[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YwehLNws0WBNRDgN@google.com>
Date: Thu, 25 Aug 2022 16:19:56 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: "Chang S. Bae" <chang.seok.bae@...el.com>
Cc: kvm@...r.kernel.org, pbonzini@...hat.com,
linux-kernel@...r.kernel.org, yang.zhong@...el.com
Subject: Re: [RFC PATCH 1/2] KVM: x86: Add a new system attribute for dynamic
XSTATE component
On Wed, Aug 24, 2022, Chang S. Bae wrote:
> On 8/24/2022 2:42 PM, Sean Christopherson wrote:
> Maybe this is a policy decision. I don't think that
> ARCH_REQ_XCOMP_GUEST_PERM goes away with this. Userspace may still use the
> arch_prctl() set. But then it makes more sense and consistent to use
> ARCH_GET_XCOMP_SUPP in first place, instead of KVM_X86_XCOMP_GUEST_SUPP, no?
KVM_X86_XCOMP_GUEST_SUPP is needed so that userspace understands what _KVM_
supports.
> > If QEMU wants to assert that it didn't misconfigure itself, it can assert on the
> > config in any number of ways, e.g. assert that ARCH_GET_XCOMP_GUEST_PERM is a
> > subset of KVM_X86_XCOMP_GUEST_SUPP at the end of kvm_request_xsave_components().
>
> Yes, but I guess the new attribute can make it simple.
Adding new uAPI and new exports to eliminate one line of userspace code is not a
good tradeoff. Am I missing something? This really seems like solution looking
for a problem.
Powered by blists - more mailing lists