All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-trivial@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] hw/input/pckbd: The i8042 device should not be user_creatable
Date: Thu, 04 Apr 2019 18:30:43 +0200	[thread overview]
Message-ID: <87lg0p4tsc.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <3ba3c765-589f-4c0a-38dc-d9126f515e7b@redhat.com> (Thomas Huth's message of "Thu, 4 Apr 2019 16:19:27 +0200")

Thomas Huth <thuth@redhat.com> writes:

> On 04/04/2019 15.29, Philippe Mathieu-Daudé wrote:
>> On 4/4/19 12:07 PM, Paolo Bonzini wrote:
>>> On 04/04/19 09:14, Thomas Huth wrote:
>>>> The i8042 PS/2 controller is part of the chipset on the motherboard.
>>>> It is instantiated by the machine init code, and it does not make sense
>>>> to allow the user to plug an additional i8042 in any of the free ISA slots.
>>>> Thus let's mark the device with user_creatable = false.
>>>>
>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>> ---
>>>>  hw/input/pckbd.c | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>
>>> user_creatable is not for devices that are not pluggable in real life;
>>> it is for devices that crash QEMU (!) or always fail if plugged by the user.
>
> ... hmm, but presenting devices to the user that are clearly not
> intended for direct use is also not very nice, is it?

Maybe, but hiding them should be separate from marking devices that
still defeat device_add.

In the ideal world, we'd be able to start with an empty board, then
build a machine with by wiring together devices.  Say like use
device_add to create and plug into parent bus, qom-set link properties
to create additional wires.

Plenty of devices fail at the device_add stage, or require additional
wiring by code.  These are marked not user_creatable.

See also commit e90f2a8c3e0e677eeea46a9b401c3f98425ffa37.

>>> So the question to ask is: would it make sense, and especially work, to
>>> add an i8042 to machines that do have an ISA bridge (for example the Alpha?)

Scratch the "would it make sense" part, keep the "would it work" part.

> I don't think so. It is a device that is supposed to be part of the
> chipset on the motherboard, so operating systems certainly don't know
> how to use this device on other machines.
>
> And at least some part of the device have to be set up in source code
> (see e.g. i8042_setup_a20_line() ...).

If (and only if) the parts that need code are essential to the
functioning the device, it should be marked not user_creatable.

>> Correct me if I'm wrong but it seems no machine directly use a 8042 on a
>> ISA bus, it is always part of a SuperIO chipset. It is not reflected in
>> the code (in particular the X86 machines, but I'm working on cleaning this).

Known issue: we model a bunch of x86 devices as ISA devices, even though
they're actually part of a super i/o device connected via LPC bus.

[...]

  reply	other threads:[~2019-04-04 16:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04  7:14 [Qemu-devel] [PATCH] hw/input/pckbd: The i8042 device should not be user_creatable Thomas Huth
2019-04-04 10:07 ` Paolo Bonzini
2019-04-04 13:29   ` Philippe Mathieu-Daudé
2019-04-04 14:19     ` Thomas Huth
2019-04-04 16:30       ` Markus Armbruster [this message]
2019-04-05 10:57         ` Thomas Huth
2019-04-05 10:57           ` Thomas Huth
2019-04-08  6:29           ` Markus Armbruster
2019-04-04 16:40       ` Philippe Mathieu-Daudé
2019-04-04 20:49         ` Philippe Mathieu-Daudé
2019-04-05  7:58           ` Paolo Bonzini
2019-04-08  6:01             ` Markus Armbruster
2019-04-08  6:01               ` Markus Armbruster

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=87lg0p4tsc.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=thuth@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.