* Peter Maydell (peter.mayd...@linaro.org) wrote: > On 29 January 2018 at 09:53, Dr. David Alan Gilbert <dgilb...@redhat.com> > wrote: > > * Peter Maydell (peter.mayd...@linaro.org) wrote: > >> On 26 January 2018 at 19:46, Dr. David Alan Gilbert <dgilb...@redhat.com> > >> wrote: > >> > * Peter Maydell (peter.mayd...@linaro.org) wrote: > >> >> 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? > >> > >> It wouldn't surprise me if it did, but I don't think I've ever > >> tried to provoke that problem... > > > > If you think it'll get the RAM contents wrong, it might be best to fail > > the migration if you can detect the cache is disabled in the guest. > > I guess QEMU could look at the value of the "MMU disabled/enabled" bit > in the guest's system registers, and refuse migration if it's off... > > (cc'd Marc, Christoffer to check that I don't have the wrong end > of the stick about how thin the ice is in the period before the > guest turns on its MMU...)
OK; I mean it's not nice either way - but a failed migration is better than one with corrupt RAM. It's not pretty for cloud users; they do host-evacuations and the like fully automatically without any knowledge of the state of a VM and hope for migrations to work in any state. Dave > thanks > -- PMM -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
