Linux Virtualization - Jun 2013 - what should a virtio-mmio transport without a backend look like?

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".
> 
> We could just say "all RAZ/WI", since this merely causes Linux
> currently to print a warning about the bad magic number, and
> then subsequently make Linux less alarmist about the zero.
> 
> We could also define that the transport should look as if
> there's some sort of 'null' backend plugged in. This would
> be more effort on the qemu side though, I think.
There are two aspects of the problem:

1. Current implementation of the virtio core won't do anything to the
device if the device/vendor IDs don't match with any of the drivers.

2. All that current virtio-mmio implementation will do is:
* read magic
* read device & vendor id
* write page size

So, a device behaving as you mentioned - magic ok, all register read as
zero, all writes ignored, will do exactly what you want.

Now, as to mandating this:

1. We could mandate device ID 0 (zero) as "NOOP". This is in line with
current ID numbers allocation, just needs formalizing at the top level
of the spec.

2. I have no problem with adding the magic/RAZ/WI behaviour to the
current appendix X, however I must say that the "write page size" will
disappear in the next version of the spec (no more page numbers, just
normal 64-bit addresses), so defining device ID as above will cover your
use case, I believe (as in: correct magic == correct device, NOOP device
== no further actions).
> 2. What was the rationale behind prohibiting interrupt
> line sharing between two virtio-mmio transports? ("device
> operation" section of appendix X). Lack of spare IRQs
> turns out to be the major limit on how many transports you
> can have.
Hm. Simplicity was the intention, really, no hidden agenda. I've never
actually tried to have two platform devices sharing an interrupt, so I'm
not sure how will the generic infrastructure behave in such situation.
> (Is there a mailing list I should be asking this question on?)
virtualization at lists.linux-foundation.org (now on copy)

Pawe?

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.

On 20 June 2013 13:58, Christopher Covington <cov at codeaurora.org>
wrote:
>> On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote:
>>> 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).
> Might it be reasonably easy to just not enumerate unused transports
> in the device tree or kernel parameters?
At least for QEMU, the backend that plugs into the transport
isn't created until after the machine model has created
transports and put together the device tree blob. So we don't
really have the information about what devices are going to
appear at the point we're doing this.

thanks
-- PMM

Pawel Moll <pawel.moll at arm.com> writes:
> 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".
>> 
>> We could just say "all RAZ/WI", since this merely causes
Linux
>> currently to print a warning about the bad magic number, and
>> then subsequently make Linux less alarmist about the zero.
>> 
>> We could also define that the transport should look as if
>> there's some sort of 'null' backend plugged in. This would
>> be more effort on the qemu side though, I think.
>
> There are two aspects of the problem:
>
> 1. Current implementation of the virtio core won't do anything to the
> device if the device/vendor IDs don't match with any of the drivers.
>
> 2. All that current virtio-mmio implementation will do is:
> * read magic
> * read device & vendor id
> * write page size
>
> So, a device behaving as you mentioned - magic ok, all register read as
> zero, all writes ignored, will do exactly what you want.
>
> Now, as to mandating this:
>
> 1. We could mandate device ID 0 (zero) as "NOOP". This is in line
with
> current ID numbers allocation, just needs formalizing at the top level
> of the spec.
FWIW, I'm happy to bless 0 as "no device present".

Cheers,
Rusty.