* Peter Maydell (peter.mayd...@linaro.org) wrote: > On 26 January 2018 at 15:47, Wei Huang <w...@redhat.com> wrote: > > > > > > On 01/25/2018 02:05 PM, Dr. David Alan Gilbert wrote: > >> * Wei Huang (w...@redhat.com) wrote: > >>> innerloop: > >>> /* clean cache because el2 might still cache guest data under KVM > >>> */ > >>> dc civac, x2 > >> > >> Can you explain a bit more about that please; if it's guest > >> visible acorss migration, doesn't that suggest we need the cache clear > >> in KVM or QEMU? > > > > I think this is ARM specific. This is caused by the inconsistency > > between guest VM's data accesses and userspace's accesses (in > > check_guest_ram) at the destination: > > > > 1) Because uncacheable (guest) + cacheable (host) ==> uncacheable. So > > the data accesses from guest VM go directly into memory. > > 2) QEMU user space will use the cacheable version. So it is possible > > that data can come from cache, instead of RAM. The difference between > > (1) and (2) obviously can cause check_guest_ram() to fail sometimes. > > I think the correct fix here is that your test code should turn > its MMU on. Trying to treat guest RAM as uncacheable doesn't work > for Arm KVM guests (for the same reason that VGA device video memory > doesn't work). If it's RAM your guest has to arrange to map it as > Normal Cacheable, and then everything should work fine.
Does this cause problems with migrating at just the wrong point during a VM boot? Dave > thanks > -- PMM -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
