Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Jan,

On 12/06/2017 09:15 AM, Jan Beulich wrote:
> > > > On 05.12.17 at 19:39, <julien.grall@xxxxxxxxxx> wrote:
> > The suggested policy is based on the KVM one:
> >         - If we trap a S/W instructions, we enable VM trapping (e.g
> > HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean.
> >         - We flush the caches on both caches being turned on and off.
> >         - Once the caches are enabled, we stop trapping VM instructions.
> >
> > Doing a full clean will require to go through the P2M and flush the
> > entries one by one. At the moment, all the memory is mapped. As you can
> > imagine flushing guest with hundreds of MB will take a very long time
> > (Linux timeout during CPU bring).
> >
> > Therefore, we need a way to limit the number of entries we need to
> > flush. The suggested solution here is to introduce Populate On Demand
> > (PoD) on Arm.
> >
> > The guest would boot with no RAM mapped in stage-2 page-table. At every
> > prefetch/data abort, the RAM would be mapped using preferably 2MB chunk
> > or 4KB. This means that when S/W would be used, the number of entries
> > mapped would be very limited. However, for safety, the flush should be
> > preemptible.
> For my own understanding: Here you suggest to use PoD in order
> to deal with S/W insn interception.
That's right. PoD would limit the number of entry to flush.

> > To limit the performance impact, we could introduce a guest option to
> > tell whether the guest will use S/W. If it does plan to use S/W, PoD
> > will be disabled.
> Therefore I'm wondering if here you mean "If it doesn't plan to ..."
Whoops. I meant "If it doesn't plan".

> Independent of this I'm pretty unclear about your conclusion that
> there will be only a very limited number of P2M entries at the time
> S/W insns would be used by the guest. Are you ignoring potentially
> malicious guests for the moment? Otoh you admit that things would
> need to be preemptible, so perhaps the argumentation is that you
> simply expect well behaved guests to only have such limited amount
> of P2M entries.
The preemption is to cover malicious guests and potentially well-behaved 
guests use case I missed. But TBH, the latter would be a call for the OS 
to be reworked as fast emulation of S/W will be really difficult.
> Am I, btw, understanding correctly that other than on x86 you
> intend PoD to not be used for maxmem > memory scenarios, at
> least for the time being?
Yes. I don't think it would be difficult to add that support for Arm as 
well.
Also, at the moment, PoD code is nearly a verbatim copy of the x86 
version. And this is only because the interface with the rest p2m code. 
I am planning to discuss on the ML the possibility to share the PoD code.
--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel