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

[Igor Mammedov]

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