lkml.org 
[lkml]   [2024]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v19 059/130] KVM: x86/tdp_mmu: Don't zap private pages for unsupported cases
    Date
    On Thu, 2024-03-28 at 09:30 +0800, Xiaoyao Li wrote:
    > > The current ABI of KVM_EXIT_X86_RDMSR when TDs are created is nothing. So I don't see how this
    > > is
    > > any kind of ABI break. If you agree we shouldn't try to support MTRRs, do you have a different
    > > exit
    > > reason or behavior in mind?
    >
    > Just return error on TDVMCALL of RDMSR/WRMSR on TD's access of MTRR MSRs.

    MTRR appears to be configured to be type "Fixed" in the TDX module. So the guest could expect to be
    able to use it and be surprised by a #GP.

    {
    "MSB": "12",
    "LSB": "12",
    "Field Size": "1",
    "Field Name": "MTRR",
    "Configuration Details": null,
    "Bit or Field Virtualization Type": "Fixed",
    "Virtualization Details": "0x1"
    },

    If KVM does not support MTRRs in TDX, then it has to return the error somewhere or pretend to
    support it (do nothing but not return an error). Returning an error to the guest would be making up
    arch behavior, and to a lesser degree so would ignoring the WRMSR. So that is why I lean towards
    returning to userspace and giving the VMM the option to ignore it, return an error to the guest or
    show an error to the user. If KVM can't support the behavior, better to get an actual error in
    userspace than a mysterious guest hang, right?

    Outside of what kind of exit it is, do you object to the general plan to punt to userspace?

    Since this is a TDX specific limitation, I guess there is KVM_EXIT_TDX_VMCALL as a general category
    of TDVMCALLs that cannot be handled by KVM.
    \
     
     \ /
      Last update: 2024-05-27 16:13    [W:4.265 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site