[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] X86/HMP: Expose x86 model specific registers vi

From: Julian Kirsch
Subject: Re: [Qemu-devel] [PATCH] X86/HMP: Expose x86 model specific registers via human monitor
Date: Wed, 8 Mar 2017 12:34:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 08.03.2017 04:09, Richard Henderson wrote:
> On 03/08/2017 11:16 AM, Julian Kirsch wrote:
>> For instance, many modern x86-64 operating systems maintain access to 
>> internal
>> data structures via the MSR_GSBASE/MSR_KERNELGSBASE MSRs. Giving
>> introspection utilities (such as a remotely attached gdb) a way of
>> accessing these registers improves analysis results drastically.
> If this is just for gdb, then we should provide access via the normal gdbstub,
> plus appropriate xml files.  There are plenty of examples of this for other 
> cpus.
> r~

Hi Richard,

I considered adding this functionality to the gdbstub.
However, my understanding of this approach is that it would make the patch
dependent on a particular (newly added) xml file being present at the gdb client
side. The current solution avoids this by letting gdb clients simply use the
newly introduced commands by means of the "monitor" command already built into 
While I appreciate that this is a bit hacky, I, on the other hand, cannot come
up with any good setting in which a normal user space gdb client might need
access to the MSRs except for the qemu one, such that adding a new xml file to
gdb just for this special use case might be difficult to communicate on the
gdb-devel list.
Another question arising in this context would also consider what and how many
MSRs the xml file(s) should contain, including the logic to provide distinct
architectural MSRs for 32 and 64 bit targets. I hope you can see this approach
incurring non-negligible planning overhead with the end result providing same or
even less functionality.
Nevertheless, I'd move the functionality over to the gdbstub and bug on
gdb-devel to include a new (minimal) xml file, if it was the only way to get an
according patch upstream in qemu.


reply via email to

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