On Thu, Aug 04, 2011 at 08:11:45AM -0600, Bjorn Helgaas wrote: > On Thu, Aug 4, 2011 at 1:28 AM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> 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. > > I tend to agree that it would be better to have a more general change > in the way we handle E820 because there are similar issues that don't > involve KVM. > > For example, see > https://bugzilla.kernel.org/show_bug.cgi?id=31602#c32; there we need > to reserve a PNP device region of 0xd0000000-0xdfffffff, but the > reservation fails because we have a previous 0xd0000000-0xd3ffffff > reservation from E820. We might hack around it for now by doing the > PNP reservation in pieces, but I think it would be cleaner to do > something different with the E820 stuff. Ah, so the BIOS _is_ confused. OK. My take was that in this case the QEMU is confused by not setting the E820 correctly and hence this shows up. So fix QEMU so that it will setup the E820 right? And sure making the Linux kernel be able to handle this would be an extra bonus - especially to deal with confused BIOSes. -- 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
