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] Critical bug: VT-d fault causes disk corruption or Dom0

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>, "Li, Haicheng" <haicheng.li@xxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic.
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Sat, 24 Jan 2009 11:07:25 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Sat, 24 Jan 2009 11:07:53 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5A08F60.21CF5%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: <C5A08CC2.21CF2%keir.fraser@xxxxxxxxxxxxx> <C5A08F60.21CF5%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acl8Q3YVs3niaMuxT1CPWgfSc0ZGCwAITqg5AAKyJXAAAOMrHgAfiHegABEJqTgAEqyPIAACkS3lAAAS7KQACh68wAAUUrk8AABj1zsAFA9jMA==
Thread-topic: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic.
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Saturday, January 24, 2009 1:27 AM
>
> On 24/01/2009 09:15, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>
> >> I talked to Joe Cihula about this.  He is suggesting map only the RAM 
> >> memory
> >> in E820 table.  This is more secure than map everything below max_page.  We
> >> can do this for x86_64 and x86_32.  For IA-64, we still map everything 
> >> below
> >> max_page as there is no tboot issue.
> >>
> >> What do you think of is approach?
> >
> > That's an orthogonal issue to avoiding Xen's RAM, but it at least ought to
> > be easy to do. As long as it doesn't skip any private BIOS buffers for any
> > devices which are still fully or partially under BIOS control (e.g., via
> > SMM). But any such buffers above max_page would already be skipped.
> >
> > I can check in a patch for this as well as a patch to fix xen_in_range().
> > I'll do both.
>
> Changesets 19081 and 19082.

Since the tboot memory is marked as reserved or unusable, the tboot_in_range() 
call is no longer needed.  Do you want me to add that to my patch set?

You've used a call to memory_is_conventional_ram() to check whether the page is 
in non-reserved RAM, but in looking at the function (below), I don't see how 
the '(e820.map[i].size > p)' test is valid--shouldn't it be '((e820.map[i].addr 
+ e820.map[i].size) > p)'?

int memory_is_conventional_ram(paddr_t p)
{
    int i;

    for ( i = 0; i < e820.nr_map; i++ )
    {
        if ( (e820.map[i].type == E820_RAM) &&
             (e820.map[i].addr <= p) &&
             (e820.map[i].size > p) )
            return 1;
    }

    return 0;
}

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