From: Avi Kivity <avi@redhat.com>
To: BrillyWu@viatech.com.cn
Cc: mtosatti@redhat.com, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: Add CPUID support for VIA CPU
Date: Wed, 13 Apr 2011 14:32:47 +0300 [thread overview]
Message-ID: <4DA589DF.8060002@redhat.com> (raw)
In-Reply-To: <C4F7CD9A92DBFF48AD8779355CD4D7890D79D2@exchsg04.s3graphics.com>
On 04/13/2011 02:05 PM, BrillyWu@viatech.com.cn wrote:
> >>
> >> + /* cpuid 0xC0000001.edx */
> >> + const u32 kvm_supported_word5_x86_features =
> >> + F(XSTORE) | F(XSTORE_EN) | F(XCRYPT) | F(XCRYPT_EN) |
> >> + F(ACE2) | F(ACE2_EN) | F(PHE) | F(PHE_EN) |
> >> + F(PMM) | F(PMM_EN);
> >> +
>
> > Are all of these features save wrt save/restore? (do they all act on
> > state in standard registers?) Do they need any control register bits
> > to be active or MSRs to configure?
>
> These features depend on instructions for the PadLock hardware engine of VIA CPU.
> The PadLock instructions just act on standard registers like general X86 instructions, and the features have been enabled when the CPU leave the factory, so there is no need to activate any control register bits or configure MSRs.
I see there is a dependency on EFLAGS[30]. Does a VM entry clear this
bit? If not, we have to do it ourselves.
> >> @@ -2484,6 +2504,17 @@ static int kvm_dev_ioctl_get_supported_c
> >>
> >> r = -E2BIG;
> >> if (nent>= cpuid->nent)
> >> + goto out_free;
> >> +
> >> + /* Add support for Centaur's CPUID instruction. */
> >> + do_cpuid_ent(&cpuid_entries[nent], 0xC0000000, 0,&nent,
> >> cpuid->nent);
>
> > nent overflow check missing here. Also, should probably skip if not a Via.
>
> If not a VIA, the "limit" will be "0", so the following cycle can not run.
I think Intel defines CPUID to return the highest standard leaf, so it
will be equivalent to cpuid(0x1a) or something like that.
> Moreover, it seems that there is no method to know whther the CPU is a VIA or not in this function.
Can't you check the vendor ID? see boot_cpu_data.
> The nent overflow check is put after the cycle like the "0x8000000" case, and when on a VIA, the returned "limit" is not large (generally it is 0xC0000004), is it neccesary to add a more check here?
Yes, otherwise userspace can supply a buffer that is exactly the wrong
size and cause an overflow.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2011-04-13 11:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-13 3:26 [PATCH] KVM: Add CPUID support for VIA CPU BrillyWu
2011-04-13 8:59 ` Avi Kivity
2011-04-13 11:05 ` BrillyWu
2011-04-13 11:32 ` Avi Kivity [this message]
2011-04-14 3:14 ` BrillyWu
2011-04-14 7:48 ` Avi Kivity
2011-04-14 9:54 ` BrillyWu
2011-04-14 10:07 ` Avi Kivity
2011-04-21 10:06 ` BrillyWu
2011-04-24 7:18 ` Avi Kivity
2011-04-25 5:55 ` BrillyWu
2011-04-27 8:48 ` Avi Kivity
2011-04-28 1:27 ` [PATCH] qemu-kvm: " BrillyWu
2011-04-14 3:59 ` [PATCH v2] KVM: " BrillyWu
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=4DA589DF.8060002@redhat.com \
--to=avi@redhat.com \
--cc=BrillyWu@viatech.com.cn \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox