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

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



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?

~Andrew

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