Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 19 Dec 2019 12:32:14 -0800
From:   Sean Christopherson <sean.j.christopherson@intel.com>
To:     John Allen <john.allen@amd.com>
Cc:     kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        pbonzini@redhat.com, rkrcmar@redhat.com, vkuznets@redhat.com
Subject: Re: [PATCH v2] kvm/svm: PKU not currently supported
Message-ID: <20191219203214.GC6439@linux.intel.com>
References: <20191219201759.21860-1-john.allen@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191219201759.21860-1-john.allen@amd.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Dec 19, 2019 at 02:17:59PM -0600, John Allen wrote:
> Current SVM implementation does not have support for handling PKU. Guests
> running on a host with future AMD cpus that support the feature will read
> garbage from the PKRU register and will hit segmentation faults on boot as
> memory is getting marked as protected that should not be. Ensure that cpuid
> from SVM does not advertise the feature.
> 
> Signed-off-by: John Allen <john.allen@amd.com>
> ---
> v2:
>   -Introduce kvm_x86_ops->pku_supported()

I like the v1 approach better, it's less code to unwind when SVM gains
support for virtualizaing PKU.

The existing cases of kvm_x86_ops->*_supported() in __do_cpuid_func() are
necessary to handle cases where it may not be possible to expose a feature
even though it's supported in hardware, host and KVM, e.g. VMX's separate
MSR-based features and PT's software control to hide it from guest.  In
this case, hiding PKU is purely due to lack of support in KVM.  The SVM
series to enable PKU can then delete a single line of SVM code instead of
having to go back in and do surgery on x86 and VMX.