From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Mon, 08 Mar 2010 20:14:52 +0200 Message-ID: <4B953E9C.6020907@redhat.com> References: <4B86917C.4070102@redhat.com> <20100225173423.GB4246@8bytes.org> <20100226084241.GF15885@elte.hu> <4B87987A.2020302@redhat.com> <20100226104437.GB7463@elte.hu> <4B87AF44.9090702@redhat.com> <20100226114217.GI7463@elte.hu> <4B87B5DE.30503@redhat.com> <1267190907.22519.601.camel@laptop> <4B87D1C8.5090901@redhat.com> <1267195321.22519.618.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jes Sorensen , Ingo Molnar , Joerg Roedel , KVM General , Zachary Amsden , Gleb Natapov , ming.m.lin@intel.com, "Zhang, Yanmin" , Thomas Gleixner , "H. Peter Anvin" , Arjan van de Ven , Fr??d??ric Weisbecker , Arnaldo Carvalho de Melo To: Peter Zijlstra Return-path: Received: from mx1.redhat.com ([209.132.183.28]:31980 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751136Ab0CHSR2 (ORCPT ); Mon, 8 Mar 2010 13:17:28 -0500 In-Reply-To: <1267195321.22519.618.camel@laptop> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 04:42 PM, Peter Zijlstra wrote: > > Also, intel debugstore things requires a host linear address, It requires a linear address, not a host linear address. Of course, it might not like the linear address mappings changing under its feet. If it has a private tlb, then this won't work. > again, not > something a vcpu can easily provide (although that might be worked > around with an msr trap, but that still limits you to 1 page data sizes, > not a limitation all software will respect). > If you're willing to pin pages, you can map the guest's buffer. That won't work if BTS can happen in parallel with a #VMEXIT, or if there are interactions with npt/ept. Will have to ask the vendors. >> All that said, what we really want is for Intel+AMD to come up with >> proper hw PMU virtualization support that makes it easy to rotate the >> full PMU in and out for a guest. Then this whole discussion will become >> a non issue. >> > As it stands there simply are a number of PMU features that defy being > virtualized, simply because the virt stuff doesn't do system topology. > So even if they were to support a virtualized pmu, it would likely be a > different beast than the native hardware is, and it will be several > hardware models in the future, coming up with a paravirt interface and > getting !linux hosts to adapt and !linux guests to use is probably as > 'easy'. > !linux hosts are someone else's problem, but how would be get !linux guests to use a soft pmu? The only way I see that happening is if a soft pmu is standardized across hypervisors, which is unfortunately unlikely. -- error compiling committee.c: too many arguments to function