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

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

Pasi K?rkk?inen wrote:
> On Tue, Mar 23, 2010 at 07:54:33PM +0000, Keir Fraser wrote:
>> On 23/03/2010 19:37, "Pasi Kärkkäinen" <pasik@xxxxxx> wrote:
>> 
>>>> It's not impossible that the BIOS VT-d support is just broken (I
>>>> assume you've never tested VT-d on this particular type of system
>>>> before). 
>>> 
>>> Yeah, I've never used VT-d on this system earlier, so it could just
>>> be broken BIOS. I guess Xen still shouldn't hang on it?
>> 
>> We'd prefer to gracefully disable VT-d.
>> 
> 
> 4.0.0-rc7 (without any extra cmdline options) does disable vt-d and
> boot ok, after 'hanging' for 30 seconds while parsing the DMAR tables.
> 
> If I add "iommu=verbose" option for Xen, then it'll print huge amount
> of stuff like I pasted earlier.. and it takes forever to print all
> that. 
> 
> 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 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.
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 
periof of time and hence VT-d is got disabled... :-)

Please dump your DMAR table using the 'acpudump' utility in *native Linux*:
# wget 
http://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20100123.tar.gz
# tar zxf pmtools-20100123.tar.gz
# cd pmtools-20100123/acpidump && make && ./acpidump --table DMAR -b > dmar.bin
Please attach the dmar.bin so we can double check.

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