Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On 5 March 2013 04:16, Paolo Bonzini <address@hidden> wrote:
>> Il 04/03/2013 18:58, Peter Maydell ha scritto:
>>>> > Mass-mark these devices as no_user.
>>> "There is no such thing as a 'no-user' device" -- Anthony
>>> (http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00896.html)
>>>
>>> We should figure out what we might be trying to use 'no-user'
>>> for, and consistently use it that way. Or alternatively we
>>> should remove it (perhaps replacing it with other flags).
>>> Mass-marking all the sysbus devices when we don't have a
>>> consistent sane defined semantics for the flag seems like
>>> a bad idea.
>>
>> $ x86_64-softmmu/qemu-system-x86_64 -device xlnx,,ps7-usb
>> (qemu) info qtree
>> bus: main-system-bus
>>   type System
>>   dev: xlnx,ps7-usb, id ""
>>     maxframes = 128
>>     irq 1
>>     mmio ffffffffffffffff/0000000000001000
>>     bus: usb-bus.0
>>       type usb-bus
>>
>> I have no idea what this means, but I'm pretty sure that no matter how I
>> configure it, it will never work.
>
> I agree. Exhibiting something that's a suboptimal user
> experience doesn't count as defining consistent semantics
> for no_user, though :-)

Can we make some progress towards something that makes more sense?

First step: reasons for marking a device no_user.

>From a user point of view, I think there's just one: -device/device_add
cannot possibly result in a working device.  Coherent enough semantics
for no_user, in my opinion, but I readily concede it's not particularly
useful for maintaining it as infrastructure and device models evolve.

For that, we need to drill down into reasons for "cannot possibly work".
Here are two, please add more:

* Can't make required connections

  -device can make only one connection: to a qbus (first order
  approximation).  Usually suffices for devices on "real" buses like
  PCI, SCSI, ...  Doesn't make any useful connection on "sysbus" (put in
  quotes because it's not really a bus).  Cases in between may exist:
  the bus connection is real enough, but the device wants additional
  connections.

  Additional connections are made by setup code that's not reachable
  from -device.  If they're required for the device to work, then
  -device cannot possibly result in a working device.  Worse, -device
  could happily claim success all the same.

  Are these additional connections always required?

  The need for additional connections depends only on the device, right?

  Automated static reasoning on setup code to determine the value of a
  "makes additional connections" flag feels intractable.  A runtime
  check could be feasible, though.

* Resource collision with board

  The device must connect to some fixed resource, but the board already
  connects something to it.  Without no_user, this should result in an
  error message of sorts, which is much better than the silent breakage
  above.  Whether the message makes any sense to the user is a different
  question.

  Unlike above, this isn't just about the device, it's about the device
  and the board.  Right now, one no_user has to make do for all boards.
  Hmm.

  A -device can also resource-collide with another -device.  But that's
  outside no_user's mission: -device *can* result in a working device
  there, just not in this particular combination.

  In a declarative world, we could automatically filter out devices who
  need resources that are never available on this board.  qdev/QOM is
  moving away from declarative.  Ideas?

>                          [and I don't think "this device
> can be added via the monitor but not the command line"
> counts as consistent or coherent...]

no_user applies equally to -device and device_add.

The command line additionally provides a number of settings the board
setup code may (or may not) use, and no_user has no effect on them.

Coherent enough for me.

>> Yes, the right thing to do would be to QOMify memory regions and
>> introduce pins, but that's a bit more than the amount of time I have now
>> for this.
>
> ...plus it means that when we do have these things we
> have to go round and identify the cases where no_user
> was set only because we didn't have the features before.
>
> My attitude here really is "yes, it's not great but it's
> been like this forever and we don't seem to have had a
> huge flood of user complaints, so better not to mess
> with it unless what you're doing is going to amount to
> some kind of cleanup".

Never underestimate users' capability to suffer quietly.