-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crosvm support #334
Comments
So the virtio image is multiboot-based (multiboot 1), and crosvm hardcodes some offsets based on x86_64 Linux conventions. So either Solo5's loader should match those conventions or crosvm should be updated to read a multiboot header before setting up registers. |
That makes sense to me. I'd try and fix crosvm to support multiboot, otherwise we'd have to maintain some kind of virtio-for-crosvm subtarget inside Solo5 which would be a pain. |
crosvm matches the 64-bit BOOT PROTOCOL described in https://www.kernel.org/doc/Documentation/x86/boot.txt. Solo5's multiboot1 header can't be used because multiboot1 is an x86_32 specification, and crosvm only emulates the CPU in x86_64 mode. |
Hmm, okay. I guess that makes sense for them since all the(ir) world is Linux. Though you mentioned that crosvm tries to boot our kernels anyway, is that because the Linux boot protocol has no magic number that lets you detect if the thing you're loading supports it? Here's a thought. Would it be possible for us to build a virtio binary that supports both protocols in the same file? That would be the way to do it, since it doesn't introduce any kind of "sub-target" or compile-time option/setting. |
I'll have to look into it. I think it's possible, since the protocols both use their own offsets (through a symbol in the mutiboot case) and headers. |
I think some people tried that ages ago and it didn't work. Our virtio code is minimal so tends to get unhappy if anything in the chain-loading process leaves the virtio "hardware" in a non-default state. |
After the elf has been loaded in memory, crosvm will skip past the first 200 bytes which may contain some 32-bit initialization code, the freshly initialized cpu seems to slide past any zero instructions (I had trouble debugging that, but I expect that there's just no logic to handle them yet), then it lands on an entry point that follows Linux's startup_64 convention. As a consequence, our hybrid elf image should put its multiboot header past the text segment. |
Though the multiboot header's physical position within the elf should be quite early (first 8192 bytes), it should either be loaded within the first 200 bytes, loaded past the start of the .text section, or not loaded at all. I'll look at what I can do with linker scripts. Edit: it needs to be loaded. Another option would be to insert a jump past the header. |
Off the top of my head, you could add a
in the linker script. Assuming WDYT? |
Yeah, I did that with a jmp and it worked. |
crosvm is a qemu alternative with a smaller attack surface, and sometimes better virtio support.
To build it, you need either a full checkout of the chromeos development tree, or a checkout containing at least:
It builds as a standard Rust project, with
cargo build
.Then you can test it with commands like these:
The text was updated successfully, but these errors were encountered: