On Thu, Feb 14, 2013 at 05:07:02PM +0200, Avi Kivity wrote: > On Thu, Feb 14, 2013 at 4:40 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > > On Thu, Feb 14, 2013 at 04:14:39PM +0200, Avi Kivity wrote: > > > > But some parents are system created and shared by many devices so children > > for > > such have no idea who their siblings are. > > > > Please take a look at the typical map in this mail: > > '[BUG] Guest OS hangs on boot when 64bit BAR present' > > > > system overlap 0 pri 0 [0x0 - 0x7fffffffffffffff] > > kvmvapic-rom overlap 1 pri 1000 [0xca000 - 0xcd000] > > pc.ram overlap 0 pri 0 [0xca000 - 0xcd000] > > ++ pc.ram [0xca000 - 0xcd000] is added to view > > .................... > > smram-region overlap 1 pri 1 [0xa0000 - 0xc0000] > > pci overlap 0 pri 0 [0xa0000 - 0xc0000] > > cirrus-lowmem-container overlap 1 pri 1 [0xa0000 - 0xc0000] > > cirrus-low-memory overlap 0 pri 0 [0xa0000 - 0xc0000] > > ++cirrus-low-memory [0xa0000 - 0xc0000] is added to view > > kvm-ioapic overlap 0 pri 0 [0xfec00000 - 0xfec01000] > > ++kvm-ioapic [0xfec00000 - 0xfec01000] is added to view > > pci-hole64 overlap 0 pri 0 [0x100000000 - 0x4000000100000000] > > pci overlap 0 pri 0 [0x100000000 - 0x4000000100000000] > > pci-hole overlap 0 pri 0 [0x7d000000 - 0x100000000] > > pci overlap 0 pri 0 [0x7d000000 - 0x100000000] > > ivshmem-bar2-container overlap 1 pri 1 [0xfe000000 - > > 0x100000000] > > ivshmem.bar2 overlap 0 pri 0 [0xfe000000 - 0x100000000] > > ++ivshmem.bar2 [0xfe000000 - 0xfec00000] is added to view > > ++ivshmem.bar2 [0xfec01000 - 0x100000000] is added to view > > > > 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? And we'll have to teach all machine types creating pci-hole about it? > > > > 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? > >> > > >> > Non overlapping is not a common case at all. E.g. with normal PCI > >> > devices you have no way to know nothing overlaps - addresses are guest > >> > programmable. > >> > >> Non overlapping is mostly useful for embedded platforms. > > > > Maybe it should have a longer name like _nonoverlap then? > > Current API makes people assume _overlap is only for special > > cases and default should be non overlap. > > The assumption is correct.