"Michael S. Tsirkin" <m...@redhat.com> writes: > On Wed, May 29, 2013 at 09:16:39AM -0500, Anthony Liguori wrote: >> "Michael S. Tsirkin" <m...@redhat.com> writes: >> > I'm guessing any compiler that decides to waste memory in this way >> > will quickly get dropped by users and then we won't worry >> > about building QEMU with it. >> >> There are other responses in the thread here and I don't really care to >> bikeshed on this issue. > > Great. Let's make the bikeshed blue then?
It's fun to argue about stuff like this and I certainly have an opinion, but I honestly don't care all that much about the offsetof thing. However... > >> >> Well, given that virtio is widely deployed today, I would think the 1.0 >> >> standard should strictly reflect what's deployed today, no? >> >> Any new config layout would be 2.0 material, right? >> > >> > Not as it's currently planned. Devices can choose >> > to support a legacy layout in addition to the new one, >> > and if you look at the patch you will see that that >> > is exactly what it does. >> >> Adding a new BAR most certainly requires bumping the revision ID or >> changing the device ID, no? > > No, why would it? If we change the programming interface for a device in a way that is incompatible, we are required to change the revision ID and/or device ID. > If a device dropped BAR0, that would be a good reason > to bump revision ID. > We don't do this yet. But we have to drop BAR0 to put it behind a PCI express bus, right? If that's the case, then device that's exposed on the PCI express bus must use a different device ID and/or revision ID. That means a new driver is needed in the guest. >> Didn't we run into this problem with the virtio-win drivers with just >> the BAR size changing? > > Because they had a bug: they validated BAR0 size. AFAIK they don't care > what happens with other bars. I think there's a grey area with respect to the assumptions a device can make about the programming interface. But very concretely, we cannot expose virtio-pci-net via PCI express with BAR0 disabled because that will result in existing virtio-pci Linux drivers breaking. > Not we. The BIOS can disable IO BAR: it can do this already > but the device won't be functional. But the only way to expose the device over PCI express is to disable the IO BAR, right? Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
