qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: David Edmondson <david.edmondson@oracle.com>, qemu-devel@nongnu.org
Cc: Babu Moger <babu.moger@amd.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <ehabkost@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [RFC PATCH 0/7] Support protection keys in an AMD EPYC-Milan VM
Date: Fri, 11 Jun 2021 18:01:55 +0200	[thread overview]
Message-ID: <330417d8-9e23-4c90-b825-24329d3e4c66@redhat.com> (raw)
In-Reply-To: <20210520145647.3483809-1-david.edmondson@oracle.com>

First of all, sorry for the delayed review.

On 20/05/21 16:56, David Edmondson wrote:
> AMD EPYC-Milan CPUs introduced support for protection keys, previously
> available only with Intel CPUs.
> 
> AMD chose to place the XSAVE state component for the protection keys
> at a different offset in the XSAVE state area than that chosen by
> Intel.
> 
> To accommodate this, modify QEMU to behave appropriately on AMD
> systems, allowing a VM to properly take advantage of the new feature.

Uff, that sucks. :(

If I understand correctly, the problem is that the layout of 
KVM_GET_XSAVE/KVM_SET_XSAVE depends on the host CPUID, which in 
retrospect would be obvious.  Is that correct?  If so, it would make 
sense and might even be easier to drop all usage of X86XSaveArea:

* update ext_save_areas based on CPUID information in kvm_cpu_instance_init

* make x86_cpu_xsave_all_areas and x86_cpu_xrstor_all_areas use the 
ext_save_areas offsets to build pointers to XSaveAVX, XSaveBNDREG, etc.

What do you think?

Paolo

> Further, avoid manipulating XSAVE state components that are not
> present on AMD systems.
> 
> The code in patch 6 that changes the CPUID 0x0d leaf is mostly dumped
> somewhere that seemed to work - I'm not sure where it really belongs.
> 
> David Edmondson (7):
>    target/i386: Declare constants for XSAVE offsets
>    target/i386: Use constants for XSAVE offsets
>    target/i386: Clarify the padding requirements of X86XSaveArea
>    target/i386: Prepare for per-vendor X86XSaveArea layout
>    target/i386: Introduce AMD X86XSaveArea sub-union
>    target/i386: Adjust AMD XSAVE PKRU area offset in CPUID leaf 0xd
>    target/i386: Manipulate only AMD XSAVE state on AMD
> 
>   target/i386/cpu.c            | 19 +++++----
>   target/i386/cpu.h            | 80 ++++++++++++++++++++++++++++--------
>   target/i386/kvm/kvm.c        | 57 +++++++++----------------
>   target/i386/tcg/fpu_helper.c | 20 ++++++---
>   target/i386/xsave_helper.c   | 70 +++++++++++++++++++------------
>   5 files changed, 152 insertions(+), 94 deletions(-)
> 



  parent reply	other threads:[~2021-06-11 16:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 14:56 [RFC PATCH 0/7] Support protection keys in an AMD EPYC-Milan VM David Edmondson
2021-05-20 14:56 ` [RFC PATCH 1/7] target/i386: Declare constants for XSAVE offsets David Edmondson
2021-05-20 14:56 ` [RFC PATCH 2/7] target/i386: Use " David Edmondson
2021-05-20 14:56 ` [RFC PATCH 3/7] target/i386: Clarify the padding requirements of X86XSaveArea David Edmondson
2021-05-20 14:56 ` [RFC PATCH 4/7] target/i386: Prepare for per-vendor X86XSaveArea layout David Edmondson
2021-05-20 14:56 ` [RFC PATCH 5/7] target/i386: Introduce AMD X86XSaveArea sub-union David Edmondson
2021-05-20 14:56 ` [RFC PATCH 6/7] target/i386: Adjust AMD XSAVE PKRU area offset in CPUID leaf 0xd David Edmondson
2021-05-20 14:56 ` [RFC PATCH 7/7] target/i386: Manipulate only AMD XSAVE state on AMD David Edmondson
2021-05-20 15:15 ` [RFC PATCH 0/7] Support protection keys in an AMD EPYC-Milan VM no-reply
2021-06-08  8:24 ` David Edmondson
2021-07-01 21:24   ` Babu Moger
2021-07-01 21:32     ` David Edmondson
2021-06-11 16:01 ` Paolo Bonzini [this message]
2021-06-14 16:21   ` David Edmondson

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=330417d8-9e23-4c90-b825-24329d3e4c66@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=babu.moger@amd.com \
    --cc=david.edmondson@oracle.com \
    --cc=ehabkost@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).