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

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Sat, 17 Aug 2013 11:22:20 +0100
Tim Deegan <tim@xxxxxxx> wrote:

> At 18:37 -0700 on 16 Aug (1376678229), Mukesh Rathor wrote:
> > Ok, changed the tools to clear fields, tested and everything works:
> > 
> > /*
> >  * 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()). *
> >  * Note, PVH save/restore is expected to happen the HVM way, ie,
> >  *        do_domctl -> XEN_DOMCTL_sethvmcontext -> hvm_load/save
> >  * and not get here.
> >  *
> >  * PVH 32bitfixme: this function needs to be modified for 32bit
> > guest.
> 
> What's the 32-bit interface going to be like?  Presumably it will have
> to load segment state, so this is just postponing that work until
> then.

Right. I think by tweaking guest mostly and xen some, taking 
advantage of the hvm container, we might be able to get 32bit down to 
bare minimum.

> >  */
> > 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;
> > 
> >     vmx_vmcs_enter(v);
> >     __vmwrite(GUEST_GS_BASE, ctxtp->gs_base_kernel);
> >     vmx_vmcs_exit(v);
> 
> Why does this one field get loaded?  Couldn't it be zero too?

With this both xen and guest can get rid of some code. Without it, 
the guest would need ugly hack, and vcpu bringup will be serialized.
So, this seems to be the most optimal solution. 

thanks
mukesh

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