RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-17 Thread Alex Williamson 
On Mon, 2006-10-16 at 21:00 +0900, Kouya SHIMURA wrote:
 Hi Alex,
 
 Could you apply an attached patch?
 There is no difference between Anthony's patch and my old one
 because all vcpus are stopped completely.

   Ok, applied.  Thanks,

Alex

-- 
Alex Williamson HP Open Source  Linux Org.


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-16 Thread Kouya SHIMURA 
Hi Alex,

Could you apply an attached patch?
There is no difference between Anthony's patch and my old one
because all vcpus are stopped completely.

Thanks,
Kouya

Signed-off-by: Kouya SHIMURA [EMAIL PROTECTED]
Signed-off-by: Anthony Xu  [EMAIL PROTECTED] 

diff -r fcd746cf4647 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cSat Oct 14 18:10:08 2006 -0600
+++ b/xen/arch/ia64/xen/domain.cMon Oct 16 20:42:45 2006 +0900
@@ -342,7 +342,7 @@ void relinquish_vcpu_resources(struct vc
 
 void free_vcpu_struct(struct vcpu *v)
 {
-   if (VMX_DOMAIN(v))
+   if (v-domain-arch.is_vti)
vmx_relinquish_vcpu_resources(v);
else
relinquish_vcpu_resources(v);

Xu, Anthony writes:
  Hi Kouya,
  
  Good catch!
  
  I think the root cause is, when VTI-domain is destroyed, vti-flag in vcpu 
  structure is not set while vti-flag in domain structure is set, so XEN think 
  of this vcpu as domU vcpu by mistake, then issue appears,
  
  Yes, your patch can fix this issue, but seems it may incur memory leak. 
  Maybe following small modification is needed.
  
  Anthony
  
  --- a/xen/arch/ia64/xen/domain.c Sun Oct 08 18:55:12 2006 -0600
  +++ b/xen/arch/ia64/xen/domain.c Tue Oct 10 19:06:44 2006 +0900
  @@ -341,9 +341,11 @@ void relinquish_vcpu_resources(struct vc
   
   void free_vcpu_struct(struct vcpu *v)
   {
  -if (VMX_DOMAIN(v))
  -vmx_relinquish_vcpu_resources(v);
  -else
  +if (v-domain-arch.is_vti) {
  +vmx_relinquish_vcpu_resources(v);
  +} else
   relinquish_vcpu_resources(v);
   
   free_xenheap_pages(v, KERNEL_STACK_SIZE_ORDER);
  
  
  
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Kouya SHIMURA
  Sent: 2006年10月10日 18:31
  To: xen-ia64-devel@lists.xensource.com
  Subject: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed
  
  Hi,
  
  I got the following panic message when I destroyed a domvti which has
  2 vcpus and 2nd vcpu is not booted yet. This panic occurs from cset 11745.
  Attached patch fixes it.
  
  (XEN) ia64_fault, vector=0x1e, ifa=0xf414802a, 
  iip=0xf4030ef0, i
  psr=0x121008226018, isr=0x0a06
  (XEN) Unaligned Reference.
  (XEN) d 0xf7d5c080 domid 0
  (XEN) vcpu 0xf7d3 vcpu 0
  (XEN)
  (XEN) CPU 1
  (XEN) psr : 121008226018 ifs : 840b ip  : 
  [f4030ef1]
  (XEN) ip is at free_domheap_pages+0x131/0x7f0
  (XEN) unat:  pfs : 0206 rsc : 0003
  (XEN) rnat: 0206 bsps: 0003 pr  : 05569aab
  (XEN) ldrs:  ccv :  fpsr: 0009804c0270033f
  (XEN) csd :  ssd : 
  (XEN) b0  : f4074930 b6  : f4034130 b7  : a00100067a90
  (XEN) f6  : 1003e000670a4 f7  : 1003ecccd
  (XEN) f8  : 1003e000c2d06 f9  : 10001c000
  (XEN) f10 : 100099c1aaa0e9000 f11 : 1003e04e0
  (XEN) r1  : f4316d10 r2  :  r3  : f7d37fe8
  (XEN) r8  : 0040 r9  :  r10 : 
  (XEN) r11 : 0009804c0270033f r12 : f7d37930 r13 : f7d3
  (XEN) r14 :  r15 : 00019c29 r16 : 0001
  (XEN) r17 : f7ff7510 r18 : f7a0eb00 r19 : f7ff7500
  (XEN) r20 : f7a0eb08 r21 : f414803a r22 : f414802a
  (XEN) r23 : f40e8200 r24 : 001008226018 r25 : f411f420
  (XEN) r26 : f4119300 r27 :  r28 : fff1
  (XEN) r29 : 8000 r30 : 0001 r31 : f414802a
  (XEN)
  (XEN) Call Trace:
  (XEN)  [f4099b40] show_stack+0x80/0xa0
  (XEN) sp=f7d37560 
  bsp=f7d310d0
  (XEN)  [f406b050] ia64_fault+0x280/0x670
  (XEN) sp=f7d37730 
  bsp=f7d31098
  (XEN)  [f4096b00] ia64_leave_kernel+0x0/0x310
  (XEN) sp=f7d37730 
  bsp=f7d31098
  (XEN)  [f4030ef0] free_domheap_pages+0x130/0x7f0
  (XEN) sp=f7d37930 
  bsp=f7d31040
  (XEN)  [f4074930] pervcpu_vhpt_free+0x30/0x50
  (XEN) sp=f7d37930 
  bsp=f7d31020
  (XEN)  [f40505d0] relinquish_vcpu_resources+0x50/0xf0
  (XEN) sp=f7d37930 
  bsp=f7d30ff0
  (XEN)  [f4050700] free_vcpu_struct+0x90/0xc0
  (XEN) sp=f7d37930 
  bsp=f7d30fd0
  (XEN)  [f401e380] free_domain+0x50/0x90
  (XEN) sp=f7d37930 
  bsp=f7d30fa0
  (XEN)  [f401f100] domain_destroy+0x2e0/0x320
  (XEN)

Re: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-12 Thread Kouya SHIMURA 
Hi,

I'm still worried about the confliction between waking up a vcpu and
destroying the domain.

I'm not sure but the following modification seems to be necessary. 
It does the same thing as hvm_bringup_ap() in x86.

LOCK_BIGLOCK might be exaggerated but at least any lock is required. 
If two cpu execute IPI at the same time, vmx_final_setup_guest() can
be called simultaneously and that incurs memory leak.

diff -r 5176c3ea3293 xen/arch/ia64/vmx/mmio.c
--- a/xen/arch/ia64/vmx/mmio.c  Sun Oct 08 18:55:12 2006 -0600
+++ b/xen/arch/ia64/vmx/mmio.c  Thu Oct 12 14:33:59 2006 +0900
@@ -386,7 +386,13 @@ static void write_ipi (VCPU *vcpu, uint6
 
 memset (c, 0, sizeof (c));
 
+   LOCK_BIGLOCK(d);
+   if (test_bit(_VCPUF_initialised, targ-vcpu_flags)) {
+   UNLOCK_BIGLOCK(d);
+   goto initialized;
+   }
 if (arch_set_info_guest (targ, c) != 0) {
+   UNLOCK_BIGLOCK(d);
 printf (arch_boot_vcpu: failure\n);
 return;
 }
@@ -397,13 +403,18 @@ static void write_ipi (VCPU *vcpu, uint6
 
 if (test_and_clear_bit(_VCPUF_down,targ-vcpu_flags)) {
 vcpu_wake(targ);
+   UNLOCK_BIGLOCK(d);
 printf (arch_boot_vcpu: vcpu %d awaken %016lx!\n,
 targ-vcpu_id, targ_regs-cr_iip);
 }
-else
+else {
+   UNLOCK_BIGLOCK(d);
 printf (arch_boot_vcpu: huu, already awaken!);
-}
-else {
+   }
+   return;
+}
+  initialized:
+{
 int running = test_bit(_VCPUF_running,targ-vcpu_flags);
 deliver_ipi (targ, ((ipi_d_t)value).dm, 
 ((ipi_d_t)value).vector);

Thanks,
Kouya

Keir Fraser writes:
  
  
  
  On 11/10/06 08:34, Xu, Anthony [EMAIL PROTECTED] wrote:
  
   Keir,
   
   When free_vcpu_struct() is called, is it guaranteed that this vcpu is 
   stopped
   completely?
  
  Yes. domain_kill() calls domain_pause() which synchronously stops execution
  of every VCPU. domain_kill() drops a 'master reference' on the domain, so
  the destructors cannot run until domain_kill() has run.
  
   -- Keir
  
  
  
  ___
  Xen-devel mailing list
  [EMAIL PROTECTED]
  http://lists.xensource.com/xen-devel


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-12 Thread Xu, Anthony 
Hi Kouya,
As keir pointed out, all the vcpus are stoping completely before calling
free_vcpu_struct(),
That means all the vcpus are not running, and will not run. So the vcpus
either are setup completely, or are not create completely.
When a domain is destroyed, domain_kill is called,
1. domain_pause is called in domain_kill, this function will stop all
vcpus synchronously,that means if this function is returned, all the
vcpus are stopped completely.
2. after that put_domain is called, this function release all the
resource belonging to this domain.
Seems there is no race condition here.


See my comments

Anthony



LOCK_BIGLOCK might be exaggerated but at least any lock is required.
If two cpu execute IPI at the same time, vmx_final_setup_guest() can
be called simultaneously and that incurs memory leak.
Vmx_final_setup_guest can be called simultaneously, only if argument is
different vcpu.




diff -r 5176c3ea3293 xen/arch/ia64/vmx/mmio.c
--- a/xen/arch/ia64/vmx/mmio.c Sun Oct 08 18:55:12 2006 -0600
+++ b/xen/arch/ia64/vmx/mmio.c Thu Oct 12 14:33:59 2006 +0900
@@ -386,7 +386,13 @@ static void write_ipi (VCPU *vcpu, uint6

 memset (c, 0, sizeof (c));

+  LOCK_BIGLOCK(d);
+  if (test_bit(_VCPUF_initialised, targ-vcpu_flags)) {
+  UNLOCK_BIGLOCK(d);
+  goto initialized;
+  }
 if (arch_set_info_guest (targ, c) != 0) {
+  UNLOCK_BIGLOCK(d);
 printf (arch_boot_vcpu: failure\n);
 return;
 }
@@ -397,13 +403,18 @@ static void write_ipi (VCPU *vcpu, uint6

 if (test_and_clear_bit(_VCPUF_down,targ-vcpu_flags)) {
 vcpu_wake(targ);
+  UNLOCK_BIGLOCK(d);
 printf (arch_boot_vcpu: vcpu %d awaken %016lx!\n,
 targ-vcpu_id, targ_regs-cr_iip);
 }
-else
+else {
+  UNLOCK_BIGLOCK(d);
 printf (arch_boot_vcpu: huu, already awaken!);
-}
-else {
+  }
+  return;
+}
+  initialized:
+{
 int running = test_bit(_VCPUF_running,targ-vcpu_flags);
 deliver_ipi (targ, ((ipi_d_t)value).dm,
 ((ipi_d_t)value).vector);

Thanks,
Kouya

Keir Fraser writes:
 
 
 
  On 11/10/06 08:34, Xu, Anthony [EMAIL PROTECTED] wrote:
 
   Keir,
  
   When free_vcpu_struct() is called, is it guaranteed that this vcpu
is stopped
   completely?
 
  Yes. domain_kill() calls domain_pause() which synchronously stops
execution
  of every VCPU. domain_kill() drops a 'master reference' on the
domain, so
  the destructors cannot run until domain_kill() has run.
 
   -- Keir
 
 
 
  ___
  Xen-devel mailing list
  [EMAIL PROTECTED]
  http://lists.xensource.com/xen-devel

___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-12 Thread Xu, Anthony 
From: Kouya SHIMURA [mailto:[EMAIL PROTECTED]
Sent: 2006年10月12日 19:13
To: Xu, Anthony
Cc: xen-ia64-devel@lists.xensource.com
Subject: RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

Abnormal OS might wake up the same vcpu from other vcpus simultaneously.
We don't care such a case? :P


Good thinking,
I think there are two situations,
If two other vcpus wake up one vcpu at the exact same time, then this vcpu 
receives only one vcpu wakeup interrupt.
If two other vcpus wake up one vcpu sequentially, the first interrupt is 
thought of as vcpu wakeup interrupt, the second interrupt is injected into 
Guest OS by this vcpu, it is the Guest OS responsible to handle this abnormal 
interrupt.

Anthony




___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-11 Thread Kouya SHIMURA 
Hi Anthony,

I think that vmx_final_setup_guest() is called asynchronously.
Because the secondary vcpus are waken by IPI, not control panel.
Actually we can observe the following log message asynchronously.
(XEN) arch_boot_vcpu: vcpu 1 awaken 046bc180!

vmx_relinquish_vcpu_resources() is called after sched_destroy_domain().
If the scheduler stops vcpus completely in sched_destroy_domain(),
it might be OK. But it seems to be up to scheduler.

Thanks,
Kouya

Xu, Anthony writes:
  From: Kouya SHIMURA [mailto:[EMAIL PROTECTED]
  Sent: 2006年10月11日 12:41
  To: Xu, Anthony
  Cc: xen-ia64-devel@lists.xensource.com
  Subject: RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed
  Hi Anthony,
  
  Thanks for your comment.
  If it is safe that vmx_reliquish_vcpu_resouces(vcpu) is called
  before the vcpu is booted, your modification looks better.
  
  I'm afraid of the race condition between vmx_final_setup_guest()
  and vmx_relinquish_vcpu_resources().
  Supposing such a condition, we might have to use some lock in order to
  prevent memory leak. How do you think?
  
  I see your point,
  In this situation, vmx_final_setup_guest() and 
  vmx_relinquish_vcpu_resources()
  are called by control panel, they should not be called serially not 
  simultaneously.
  
  
  Anthony


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-11 Thread Xu, Anthony 
-Original Message-
From: Kouya SHIMURA [mailto:[EMAIL PROTECTED]
Sent: 2006年10月11日 14:27
To: Xu, Anthony
Cc: xen-ia64-devel@lists.xensource.com
Subject: RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

Hi Anthony,

I think that vmx_final_setup_guest() is called asynchronously.
Because the secondary vcpus are waken by IPI, not control panel.
Actually we can observe the following log message asynchronously.
(XEN) arch_boot_vcpu: vcpu 1 awaken 046bc180!
You are right at this point.

vmx_relinquish_vcpu_resources() is called after sched_destroy_domain().
If the scheduler stops vcpus completely in sched_destroy_domain(),
it might be OK. But it seems to be up to scheduler.

I'm not sure about this, 
But, if vcpus are not completely stopped before calling 
vmx_relinquish_vcpu_resources,
That's a big issue; vcpus may access some memories which have been freed and 
may be
used by other guys.


Keir,

When free_vcpu_struct() is called, is it guaranteed that this vcpu is stopped 
completely?

Thanks,
Anthony

___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Re: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-11 Thread Keir Fraser 



On 11/10/06 08:34, Xu, Anthony [EMAIL PROTECTED] wrote:

 Keir,
 
 When free_vcpu_struct() is called, is it guaranteed that this vcpu is stopped
 completely?

Yes. domain_kill() calls domain_pause() which synchronously stops execution
of every VCPU. domain_kill() drops a 'master reference' on the domain, so
the destructors cannot run until domain_kill() has run.

 -- Keir



___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-10 Thread Kouya SHIMURA 
Hi Anthony,

Thanks for your comment.
If it is safe that vmx_reliquish_vcpu_resouces(vcpu) is called
before the vcpu is booted, your modification looks better.

I'm afraid of the race condition between vmx_final_setup_guest()
and vmx_relinquish_vcpu_resources(). 
Supposing such a condition, we might have to use some lock in order to
prevent memory leak. How do you think?

Thanks,
Kouya

Xu, Anthony writes:
  Hi Kouya,
  
  Good catch!
  
  I think the root cause is, when VTI-domain is destroyed, vti-flag in vcpu 
  structure is not set while vti-flag in domain structure is set, so XEN think 
  of this vcpu as domU vcpu by mistake, then issue appears,
  
  Yes, your patch can fix this issue, but seems it may incur memory leak. 
  Maybe following small modification is needed.
  
  Anthony
  
  --- a/xen/arch/ia64/xen/domain.c Sun Oct 08 18:55:12 2006 -0600
  +++ b/xen/arch/ia64/xen/domain.c Tue Oct 10 19:06:44 2006 +0900
  @@ -341,9 +341,11 @@ void relinquish_vcpu_resources(struct vc
   
   void free_vcpu_struct(struct vcpu *v)
   {
  -if (VMX_DOMAIN(v))
  -vmx_relinquish_vcpu_resources(v);
  -else
  +if (v-domain-arch.is_vti) {
  +vmx_relinquish_vcpu_resources(v);
  +} else
   relinquish_vcpu_resources(v);
   
   free_xenheap_pages(v, KERNEL_STACK_SIZE_ORDER);
  
  
  
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of Kouya SHIMURA
  Sent: 2006年10月10日 18:31
  To: xen-ia64-devel@lists.xensource.com
  Subject: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed
  
  Hi,
  
  I got the following panic message when I destroyed a domvti which has
  2 vcpus and 2nd vcpu is not booted yet. This panic occurs from cset 11745.
  Attached patch fixes it.
  
  (XEN) ia64_fault, vector=0x1e, ifa=0xf414802a, 
  iip=0xf4030ef0, i
  psr=0x121008226018, isr=0x0a06
  (XEN) Unaligned Reference.
  (XEN) d 0xf7d5c080 domid 0
  (XEN) vcpu 0xf7d3 vcpu 0
  (XEN)
  (XEN) CPU 1
  (XEN) psr : 121008226018 ifs : 840b ip  : 
  [f4030ef1]
  (XEN) ip is at free_domheap_pages+0x131/0x7f0
  (XEN) unat:  pfs : 0206 rsc : 0003
  (XEN) rnat: 0206 bsps: 0003 pr  : 05569aab
  (XEN) ldrs:  ccv :  fpsr: 0009804c0270033f
  (XEN) csd :  ssd : 
  (XEN) b0  : f4074930 b6  : f4034130 b7  : a00100067a90
  (XEN) f6  : 1003e000670a4 f7  : 1003ecccd
  (XEN) f8  : 1003e000c2d06 f9  : 10001c000
  (XEN) f10 : 100099c1aaa0e9000 f11 : 1003e04e0
  (XEN) r1  : f4316d10 r2  :  r3  : f7d37fe8
  (XEN) r8  : 0040 r9  :  r10 : 
  (XEN) r11 : 0009804c0270033f r12 : f7d37930 r13 : f7d3
  (XEN) r14 :  r15 : 00019c29 r16 : 0001
  (XEN) r17 : f7ff7510 r18 : f7a0eb00 r19 : f7ff7500
  (XEN) r20 : f7a0eb08 r21 : f414803a r22 : f414802a
  (XEN) r23 : f40e8200 r24 : 001008226018 r25 : f411f420
  (XEN) r26 : f4119300 r27 :  r28 : fff1
  (XEN) r29 : 8000 r30 : 0001 r31 : f414802a
  (XEN)
  (XEN) Call Trace:
  (XEN)  [f4099b40] show_stack+0x80/0xa0
  (XEN) sp=f7d37560 
  bsp=f7d310d0
  (XEN)  [f406b050] ia64_fault+0x280/0x670
  (XEN) sp=f7d37730 
  bsp=f7d31098
  (XEN)  [f4096b00] ia64_leave_kernel+0x0/0x310
  (XEN) sp=f7d37730 
  bsp=f7d31098
  (XEN)  [f4030ef0] free_domheap_pages+0x130/0x7f0
  (XEN) sp=f7d37930 
  bsp=f7d31040
  (XEN)  [f4074930] pervcpu_vhpt_free+0x30/0x50
  (XEN) sp=f7d37930 
  bsp=f7d31020
  (XEN)  [f40505d0] relinquish_vcpu_resources+0x50/0xf0
  (XEN) sp=f7d37930 
  bsp=f7d30ff0
  (XEN)  [f4050700] free_vcpu_struct+0x90/0xc0
  (XEN) sp=f7d37930 
  bsp=f7d30fd0
  (XEN)  [f401e380] free_domain+0x50/0x90
  (XEN) sp=f7d37930 
  bsp=f7d30fa0
  (XEN)  [f401f100] domain_destroy+0x2e0/0x320
  (XEN) sp=f7d37930 
  bsp=f7d30f80
  (XEN)  [f4031190] free_domheap_pages+0x3d0/0x7f0
  (XEN) sp=f7d37940 
  bsp=f7d30f40
  (XEN)  [f40627d0] zap_domain_page_one+0x360/0x4d0
  (XEN) sp=f7d37940 
  bsp=f7d30ef8

RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed

2006-10-10 Thread Xu, Anthony 
From: Kouya SHIMURA [mailto:[EMAIL PROTECTED]
Sent: 2006年10月11日 12:41
To: Xu, Anthony
Cc: xen-ia64-devel@lists.xensource.com
Subject: RE: [Xen-ia64-devel] [PATCH] Xen panics when domvti is destroyed
Hi Anthony,

Thanks for your comment.
If it is safe that vmx_reliquish_vcpu_resouces(vcpu) is called
before the vcpu is booted, your modification looks better.

I'm afraid of the race condition between vmx_final_setup_guest()
and vmx_relinquish_vcpu_resources().
Supposing such a condition, we might have to use some lock in order to
prevent memory leak. How do you think?

I see your point,
In this situation, vmx_final_setup_guest() and vmx_relinquish_vcpu_resources()
are called by control panel, they should not be called serially not 
simultaneously.


Anthony

___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel