RE: [Xen-devel] Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

Jan Beulich wrote:
>>>> "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> 24.03.10 02:52 >>>
>> Pasi K?rkk?inen wrote:
>>> Hmm.. wondering if the patch Jan just sent will help with that.
>>> Sounds like it might help :)
>> I guess Jan's patch helps here in a very interesting way:
> 
> I think reference was to a patch I sent yesterday, which I don't think
> would help here (as the box would have to crash for it to help).
I think the reference is changeset 21039 (VT-d: reduce default verbosity).

>> I suspect your BIOS doesn't construct the DMAR properly, e.g., in
>> acpi_parse_dmar(),  entry_header->length is always 0, so xen'll hang
>> in the while loop and continue printing the "dmaru->address = 0"
>> message when iommu=verbose.   
> 
> Surely entry_header->length == 0 (or really
> entry_header->length < sizeof(struct acpi_table_XXX)) should be
> considered invalid, and hence get checked for? Linux at least has
> a check against zero here...
I think Weidong is making a patch for this.

> 
>> Without verbose message outputing, the loop runs even faster and in
>> acpi_parse_one_drhd(),  xmalloc(struct acpi_drhd_unit) would NULL in
>> a short period of time and hence VT-d is got disabled... :-)  
> 
> Why would you expect xmalloc() to fail soon? This is only to be
> expected on a 32-bit system (which I doubt this one is).
I guess here acpi_parse_dmar() becomes something like this
while (1)
{
   acpi_parse_one_drhd()
}
and acpi_parse_one_drhd() and acpi_parse_dev_scope(), the xmalloc-ed memory is 
not xfree-ed and hence leaked, so after "Xen takes  long time (25-30 seconds) 
to check for VT-d stuff, and then in the end IO virtualization gets disabled 
with 'Failed to parse ACPI DMAR' message -- I guess after "25-30 seconds" the 
xmalloc would return NULL here.

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