On Tue, 20 Apr 2021 at 11:24, Michael S. Tsirkin <m...@redhat.com> wrote: > > On Thu, Mar 25, 2021 at 04:33:15PM +0000, Peter Maydell wrote: > > Currently the gpex PCI controller implements no special behaviour for > > guest accesses to areas of the PIO and MMIO where it has not mapped > > any PCI devices, which means that for Arm you end up with a CPU > > exception due to a data abort. > > > > Most host OSes expect "like an x86 PC" behaviour, where bad accesses > > like this return -1 for reads and ignore writes. In the interests of > > not being surprising, make host CPU accesses to these windows behave > > as -1/discard where there's no mapped PCI device. > > > > The old behaviour generally didn't cause any problems, because > > almost always the guest OS will map the PCI devices and then only > > access where it has mapped them. One corner case where you will see > > this kind of access is if Linux attempts to probe legacy ISA > > devices via a PIO window access. So far the only case where we've > > seen this has been via the syzkaller fuzzer. > > > > Reported-by: Dmitry Vyukov <dvyu...@google.com> > > Fixes: https://bugs.launchpad.net/qemu/+bug/1918917 > > Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> > > > Looks ok superficially > > Acked-by: Michael S. Tsirkin <m...@redhat.com> > > Peter pls merge if appropriate.
Thanks; I'll take it via target-arm.next for 6.1 (it'll need a tweak to use hw_compat_6_0 rather than hw_compat_5_2 so it might need to wait until the patch adding hw_compat_6_0 hits master.) -- PMM
