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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.12.14 at 11:54, <wei.liu2@xxxxxxxxxx> wrote:
> On Wed, Dec 10, 2014 at 08:20:38AM +0000, Jan Beulich wrote:
>> >>> On 09.12.14 at 19:06, <wei.liu2@xxxxxxxxxx> wrote:
>> > On Tue, Dec 09, 2014 at 04:53:40PM +0000, Jan Beulich wrote:
>> >> >>> On 01.12.14 at 16:33, <wei.liu2@xxxxxxxxxx> wrote:
>> >> > +        memset(memory, 0, sizeof(*memory));
>> >> > +        memory->type          = ACPI_MEMORY_AFFINITY;
>> >> > +        memory->length        = sizeof(*memory);
>> >> > +        memory->domain        = vmemrange[i].nid;
>> >> > +        memory->flags         = ACPI_MEM_AFFIN_ENABLED;
>> >> > +        memory->base_address  = vmemrange[i].start;
>> >> > +        memory->mem_length    = mem;
>> >> > +        memory++;
>> >> > +    }
>> >> > +
>> >> > +    srat->header.length = size;
>> >> 
>> >> Mind checking size == memory - p here?
>> >> 
>> > 
>> > Why? There doesn't seem to be anything that would cause memory -p !=
>> > size in between during runtime.
>> 
>> Except for that original calculation being wrong - that's what I would
>> mean such a check to verify.
>> 
> 
> Do you mean the code is wrong? I don't think so.

No, the code looks right. It's just that two disconnected
calculations easily get out of sync when someone later changes
them.

> Even if I have 
> 
> +    if ( ((unsigned long)memory) - ((unsigned long)p) != size )
> +        return NULL;
> +
> 
> Hvmloader doesn't complain, i.e. I don't see error message printed out
> in the construct_secondary_tables.
> 
> Anyway, if the above snippet is what you want, I can add it.

I was actually more after a BUG_ON() / ASSERT() kind of thing.

Jan


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