Hi, > > Second thing: Booting with an unpatched seabios has bad effects: > > > > [root@localhost ~]# cat /proc/iomem > > 00000000-000fffff : PCI Bus 0000:10 > > 00000000-00000fff : reserved > > 00001000-0009fbff : System RAM > > 0009fc00-0009ffff : reserved > > 000c0000-000c91ff : Video ROM > > 000c9800-000ca1ff : Adapter ROM > > 000ca800-000ccbff : Adapter ROM > > 000f0000-000fffff : reserved > > 000f0000-000fffff : System ROM > > 00100000-3ffdffff : System RAM > > 01000000-0174bde4 : Kernel code > > 0174bde5-01d30cff : Kernel data > > 01eaa000-0202afff : Kernel bss > > 3ffe0000-3fffffff : reserved > > fd000000-fdffffff : 0000:00:02.0 > > fd000000-fdffffff : bochs-drm > > febc0000-febdffff : 0000:00:03.0 > > febc0000-febdffff : e1000 > > febf0000-febf0fff : 0000:00:02.0 > > febf0000-febf0fff : bochs-drm > > fec00000-fec003ff : IOAPIC 0 > > fed00000-fed003ff : HPET 0 > > fed00000-fed003ff : PNP0103:00 > > fee00000-fee00fff : Local APIC > > feffc000-feffffff : reserved > > fffc0000-ffffffff : reserved > > > > "PCI Bus 0000:10" is bogus and "PCI Bus 0000:00" isn't there at all. > Yes, you shouldn't use pxb if you are not using the corresponding SeaBIOS. > However, as I understand we always attach a SeaBIOS binary with a QEMU > release, > so we should be OK with this.
IMO the qemu side should be more robust and not assume specific guest behavior. The guest firmware simply not configuring the pxb shouldn't cause the resources for bus 0 breaking that badly. pxb not working if you run firmware without pxb support is ok. But everything else should continue to work as it did before. cheers, Gerd