[Qemu-devel] [PATCH] dump: add kernel_gs_base to QEMU CPU state

[Qemu-devel] [PATCH] dump: add kernel_gs_base to QEMU CPU state

[Viktor Prutyanov]

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

Re: [Qemu-devel] [PATCH] dump: add kernel_gs_base to QEMU CPU state

[Eduardo Habkost]

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

Re: [Qemu-devel] [PATCH] dump: add kernel_gs_base to QEMU CPU state

[Paolo Bonzini]

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?
> 
> 

Re: [Qemu-devel] [PATCH] dump: add kernel_gs_base to QEMU CPU state

[Viktor Prutyanov]

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
> >   
> 

Re: [Qemu-devel] [PATCH] dump: add kernel_gs_base to QEMU CPU state

[Paolo Bonzini]

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

Re: [Qemu-devel] [PATCH] dump: add kernel_gs_base to QEMU CPU state

[Eduardo Habkost]

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