From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [PATCH] x86/HVM: correct CPUID leaf 80000008 handling
Date: Thu, 27 Mar 2014 15:22:27 +0000 [thread overview]
Message-ID: <53344233.4030906@citrix.com> (raw)
In-Reply-To: <53344D5F0200007800002F58@nat28.tlf.novell.com>
On 27/03/14 15:10, Jan Beulich wrote:
>>>> On 27.03.14 at 12:44, <tim@xen.org> wrote:
>> At 11:48 +0000 on 26 Mar (1395830898), Jan Beulich wrote:
>>> CPUID[80000001].EAX[23:16] have been given the meaning of the guest
>> s/80000001/80000008/?
> Oops, of course.
>
>>> @@ -3083,6 +3083,23 @@ void hvm_cpuid(unsigned int input, unsig
>>> if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
>>> *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
>>> break;
>>> +
>>> + case 0x80000008:
>>> + count = cpuid_eax(0x80000008);
>>> + count = (count >> 16) & 0xff ?: count & 0xff;
>>> + if ( (*eax & 0xff) > count )
>>> + *eax = (*eax & ~0xff) | count;
>>> +
>>> + hvm_cpuid(1, NULL, NULL, NULL, &_edx);
>>> + count = _edx & (cpufeat_mask(X86_FEATURE_PAE) |
>>> + cpufeat_mask(X86_FEATURE_PSE36)) ? 36 : 32;
>>> + if ( (*eax & 0xff) < count )
>>> + *eax = (*eax & ~0xff) | count;
>> What is this for? Surely if the CPU really claims to have a paddr
>> limit lower than 32 then (a) it's buggy and (b) we can't just pretend
>> it doesn't say that.
> But what we modify isn't what came from hardware, but what was
> presented (possibly overridden) by the tool stack.
This is just one of the many things in the mess which is the current
cpuid policy/levelling code where libxc and disagree in an unsafe way.
In this particular case, it is not valid for libxc to be able to set any
policy which would make cpuid.0x80000008.eax able to report a physical
width greater than currently supported on the cpu, or less than is
architecturally supported for long mode (which I believe is indeed 36
bits, but cant offhand remember where I read this).
My proposal for this was for there to be very strict sanity checking
when trying to upload the policy leaves, which removes large quantities
of Xen's second-guessing in locations such as this.
~Andrew
next prev parent reply other threads:[~2014-03-27 15:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 11:48 [PATCH] x86/HVM: correct CPUID leaf 80000008 handling Jan Beulich
2014-03-27 11:44 ` Tim Deegan
2014-03-27 15:10 ` Jan Beulich
2014-03-27 15:22 ` Andrew Cooper [this message]
2014-03-27 15:37 ` Tim Deegan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53344233.4030906@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.