Re: [Xen-devel] [PATCH] x86/svm: Fixes to nested-svm MSR handing

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.12.18 at 12:52, <andrew.cooper3@xxxxxxxxxx> wrote:
> The intention of this patch was to remove the calls to nsvm_{rd,wr}msr() from
> the default cases of svm_msr_{read,write}_intercept(), but it has turned into
> a more corrective patch than just code motion.
> 
> First, collect the VM_CR bit definitions next to the main define, and simplify
> the naming.  The SVM MSRs should be entirely unavailable when SVM isn't
> enumerated in CPUID.
> 
> When SVM is available, Xen only supports the "Enabled" mode as described in
> the BKGD/PPRs, which means VM_CR.LOCK should be set.  This in turn means the
> MSR_SVM_LOCK_KEY should be implemented.  It is read-as-0/write-discard as Xen
> doesn't implement the "disabled with user supplied key" mode.
> 
> The correct reset value for the HSAVE address is 0, not ~0.  Xen doesn't use
> the guest frame for anything, and doesn't implement TSEG/ASEG/HyperTransport
> in the guest physical address space.  Drop the arbitrary upper bounds check
> which appears to be an incorrect attempt to exclude the HT range below the 4G
> boundary, and accept any frame within MAXPHYSADDR.  When we get a usable
> physmap layout in Xen, this should be restricted to RAM pages.
> 
> Remove the now-unused ret variables from the intercept functions, as well as
> the unnecessary result variable in svm_msr_write_intercept().
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel