On 12/12/22 18:39, Sean Christopherson wrote:
The notion of address spaces is already existing architecture-neutral
concept in KVM (e.g. see uses of KVM_ADDRESS_SPACE_NUM in
virt/kvm/kvm_main.c), although SMM is the only use-case I'm aware of.
Yes, SMM is currently the only use-case.
It's possible that in the future Hyper-V VTLs will also have per-level
protections. It wouldn't use as_id, but it would likely be recorded in
the upper byte of the role.
I'm not sure if Microsoft intends to port those to ARM as well.
My preference would be to leave .smm in x86's page role
What about defining a byte of arch_role and a macro to build it?
Unless I'm missing something, e.g. a need to map GPAs differently for
SMM vs. non-SMM, SMM could have been implemented with a simple flag
in a memslot to mark the memslot as SMM-only.
Unfortunately not, because there can be another region (for example
video RAM at 0A0000h) underneath SMRAM.
In fact, KVM_MEM_X86_SMRAM was the first idea. It was uglier than
multiple address spaces
(https://lore.kernel.org/lkml/1431084034-8425-1-git-send-email-pbonzini@xxxxxxxxxx).
In retrospect there were probably ways to mix the best of the two
designs, but it wasn't generic enough.
And separate address spaces become truly nasty if the CPU can access multiple
protected regions, e.g. if the CPU can access type X and type Y at the same time,
then there would need to be memslots for "regular", X, Y, and X+Y.
Without a usecase that's hard to say. It's just as possible that there
would be a natural hierarchy of levels.
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
