[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin O'Connor
Subject: Re: [Qemu-devel] [PATCH 3/3] Changes related to secondary buses and 64bit regions
Date: Fri, 30 Dec 2011 01:22:54 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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?


--- 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) {
+                pci_set_io_region_addr(pci, i, 0);
+            }

reply via email to

[Prev in Thread] Current Thread [Next in Thread]