On Wed, Mar 24, 2010 at 09:52:45AM +0800, Cui, Dexuan wrote:
> 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
> 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
> # tar zxf pmtools-20100123.tar.gz
> # cd pmtools-20100123/acpidump && make && ./acpidump --table DMAR -b >
> Please attach the dmar.bin so we can double check.
Thanks, I'll provide the dmar table later when I have access to the machine
Xen-devel mailing list