On Fri, Jan 25, 2013 at 8:08 AM, Andreas Färber <afaer...@suse.de> wrote: > 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).
I just want to inspect register values. The implementation of qom-set for CPU registers could just always fail. > 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. I like this QOM approach: there's no point in coming up with a bunch of per-arch data structures and queries when CPUs are already represented in QOM. When I have some time, I'll submit a patch for the QOM approach. On Fri, Jan 25, 2013 at 7:51 AM, Andreas Färber <afaer...@suse.de> wrote: > Is there a particular release this feature is being requested for? We want our product to work with stock qemu-1.4.0 (currently, Gridcentric ships QEMU along with a couple of patches). So I had hoped this would get into qemu-1.4.0. However, since doing this *right* (i.e. using QOM) isn't such a small patch, we aren't holding our breath for this feature making it into 1.4 (i.e., I probably won't get around to submitting the QOM patch in time). Since I submitted this patch, we've decided to glean the information by parsing HMP's 'info registers', which is available in stock QEMU. So, from our perspective, including registers in QMP in 1.4 isn't important. However, it would be nice to spare other people the joy (pain?) of parsing HMP in the future ;-)
