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

Re: [Xen-devel] [PATCH] xen/x86: Identify which vcpu's CR4 is being badly modified



>>> On 25.03.14 at 20:40, <andrew.cooper3@xxxxxxxxxx> wrote:
> When the toolstack is setting vcpu state on behalf of a migrating guest, the
> domain/vcpu reference from gdprintk() identifies the toolstack, not the
> affected domain.
> 
> After this change, the error looks more like:
> 
>   domain.c:632:d0v3 Attempt to change d1v0's CR4 flags 00002660 -> 01875000

And is the leading d0v3 really useful here in any way? I'd really like to
see unmotivated uses of gdprintk() replaced by printk(XENLOG_G_...).

Jan

> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> CC: Keir Fraser <keir@xxxxxxx>
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> ---
>  xen/arch/x86/domain.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index b48f2dc..59e2729 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -652,8 +652,8 @@ unsigned long pv_guest_cr4_fixup(const struct vcpu *v, 
> unsigned long guest_cr4)
>  
>      if ( (guest_cr4 & hv_cr4_mask) != (hv_cr4 & hv_cr4_mask) )
>          gdprintk(XENLOG_WARNING,
> -                 "Attempt to change CR4 flags %08lx -> %08lx\n",
> -                 hv_cr4, guest_cr4);
> +                 "Attempt to change %pv's CR4 flags %08lx -> %08lx\n",
> +                 v, hv_cr4, guest_cr4);
>  
>      return (hv_cr4 & hv_cr4_mask) | (guest_cr4 & ~hv_cr4_mask);
>  }
> -- 
> 1.7.10.4




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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.