Rusty Russell wrote: > On Tuesday 13 November 2007 10:25:54 Anthony Liguori wrote: > >> Dor Laor wrote: >> >>> Anthony Liguori wrote: >>> >>>> Dor Laor wrote: >>>> >>>>> In general I think we need to add another feature or even version >>>>> number ( I know you guys hate it). >>>>> The reason is - Let's say you dont change functionality but change >>>>> the irq protocol (for example the isr won't be zeroed on read), then >>>>> an old >>>>> guest driver wouldn't know it runs on a new host version and will >>>>> have its irq line pulled up. >>>>> So I suggest adding a capability of VIRTIO_ISR_CLEAR_XXX or adding a >>>>> version number. >>>>> Comments? >>>>> >>>> I don't think we'll actually change the ISR protocol. I think it's >>>> the best that it can actually be. However, if we do need to change >>>> the ABI for some reason, I think the right thing to do is just use a >>>> new device ID (since it's effectively a new device). >>>> >>>> Regards, >>>> >>>> Anthony Liguori >>>> >>> Changing the devid is acceptable and much more easier then backward >>> compatibility support, I prefer it too. >>> Note that there are some disadvantages when changing the devid - For >>> example, >>> if you installed an old device drivers in the guest kernel and after a >>> while you bring the guest down, >>> upgrade the kvm host version and bring the guest back up. >>> If it has a new device id (and since the abi is not maintained the >>> driver won't match VENDOR=virtio; DEVID=*), >>> then the guest won't have a driver for the new device. >>> In that case I think a guest agent can switch to fully virtualized >>> device and afterwards install the driver automatically. >>> This is what we do in our production environment. >>> >> Hrm, I have to think about backwards compatibility at the virtio-pci >> layer. virtio-pci basically exposes two things, the first is an ABI for >> doing bidirectional notification and setting driver status. The second >> is a standard and transparent mechanism for virt_rings. >> >> I think that the first is simply enough that we don't need a feature >> mask or a version number. Maybe perhaps with the status bits, I don't >> know. For the virt_rings, if we had something more sophisticated than >> virt_rings down the road, that can be discovered/configured in the >> per-device configuration area so I don't think we need feature/version >> info for that. >> > > I originally had feature bits on each virtqueue for just such a reason. Used > the same "ack" logic as the normal feature bits (ie. set corresponding bit to > indicate guest wants to use the feature). > > Probably worth engineering this in now. > > I don't think a per-queue feature bit is worthwhile. What we need is feature bits for the ABI.
I'd start with one feature bit for the base device ABI. We can add further bits if we add new descriptor types, new queues, or newer config features The feature bits would be explicitly named and documented, instead of "I have a third virtqueue so I can use this new ABI". -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
