Re: [Xen-devel] [PATCH v18 00/16] x86/PMU: Xen PMU PV(H) support

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 02/17/2015 10:13 AM, Andrew Cooper wrote:
> On 16/02/15 22:26, Boris Ostrovsky wrote:
> > Changes in v18:
> >
> > * Return 1 (i.e. "handled") in vpmu_do_interrupt() if PMU_CACHED is
> >    set. This is needed since we can get an interrupt while this flag is
> >    set on AMD processors when multiple counters are in use (**) (AMD
> >    processor don't mask LVTPC when PMC interrupt happens and so there
> >    is a window in vpmu_do_interrupt() until it sets the mask
> >    bit). Patch #14
> > * Unload both current and last_vcpu (if different) vpmu and clear
> >    this_cpu(last_vcpu) in vpmu_unload_all. Patch #5
> > * Make major version check for certain xenpmu_ops. Patch #5
> > * Make xenpmu_op()'s first argument unsigned. Patch #5
> > * Don't use format specifier for __stringify(). Patch #6
> > * Don't print generic error in vpmu_init(). Patch #6
> > * Don't test for VPMU existance in vpmu_initialise(). New patch #15
> > * Added vpmu_disabled flag to make sure VPMU doesn't get reenabled from
> >    dom0 (for example when watchdog is active). Patch #5
> > * Updated tags on some patches to better reflect latest reviewed status)
> >
> > (**) While testing this I discovered that AMD VPMU is quite broken for
> > HVM: when multiple counters are in use linux dom0 often gets
> > unexpected NMIs. This may have something to do with what I mentioned
> > in the first bullet. However, this doesn't appear to be related to
> > this patch series (or earlier VPMU patches) --- I can reproduce this
> > all the way back to 4.1
> Do you have a public git tree with this in?
Sigh.. no. I tried setting it up on our public site but failed miserably.

I can try again if this would be helpful (you'll need Linux changes as 
well).
-boris


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