On 2016-07-20 13:17, Mark Rutland wrote: > On Wed, Jul 20, 2016 at 12:19:20PM +0200, Jan Kiszka wrote: >> Again my question: What are the requirements regarding cache maintenance >> when allowing a guest to run with caches off? > > a) There must be no cacheable alias for the relevant addresses present > in TLBs or page tables for any CPU, for the executing exception level > or higher. Note that this includes hyp on the CPU the guest is > executing on, even during the execution of the guest. > > b) All caches to the PoC must not contain entries for any address the > guest will access. i.e. first you must invalidate, or > clean+invalidate the address range to the PoC. This must be done by > VA, and broadcast so as to affect all relevant caches. > > If those are not strictly followed, the usual issues resulting from > mismatched attributes, or from unexepcted data cache hit apply. > > I believe that KVM is on dodgy ground due to the kernel linear mapping > violating (a), and hence (b) also. > >> Jean-Philippe tried to address that in [1], but it's not complete or >> not fully correct or even both. > > It looks like that's using Set/Way ops, so that's not correct in all > cases. That does not guarantee the state of shared levels of cache, nor > of system caches. > > It doesn't affect other agents and is also incomplete.
The reasoning behind set/way (thus attempted full) flush is that the hypervisor does not know which VAs the root cell (a guest) has used in order to prepare the setup (code & data) of a non-root cell (a second guest). However, I think we better resolve that inside the non-root cell itself, over the target range that it actually touched. Tony added something to the Linux driver anyway, as ARM64 needed that. Then - IIUC now - we should only have to deal with flushing the stage-2 page tables prior to entering the guest, but then on a VA-basis. In addition, I will have to look into our communication page, data shared between hypervisor and cell. But that is less urgent. Thanks, Jan > > Thanks, > Mark. > >> [1] >> https://github.com/siemens/jailhouse/commit/add44a7a8431058ec9acb3db328166f8a8c34dcb -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
