From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgUWK-00089q-1j for qemu-devel@nongnu.org; Thu, 29 Dec 2011 23:56:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgUWJ-0000rp-6C for qemu-devel@nongnu.org; Thu, 29 Dec 2011 23:56:44 -0500 Received: from usrksweb02.endace.com ([174.143.168.194]:42605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgUWI-0000rh-TO for qemu-devel@nongnu.org; Thu, 29 Dec 2011 23:56:43 -0500 Message-ID: <4EFD4466.4020405@endace.com> Date: Fri, 30 Dec 2011 17:56:06 +1300 From: Alexey Korolev MIME-Version: 1.0 References: <4EFA9DF0.7050902@endace.com> <4EFAAABB.3020804@endace.com> <20111228114302.GB26310@redhat.com> <4EFBFD4A.8020402@endace.com> <20111229161844.GD2300@redhat.com> In-Reply-To: <20111229161844.GD2300@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] Changes related to secondary buses and 64bit regions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: sfd@endace.com, yamahata@valinux.co.jp, seabios@seabios.org, qemu-devel@nongnu.org On 30/12/11 05:18, Michael S. Tsirkin wrote: > On Thu, Dec 29, 2011 at 06:40:26PM +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. >>> 2. Put the 32 bit one in the non-prefetcheable range >> I'd rather not do this. Bios should not change memory region types. >> It will confuse guest OS drivers. > It shouldn't, it's a legal behavious. > Prefetcheable BAR allows certain optimizations but does not > require them. Well it is really difficult to say what is a "legal behavior". Yes it is legal behavior for PCI operations. But it could be a problem in software . I won't be surprised if a driver fail to start if we substitute the regions. It will be very hard to check all possible cases.