Re: [Xen-devel] [PATCH v6 11/19] x86/VPMU: Initialize PMU for PV guests

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 05/21/2014 04:01 AM, Jan Beulich wrote:
> > > > On 20.05.14 at 19:47, <boris.ostrovsky@xxxxxxxxxx> wrote:
> > On 05/20/2014 11:51 AM, Jan Beulich wrote:
> > > > > > On 13.05.14 at 17:53, <boris.ostrovsky@xxxxxxxxxx> wrote:
> > > > --- a/xen/arch/x86/hvm/svm/svm.c
> > > > +++ b/xen/arch/x86/hvm/svm/svm.c
> > > > @@ -1150,7 +1150,8 @@ static int svm_vcpu_initialise(struct vcpu *v)
> > > >            return rc;
> > > >        }
> > > >    
> > > > -    vpmu_initialise(v);
> > > > +    if ( is_hvm_domain(v->domain) )
> > > > +        vpmu_initialise(v);
> > > Why?
> > This patch adds initialization for PV domains, which is conditioned by
> > is_pv_domain() in amd_vpmu_initialise()/core2_vpmu_alloc_resource(). I
> > don't want PVH domains (which call these routines) to try to set up
> > their VPMUs from here. This is supposed to happen via pvpmu_init()
> > (which in this patch will return -EINVAL for PVH).
> So what's the reason for making PVH PV-like here rather than
> HVM-like? With the intended goal of making PVH a HVM sub-mode,
> that'll require more exceptions in the long run.

Primarily because of interrupt handling: we don't end up in HVM guest's 
interrupt handler for PMU interrupts but rather in the PV PMU_VIRQ 
handler which expects shared context to be set up. This means that 
initialization for PVH has to be slightly different.
-boris


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