On 2011-08-04 21:18, Konrad Rzeszutek Wilk wrote: > 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. This is a host-side issue, not a guest-side one. No QEMU here, no SeaBIOS (rather the "usual" kind of BIOS you get with physical HW). The problem shows up when any kind of *host-side* driver (including KVM's device pass-through code) requests the PCI resources of that device. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
