On Tue, Oct 5, 2021 at 10:59 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Tue, Oct 05, 2021, Jim Mattson wrote: > > On Tue, Oct 5, 2021 at 9:16 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > > > On Tue, Sep 28, 2021, Robert Hoo wrote: > > > > On Fri, 2021-09-03 at 15:11 +0000, Sean Christopherson wrote: > > > > You also said, "This is quite the complicated mess for > > > > something I'm guessing no one actually cares about. At what point do > > > > we chalk this up as a virtualization hole and sweep it under the rug?" > > > > -- I couldn't agree more. > > > > > > ... > > > > > > > So, Sean, can you help converge our discussion and settle next step? > > > > > > Any objection to simply keeping KVM's current behavior, i.e. sweeping this under > > > the proverbial rug? > > > > Adding 8 KiB per vCPU seems like no big deal to me, but, on the other > > hand, Paolo recently argued that slightly less than 1 KiB per vCPU was > > unreasonable for VM-exit statistics, so maybe I've got a warped > > perspective. I'm all for pedantic adherence to the specification, but > > I have to admit that no actual hypervisor is likely to care (or ever > > will). > > It's not just the memory, it's also the complexity, e.g. to get VMCS shadowing > working correctly, both now and in the future. As far as CPU feature virtualization goes, this one doesn't seem that complex to me. It's not anywhere near as complex as virtualizing MTF, for instance, and KVM *claims* to do that! :-)
