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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-09-04 at 17:47 +0200, Roger Pau Monnà wrote:
> 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?

If the new interface could support both PV (vcpu_guest_context) and the new
thing (i.e. with a type field and a union perhaps), or if the new interface
can work for PV some other way then it's not unheard of to rename the
existing number with _compat and take over the name with a new number.

It just needs some compat __XEN_INTERFACE_VERSION__ stuff in the headers,
like with e.g. __HYPERVISOR_sched_op vs __HYPERVISOR_sched_op_compat.

(I've not looked at this interface and I don't really remember what the old
one looks like, so maybe this is an insane idea in this case)

Ian.


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