From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH] libxc: Add xc_domain_hvm_get_mtrr_type() call Date: Wed, 19 Dec 2012 17:46:27 +0000 Message-ID: <20121219174627.GA67643@ocelot.phlegethon.org> References: <50D19A2B.2050006@gmail.com> <1355916539.14620.332.camel@zakaz.uk.xensource.com> <50D1A9D1.2020106@gmail.com> <50D1D5BD.8080001@gmail.com> <1355929247.14620.436.camel@zakaz.uk.xensource.com> <50D1DCC5.5050309@citrix.com> <1355932443.14620.448.camel@zakaz.uk.xensource.com> <50D1E723.4070201@citrix.com> <1355933739.14620.456.camel@zakaz.uk.xensource.com> <50D1EB56.40400@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <50D1EB56.40400@gmail.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: Razvan Cojocaru Cc: Andrew Cooper , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org At 18:29 +0200 on 19 Dec (1355941750), Razvan Cojocaru wrote: > >>Ah - I see your concern. Yes - it might well be different. Is this > >>information passed in an HVM save record? It does not appear to be > >>associated with the MTRR HVM save record. > > > >No , this is the internal state not the save record but Razvan is > >implementing the same logic in libxc which must necessarily be based on > >the hvm saved state only and not the internal emulation state. > > Exactly, and all I need extra an extra variable in the save record (or > simply a single bit in a safe place in one of the existing ones), > telling me if the MTRRs are overlapped or not. The CPUID code is just a > part of the logic that finds this out in the hypervisor; and > specifically it is a part that's better _left_in_ the hypervisor. That > is in fact what I was trying to say a few messages ago, when I called > the cpuid_eax() function the tricky part. :) > > Do we agree that a bool_t overlapped should be added to struct > hvm_hw_mtrr for this case? Sorry, no. The 'overlapped' bit is a piece of xen implementation, and not an architectural state of the VM, so it doesn't belong in the save record. It's trivial to recalculate in a user-space tool, and the result can be cached (since you can also get a mem-event on MSR writes, you don't have to pull all this MTRR state out of the giuest except when the MTRRs have been changed). I'll take a proper look at this thread tomorrow and see if I can suggest anything more helpful. Tim.