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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.15 at 16:31, <roger.pau@xxxxxxxxxx> wrote:
> El 04/09/15 a les 16.08, Jan Beulich ha escrit:
>>>>> On 04.09.15 at 14:11, <roger.pau@xxxxxxxxxx> wrote:
>>> The format of the structure passed in the %ebx register is the following:
>> 
>> Even if it may sound like splitting hair: Please use precise wording. It's
>> not the structure that's contained in %ebx, but %ebx hold the address
>> of that structure.
> 
> Would you be fine with replacing this sentence with:
> 
> The format of the boot start info structure is the following:

Yes (maybe insert "(pointed to be %ebx)").

>>> struct hvm_start_info {
>>> #define HVM_START_MAGIC_VALUE 0x336ec578
>>>     uint32_t magic;             /* Contains the magic value 0x336ec578      
>>>  */
>>>                                 /* ("xEn3" with the 0x80 bit of the "E" 
>>> set).*/
>>>     uint32_t flags;             /* SIF_xxx flags.                           
>>>  */
>> 
>> Do really mean to re-use the SIF_* flags here?
> 
> We can introduce a new set of flags, HVM_INIT_*, which ATM is only going
> to be:
> 
> #define HVM_FLAGS_INITDOMAIN (1<<0)

From an abstract pov I'd prefer that. Maybe I'm overlooking
something which would be simplified by using the same values...

>>> AP startup
>>> ==========
>>>
>>> AP startup is performed using hypercalls. The following VCPU operations
>>> are used in order to bring up secondary vCPUs:
>>>
>>>  * VCPUOP_initialise is used to set the initial state of the vCPU. The
>>>    argument passed to the hypercall must be of the type vcpu_hvm_context.
>> 
>> VCPUOP_initialise takes a struct vcpu_guest_context; I don't think
>> we can or should change that.
> 
> Didn't we agree that vcpu_guest_context was not suitable for HVM/PVH guests?

Yes we did.

> Patch 24 of my HVM-without-dm series already introduces this new
> structure and the necessary helpers.

I didn't look at most of the series yet (despite it already being at v6;
I'm sorry, I just didn't get around so far). But I think you agree that
we can't just change an existing hypercall. Iirc along with agreeing
on vcpu_guest_context not being suitable we also agreed that this
will need to be a new sub-op, and I wondered whether calling it
VCPUOP_initialize would be too subtle.

Jan


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