Re: [PATCH][SVM] fix spinlock panic

[Christoph Egger <Christoph.Egger@amd.com>]

On Thursday 18 June 2009 10:51:17 Keir Fraser wrote:
> On 17/06/2009 15:20, "Christoph Egger" <Christoph.Egger@amd.com> 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