On Tue, Aug 2, 2011 at 10:16 AM, Maxim Nikolaev <mnikolaev13@xxxxxxxxxxx> wrote: > > On Aug 2, 2011, at 7:14 PM, Bjorn Helgaas wrote: > >> On Mon, Aug 1, 2011 at 9:47 PM, Nikolaev, Maxim >> <maxim.nikolaev@xxxxxxxxxxx> wrote: >>> >>> Hello Folks, >>> >>> I work on passing-thought nVidia PCI video card from Linux host to >>> Windows guest and was able to do it for FX-3800 but I faced the problem >>> with Quadro 2000. The problem is one of Quadro 2000 BAR's conflicts with >>> memory reported by BIOS-e820 as reserved. Basically they are overlapped >>> and kvm does not want to go further. dmesg, /proc/iomem and lspci are at >>> the end of this email. >>> The memory reserved by BIOS-e820 >>> [ 0.000000] BIOS-e820: 00000000fa000000 - 00000000fc000000 >>> (reserved) >>> Quadro 2000 is 05:00.0 and its conflicting BAR is >>> Region 3: Memory at f8000000 (64-bit, prefetchable) [disabled] >>> [size=64M] >>> and its upstream bridge 00:1c.00 >>> >>> I have a number of questions and will appreciate you a lot for >>> clarification >>> 1. Is this conflict a really problem of kernel PCI? (I just assume that >>> maybe kvm does not handle this case properly) >>> 2. If it is a kernel problem/feature then how I can avoid it? Where BAR >>> allocation is located in kernel source code? I enabled pci=earlydump and >>> see that PCI config space is the same at early boot stage and at the >>> entire kernel boot up that means at least in my case kernel does nothing >>> with BAR's allocated by BIOS. I've tried different kernel PCI options: >>> nocrs, use_crs, noacpi with the same results: BAR's are always located >>> at the same addresses. What I need is to make kernel to allocate BAR's >>> at different addresses that does not overlap with BIOS-e820 region. How >>> to make kernel to rearrange BAR's the other way then it is done in BIOS? >> >> Linux is quite strict about the E820 table. For instance, it puts >> E820 reserved areas in the iomem_resource tree, as you can see from >> /proc/iomem. We apparently don't move a BAR that conflicts with an >> E820 reserved area, but as you can see, a driver has trouble trying to >> claim the BAR. >> >> My experience is that Windows handles E820 reservations differently >> than Linux does. As far as I can tell, E820 has no connection at all >> to PCI resources (one example is here: >> https://bugzilla.kernel.org/show_bug.cgi?id=16228#c45). >> >> I expect that the Quadro 2000 probably works fine at [mem >> 0xf8000000-0xfbffffff] under Windows. Does it work under Linux as a >> host device? I suspect that might be broken too, because the nvidia >> driver would probably hit the same reservation issue that pci-stub >> hits. > > [Maxim Nikolaev] Q2000 works fine under Windows 7 but I've not checked how > BAR's are allocated their. Under the Linux host, nouveau driver somehow > works (I've not tested it thoroughly such as 3D capability) although still > complaining about resource conflict. BAR's allocation keeps the same. As for > native nvidia driver then it crashes under the Linux host It'd be interesting to know whether Windows moves the BARs. I think you can learn that from somewhere in the control panel, or via a tool like Everest (now called AIDA64, I guess): http://www.aida64.com/ The dmesg and /proc/iomem with nouveau would also be interesting. I suppose it's probably the same problem you see with pci-stub, but interesting that it still sort of works. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
