3 ms·
I don't think that working with proprietary piece of code which is not even allowed to be used for anything but proprietary virtualization.framework is very int
by vbezhenar 3y ago
I don't think that working with proprietary piece of code which is not even allowed to be used for anything but proprietary virtualization.framework is very interesting for those who can pull that kind of implementation.
Theoretically: why not? Kernel is not something drastically different from userspace. Sure, some rules are different, but I don't think that it's completely impossible to adapt Rosetta to the kernel.
But practically: I doubt it. qemu is not supporting even ordinary Rosetta, last time I checked, despite that fact that it should be pretty trivial to implement.
- doctoboggan 3y ago"Docker Desktop for Mac" as the option to use rosetta 2 to run linux/amd64 containers on apple silicon Macs.
- maxmouchet 3y agoRosetta is used to run the amd64 binaries, but not the (arm) kernel of the Docker VM.
- zeusk 3y ago> Theoretically: why not? Kernel is not something drastically different from userspace. Sure, some rules are different, but I don't think that it's completely impossible to adapt Rosetta to the kernel. It's not impossible but very infeasible since kernel has critical sections where you can't take an interrupt or fault (leading to panic); such code sitting at the translation boundary would not work.
- gorkish 3y agoThis is why I mentioned "old vmware" which before VT handled these types of critical sections through an interpreting emulator while executing as many of the x86 instructions as possible unmodified. That is to say, they already did the hard part of breaking out the tricky bits. I was kind of hoping maybe QEMU had a similar strategy for x86-machine-on-x86-usermode without requiring virtualization extensions that could just be executed directly through rosetta (on macos or linux)