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

["Roger Pau Monné" <roger.pau@citrix.com>]

El 10/06/15 a les 23.31, Andrew Cooper ha escrit:
> 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. 

That's not 100% true, since we agreed to always launch the guest in
32bit protected mode we could create some simple 32bit page tables
without PAE.

IMHO it's not worth it, it's very unlikely that the page tables we build
are going to be suitable for the guest OS, so the guest needs to build
it's own page tables anyway.

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

I have the following trampoline which seems to work fine on a FreeBSD
64bit kernel (which is an ELF64 binary itself):

https://people.freebsd.org/~royger/xen-locore32.S

(I've also hacked the HVM builder code in libxc in order to load a
kernel directly instead of the hvmloader image, but that's too dirty to
post here).

Roger.