Re: [Qemu-devel] [PATCH RFC] memory: drop _overlap variant

[Avi Kivity]

On Thu, Feb 14, 2013 at 4:40 PM, Michael S. Tsirkin <address@hidden> 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.

>
> 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.

>> >
>> > 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.