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

Re: [Xen-devel] RFC: PVH set vcpu info context in vmcs....



On Mon, 19 Aug 2013 10:34:49 +0100
"Jan Beulich" <jbeulich@xxxxxxxx> wrote:

> >>> Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> 08/17/13 3:37 AM >>>
> >/*
> >* Set vmcs fields during boot of a vcpu. Called from
> >arch_set_info_guest. *
> >* Boot vcpu call is from tools via:
> >*     do_domctl -> XEN_DOMCTL_setvcpucontext -> arch_set_info_guest
> >*
> >* Secondary vcpu's are brought up by the guest itself via:
> >*     do_vcpu_op -> VCPUOP_initialise -> arch_set_info_guest
> >*     (In case of linux, the call comes from
> >cpu_initialize_context()).
> 
> So here you describe clearly that the function is to be called for
> each vCPU exactly once. No vCPU == 0 special casing needed (also not
> in the caller, as I understood you moved the check there - if not,
> all is fine).

No more check for vcpu==0 needed now.

> >int vmx_pvh_vcpu_boot_set_info(struct vcpu *v, 
> >struct vcpu_guest_context *ctxtp)
> >{
> >if ( ctxtp->ldt_base || ctxtp->ldt_ents ||
> >ctxtp->user_regs.cs || ctxtp->user_regs.ss || ctxtp->user_regs.es ||
> >ctxtp->user_regs.ds || ctxtp->user_regs.fs || ctxtp->user_regs.gs ||
> >ctxtp->gdt.pvh.addr || ctxtp->gdt.pvh.limit ||
> >ctxtp->fs_base || ctxtp->gs_base_user )
> >return -EINVAL;
> 
> I assume there's be a place where these restrictions are both
> documented and rationalized; otherwise this looks pretty arbitrary.

Yes, I'll document the API.

thanks
mukesh


_______________________________________________
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®.