From patchwork Fri Dec 30 06:22:54 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin O'Connor X-Patchwork-Id: 133619 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [140.186.70.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 23419B6FAF for ; Fri, 30 Dec 2011 17:23:44 +1100 (EST) Received: from localhost ([::1]:57996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgVsR-0001jD-0b for incoming@patchwork.ozlabs.org; Fri, 30 Dec 2011 01:23:39 -0500 Received: from eggs.gnu.org ([140.186.70.92]:54347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgVsF-0001dS-Fb for qemu-devel@nongnu.org; Fri, 30 Dec 2011 01:23:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgVrm-0004Wh-AR for qemu-devel@nongnu.org; Fri, 30 Dec 2011 01:23:27 -0500 Received: from mail-qw0-f52.google.com ([209.85.216.52]:43998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgVrm-0004Wb-4d for qemu-devel@nongnu.org; Fri, 30 Dec 2011 01:22:58 -0500 Received: by qadc11 with SMTP id c11so8643353qad.4 for ; Thu, 29 Dec 2011 22:22:57 -0800 (PST) Received: by 10.224.217.133 with SMTP id hm5mr45907612qab.49.1325226177542; Thu, 29 Dec 2011 22:22:57 -0800 (PST) Received: from localhost (207-172-165-101.c3-0.avec-ubr1.nyr-avec.ny.cable.rcn.com. [207.172.165.101]) by mx.google.com with ESMTPS id el3sm6722144qab.8.2011.12.29.22.22.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 22:22:56 -0800 (PST) Date: Fri, 30 Dec 2011 01:22:54 -0500 From: Kevin O'Connor To: Alexey Korolev Message-ID: <20111230062254.GA22078@morn.localdomain> References: <4EFA9DF0.7050902@endace.com> <4EFAAABB.3020804@endace.com> <20111228114302.GB26310@redhat.com> <4EFBFD90.3020705@endace.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4EFBFD90.3020705@endace.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.216.52 Cc: sfd@endace.com, yamahata@valinux.co.jp, seabios@seabios.org, qemu-devel@nongnu.org, "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH 3/3] Changes related to secondary buses and 64bit regions X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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); + } } } }