WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH] Enable Core 2 Duo Performance Counters in HVM gu

To: "Shan, Haitao" <haitao.shan@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Enable Core 2 Duo Performance Counters in HVM guest
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 11 Dec 2007 15:01:32 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Delivery-date: Tue, 11 Dec 2007 06:55:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <823A93EED437D048963A3697DB0E35DEF355D2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acg73Y05/4ppWsehQP2zvW5iILuRqwABFPeHAATfHyAABFZkiw==
Thread-topic: [PATCH] Enable Core 2 Duo Performance Counters in HVM guest
User-agent: Microsoft-Entourage/11.3.6.070618
Oh yes, I see you save/restore MSR state and LVTPC across context switch. That’s fine then. But I don’t think you should pass through any of the virtual LVTPC register fields at all, except to toggle the mask field of the real LVTPC depending on whether or not performance counter interrupt delivery is currently enabled for the VCPU (I’d implement this just to avoid unnecessary real interrupts which are certainly not going to turn into virtual interrupts). There are no real LVTPC fields which should really be under guest control, and so cooking the guest LVTPC value and poking it into the real LVTPC in the vlapic code looks odd. As does save/restore of the whole LVTPC on context switch -- at most you should need to track masked/not-masked. And you’re letting the guest have access to reserved bits of the real LVTPC, which is not good...

Ignore my comment about save/restore — I misread your context-switching code as HVM save/restore code!

 -- Keir

On 11/12/07 13:32, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:

* Poking the LVTPC as a one-off event only when the VCPU writes its virtual LVTPC is not going to fly. What if the VCPU is subsequently migrated to a different physical CPU? In any case the LVTPC is a shared resource that needs synchronised access via e.g., context switching or mutual exclusion (see the next point below).
I think in the patch I will save/load LVTPC during context switch.

 * How does this interact with, for example, xenoprof? Ideally we should be able to run xenoprof and this concurrently over disjoint subsets of domains. At the very least xenoprof and this patch should avoid stomping on each other by implementing some form of mutual exclusion. Probably some resource sharing (e.g., the PMC interrupt vector) also is possible. I expect this will require some design thought, but unfortunately that is the price for being second into the tree.
Yes. How to share PMU resources will need careful design. But I really don’t think it possible to run both concurrently unless we do some sort of PMC’s partition. Of course, it is silly of me not to implement a mechanism for mutual exclusion. I will implement one.

 * Impact on save/restore to/from Core-2 processors: has this been tested at all?
I will try doing the test. I think whether it should support save/restore can be argued. Does anyone want to run VTune/Oprofile during save/restore? This can be hardly a good usage model. But at least, I update it to ensure it does not break current save/restore.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel