[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 04.09.15 at 17:26, <ian.campbell@xxxxxxxxxx> wrote:
> On Fri, 2015-09-04 at 09:21 -0600, Jan Beulich wrote:
>> > > > 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:
>> > > > 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.
> 
> You mean literally only s/s/z/?

Indeed ;-)

> In which case, yes, far far to subtle.

I was afraid I would get feedback like this (and I was surprised I
didn't already when I first suggested this).

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.