On 13/10/2015 15:55, Peter Maydell wrote: > On 13 October 2015 at 14:25, Peter Maydell <peter.mayd...@linaro.org> wrote: >> On 13 October 2015 at 14:19, Michael S. Tsirkin <m...@redhat.com> wrote: >>> On Tue, Oct 13, 2015 at 02:12:34PM +0100, Peter Maydell wrote: >>>> Well, if we're going to go around and fix the machines which >>>> don't get things right, I guess. It's a shame the default for >>>> the global is "this machine is broken", because now every >>>> new machine will default unnecessarily to broken, and there's >>>> no way to grep the source tree for machines which need fixing. >> >>> It'd be easy enough to revert the logic if someone's willing to start on >>> this. I'm reluctant to make this patchset depend on changing all >>> machines, but if you think I'm wrong, pls let me know. >> >> Most machines don't have a PCI controller, luckily. >> I'll have a look at how many files it would touch... > > So, first up I'm happy that the gpex and versatile > pci controllers don't have this problem (the way they > set up the mmio and io windows means there won't be > overlaps). That leaves the following pci controllers, > which I've listed with the source files which define machines > that use them: > > hw/pci-host/pbm > hw/sparc64/sun4u.c > hw/pci-host/bonito > hw/mips/mips_fulong2e.c > hw/pci-host/grackle > hw/pc/mac_oldworld.c > hw/pci-host/piix > [the x86 systems] > hw/pci-host/ppce500 > hw/ppc/e500.c > hw/pci-host/prep > hw/ppc/prep.c > hw/pci-host/q35 > [x86 systems] > hw/pci-host/uninorth > hw/ppc/mac_newworld.c > hw/alpha/typhoon > used in hw/alpha/dp264.c > hw/mips/gt64xxx_pci > hw/mips/mips_malta.c > hw/ppc/ppc4xx_pci > hw/ppc/ppc440_bamboo.c > hw/ppc/spapr_pci > hw/ppc/spapr.c [already marked as '0 addrs ok'] > hw/s390/s390-pci-bus > hw/s390/s390-virtio-ccw.c > hw/sh4/sh_pci > hw/sh4/rd2.c > > So we'd need to touch perhaps fifteen files in total. > > I don't insist we do that rather than applying this particular > patch, but I don't think it's a huge effort.
I'm going to remove the zero address checking and try to start a qemu for each of them to see which ones are broken. I remember from a previous discussion on my initial patch that x86 should be ok. > thanks > -- PMM > Laurent
