target/i386/arch_dump.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
This patch adds field with content of KERNEL_GS_BASE MSR to QEMU note in
ELF dump.
On Windows, if all vCPUs are running usermode tasks at the time the dump is
created, this can be helpful in the discovery of guest system structures
during conversion ELF dump to MEMORY.DMP dump.
Signed-off-by: Viktor Prutyanov <viktor.prutyanov@virtuozzo.com>
---
target/i386/arch_dump.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/i386/arch_dump.c b/target/i386/arch_dump.c
index 35b55fc..a702138 100644
--- a/target/i386/arch_dump.c
+++ b/target/i386/arch_dump.c
@@ -237,7 +237,7 @@ int x86_cpu_write_elf32_note(WriteCoreDumpFunction f, CPUState *cs,
* please count up QEMUCPUSTATE_VERSION if you have changed definition of
* QEMUCPUState, and modify the tools using this information accordingly.
*/
-#define QEMUCPUSTATE_VERSION (1)
+#define QEMUCPUSTATE_VERSION (2)
struct QEMUCPUSegment {
uint32_t selector;
@@ -258,6 +258,7 @@ struct QEMUCPUState {
QEMUCPUSegment cs, ds, es, fs, gs, ss;
QEMUCPUSegment ldt, tr, gdt, idt;
uint64_t cr[5];
+ uint64_t kernel_gs_base;
};
typedef struct QEMUCPUState QEMUCPUState;
@@ -315,6 +316,8 @@ static void qemu_get_cpustate(QEMUCPUState *s, CPUX86State *env)
s->cr[2] = env->cr[2];
s->cr[3] = env->cr[3];
s->cr[4] = env->cr[4];
+
+ s->kernel_gs_base = env->kernelgsbase;
}
static inline int cpu_write_qemu_note(WriteCoreDumpFunction f,
--
2.7.4
On Tue, Jul 10, 2018 at 06:21:09PM +0300, Viktor Prutyanov wrote: > This patch adds field with content of KERNEL_GS_BASE MSR to QEMU note in > ELF dump. > > On Windows, if all vCPUs are running usermode tasks at the time the dump is > created, this can be helpful in the discovery of guest system structures > during conversion ELF dump to MEMORY.DMP dump. > > Signed-off-by: Viktor Prutyanov <viktor.prutyanov@virtuozzo.com> > --- > target/i386/arch_dump.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/target/i386/arch_dump.c b/target/i386/arch_dump.c > index 35b55fc..a702138 100644 > --- a/target/i386/arch_dump.c > +++ b/target/i386/arch_dump.c > @@ -237,7 +237,7 @@ int x86_cpu_write_elf32_note(WriteCoreDumpFunction f, CPUState *cs, > * please count up QEMUCPUSTATE_VERSION if you have changed definition of > * QEMUCPUState, and modify the tools using this information accordingly. Where are the tools using this information, that need to be updated? Won't this break existing versions of those tools? Is the dump format and pointers to available tools documented somewhere? > */ > -#define QEMUCPUSTATE_VERSION (1) > +#define QEMUCPUSTATE_VERSION (2) > > struct QEMUCPUSegment { > uint32_t selector; > @@ -258,6 +258,7 @@ struct QEMUCPUState { > QEMUCPUSegment cs, ds, es, fs, gs, ss; > QEMUCPUSegment ldt, tr, gdt, idt; > uint64_t cr[5]; > + uint64_t kernel_gs_base; > }; > > typedef struct QEMUCPUState QEMUCPUState; > @@ -315,6 +316,8 @@ static void qemu_get_cpustate(QEMUCPUState *s, CPUX86State *env) > s->cr[2] = env->cr[2]; > s->cr[3] = env->cr[3]; > s->cr[4] = env->cr[4]; > + > + s->kernel_gs_base = env->kernelgsbase; > } > > static inline int cpu_write_qemu_note(WriteCoreDumpFunction f, > -- > 2.7.4 > -- Eduardo
On 11/07/2018 18:00, Eduardo Habkost wrote: >> @@ -237,7 +237,7 @@ int x86_cpu_write_elf32_note(WriteCoreDumpFunction f, CPUState *cs, >> * please count up QEMUCPUSTATE_VERSION if you have changed definition of >> * QEMUCPUState, and modify the tools using this information accordingly. > Where are the tools using this information, that need to be > updated? Won't this break existing versions of those tools? I think it's okay to _not_ change the version, since the format is backwards-compatible. Each QEMUCPUState struct is in a separate ELF note, and the presence of the new field is visible in both 1) the size of the note 2) the size field of the struct. Another possibility is to stash kernel_gs_base in cr[1]. This approach doesn't scale, but the word is otherwise unused if we want to make it super safe. I don't recommend it. Paolo > Is the dump format and pointers to available tools documented > somewhere? > >
On Wed, Jul 11, 2018 at 06:19:33PM +0200, Paolo Bonzini wrote: > On 11/07/2018 18:00, Eduardo Habkost wrote: > >> @@ -237,7 +237,7 @@ int x86_cpu_write_elf32_note(WriteCoreDumpFunction f, CPUState *cs, > >> * please count up QEMUCPUSTATE_VERSION if you have changed definition of > >> * QEMUCPUState, and modify the tools using this information accordingly. > > Where are the tools using this information, that need to be > > updated? Won't this break existing versions of those tools? > > I think it's okay to _not_ change the version, since the format is > backwards-compatible. Each QEMUCPUState struct is in a separate ELF > note, and the presence of the new field is visible in both 1) the size > of the note 2) the size field of the struct. If we do it, can we please make the documentation (or at least code comments, as documentation doesn't seem to exist) clearly state that the new field is optional in version 1? -- Eduardo
On Wed, 11 Jul 2018 13:00:25 -0300 Eduardo Habkost <ehabkost@redhat.com> wrote: > On Tue, Jul 10, 2018 at 06:21:09PM +0300, Viktor Prutyanov wrote: > > This patch adds field with content of KERNEL_GS_BASE MSR to QEMU > > note in ELF dump. > > > > On Windows, if all vCPUs are running usermode tasks at the time the > > dump is created, this can be helpful in the discovery of guest > > system structures during conversion ELF dump to MEMORY.DMP dump. > > > > Signed-off-by: Viktor Prutyanov <viktor.prutyanov@virtuozzo.com> > > --- > > target/i386/arch_dump.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/target/i386/arch_dump.c b/target/i386/arch_dump.c > > index 35b55fc..a702138 100644 > > --- a/target/i386/arch_dump.c > > +++ b/target/i386/arch_dump.c > > @@ -237,7 +237,7 @@ int > > x86_cpu_write_elf32_note(WriteCoreDumpFunction f, CPUState *cs, > > * please count up QEMUCPUSTATE_VERSION if you have changed > > definition of > > * QEMUCPUState, and modify the tools using this information > > accordingly. > > Where are the tools using this information, that need to be > updated? Won't this break existing versions of those tools? > > Is the dump format and pointers to available tools documented > somewhere? I hope that someone from community knows about those tools because I can't find such tools. > > > */ > > -#define QEMUCPUSTATE_VERSION (1) > > +#define QEMUCPUSTATE_VERSION (2) > > > > struct QEMUCPUSegment { > > uint32_t selector; > > @@ -258,6 +258,7 @@ struct QEMUCPUState { > > QEMUCPUSegment cs, ds, es, fs, gs, ss; > > QEMUCPUSegment ldt, tr, gdt, idt; > > uint64_t cr[5]; > > + uint64_t kernel_gs_base; > > }; > > > > typedef struct QEMUCPUState QEMUCPUState; > > @@ -315,6 +316,8 @@ static void qemu_get_cpustate(QEMUCPUState *s, > > CPUX86State *env) s->cr[2] = env->cr[2]; > > s->cr[3] = env->cr[3]; > > s->cr[4] = env->cr[4]; > > + > > + s->kernel_gs_base = env->kernelgsbase; > > } > > > > static inline int cpu_write_qemu_note(WriteCoreDumpFunction f, > > -- > > 2.7.4 > > >
On 11/07/2018 18:26, Viktor Prutyanov wrote: >> Where are the tools using this information, that need to be >> updated? Won't this break existing versions of those tools? >> >> Is the dump format and pointers to available tools documented >> somewhere? > I hope that someone from community knows about those tools because I > can't find such tools. > I checked crash, and it doesn't have any issue with QEMUCPUState that is bigger than what is currently in QEMU. It doesn't use anything but CR3 and IDT base. It also doesn't at all check the version! :O Paolo
© 2016 - 2024 Red Hat, Inc.