qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/4] s390/kvm: Add a channel I/O based virtio tr


From: Rusty Russell
Subject: Re: [Qemu-devel] [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.
Date: Tue, 14 Aug 2012 09:40:01 +0930
User-agent: Notmuch/0.12 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu)

On Mon, 13 Aug 2012 10:56:38 +0200, Cornelia Huck <address@hidden> wrote:
> On Wed, 08 Aug 2012 13:52:57 +0930
> Rusty Russell <address@hidden> wrote:
> 
> > On Tue,  7 Aug 2012 16:52:47 +0200, Cornelia Huck <address@hidden> wrote:
> > 1) Please don't limit yourself to 32 feature bits!  If you look at how
> >    virtio_mmio does it, they use a selector to index into a
> >    theoretically-infinite array of feature bits:
> 
> It should be easy to extend the data processed by the feature ccws to a
> feature/index combination. Would it be practical to limit the index to
> an 8 bit value?

256 feature bits?  That seems like it could one day be limiting.  Or an
8 bit accessor into feature words?  8192 seems enough for anyone sane.

> > Note that we're also speculating a move to a new vring format, which
> > will probably be little-endian.  But you probably want a completely new
> > ccw code for that anyway.
> 
> Do you have a pointer to that discussion handy?
> 
> If the host may support different vring formats, I'll probably want to
> add some kind of discovery mechanism for that as well (what discovery
> mechanism depends on whether this would be per-device or per-machine).

It would be per-machine; per-device would be a bit crazy.  We'd
deprecate the old ring format.

There's been no consistent thread on the ideas for a ring change,
unfortunately, but you can find interesting parts here, off this thread:

Message-ID: <address@hidden>
Subject: Re: [RFC 7/11] virtio_pci: new, capability-aware driver.

Cheers,
Rusty.



reply via email to

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