Re: [Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new

[Andreas Färber]

Am 24.05.2012 15:48, schrieb Igor Mammedov:
> On 05/24/2012 03:04 PM, Anthony Liguori wrote:
>>
>> I'm not sure how I feel about this. I never intended for a user to be
>> able to create objects that were arbitrary children of other objects.
>>
>> In some ways, I think this is almost too powerful of an interface to
>> expose to users. I like things like device_add() better that only
>> creates objects
>> of TYPE_DEVICE that are always in /peripherial.
>>
>> For block, we'd have a similar interface that always created objects
>> of TYPE_BLOCK_DRIVER and put them in /block.
> 
> Will we have a special cases for every incompatible device types that is
> going to be hot-plugged via device_add monitor command?
> 
> For CPUs my thoughts were moving in opposite direction, like:
>  - make possible to create and initialize CPU as a regular QOM object
>  - hack qdev_device_add() to allow not only TYPE_DEVICE to be created there
> 
> There are patches out there that make cpu a child of /machine at board
> level.
> But for hot-added objects parent could be specified as a property
> or knowledge about parent hard-coded inside of object itself or
> hard-coded in device_add().
> Which one of them likely to be adopted?

For system emulation I am working towards making the CPU a device so
that we can reuse common device infrastructure:

https://github.com/afaerber/qemu-cpu/commits/qom-cpu-dev

That's independent of what QMP commands we provide to the user though.

If we created a TYPE_X86_CPU with -device, we would not get an APIC
attached currently.
If however we created a container object as suggested by Peter and
others before, then we cannot as easily modify properties of the child
objects (family, vendor, etc. of CPU) via command line. Same issue as
with SoCs (the sh7750 realize discussion).

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg