Hi Peter, On 12/10/2017 13:54, Peter Maydell wrote: > On 27 September 2017 at 15:56, Eric Auger <[email protected]> wrote: >> The ITS is not properly reset at the moment. It is possible the >> GITS_BASER<n>.valid is set and the in-kernel ITS caches are not >> empty (list of devices, collections, LPIs) while data structures >> in guest RAM are invalid/inconsistent. >> >> For instance, this happens after a guest shutdown -r now or a >> system reset, if we save the state before the guest re-writes >> the ITS registers or map devices, the table save ioctl may >> produce a QEMU abort. >> >> Until there is a proper reset implemented, let's unplug the >> consistency error checking. >> >> The reset issue will be fixed in subsequent patches. >> >> Signed-off-by: Eric Auger <[email protected]> >> Reported-by: wanghaibin <[email protected]> > > When in particular does this cause an abort -- when we're > trying to save the state in these edge cases, or when we're > trying to restore it? Both.
After a guest reset, device GITS_BASER<n> may point to an L1 device table that is not valid anymore. In that case device table save IOTCL returned -EINVAL and we aborted. On restore we had a bug in case all data in the table is invalid. In that case as well we currently abort. What does the kernel do -- is it just > rejecting the attempt, or might it actually have done bad > things to guest memory ? On Save, in case the GITS_BASER points to an invalid linear device tree table but the page still corresponds to a visible gfn window, this memory could be overwritten by the kernel. Thanks Eric > > thanks > -- PMM >
