PM
To: Cédric Le Goater
Cc: Kane Chen ; Philippe Mathieu-Daudé
; Peter Maydell ; Steven Lee
; Troy Lee ; Jamin Lin
; Andrew Jeffery
; Joel Stanley ; open
list:ASPEED BMCs ; open list:All patches CC here
; qemu-block ; Troy Lee
Subject: Configuring onboard devices, in particular memory contents (was:
[PAT
c Le Goater
> Cc: Kane Chen ; Philippe Mathieu-Daudé
> ; Peter Maydell ; Steven Lee
> ; Troy Lee ; Jamin Lin
> ; Andrew Jeffery
> ; Joel Stanley ; open
> list:ASPEED BMCs ; open list:All patches CC here
> ; qemu-block ; Troy Lee
>
> Subject: Configuring onboard devices, in
...
>
> However, the Aspeed SBC device is a platform device and it makes
> things more complex : it can not be created on the command line,
> it is directly created by the machine and the soc and passing
> device properties to specify a blockdev it is not possible :
>
> qemu-
On Sun, May 03, 2020 at 11:13:41PM +0100, Mark Cave-Ayland wrote:
> On 02/05/2020 06:47, Markus Armbruster wrote:
>
> > Mark Cave-Ayland writes:
> >
> >> On 30/04/2020 16:20, Markus Armbruster wrote:
> >>
> Ah I see now, these aliases are for individual properties rather than
> object
On 02/05/2020 06:47, Markus Armbruster wrote:
> Mark Cave-Ayland writes:
>
>> On 30/04/2020 16:20, Markus Armbruster wrote:
>>
Ah I see now, these aliases are for individual properties rather than
objects. What I
was trying to ask was if it were possible to have something like th
Mark Cave-Ayland writes:
> On 30/04/2020 16:20, Markus Armbruster wrote:
>
>>> Ah I see now, these aliases are for individual properties rather than
>>> objects. What I
>>> was trying to ask was if it were possible to have something like this:
>>>
>>> /machine (SS-5-machine)
>>> /builtin
>>>
On 30/04/2020 16:20, Markus Armbruster wrote:
>> Ah I see now, these aliases are for individual properties rather than
>> objects. What I
>> was trying to ask was if it were possible to have something like this:
>>
>> /machine (SS-5-machine)
>> /builtin
>> /nic0 -> link to "lance" device
>>
a-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
Daniel P. Berrangé writes:
> On Thu, Apr 30, 2020 at 11:45:40AM +0100, Peter Maydell wrote:
>> On Thu, 30 Apr 2020 at 11:34, Daniel P. Berrangé wrote:
>> > We "merely" need a new query language targetted to QEMU's qtree
>> > structure, which we can expose in the CLI that gives unique access
>> >
gt;>> 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
Daniel P. Berrangé writes:
> On Thu, Apr 30, 2020 at 12:03:12PM +0200, Markus Armbruster wrote:
>> Peter Maydell writes:
>>
>> > On Thu, 30 Apr 2020 at 08:09, Markus Armbruster wrote:
>> >> Our means to configure onboard devices are weak. We sidestepped this
>> >> for isa-fdc by taking it off
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 tempt
On 30/04/2020 11:45, Peter Maydell wrote:
> On Thu, 30 Apr 2020 at 11:34, Daniel P. Berrangé wrote:
>> We "merely" need a new query language targetted to QEMU's qtree
>> structure, which we can expose in the CLI that gives unique access
>> to every possible property.
>
> Past resistance to this
On Thu, Apr 30, 2020 at 11:45:40AM +0100, Peter Maydell wrote:
> On Thu, 30 Apr 2020 at 11:34, Daniel P. Berrangé wrote:
> > We "merely" need a new query language targetted to QEMU's qtree
> > structure, which we can expose in the CLI that gives unique access
> > to every possible property.
>
> P
On Thu, 30 Apr 2020 at 11:34, Daniel P. Berrangé wrote:
> We "merely" need a new query language targetted to QEMU's qtree
> structure, which we can expose in the CLI that gives unique access
> to every possible property.
Past resistance to this has been grounded in not wanting to
expose the exact
> 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
> int
On Thu, Apr 30, 2020 at 12:03:12PM +0200, Markus Armbruster wrote:
> Peter Maydell writes:
>
> > On Thu, 30 Apr 2020 at 08:09, Markus Armbruster 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 wo
.
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?
18 matches
Mail list logo
