Re: [Xen-devel] [PATCH 2/3] x86: also show FS/GS base addresses when dumping registers

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/10/17 15:23, Jan Beulich wrote:
> Their state may be important to figure the reason for a crash. To not
> further grow duplicate code, break out a helper function.
>
> I realize that (ab)using the control register array here may not be
> considered the nicest solution, but it seems easier (and less overall
> overhead) to do so compared to the alternative of introducing another
> helper structure.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Printing this information is definitely a good idea.

Reviewed-by Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, with two
observations.

>
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -36,6 +36,21 @@ static void print_xen_info(void)
>  
>  enum context { CTXT_hypervisor, CTXT_pv_guest, CTXT_hvm_guest };
>  

/* (ab)use crs[5..7] for fs/gs bases. */

?  A comment to this effect at least makes it clear that this is
intentional.

> +static void read_registers(struct cpu_user_regs *regs, unsigned long crs[8])
> +{
> +    crs[0] = read_cr0();
> +    crs[2] = read_cr2();
> +    crs[3] = read_cr3();
> +    crs[4] = read_cr4();
> +    regs->ds = read_sreg(ds);
> +    regs->es = read_sreg(es);
> +    regs->fs = read_sreg(fs);
> +    regs->gs = read_sreg(gs);
> +    crs[5] = rdfsbase();
> +    crs[6] = rdgsbase();
> +    rdmsrl(MSR_SHADOW_GS_BASE, crs[7]);
> +}
> +
>  static void _show_registers(
>      const struct cpu_user_regs *regs, unsigned long crs[8],
>      enum context context, const struct vcpu *v)
> @@ -146,6 +160,7 @@ void show_registers(const struct cpu_use
>  void vcpu_show_registers(const struct vcpu *v)
>  {
>      const struct cpu_user_regs *regs = &v->arch.user_regs;
> +    bool_t kernel = guest_kernel_mode(v, regs);

Forward porting mishap?

>      unsigned long crs[8];
>  
>      /* Only handle PV guests for now */
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel