Re: [Qemu-devel] [PATCH 3/3] Changes related to secondary buses and 64bit regions

[Kevin O'Connor <kevin@koconnor.net>]

On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
> On 29/12/11 00:43, Michael S. Tsirkin wrote:
> >On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
> >>All devices behind a bridge need to have all their regions consecutive and
> >>not overlapping with all the normal memory ranges.
> >>Since prefetchable memory is described by one record, we must avoid the situations
> >>when 32bit and 64bit prefetchable regions are present within one secondary bus.
> >How do we avoid this? Assume we have two devices:
> >a 32 bit and a 64 bit one, behind a bridge.
> >There are two main things we can do:
> >1. Make the 64 bit device only use the low 32 bit
>  It was my first implementation. Unfortunately older versions of
> Linux (Like 2.6.18) hang during startup with this.
> As far as I remember it was qemu-0.15 so may be 1.0 have no such an
> issue. I will check this.

That seems really odd - there's nothing unusual with a 64bit bar being
set to an address under 4gig.

Looking at the current code, it's not initializing 64bit bars properly
(it doesn't initialize the top bits of the 64bit address).  Does just
the patch below (totally untested) improve things for you?

-Kevin


--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -545,8 +545,10 @@ static void pci_bios_map_devices(struct pci_bus *busses)
                     i, addr, pci->bars[i].size, region_type_name[type]);
             pci_set_io_region_addr(pci, i, addr);
 
-            if (pci->bars[i].is64)
+            if (pci->bars[i].is64) {
                 i++;
+                pci_set_io_region_addr(pci, i, 0);
+            }
         }
     }
 }