Re: [Xen-devel] [Draft A] Boot ABI for HVM guests without a device-model

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/06/2015 19:55, Konrad Rzeszutek Wilk wrote:
>> All other processor registers and flag bits are undefined. The OS is in 
>> charge of setting up it's own stack, GDT and IDT.
>>
>> Note that the boot protocol resembles the multiboot1 specification, 
>> this is done so OSes with multiboot1 entry points can reuse those if 
>> desired. Also note that the processor starts with paging disabled, 
>> which means that all the memory addresses in the start_info page will 
>> be physical memory addresses.
> Wow?! Pagetables disabled?! Why? Usually boot loaders start with some
> pagetables setup for the OS - to cover at least the kernel and the
> ramdisk. Either it being in 1-1 pagetables or such.
>
> Why make this work harder for the guest?
> Why can't the hypervisor setup most of these things for the guest?

If you start with paging enabled, the domain builder has to know the
intended runmode and paging details a priori. 

Starting with paging disabled allows one single guest binary to set
itself up however it likes, which includes one single binary being able
to chainload any further payload; an option not available to PV guests
at all.

There are usecases which actually want to run without paging, or without
PAE.  Few, granted, but some non-the-less.  Alternatively, a distro
which might wish to choose between 32 or 64bit depending on the quantity
of RAM in the VM.

From a 32bit flat entry, it is 0x40 bytes worth of instructions for
32bit, or 0x4f bytes worth of instructions for 64bit to get set up in
the desired paging mode, with a usable stack (and I could definitely
reduce those numbers, at the expense of readability). (TODO - find
enough free time to finish the test framework and publish it.)  The
point is that it is not hard at all, but offers substantially more
flexibility to both host and guest software.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel