On Fri, Mar 21, 2014 at 2:25 PM, Sasha Levin <sasha.levin@xxxxxxxxxx> wrote: > On 03/21/2014 04:07 PM, Bjorn Helgaas wrote: >> >> I think I figured out what the problem is. In virtio_pci__init(), we >> allocate some address space with pci_get_io_space_block(), save its >> address in vpci->mmio_addr, and hook that address space up to >> virtio_pci__io_mmio_callback with kvm__register_mmio(). >> >> But when we update the BAR value in pci__config_wr(), the address >> space mapping is never updated. I think this means that virtio-pci >> can't tolerate its devices being moved by the OS. >> >> In my opinion, this is a bug in linux-kvm. We've managed to avoid >> triggering this bug by preventing Linux from moving the BAR (either by >> me reverting my patch, or by Sasha's linux-kvm change [1]). But it's >> not very robust to assume that the OS will never change the BAR, so >> it's quite possible that you'll trip over this again in the future. > > > The purpose of KVM tool is to implement as much as possible of the KVM > interface and the virtio spec so that we'll have a good development/testing > environment with a very simple to understand codebase. > > The issue you've mentioned is the "evil" side of the KVM tool. It never > tried (or claimed) to implement anything close to legacy hardware > interfaces. This means, for example, that it doesn't run any BIOS, there's > very lacking APIC support and the kernel is just injected into the virtual > RAM and gets run from there. > > It also means that we went into the PCI spec deep enough to get the code > to work with the kernel. The only reason we implemented MSI interrupts > for example is because they provide improved performance with KVM, not > because we were trying to get a complete implementation of the PCI spec. > > So yes, the PCI implementation in the KVM tool is lacking and what we > have there might be broken by making the kernel conform more closely > to the spec, but we are always happy to adapt and improve our code to > work with any changes in the kernel. > > To sum it up, If you'll end up adding a change to the kernel that is > valid according to the spec but breaks the KVM tool we'll just go ahead > and fix the tool. You really don't need to worry about breaking it. That makes sense, and I'm glad I had a chance to get acquainted with the KVM tool. If I get another problem report related to it, I'll try to remember that I don't need to worry about breaking it :) 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
