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 15.18, Andrew Cooper ha escrit:
>>  * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits
>>    are all undefined. 
> 
> "unspecified" is perhaps better phrasing.  Most will be 0, but ET will
> be set as it is a read-only bit in all processors Xen will function on
> these days.

OK. I think we can say that:

 * cr0: bit 0 (PE) and bit 4 (ET) will be set. All the other bits are
   cleared.

> Perhaps also worth calling out cr4 as well, which typically starts as
> all zeroes.

 * cr4: all bits are cleared.

>>
>>  * cs: must be a 32-bit read/execute code segment with an offset of ‘0’
>>    and a limit of ‘0xFFFFFFFF’. The exact value is undefined.
>>
>>  * ds, es, fs, gs, ss: must be a 32-bit read/write data segment with an
>>    offset of ‘0’ and a limit of ‘0xFFFFFFFF’. The exact values are all
>>    undefined. 
> 
> I would be tempted to only define ds and possibly es.  Any code using
> this boot protocol will load its gdt and reload the segments in very
> short order, and ss is useless until esp has been set up appropriately.

I would rather prefer to have ss already defined according to the above
text, this way you just need to load a valid stack into esp, but I'm not
going to strongly argue about it.

>> Do we want to keep using the start_info page? Most of the fields there 
>> are not relevant for auto-translated guests, but without it we have to 
>> figure out how to pass the following information to the guest:
>>
>>  - Flags: SIF_xxx flags, this could probably be done with cpuid instead.
>>  - cmd_line: ?
>>  - console mfn: ?
>>  - console evtchn: ?
>>  - console_info address: ?
> 
> All console information should be available from the HVMPARAMS.  I see
> no reason to prevent a PVH guest getting at these.
> 
> This just leaves the command line being awkward.

I've forgot to add the kernel payload (initramfs), which could also be
fetched using a HVMPARAM, so that just leaves the cmd_line, which could
be passed as a physical memory address in one of the gp registers. I
don't have a strong opinion on whether we should create a new
hvm_start_info struct that contains those, or whether we should just add
new HVMPARAMS.


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