All of lore.kernel.org
 help / color / mirror / Atom feed
From: rusty@rustcorp.com.au (Rusty Russell)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 1/2] virtio: Add AMBA bus driver for virtio device
Date: Tue, 13 Sep 2011 12:28:26 +0930	[thread overview]
Message-ID: <87hb4h408d.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1315845956.3297.7.camel@hornet.cambridge.arm.com>

On Mon, 12 Sep 2011 17:45:56 +0100, Pawel Moll <pawel.moll@arm.com> wrote:
> On Mon, 2011-09-12 at 11:01 +0930, Rusty Russell wrote:
> > You need to make these at least 64 bits.  Lguest makes them variable
> > width, in fact.
> 
> No problem, I've reserved 128 bits in the modified registers layout (see
> RFC v2), I can even change it into "offset/value" interface, which would
> give you variable width. One thing I don't get is how to access feature
> bits > 31? The get_features() seems
> to be limited to 32:
> 
> struct virtio_config_ops {
> <...>
> 	u32 (*get_features)(struct virtio_device *vdev);
> <...>
> }

There's a patch for that already :)

> > > + *  0x008   32  QueuePFN      PFN for the currently selected queue
> > > + *  0x00c   32  QueueNum      Queue size for the currently selected queue
> > 
> > You should, I believe, seriously consider allowing the guest to set the
> > queue size, rather than the host (perhaps the host could suggest one,
> > but the guest should be able to override it).
> 
> I guess the QueueNum could be simply a read/write register - guest can
> read suggestion and override it writing it back. The same question
> though - how can guest change it? (I mean some API?)

We can sort that out later... the Guest may try some ambitious large
allocation and fall back if it fails.

> > Anthony or Michael might suggest other changes, since they are most
> > familiar with virtio_pci limitations...
> 
> I've added them on the RFC v2 Cc as well - all feedback more then
> welcome!

Excellent...  of course, the virtualization list is down at the moment,
making this a bit more awkward.

Cheers,
Rusty.

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Pawel Moll <pawel.moll@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Anthony Liguori <aliguori@us.ibm.com>,
	virtualization <virtualization@lists.linux-foundation.org>,
	"Michael S.Tsirkin" <mst@redhat.com>,
	Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [RFC 1/2] virtio: Add AMBA bus driver for virtio device
Date: Tue, 13 Sep 2011 12:28:26 +0930	[thread overview]
Message-ID: <87hb4h408d.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1315845956.3297.7.camel@hornet.cambridge.arm.com>

On Mon, 12 Sep 2011 17:45:56 +0100, Pawel Moll <pawel.moll@arm.com> wrote:
> On Mon, 2011-09-12 at 11:01 +0930, Rusty Russell wrote:
> > You need to make these at least 64 bits.  Lguest makes them variable
> > width, in fact.
> 
> No problem, I've reserved 128 bits in the modified registers layout (see
> RFC v2), I can even change it into "offset/value" interface, which would
> give you variable width. One thing I don't get is how to access feature
> bits > 31? The get_features() seems
> to be limited to 32:
> 
> struct virtio_config_ops {
> <...>
> 	u32 (*get_features)(struct virtio_device *vdev);
> <...>
> }

There's a patch for that already :)

> > > + *  0x008   32  QueuePFN      PFN for the currently selected queue
> > > + *  0x00c   32  QueueNum      Queue size for the currently selected queue
> > 
> > You should, I believe, seriously consider allowing the guest to set the
> > queue size, rather than the host (perhaps the host could suggest one,
> > but the guest should be able to override it).
> 
> I guess the QueueNum could be simply a read/write register - guest can
> read suggestion and override it writing it back. The same question
> though - how can guest change it? (I mean some API?)

We can sort that out later... the Guest may try some ambitious large
allocation and fall back if it fails.

> > Anthony or Michael might suggest other changes, since they are most
> > familiar with virtio_pci limitations...
> 
> I've added them on the RFC v2 Cc as well - all feedback more then
> welcome!

Excellent...  of course, the virtualization list is down at the moment,
making this a bit more awkward.

Cheers,
Rusty.

  parent reply	other threads:[~2011-09-13  2:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-02 12:24 [RFC 0/2] Memory mapped virtio device Pawel Moll
2011-09-02 12:24 ` Pawel Moll
2011-09-02 12:24 ` [RFC 1/2] virtio: Add AMBA bus driver for " Pawel Moll
2011-09-12  1:31   ` Rusty Russell
2011-09-12 16:45     ` Pawel Moll
2011-09-12 16:45       ` Pawel Moll
2011-09-12 16:51       ` [RFC v2] arm: Add platform " Pawel Moll
2011-09-12 17:27         ` Anthony Liguori
2011-09-12 17:27           ` Anthony Liguori
2011-09-13  8:58           ` Pawel Moll
2011-09-13  8:58             ` Pawel Moll
2011-09-13  2:58       ` Rusty Russell [this message]
2011-09-13  2:58         ` [RFC 1/2] virtio: Add AMBA " Rusty Russell
2011-09-13  9:40         ` Pawel Moll
2011-09-13  9:40           ` Pawel Moll
2011-09-14  0:18           ` Rusty Russell
2011-09-14  0:18             ` Rusty Russell
2011-09-14 16:47             ` Pawel Moll
2011-09-14 16:47               ` Pawel Moll
2011-09-02 12:24 ` [RFC 2/2] ARM: Add VIRTUALIZATION configuration menu and virtio options Pawel Moll

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87hb4h408d.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.