Re: [RFC PATCH 8/16]: PVH xen: domain creation code changes

[Mukesh Rathor <mukesh.rathor@oracle.com>]

On Mon, 14 Jan 2013 11:49:42 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 12.01.13 at 02:57, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > +#if 0
> > +    /* should we allow PV dom0 to create PVH domU's ???? */
> > +    if ( is_pvh_vcpu(v) && !is_pvh_vcpu(current) )
> > +        return -EINVAL;
> > +#endif
> 
> Any Dom0 ought to be able to construct any kind of guest imo.

Agree. Removed the code.

> So you add these hooks, call them unconditionally, yet neither VMX
> nor SVM implement them? What's the purpose? Series of patches
> are expected to be consistent at each patch boundary.

I'm told to keep patch sizes small, so I try to group together
changes. The functions are small/generic enough I figured it would 
be OK.

> > --- a/xen/include/asm-x86/hvm/vcpu.h	Fri Jan 11 16:29:49
> > 2013 -0800 +++ b/xen/include/asm-x86/hvm/vcpu.h	Fri Jan 11
> > 16:31:33 2013 -0800 @@ -104,6 +104,13 @@ struct nestedvcpu {
> >  
> >  #define vcpu_nestedhvm(v) ((v)->arch.hvm_vcpu.nvcpu)
> >  
> > +/* add any PVH specific fields here */
> > +struct pvh_hvm_vcpu_ext
> > +{
> > +    /* Guest-specified relocation of vcpu_info. */
> > +    unsigned long pvh_vcpu_info_mfn;
> 
> Isn't that a field equivalent to v->arch.pv_vcpu.vcpu_info_mfn?
> Preferably they would be shared then, or if not, having "pvh" in
> the containing structure's field name and the field name here is
> clearly one too much.

No, it's a union, so can't use pv_vcpu.vcpu_info_mfn. I like the
3 char prefix to field name so grep/cscope can find it easily.

Thanks,
Mukesh