On Thu, Feb 14, 2013 at 07:02:15PM +0200, Avi Kivity wrote: > On Thu, Feb 14, 2013 at 6:50 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > >> > As you see, ioapic at 0xfec00000 overlaps pci-hole. > >> > ioapic is guest programmable in theory - should use _overlap? > >> > pci-hole is not but can overlap with ioapic. > >> > So also _overlap? > >> > >> It's a bug. The ioapic is in the pci address space, not the system > >> address space. And yes it's overlappable. > > > > So you want to put it where? Under pci-hole? > > No, under the pci address space. Look at the 440fx block diagram. > > > And we'll have to teach all machine types > > creating pci-hole about it? > > No. > > > > >> > > >> > Let's imagine someone writes a guest programmable device for > >> > ARM. Now we should update all ARM devices from regular to _overlap? > >> > >> It's sufficient to update the programmable device. > > > > Then the device can be higher priority (works for apic) > > but not lower priority. Make priority signed? > > Is there an actual real problem that needs fixing?
Yes. Guests sometimes cause device BARs to temporary overlap the APIC range during BAR sizing. It works fine on a physical system but fails on KVM since pci has same priority. See the report: [BUG] Guest OS hangs on boot when 64bit BAR present -- MST
