Hi Marc, On Mon, Dec 04, 2023 at 11:03:24AM +0000, Marc Zyngier wrote: > Hi Joey, > > On Fri, 24 Nov 2023 16:34:45 +0000, > Joey Gouly <joey.gouly@xxxxxxx> wrote: > > > > Hello everyone, > > > > This series implements the Permission Overlay Extension introduced in 2022 > > VMSA enhancements [1]. It is based on v6.7-rc2. > > > > Changes since v2[2]: > > # Added ptrace support and selftest > > # Add missing POR_EL0 initialisation in fork/clone > > # Rebase onto v6.7-rc2 > > # Add r-bs > > > > The Permission Overlay Extension allows to constrain permissions on memory > > regions. This can be used from userspace (EL0) without a system call or TLB > > invalidation. > > I have given this series a few more thoughts, and came to the > conclusion that is it still incomplete on the KVM front: > > * FEAT_S1POE often comes together with FEAT_S2POE. For obvious > reasons, we cannot afford to let the guest play with S2POR_EL1, nor > do we want to advertise FEAT_S2POE to the guest. > > You will need to add some additional FGT for this, and mask out > FEAT_S2POE from the guest's view of the ID registers. I found out last week that I had misunderstood S2POR_EL1, so yes looks like we need to trap that. I will add that in. > > * letting the guest play with POE comes with some interesting strings > attached: a guest that has started on a POE-enabled host cannot be > migrated to one that doesn't have POE. which means that the POE > registers should only be visible to the host userspace if enabled in > the guest's ID registers, and thus only context-switched in these > conditions. They should otherwise UNDEF. Can you give me some clarification here? - By visible to the host userspace do you mean via the GET_ONE_REG API? - Currently the ID register (ID_AA64MMFR3_EL1) is not ID_WRITABLE, should this series or another make it so? Currently if the host had POE it's enabled in the guest, so I believe migration to a non-POE host will fail? - For the context switch, do you mean something like: if (system_supports_poe() && ID_REG(MMFR3_EL1) & S1POE) ctxt_sys_reg(ctxt, POR_EL0) = read_sysreg_s(SYS_POR_EL0); That would need some refactoring, since I don't see how to access id_regs from struct kvm_cpu_context. Thanks, Joey
