From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v10 09/20] x86/VPMU: Add public xenpmu.h Date: Fri, 12 Sep 2014 11:18:48 -0400 Message-ID: <54130ED8.1000707@oracle.com> References: <1409802080-6160-1-git-send-email-boris.ostrovsky@oracle.com> <1409802080-6160-10-git-send-email-boris.ostrovsky@oracle.com> <54108045020000780003362D@mail.emea.novell.com> <5410890B.9010900@oracle.com> <54115FCA0200007800033A6C@mail.emea.novell.com> <5411A97C.7090100@oracle.com> <5411D40F0200007800033FDA@mail.emea.novell.com> <5411BF12.6090600@oracle.com> <5411E2F502000078000340BA@mail.emea.novell.com> <5411D31B.90403@oracle.com> <5412B3DE02000078000344A0@mail.emea.novell.com> <54130169.9000006@oracle.com> <5413219402000078000348D8@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5413219402000078000348D8@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: tim@xen.org, kevin.tian@intel.com, keir@xen.org, suravee.suthikulpanit@amd.com, andrew.cooper3@citrix.com, eddie.dong@intel.com, xen-devel@lists.xen.org, Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com List-Id: xen-devel@lists.xenproject.org On 09/12/2014 10:38 AM, Jan Beulich wrote: >>>> On 12.09.14 at 16:21, wrote: >> On 09/12/2014 02:50 AM, Jan Beulich wrote: >>> Okay, so you're tailoring the hypervisor interface to Linux. That's >>> not what we generally aim for, and hence I continue to think this >>> isn't the right approach. >> But we know that at least one consumer of this interface (Linux/perf) >> does want to have full GPR set. > You said they use a struct pt_regs somewhere - that's not the same > as struct cpu_user_regs (and the overlap of registers being in both > is not much more than a coincidence), and you didn't clarify yet how > much of this information is _actually_ getting consumed (i.e. this may > well just happen to be a suitable container for conveying a smaller > set). I don't know how all registers are consumed in Linux code (except for RIP and CS) and I am not sure it's all that important: we know that we need to pass GPRs to perf infrastructure which, for the most part, is a black box (especially given the insane amount of code churn that happens in perf). If and when we find out that something that perf wants is not provided in pt_regs (converted from cpu_user_regs) then we will have to deal with it. But it's not much different from what would happen if we use specific registers in the shared structure. > >> So why not provide it? Especially since >> (I suspect that) doing memcpy may be faster than copying only selected >> fields. >> >> If you are categorically against this I can certainly rework this and >> pass RIP, RSP, CS and EFLAGS only. > My problem with this is that (a) it exposes an arbitrary subset of > registers and (b) in an incompatible way (a 32-bit profiling domain > should very well be told all 64-bit registers of a 64-bit guest it > profiles). Since b would need addressing by a custom structure > anyway, dealing with a at the same time seems reasonable to me. Note that (b) is not supported --- 32-bit domains can only profile themselves and not the hypervisor (or other domains). > > But of course it would help if other interested parties would voice > their view of this... -boris