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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.06.15 at 16:53, <roger.pau@xxxxxxxxxx> wrote:
> El 10/06/15 a les 15.15, Jan Beulich ha escrit:
>>>>> On 10.06.15 at 14:34, <roger.pau@xxxxxxxxxx> wrote:
>> For my taste, it's getting too
>> close to something that could be a legitimate 32-bit kernel pointer
>> (agreed, all values could be valid pointers in 32-bit OSes, but with
>> OSes tending to place themselves high in memory, a value numerically
>> closer to what multiboot1 uses would seem more desirable).
> 
> I don't have any strong opinions here, does the following seem more 
> suitable:
> 
> 0x336ec578 ("xEn3" with the 0x80 bit of the "E" set)
> 
> (from xc_dom_binloader.c)

That would seem fine to me.

>>>  * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits
>>>    are all undefined. 
>> 
>> I see that grub1 documentation says so, but I doubt this is realistic
>> (even less so for cr4 bits): Some of the bits (including ones not
>> currently defined) may have a meaning even in non-paged protected
>> mode, and the environment should be as completely defined as possible.
>> I.e. I think most other bits should be defined to be zero upon handoff.
>> 
>>>  * 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.
>> 
>> I guess "exact value" really means "selector value".
> 
> I think so, it's a literal copy from the multiboot1 spec.

In which case let's please try to be more accurate.

>>> Comments for further discussion:
>>>
>>> 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: ?
>> 
>> Yeah, settling on ideally a reasonably arch-independent mechanism
>> that doesn't place undue constraints on future ports would be nice.
>> And considering a hypothetical variant of x86 Xen not supporting PV
>> guests anymore, this would no longer define XEN_HAVE_PV_GUEST_ENTRY
>> and hence no longer have a struct start_info. So from a puristic pov
>> the information should indeed be conveyed another way.
> 
> What about the following layout:
> 
> struct hvm_start_info {

I mean, if you want to go with another structure, then I can't see why
you wouldn't want to use what is there. I was rather understanding
you'd like to go without any such structure, and would allow the guest
to retrieve the respective data another way (CPUID, HVM param, ...).

Jan

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