From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 2/6] virtio block driver for QEMU (v2) Date: Mon, 12 Nov 2007 17:25:54 -0600 Message-ID: <4738E102.2050200@us.ibm.com> References: <11947512401155-git-send-email-aliguori@us.ibm.com> <11947512432057-git-send-email-aliguori@us.ibm.com> <47373ADF.3000607@qumranet.com> <47375731.7020007@us.ibm.com> <4738452F.8070502@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Avi Kivity To: dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org Return-path: In-Reply-To: <4738452F.8070502-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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. Rusty, Avi: any thoughts? I'm a bit on the fence. Regards, Anthony Liguori > 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/