On 01/26/2018 10:39 AM, Peter Maydell 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
I did try MMU-on while debugging this problem. It was a migration unit test written on top of kvm-unit-tests and I forced QEMU's tests/migration-test.c to use this .flat file as -kernel parameter. I didn't see any memory check failures using this approach. So I can confirm your suggestion. But turning MMU on means a much larger binary blob. I know you don't like the existing migration-test.c approach. Building a more complicated test case and embedding it in migration-test.c code will make the situation worse. Because of this, I chose the current version: small and manageable (even with one extra cache flush instruction). > 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. > > thanks > -- PMM >
