Am 25.01.2013 13:45, schrieb Luiz Capitulino: > On Fri, 25 Jan 2013 13:38:18 +0100 > Paolo Bonzini <pbonz...@redhat.com> 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
