All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Paul Brook <paul@codesourcery.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	qemu-devel@nongnu.org, Pawel Moll <pawel.moll@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/4] virtio-mmio transport
Date: Fri, 09 Dec 2011 09:57:40 -0600	[thread overview]
Message-ID: <4EE22FF4.5050903@codemonkey.ws> (raw)
In-Reply-To: <201112091516.07644.paul@codesourcery.com>

On 12/09/2011 09:16 AM, Paul Brook wrote:
> [Replying to various bits of this thread all at once]
>
>>   * you have to specify which kind of virtio device you want in the
>>     board model. In particular this means that for virtio-blk the user
>>     has to say "-drive if=none,file=whatever.img,id=myimg
>>     -global virtio-blk-mmio.drive=myimg" or the virtio-blk layer will
>>     refuse to start, which is not at all userfriendly
>
> This is pretty lame.  I see two or three bugs here:
>
> 1) We're greating virtio devices unconditionally.  Much better would be to
> have devices be allocated as necessary.  e.g. unless the user explicitly
> requests otherwise, put the first device at a particular address, and
> subsequent devices at sequential addresses. The guest OS can then easily probe
> them to see which are present.  I guess a null virtio device might make sense
> to avoid accessing undefined memory regions.
> For the vexpress board the logic tile site (0xc0000000) seems like a sensible
> location.  Your current choice of an area reserved by the southbridge seems
> somewhat questionable.
>
> 2) virtio-blk fails if no drive is connected.  I guess you could call this a
> feature, which means you must fix (1).  If not then I think it's reasonable
> for hardcoded board devices should also use hardcoded drive IDs.  i.e. we act
> as if the user specified "-global virtio-blk-mmio.drive=virtio" or similar
>
> 3) "qemu -drive if=virtio" assmes you want PCI virtio.  Either we consider
> this an obsolete legacy option and document it as such, or fix it as part of
> (1).  In the latter case it's probably going to do the wrong thing on boards
> that have both virtio-mmio and PCI (there are at least two correct answers).
>
>> [...]
>> Correct.  Syborg virtio was something Paul Brook did bit is not an
>> "official" virtio transport as far as Linux or the spec is concerned.
>>
>> I'm not sure what guest software uses the syborg virtio transport.
>
> It is/was a virtual reference platform for SymbianOS.  However since then the
> Symbian Foundation got shot in the back of the head and the rest of Nokia
> jumped ship to Windows, so I'd be surprised if anyone really cares about it.

Can we remove syborg virtio then?

Regards,

Anthony Liguori

>
> Paul
>

  reply	other threads:[~2011-12-09 15:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-14 14:55 [Qemu-devel] [RFC 0/4] virtio-mmio transport Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 1/4] virtio: Add support for guest setting of queue size Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 2/4] virtio: Support transports which can specify the vring alignment Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 3/4] Add MMIO based virtio transport Peter Maydell
2011-11-14 14:55 ` [Qemu-devel] [RFC 4/4] hw/vexpress.c: Add MMIO " Peter Maydell
2011-11-14 15:41 ` [Qemu-devel] [RFC 0/4] virtio-mmio transport Stefan Hajnoczi
2011-11-16 14:33 ` Paolo Bonzini
2011-11-16 18:41   ` Peter Maydell
2011-11-16 19:56     ` Anthony Liguori
2011-11-17 11:20       ` Pawel Moll
2011-11-17 11:44         ` Paolo Bonzini
2011-12-09 15:16       ` Paul Brook
2011-12-09 15:57         ` Anthony Liguori [this message]
2011-12-12  2:52           ` Paul Brook
2011-12-12 11:16             ` Pawel Moll
2011-12-12 11:16               ` Pawel Moll
2011-12-12 14:45               ` Paul Brook
2011-12-12 14:51                 ` Pawel Moll
2011-12-12 14:51                   ` Pawel Moll
2011-12-16  5:36                 ` Rusty Russell
2011-12-16  5:36                 ` Rusty Russell
2011-12-12 14:45               ` Paul Brook
2011-12-12 12:14 ` Stefan Hajnoczi
2011-12-12 12:28   ` Pawel Moll
2011-12-12 13:12     ` Michael S. Tsirkin
2011-12-12 13:19       ` Pawel Moll
2011-12-12 15:11     ` Stefan Hajnoczi
2011-12-12 15:18       ` Peter Maydell
2011-12-12 15:21       ` 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=4EE22FF4.5050903@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=paul@codesourcery.com \
    --cc=pawel.moll@arm.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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.