It is worthwhile, when designing virtio, to keep in mind as many possible users as possible. In addition to block and net, I see at least the following: - vmgl (paravirtualized 3D graphics) [http://www.cs.toronto.edu/~andreslc/xen-gl/] - scsi (for tape, cd writer, etc.) - framebuffer (with just one request to share the framebuffer?) There are probably more. Any ideas? -- error compiling committee.c: too many arguments to function
On Sun, Jun 10, 2007 at 10:33:57AM +0300, Avi Kivity wrote:> It is worthwhile, when designing virtio, to keep in mind as many > possible users as possible. In addition to block and net, I see at > least the following: > > - vmgl (paravirtualized 3D graphics) > [http://www.cs.toronto.edu/~andreslc/xen-gl/] > - scsi (for tape, cd writer, etc.) > - framebuffer (with just one request to share the framebuffer?) > > There are probably more. Any ideas?- Fast inter-domain networking, a-la XenSocket. - PCI (or your favorite HW bus) passthrough, for your favorite oddball device (e.g., crypto-accelerators). Cheers, Muli
On Sun, 2007-06-10 at 10:33 +0300, Avi Kivity wrote:> It is worthwhile, when designing virtio, to keep in mind as many > possible users as possible. In addition to block and net, I see at > least the following: > > - vmgl (paravirtualized 3D graphics) > [http://www.cs.toronto.edu/~andreslc/xen-gl/] > - scsi (for tape, cd writer, etc.) > - framebuffer (with just one request to share the framebuffer?)Console, USB. HPA suggested an entropy device. Framebuffer is an interesting one. Virtio doesn't assume shared memory, so naively the fb you would just send outbufs describing changed memory. This would work, but describing rectangles is better. A helper might be the right approach here Lguest doesn't have a framebuffer, so maybe this is a good thing for me to hack on, but I promised myself I'd finish NAPI for the net device, and tag for block device first. Cheers, Rusty.
On 6/10/07, Avi Kivity <avi@qumranet.com> wrote:> There are probably more. Any ideas?sessions to 9p servers. But if we had a way to, first, do PV that send/receive to an fd pair, that would be a start. ron
Rusty Russell <rusty@rustcorp.com.au> writes:> On Sun, 2007-06-10 at 10:33 +0300, Avi Kivity wrote: >> It is worthwhile, when designing virtio, to keep in mind as many >> possible users as possible. In addition to block and net, I see at >> least the following:[...]> Framebuffer is an interesting one. Virtio doesn''t assume shared memory, > so naively the fb you would just send outbufs describing changed memory. > This would work, but describing rectangles is better. A helper might be > the right approach hereWouldn''t that be slow? Xen''s PV framebuffer tracks dirty areas with page granularity.> Lguest doesn''t have a framebuffer, so maybe this is a good thing for me > to hack on, but I promised myself I''d finish NAPI for the net device, > and tag for block device first.That would be nice. It usually takes more than one implementation to get an abstraction right. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Rusty Russell wrote:> On Mon, 2007-06-11 at 10:16 +0200, Gerd Hoffmann wrote: >> Hi, >> >>> Framebuffer is an interesting one. Virtio doesn't assume shared memory, >>> so naively the fb you would just send outbufs describing changed memory. >>> This would work, but describing rectangles is better. A helper might be >>> the right approach here >> Rectangles work just fine for a framebuffer console. They stop working >> once you plan to run any graphical stuff such as an X-Server on top of >> the framebuffer. Only way to get notified about changes is page faults, >> i.e. 4k granularity on the linear framebuffer memory. > > Yes, I discussed this with Ben Herrenschmidt a couple of months ago. It > would be better to provide a fb ioctl which X could use to describe > changed rectangles if available. In the virtio case we could hand that > information through, and other virtualized framebuffers would be able to > use it similarly.The X fbdev driver is going to make supporting a new fb ioctl pretty fun. It currently doesn't even support the existing fb ioctls and has a strange abstraction layer. I reckon writing a new X driver from scratch (or based on something like the vnc X driver) would be easier in the long run. Regards, Anthony Liguori> Cheers, > Rusty.