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@lists.xen.org
http://lists.xen.org/xen-devel
