[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new
Date: Thu, 24 May 2012 17:33:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

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
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:


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 

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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]