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

On 21 June 2013 19:45, Christopher Covington <cov at codeaurora.org>
wrote:
> You were proposing to use a valid/existing MagicValue/Version/VendorID with
a
> special DeviceID that does nothing. I'm saying why not use a
valid/existing
> MagicValue/Version/VendorID/DeviceID with a special parameter setting,
size=0,
> that does nothing?
Ah, I see. Well, it sounds from your quoted mount message as if they
do actually do something (ie the kernel finds a block device and
creates a /dev/vda for it), rather than nothing, which seems like
a bad thing. Also, it's mixing a detail of the backend layer (what
a zero-sized disk happens to look like) with the transport layer,
which seems a bit ugly spec-wise.

(Implementation wise I'm not crazy about it either since it would
be way more complicated than saying "no backend? OK, RAZ/WI".)

-- PMM

On 06/22/2013 06:51 AM, Peter Maydell wrote:
> On 21 June 2013 19:45, Christopher Covington <cov at codeaurora.org>
wrote:
>> You were proposing to use a valid/existing MagicValue/Version/VendorID
with a
>> special DeviceID that does nothing. I'm saying why not use a
valid/existing
>> MagicValue/Version/VendorID/DeviceID with a special parameter setting,
size=0,
>> that does nothing?
[...]
> Also, it's mixing a detail of the backend layer (what
> a zero-sized disk happens to look like) with the transport layer,
> which seems a bit ugly spec-wise.
I don't think that has to be the case. From what I understand of your
architecture, the device layer is completely opaque to the transport layer,
and the transport layer is immutable, but surely the device layer will at
least know how many transports are available? As long as that's true,
can't
the device layer just create real devices and hook them up to transports, and
then create no-op devices and hook them up to any remaining transports?
> (Implementation wise I'm not crazy about it either since it would
> be way more complicated than saying "no backend? OK, RAZ/WI".)
(I thought virtio block devices were already implemented.)

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

On 24 June 2013 13:26, Christopher Covington <cov at codeaurora.org>
wrote:
> On 06/22/2013 06:51 AM, Peter Maydell wrote:
>> On 21 June 2013 19:45, Christopher Covington <cov at
codeaurora.org> wrote:
>>> You were proposing to use a valid/existing
MagicValue/Version/VendorID with a
>>> special DeviceID that does nothing. I'm saying why not use a
valid/existing
>>> MagicValue/Version/VendorID/DeviceID with a special parameter
setting, size=0,
>>> that does nothing?
>
> [...]
>
>> Also, it's mixing a detail of the backend layer (what
>> a zero-sized disk happens to look like) with the transport layer,
>> which seems a bit ugly spec-wise.
>
> I don't think that has to be the case. From what I understand of your
> architecture, the device layer is completely opaque to the transport layer,
> and the transport layer is immutable, but surely the device layer will at
> least know how many transports are available? As long as that's true,
can't
> the device layer just create real devices and hook them up to transports,
and
> then create no-op devices and hook them up to any remaining transports?
No, the device creation code just creates all the devices the user
asks for. At the point where it can't find a transport to
plug one into, the device-creation fails with an error message.
It doesn't attempt to find buses with nothing plugged in (since
for instance it's entirely reasonable to have a PCI slot with
no card in it).
>> (Implementation wise I'm not crazy about it either since it would
>> be way more complicated than saying "no backend? OK,
RAZ/WI".)
>
> (I thought virtio block devices were already implemented.)
Yes, but "what does a transport do if there's no backend" is
transport code, whereas the block device is backend code.
I actually think the creation of a spurious /dev/vda makes
'zero-sized block backend' a non-starter anyway, though.
It's also neither conceptually pure nor pragmatically easy,
so it falls between two stools.

I could see the rationale for a 'cleanliness of spec' position
that we should handle this with a 'null' backend with a new
DeviceID which is completely functional (including all the host
feature bitmaps, setting up queues, interrupts, etc) but just
doesn't do anything. That would be more complicated to implement
than RAZ/WI, but not impossible.

thanks
-- PMM