All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sheng Yang <sheng@linux.intel.com>
To: Avi Kivity <avi@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [PATCH] qemu: Enable XSAVE related CPUID
Date: Thu, 27 May 2010 21:55:18 +0800	[thread overview]
Message-ID: <201005272155.18940.sheng@linux.intel.com> (raw)
In-Reply-To: <4BFE6BF1.90501@redhat.com>

On Thursday 27 May 2010 20:56:17 Avi Kivity wrote:
> On 05/27/2010 12:50 PM, Sheng Yang wrote:
> > We can support it in KVM now. The initial values are the minimal
> > requirement of XSAVE capable processor.
> > 
> > Signed-off-by: Sheng Yang<sheng@linux.intel.com>
> > ---
> > 
> >   target-i386/cpuid.c |   32 ++++++++++++++++++++++++++++++++
> >   1 files changed, 32 insertions(+), 0 deletions(-)
> > 
> > diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
> > index eebf038..cbf5595 100644
> > --- a/target-i386/cpuid.c
> > +++ b/target-i386/cpuid.c
> > @@ -1067,6 +1067,38 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t
> > index, uint32_t count,
> > 
> >           *ecx = 0;
> >           *edx = 0;
> >           break;
> > 
> > +    case 0xD:
> > +        /* Processor Extended State */
> > +        if (!(env->cpuid_ext_features&  CPUID_EXT_XSAVE)) {
> > +            *eax = 0;
> > +            *ebx = 0;
> > +            *ecx = 0;
> > +            *edx = 0;
> > +            break;
> > +        }
> > +        if (count == 0) {
> > +            *eax = 0x7; /* FP | SSE | YMM */
> > +            *ebx = 0x340; /* FP + SSE + YMM size */
> > +            *ecx = 0x340; /* FP + SSE + YMM size */
> 
> For -cpu host, we should pick these from KVM_GET_SUPPORTED_CPUID.  For
> canned cpu types (e.g. qemu64), we need to return what we always did.

Yes, I also prefer this way. didn't do this because it's somehow out of current 
QEmu CPUID setting mechanism.
> 
> We can also add a new cpu type that has them built in (there's no cpu on
> the market with avx, right?)

Right... Let's use -cpu host now.

> 
> > +            *edx = 0;
> > +        } else if (count == 1) {
> > +            /* eax = 1, so we can continue with others */
> > +            *eax = 1;
> > +            *ebx = 0;
> > +            *ecx = 0;
> > +            *edx = 0;
> > +        } else if (count == 2) {
> > +            *eax = 0x100; /* YMM size */
> > +            *ebx = 0x240; /* YMM offset */
> > +            *ecx = 0;
> > +            *edx = 0;
> 
> These, too.

Sure.

--
regards
Yang, Sheng

> 
> > +        } else {
> > +            *eax = 0;
> > +            *ebx = 0;
> > +            *ecx = 0;
> > +            *edx = 0;
> > +        }
> > +        break;
> > 
> >       case 0x80000000:
> >           *eax = env->cpuid_xlevel;
> >           *ebx = env->cpuid_vendor1;

WARNING: multiple messages have this Message-ID (diff)
From: Sheng Yang <sheng@linux.intel.com>
To: Avi Kivity <avi@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH] qemu: Enable XSAVE related CPUID
Date: Thu, 27 May 2010 21:55:18 +0800	[thread overview]
Message-ID: <201005272155.18940.sheng@linux.intel.com> (raw)
In-Reply-To: <4BFE6BF1.90501@redhat.com>

On Thursday 27 May 2010 20:56:17 Avi Kivity wrote:
> On 05/27/2010 12:50 PM, Sheng Yang wrote:
> > We can support it in KVM now. The initial values are the minimal
> > requirement of XSAVE capable processor.
> > 
> > Signed-off-by: Sheng Yang<sheng@linux.intel.com>
> > ---
> > 
> >   target-i386/cpuid.c |   32 ++++++++++++++++++++++++++++++++
> >   1 files changed, 32 insertions(+), 0 deletions(-)
> > 
> > diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
> > index eebf038..cbf5595 100644
> > --- a/target-i386/cpuid.c
> > +++ b/target-i386/cpuid.c
> > @@ -1067,6 +1067,38 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t
> > index, uint32_t count,
> > 
> >           *ecx = 0;
> >           *edx = 0;
> >           break;
> > 
> > +    case 0xD:
> > +        /* Processor Extended State */
> > +        if (!(env->cpuid_ext_features&  CPUID_EXT_XSAVE)) {
> > +            *eax = 0;
> > +            *ebx = 0;
> > +            *ecx = 0;
> > +            *edx = 0;
> > +            break;
> > +        }
> > +        if (count == 0) {
> > +            *eax = 0x7; /* FP | SSE | YMM */
> > +            *ebx = 0x340; /* FP + SSE + YMM size */
> > +            *ecx = 0x340; /* FP + SSE + YMM size */
> 
> For -cpu host, we should pick these from KVM_GET_SUPPORTED_CPUID.  For
> canned cpu types (e.g. qemu64), we need to return what we always did.

Yes, I also prefer this way. didn't do this because it's somehow out of current 
QEmu CPUID setting mechanism.
> 
> We can also add a new cpu type that has them built in (there's no cpu on
> the market with avx, right?)

Right... Let's use -cpu host now.

> 
> > +            *edx = 0;
> > +        } else if (count == 1) {
> > +            /* eax = 1, so we can continue with others */
> > +            *eax = 1;
> > +            *ebx = 0;
> > +            *ecx = 0;
> > +            *edx = 0;
> > +        } else if (count == 2) {
> > +            *eax = 0x100; /* YMM size */
> > +            *ebx = 0x240; /* YMM offset */
> > +            *ecx = 0;
> > +            *edx = 0;
> 
> These, too.

Sure.

--
regards
Yang, Sheng

> 
> > +        } else {
> > +            *eax = 0;
> > +            *ebx = 0;
> > +            *ecx = 0;
> > +            *edx = 0;
> > +        }
> > +        break;
> > 
> >       case 0x80000000:
> >           *eax = env->cpuid_xlevel;
> >           *ebx = env->cpuid_vendor1;

  reply	other threads:[~2010-05-27 13:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-27  9:50 [PATCH] qemu: Enable XSAVE related CPUID Sheng Yang
2010-05-27  9:50 ` [Qemu-devel] " Sheng Yang
2010-05-27 12:56 ` Avi Kivity
2010-05-27 12:56   ` [Qemu-devel] " Avi Kivity
2010-05-27 13:55   ` Sheng Yang [this message]
2010-05-27 13:55     ` Sheng Yang

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=201005272155.18940.sheng@linux.intel.com \
    --to=sheng@linux.intel.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.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.