qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] qapi/x86: add control registers to query-cpus


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH] qapi/x86: add control registers to query-cpus
Date: Fri, 25 Jan 2013 14:08:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2

Am 25.01.2013 13:45, schrieb Luiz Capitulino:
> On Fri, 25 Jan 2013 13:38:18 +0100
> Paolo Bonzini <address@hidden> wrote:
> 
>> Il 25/01/2013 13:34, Eduardo Habkost ha scritto:
>>> We already have CPU QOM objects, we just need to add a
>>> methods/properties so each per-architecture subclass will implement
>>> what's necessary for the command.
>>>
>>> We could go even further: just use the qom-* commands. Then if there's
>>> some set of registers we really want to expose to the outside, just add
>>> them as properties to the CPU object.
>>
>> Makes sense.
> 
> Oh, agreed. That would be a lot better and I didn't even consider this.
> 
> What's the status of the CPU work on QOM? Would it be possible to expose
> registers info already or some work is still needed? If work is needed,
> what's missing?

Should be possible since v1.1. :)

I made an demo for ARM once but that didn't get applied at the time due
to CP15 rework. Elsewhere it's waiting for creative volunteers.

Similarly, my invasive CPUState refactoring series aim at making generic
"halted" etc. properties available for introspection.

We just need to be aware that inspecting register values is one thing,
but that letting QMP qom-set arbitrary registers during runtime could
cause unpredictable issues. Checks on dev->realized could be added as
precaution (cf. qdev static properties).

The work needed mentioned elsewhere was that users need to know which
object to qom-get properties on. We thus need to
object_property_add_child() the CPUs somewhere, and this is going to be
machine-specific as opposed to target-specific as opposed to generic. ;)
If needed, we could (given any such paths) have generic link properties.

Regards,
Andreas

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



reply via email to

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