All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-devel@nongnu.org, "H. Peter Anvin" <hpa@linux.intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	"Richard W. M. Jones" <rjones@redhat.com>
Subject: [Qemu-devel] Re: qdev: Some ISA devices don't handle second instantiation gracefully
Date: Tue, 12 Oct 2010 16:52:57 +0200	[thread overview]
Message-ID: <4CB47649.6020104@redhat.com> (raw)
In-Reply-To: <3D29523C-48CB-41B3-BCBE-901EAEE2779E@suse.de>

   Hi,

>> They call register_ioport_write(), which aborts via hw_error() when
>> the port is already in use.  This is okay for non-configurable
>> parts of a board emulation, but not okay for a qdev device, unless
>> it has no_user set.
>>
>> Related: when isa_init_irq() finds the requested IRQ already in
>> use, it fails with exit(1).  Maybe register_ioport_write()&
>> friends should do that as well.
>>
>> Or maybe qdev device models should have an "at most one" flag.
>
> There can be multiple of these devices on different ports, but a
> single PIO port can still only be managed by a single device. By
> creating the same device twice without giving it a PIO option, you
> put two devices on the same PIO port which can't work.
>
> As this is a configuration error, I'd guess the best way to deal with
> it is to return an error for register_ioport which makes the qdev
> init fail. Then the respective instantiator can do what is fit. If
> the device is passed in on the cmdline, it'd refuse to create the
> machine and exit. If it's a hotplug event, it would fail to hotplug.

ISA isn't hotpluggable anyway, so just exiting unconditionally here 
isn't a big issue IMHO as effectively only ISA devices are affected by 
this.

register_ioport_write() should exit with a more useful error message 
here instead of calling hw_error() though.

We could also make register_ioport_write() pass up an error and have all 
callers check that.  Not sure this is worth the trouble though.

An "at most one" flag might make sense.  But on a PC all ISA devices 
which exist only once at a fixed address (keyboard, floppy, ...) are 
automagically created so no_user does the trick here.  The other ones 
(serial, ne2k_isa, ...) actually can be created multiple times if you 
configure different iobases using properties.

Dunno what kind of device apple-smc is ...

cheers,
   Gerd

  reply	other threads:[~2010-10-12 14:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-12 12:50 [Qemu-devel] isa-applesmc doesn't handle second instantiation gracefully Markus Armbruster
2010-10-12 12:57 ` [Qemu-devel] " Alexander Graf
2010-10-12 13:00 ` [Qemu-devel] qdev: Some ISA devices don't handle second instantiation gracefully (was: isa-applesmc doesn't handle second instantiation gracefully) Markus Armbruster
2010-10-12 13:04   ` [Qemu-devel] " Alexander Graf
2010-10-12 14:52     ` Gerd Hoffmann [this message]
2010-10-12 13:27   ` [Qemu-devel] qdev: Some ISA devices don't handle second instantiation gracefully Anthony Liguori
2010-10-12 13:54     ` Markus Armbruster
2010-10-12 14:24       ` Anthony Liguori
2010-10-13 12:47   ` [Qemu-devel] Re: qdev: Some ISA devices don't handle second instantiation gracefully (was: isa-applesmc doesn't handle second instantiation gracefully) Richard W.M. Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CB47649.6020104@redhat.com \
    --to=kraxel@redhat.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=hpa@linux.intel.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.