From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbU1q-0006A1-SR for qemu-devel@nongnu.org; Fri, 16 Dec 2011 04:24:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbU1p-0001KQ-UD for qemu-devel@nongnu.org; Fri, 16 Dec 2011 04:24:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbU1p-0001KH-Na for qemu-devel@nongnu.org; Fri, 16 Dec 2011 04:24:33 -0500 Message-ID: <4EEB0E1B.5070002@redhat.com> Date: Fri, 16 Dec 2011 10:23:39 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <4ED58108.3090903@endace.com> <20111130074903.GD17781@redhat.com> <4ED70E71.3030003@endace.com> <4ED7640D.5060203@redhat.com> <4ED767DF.7060707@redhat.com> <4EDC4899.2080101@endace.com> <4EE5B6E4.4010301@redhat.com> <4EE6D234.3000203@endace.com> <4EE8265F.2010703@endace.com> <4EE9B45A.2050401@redhat.com> <4EEACBFB.7000909@endace.com> In-Reply-To: <4EEACBFB.7000909@endace.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Korolev Cc: sfd@endace.com, yamahata@valinux.co.jp, seabios@seabios.org, qemu-devel@nongnu.org, "Michael S. Tsirkin" On 12/16/11 05:41, Alexey Korolev wrote: >>> I wonder if there any particular reason to separate prefetchable a >>> non-prefetchable memory regions in pciinit? Extra two more regions would >>> make code more complex. >> Oh yes, there is. Which reminds me that the whole thing isn't that easy >> unfortunaly ... >> >> The reason are pci bridges. They have two memory regions, one for >> prefetchable and one for non-prefetchable memory. All devices behind a >> pci bridge must have the bars within the bridges memory regions, thats >> why they are grouped together. >> >> This also implies that a 32bit and a 64bit bar (of the same type) behind >> a pci bridge must be mapped next to each other, so moving up 64bit bars >> unconditionally isn't going to fly. Devices behind bridges need some >> extra care, only when all bars are 64bit capable they can actually be >> mapped above 4G. > The qemu actually does not simulate PCI bridges at all. So good question > shall we bother about this? Yes. There is work in progress to add pci-express and a more modern chipset emulation to qemu. I think for now it is fine if we simply map everything behind a bridge below 4G and hash out the details (i.e. whenever we can move the bridge memory window above 4G or not) later. > I did some preliminary tests: 64bit BARs > are working quite well for linux 2.6.18 - 3.0 and windows 2008. Nice. > Also I've found important detail that according to PCI architecture > specification, the bridges can describe 64bit ranges for prefetchable > type of memory only. So it's very unlikely that devices exporting 64bit > non-prefetchable BARs. I guess we just need to add one extra type. Agree. > Even if there are two separate prefetchable memory regions (32 bit and > 64bit), it won't be a problem as there is no bridge on the 440FX inside > the virtual machine. Yes, devices attached to the root bus don't have to care about bridge windows. cheers, Gerd