qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Configuring onboard devices (was: Failing property setters + hardwired d


From: Markus Armbruster
Subject: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day)
Date: Thu, 30 Apr 2020 12:03:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On Thu, 30 Apr 2020 at 08:09, Markus Armbruster <address@hidden> wrote:
>> Our means to configure onboard devices are weak.  We sidestepped this
>> for isa-fdc by taking it off the board, and thus make -device work.
>
> This seems to be a general dynamic: the x86 pc machine works
> via -device options (or is changed so it can work that way);
> and then people propose dropping/deprecating/etc the config
> options that work with onboard devices, without providing
> clear solutions/instructions on how the command line needs
> to change/etc for the mass of boards which are not the x86
> pc machine and which do have a lot of onboard devices which
> can't be handled via -device.
>
> So my gut reaction to the "we should deprecate -global"
> suggestions in this thread was a bit "here we go again"...
> What works for x86 or even "what is sufficient for libvirt"
> doesn't necessarily cover all the cases.

Such shortsighted proposals have been made, but don't think it's what
we're doing here.

You're 100% right in that we do need to configure onboard devices.
-global is a terrible way to do it, though: it applies to *all* devices
of a kind.  What if the board has more than one?  What if the can add
more?

Taking onboard devices off the board can occasionally sidestep the
issue.  For isa-fdc, we genuinely *wanted* to take the damn thing off,
because all it did for most users was provide them with VENOM.  Not
needing -global for it anymore was just a nice bonus.

Taking onboard devices off just to reduce the device configuration
problem to a solved one, namely -device, may be tempting (it was to me),
but it's too intrusive to be practical at scale.

Adding machine properties that alias onboard device properties is less
intrusive.  The ones I added were still a lot of work.

Configuring onboard devices via machine properties restricts property
access to the ones we added to the machine.  This differs from pluggable
devices, where users can access all properties.

Any better ideas for letting users configure onboard devices?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]