WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH][SVM] fix spinlock panic

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH][SVM] fix spinlock panic
From: Christoph Egger <Christoph.Egger@xxxxxxx>
Date: Thu, 18 Jun 2009 11:25:36 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 18 Jun 2009 02:39:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C65FBE95.D955%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C65FBE95.D955%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.7
On Thursday 18 June 2009 10:51:17 Keir Fraser wrote:
> On 17/06/2009 15:20, "Christoph Egger" <Christoph.Egger@xxxxxxx> wrote:
> > Attached patch enables irq when initializing SVM so it's safe to take
> > locks. This fixes a panic like this:
>
> The bug is related to the fact you leak memory on every S3 resume, by
> reallocating hsa[cpu] and root_vmcb[cpu] which were never freed. Please see
> c/s 19784 in the staging tree which does a general cleanup and fix of
> start_svm(). It should fix your crash.
>
> It does change behaviour a bit -- primarily: It does not reset the ASID
> logic completely (I'm not certain there couldn't be VCPUs hanging around
> pointing at earlier generations on this CPU, in which case it would be
> dangerous to reset the ASID generation back to zero); Also, as well as not
> reallocating hsa and root_vmcb, we don't re-init them either. I don't know
> ehether that strictly matters but obviously we could easily re-jig the code
> to always clear_page() those pages unconditionally.

Thanks for it. Regarding ASID, I will ask back.
Now, I trigger an ASSERT() called by setup_vmcb_dump():

(XEN) Assertion 'key_table[key].u.handler == ((void*)0)' failed at 
keyhandler.c:68
[]
(XEN) Xen call trace:
(XEN)    [<ffff828c8010e0b6>] register_keyhandler+0x24/0x65
(XEN)    [<ffff828c801a7487>] setup_vmcb_dump+0x1c/0x1e
(XEN)    [<ffff828c801a5a37>] start_svm+0x98/0xdc
(XEN)    [<ffff828c8018747d>] init_amd+0x92b/0x96e
(XEN)    [<ffff828c80187be8>] identify_cpu+0xc3/0x23e
(XEN)    [<ffff828c8016576b>] smp_store_cpu_info+0x3b/0xca
(XEN)    [<ffff828c801658fb>] smp_callin+0x101/0x217
(XEN)    [<ffff828c80166997>] start_secondary+0xb0/0x419

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>