All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xen/x86: Identify which vcpu's CR4 is being badly modified
@ 2014-03-25 19:40 Andrew Cooper
  2014-03-26 13:17 ` Jan Beulich
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cooper @ 2014-03-25 19:40 UTC (permalink / raw)
  To: Xen-devel; +Cc: Andrew Cooper, Keir Fraser, Jan Beulich

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

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
---
 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

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen/x86: Identify which vcpu's CR4 is being badly modified
  2014-03-25 19:40 [PATCH] xen/x86: Identify which vcpu's CR4 is being badly modified Andrew Cooper
@ 2014-03-26 13:17 ` Jan Beulich
  2014-03-26 13:30   ` Andrew Cooper
  0 siblings, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2014-03-26 13:17 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Keir Fraser, Xen-devel

>>> On 25.03.14 at 20:40, <andrew.cooper3@citrix.com> 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@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> ---
>  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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen/x86: Identify which vcpu's CR4 is being badly modified
  2014-03-26 13:17 ` Jan Beulich
@ 2014-03-26 13:30   ` Andrew Cooper
  2014-03-26 13:38     ` Jan Beulich
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cooper @ 2014-03-26 13:30 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Keir Fraser, Xen-devel

On 26/03/14 13:17, Jan Beulich wrote:
>>>> On 25.03.14 at 20:40, <andrew.cooper3@citrix.com> 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

Personally, I find it useful to distinguish between "the toolstack tried
something" and "a guest tried something", although the file/line
reference is quite useless.

Perhaps printk(XENLOG_G_WARNING "%pv attempted to change %pv's CR4 flags
...", current, v ....) ?

~Andrew

>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Keir Fraser <keir@xen.org>
>> CC: Jan Beulich <JBeulich@suse.com>
>> ---
>>  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
>
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen/x86: Identify which vcpu's CR4 is being badly modified
  2014-03-26 13:30   ` Andrew Cooper
@ 2014-03-26 13:38     ` Jan Beulich
  2014-03-26 14:00       ` [PATCH v2] " Andrew Cooper
  2014-03-26 14:24       ` [PATCH v3] " Andrew Cooper
  0 siblings, 2 replies; 8+ messages in thread
From: Jan Beulich @ 2014-03-26 13:38 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Keir Fraser, Xen-devel

>>> On 26.03.14 at 14:30, <andrew.cooper3@citrix.com> wrote:
> On 26/03/14 13:17, Jan Beulich wrote:
>>>>> On 25.03.14 at 20:40, <andrew.cooper3@citrix.com> 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
> 
> Personally, I find it useful to distinguish between "the toolstack tried
> something" and "a guest tried something", although the file/line
> reference is quite useless.
> 
> Perhaps printk(XENLOG_G_WARNING "%pv attempted to change %pv's CR4 flags
> ...", current, v ....) ?

Which vCPU this was being done on is of no interest at all; I can see
the originating domain being useful to know.

Jan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH v2] xen/x86: Identify which vcpu's CR4 is being badly modified
  2014-03-26 13:38     ` Jan Beulich
@ 2014-03-26 14:00       ` Andrew Cooper
  2014-03-26 14:22         ` Andrew Cooper
  2014-03-26 14:25         ` Jan Beulich
  2014-03-26 14:24       ` [PATCH v3] " Andrew Cooper
  1 sibling, 2 replies; 8+ messages in thread
From: Andrew Cooper @ 2014-03-26 14:00 UTC (permalink / raw)
  To: Xen-devel; +Cc: Andrew Cooper, Keir Fraser, Jan Beulich

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:

  (XEN) d0 attempted to change d6v0's CR4 flags 00002660 -> 01876000

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>

---
v2: gdprintk -> printk, drop current's vcpu reference.
---
 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

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] xen/x86: Identify which vcpu's CR4 is being badly modified
  2014-03-26 14:00       ` [PATCH v2] " Andrew Cooper
@ 2014-03-26 14:22         ` Andrew Cooper
  2014-03-26 14:25         ` Jan Beulich
  1 sibling, 0 replies; 8+ messages in thread
From: Andrew Cooper @ 2014-03-26 14:22 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Keir Fraser, Jan Beulich, Xen-devel

Please ignore this - I appear to have gained the new patch message with
the old patch.  I shall try to correct.

~Andrew

On 26/03/14 14:00, Andrew Cooper 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:
>
>   (XEN) d0 attempted to change d6v0's CR4 flags 00002660 -> 01876000
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
>
> ---
> v2: gdprintk -> printk, drop current's vcpu reference.
> ---
>  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);
>  }

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH v3] xen/x86: Identify which vcpu's CR4 is being badly modified
  2014-03-26 13:38     ` Jan Beulich
  2014-03-26 14:00       ` [PATCH v2] " Andrew Cooper
@ 2014-03-26 14:24       ` Andrew Cooper
  1 sibling, 0 replies; 8+ messages in thread
From: Andrew Cooper @ 2014-03-26 14:24 UTC (permalink / raw)
  To: Xen-devel; +Cc: Andrew Cooper, Keir Fraser, Jan Beulich

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:

  (XEN) d0 attempted to change d6v0's CR4 flags 00002660 -> 01876000

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>

---
v3: Send correct patch.
v2: gdprintk -> printk, drop current's vcpu reference.
---
 xen/arch/x86/domain.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index b48f2dc..796b775 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -651,9 +651,9 @@ unsigned long pv_guest_cr4_fixup(const struct vcpu *v, unsigned long guest_cr4)
         hv_cr4_mask &= ~X86_CR4_OSXSAVE;
 
     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);
+        printk(XENLOG_G_WARNING
+               "d%d attempted to change %pv's CR4 flags %08lx -> %08lx\n",
+               current->domain->domain_id, v, hv_cr4, guest_cr4);
 
     return (hv_cr4 & hv_cr4_mask) | (guest_cr4 & ~hv_cr4_mask);
 }
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] xen/x86: Identify which vcpu's CR4 is being badly modified
  2014-03-26 14:00       ` [PATCH v2] " Andrew Cooper
  2014-03-26 14:22         ` Andrew Cooper
@ 2014-03-26 14:25         ` Jan Beulich
  1 sibling, 0 replies; 8+ messages in thread
From: Jan Beulich @ 2014-03-26 14:25 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Keir Fraser, Xen-devel

>>> On 26.03.14 at 15:00, <andrew.cooper3@citrix.com> 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:
> 
>   (XEN) d0 attempted to change d6v0's CR4 flags 00002660 -> 01876000
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> 
> ---
> v2: gdprintk -> printk, drop current's vcpu reference.

Unrefreshed patch?

Jan

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2014-03-26 14:25 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-25 19:40 [PATCH] xen/x86: Identify which vcpu's CR4 is being badly modified Andrew Cooper
2014-03-26 13:17 ` Jan Beulich
2014-03-26 13:30   ` Andrew Cooper
2014-03-26 13:38     ` Jan Beulich
2014-03-26 14:00       ` [PATCH v2] " Andrew Cooper
2014-03-26 14:22         ` Andrew Cooper
2014-03-26 14:25         ` Jan Beulich
2014-03-26 14:24       ` [PATCH v3] " Andrew Cooper

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.