Re: [RFC PATCH 01/37] KVM: x86/mmu: Store the address space ID directly in kvm_mmu_page_role

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux