qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport
Date: Thu, 28 Oct 2010 11:27:31 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.4

 On 10/27/2010 03:00 PM, Ian Molton wrote:
On 19/10/10 11:39, Avi Kivity wrote:
On 10/19/2010 12:31 PM, Ian Molton wrote:

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/

Ok, but I'm not patching that until theres been some review.

Well, I like to review an implementation against a spec.


There are links to the associated qemu and guest OS changes in my original email.

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.

Fixed - updated patch tested and attached.
+
+       /* Transfer data */
+       if (virtqueue_add_buf(vq, sg_list, o_page, i_page, gldata)>= 0) {
+               virtqueue_kick(vq);
+               /* Chill out until it's done with the buffer. */
+               wait_for_completion(&gldata->done);
+       }
+

Better, but still unsatisfying. If the server is busy, the caller would block. I guess it's expected since it's called from ->fsync(). I'm not sure whether that's the best interface, perhaps aio_writev is better.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]