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. Regards, Dor
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
