Gabriel de Perthuis

crosvm matches the **64-bit BOOT PROTOCOL** described in . 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....

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. For now my...

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...

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...

Yeah, I did that with a jmp and it worked.

It looks like it can only be implemented on spt ant hvt (with fdatasync, so more costly than a basic barrier). Virtio has support too (as an optional feature), but...

Since this interface should be sector aligned, should we break consistency and take offsets and length as sectors? Would it simplify the checking the spt backend would need to do...

With spt bindings on Linux, this will use [fallocate](http://man7.org/linux/man-pages/man2/fallocate.2.html) with `FALLOC_FL_PUNCH_HOLE` and fallback to zeroing manually if the filesystem doesn't support it. I'm not sure about tenders/hvt because that should...

(just to document the virtio fallbacks while the spec is fresh on my mind: if VIRTIO_BLK_F_WRITE_ZEROES is not supported, do the whole thing manually. Otherwise, call VIRTIO_BLK_T_WRITE_ZEROES with unmap set...

Linux also implements it for block devices: See blkdev_fallocate in https://github.com/torvalds/linux/blob/master/fs/block_dev.c At any rate, the logic for this will be the same regardless of what the backing store is; if...