lkml.org 
[lkml]   [2023]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] KVM: x86: Track supported ARCH_CAPABILITIES in kvm_caps
    From
    On Fri, May 19, 2023, Chao Gao wrote:
    > +Pawan, could you share your thoughts on questions about FB_CLEAR?
    >
    > On Thu, May 18, 2023 at 10:33:15AM -0700, Sean Christopherson wrote:
    > >I do like snapshotting and then updating the value, even though there's likely no
    > >meaningful performance benefit, as that would provide a place to document that
    > >the "supported" value is dynamic. Though the fact that it's dynamic is arguably a bug
    > >in its own right, e.g. if userspace isn't careful, a VM can have vCPUs with different
    > >values for ARCH_CAPABILITIES. But fixing that is probably a fool's errand. So
    >
    > I am not sure if fixing it is fool. There would be some other problem:

    Heh, "fool's errand" is an idiom that means doing something has almost no chance
    of succeeding, not that doing something is foolish. I 100% agree that there's
    value in presenting a consistent model to the guest, but there are conflicting
    requirements in play. To present a consistent model, KVM essentially needs to
    disallow changing the module param after VMs/vCPUs have been created, but that
    would prevent userspace from toggling the param while VMs are running, e.g. in
    response to a new vulnerability.

    The only feasible idea I can think of is to disallow *disabling* the mitigation
    while VMs/vCPUs are active. But then that prevents turning the L1D flush mitigation
    back off if some other mitigation is deployed, e.g. via livepatch, policy update,
    etc.

    That's why I said trying to fix the knob is probably a fool's errand. AFAICT,
    there's no straightforward solution that makes everybody happy. :-/

    \
     
     \ /
      Last update: 2023-05-19 17:26    [W:2.747 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site