[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Re: [PATCH] Enable Core 2 Duo Performance Counters inHVM guest
- To: "Shan, Haitao" <haitao.shan@xxxxxxxxx>
- From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
- Date: Fri, 14 Dec 2007 09:54:49 +0000
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
- Delivery-date: Fri, 14 Dec 2007 01:55:38 -0800
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- Thread-index: Acg73Y05/4ppWsehQP2zvW5iILuRqwABFPeHAATfHyAABFZkiwCG+UmAAAJGdv8AADdksAACsmls
- Thread-topic: [Xen-devel] Re: [PATCH] Enable Core 2 Duo Performance Counters inHVM guest
1. Shouldn’t the family-specific file be called vpmu_core2.c then?
2. Ah yes, actually setup_irq()/request_irq() is not a suitable interface. The current code is fine.
-- Keir
On 14/12/07 09:32, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:
Is the virtualisation for Core, or Core 2, or both?
Only Core 2. The reason is that Core do not have global control MSR. This MSR is the only one which will use VMX's HW capability to save and load on vmentry/vmexit. The benefit is the all the other MSRs can be handled with software flexibility, like the "lazy load" mechanism.
I don’t think you need to statically allocate a PMU_VECTOR. request_irq() yourself a vector when VMX is initialised at boot time. This will avoid touching a bunch of generic files.
But request_irq can not ensure PMU can be assigned with a high vector. High vector will help to handle PMIs in time so that gain accurate performance data.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
