OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio] Groups - Action Item "Create text version of virtio 0.9.5 document" added

Pawel Moll <pawel.moll@arm.com> writes:

> On Wed, 2013-07-31 at 12:43 +0100, Michael S. Tsirkin wrote:
>> On Wed, Jul 31, 2013 at 12:05:07PM +0100, Pawel Moll wrote:
>> > On Wed, 2013-07-31 at 11:29 +0100, Michael S. Tsirkin wrote:
>> > >  Em, which one of specs? What I'm talking about is reserving a "Subsystem
>> > > > Device ID" (p.2.1 of the current spec) value 0 to a "device that does
>> > > > nothing" (is not a network card, nor block device, nor console, nor etc.
>> > > > nor anything else) and specifying how is the guest supposed to behave
>> > > > with such device (do nothing). In the current speech it would be
>> > > > "Appendix I: Doing Nothing Device", following "Appendix I: SCSI Host
>> > > > Device". How does this break anything?
>> > > 
>> > > It doesn't but then it will have to keep doing nothing :)
>> > 
>> > And that's the general plan.
>> Confused. You wrote: usecase:
>> 	create a pool of memory
>> 	mapped devices and assign functions to them later
>> Sounds like you really want a way to say
>> "there's no device there" not "there's a device here but it does nothing".
> Hm. Qemu people can't say "there's no device there", so they wanted to
> define a set of "devices doing nothing" as a default (at well known
> addresses, so the guest OS knows exactly where to look for virtio
> devices)

I'm not sure where this discussion took place, but there is nothing in
QEMU that requires a dummy device to be used.

The analogy would be a PCI slot that doesn't have a device plugged into
it.  Per the PCI spec, if a device is absent, any reads to the slot
will return a well defined value (all ones).  Those values are invalid
for things like a device id.

> and sometimes make some of them do something depending on the
> command line options. All this *before* the OS is actually launched, so
> when this happens the landscape is already set, eg. either 4 do-nothing
> devices, or 3 do-nothings and one block device, or 2 do-nothings, one
> block, one network device, etc.

I think you're confusing things a bit.

The way virtio-mmio is initialized in QEMU means that the QEMU machine
has to explicitly create the transport devices.  They must have fixed
MMIO addresses, etc.  virtio-mmio is a essentially a virtio host
controller that can support at most one device attached to it.

I really dislike the design of virtio-mmio.  I don't understand why it
limits itself to a single device.  But that's a different discussion.

virtio-blk is a separate device that can be connected to the transport.
And yes, there should be a way to specify "this transport is not
connected to anything".

But that's distinctly different than a device that does nothing.  We do
not model a dummy device in QEMU.


Anthony Liguori

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]