RE: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic.

["Cihula, Joseph" <joseph.cihula@xxxxxxxxx>]

> 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