On Thu, Aug 04, 2011 at 09:28:25AM +0200, Jan Kiszka wrote: > On 2011-08-04 05:14, Konrad Rzeszutek Wilk wrote: > >>>>>> 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 > >> OK, if it's safe to ignore for PCI allocations, then ignore the > >> reservation. But I think that should be done automatically if somehow > >> possible, not by the user via a kernel parameter. > >> > >> Is there a simple way to test such a policy without significant > >> refactoring of the e820 code? > > > > Why not just make the kvm PCI passthrough code check the MMIO > > of the card and make an "gap" in the E820 for that region. In essence > > creating a PCI I/O region? > > > > Why does QEMU setup up that reserved region? Can it move it? > > I really don't think this is KVM business. The fact that also nouveau > and nvidia's blob complain or even stumble (Maxim is checking if the > hack also heals the latter) and both are using a standard PCI core > service to request the card resources strongly suggests that the problem > should not be attacked by some ad-hoc workaround in KVM. So what if the PCI resource is allocated by SeaBIOS/KVM/Bochs ofr its own usage and the PCI card that is plugged intersects that region. Making the Linux kernel move the PCI resource (for either one of them) seems like a workaround - as in on a normal machine you would not have this conflict. The BIOS would have setup the PCI resources to not intersect - right? Or is that actually not true and we should be able to move the PCI resources (MMIO) around after bootup - and we just never did it b/c we never hit a problem with it? -- 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
