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 17.21, Jan Beulich ha escrit:
>>>> 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.

VCPUOP_initialize was never available to HVM guests, so I don't think
changing the argument is a problem. However, I understand that for the
sake of clarity overloading an hypercall this way is not the best
practice. What about naming it VCPUOP_hvm_initialise?

Would it make sense to add aliases to have:

#define VCPU_hvm_up VCPU_up
#define VCPU_hvm_down VCPU_down
#define VCPU_hvm_is_up VCPU_is_up

Just for symmetry reasons?

Roger.


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