Re: [PATCH v3 00/25] Permission Overlay Extension

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

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux