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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/06/15 16:38, Roger Pau Monnà wrote:
> 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.

bit 0 set, all other writeable bits clear.

We should not state that ET will be set, even though will be the case in
reality.

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

I would prefer not to give people rope to hang themselves with, when it
comes to making assumptions about starting state.

Any code which doesn't explicitly set up ss is skating on thin ice.

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

I should have remembered as well, as I have a curiously-pvh-like usecase
which wants similar bits.

The reason I suggested multiboot was for modules and command line
support.  If we are not going for exactly multiboot, but something
similar, we might want to make a pvh_start_info with a module list and
cmdline pointer in it.

~Andrew

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