On 26/01/21 20:56, Sean Christopherson wrote:
It does belong in the mmu_role_bits though;-)
Does it? We don't support PKU/PKS for shadow paging, and it's always zero
for EPT. We only support enough PKU/PKS for emulation.
As proposed, yes. The PKU/PKS mask is tracked on a per-mmu basis, e.g.
computed in update_pkr_bitmask() and consumed in permission_fault()
during emulation. Omitting CR4.PKS from the extended role could let KVM
reuse an MMU with the wrong pkr_mask.
Right, not for the hash table key but for reuse.
IIUC, the logic is PKU|PKS, with pkr_mask generation being PKU vs. PKS agnostic.
Not in the patches as submitted, but it's what I suggested indeed (using
one bit of the PFEC to pick one of CR4.PKE and CR4.PKS).
Another option would be to move the tracking out of the MMU, e.g. make pkr_mask
per-vCPU and recalculate when CR4 changes. I think that would "just work", even
when nested VMs are in play?
Yeah, pkr_mask is basically one of four constants (depending on CR4.PKE
and CR4.PKS) so recalculating when CR4 changes would work too. But I'm
okay with doing that later, too.
Paolo
