On 2016-08-01 19:23, Antonios Motakis wrote: > > > On 20-Jul-16 13:31, Jan Kiszka wrote: >> 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. > > Hello, > > Late to the party (response time may be inversely proportional to expert > rank). > > Yeah, we added an icache flush when loading to cell memory from the driver > side, so instruction caches are already consistent for us. We found that > simpler than whatever the ARMv7 port is doing :)
Yes, definitely. For ARMv7, I've already a patch here that also flushes the dcache from within the driver so that we can stop worrying about this aspect in the hypervisor. > > Regarding break before make, since Mark confirmed that this applies also when > changing intermediate levels of a mapping; we will need to take this into > account also in the code paths in Jailhouse that split/merge hugepages as > needed. > > Rather than a reordering of the cache flush functions called from the core, > maybe the most straightforward way to do it is via a check in each set_pte > call? I started to implement BBM, but then I read the spec again and mapped this on our model of modifications. To me it makes no sense anymore to implement this complication, simply because we are not in the situation that the spec describes: At the time of changes, from the first write to the final TLB flush, there are no "multiple threads of execution" that "can use the same translation tables". Jailhouse pulls all CPUs that will be affected by the stage-2 changes out of PL1/0 into HYP mode, only starts the modifications when they arrived there, ensures the flush (which is nicely broadcast to all CPUs) and only then releases the CPUs again into guest mode. However, what we need to change according to my current understanding - at least of ARMv7 - is making all stage-2 changes coherent, thus enforcing dcache flushes for the affected table entries. That is needed when we run the guest later on with caches off. IIUC, that also includes stage-2 translations. That change is trivial, though. > > Jan, if I understood right you are already looking into implementing this on > ARMv7? Yes, I'm (slowly) on it. I will share first code soon and would welcome any reviews, tests and also help/feedback with mapping things on ARM64 properly. Thanks, Jan -- 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.
