[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Configuring onboard devices
From: |
Markus Armbruster |
Subject: |
Re: Configuring onboard devices |
Date: |
Thu, 30 Apr 2020 16:11:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Mark Cave-Ayland <address@hidden> writes:
> On 30/04/2020 11:03, Markus Armbruster wrote:
>> 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?
>
> Is it possible to let machine owners add alias properties to the machine
> object
> referencing in-built devices? I could then instantiate my on-board nic in the
> machine
> init() function, and then use object_property_add_alias() to add a "nic0"
> alias on
> the machine that can be used to wire it up to a netdev using the command line.
Have a look at hw/arm/virt.c's virt_flash_create(), from commit
e0561e60f1 "hw/arm/virt: Support firmware configuration with -blockdev".
It adds machine properties "pflash0" and "pflash1" as aliases for the
onboard flash memory devices' property "drive".
Does this answer your question?
- Failing property setters + hardwired devices + -global = a bad day, Markus Armbruster, 2020/04/29
- Re: Failing property setters + hardwired devices + -global = a bad day, Paolo Bonzini, 2020/04/29
- Re: Failing property setters + hardwired devices + -global = a bad day, Daniel P . Berrangé, 2020/04/29
- Re: Failing property setters + hardwired devices + -global = a bad day, Markus Armbruster, 2020/04/30
- Re: Failing property setters + hardwired devices + -global = a bad day, Peter Maydell, 2020/04/30
- Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Markus Armbruster, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Mark Cave-Ayland, 2020/04/30
- Re: Configuring onboard devices,
Markus Armbruster <=
- Re: Configuring onboard devices, Mark Cave-Ayland, 2020/04/30
- Re: Configuring onboard devices, Markus Armbruster, 2020/04/30
- Re: Configuring onboard devices, Mark Cave-Ayland, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Daniel P . Berrangé, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Peter Maydell, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Daniel P . Berrangé, 2020/04/30
- Re: Configuring onboard devices, Markus Armbruster, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Mark Cave-Ayland, 2020/04/30
- Re: Configuring onboard devices, Markus Armbruster, 2020/04/30