All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: David Edmondson <david.edmondson@oracle.com>, qemu-devel@nongnu.org
Cc: Richard Henderson <richard.henderson@linaro.org>,
	Michael Roth <michael.roth@amd.com>,
	kvm@vger.kernel.org, Roman Bolshakov <r.bolshakov@yadro.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	babu.moger@amd.com, Cameron Esfahani <dirty@apple.com>,
	Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [RFC PATCH 0/8] Derive XSAVE state component offsets from CPUID leaf 0xd where possible
Date: Mon, 5 Jul 2021 18:57:42 +0200	[thread overview]
Message-ID: <811b9dd2-1e9f-d0fc-d3cb-c95671ac09ea@redhat.com> (raw)
In-Reply-To: <20210705104632.2902400-1-david.edmondson@oracle.com>

On 05/07/21 12:46, David Edmondson wrote:
> The offset of XSAVE state components within the XSAVE state area is
> currently hard-coded via reference to the X86XSaveArea structure. This
> structure is accurate for Intel systems at the time of writing, but
> incorrect for newer AMD systems, as the state component for protection
> keys is located differently (offset 0x980 rather than offset 0xa80).
> 
> For KVM and HVF, replace the hard-coding of the state component
> offsets with data derived from CPUID leaf 0xd information.
> 
> TCG still uses the X86XSaveArea structure, as there is no underlying
> CPU to use in determining appropriate values.
> 
> This is a replacement for the changes in
> https://lore.kernel.org/r/20210520145647.3483809-1-david.edmondson@oracle.com,
> which simply modifed the hard-coded offsets for AMD systems.
> 
> Testing on HVF is minimal (it builds and, by observation, the XSAVE
> state component offsets reported to a running VM are accurate on an
> older Intel system).

This looks great, thanks, so I am queuing it.

Paolo

> David Edmondson (8):
>    target/i386: Declare constants for XSAVE offsets
>    target/i386: Consolidate the X86XSaveArea offset checks
>    target/i386: Clarify the padding requirements of X86XSaveArea
>    target/i386: Pass buffer and length to XSAVE helper
>    target/i386: Make x86_ext_save_areas visible outside cpu.c
>    target/i386: Observe XSAVE state area offsets
>    target/i386: Populate x86_ext_save_areas offsets using cpuid where
>      possible
>    target/i386: Move X86XSaveArea into TCG
> 
>   target/i386/cpu.c            |  18 +--
>   target/i386/cpu.h            |  41 ++----
>   target/i386/hvf/hvf-cpu.c    |  34 +++++
>   target/i386/hvf/hvf.c        |   3 +-
>   target/i386/hvf/x86hvf.c     |  19 ++-
>   target/i386/kvm/kvm-cpu.c    |  36 +++++
>   target/i386/kvm/kvm.c        |  52 +------
>   target/i386/tcg/fpu_helper.c |   1 +
>   target/i386/tcg/tcg-cpu.c    |  20 +++
>   target/i386/tcg/tcg-cpu.h    |  57 ++++++++
>   target/i386/xsave_helper.c   | 267 ++++++++++++++++++++++++++---------
>   11 files changed, 381 insertions(+), 167 deletions(-)
> 


WARNING: multiple messages have this Message-ID
From: Paolo Bonzini <pbonzini@redhat.com>
To: David Edmondson <david.edmondson@oracle.com>, qemu-devel@nongnu.org
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	kvm@vger.kernel.org, Michael Roth <michael.roth@amd.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Cameron Esfahani <dirty@apple.com>,
	babu.moger@amd.com, Roman Bolshakov <r.bolshakov@yadro.com>
Subject: Re: [RFC PATCH 0/8] Derive XSAVE state component offsets from CPUID leaf 0xd where possible
Date: Mon, 5 Jul 2021 18:57:42 +0200	[thread overview]
Message-ID: <811b9dd2-1e9f-d0fc-d3cb-c95671ac09ea@redhat.com> (raw)
In-Reply-To: <20210705104632.2902400-1-david.edmondson@oracle.com>

On 05/07/21 12:46, David Edmondson wrote:
> The offset of XSAVE state components within the XSAVE state area is
> currently hard-coded via reference to the X86XSaveArea structure. This
> structure is accurate for Intel systems at the time of writing, but
> incorrect for newer AMD systems, as the state component for protection
> keys is located differently (offset 0x980 rather than offset 0xa80).
> 
> For KVM and HVF, replace the hard-coding of the state component
> offsets with data derived from CPUID leaf 0xd information.
> 
> TCG still uses the X86XSaveArea structure, as there is no underlying
> CPU to use in determining appropriate values.
> 
> This is a replacement for the changes in
> https://lore.kernel.org/r/20210520145647.3483809-1-david.edmondson@oracle.com,
> which simply modifed the hard-coded offsets for AMD systems.
> 
> Testing on HVF is minimal (it builds and, by observation, the XSAVE
> state component offsets reported to a running VM are accurate on an
> older Intel system).

