On Wed, May 29, 2013 at 09:55:55AM -0500, Anthony Liguori wrote: > "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > > > On Wed, May 29, 2013 at 09:16:39AM -0500, Anthony Liguori wrote: > >> "Michael S. Tsirkin" <mst@xxxxxxxxxx> 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. It's compatible. > > 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? No, no. The PCIe spec states that failure to allocate an I/O BAR should still allow the device to function. That's *guest* allocating an I/O BAR. > 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 No :) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
