From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=45533 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P89bT-0000QJ-RH
	for qemu-devel@nongnu.org; Tue, 19 Oct 2010 06:39:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1P89bS-0005lq-Kf
	for qemu-devel@nongnu.org; Tue, 19 Oct 2010 06:39:35 -0400
Received: from mx1.redhat.com ([209.132.183.28]:31251)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1P89bS-0005le-E6
	for qemu-devel@nongnu.org; Tue, 19 Oct 2010 06:39:34 -0400
Message-ID: <4CBD7560.6080207@redhat.com>
Date: Tue, 19 Oct 2010 12:39:28 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <4CAC9CD1.2050601@collabora.co.uk> <4CB1D79A.6070805@redhat.com>
	<4CBD739A.2010500@collabora.co.uk>
In-Reply-To: <4CBD739A.2010500@collabora.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Ian Molton <ian.molton@collabora.co.uk>
Cc: linux-kernel@vger.kernel.org, QEMU Developers <qemu-devel@nongnu.org>

  On 10/19/2010 12:31 PM, Ian Molton wrote:
>
>> an virtualization@, many virtio developers live there.
>
> you mean virtualization@lists.osdl.org ?

Yes.

>
>> 2. should start with a patch to the virtio-pci spec to document what
>> you're doing
>
> Where can I find that spec?

http://ozlabs.org/~rusty/virtio-spec/

>
>>> + /* Transfer data */
>>> + if (virtqueue_add_buf(vq, sg_list, o_page, i_page, (void *)1)>= 0) {
>>> + virtqueue_kick(vq);
>>> + /* Chill out until it's done with the buffer. */
>>> + while (!virtqueue_get_buf(vq,&count))
>>> + cpu_relax();
>>> + }
>>> +
>>
>> This is pretty gross, and will burn lots of cpu if the hypervisor
>> processes the queue asynchronously.
>
> It doesnt, at present... It could be changed fairly easily ithout 
> breaking anything if that happens though.

The hypervisor and the guest can be changed independently.  The driver 
should be coded so that it doesn't depend on hypervisor implementation 
details.

-- 
error compiling committee.c: too many arguments to function