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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

El 04/09/15 a les 16.08, Jan Beulich ha escrit:
>>>> On 04.09.15 at 14:11, <roger.pau@xxxxxxxxxx> wrote:
>>  * cs: must be a 32-bit read/execute code segment with an offset of â0â
>>    and a limit of â0xFFFFFFFFâ. The selector value is unspecified.
>>
>>  * ds, es: must be a 32-bit read/write data segment with an offset of
>>    â0â and a limit of â0xFFFFFFFFâ. The selector values are all unspecified.
> 
> In both cases s/offset/base/.

Right, sorry.

> 
>>  * tr: must be a 32-bit TSS (active) with a base of '0' and a limit of 
>> '0xFF'.
> 
> Already on the previous version I asked about this strange 0xFF,
> and I don't recall any answer.

My bad, I have actually changed this in the code (see v6), but forgot to
update the design document. 0x67 is perfectly fine, and is what should
be used.

Just for the record, I've initially set it to 0xff because that's how
it's done in construct_vmcs.

>>  * eflags: bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared.
>>    Other bits are all unspecified.
> 
> At the very least I'd also require TF to be clear.

Yes, that makes sense. I'm quite surprised that multiboot1 doesn't
mandate TF to also be cleared.

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

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

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

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

Roger.


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