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

RE: [Xen-devel] X86_64 "assert" when booting 64-bit image.

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Subject: RE: [Xen-devel] X86_64 "assert" when booting 64-bit image.
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Thu, 9 Feb 2006 09:44:22 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 09 Feb 2006 17:55:45 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYtnWyfmpWTtqvHTA6wnXR2YDk79gAAO2lQ
Thread-topic: [Xen-devel] X86_64 "assert" when booting 64-bit image.
Keir Fraser wrote:
> On 9 Feb 2006, at 17:16, Petersson, Mats wrote:
> 
>>> No, please try removing the if statement *as well*. That
>>> whole conditional return of 0 should go away -- the only
>>> return statement in that function should be the one on the
>>> final final of the function. Let me know how that works out.
>> 
>> So this is an updated patch...
>> 
>> I can't tell any difference - but then I'm not sure what type of
>> cases it's trying to catch... ;-)
> 
> Yes, that's the patch I wanted. You tested it and it works?
> 
>   -- Keir
> 
> 

I think that particular check is valid; it's basically saying "we shadow
page tables only". I feel mfn_is_page_table can be wrong with the type
PGT_fl1_shadow, which is bigger than PGT_l4_shadow.  Let me check and
come back. I slightly remember I needed to kill the check when I was
debugging the code, but not sure if it was triggered by a bug.
 

    if ( VALID_MFN(mfn) && mfn_valid(mfn) &&
         (stype != PGT_writable_pred) &&
         ((stype == PGT_snapshot)
          ? !mfn_out_of_sync(mfn)
          : !mfn_is_page_table(mfn)) )
    {
        perfc_incrc(shadow_status_shortcut);
#ifndef NDEBUG
        if ( ___shadow_status(d, gpfn, stype) != 0 )
        {
            printk("d->id=%d gpfn=%lx mfn=%lx stype=%lx c=%x t=%"
PRtype_info " "
                   "mfn_out_of_sync(mfn)=%d
mfn_is_page_table(mfn)=%d\n",
                   d->domain_id, gpfn, mfn, stype,
                   mfn_to_page(mfn)->count_info,
                   mfn_to_page(mfn)->u.inuse.type_info,
                   mfn_out_of_sync(mfn), mfn_is_page_table(mfn));
            BUG();
        }

        // Undo the affects of the above call to ___shadow_status()'s
perf
        // counters, since that call is really just part of an
assertion.
        //
        perfc_decrc(shadow_status_calls);
        perfc_decrc(shadow_status_miss);
#endif
        return 0;
    }
Jun
---
Intel Open Source Technology Center

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