From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDWXD-00013I-QV for qemu-devel@nongnu.org; Thu, 07 Mar 2013 03:50:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDWXA-0005Ks-T0 for qemu-devel@nongnu.org; Thu, 07 Mar 2013 03:50:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDWXA-0005KO-FI for qemu-devel@nongnu.org; Thu, 07 Mar 2013 03:50:40 -0500 From: Markus Armbruster References: <1362418348-27398-1-git-send-email-pbonzini@redhat.com> <51350131.1070703@redhat.com> Date: Thu, 07 Mar 2013 09:48:07 +0100 In-Reply-To: (Peter Maydell's message of "Tue, 5 Mar 2013 07:22:19 +0800") Message-ID: <874ngnsiig.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , Anthony Liguori , qemu-devel@nongnu.org Peter Maydell writes: > On 5 March 2013 04:16, Paolo Bonzini 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.