Messages in this thread | | | Subject | Re: [RFC 6/7] KVM: X86: Expose PKS to guest and userspace | From | Paolo Bonzini <> | Date | Tue, 26 Jan 2021 21:05:55 +0100 |
| |
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
| |