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@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm