From: Christopher Covington <cov@codeaurora.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "KONRAD Frédéric" <fred.konrad@greensocs.com>,
"Pawel Moll" <pawel.moll@arm.com>,
virtualization@lists.linux-foundation.org
Subject: Re: what should a virtio-mmio transport without a backend look like?
Date: Thu, 20 Jun 2013 08:58:03 -0400 [thread overview]
Message-ID: <51C2FC5B.7080406@codeaurora.org> (raw)
In-Reply-To: <1371726501.3231.22.camel@hornet>
Hi Peter,
On 06/20/2013 07:08 AM, Pawel Moll wrote:
> On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote:
>> I'm (finally) trying to add virtio-mmio support properly to
>> QEMU now Fred has put all the refactoring foundations in place.
>>
>> 1. One question I've run into is: what should a virtio-mmio transport
>> with no backend look like to the guest OS? The spec as written
>> seems to assume that there's always some backend present.
>> (The idea is that QEMU might just always instantiate say 8
>> mmio transports, and then whether they actually have a
>> blk/net/whatever backend depends on user options).
>>
>> It looks as if the current linux driver insists (if it sees a
>> device tree node) that the MagicValue register at least is
>> correct (otherwise it complains). So one possibility would
>> be "MagicValue/Version/VendorID must read as usual, DeviceID
>> should read as some special "nothing here" value (0?), everything
>> else can RAZ/WI".
Might it be reasonably easy to just not enumerate unused transports in the
device tree or kernel parameters?
Regards,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
next prev parent reply other threads:[~2013-06-20 12:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAFEAcA9qCUQLZho8wJvewYJ0AEhDBc37_LpZWs8XBV1U7RVZgA@mail.gmail.com>
2013-06-20 11:08 ` what should a virtio-mmio transport without a backend look like? Pawel Moll
2013-06-20 12:58 ` Christopher Covington [this message]
2013-06-21 15:23 ` Peter Maydell
2013-06-21 16:02 ` Christopher Covington
2013-06-21 16:41 ` Peter Maydell
2013-06-21 16:47 ` Pawel Moll
2013-06-21 17:01 ` Peter Maydell
2013-06-21 18:01 ` Christopher Covington
2013-06-21 18:28 ` Peter Maydell
2013-06-21 18:45 ` Christopher Covington
2013-06-22 10:51 ` Peter Maydell
2013-06-24 12:26 ` Christopher Covington
2013-06-24 12:57 ` Peter Maydell
2013-06-21 20:13 ` Paolo Bonzini
2013-07-01 0:07 ` Rusty Russell
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=51C2FC5B.7080406@codeaurora.org \
--to=cov@codeaurora.org \
--cc=fred.konrad@greensocs.com \
--cc=pawel.moll@arm.com \
--cc=peter.maydell@linaro.org \
--cc=virtualization@lists.linux-foundation.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.