Re: [Xen-devel] [PATCH 12/19] hvmloader: construct SRAT

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Nov 24, 2014 at 10:26:44AM +0000, Jan Beulich wrote:
> >>> On 24.11.14 at 11:13, <wei.liu2@xxxxxxxxxx> wrote:
> > On Mon, Nov 24, 2014 at 10:08:42AM +0000, Jan Beulich wrote:
> >> >>> On 21.11.14 at 16:06, <wei.liu2@xxxxxxxxxx> wrote:
> >> > @@ -270,6 +331,13 @@ static int construct_secondary_tables(unsigned long 
> >> > *table_ptrs,
> >> >          table_ptrs[nr_tables++] = (unsigned long)madt;
> >> >      }
> >> >  
> >> > +    if ( hvm_info->nr_nodes > 0 )
> >> > +    {
> >> > +        srat = construct_srat();
> >> > +        if (!srat) return -1;
> >> 
> >> I don't think failure to set up secondary information (especially when
> >> it requires a variable size table and hence has [slightly] higher
> >> likelihood of table space allocation failing) should result in skipping
> >> other table setup.
> > 
> > But MADT, HPET and WAET are treated like that. I want to be
> > consistent.
> 
> I kind of expected you to say that, and specifically added the
> reference to SRAT and SLIT being variable size (and perhaps
> relatively big). While MADT is variable size too, it (other than the
> tables you add here) is kind of essential for the guest to come up
> in ACPI mode. Which btw also tells us that these two tables
> should be added as late as possible, to avoid them exhausting
> memory before other, essential allocations got done.
> 

So the plan is:

1. Move SRAT and SLIT down.
2. Don't return -1 on failure (and print warning).

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel