On 14 September 2013 22:31, Michael S. Tsirkin <m...@redhat.com> wrote: > Enabling the print in memory.c shows quite a lot > of these: > warning: subregion collision fec00000/1000 (ioapic) vs 8000000/f8000000 > (pci-hole) > warning: subregion collision fed00000/400 (hpet) vs 8000000/f8000000 > (pci-hole) > warning: subregion collision 0/80 (ich9-pm) vs 8/8 (dma-cont) > warning: subregion collision 0/80 (ich9-pm) vs 0/8 (dma-chan) > warning: subregion collision 0/80 (ich9-pm) vs 64/1 (i8042-cmd) > warning: subregion collision 0/80 (ich9-pm) vs 60/1 (i8042-data) > warning: subregion collision 0/80 (ich9-pm) vs 61/1 (elcr) > warning: subregion collision 0/80 (ich9-pm) vs 40/4 (pit) > warning: subregion collision 0/80 (ich9-pm) vs 70/2 (rtc) > warning: subregion collision 0/80 (ich9-pm) vs 20/2 (pic) > warning: subregion collision 0/80 (ich9-pm) vs 7e/2 (kvmvapic) > warning: subregion collision b0000000/10000000 (pcie-mmcfg) vs > 8000000/f8000000 (pci-hole) > > They likely work fine because the initialization order > happens to give priority to regions which are > registered later. > But we really should fix these, should we not?
Yes, I think we should. Somebody needs to work out what the correct priority order is and register things with the overlap flag set and a suitable priority value. (This might be easier to do if that patch for "make priorities signed rather than unsigned" is fixed to pass code review and committed.) -- PMM
