From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] virtio-blk PCI backend Date: Thu, 08 Nov 2007 16:02:51 +0200 Message-ID: <4733170B.70206@qumranet.com> References: <11944902733951-git-send-email-aliguori@us.ibm.com> <4732ABA0.5090603@qumranet.com> <473315DB.9030803@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Anthony Liguori Return-path: In-Reply-To: <473315DB.9030803-r/Jw6+rmf7HQT0dZR+AlfA@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 Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >> >>> + case VIRTIO_PCI_QUEUE_NOTIFY: >>> + if (val < VIRTIO_PCI_QUEUE_MAX) >>> + virtio_ring_kick(vdev, &vdev->vq[val]); >>> + break; >>> >> >> I see you're not using hypercalls for this, presumably for compatibility >> with -no-kvm. > > More than just that. By stick to PIO, we are compatible with just > about any VMM. For instance, we get Xen support for free. If we used > hypercalls, even if we agreed on a way to determine which number to > use and how to make those calls, it would still be difficult to > implement in something like Xen. > But pio through the config space basically means you're committed to handling it in qemu. We want a more flexible mechanism. Detecting how to make hypercalls can be left to paravirt_ops. (for Xen you'd use an event channel; and for kvm the virtio kick hypercall). >> Well I think I have a solution: advertise vmcall, >> vmmcall, pio to some port, and int $some_vector as hypercall feature >> bits in cpuid (for kvm, kvm, qemu, and kvm-lite respectively). Early >> setup code could patch the instruction as appropriate (I hear code >> patching is now taught in second grade). >> > > That ties our device to our particular hypercall implementation. If > we were going to do this, I'd prefer to advertise it in the device I > think. I really would need to look at the performance though of > vmcall and an edge triggered interrupt. It would have to be pretty > compelling to warrant the additional complexity I think. vmcall costs will go down, and we don't want to use different mechanisms for high bandwidth and low bandwidth devices. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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/