Xen devel - May 2007 - [PATCH] [HVM][SVM] Handle threshold register for guests

Hi!

The threshold register has been introduced in AMD RevF CPUs along with SVM
(Actually this MCA/MCE msr register existed before, but had no meaning).
Therefore no need for additional cpuid checks.

On read access it reports the HVM guest the register has been locked by the 
BIOS. This means, it is not available for OS use. Thus, write accesses are
simply ignored.
This behaviour actually matches real HW, so guests can deal with this.

Further, this way no multiplexing for multiple guests is necessary.
Please apply.

Signed off by: Christoph Egger <Christoph.Egger@amd.com>


-- 
AMD Saxony, Dresden Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


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

On 21/5/07 18:24, "Christoph Egger" <Christoph.Egger@amd.com>
wrote:
> The threshold register has been introduced in AMD RevF CPUs along with SVM
> (Actually this MCA/MCE msr register existed before, but had no meaning).
> Therefore no need for additional cpuid checks.
> 
> On read access it reports the HVM guest the register has been locked by the
> BIOS. This means, it is not available for OS use. Thus, write accesses are
> simply ignored.
> This behaviour actually matches real HW, so guests can deal with this.
> 
> Further, this way no multiplexing for multiple guests is necessary.
> Please apply.
I can''t find any information about the revised semantics of M4_MISC in
the
latest revision (3.12) of Volume 2 of the AMD64 Architecture
Programmer''s
Manual. Am I looking in the wrong place?

Since we don''t advertise SVM capability to guests, wouldn''t
they assume old
semantics for this register anyway?

 Thanks,
 Keir


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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Keir Fraser
> Sent: 24 May 2007 11:46
> To: Egger, Christoph; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] [HVM][SVM] Handle threshold 
> register for guests
> 
> On 21/5/07 18:24, "Christoph Egger"
<Christoph.Egger@amd.com> wrote:
> 
> > The threshold register has been introduced in AMD RevF CPUs 
> along with SVM
> > (Actually this MCA/MCE msr register existed before, but had 
> no meaning).
> > Therefore no need for additional cpuid checks.
> > 
> > On read access it reports the HVM guest the register has 
> been locked by the
> > BIOS. This means, it is not available for OS use. Thus, 
> write accesses are
> > simply ignored.
> > This behaviour actually matches real HW, so guests can deal 
> with this.
> > 
> > Further, this way no multiplexing for multiple guests is necessary.
> > Please apply.
> 
> I can''t find any information about the revised semantics of 
> M4_MISC in the
> latest revision (3.12) of Volume 2 of the AMD64 Architecture 
> Programmer''s
> Manual. Am I looking in the wrong place?
> 
> Since we don''t advertise SVM capability to guests,
wouldn''t
> they assume old
> semantics for this register anyway?
Yes, you''re looking in the wrong place the APM is for "generic
functionality", the BIOS and Kernel Developer''s Guide (BKDG) is
more
specific as to implementation details for the different generations, and
on page 225 [public version], you''ll find the details of this register.

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
32559.pdf

As to whether the processor expects this behaviour or not is a different
question. But let''s say they use the family/model CPUID info to
identify
if this feature is available or not, rather than the more loosely
coupled feature-bit of SVM (e.g. a Sempron Rev F processor would have
the functionality in this register, but no SVM bit set as it''s not got
SVM-feature). 

I think the patch is OK to support any future OS that MAY try to use
this register. It''s not harming anything, right?

--
Mats
> 
>  Thanks,
>  Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 


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

On Thursday 24 May 2007 13:00:10 Petersson, Mats wrote:
> > On 21/5/07 18:24, "Christoph Egger"
<Christoph.Egger@amd.com> wrote:
> > > The threshold register has been introduced in AMD RevF CPUs
> > > along with SVM (Actually this MCA/MCE msr register existed
before,
> > > but had no meaning).
> > > Therefore no need for additional cpuid checks.
> > >
> > > On read access it reports the HVM guest the register has
> > > been locked by the BIOS. This means, it is not available for OS
use.
> > > Thus, write accesses are simply ignored.
> > > This behaviour actually matches real HW, so guests can deal with
this.
> > > Further, this way no multiplexing for multiple guests is
necessary.
> > > Please apply.
> >
> > I can''t find any information about the revised semantics of
> > M4_MISC in the latest revision (3.12) of Volume 2 of the
> > AMD64 Architecture Programmer''s Manual. Am I looking in the
wrong place?
> >
> > Since we don''t advertise SVM capability to guests,
wouldn''t
> > they assume old semantics for this register anyway?
>
> Yes, you''re looking in the wrong place the APM is for
"generic
> functionality", the BIOS and Kernel Developer''s Guide (BKDG)
is more
> specific as to implementation details for the different generations, and
> on page 225 [public version], you''ll find the details of this
register.
>
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
> 32559.pdf
>
> As to whether the processor expects this behaviour or not is a different
> question. But let''s say they use the family/model CPUID info to
identify
> if this feature is available or not, rather than the more loosely
> coupled feature-bit of SVM (e.g. a Sempron Rev F processor would have
> the functionality in this register, but no SVM bit set as it''s not
got
> SVM-feature).
The code the patch adds will never run on these CPUs, so no problem.
> I think the patch is OK to support any future OS that MAY try to use
> this register. It''s not harming anything, right?
Yes, that''s right.

<side node>
Linux/x86_64 does the threshold counting in software, but
it reads the HW register at boot time one time for each CPU
to get a value where to start counting from. With
my patch, Linux does not find the threshold register marked as
not being available for OS use and starts counting from zero
for sure.
</side node>


-- 
AMD Saxony, Dresden Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy



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

On 24/5/07 12:00, "Petersson, Mats" <Mats.Petersson@amd.com>
wrote:
> Yes, you''re looking in the wrong place the APM is for
"generic
> functionality", the BIOS and Kernel Developer''s Guide (BKDG)
is more
> specific as to implementation details for the different generations, and
> on page 225 [public version], you''ll find the details of this
register.
> 
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
> 32559.pdf
> 
> As to whether the processor expects this behaviour or not is a different
> question. But let''s say they use the family/model CPUID info to
identify
> if this feature is available or not, rather than the more loosely
> coupled feature-bit of SVM (e.g. a Sempron Rev F processor would have
> the functionality in this register, but no SVM bit set as it''s not
got
> SVM-feature). 
> 
> I think the patch is OK to support any future OS that MAY try to use
> this register. It''s not harming anything, right?
I''ll take another look. I think the patch will be fine.

 -- Keir


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