This looks great, thanks, so I am queuing it.

Paolo

> David Edmondson (8):
>    target/i386: Declare constants for XSAVE offsets
>    target/i386: Consolidate the X86XSaveArea offset checks
>    target/i386: Clarify the padding requirements of X86XSaveArea
>    target/i386: Pass buffer and length to XSAVE helper
>    target/i386: Make x86_ext_save_areas visible outside cpu.c
>    target/i386: Observe XSAVE state area offsets
>    target/i386: Populate x86_ext_save_areas offsets using cpuid where
>      possible
>    target/i386: Move X86XSaveArea into TCG
> 
>   target/i386/cpu.c            |  18 +--
>   target/i386/cpu.h            |  41 ++----
>   target/i386/hvf/hvf-cpu.c    |  34 +++++
>   target/i386/hvf/hvf.c        |   3 +-
>   target/i386/hvf/x86hvf.c     |  19 ++-
>   target/i386/kvm/kvm-cpu.c    |  36 +++++
>   target/i386/kvm/kvm.c        |  52 +------
>   target/i386/tcg/fpu_helper.c |   1 +
>   target/i386/tcg/tcg-cpu.c    |  20 +++
>   target/i386/tcg/tcg-cpu.h    |  57 ++++++++
>   target/i386/xsave_helper.c   | 267 ++++++++++++++++++++++++++---------
>   11 files changed, 381 insertions(+), 167 deletions(-)
> 



  parent reply	other threads:[~2021-07-05 16:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05 10:46 [RFC PATCH 0/8] Derive XSAVE state component offsets from CPUID leaf 0xd where possible David Edmondson
2021-07-05 10:46 ` David Edmondson
2021-07-05 10:46 ` [RFC PATCH 1/8] target/i386: Declare constants for XSAVE offsets David Edmondson
2021-07-05 10:46   ` David Edmondson
2021-07-05 10:46 ` [RFC PATCH 2/8] target/i386: Consolidate the X86XSaveArea offset checks David Edmondson
2021-07-05 10:46   ` David Edmondson
2021-07-05 10:46 ` [RFC PATCH 3/8] target/i386: Clarify the padding requirements of X86XSaveArea David Edmondson
2021-07-05 10:46   ` David Edmondson
2021-07-05 10:46 ` [RFC PATCH 4/8] target/i386: Pass buffer and length to XSAVE helper David Edmondson
2021-07-05 10:46   ` David Edmondson
2021-07-05 10:46 ` [RFC PATCH 5/8] target/i386: Make x86_ext_save_areas visible outside cpu.c David Edmondson
2021-07-05 10:46   ` David Edmondson
2021-07-05 10:46 ` [RFC PATCH 6/8] target/i386: Observe XSAVE state area offsets David Edmondson
2021-07-05 10:46   ` David Edmondson
2021-07-05 10:46 ` [RFC PATCH 7/8] target/i386: Populate x86_ext_save_areas offsets using cpuid where possible David Edmondson
2021-07-05 10:46   ` David Edmondson
2021-07-05 10:46 ` [RFC PATCH 8/8] target/i386: Move X86XSaveArea into TCG David Edmondson
2021-07-05 10:46   ` David Edmondson
2021-07-07  1:09   ` Richard Henderson
2021-07-07  1:09     ` Richard Henderson
2021-07-07  6:51     ` Paolo Bonzini
2021-07-07 10:10     ` David Edmondson
2021-07-07 10:10       ` David Edmondson
2021-07-08  7:45       ` David Edmondson
2021-07-08 15:22         ` Richard Henderson
2021-07-08 16:13           ` David Edmondson
2021-07-05 16:57 ` Paolo Bonzini [this message]
2021-07-05 16:57   ` [RFC PATCH 0/8] Derive XSAVE state component offsets from CPUID leaf 0xd where possible Paolo Bonzini

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=811b9dd2-1e9f-d0fc-d3cb-c95671ac09ea@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=babu.moger@amd.com \
    --cc=david.edmondson@oracle.com \
    --cc=dirty@apple.com \
    --cc=ehabkost@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=r.bolshakov@yadro.com \
    --cc=richard.henderson@linaro.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.