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

[Igor Mammedov <imammedo@redhat.com>]

On 05/24/2012 04:01 PM, Andreas Färber wrote:
> 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.
Thanks for the link and job you've done on cpus. It looks much smaller/cleaner
than when I've attempted to do it several months ago, that was big and ugly hack.

> If we created a TYPE_X86_CPU with -device, we would not get an APIC
> attached currently.
That is why I'm adding intermediate cpu_model property for now, so that
it would possible to create TYPE_X86_CPU and set cpu_model property which
would create APIC if cpu advertises it.
Then when cpu subclasses implemented and possibly cpu features are converted
to properties, we could move APIC creation to a more appropriate place and
drop cpu_model property.

> 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
Yep, that would complicate things. I don't like it for x86 because
container device would be just dumb chip packaging if we try to match it
with a real hardware and as you say it would be difficult to use it.

> with SoCs (the sh7750 realize discussion).
could
>
> Andreas
>

-- 
-----
  Igor