On Fri, May 05, 2023, Micka�l Sala�n wrote: > > On 05/05/2023 18:28, Sean Christopherson wrote: > > I have no doubt that we'll need to solve performance and scaling issues > > with the > > memory attributes implementation, e.g. to utilize xarray multi-range support > > instead of storing information on a per-4KiB-page basis, but AFAICT, the > > core > > idea is sound. And a very big positive from a maintenance perspective is > > that > > any optimizations, fixes, etc. for one use case (CoCo vs. hardening) should > > also > > benefit the other use case. > > > > [1] https://lore.kernel.org/all/20230311002258.852397-22-sea...@google.com > > [2] https://lore.kernel.org/all/y2wb48kd0j4vg...@google.com > > [3] https://lore.kernel.org/all/y1a1i9vbj%2fpvm...@google.com > > I agree, I used this mechanism because it was easier at first to rely on a > previous work, but while I was working on the MBEC support, I realized that > it's not the optimal way to do it. > > I was thinking about using a new special EPT bit similar to > EPT_SPTE_HOST_WRITABLE, but it may not be portable though. What do you > think?
On x86, SPTEs are even more ephemeral than memslots. E.g. for historical reasons, KVM zaps all SPTEs if _any_ memslot is deleted, which is problematic if the guest is moving around BARs, using option ROMs, etc. ARM's pKVM tracks metadata in its stage-2 PTEs, i.e. doesn't need an xarray to otrack attributes, but that works only because pKVM is more privileged than the host kernel, and the shared vs. private memory attribute that pKVM cares about is very, very restricted in how it can be used and changed. I tried shoehorning private vs. shared metadata into x86's SPTEs in the past, and it ended up being a constant battle with the kernel, e.g. page migration, and with KVM itself, e.g. the above memslot mess.
