Re: KVM/arm64: SPE: Translate VA to IPA on a stage 2 fault instead of pinning VM memory

[Marc Zyngier <maz@kernel.org>]

On 2022-07-27 11:19, Alexandru Elisei wrote:
> Hi Oliver,
> 
> Thank you for the help, replies below.
> 
> On Tue, Jul 26, 2022 at 10:51:21AM -0700, Oliver Upton wrote:
>> Hi Alex,
>> 
>> On Mon, Jul 25, 2022 at 11:06:24AM +0100, Alexandru Elisei wrote:
>> 
>> [...]
>> 
>> > > A funkier approach might be to defer pinning of the buffer until the SPE is
>> > > enabled and avoid pinning all of VM memory that way, although I can't
>> > > immediately tell how flexible the architecture is in allowing you to cache
>> > > the base/limit values.
>> >
>> > I was investigating this approach, and Mark raised a concern that I think
>> > might be a showstopper.
>> >
>> > Let's consider this scenario:
>> >
>> > Initial conditions: guest at EL1, profiling disabled (PMBLIMITR_EL1.E = 0,
>> > PMBSR_EL1.S = 0, PMSCR_EL1.{E0SPE,E1SPE} = {0,0}).
>> >
>> > 1. Guest programs the buffer and enables it (PMBLIMITR_EL1.E = 1).
>> > 2. Guest programs SPE to enable profiling at **EL0**
>> > (PMSCR_EL1.{E0SPE,E1SPE} = {1,0}).
>> > 3. Guest changes the translation table entries for the buffer. The
>> > architecture allows this.
>> > 4. Guest does an ERET to EL0, thus enabling profiling.
>> >
>> > Since KVM cannot trap the ERET to EL0, it will be impossible for KVM to pin
>> > the buffer at stage 2 when profiling gets enabled at EL0.
>> 
>> Not saying we necessarily should, but this is possible with FGT no?
> 
> It doesn't look to me like FEAT_FGT offers any knobs to trap ERET from 
> EL1.

See HFGITR.ERET.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm