* Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
@ 2010-03-23 14:27 Pasi Kärkkäinen
2010-03-23 14:40 ` Jan Beulich
2010-03-23 14:40 ` Pasi Kärkkäinen
0 siblings, 2 replies; 33+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-23 14:27 UTC (permalink / raw)
To: xen-devel
Hello,
Just when I wrote that Xen 4.0.0-rc7 works fine for me.. :)
Ok, so I went to BIOS and enabled VT-d. I haven't used VT-d earlier on this system.
Without serial console (normal VGA text console) I noticed that 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.
When I add iommu=verbose for Xen (dunno if it's related to this new flag),
then Xen just displayes the same messages repeatedly and doesn't start.
(or it takes very long to boot).
Full Xen log from serial console here:
http://pasik.reaktio.net/xen/debug/xen-400-rc7-vt-d-dmar.txt
XEN) Enabling APIC mode: Flat. Using 3 I/O APICs
(XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
(XEN) [VT-D]dmar.c:656: Host address width 36
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
..
..
..
same stuff continues for a very long time.. I didn't bother waiting
so I just power cycled the machine in the end.
I'm using Supermicro X7SB4 motherboard with BIOS version 1.2a (the latest available).
-- Pasi
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-23 14:27 Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing Pasi Kärkkäinen
@ 2010-03-23 14:40 ` Jan Beulich
2010-03-23 14:40 ` Pasi Kärkkäinen
1 sibling, 0 replies; 33+ messages in thread
From: Jan Beulich @ 2010-03-23 14:40 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: xen-devel
And what is the last c/s that worked for you? Was that reporting valid
addresses in those "dmaru->address = ..." messages? If so it would
seem like the DMAR table got corrupted (by Xen?) somehow. If not (i.e.
if the address was zero there too), some error checking may have got
removed accidentally.
Jan
>>> Pasi Kärkkäinen<pasik@iki.fi> 23.03.10 15:27 >>>
Hello,
Just when I wrote that Xen 4.0.0-rc7 works fine for me.. :)
Ok, so I went to BIOS and enabled VT-d. I haven't used VT-d earlier on this system.
Without serial console (normal VGA text console) I noticed that 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.
When I add iommu=verbose for Xen (dunno if it's related to this new flag),
then Xen just displayes the same messages repeatedly and doesn't start.
(or it takes very long to boot).
Full Xen log from serial console here:
http://pasik.reaktio.net/xen/debug/xen-400-rc7-vt-d-dmar.txt
XEN) Enabling APIC mode: Flat. Using 3 I/O APICs
(XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
(XEN) [VT-D]dmar.c:656: Host address width 36
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
(XEN) [VT-D]dmar.c:666: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:384: dmaru->address = 0
..
..
..
same stuff continues for a very long time.. I didn't bother waiting
so I just power cycled the machine in the end.
I'm using Supermicro X7SB4 motherboard with BIOS version 1.2a (the latest available).
-- Pasi
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-23 14:27 Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing Pasi Kärkkäinen
2010-03-23 14:40 ` Jan Beulich
@ 2010-03-23 14:40 ` Pasi Kärkkäinen
2010-03-23 14:48 ` Keir Fraser
1 sibling, 1 reply; 33+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-23 14:40 UTC (permalink / raw)
To: xen-devel
On Tue, Mar 23, 2010 at 04:27:54PM +0200, Pasi Kärkkäinen wrote:
> Hello,
>
> Just when I wrote that Xen 4.0.0-rc7 works fine for me.. :)
> Ok, so I went to BIOS and enabled VT-d. I haven't used VT-d earlier on this system.
>
I just tried Xen 4.0.0-rc6-pre, and it has the same problem,
it is flooding the same messages and takes forever to boot.
So 4.0.0-rc7 actually works better, since it surpresses
the messages as a default so it takes "only" 30 secs to parse
the DMAR tables.
-- Pasi
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-23 14:40 ` Pasi Kärkkäinen
@ 2010-03-23 14:48 ` Keir Fraser
2010-03-23 19:37 ` Pasi Kärkkäinen
0 siblings, 1 reply; 33+ messages in thread
From: Keir Fraser @ 2010-03-23 14:48 UTC (permalink / raw)
To: Pasi Kärkkäinen, xen-devel; +Cc: Weidong Han
On 23/03/2010 14:40, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
>> Just when I wrote that Xen 4.0.0-rc7 works fine for me.. :)
>> Ok, so I went to BIOS and enabled VT-d. I haven't used VT-d earlier on this
>> system.
>>
>
> I just tried Xen 4.0.0-rc6-pre, and it has the same problem,
> it is flooding the same messages and takes forever to boot.
>
> So 4.0.0-rc7 actually works better, since it surpresses
> the messages as a default so it takes "only" 30 secs to parse
> the DMAR tables.
Do you have the latest BIOS version installed? What motherboard do you have?
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).
-- Keir
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-23 14:48 ` Keir Fraser
@ 2010-03-23 19:37 ` Pasi Kärkkäinen
2010-03-23 19:54 ` Keir Fraser
0 siblings, 1 reply; 33+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-23 19:37 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, Weidong Han
On Tue, Mar 23, 2010 at 02:48:39PM +0000, Keir Fraser wrote:
> On 23/03/2010 14:40, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
>
> >> Just when I wrote that Xen 4.0.0-rc7 works fine for me.. :)
> >> Ok, so I went to BIOS and enabled VT-d. I haven't used VT-d earlier on this
> >> system.
> >>
> >
> > I just tried Xen 4.0.0-rc6-pre, and it has the same problem,
> > it is flooding the same messages and takes forever to boot.
> >
> > So 4.0.0-rc7 actually works better, since it surpresses
> > the messages as a default so it takes "only" 30 secs to parse
> > the DMAR tables.
>
> Do you have the latest BIOS version installed? What motherboard do you have?
>
I actually already had this information in the first mail :)
here it is again: Supermicro X7SB4 motherboard with BIOS version 1.2a (the latest available).
> 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?
-- Pasi
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-23 19:37 ` Pasi Kärkkäinen
@ 2010-03-23 19:54 ` Keir Fraser
2010-03-23 20:05 ` Pasi Kärkkäinen
0 siblings, 1 reply; 33+ messages in thread
From: Keir Fraser @ 2010-03-23 19:54 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: xen-devel, Weidong Han
On 23/03/2010 19:37, "Pasi Kärkkäinen" <pasik@iki.fi> 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.
-- Keir
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-23 19:54 ` Keir Fraser
@ 2010-03-23 20:05 ` Pasi Kärkkäinen
2010-03-24 0:40 ` Weidong Han
2010-03-24 1:52 ` Cui, Dexuan
0 siblings, 2 replies; 33+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-23 20:05 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, Weidong Han
On Tue, Mar 23, 2010 at 07:54:33PM +0000, Keir Fraser wrote:
> On 23/03/2010 19:37, "Pasi Kärkkäinen" <pasik@iki.fi> 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 :)
-- Pasi
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-23 20:05 ` Pasi Kärkkäinen
@ 2010-03-24 0:40 ` Weidong Han
2010-03-24 1:52 ` Cui, Dexuan
1 sibling, 0 replies; 33+ messages in thread
From: Weidong Han @ 2010-03-24 0:40 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: xen-devel, Keir Fraser
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@iki.fi> 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.
>
The BIOS is likely broken. Could you dump the ACPI tables? Then we can
confirm if it's BIOS issue. Maybe we can cook a patch to detect this
issue (dmaru->address == 0), and handle it more gracefully. I will have
a look at it.
Regards,
Weidong.
> Hmm.. wondering if the patch Jan just sent will help with that.
> Sounds like it might help :)
>
> -- Pasi
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-23 20:05 ` Pasi Kärkkäinen
2010-03-24 0:40 ` Weidong Han
@ 2010-03-24 1:52 ` Cui, Dexuan
2010-03-24 8:24 ` Jan Beulich
` (2 more replies)
1 sibling, 3 replies; 33+ messages in thread
From: Cui, Dexuan @ 2010-03-24 1:52 UTC (permalink / raw)
To: Pasi Kärkkäinen, Keir Fraser; +Cc: xen-devel, Han, Weidong
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@iki.fi> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 1:52 ` Cui, Dexuan
@ 2010-03-24 8:24 ` Jan Beulich
2010-03-24 8:54 ` Cui, Dexuan
2010-03-24 9:02 ` Weidong Han
2010-03-24 8:50 ` Pasi Kärkkäinen
2010-03-26 19:45 ` Pasi Kärkkäinen
2 siblings, 2 replies; 33+ messages in thread
From: Jan Beulich @ 2010-03-24 8:24 UTC (permalink / raw)
To: pasik, Dexuan Cui; +Cc: xen-devel, Weidong Han, Keir Fraser
>>> "Cui, Dexuan" <dexuan.cui@intel.com> 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 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...
>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... :-)
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).
Jan
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 1:52 ` Cui, Dexuan
2010-03-24 8:24 ` Jan Beulich
@ 2010-03-24 8:50 ` Pasi Kärkkäinen
2010-03-26 19:45 ` Pasi Kärkkäinen
2 siblings, 0 replies; 33+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-24 8:50 UTC (permalink / raw)
To: Cui, Dexuan; +Cc: xen-devel, Han, Weidong, Keir Fraser
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@iki.fi> 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, I'll provide the dmar table later when I have access to the machine again.
-- Pasi
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 8:24 ` Jan Beulich
@ 2010-03-24 8:54 ` Cui, Dexuan
2010-03-24 9:02 ` Weidong Han
1 sibling, 0 replies; 33+ messages in thread
From: Cui, Dexuan @ 2010-03-24 8:54 UTC (permalink / raw)
To: Jan Beulich, pasik; +Cc: xen-devel, Han, Weidong, Keir Fraser
Jan Beulich wrote:
>>>> "Cui, Dexuan" <dexuan.cui@intel.com> 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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 8:24 ` Jan Beulich
2010-03-24 8:54 ` Cui, Dexuan
@ 2010-03-24 9:02 ` Weidong Han
2010-03-24 9:10 ` Pasi Kärkkäinen
2010-03-24 9:46 ` Jan Beulich
1 sibling, 2 replies; 33+ messages in thread
From: Weidong Han @ 2010-03-24 9:02 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser, Cui, Dexuan
Jan Beulich wrote:
>>>> "Cui, Dexuan" <dexuan.cui@intel.com> 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 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...
>
yes, we need the check to solve Pasi's issue. I ported the patch from
Linux, post below. Pasi, pls test the patch on your machine.
it cannot check entry_header->length < sizeof(struct acpi_table_XXX),
which is not the actual size in acpi table.
diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:54:31 2010 +0800
@@ -659,6 +659,15 @@ static int __init acpi_parse_dmar(struct
while ( ((unsigned long)entry_header) <
(((unsigned long)dmar) + table->length) )
{
+ /* Avoid looping forever on bad ACPI tables */
+ if ( entry_header->length == 0 )
+ {
+ dprintk(XENLOG_WARNING VTDPREFIX,
+ "Invalid 0-length entry_header\n");
+ ret = -EINVAL;
+ break;
+ }
+
switch ( entry_header->type )
{
case ACPI_DMAR_DRHD:
>
>> 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... :-)
>>
>
> 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).
>
> Jan
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 9:02 ` Weidong Han
@ 2010-03-24 9:10 ` Pasi Kärkkäinen
2010-03-24 9:46 ` Jan Beulich
1 sibling, 0 replies; 33+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-24 9:10 UTC (permalink / raw)
To: Weidong Han; +Cc: xen-devel, Keir Fraser, Jan Beulich, Cui, Dexuan
On Wed, Mar 24, 2010 at 05:02:10PM +0800, Weidong Han wrote:
> Jan Beulich wrote:
>>>>> "Cui, Dexuan" <dexuan.cui@intel.com> 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 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...
>>
> yes, we need the check to solve Pasi's issue. I ported the patch from
> Linux, post below. Pasi, pls test the patch on your machine.
>
Thanks, I'll try it on friday, I'm away from the system until that.
-- Pasi
> it cannot check entry_header->length < sizeof(struct acpi_table_XXX),
> which is not the actual size in acpi table.
>
> diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
> --- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010 +0800
> +++ b/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:54:31 2010 +0800
> @@ -659,6 +659,15 @@ static int __init acpi_parse_dmar(struct
> while ( ((unsigned long)entry_header) <
> (((unsigned long)dmar) + table->length) )
> {
> + /* Avoid looping forever on bad ACPI tables */
> + if ( entry_header->length == 0 )
> + {
> + dprintk(XENLOG_WARNING VTDPREFIX,
> + "Invalid 0-length entry_header\n");
> + ret = -EINVAL;
> + break;
> + }
> +
> switch ( entry_header->type )
> {
> case ACPI_DMAR_DRHD:
>
>
>>
>>> 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... :-)
>>>
>>
>> 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).
>>
>> Jan
>>
>>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 9:02 ` Weidong Han
2010-03-24 9:10 ` Pasi Kärkkäinen
@ 2010-03-24 9:46 ` Jan Beulich
2010-03-24 11:00 ` Weidong Han
1 sibling, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2010-03-24 9:46 UTC (permalink / raw)
To: Weidong Han; +Cc: xen-devel, Keir Fraser, Dexuan Cui
>>> Weidong Han <weidong.han@intel.com> 24.03.10 10:02 >>>
>it cannot check entry_header->length < sizeof(struct acpi_table_XXX),
>which is not the actual size in acpi table.
I don't follow here: Minimally checking against
sizeof(struct acpi_dmar_entry_header) should be possible. But I can't
even see why checking for sizeof(struct acpi_table_XXX) in the
individual case statements can't be done.
Jan
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 9:46 ` Jan Beulich
@ 2010-03-24 11:00 ` Weidong Han
2010-03-24 11:11 ` Jan Beulich
2010-03-24 17:34 ` Nadolski, Ed
0 siblings, 2 replies; 33+ messages in thread
From: Weidong Han @ 2010-03-24 11:00 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser, Cui, Dexuan
Jan Beulich wrote:
>>>> Weidong Han <weidong.han@intel.com> 24.03.10 10:02 >>>
>>>>
>> it cannot check entry_header->length < sizeof(struct acpi_table_XXX),
>> which is not the actual size in acpi table.
>>
>
> I don't follow here: Minimally checking against
> sizeof(struct acpi_dmar_entry_header) should be possible. But I can't
> even see why checking for sizeof(struct acpi_table_XXX) in the
> individual case statements can't be done.
>
> Jan
>
Re-checked the code. You're right. Updated the patch to check with
sizeof(struct acpi_table_XXX).
Idea-by: Jan Beulich <jbeulich@novell.com <mailto:jbeulich@novell.com>>
Signed-off-by: Weidong Han <weidong.han@intel.com>
diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 03:53:21 2010 +0800
@@ -659,6 +659,23 @@ static int __init acpi_parse_dmar(struct
while ( ((unsigned long)entry_header) <
(((unsigned long)dmar) + table->length) )
{
+ /*
+ * entry_header length should not smaller than size of
+ * any acpi dmar structures. also avoid endless looping
+ * when the lenght is 0 on some bad BIOSs
+ */
+ if ( entry_header->length < sizeof(struct acpi_table_drhd) &&
+ entry_header->length < sizeof(struct acpi_table_rmrr) &&
+ entry_header->length < sizeof(struct acpi_table_atsr) &&
+ entry_header->length < sizeof(struct acpi_table_rhsa) )
+ {
+ dprintk(XENLOG_WARNING VTDPREFIX,
+ "Invalid entry_header length: 0x%x\n",
+ entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
switch ( entry_header->type )
{
case ACPI_DMAR_DRHD:
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 11:00 ` Weidong Han
@ 2010-03-24 11:11 ` Jan Beulich
2010-03-25 0:55 ` Weidong Han
2010-03-24 17:34 ` Nadolski, Ed
1 sibling, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2010-03-24 11:11 UTC (permalink / raw)
To: Weidong Han; +Cc: xen-devel, Keir Fraser, Dexuan Cui
>>> Weidong Han <weidong.han@intel.com> 24.03.10 12:00 >>>
>Re-checked the code. You're right. Updated the patch to check with
>sizeof(struct acpi_table_XXX).
Why that way instead of checking for the header size in the common
code path, and for the precise size in the case statements?
Jan
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 11:00 ` Weidong Han
2010-03-24 11:11 ` Jan Beulich
@ 2010-03-24 17:34 ` Nadolski, Ed
2010-03-25 0:04 ` Weidong Han
1 sibling, 1 reply; 33+ messages in thread
From: Nadolski, Ed @ 2010-03-24 17:34 UTC (permalink / raw)
To: Weidong Han, Jan Beulich; +Cc: Keir, xen-devel, Fraser, Cui, Dexuan
> -----Original Message-----
> Idea-by: Jan Beulich <jbeulich@novell.com <mailto:jbeulich@novell.com>>
> Signed-off-by: Weidong Han <weidong.han@intel.com>
>
> diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
> --- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010
> +0800
> +++ b/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 03:53:21 2010
> +0800
> @@ -659,6 +659,23 @@ static int __init acpi_parse_dmar(struct
> while ( ((unsigned long)entry_header) <
> (((unsigned long)dmar) + table->length) )
> {
> + /*
> + * entry_header length should not smaller than size of
> + * any acpi dmar structures. also avoid endless looping
> + * when the lenght is 0 on some bad BIOSs
> + */
> + if ( entry_header->length < sizeof(struct acpi_table_drhd) &&
> + entry_header->length < sizeof(struct acpi_table_rmrr) &&
> + entry_header->length < sizeof(struct acpi_table_atsr) &&
> + entry_header->length < sizeof(struct acpi_table_rhsa) )
> + {
> + dprintk(XENLOG_WARNING VTDPREFIX,
> + "Invalid entry_header length: 0x%x\n",
> + entry_header->length);
> + ret = -EINVAL;
> + break;
> + }
> +
> switch ( entry_header->type )
> {
> case ACPI_DMAR_DRHD:
I'm also seeing a hang on boot with 4.0.0-rc7, but I am not clear if this is the same issue. Here is the tail end of the trace:
[ 4.802862] NetLabel: unlabeled traffic allowed by default
[ 4.808653] DMAR:Host address width 40
[ 4.812310] DMAR:DRHD base: 0x000000dfffe000 flags: 0x0
[ 4.817604] IOMMU dfffe000: ver 1:0 cap c90780106f0462 ecap f020fe
[ 4.823816] DMAR:DRHD base: 0x000000fedc0000 flags: 0x1
[ 4.829105] IOMMU fedc0000: ver 1:0 cap c90780106f0462 ecap f020f6
[ 4.835325] DMAR:RMRR base: 0x000000dbe58000 end: 0x000000dbe6ffff
[ 4.841556] DMAR:ATSR flags: 0x0
[ 4.844844] DMAR:ATSR flags: 0x0
[ 4.848133] Not all IO-APIC's listed under remapping hardware
[ 4.854028] IOMMU 0xdfffe000: using Queued invalidation
[ 4.859217] IOMMU 0xfedc0000: using Queued invalidation
[ 4.864493] IOMMU: Setting RMRR:
[ 4.867778] IOMMU: Setting identity map for device 0000:00:1d.0 [0xdbe58000 - 0xdbe70000]
[ 4.876053] IOMMU: Setting identity map for device 0000:00:1d.1 [0xdbe58000 - 0xdbe70000]
[ 4.884264] IOMMU: Setting identity map for device 0000:00:1d.2 [0xdbe58000 - 0xdbe70000]
[ 4.892485] IOMMU: Setting identity map for device 0000:00:1d.7 [0xdbe58000 - 0xdbe70000]
[ 4.900709] IOMMU: Setting identity map for device 0000:00:1a.0 [0xdbe58000 - 0xdbe70000]
[ 4.908928] IOMMU: Setting identity map for device 0000:00:1a.1 [0xdbe58000 - 0xdbe70000]
[ 4.917150] IOMMU: Setting identity map for device 0000:00:1a.2 [0xdbe58000 - 0xdbe70000]
[ 4.925390] IOMMU: Setting identity map for device 0000:00:1a.7 [0xdbe58000 - 0xdbe70000]
[ 4.933612] IOMMU: Prepare 0-16MiB unity mapping for LPC
[ 4.938938] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]
[ 4.946651] VT-d detected invalid descriptor: low=11, high=0
Then it hangs. This is on a Dell T7500 quad-core Xeon with the latest Dell BIOS (rev. A03). Should I try the suggested patch, or any particular command line or build options? Should I dump the DMAR tables?
Thanks,
Ed
Here is the full trace:
__ __ _ _ ___ ___ _____
\ \/ /___ _ __ | || | / _ \ / _ \ _ __ __|___ |
\ // _ \ '_ \ | || |_| | | | | | |__| '__/ __| / /
/ \ __/ | | | |__ _| |_| | |_| |__| | | (__ / /
/_/\_\___|_| |_| |_|(_)___(_)___/ |_| \___/_/
(XEN) Xen version 4.0.0-rc7 (root@) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) Tue Mar 23 17:04:42 MDT 2010
(XEN) Latest ChangeSet: Tue Mar 23 09:37:59 2010 +0000 21057:0475c567c708
(XEN) Console output is synchronous.
(XEN) Command line: iommu=1 acpi_skip_timer_override loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1 console=com1
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009e400 (usable)
(XEN) 00000000000f0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000dbdf9c00 (usable)
(XEN) 00000000dbdf9c00 - 00000000dbe4bc00 (ACPI NVS)
(XEN) 00000000dbe4bc00 - 00000000dbe4dc00 (ACPI data)
(XEN) 00000000dbe4dc00 - 00000000dc000000 (reserved)
(XEN) 00000000f8000000 - 00000000fd000000 (reserved)
(XEN) 00000000fe000000 - 00000000fed00400 (reserved)
(XEN) 00000000fee00000 - 00000000fef00000 (reserved)
(XEN) 00000000ffb00000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 00000001a4000000 (usable)
(XEN) ACPI: RSDP 000FEBF0, 0024 (r2 DELL )
(XEN) ACPI: XSDT 000FCC3C, 0084 (r1 DELL B10K 15 ASL 61)
(XEN) ACPI: FACP 000FCD34, 00F4 (r3 DELL B10K 15 ASL 61)
(XEN) ACPI: DSDT FFE9A4EE, 5732 (r1 DELL dt_ex 1000 INTL 20050624)
(XEN) ACPI: FACS DBDF9C00, 0040
(XEN) ACPI: SSDT FFE9FD41, 00AC (r1 DELL st_ex 1000 INTL 20050624)
(XEN) ACPI: APIC 000FCE28, 016A (r1 DELL B10K 15 ASL 61)
(XEN) ACPI: BOOT 000FCF92, 0028 (r1 DELL B10K 15 ASL 61)
(XEN) ACPI: ASF! 000FCFBA, 0096 (r32 DELL B10K 15 ASL 61)
(XEN) ACPI: MCFG 000FD050, 003E (r1 DELL B10K 15 ASL 61)
(XEN) ACPI: HPET 000FD08E, 0038 (r1 DELL B10K 15 ASL 61)
(XEN) ACPI: TCPA 000FD2EA, 0032 (r1 DELL B10K 15 ASL 61)
(XEN) ACPI: DMAR 000FD31C, 00F8 (r1 DELL B10K 15 ASL 61)
(XEN) ACPI: SLIC 000FD0C6, 0176 (r1 DELL B10K 15 ASL 61)
(XEN) ACPI: _RAT 000FDECE, 0030 (r1 DELL B10K 15 ASL 61)
(XEN) ACPI: SSDT DBE4DC00, 10F4 (r1 INTEL PPM RCM 80000001 INTL 20061109)
(XEN) System RAM: 6104MB (6250856kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-00000001a4000000
(XEN) Domain heap initialised
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI: wakeup_vec[dbdf9c0c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) Processor #6 7:10 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x19] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x20] lapic_id[0x00] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
(XEN) ACPI: IOAPIC (id[0x0a] address[0xfec88000] gsi_base[48])
(XEN) IOAPIC[2]: apic_id 10, version 32, address 0xfec88000, GSI 48-71
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: BIOS IRQ0 pin2 override ignored.
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Flat. Using 3 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2128.034 MHz processor.
(XEN) Initing memory sharing.
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Extended Page Tables (EPT)
(XEN) - Virtual-Processor Identifiers (VPID)
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d Snoop Control supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=0 apic2=-1 pin2=-1
(XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
(XEN) ...trying to set up timer (IRQ0) through the 8259A ... failed.
(XEN) ...trying to set up timer as Virtual Wire IRQ... works.
(XEN) TSC is reliable, synchronization unnecessary
(XEN) Platform timer is 14.318MHz HPET
ÿ(XEN) Allocated console ring of 32 KiB.
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) Brought up 4 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1b62000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000198000000->000000019c000000 (1500636 pages to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff81b62000
(XEN) Init. ramdisk: ffffffff81b62000->ffffffff829c1000
(XEN) Phys-Mach map: ffffffff829c1000->ffffffff83553ee0
(XEN) Start info: ffffffff83554000->ffffffff835544b4
(XEN) Page tables: ffffffff83555000->ffffffff83574000
(XEN) Boot stack: ffffffff83574000->ffffffff83575000
(XEN) TOTAL: ffffffff80000000->ffffffff83800000
(XEN) ENTRY ADDRESS: ffffffff818f6a20
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 168kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.31.12 (root@truckee) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) #1 SMP Tue Mar 23 16:46:07 MDT 2010
[ 0.000000] Command line: ro root=UUID=edbcbc29-f3e4-4985-80c1-3c3b0ce24d17 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=hvc0 earlyprintk=xen xen-pciback.hide=(24:00.0)(24:00.1)(25:00.0)(25:00.1) acpi_skip_timer_override
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] xen_release_chunk: looking at area pfn 9f-a0: 1 pages freed
[ 0.000000] xen_release_chunk: looking at area pfn dc000-f8000: 114688 pages freed
[ 0.000000] xen_release_chunk: looking at area pfn fd000-fe000: 4096 pages freed
[ 0.000000] xen_release_chunk: looking at area pfn fed01-fee00: 255 pages freed
[ 0.000000] xen_release_chunk: looking at area pfn fef00-ffb00: 3072 pages freed
[ 0.000000] released 122112 pages of unused memory
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 000000000009e400 (usable)
[ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved)
[ 0.000000] Xen: 0000000000100000 - 00000000dbdf9c00 (usable)
[ 0.000000] Xen: 00000000dbdf9c00 - 00000000dbe4bc00 (ACPI NVS)
[ 0.000000] Xen: 00000000dbe4bc00 - 00000000dbe4dc00 (ACPI data)
[ 0.000000] Xen: 00000000dbe4dc00 - 00000000dc000000 (reserved)
[ 0.000000] Xen: 00000000f8000000 - 00000000fd000000 (reserved)
[ 0.000000] Xen: 00000000fe000000 - 00000000fed00400 (reserved)
[ 0.000000] Xen: 00000000fee00000 - 00000000fef00000 (reserved)
[ 0.000000] Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[ 0.000000] Xen: 0000000100000000 - 00000001725dc000 (usable)
[ 0.000000] console [xenboot0] enabled
[ 0.000000] DMI 2.5 present.
[ 0.000000] last_pfn = 0x1725dc max_arch_pfn = 0x400000000
[ 0.000000] last_pfn = 0xdbdf9 max_arch_pfn = 0x400000000
[ 0.000000] Scanning 1 areas for low memory corruption
[ 0.000000] modified physical RAM map:
[ 0.000000] modified: 0000000000000000 - 0000000000001000 (usable)
[ 0.000000] modified: 0000000000001000 - 0000000000006000 (reserved)
[ 0.000000] modified: 0000000000006000 - 000000000009e400 (usable)
[ 0.000000] modified: 00000000000a0000 - 0000000000100000 (reserved)
[ 0.000000] modified: 0000000000100000 - 00000000dbdf9c00 (usable)
[ 0.000000] modified: 00000000dbdf9c00 - 00000000dbe4bc00 (ACPI NVS)
[ 0.000000] modified: 00000000dbe4bc00 - 00000000dbe4dc00 (ACPI data)
[ 0.000000] modified: 00000000dbe4dc00 - 00000000dc000000 (reserved)
[ 0.000000] modified: 00000000f8000000 - 00000000fd000000 (reserved)
[ 0.000000] modified: 00000000fe000000 - 00000000fed00400 (reserved)
[ 0.000000] modified: 00000000fee00000 - 00000000fef00000 (reserved)
[ 0.000000] modified: 00000000ffb00000 - 0000000100000000 (reserved)
[ 0.000000] modified: 0000000100000000 - 00000001725dc000 (usable)
[ 0.000000] init_memory_mapping: 0000000000000000-00000000dbdf9000
[ 0.000000] init_memory_mapping: 0000000100000000-00000001725dc000
[ 0.000000] RAMDISK: 01b62000 - 029c1000
[ 0.000000] ACPI: RSDP 00000000000febf0 00024 (v02 DELL )
[ 0.000000] ACPI: XSDT 00000000000fcc3c 00084 (v01 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: FACP 00000000000fcd34 000F4 (v03 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: DSDT 00000000ffe9a4ee 05732 (v01 DELL dt_ex 00001000 INTL 20050624)
[ 0.000000] ACPI: FACS 00000000dbdf9c00 00040
[ 0.000000] ACPI: SSDT 00000000ffe9fd41 000AC (v01 DELL st_ex 00001000 INTL 20050624)
[ 0.000000] ACPI: APIC 00000000000fce28 0016A (v01 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: BOOT 00000000000fcf92 00028 (v01 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: ASF! 00000000000fcfba 00096 (v32 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: MCFG 00000000000fd050 0003E (v01 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: HPET 00000000000fd08e 00038 (v01 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: TCPA 00000000000fd2ea 00032 (v01 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: DMAR 00000000000fd31c 000F8 (v01 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: SLIC 00000000000fd0c6 00176 (v01 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: _RAT 00000000000fdece 00030 (v01 DELL B10K 00000015 ASL 00000061)
[ 0.000000] ACPI: SSDT 00000000dbe4dc00 010F4 (v01 INTEL PPM RCM 80000001 INTL 20061109)
[ 0.000000] (9 early reservations) ==> bootmem [0000000000 - 01725dc000]
[ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
[ 0.000000] #1 [0003555000 - 0003574000] XEN PAGETABLES ==> [0003555000 - 0003574000]
[ 0.000000] #2 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
[ 0.000000] #3 [0001000000 - 0001b415f4] TEXT DATA BSS ==> [0001000000 - 0001b415f4]
[ 0.000000] #4 [0001b62000 - 00029c1000] RAMDISK ==> [0001b62000 - 00029c1000]
[ 0.000000] #5 [00029c1000 - 0003555000] XEN START INFO ==> [00029c1000 - 0003555000]
[ 0.000000] #6 [0001b42000 - 0001b42184] BRK ==> [0001b42000 - 0001b42184]
[ 0.000000] #7 [0000100000 - 00007c2000] PGTABLE ==> [0000100000 - 00007c2000]
[ 0.000000] #8 [0003574000 - 0003909000] PGTABLE ==> [0003574000 - 0003909000]
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000000 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal 0x00100000 -> 0x001725dc
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[4] active PFN ranges
[ 0.000000] 0: 0x00000000 -> 0x00000001
[ 0.000000] 0: 0x00000006 -> 0x0000009e
[ 0.000000] 0: 0x00000100 -> 0x000dbdf9
[ 0.000000] 0: 0x00100000 -> 0x001725dc
[ 0.000000] ACPI: PM-Timer IO Port: 0x808
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x00] disabled)
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
[ 0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
[ 0.000000] IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
[ 0.000000] ACPI: IOAPIC (id[0x0a] address[0xfec88000] gsi_base[48])
[ 0.000000] IOAPIC[2]: apic_id 10, version 32, address 0xfec88000, GSI 48-71
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: BIOS IRQ0 pin2 override ignored.
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
(XEN) io_apic.c:2290:
(XEN) ioapic_guest_write: apic=0, pin=0, irq=0
(XEN) ioapic_guest_write: new_entry=000109f0
(XEN) ioapic_guest_write: old_entry=000100f0 pirq=0
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
(XEN) io_apic.c:2290:
(XEN) ioapic_guest_write: apic=0, pin=2, irq=2
(XEN) ioapic_guest_write: new_entry=00010940
(XEN) ioapic_guest_write: old_entry=00000940 pirq=0
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
(XEN) irq.c:1445: dom0: pirq 0 or irq 3 already mapped
(XEN) io_apic.c:2290:
(XEN) ioapic_guest_write: apic=0, pin=4, irq=4
(XEN) ioapic_guest_write: new_entry=000109f1
(XEN) ioapic_guest_write: old_entry=000009f1 pirq=0
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
(XEN) irq.c:1445: dom0: pirq 0 or irq 5 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 6 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 7 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 8 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 9 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 10 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 11 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 12 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 13 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 14 already mapped
(XEN) irq.c:1445: dom0: pirq 0 or irq 15 already mapped
(XEN) allocated vector b0 for irq 16
(XEN) irq.c:1445: dom0: pirq 0 or irq 16 already mapped
(XEN) allocated vector b8 for irq 17
(XEN) irq.c:1445: dom0: pirq 0 or irq 17 already mapped
(XEN) allocated vector c0 for irq 18
(XEN) irq.c:1445: dom0: pirq 0 or irq 18 already mapped
(XEN) allocated vector c8 for irq 19
(XEN) irq.c:1445: dom0: pirq 0 or irq 19 already mapped
(XEN) allocated vector d0 for irq 20
(XEN) irq.c:1445: dom0: pirq 0 or irq 20 already mapped
(XEN) allocated vector d8 for irq 21
(XEN) irq.c:1445: dom0: pirq 0 or irq 21 already mapped
(XEN) allocated vector 21 for irq 22
(XEN) irq.c:1445: dom0: pirq 0 or irq 22 already mapped
(XEN) allocated vector 29 for irq 23
(XEN) irq.c:1445: dom0: pirq 0 or irq 23 already mapped
(XEN) allocated vector 31 for irq 24
(XEN) irq.c:1445: dom0: pirq 0 or irq 24 already mapped
(XEN) allocated vector 39 for irq 25
(XEN) irq.c:1445: dom0: pirq 0 or irq 25 already mapped
(XEN) allocated vector 41 for irq 26
(XEN) irq.c:1445: dom0: pirq 0 or irq 26 already mapped
(XEN) allocated vector 49 for irq 27
(XEN) irq.c:1445: dom0: pirq 0 or irq 27 already mapped
(XEN) allocated vector 51 for irq 28
(XEN) irq.c:1445: dom0: pirq 0 or irq 28 already mapped
(XEN) allocated vector 59 for irq 29
(XEN) irq.c:1445: dom0: pirq 0 or irq 29 already mapped
(XEN) allocated vector 61 for irq 30
(XEN) irq.c:1445: dom0: pirq 0 or irq 30 already mapped
(XEN) allocated vector 69 for irq 31
(XEN) irq.c:1445: dom0: pirq 0 or irq 31 already mapped
(XEN) allocated vector 71 for irq 32
(XEN) irq.c:1445: dom0: pirq 0 or irq 32 already mapped
(XEN) allocated vector 79 for irq 33
(XEN) irq.c:1445: dom0: pirq 0 or irq 33 already mapped
(XEN) allocated vector 81 for irq 34
(XEN) irq.c:1445: dom0: pirq 0 or irq 34 already mapped
(XEN) allocated vector 89 for irq 35
(XEN) irq.c:1445: dom0: pirq 0 or irq 35 already mapped
(XEN) allocated vector 91 for irq 36
(XEN) irq.c:1445: dom0: pirq 0 or irq 36 already mapped
(XEN) allocated vector 99 for irq 37
(XEN) irq.c:1445: dom0: pirq 0 or irq 37 already mapped
(XEN) allocated vector a1 for irq 38
(XEN) irq.c:1445: dom0: pirq 0 or irq 38 already mapped
(XEN) allocated vector a9 for irq 39
(XEN) irq.c:1445: dom0: pirq 0 or irq 39 already mapped
(XEN) allocated vector b1 for irq 40
(XEN) irq.c:1445: dom0: pirq 0 or irq 40 already mapped
(XEN) allocated vector b9 for irq 41
(XEN) irq.c:1445: dom0: pirq 0 or irq 41 already mapped
(XEN) allocated vector c1 for irq 42
(XEN) irq.c:1445: dom0: pirq 0 or irq 42 already mapped
(XEN) allocated vector c9 for irq 43
(XEN) irq.c:1445: dom0: pirq 0 or irq 43 already mapped
(XEN) allocated vector d1 for irq 44
(XEN) irq.c:1445: dom0: pirq 0 or irq 44 already mapped
(XEN) allocated vector d9 for irq 45
(XEN) irq.c:1445: dom0: pirq 0 or irq 45 already mapped
(XEN) allocated vector 22 for irq 46
(XEN) irq.c:1445: dom0: pirq 0 or irq 46 already mapped
(XEN) allocated vector 2a for irq 47
(XEN) irq.c:1445: dom0: pirq 0 or irq 47 already mapped
(XEN) allocated vector 32 for irq 48
(XEN) irq.c:1445: dom0: pirq 0 or irq 48 already mapped
(XEN) allocated vector 3a for irq 49
(XEN) irq.c:1445: dom0: pirq 0 or irq 49 already mapped
(XEN) allocated vector 42 for irq 50
(XEN) irq.c:1445: dom0: pirq 0 or irq 50 already mapped
(XEN) allocated vector 4a for irq 51
(XEN) irq.c:1445: dom0: pirq 0 or irq 51 already mapped
(XEN) allocated vector 52 for irq 52
(XEN) irq.c:1445: dom0: pirq 0 or irq 52 already mapped
(XEN) allocated vector 5a for irq 53
(XEN) irq.c:1445: dom0: pirq 0 or irq 53 already mapped
(XEN) allocated vector 62 for irq 54
(XEN) irq.c:1445: dom0: pirq 0 or irq 54 already mapped
(XEN) allocated vector 6a for irq 55
(XEN) irq.c:1445: dom0: pirq 0 or irq 55 already mapped
(XEN) allocated vector 72 for irq 56
(XEN) irq.c:1445: dom0: pirq 0 or irq 56 already mapped
(XEN) allocated vector 7a for irq 57
(XEN) irq.c:1445: dom0: pirq 0 or irq 57 already mapped
(XEN) allocated vector 8a for irq 58
(XEN) irq.c:1445: dom0: pirq 0 or irq 58 already mapped
(XEN) allocated vector 92 for irq 59
(XEN) irq.c:1445: dom0: pirq 0 or irq 59 already mapped
(XEN) allocated vector 9a for irq 60
(XEN) irq.c:1445: dom0: pirq 0 or irq 60 already mapped
(XEN) allocated vector a2 for irq 61
(XEN) irq.c:1445: dom0: pirq 0 or irq 61 already mapped
(XEN) allocated vector aa for irq 62
(XEN) irq.c:1445: dom0: pirq 0 or irq 62 already mapped
(XEN) allocated vector b2 for irq 63
(XEN) irq.c:1445: dom0: pirq 0 or irq 63 already mapped
(XEN) allocated vector ba for irq 64
(XEN) irq.c:1445: dom0: pirq 0 or irq 64 already mapped
(XEN) allocated vector c2 for irq 65
(XEN) irq.c:1445: dom0: pirq 0 or irq 65 already mapped
(XEN) allocated vector ca for irq 66
(XEN) irq.c:1445: dom0: pirq 0 or irq 66 already mapped
(XEN) allocated vector d2 for irq 67
(XEN) irq.c:1445: dom0: pirq 0 or irq 67 already mapped
(XEN) allocated vector da for irq 68
(XEN) irq.c:1445: dom0: pirq 0 or irq 68 already mapped
(XEN) allocated vector 23 for irq 69
(XEN) irq.c:1445: dom0: pirq 0 or irq 69 already mapped
(XEN) allocated vector 2b for irq 70
(XEN) irq.c:1445: dom0: pirq 0 or irq 70 already mapped
(XEN) allocated vector 33 for irq 71
(XEN) irq.c:1445: dom0: pirq 0 or irq 71 already mapped
[ 0.000000] PM: Registered nosave memory: 0000000000001000 - 0000000000006000
[ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
[ 0.000000] PM: Registered nosave memory: 00000000dbdf9000 - 00000000dbdfa000
[ 0.000000] PM: Registered nosave memory: 00000000dbdfa000 - 00000000dbe4b000
[ 0.000000] PM: Registered nosave memory: 00000000dbe4b000 - 00000000dbe4c000
[ 0.000000] PM: Registered nosave memory: 00000000dbe4c000 - 00000000dbe4d000
[ 0.000000] PM: Registered nosave memory: 00000000dbe4d000 - 00000000dbe4e000
[ 0.000000] PM: Registered nosave memory: 00000000dbe4e000 - 00000000dc000000
[ 0.000000] PM: Registered nosave memory: 00000000dc000000 - 00000000f8000000
[ 0.000000] PM: Registered nosave memory: 00000000f8000000 - 00000000fd000000
[ 0.000000] PM: Registered nosave memory: 00000000fd000000 - 00000000fe000000
[ 0.000000] PM: Registered nosave memory: 00000000fe000000 - 00000000fed00000
[ 0.000000] PM: Registered nosave memory: 00000000fed00000 - 00000000fee00000
[ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fef00000
[ 0.000000] PM: Registered nosave memory: 00000000fef00000 - 00000000ffb00000
[ 0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000
[ 0.000000] Allocating PCI resources starting at dc000000 (gap: dc000000:1c000000)
[ 0.000000] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
[ 0.000000] PERCPU: Allocated 22 4k pages, static data 88096 bytes
[ 1.942599] Xen: using vcpu_info placement
[ 1.946571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1346468
[ 1.954617] Kernel command line: ro root=UUID=edbcbc29-f3e4-4985-80c1-3c3b0ce24d17 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=hvc0 earlyprintk=xen xen-pciback.hide=(24:00.0)(24:00.1)(25:00.0)(25:00.1) acpi_skip_timer_override
[ 1.977820] PID hash table entries: 4096 (order: 12, 32768 bytes)
[ 1.984930] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 1.994157] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 2.002360] Initializing CPU#0
[ 2.005557] PCI-DMA: Using Xen software bounce buffering for IO (Xen-SWIOTLB)
[ 2.043084] Placing 64MB Xen software IO TLB between ffff880020000000 - ffff880024000000
[ 2.050987] Xen software IO TLB at phys 0x20000000 - 0x24000000
[ 2.081254] Memory: 5270320k/6068080k available (5468k kernel code, 592312k absent, 204716k reserved, 3617k data, 528k init)
[ 2.092292] SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 2.099903] Hierarchical RCU implementation.
[ 2.104129] NR_IRQS:4352 nr_irqs:1024
[ 2.107829] xen_set_ioapic_routing: irq 0 gsi 0 vector 0 ioapic 0 pin 0 triggering 0 polarity 0
(XEN) io_apic.c:2290:
(XEN) ioapic_guest_write: apic=0, pin=0, irq=0
(XEN) ioapic_guest_write: new_entry=000009f0
(XEN) ioapic_guest_write: old_entry=000100f0 pirq=0
(XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
[ 2.137538] xen_set_ioapic_routing: irq 1 gsi 1 vector 1 ioapic 0 pin 1 triggering 0 polarity 0
[ 2.146195] xen_set_ioapic_routing: irq 2 gsi 2 vector 2 ioapic 0 pin 2 triggering 0 polarity 0
[ 2.154850] xen_set_ioapic_routing: irq 3 gsi 3 vector 3 ioapic 0 pin 3 triggering 0 polarity 0
[ 2.163502] xen_set_ioapic_routing: irq 4 gsi 4 vector 4 ioapic 0 pin 4 triggering 0 polarity 0
[ 2.172157] xen_set_ioapic_routing: irq 5 gsi 5 vector 5 ioapic 0 pin 5 triggering 0 polarity 0
[ 2.180810] xen_set_ioapic_routing: irq 6 gsi 6 vector 6 ioapic 0 pin 6 triggering 0 polarity 0
[ 2.189466] xen_set_ioapic_routing: irq 7 gsi 7 vector 7 ioapic 0 pin 7 triggering 0 polarity 0
[ 2.198119] xen_set_ioapic_routing: irq 8 gsi 8 vector 8 ioapic 0 pin 8 triggering 0 polarity 0
[ 2.206775] xen_set_ioapic_routing: irq 9 gsi 9 vector 9 ioapic 0 pin 9 triggering 1 polarity 0
[ 2.215428] xen_set_ioapic_routing: irq 10 gsi 10 vector 10 ioapic 0 pin 10 triggering 0 polarity 0
[ 2.224429] xen_set_ioapic_routing: irq 11 gsi 11 vector 11 ioapic 0 pin 11 triggering 0 polarity 0
[ 2.233429] xen_set_ioapic_routing: irq 12 gsi 12 vector 12 ioapic 0 pin 12 triggering 0 polarity 0
[ 2.242430] xen_set_ioapic_routing: irq 13 gsi 13 vector 13 ioapic 0 pin 13 triggering 0 polarity 0
[ 2.251429] xen_set_ioapic_routing: irq 14 gsi 14 vector 14 ioapic 0 pin 14 triggering 0 polarity 0
[ 2.260430] xen_set_ioapic_routing: irq 15 gsi 15 vector 15 ioapic 0 pin 15 triggering 0 polarity 0
[ 2.269430] Detected 2128.034 MHz processor.
[ 2.279375] Console: colour VGA+ 80x25
[ 2.282946] console handover: boot [xenboot0] -> real [hvc0]
[ 2.288583] installing Xen timer for CPU 0
[ 2.292748] xen: vcpu_time_info placement not supported
[ 2.297998] Calibrating delay loop (skipped), value calculated using timer frequency.. 4256.06 BogoMIPS (lpj=2128034)
[ 2.308684] Security Framework initialized
[ 2.312799] SELinux: Initializing.
[ 2.316361] Mount-cache hash table entries: 256
[ 2.321069] Initializing cgroup subsys ns
[ 2.325002] Initializing cgroup subsys cpuacct
[ 2.329504] Initializing cgroup subsys freezer
[ 2.334028] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 2.338756] CPU: L2 cache: 256K
[ 2.341957] CPU: L3 cache: 4096K
[ 2.345253] CPU: Unsupported number of siblings 16
[ 2.349838] mce: CPU supports 9 MCE banks
[ 2.354190] Performance Counters: unsupported p6 CPU model 26 no PMU driver, software counters only.
[ 2.363344] SMP alternatives: switching to UP code
[ 2.407457] ACPI: Core revision 20090521
[ 2.672546] installing Xen timer for CPU 1
[ 2.676585] SMP alternatives: switching to SMP code
[ 0.000007] Initializing CPU#1
[ 0.000049] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 0.000051] CPU: L2 cache: 256K
[ 0.000053] CPU: L3 cache: 4096K
[ 0.000056] CPU: Unsupported number of siblings 16
[ 0.000059] mce: CPU supports 9 MCE banks
[ 2.719736] installing Xen timer for CPU 2
[ 0.000006] Initializing CPU#2
[ 0.000045] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 0.000048] CPU: L2 cache: 256K
[ 0.000049] CPU: L3 cache: 4096K
[ 0.000052] CPU: Unsupported number of siblings 16
[ 0.000056] mce: CPU supports 9 MCE banks
[ 2.747215] installing Xen timer for CPU 3
[ 0.000006] Initializing CPU#3
[ 0.000045] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 0.000048] CPU: L2 cache: 256K
[ 0.000049] CPU: L3 cache: 4096K
[ 0.000052] CPU: Unsupported number of siblings 16
[ 0.000055] mce: CPU supports 9 MCE banks
[ 2.774649] Brought up 4 CPUs
[ 2.801463] Booting paravirtualized kernel on Xen
[ 2.806067] Xen version: 4.0.0-rc7 (preserve-AD) (dom0)
[ 2.811518] Grant tables using version 2 layout.
[ 2.816053] Grant table initialized
[ 2.819614] Time: 17:07:25 Date: 03/24/10
[ 2.823796] NET: Registered protocol family 16
[ 2.828609] xenbus_probe_init ok
[ 2.832082] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 2.839549] ACPI: bus type pci registered
[ 2.843768] PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
[ 2.850627] PCI: MCFG area at f8000000 reserved in E820
[ 2.869071] PCI: Using MMCONFIG at f8000000 - fbffffff
[ 2.874113] PCI: Using configuration type 1 for base access
[ 2.891413] bio: create slab <bio-0> at 0
[ 2.980580] ACPI: BIOS _OSI(Linux) query ignored
[ 3.004569] ACPI: Interpreter enabled
[ 3.008136] ACPI: (supports S0 S1 S3 S4 S5)
[ 3.012378] ACPI: Using IOAPIC for interrupt routing
[ 3.123980] ACPI Warning: Incorrect checksum in table [TCPA] - 00, should be 7F 20090521 tbutils-246
[ 3.133010] ACPI Warning: Incorrect checksum in table [_RAT] - 00, should be 63 20090521 tbutils-246
[ 3.142303] ACPI: No dock devices found.
[ 3.161083] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 3.166005] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[ 3.171998] pci 0000:00:00.0: PME# disabled
[ 3.176390] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[ 3.182382] pci 0000:00:01.0: PME# disabled
[ 3.186775] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[ 3.192767] pci 0000:00:03.0: PME# disabled
[ 3.197164] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[ 3.203156] pci 0000:00:07.0: PME# disabled
[ 3.208474] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[ 3.214467] pci 0000:00:1a.7: PME# disabled
[ 3.218843] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 3.224852] pci 0000:00:1c.0: PME# disabled
[ 3.229237] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[ 3.235237] pci 0000:00:1c.5: PME# disabled
[ 3.240157] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[ 3.246150] pci 0000:00:1d.7: PME# disabled
[ 3.250643] pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
[ 3.258193] pci 0000:00:1f.0: quirk: region 0880-08bf claimed by ICH6 GPIO
[ 3.265120] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0c00 (mask 007f)
[ 3.272731] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 00e0 (mask 0007)
[ 3.280348] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0900 (mask 003f)
[ 3.288227] pci 0000:00:1f.2: PME# supported from D3hot
[ 3.293357] pci 0000:00:1f.2: PME# disabled
[ 3.297872] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[ 3.303864] pci 0000:01:00.0: PME# disabled
[ 3.309163] pci 0000:06:00.0: PME# supported from D3hot D3cold
[ 3.314902] pci 0000:06:00.0: PME# disabled
[ 3.319459] pci 0000:07:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 3.325976] pci 0000:07:0a.0: PME# disabled
[ 3.330278] pci 0000:00:1e.0: transparent bridge
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:01.0
(XEN) PCI add device 00:03.0
(XEN) PCI add device 00:07.0
(XEN) PCI add device 00:14.0
(XEN) PCI add device 00:14.1
(XEN) PCI add device 00:14.2
(XEN) PCI add device 00:1a.0
(XEN) PCI add device 00:1a.1
(XEN) PCI add device 00:1a.2
(XEN) PCI add device 00:1a.7
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.5
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 03:00.0
(XEN) PCI add device 06:00.0
(XEN) PCI add device 07:0a.0
[ 4.380036] ACPI: PCI Root Bridge [PCI7] (0000:20)
[ 4.384962] pci 0000:20:03.0: PME# supported from D0 D3hot D3cold
[ 4.390955] pci 0000:20:03.0: PME# disabled
[ 4.395365] pci 0000:20:07.0: PME# supported from D0 D3hot D3cold
[ 4.401358] pci 0000:20:07.0: PME# disabled
[ 4.405762] pci 0000:20:09.0: PME# supported from D0 D3hot D3cold
[ 4.411753] pci 0000:20:09.0: PME# disabled
[ 4.416710] pci 0000:22:00.0: PME# supported from D0 D3hot D3cold
[ 4.422704] pci 0000:22:00.0: PME# disabled
[ 4.427207] pci 0000:23:01.0: PME# supported from D0 D3hot D3cold
[ 4.433200] pci 0000:23:01.0: PME# disabled
[ 4.437604] pci 0000:23:02.0: PME# supported from D0 D3hot D3cold
[ 4.443597] pci 0000:23:02.0: PME# disabled
(XEN) PCI add device 20:03.0
(XEN) PCI add device 20:07.0
(XEN) PCI add device 20:09.0
(XEN) PCI add device 20:14.0
(XEN) PCI add device 20:14.1
(XEN) PCI add device 20:14.2
(XEN) PCI add device 22:00.0
(XEN) PCI add device 23:01.0
(XEN) PCI add device 23:02.0
(XEN) PCI add device 24:00.0
(XEN) PCI add device 24:00.1
(XEN) PCI add device 25:00.0
(XEN) PCI add device 25:00.1
[ 4.592250] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
[ 4.599946] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15)
[ 4.607633] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 15)
[ 4.615320] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 15)
[ 4.623005] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *9 10 11 12 15)
[ 4.630684] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
[ 4.639490] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 15)
[ 4.647181] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 15)
[ 4.654695] xenbus_probe_backend_init bus registered ok
[ 4.659879] xenbus_probe_frontend_init bus registered ok
[ 4.665187] xen_balloon: Initialising balloon driver with page order 0.
[ 4.672256] SCSI subsystem initialized
[ 4.676431] usbcore: registered new interface driver usbfs
[ 4.681888] usbcore: registered new interface driver hub
[ 4.687270] usbcore: registered new device driver usb
[ 4.692702] PCI: Using ACPI for IRQ routing
[ 4.697003] IO APIC resources couldn't be allocated.
[ 4.727285] cfg80211: Using static regulatory domain info
[ 4.732586] cfg80211: Regulatory domain: US
[ 4.736826] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 4.744092] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
[ 4.750933] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 4.757770] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 4.764606] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 4.771443] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
[ 4.778280] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
[ 4.785128] cfg80211: Calling CRDA for country: US
[ 4.790015] NetLabel: Initializing
[ 4.793419] NetLabel: domain hash size = 128
[ 4.797833] NetLabel: protocols = UNLABELED CIPSOv4
[ 4.802862] NetLabel: unlabeled traffic allowed by default
[ 4.808653] DMAR:Host address width 40
[ 4.812310] DMAR:DRHD base: 0x000000dfffe000 flags: 0x0
[ 4.817604] IOMMU dfffe000: ver 1:0 cap c90780106f0462 ecap f020fe
[ 4.823816] DMAR:DRHD base: 0x000000fedc0000 flags: 0x1
[ 4.829105] IOMMU fedc0000: ver 1:0 cap c90780106f0462 ecap f020f6
[ 4.835325] DMAR:RMRR base: 0x000000dbe58000 end: 0x000000dbe6ffff
[ 4.841556] DMAR:ATSR flags: 0x0
[ 4.844844] DMAR:ATSR flags: 0x0
[ 4.848133] Not all IO-APIC's listed under remapping hardware
[ 4.854028] IOMMU 0xdfffe000: using Queued invalidation
[ 4.859217] IOMMU 0xfedc0000: using Queued invalidation
[ 4.864493] IOMMU: Setting RMRR:
[ 4.867778] IOMMU: Setting identity map for device 0000:00:1d.0 [0xdbe58000 - 0xdbe70000]
[ 4.876053] IOMMU: Setting identity map for device 0000:00:1d.1 [0xdbe58000 - 0xdbe70000]
[ 4.884264] IOMMU: Setting identity map for device 0000:00:1d.2 [0xdbe58000 - 0xdbe70000]
[ 4.892485] IOMMU: Setting identity map for device 0000:00:1d.7 [0xdbe58000 - 0xdbe70000]
[ 4.900709] IOMMU: Setting identity map for device 0000:00:1a.0 [0xdbe58000 - 0xdbe70000]
[ 4.908928] IOMMU: Setting identity map for device 0000:00:1a.1 [0xdbe58000 - 0xdbe70000]
[ 4.917150] IOMMU: Setting identity map for device 0000:00:1a.2 [0xdbe58000 - 0xdbe70000]
[ 4.925390] IOMMU: Setting identity map for device 0000:00:1a.7 [0xdbe58000 - 0xdbe70000]
[ 4.933612] IOMMU: Prepare 0-16MiB unity mapping for LPC
[ 4.938938] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]
[ 4.946651] VT-d detected invalid descriptor: low=11, high=0
<<hangs here>>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 17:34 ` Nadolski, Ed
@ 2010-03-25 0:04 ` Weidong Han
2010-04-05 18:00 ` Nadolski, Ed
0 siblings, 1 reply; 33+ messages in thread
From: Weidong Han @ 2010-03-25 0:04 UTC (permalink / raw)
To: Nadolski, Ed; +Cc: xen-devel, Keir Fraser, Jan Beulich, Cui, Dexuan
Nadolski, Ed wrote:
>> -----Original Message-----
>> Idea-by: Jan Beulich <jbeulich@novell.com <mailto:jbeulich@novell.com>>
>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>
>> diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
>> --- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010
>> +0800
>> +++ b/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 03:53:21 2010
>> +0800
>> @@ -659,6 +659,23 @@ static int __init acpi_parse_dmar(struct
>> while ( ((unsigned long)entry_header) <
>> (((unsigned long)dmar) + table->length) )
>> {
>> + /*
>> + * entry_header length should not smaller than size of
>> + * any acpi dmar structures. also avoid endless looping
>> + * when the lenght is 0 on some bad BIOSs
>> + */
>> + if ( entry_header->length < sizeof(struct acpi_table_drhd) &&
>> + entry_header->length < sizeof(struct acpi_table_rmrr) &&
>> + entry_header->length < sizeof(struct acpi_table_atsr) &&
>> + entry_header->length < sizeof(struct acpi_table_rhsa) )
>> + {
>> + dprintk(XENLOG_WARNING VTDPREFIX,
>> + "Invalid entry_header length: 0x%x\n",
>> + entry_header->length);
>> + ret = -EINVAL;
>> + break;
>> + }
>> +
>> switch ( entry_header->type )
>> {
>> case ACPI_DMAR_DRHD:
>>
>
>
> I'm also seeing a hang on boot with 4.0.0-rc7, but I am not clear if this is the same issue. Here is the tail end of the trace:
>
> [ 4.802862] NetLabel: unlabeled traffic allowed by default
> [ 4.808653] DMAR:Host address width 40
> [ 4.812310] DMAR:DRHD base: 0x000000dfffe000 flags: 0x0
> [ 4.817604] IOMMU dfffe000: ver 1:0 cap c90780106f0462 ecap f020fe
> [ 4.823816] DMAR:DRHD base: 0x000000fedc0000 flags: 0x1
> [ 4.829105] IOMMU fedc0000: ver 1:0 cap c90780106f0462 ecap f020f6
> [ 4.835325] DMAR:RMRR base: 0x000000dbe58000 end: 0x000000dbe6ffff
> [ 4.841556] DMAR:ATSR flags: 0x0
> [ 4.844844] DMAR:ATSR flags: 0x0
> [ 4.848133] Not all IO-APIC's listed under remapping hardware
> [ 4.854028] IOMMU 0xdfffe000: using Queued invalidation
> [ 4.859217] IOMMU 0xfedc0000: using Queued invalidation
> [ 4.864493] IOMMU: Setting RMRR:
> [ 4.867778] IOMMU: Setting identity map for device 0000:00:1d.0 [0xdbe58000 - 0xdbe70000]
> [ 4.876053] IOMMU: Setting identity map for device 0000:00:1d.1 [0xdbe58000 - 0xdbe70000]
> [ 4.884264] IOMMU: Setting identity map for device 0000:00:1d.2 [0xdbe58000 - 0xdbe70000]
> [ 4.892485] IOMMU: Setting identity map for device 0000:00:1d.7 [0xdbe58000 - 0xdbe70000]
> [ 4.900709] IOMMU: Setting identity map for device 0000:00:1a.0 [0xdbe58000 - 0xdbe70000]
> [ 4.908928] IOMMU: Setting identity map for device 0000:00:1a.1 [0xdbe58000 - 0xdbe70000]
> [ 4.917150] IOMMU: Setting identity map for device 0000:00:1a.2 [0xdbe58000 - 0xdbe70000]
> [ 4.925390] IOMMU: Setting identity map for device 0000:00:1a.7 [0xdbe58000 - 0xdbe70000]
> [ 4.933612] IOMMU: Prepare 0-16MiB unity mapping for LPC
> [ 4.938938] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]
> [ 4.946651] VT-d detected invalid descriptor: low=11, high=0
>
> Then it hangs. This is on a Dell T7500 quad-core Xeon with the latest Dell BIOS (rev. A03). Should I try the suggested patch, or any particular command line or build options? Should I dump the DMAR tables?
>
Your issue is different. It's caused by enabling VT-d in pv-ops dom0.
but pv-ops dom0 should not see DMAR table because its signature is
zapped after xen enables it. Pls have a try with turn off VT-d in pvops
config (# CONFIG_DMAR is not set) , it should solve your issue. But we
need to find why pv-ops dom0 still sees DMAR table in ACPI. Pls dump
DMAR tables.
Regards,
Weidong
> Thanks,
> Ed
>
>
> Here is the full trace:
> __ __ _ _ ___ ___ _____
> \ \/ /___ _ __ | || | / _ \ / _ \ _ __ __|___ |
> \ // _ \ '_ \ | || |_| | | | | | |__| '__/ __| / /
> / \ __/ | | | |__ _| |_| | |_| |__| | | (__ / /
> /_/\_\___|_| |_| |_|(_)___(_)___/ |_| \___/_/
>
> (XEN) Xen version 4.0.0-rc7 (root@) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) Tue Mar 23 17:04:42 MDT 2010
> (XEN) Latest ChangeSet: Tue Mar 23 09:37:59 2010 +0000 21057:0475c567c708
> (XEN) Console output is synchronous.
> (XEN) Command line: iommu=1 acpi_skip_timer_override loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1 console=com1
> (XEN) Video information:
> (XEN) VGA is text mode 80x25, font 8x16
> (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN) Found 1 MBR signatures
> (XEN) Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN) 0000000000000000 - 000000000009e400 (usable)
> (XEN) 00000000000f0000 - 0000000000100000 (reserved)
> (XEN) 0000000000100000 - 00000000dbdf9c00 (usable)
> (XEN) 00000000dbdf9c00 - 00000000dbe4bc00 (ACPI NVS)
> (XEN) 00000000dbe4bc00 - 00000000dbe4dc00 (ACPI data)
> (XEN) 00000000dbe4dc00 - 00000000dc000000 (reserved)
> (XEN) 00000000f8000000 - 00000000fd000000 (reserved)
> (XEN) 00000000fe000000 - 00000000fed00400 (reserved)
> (XEN) 00000000fee00000 - 00000000fef00000 (reserved)
> (XEN) 00000000ffb00000 - 0000000100000000 (reserved)
> (XEN) 0000000100000000 - 00000001a4000000 (usable)
> (XEN) ACPI: RSDP 000FEBF0, 0024 (r2 DELL )
> (XEN) ACPI: XSDT 000FCC3C, 0084 (r1 DELL B10K 15 ASL 61)
> (XEN) ACPI: FACP 000FCD34, 00F4 (r3 DELL B10K 15 ASL 61)
> (XEN) ACPI: DSDT FFE9A4EE, 5732 (r1 DELL dt_ex 1000 INTL 20050624)
> (XEN) ACPI: FACS DBDF9C00, 0040
> (XEN) ACPI: SSDT FFE9FD41, 00AC (r1 DELL st_ex 1000 INTL 20050624)
> (XEN) ACPI: APIC 000FCE28, 016A (r1 DELL B10K 15 ASL 61)
> (XEN) ACPI: BOOT 000FCF92, 0028 (r1 DELL B10K 15 ASL 61)
> (XEN) ACPI: ASF! 000FCFBA, 0096 (r32 DELL B10K 15 ASL 61)
> (XEN) ACPI: MCFG 000FD050, 003E (r1 DELL B10K 15 ASL 61)
> (XEN) ACPI: HPET 000FD08E, 0038 (r1 DELL B10K 15 ASL 61)
> (XEN) ACPI: TCPA 000FD2EA, 0032 (r1 DELL B10K 15 ASL 61)
> (XEN) ACPI: DMAR 000FD31C, 00F8 (r1 DELL B10K 15 ASL 61)
> (XEN) ACPI: SLIC 000FD0C6, 0176 (r1 DELL B10K 15 ASL 61)
> (XEN) ACPI: _RAT 000FDECE, 0030 (r1 DELL B10K 15 ASL 61)
> (XEN) ACPI: SSDT DBE4DC00, 10F4 (r1 INTEL PPM RCM 80000001 INTL 20061109)
> (XEN) System RAM: 6104MB (6250856kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at 0000000000000000-00000001a4000000
> (XEN) Domain heap initialised
> (XEN) DMI 2.5 present.
> (XEN) Using APIC driver default
> (XEN) ACPI: PM-Timer IO Port: 0x808
> (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
> (XEN) ACPI: wakeup_vec[dbdf9c0c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee00000
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) Processor #0 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
> (XEN) Processor #2 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
> (XEN) Processor #4 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
> (XEN) Processor #6 7:10 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x19] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC (acpi_id[0x20] lapic_id[0x00] disabled)
> (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
> (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
> (XEN) ACPI: IOAPIC (id[0x0a] address[0xfec88000] gsi_base[48])
> (XEN) IOAPIC[2]: apic_id 10, version 32, address 0xfec88000, GSI 48-71
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> (XEN) ACPI: BIOS IRQ0 pin2 override ignored.
> (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> (XEN) ACPI: IRQ9 used by override.
> (XEN) Enabling APIC mode: Flat. Using 3 I/O APICs
> (XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
> (XEN) PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
> (XEN) PCI: MCFG area at f8000000 reserved in E820
> (XEN) Using ACPI (MADT) for SMP configuration information
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 2128.034 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) VMX: Supported advanced features:
> (XEN) - APIC MMIO access virtualisation
> (XEN) - APIC TPR shadow
> (XEN) - Extended Page Tables (EPT)
> (XEN) - Virtual-Processor Identifiers (VPID)
> (XEN) - Virtual NMI
> (XEN) - MSR direct-access bitmap
> (XEN) HVM: ASIDs enabled.
> (XEN) HVM: VMX enabled
> (XEN) HVM: Hardware Assisted Paging detected.
> (XEN) Intel machine check reporting enabled
> (XEN) Intel VT-d Snoop Control supported.
> (XEN) Intel VT-d DMA Passthrough not supported.
> (XEN) Intel VT-d Queued Invalidation supported.
> (XEN) Intel VT-d Interrupt Remapping not supported.
> (XEN) I/O virtualisation enabled
> (XEN) I/O virtualisation for PV guests disabled
> (XEN) Total of 4 processors activated.
> (XEN) ENABLING IO-APIC IRQs
> (XEN) -> Using new ACK method
> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=0 apic2=-1 pin2=-1
> (XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> (XEN) ...trying to set up timer (IRQ0) through the 8259A ... failed.
> (XEN) ...trying to set up timer as Virtual Wire IRQ... works.
> (XEN) TSC is reliable, synchronization unnecessary
> (XEN) Platform timer is 14.318MHz HPET
> ÿ(XEN) Allocated console ring of 32 KiB.
> (XEN) microcode.c:73:d32767 microcode: CPU1 resumed
> (XEN) Brought up 4 CPUs
> (XEN) microcode.c:73:d32767 microcode: CPU2 resumed
> (XEN) microcode.c:73:d32767 microcode: CPU3 resumed
> (XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
> (XEN) ACPI sleep modes: S3
> (XEN) mcheck_poll: Machine check polling timer started.
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Xen kernel: 64-bit, lsb, compat32
> (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1b62000
> (XEN) PHYSICAL MEMORY ARRANGEMENT:
> (XEN) Dom0 alloc.: 0000000198000000->000000019c000000 (1500636 pages to be allocated)
> (XEN) VIRTUAL MEMORY ARRANGEMENT:
> (XEN) Loaded kernel: ffffffff81000000->ffffffff81b62000
> (XEN) Init. ramdisk: ffffffff81b62000->ffffffff829c1000
> (XEN) Phys-Mach map: ffffffff829c1000->ffffffff83553ee0
> (XEN) Start info: ffffffff83554000->ffffffff835544b4
> (XEN) Page tables: ffffffff83555000->ffffffff83574000
> (XEN) Boot stack: ffffffff83574000->ffffffff83575000
> (XEN) TOTAL: ffffffff80000000->ffffffff83800000
> (XEN) ENTRY ADDRESS: ffffffff818f6a20
> (XEN) Dom0 has maximum 4 VCPUs
> (XEN) Scrubbing Free RAM: .done.
> (XEN) Xen trace buffers: disabled
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) **********************************************
> (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
> (XEN) ******* This option is intended to aid debugging of Xen by ensuring
> (XEN) ******* that all output is synchronously delivered on the serial line.
> (XEN) ******* However it can introduce SIGNIFICANT latencies and affect
> (XEN) ******* timekeeping. It is NOT recommended for production use!
> (XEN) **********************************************
> (XEN) 3... 2... 1...
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
> (XEN) Freed 168kB init memory.
> mapping kernel into physical memory
> Xen: setup ISA identity maps
> about to get started...
> [ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Linux version 2.6.31.12 (root@truckee) (gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC) ) #1 SMP Tue Mar 23 16:46:07 MDT 2010
> [ 0.000000] Command line: ro root=UUID=edbcbc29-f3e4-4985-80c1-3c3b0ce24d17 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=hvc0 earlyprintk=xen xen-pciback.hide=(24:00.0)(24:00.1)(25:00.0)(25:00.1) acpi_skip_timer_override
> [ 0.000000] KERNEL supported cpus:
> [ 0.000000] Intel GenuineIntel
> [ 0.000000] AMD AuthenticAMD
> [ 0.000000] Centaur CentaurHauls
> [ 0.000000] xen_release_chunk: looking at area pfn 9f-a0: 1 pages freed
> [ 0.000000] xen_release_chunk: looking at area pfn dc000-f8000: 114688 pages freed
> [ 0.000000] xen_release_chunk: looking at area pfn fd000-fe000: 4096 pages freed
> [ 0.000000] xen_release_chunk: looking at area pfn fed01-fee00: 255 pages freed
> [ 0.000000] xen_release_chunk: looking at area pfn fef00-ffb00: 3072 pages freed
> [ 0.000000] released 122112 pages of unused memory
> [ 0.000000] BIOS-provided physical RAM map:
> [ 0.000000] Xen: 0000000000000000 - 000000000009e400 (usable)
> [ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved)
> [ 0.000000] Xen: 0000000000100000 - 00000000dbdf9c00 (usable)
> [ 0.000000] Xen: 00000000dbdf9c00 - 00000000dbe4bc00 (ACPI NVS)
> [ 0.000000] Xen: 00000000dbe4bc00 - 00000000dbe4dc00 (ACPI data)
> [ 0.000000] Xen: 00000000dbe4dc00 - 00000000dc000000 (reserved)
> [ 0.000000] Xen: 00000000f8000000 - 00000000fd000000 (reserved)
> [ 0.000000] Xen: 00000000fe000000 - 00000000fed00400 (reserved)
> [ 0.000000] Xen: 00000000fee00000 - 00000000fef00000 (reserved)
> [ 0.000000] Xen: 00000000ffb00000 - 0000000100000000 (reserved)
> [ 0.000000] Xen: 0000000100000000 - 00000001725dc000 (usable)
> [ 0.000000] console [xenboot0] enabled
> [ 0.000000] DMI 2.5 present.
> [ 0.000000] last_pfn = 0x1725dc max_arch_pfn = 0x400000000
> [ 0.000000] last_pfn = 0xdbdf9 max_arch_pfn = 0x400000000
> [ 0.000000] Scanning 1 areas for low memory corruption
> [ 0.000000] modified physical RAM map:
> [ 0.000000] modified: 0000000000000000 - 0000000000001000 (usable)
> [ 0.000000] modified: 0000000000001000 - 0000000000006000 (reserved)
> [ 0.000000] modified: 0000000000006000 - 000000000009e400 (usable)
> [ 0.000000] modified: 00000000000a0000 - 0000000000100000 (reserved)
> [ 0.000000] modified: 0000000000100000 - 00000000dbdf9c00 (usable)
> [ 0.000000] modified: 00000000dbdf9c00 - 00000000dbe4bc00 (ACPI NVS)
> [ 0.000000] modified: 00000000dbe4bc00 - 00000000dbe4dc00 (ACPI data)
> [ 0.000000] modified: 00000000dbe4dc00 - 00000000dc000000 (reserved)
> [ 0.000000] modified: 00000000f8000000 - 00000000fd000000 (reserved)
> [ 0.000000] modified: 00000000fe000000 - 00000000fed00400 (reserved)
> [ 0.000000] modified: 00000000fee00000 - 00000000fef00000 (reserved)
> [ 0.000000] modified: 00000000ffb00000 - 0000000100000000 (reserved)
> [ 0.000000] modified: 0000000100000000 - 00000001725dc000 (usable)
> [ 0.000000] init_memory_mapping: 0000000000000000-00000000dbdf9000
> [ 0.000000] init_memory_mapping: 0000000100000000-00000001725dc000
> [ 0.000000] RAMDISK: 01b62000 - 029c1000
> [ 0.000000] ACPI: RSDP 00000000000febf0 00024 (v02 DELL )
> [ 0.000000] ACPI: XSDT 00000000000fcc3c 00084 (v01 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: FACP 00000000000fcd34 000F4 (v03 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: DSDT 00000000ffe9a4ee 05732 (v01 DELL dt_ex 00001000 INTL 20050624)
> [ 0.000000] ACPI: FACS 00000000dbdf9c00 00040
> [ 0.000000] ACPI: SSDT 00000000ffe9fd41 000AC (v01 DELL st_ex 00001000 INTL 20050624)
> [ 0.000000] ACPI: APIC 00000000000fce28 0016A (v01 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: BOOT 00000000000fcf92 00028 (v01 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: ASF! 00000000000fcfba 00096 (v32 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: MCFG 00000000000fd050 0003E (v01 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: HPET 00000000000fd08e 00038 (v01 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: TCPA 00000000000fd2ea 00032 (v01 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: DMAR 00000000000fd31c 000F8 (v01 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: SLIC 00000000000fd0c6 00176 (v01 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: _RAT 00000000000fdece 00030 (v01 DELL B10K 00000015 ASL 00000061)
> [ 0.000000] ACPI: SSDT 00000000dbe4dc00 010F4 (v01 INTEL PPM RCM 80000001 INTL 20061109)
> [ 0.000000] (9 early reservations) ==> bootmem [0000000000 - 01725dc000]
> [ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
> [ 0.000000] #1 [0003555000 - 0003574000] XEN PAGETABLES ==> [0003555000 - 0003574000]
> [ 0.000000] #2 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
> [ 0.000000] #3 [0001000000 - 0001b415f4] TEXT DATA BSS ==> [0001000000 - 0001b415f4]
> [ 0.000000] #4 [0001b62000 - 00029c1000] RAMDISK ==> [0001b62000 - 00029c1000]
> [ 0.000000] #5 [00029c1000 - 0003555000] XEN START INFO ==> [00029c1000 - 0003555000]
> [ 0.000000] #6 [0001b42000 - 0001b42184] BRK ==> [0001b42000 - 0001b42184]
> [ 0.000000] #7 [0000100000 - 00007c2000] PGTABLE ==> [0000100000 - 00007c2000]
> [ 0.000000] #8 [0003574000 - 0003909000] PGTABLE ==> [0003574000 - 0003909000]
> [ 0.000000] Zone PFN ranges:
> [ 0.000000] DMA 0x00000000 -> 0x00001000
> [ 0.000000] DMA32 0x00001000 -> 0x00100000
> [ 0.000000] Normal 0x00100000 -> 0x001725dc
> [ 0.000000] Movable zone start PFN for each node
> [ 0.000000] early_node_map[4] active PFN ranges
> [ 0.000000] 0: 0x00000000 -> 0x00000001
> [ 0.000000] 0: 0x00000006 -> 0x0000009e
> [ 0.000000] 0: 0x00000100 -> 0x000dbdf9
> [ 0.000000] 0: 0x00100000 -> 0x001725dc
> [ 0.000000] ACPI: PM-Timer IO Port: 0x808
> [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x01] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x02] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x03] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x00] disabled)
> [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
> [ 0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
> [ 0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> [ 0.000000] ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24])
> [ 0.000000] IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47
> [ 0.000000] ACPI: IOAPIC (id[0x0a] address[0xfec88000] gsi_base[48])
> [ 0.000000] IOAPIC[2]: apic_id 10, version 32, address 0xfec88000, GSI 48-71
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [ 0.000000] ACPI: BIOS IRQ0 pin2 override ignored.
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> [ 0.000000] Using ACPI (MADT) for SMP configuration information
> [ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
> [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> (XEN) io_apic.c:2290:
> (XEN) ioapic_guest_write: apic=0, pin=0, irq=0
> (XEN) ioapic_guest_write: new_entry=000109f0
> (XEN) ioapic_guest_write: old_entry=000100f0 pirq=0
> (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
> (XEN) io_apic.c:2290:
> (XEN) ioapic_guest_write: apic=0, pin=2, irq=2
> (XEN) ioapic_guest_write: new_entry=00010940
> (XEN) ioapic_guest_write: old_entry=00000940 pirq=0
> (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
> (XEN) irq.c:1445: dom0: pirq 0 or irq 3 already mapped
> (XEN) io_apic.c:2290:
> (XEN) ioapic_guest_write: apic=0, pin=4, irq=4
> (XEN) ioapic_guest_write: new_entry=000109f1
> (XEN) ioapic_guest_write: old_entry=000009f1 pirq=0
> (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
> (XEN) irq.c:1445: dom0: pirq 0 or irq 5 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 6 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 7 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 8 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 9 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 10 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 11 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 12 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 13 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 14 already mapped
> (XEN) irq.c:1445: dom0: pirq 0 or irq 15 already mapped
> (XEN) allocated vector b0 for irq 16
> (XEN) irq.c:1445: dom0: pirq 0 or irq 16 already mapped
> (XEN) allocated vector b8 for irq 17
> (XEN) irq.c:1445: dom0: pirq 0 or irq 17 already mapped
> (XEN) allocated vector c0 for irq 18
> (XEN) irq.c:1445: dom0: pirq 0 or irq 18 already mapped
> (XEN) allocated vector c8 for irq 19
> (XEN) irq.c:1445: dom0: pirq 0 or irq 19 already mapped
> (XEN) allocated vector d0 for irq 20
> (XEN) irq.c:1445: dom0: pirq 0 or irq 20 already mapped
> (XEN) allocated vector d8 for irq 21
> (XEN) irq.c:1445: dom0: pirq 0 or irq 21 already mapped
> (XEN) allocated vector 21 for irq 22
> (XEN) irq.c:1445: dom0: pirq 0 or irq 22 already mapped
> (XEN) allocated vector 29 for irq 23
> (XEN) irq.c:1445: dom0: pirq 0 or irq 23 already mapped
> (XEN) allocated vector 31 for irq 24
> (XEN) irq.c:1445: dom0: pirq 0 or irq 24 already mapped
> (XEN) allocated vector 39 for irq 25
> (XEN) irq.c:1445: dom0: pirq 0 or irq 25 already mapped
> (XEN) allocated vector 41 for irq 26
> (XEN) irq.c:1445: dom0: pirq 0 or irq 26 already mapped
> (XEN) allocated vector 49 for irq 27
> (XEN) irq.c:1445: dom0: pirq 0 or irq 27 already mapped
> (XEN) allocated vector 51 for irq 28
> (XEN) irq.c:1445: dom0: pirq 0 or irq 28 already mapped
> (XEN) allocated vector 59 for irq 29
> (XEN) irq.c:1445: dom0: pirq 0 or irq 29 already mapped
> (XEN) allocated vector 61 for irq 30
> (XEN) irq.c:1445: dom0: pirq 0 or irq 30 already mapped
> (XEN) allocated vector 69 for irq 31
> (XEN) irq.c:1445: dom0: pirq 0 or irq 31 already mapped
> (XEN) allocated vector 71 for irq 32
> (XEN) irq.c:1445: dom0: pirq 0 or irq 32 already mapped
> (XEN) allocated vector 79 for irq 33
> (XEN) irq.c:1445: dom0: pirq 0 or irq 33 already mapped
> (XEN) allocated vector 81 for irq 34
> (XEN) irq.c:1445: dom0: pirq 0 or irq 34 already mapped
> (XEN) allocated vector 89 for irq 35
> (XEN) irq.c:1445: dom0: pirq 0 or irq 35 already mapped
> (XEN) allocated vector 91 for irq 36
> (XEN) irq.c:1445: dom0: pirq 0 or irq 36 already mapped
> (XEN) allocated vector 99 for irq 37
> (XEN) irq.c:1445: dom0: pirq 0 or irq 37 already mapped
> (XEN) allocated vector a1 for irq 38
> (XEN) irq.c:1445: dom0: pirq 0 or irq 38 already mapped
> (XEN) allocated vector a9 for irq 39
> (XEN) irq.c:1445: dom0: pirq 0 or irq 39 already mapped
> (XEN) allocated vector b1 for irq 40
> (XEN) irq.c:1445: dom0: pirq 0 or irq 40 already mapped
> (XEN) allocated vector b9 for irq 41
> (XEN) irq.c:1445: dom0: pirq 0 or irq 41 already mapped
> (XEN) allocated vector c1 for irq 42
> (XEN) irq.c:1445: dom0: pirq 0 or irq 42 already mapped
> (XEN) allocated vector c9 for irq 43
> (XEN) irq.c:1445: dom0: pirq 0 or irq 43 already mapped
> (XEN) allocated vector d1 for irq 44
> (XEN) irq.c:1445: dom0: pirq 0 or irq 44 already mapped
> (XEN) allocated vector d9 for irq 45
> (XEN) irq.c:1445: dom0: pirq 0 or irq 45 already mapped
> (XEN) allocated vector 22 for irq 46
> (XEN) irq.c:1445: dom0: pirq 0 or irq 46 already mapped
> (XEN) allocated vector 2a for irq 47
> (XEN) irq.c:1445: dom0: pirq 0 or irq 47 already mapped
> (XEN) allocated vector 32 for irq 48
> (XEN) irq.c:1445: dom0: pirq 0 or irq 48 already mapped
> (XEN) allocated vector 3a for irq 49
> (XEN) irq.c:1445: dom0: pirq 0 or irq 49 already mapped
> (XEN) allocated vector 42 for irq 50
> (XEN) irq.c:1445: dom0: pirq 0 or irq 50 already mapped
> (XEN) allocated vector 4a for irq 51
> (XEN) irq.c:1445: dom0: pirq 0 or irq 51 already mapped
> (XEN) allocated vector 52 for irq 52
> (XEN) irq.c:1445: dom0: pirq 0 or irq 52 already mapped
> (XEN) allocated vector 5a for irq 53
> (XEN) irq.c:1445: dom0: pirq 0 or irq 53 already mapped
> (XEN) allocated vector 62 for irq 54
> (XEN) irq.c:1445: dom0: pirq 0 or irq 54 already mapped
> (XEN) allocated vector 6a for irq 55
> (XEN) irq.c:1445: dom0: pirq 0 or irq 55 already mapped
> (XEN) allocated vector 72 for irq 56
> (XEN) irq.c:1445: dom0: pirq 0 or irq 56 already mapped
> (XEN) allocated vector 7a for irq 57
> (XEN) irq.c:1445: dom0: pirq 0 or irq 57 already mapped
> (XEN) allocated vector 8a for irq 58
> (XEN) irq.c:1445: dom0: pirq 0 or irq 58 already mapped
> (XEN) allocated vector 92 for irq 59
> (XEN) irq.c:1445: dom0: pirq 0 or irq 59 already mapped
> (XEN) allocated vector 9a for irq 60
> (XEN) irq.c:1445: dom0: pirq 0 or irq 60 already mapped
> (XEN) allocated vector a2 for irq 61
> (XEN) irq.c:1445: dom0: pirq 0 or irq 61 already mapped
> (XEN) allocated vector aa for irq 62
> (XEN) irq.c:1445: dom0: pirq 0 or irq 62 already mapped
> (XEN) allocated vector b2 for irq 63
> (XEN) irq.c:1445: dom0: pirq 0 or irq 63 already mapped
> (XEN) allocated vector ba for irq 64
> (XEN) irq.c:1445: dom0: pirq 0 or irq 64 already mapped
> (XEN) allocated vector c2 for irq 65
> (XEN) irq.c:1445: dom0: pirq 0 or irq 65 already mapped
> (XEN) allocated vector ca for irq 66
> (XEN) irq.c:1445: dom0: pirq 0 or irq 66 already mapped
> (XEN) allocated vector d2 for irq 67
> (XEN) irq.c:1445: dom0: pirq 0 or irq 67 already mapped
> (XEN) allocated vector da for irq 68
> (XEN) irq.c:1445: dom0: pirq 0 or irq 68 already mapped
> (XEN) allocated vector 23 for irq 69
> (XEN) irq.c:1445: dom0: pirq 0 or irq 69 already mapped
> (XEN) allocated vector 2b for irq 70
> (XEN) irq.c:1445: dom0: pirq 0 or irq 70 already mapped
> (XEN) allocated vector 33 for irq 71
> (XEN) irq.c:1445: dom0: pirq 0 or irq 71 already mapped
> [ 0.000000] PM: Registered nosave memory: 0000000000001000 - 0000000000006000
> [ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
> [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
> [ 0.000000] PM: Registered nosave memory: 00000000dbdf9000 - 00000000dbdfa000
> [ 0.000000] PM: Registered nosave memory: 00000000dbdfa000 - 00000000dbe4b000
> [ 0.000000] PM: Registered nosave memory: 00000000dbe4b000 - 00000000dbe4c000
> [ 0.000000] PM: Registered nosave memory: 00000000dbe4c000 - 00000000dbe4d000
> [ 0.000000] PM: Registered nosave memory: 00000000dbe4d000 - 00000000dbe4e000
> [ 0.000000] PM: Registered nosave memory: 00000000dbe4e000 - 00000000dc000000
> [ 0.000000] PM: Registered nosave memory: 00000000dc000000 - 00000000f8000000
> [ 0.000000] PM: Registered nosave memory: 00000000f8000000 - 00000000fd000000
> [ 0.000000] PM: Registered nosave memory: 00000000fd000000 - 00000000fe000000
> [ 0.000000] PM: Registered nosave memory: 00000000fe000000 - 00000000fed00000
> [ 0.000000] PM: Registered nosave memory: 00000000fed00000 - 00000000fee00000
> [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fef00000
> [ 0.000000] PM: Registered nosave memory: 00000000fef00000 - 00000000ffb00000
> [ 0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000
> [ 0.000000] Allocating PCI resources starting at dc000000 (gap: dc000000:1c000000)
> [ 0.000000] NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:4 nr_node_ids:1
> [ 0.000000] PERCPU: Allocated 22 4k pages, static data 88096 bytes
> [ 1.942599] Xen: using vcpu_info placement
> [ 1.946571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1346468
> [ 1.954617] Kernel command line: ro root=UUID=edbcbc29-f3e4-4985-80c1-3c3b0ce24d17 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us console=hvc0 earlyprintk=xen xen-pciback.hide=(24:00.0)(24:00.1)(25:00.0)(25:00.1) acpi_skip_timer_override
> [ 1.977820] PID hash table entries: 4096 (order: 12, 32768 bytes)
> [ 1.984930] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
> [ 1.994157] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
> [ 2.002360] Initializing CPU#0
> [ 2.005557] PCI-DMA: Using Xen software bounce buffering for IO (Xen-SWIOTLB)
> [ 2.043084] Placing 64MB Xen software IO TLB between ffff880020000000 - ffff880024000000
> [ 2.050987] Xen software IO TLB at phys 0x20000000 - 0x24000000
> [ 2.081254] Memory: 5270320k/6068080k available (5468k kernel code, 592312k absent, 204716k reserved, 3617k data, 528k init)
> [ 2.092292] SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [ 2.099903] Hierarchical RCU implementation.
> [ 2.104129] NR_IRQS:4352 nr_irqs:1024
> [ 2.107829] xen_set_ioapic_routing: irq 0 gsi 0 vector 0 ioapic 0 pin 0 triggering 0 polarity 0
> (XEN) io_apic.c:2290:
> (XEN) ioapic_guest_write: apic=0, pin=0, irq=0
> (XEN) ioapic_guest_write: new_entry=000009f0
> (XEN) ioapic_guest_write: old_entry=000100f0 pirq=0
> (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ!
> [ 2.137538] xen_set_ioapic_routing: irq 1 gsi 1 vector 1 ioapic 0 pin 1 triggering 0 polarity 0
> [ 2.146195] xen_set_ioapic_routing: irq 2 gsi 2 vector 2 ioapic 0 pin 2 triggering 0 polarity 0
> [ 2.154850] xen_set_ioapic_routing: irq 3 gsi 3 vector 3 ioapic 0 pin 3 triggering 0 polarity 0
> [ 2.163502] xen_set_ioapic_routing: irq 4 gsi 4 vector 4 ioapic 0 pin 4 triggering 0 polarity 0
> [ 2.172157] xen_set_ioapic_routing: irq 5 gsi 5 vector 5 ioapic 0 pin 5 triggering 0 polarity 0
> [ 2.180810] xen_set_ioapic_routing: irq 6 gsi 6 vector 6 ioapic 0 pin 6 triggering 0 polarity 0
> [ 2.189466] xen_set_ioapic_routing: irq 7 gsi 7 vector 7 ioapic 0 pin 7 triggering 0 polarity 0
> [ 2.198119] xen_set_ioapic_routing: irq 8 gsi 8 vector 8 ioapic 0 pin 8 triggering 0 polarity 0
> [ 2.206775] xen_set_ioapic_routing: irq 9 gsi 9 vector 9 ioapic 0 pin 9 triggering 1 polarity 0
> [ 2.215428] xen_set_ioapic_routing: irq 10 gsi 10 vector 10 ioapic 0 pin 10 triggering 0 polarity 0
> [ 2.224429] xen_set_ioapic_routing: irq 11 gsi 11 vector 11 ioapic 0 pin 11 triggering 0 polarity 0
> [ 2.233429] xen_set_ioapic_routing: irq 12 gsi 12 vector 12 ioapic 0 pin 12 triggering 0 polarity 0
> [ 2.242430] xen_set_ioapic_routing: irq 13 gsi 13 vector 13 ioapic 0 pin 13 triggering 0 polarity 0
> [ 2.251429] xen_set_ioapic_routing: irq 14 gsi 14 vector 14 ioapic 0 pin 14 triggering 0 polarity 0
> [ 2.260430] xen_set_ioapic_routing: irq 15 gsi 15 vector 15 ioapic 0 pin 15 triggering 0 polarity 0
> [ 2.269430] Detected 2128.034 MHz processor.
> [ 2.279375] Console: colour VGA+ 80x25
> [ 2.282946] console handover: boot [xenboot0] -> real [hvc0]
> [ 2.288583] installing Xen timer for CPU 0
> [ 2.292748] xen: vcpu_time_info placement not supported
> [ 2.297998] Calibrating delay loop (skipped), value calculated using timer frequency.. 4256.06 BogoMIPS (lpj=2128034)
> [ 2.308684] Security Framework initialized
> [ 2.312799] SELinux: Initializing.
> [ 2.316361] Mount-cache hash table entries: 256
> [ 2.321069] Initializing cgroup subsys ns
> [ 2.325002] Initializing cgroup subsys cpuacct
> [ 2.329504] Initializing cgroup subsys freezer
> [ 2.334028] CPU: L1 I cache: 32K, L1 D cache: 32K
> [ 2.338756] CPU: L2 cache: 256K
> [ 2.341957] CPU: L3 cache: 4096K
> [ 2.345253] CPU: Unsupported number of siblings 16
> [ 2.349838] mce: CPU supports 9 MCE banks
> [ 2.354190] Performance Counters: unsupported p6 CPU model 26 no PMU driver, software counters only.
> [ 2.363344] SMP alternatives: switching to UP code
> [ 2.407457] ACPI: Core revision 20090521
> [ 2.672546] installing Xen timer for CPU 1
> [ 2.676585] SMP alternatives: switching to SMP code
> [ 0.000007] Initializing CPU#1
> [ 0.000049] CPU: L1 I cache: 32K, L1 D cache: 32K
> [ 0.000051] CPU: L2 cache: 256K
> [ 0.000053] CPU: L3 cache: 4096K
> [ 0.000056] CPU: Unsupported number of siblings 16
> [ 0.000059] mce: CPU supports 9 MCE banks
> [ 2.719736] installing Xen timer for CPU 2
> [ 0.000006] Initializing CPU#2
> [ 0.000045] CPU: L1 I cache: 32K, L1 D cache: 32K
> [ 0.000048] CPU: L2 cache: 256K
> [ 0.000049] CPU: L3 cache: 4096K
> [ 0.000052] CPU: Unsupported number of siblings 16
> [ 0.000056] mce: CPU supports 9 MCE banks
> [ 2.747215] installing Xen timer for CPU 3
> [ 0.000006] Initializing CPU#3
> [ 0.000045] CPU: L1 I cache: 32K, L1 D cache: 32K
> [ 0.000048] CPU: L2 cache: 256K
> [ 0.000049] CPU: L3 cache: 4096K
> [ 0.000052] CPU: Unsupported number of siblings 16
> [ 0.000055] mce: CPU supports 9 MCE banks
> [ 2.774649] Brought up 4 CPUs
> [ 2.801463] Booting paravirtualized kernel on Xen
> [ 2.806067] Xen version: 4.0.0-rc7 (preserve-AD) (dom0)
> [ 2.811518] Grant tables using version 2 layout.
> [ 2.816053] Grant table initialized
> [ 2.819614] Time: 17:07:25 Date: 03/24/10
> [ 2.823796] NET: Registered protocol family 16
> [ 2.828609] xenbus_probe_init ok
> [ 2.832082] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
> [ 2.839549] ACPI: bus type pci registered
> [ 2.843768] PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
> [ 2.850627] PCI: MCFG area at f8000000 reserved in E820
> [ 2.869071] PCI: Using MMCONFIG at f8000000 - fbffffff
> [ 2.874113] PCI: Using configuration type 1 for base access
> [ 2.891413] bio: create slab <bio-0> at 0
> [ 2.980580] ACPI: BIOS _OSI(Linux) query ignored
> [ 3.004569] ACPI: Interpreter enabled
> [ 3.008136] ACPI: (supports S0 S1 S3 S4 S5)
> [ 3.012378] ACPI: Using IOAPIC for interrupt routing
> [ 3.123980] ACPI Warning: Incorrect checksum in table [TCPA] - 00, should be 7F 20090521 tbutils-246
> [ 3.133010] ACPI Warning: Incorrect checksum in table [_RAT] - 00, should be 63 20090521 tbutils-246
> [ 3.142303] ACPI: No dock devices found.
> [ 3.161083] ACPI: PCI Root Bridge [PCI0] (0000:00)
> [ 3.166005] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
> [ 3.171998] pci 0000:00:00.0: PME# disabled
> [ 3.176390] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
> [ 3.182382] pci 0000:00:01.0: PME# disabled
> [ 3.186775] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
> [ 3.192767] pci 0000:00:03.0: PME# disabled
> [ 3.197164] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
> [ 3.203156] pci 0000:00:07.0: PME# disabled
> [ 3.208474] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
> [ 3.214467] pci 0000:00:1a.7: PME# disabled
> [ 3.218843] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
> [ 3.224852] pci 0000:00:1c.0: PME# disabled
> [ 3.229237] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
> [ 3.235237] pci 0000:00:1c.5: PME# disabled
> [ 3.240157] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
> [ 3.246150] pci 0000:00:1d.7: PME# disabled
> [ 3.250643] pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
> [ 3.258193] pci 0000:00:1f.0: quirk: region 0880-08bf claimed by ICH6 GPIO
> [ 3.265120] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0c00 (mask 007f)
> [ 3.272731] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 00e0 (mask 0007)
> [ 3.280348] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 3 PIO at 0900 (mask 003f)
> [ 3.288227] pci 0000:00:1f.2: PME# supported from D3hot
> [ 3.293357] pci 0000:00:1f.2: PME# disabled
> [ 3.297872] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
> [ 3.303864] pci 0000:01:00.0: PME# disabled
> [ 3.309163] pci 0000:06:00.0: PME# supported from D3hot D3cold
> [ 3.314902] pci 0000:06:00.0: PME# disabled
> [ 3.319459] pci 0000:07:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
> [ 3.325976] pci 0000:07:0a.0: PME# disabled
> [ 3.330278] pci 0000:00:1e.0: transparent bridge
> (XEN) PCI add device 00:00.0
> (XEN) PCI add device 00:01.0
> (XEN) PCI add device 00:03.0
> (XEN) PCI add device 00:07.0
> (XEN) PCI add device 00:14.0
> (XEN) PCI add device 00:14.1
> (XEN) PCI add device 00:14.2
> (XEN) PCI add device 00:1a.0
> (XEN) PCI add device 00:1a.1
> (XEN) PCI add device 00:1a.2
> (XEN) PCI add device 00:1a.7
> (XEN) PCI add device 00:1c.0
> (XEN) PCI add device 00:1c.5
> (XEN) PCI add device 00:1d.0
> (XEN) PCI add device 00:1d.1
> (XEN) PCI add device 00:1d.2
> (XEN) PCI add device 00:1d.7
> (XEN) PCI add device 00:1e.0
> (XEN) PCI add device 00:1f.0
> (XEN) PCI add device 00:1f.2
> (XEN) PCI add device 00:1f.3
> (XEN) PCI add device 01:00.0
> (XEN) PCI add device 03:00.0
> (XEN) PCI add device 06:00.0
> (XEN) PCI add device 07:0a.0
> [ 4.380036] ACPI: PCI Root Bridge [PCI7] (0000:20)
> [ 4.384962] pci 0000:20:03.0: PME# supported from D0 D3hot D3cold
> [ 4.390955] pci 0000:20:03.0: PME# disabled
> [ 4.395365] pci 0000:20:07.0: PME# supported from D0 D3hot D3cold
> [ 4.401358] pci 0000:20:07.0: PME# disabled
> [ 4.405762] pci 0000:20:09.0: PME# supported from D0 D3hot D3cold
> [ 4.411753] pci 0000:20:09.0: PME# disabled
> [ 4.416710] pci 0000:22:00.0: PME# supported from D0 D3hot D3cold
> [ 4.422704] pci 0000:22:00.0: PME# disabled
> [ 4.427207] pci 0000:23:01.0: PME# supported from D0 D3hot D3cold
> [ 4.433200] pci 0000:23:01.0: PME# disabled
> [ 4.437604] pci 0000:23:02.0: PME# supported from D0 D3hot D3cold
> [ 4.443597] pci 0000:23:02.0: PME# disabled
> (XEN) PCI add device 20:03.0
> (XEN) PCI add device 20:07.0
> (XEN) PCI add device 20:09.0
> (XEN) PCI add device 20:14.0
> (XEN) PCI add device 20:14.1
> (XEN) PCI add device 20:14.2
> (XEN) PCI add device 22:00.0
> (XEN) PCI add device 23:01.0
> (XEN) PCI add device 23:02.0
> (XEN) PCI add device 24:00.0
> (XEN) PCI add device 24:00.1
> (XEN) PCI add device 25:00.0
> (XEN) PCI add device 25:00.1
> [ 4.592250] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 15)
> [ 4.599946] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 15)
> [ 4.607633] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 15)
> [ 4.615320] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 15)
> [ 4.623005] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *9 10 11 12 15)
> [ 4.630684] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 15) *0, disabled.
> [ 4.639490] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 15)
> [ 4.647181] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 15)
> [ 4.654695] xenbus_probe_backend_init bus registered ok
> [ 4.659879] xenbus_probe_frontend_init bus registered ok
> [ 4.665187] xen_balloon: Initialising balloon driver with page order 0.
> [ 4.672256] SCSI subsystem initialized
> [ 4.676431] usbcore: registered new interface driver usbfs
> [ 4.681888] usbcore: registered new interface driver hub
> [ 4.687270] usbcore: registered new device driver usb
> [ 4.692702] PCI: Using ACPI for IRQ routing
> [ 4.697003] IO APIC resources couldn't be allocated.
> [ 4.727285] cfg80211: Using static regulatory domain info
> [ 4.732586] cfg80211: Regulatory domain: US
> [ 4.736826] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> [ 4.744092] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
> [ 4.750933] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 4.757770] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 4.764606] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 4.771443] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> [ 4.778280] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> [ 4.785128] cfg80211: Calling CRDA for country: US
> [ 4.790015] NetLabel: Initializing
> [ 4.793419] NetLabel: domain hash size = 128
> [ 4.797833] NetLabel: protocols = UNLABELED CIPSOv4
> [ 4.802862] NetLabel: unlabeled traffic allowed by default
> [ 4.808653] DMAR:Host address width 40
> [ 4.812310] DMAR:DRHD base: 0x000000dfffe000 flags: 0x0
> [ 4.817604] IOMMU dfffe000: ver 1:0 cap c90780106f0462 ecap f020fe
> [ 4.823816] DMAR:DRHD base: 0x000000fedc0000 flags: 0x1
> [ 4.829105] IOMMU fedc0000: ver 1:0 cap c90780106f0462 ecap f020f6
> [ 4.835325] DMAR:RMRR base: 0x000000dbe58000 end: 0x000000dbe6ffff
> [ 4.841556] DMAR:ATSR flags: 0x0
> [ 4.844844] DMAR:ATSR flags: 0x0
> [ 4.848133] Not all IO-APIC's listed under remapping hardware
> [ 4.854028] IOMMU 0xdfffe000: using Queued invalidation
> [ 4.859217] IOMMU 0xfedc0000: using Queued invalidation
> [ 4.864493] IOMMU: Setting RMRR:
> [ 4.867778] IOMMU: Setting identity map for device 0000:00:1d.0 [0xdbe58000 - 0xdbe70000]
> [ 4.876053] IOMMU: Setting identity map for device 0000:00:1d.1 [0xdbe58000 - 0xdbe70000]
> [ 4.884264] IOMMU: Setting identity map for device 0000:00:1d.2 [0xdbe58000 - 0xdbe70000]
> [ 4.892485] IOMMU: Setting identity map for device 0000:00:1d.7 [0xdbe58000 - 0xdbe70000]
> [ 4.900709] IOMMU: Setting identity map for device 0000:00:1a.0 [0xdbe58000 - 0xdbe70000]
> [ 4.908928] IOMMU: Setting identity map for device 0000:00:1a.1 [0xdbe58000 - 0xdbe70000]
> [ 4.917150] IOMMU: Setting identity map for device 0000:00:1a.2 [0xdbe58000 - 0xdbe70000]
> [ 4.925390] IOMMU: Setting identity map for device 0000:00:1a.7 [0xdbe58000 - 0xdbe70000]
> [ 4.933612] IOMMU: Prepare 0-16MiB unity mapping for LPC
> [ 4.938938] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]
> [ 4.946651] VT-d detected invalid descriptor: low=11, high=0
> <<hangs here>>
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 11:11 ` Jan Beulich
@ 2010-03-25 0:55 ` Weidong Han
2010-03-25 8:43 ` Jan Beulich
0 siblings, 1 reply; 33+ messages in thread
From: Weidong Han @ 2010-03-25 0:55 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser, Cui, Dexuan
Jan Beulich wrote:
>>>> Weidong Han <weidong.han@intel.com> 24.03.10 12:00 >>>
>>>>
>> Re-checked the code. You're right. Updated the patch to check with
>> sizeof(struct acpi_table_XXX).
>>
>
> Why that way instead of checking for the header size in the common
> code path, and for the precise size in the case statements?
>
> Jan
>
>
Do you mean to know which case fails on length checking? How about below
patch?
diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 17:46:03 2010 +0800
@@ -664,21 +664,57 @@ static int __init acpi_parse_dmar(struct
case ACPI_DMAR_DRHD:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_DRHD:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_drhd) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ goto disable;
+ }
+
ret = acpi_parse_one_drhd(entry_header);
break;
case ACPI_DMAR_RMRR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_RMRR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_rmrr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ goto disable;
+ }
+
ret = acpi_parse_one_rmrr(entry_header);
break;
case ACPI_DMAR_ATSR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_ATSR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_atsr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ goto disable;
+ }
+
ret = acpi_parse_one_atsr(entry_header);
break;
case ACPI_DMAR_RHSA:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_RHSA:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_rhsa) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ goto disable;
+ }
+
ret = acpi_parse_one_rhsa(entry_header);
break;
default:
@@ -694,6 +730,7 @@ static int __init acpi_parse_dmar(struct
entry_header = ((void *)entry_header + entry_header->length);
}
+disable:
if ( ret )
{
printk(XENLOG_WARNING
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-25 0:55 ` Weidong Han
@ 2010-03-25 8:43 ` Jan Beulich
2010-03-25 9:05 ` Weidong Han
0 siblings, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2010-03-25 8:43 UTC (permalink / raw)
To: Weidong Han; +Cc: xen-devel, Keir Fraser, Dexuan Cui
>>> Weidong Han <weidong.han@intel.com> 25.03.10 01:55 >>>
>Do you mean to know which case fails on length checking? How about below
>patch?
Yes, something like this. Although I'd prefer to have a general
sizeof(struct acpi_dmar_entry_header) check before the switch
statement (to avoid even looking at out of range header fields),
and "break"s instead of "goto disable"s.
Jan
diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 17:46:03 2010 +0800
@@ -664,21 +664,57 @@ static int __init acpi_parse_dmar(struct
case ACPI_DMAR_DRHD:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_DRHD:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_drhd) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ goto disable;
+ }
+
ret = acpi_parse_one_drhd(entry_header);
break;
case ACPI_DMAR_RMRR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_RMRR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_rmrr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ goto disable;
+ }
+
ret = acpi_parse_one_rmrr(entry_header);
break;
case ACPI_DMAR_ATSR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_ATSR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_atsr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ goto disable;
+ }
+
ret = acpi_parse_one_atsr(entry_header);
break;
case ACPI_DMAR_RHSA:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_RHSA:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_rhsa) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ goto disable;
+ }
+
ret = acpi_parse_one_rhsa(entry_header);
break;
default:
@@ -694,6 +730,7 @@ static int __init acpi_parse_dmar(struct
entry_header = ((void *)entry_header + entry_header->length);
}
+disable:
if ( ret )
{
printk(XENLOG_WARNING
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-25 8:43 ` Jan Beulich
@ 2010-03-25 9:05 ` Weidong Han
2010-03-25 9:16 ` Jan Beulich
0 siblings, 1 reply; 33+ messages in thread
From: Weidong Han @ 2010-03-25 9:05 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser, Cui, Dexuan
Jan Beulich wrote:
>>>> Weidong Han <weidong.han@intel.com> 25.03.10 01:55 >>>
>>>>
>> Do you mean to know which case fails on length checking? How about below
>> patch?
>>
>
> Yes, something like this. Although I'd prefer to have a general
> sizeof(struct acpi_dmar_entry_header) check before the switch
> statement (to avoid even looking at out of range header fields),
> and "break"s instead of "goto disable"s.
>
>
Ok. Updated the patch according to your suggestion. Thanks.
diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c Fri Mar 26 01:59:55 2010 +0800
@@ -659,26 +659,71 @@ static int __init acpi_parse_dmar(struct
while ( ((unsigned long)entry_header) <
(((unsigned long)dmar) + table->length) )
{
+ if ( entry_header->length < sizeof(struct acpi_dmar_entry_header) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ "Invalid ACPI DMAR entry length: 0x%x\n",
+ entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
switch ( entry_header->type )
{
case ACPI_DMAR_DRHD:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_DRHD:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_drhd) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_drhd(entry_header);
break;
case ACPI_DMAR_RMRR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_RMRR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_rmrr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_rmrr(entry_header);
break;
case ACPI_DMAR_ATSR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_ATSR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_atsr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_atsr(entry_header);
break;
default:
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-25 9:05 ` Weidong Han
@ 2010-03-25 9:16 ` Jan Beulich
2010-03-25 9:21 ` Weidong Han
0 siblings, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2010-03-25 9:16 UTC (permalink / raw)
To: Weidong Han; +Cc: xen-devel, Keir Fraser, Dexuan Cui
>>> Weidong Han <weidong.han@intel.com> 25.03.10 10:05 >>>
>Ok. Updated the patch according to your suggestion. Thanks.
Looks good to me, and I would ack it if I didn't (sorry, only now)
notice that it can't be against -unstable: The patch seems to be
against code which doesn't have an ACPI_DMAR_RHSA case in
acpi_parse_dmar(). Quite odd...
Jan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c Fri Mar 26 01:59:55 2010 +0800
@@ -659,26 +659,71 @@ static int __init acpi_parse_dmar(struct
while ( ((unsigned long)entry_header) <
(((unsigned long)dmar) + table->length) )
{
+ if ( entry_header->length < sizeof(struct acpi_dmar_entry_header) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ "Invalid ACPI DMAR entry length: 0x%x\n",
+ entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
switch ( entry_header->type )
{
case ACPI_DMAR_DRHD:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_DRHD:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_drhd) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_drhd(entry_header);
break;
case ACPI_DMAR_RMRR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_RMRR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_rmrr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_rmrr(entry_header);
break;
case ACPI_DMAR_ATSR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_ATSR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_atsr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_atsr(entry_header);
break;
default:
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-25 9:16 ` Jan Beulich
@ 2010-03-25 9:21 ` Weidong Han
2010-03-25 9:30 ` Jan Beulich
0 siblings, 1 reply; 33+ messages in thread
From: Weidong Han @ 2010-03-25 9:21 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser, Cui, Dexuan
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
Jan Beulich wrote:
>>>> Weidong Han <weidong.han@intel.com> 25.03.10 10:05 >>>
>>>>
>> Ok. Updated the patch according to your suggestion. Thanks.
>>
>
> Looks good to me, and I would ack it if I didn't (sorry, only now)
> notice that it can't be against -unstable: The patch seems to be
> against code which doesn't have an ACPI_DMAR_RHSA case in
> acpi_parse_dmar(). Quite odd...
>
> Jan
>
Sorry, I didn't copy it completely. Attached it. Thanks.
Regards,
Weidong
[-- Attachment #2: dmar-length-check.patch --]
[-- Type: text/plain, Size: 2693 bytes --]
diff -r a4eac162dcb9 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c Thu Mar 25 01:05:03 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c Fri Mar 26 01:59:55 2010 +0800
@@ -659,26 +659,71 @@ static int __init acpi_parse_dmar(struct
while ( ((unsigned long)entry_header) <
(((unsigned long)dmar) + table->length) )
{
+ if ( entry_header->length < sizeof(struct acpi_dmar_entry_header) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ "Invalid ACPI DMAR entry length: 0x%x\n",
+ entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
switch ( entry_header->type )
{
case ACPI_DMAR_DRHD:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_DRHD:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_drhd) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_drhd(entry_header);
break;
case ACPI_DMAR_RMRR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_RMRR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_rmrr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_rmrr(entry_header);
break;
case ACPI_DMAR_ATSR:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_ATSR:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_atsr) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_atsr(entry_header);
break;
case ACPI_DMAR_RHSA:
if ( iommu_verbose )
dprintk(VTDPREFIX, "found ACPI_DMAR_RHSA:\n");
+
+ if ( entry_header->length < sizeof(struct acpi_table_rhsa) )
+ {
+ dprintk(XENLOG_ERR VTDPREFIX,
+ " Invalid length: 0x%x\n", entry_header->length);
+ ret = -EINVAL;
+ break;
+ }
+
ret = acpi_parse_one_rhsa(entry_header);
break;
default:
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-25 9:21 ` Weidong Han
@ 2010-03-25 9:30 ` Jan Beulich
2010-03-25 9:34 ` Pasi Kärkkäinen
0 siblings, 1 reply; 33+ messages in thread
From: Jan Beulich @ 2010-03-25 9:30 UTC (permalink / raw)
To: Weidong Han; +Cc: xen-devel, Keir Fraser, Dexuan Cui
>>> Weidong Han <weidong.han@intel.com> 25.03.10 10:21 >>>
>Sorry, I didn't copy it completely. Attached it. Thanks.
Ah, yes, this one looks fine to me.
Acked-by: Jan Beulich <jbeulich@novell.com>
Thanks a lot,
Jan
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-25 9:30 ` Jan Beulich
@ 2010-03-25 9:34 ` Pasi Kärkkäinen
2010-03-25 9:44 ` Keir Fraser
0 siblings, 1 reply; 33+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-25 9:34 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Weidong Han, Keir Fraser, Dexuan Cui
On Thu, Mar 25, 2010 at 09:30:18AM +0000, Jan Beulich wrote:
> >>> Weidong Han <weidong.han@intel.com> 25.03.10 10:21 >>>
> >Sorry, I didn't copy it completely. Attached it. Thanks.
>
> Ah, yes, this one looks fine to me.
>
> Acked-by: Jan Beulich <jbeulich@novell.com>
>
I'll test this patch tomorrow.
-- Pasi
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-25 9:34 ` Pasi Kärkkäinen
@ 2010-03-25 9:44 ` Keir Fraser
2010-03-26 19:20 ` Pasi Kärkkäinen
0 siblings, 1 reply; 33+ messages in thread
From: Keir Fraser @ 2010-03-25 9:44 UTC (permalink / raw)
To: Pasi Kärkkäinen, Jan Beulich; +Cc: xen-devel, Weidong Han, Dexuan Cui
On 25/03/2010 09:34, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> On Thu, Mar 25, 2010 at 09:30:18AM +0000, Jan Beulich wrote:
>>>>> Weidong Han <weidong.han@intel.com> 25.03.10 10:21 >>>
>>> Sorry, I didn't copy it completely. Attached it. Thanks.
>>
>> Ah, yes, this one looks fine to me.
>>
>> Acked-by: Jan Beulich <jbeulich@novell.com>
>>
>
> I'll test this patch tomorrow.
I changed it around a bit and applied to xen-unstable, so you can just test
tip.
-- Keir
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-25 9:44 ` Keir Fraser
@ 2010-03-26 19:20 ` Pasi Kärkkäinen
2010-03-29 6:42 ` Cui, Dexuan
0 siblings, 1 reply; 33+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-26 19:20 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, Weidong Han, Jan Beulich, Dexuan Cui
On Thu, Mar 25, 2010 at 09:44:25AM +0000, Keir Fraser wrote:
> On 25/03/2010 09:34, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
>
> > On Thu, Mar 25, 2010 at 09:30:18AM +0000, Jan Beulich wrote:
> >>>>> Weidong Han <weidong.han@intel.com> 25.03.10 10:21 >>>
> >>> Sorry, I didn't copy it completely. Attached it. Thanks.
> >>
> >> Ah, yes, this one looks fine to me.
> >>
> >> Acked-by: Jan Beulich <jbeulich@novell.com>
> >>
> >
> > I'll test this patch tomorrow.
>
> I changed it around a bit and applied to xen-unstable, so you can just test
> tip.
>
Ok, I just tested 4.0.0-rc8.
(XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
(XEN) [VT-D]dmar.c:371: Invalid ACPI DMAR entry length: 0x0
(XEN) Failed to parse ACPI DMAR. Disabling VT-d.
No 30 second delay anymore, VT-d gets disabled immediately.
And with iommu=verbose:
(XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
(XEN) [VT-D]dmar.c:679: Host address width 36
(XEN) [VT-D]dmar.c:371: Invalid ACPI DMAR entry length: 0x0
(XEN) Failed to parse ACPI DMAR. Disabling VT-d.
So both seem to work as expected with this broken BIOS.
Thanks!
-- Pasi
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-24 1:52 ` Cui, Dexuan
2010-03-24 8:24 ` Jan Beulich
2010-03-24 8:50 ` Pasi Kärkkäinen
@ 2010-03-26 19:45 ` Pasi Kärkkäinen
2010-03-29 6:48 ` Cui, Dexuan
2 siblings, 1 reply; 33+ messages in thread
From: Pasi Kärkkäinen @ 2010-03-26 19:45 UTC (permalink / raw)
To: Cui, Dexuan; +Cc: xen-devel, Han, Weidong, Keir Fraser
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
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@iki.fi> 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.
>
Here it is (as an attachment).
Xen 4.0.0-rc8 works properly now, meaning it disables VT-d immediately
without delays.
Motherboard: Supermicro X7SB4
BIOS: v1.2a
-- Pasi
[-- Attachment #2: Supermicro-X7SB4-BIOS12a-dmar.bin --]
[-- Type: application/octet-stream, Size: 407 bytes --]
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-26 19:20 ` Pasi Kärkkäinen
@ 2010-03-29 6:42 ` Cui, Dexuan
0 siblings, 0 replies; 33+ messages in thread
From: Cui, Dexuan @ 2010-03-29 6:42 UTC (permalink / raw)
To: Pasi Kärkkäinen, Keir Fraser
Cc: xen-devel, Han, Weidong, Jan Beulich
Pasi Kärkkäinen wrote:
> On Thu, Mar 25, 2010 at 09:44:25AM +0000, Keir Fraser wrote:
>> On 25/03/2010 09:34, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
>>
>>> On Thu, Mar 25, 2010 at 09:30:18AM +0000, Jan Beulich wrote:
>>>>>>> Weidong Han <weidong.han@intel.com> 25.03.10 10:21 >>>
>>>>> Sorry, I didn't copy it completely. Attached it. Thanks.
>>>>
>>>> Ah, yes, this one looks fine to me.
>>>>
>>>> Acked-by: Jan Beulich <jbeulich@novell.com>
>>>>
>>>
>>> I'll test this patch tomorrow.
>>
>> I changed it around a bit and applied to xen-unstable, so you can
>> just test tip.
>>
>
> Ok, I just tested 4.0.0-rc8.
>
> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
> (XEN) [VT-D]dmar.c:371: Invalid ACPI DMAR entry length: 0x0
> (XEN) Failed to parse ACPI DMAR. Disabling VT-d.
>
> No 30 second delay anymore, VT-d gets disabled immediately.
>
> And with iommu=verbose:
>
> (XEN) ACPI: HPET id: 0xffffffff base: 0xfed00000
> (XEN) [VT-D]dmar.c:679: Host address width 36
> (XEN) [VT-D]dmar.c:371: Invalid ACPI DMAR entry length: 0x0
> (XEN) Failed to parse ACPI DMAR. Disabling VT-d.
>
> So both seem to work as expected with this broken BIOS.
>
Yes, this is expected.
Thanks,
-- Dexuan
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-26 19:45 ` Pasi Kärkkäinen
@ 2010-03-29 6:48 ` Cui, Dexuan
0 siblings, 0 replies; 33+ messages in thread
From: Cui, Dexuan @ 2010-03-29 6:48 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: xen-devel, Han, Weidong, Keir Fraser
Pasi Kärkkäinen wrote:
> 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@iki.fi> 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.
>>
>
> Here it is (as an attachment).
>
> Xen 4.0.0-rc8 works properly now, meaning it disables VT-d immediately
> without delays.
>
> Motherboard: Supermicro X7SB4
> BIOS: v1.2a
>
> -- Pasi
With "iasl -d Supermicro-X7SB4-BIOS12a-dmar.bin", we can easily confirm the BIOS is broken.
Please check if there is newer BIOS available.
Thanks,
-- Dexuan
^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-03-25 0:04 ` Weidong Han
@ 2010-04-05 18:00 ` Nadolski, Ed
2010-04-07 1:43 ` Weidong Han
0 siblings, 1 reply; 33+ messages in thread
From: Nadolski, Ed @ 2010-04-05 18:00 UTC (permalink / raw)
To: Weidong Han; +Cc: xen-devel, Keir Fraser, Jan Beulich, Cui, Dexuan
[-- Attachment #1: Type: text/plain, Size: 2738 bytes --]
> > I'm also seeing a hang on boot with 4.0.0-rc7, but I am not clear if
> this is the same issue. Here is the tail end of the trace:
> >
> > [ 4.802862] NetLabel: unlabeled traffic allowed by default
> > [ 4.808653] DMAR:Host address width 40
> > [ 4.812310] DMAR:DRHD base: 0x000000dfffe000 flags: 0x0
> > [ 4.817604] IOMMU dfffe000: ver 1:0 cap c90780106f0462 ecap f020fe
> > [ 4.823816] DMAR:DRHD base: 0x000000fedc0000 flags: 0x1
> > [ 4.829105] IOMMU fedc0000: ver 1:0 cap c90780106f0462 ecap f020f6
> > [ 4.835325] DMAR:RMRR base: 0x000000dbe58000 end: 0x000000dbe6ffff
> > [ 4.841556] DMAR:ATSR flags: 0x0
> > [ 4.844844] DMAR:ATSR flags: 0x0
> > [ 4.848133] Not all IO-APIC's listed under remapping hardware
> > [ 4.854028] IOMMU 0xdfffe000: using Queued invalidation
> > [ 4.859217] IOMMU 0xfedc0000: using Queued invalidation
> > [ 4.864493] IOMMU: Setting RMRR:
> > [ 4.867778] IOMMU: Setting identity map for device 0000:00:1d.0
> [0xdbe58000 - 0xdbe70000]
> > [ 4.876053] IOMMU: Setting identity map for device 0000:00:1d.1
> [0xdbe58000 - 0xdbe70000]
> > [ 4.884264] IOMMU: Setting identity map for device 0000:00:1d.2
> [0xdbe58000 - 0xdbe70000]
> > [ 4.892485] IOMMU: Setting identity map for device 0000:00:1d.7
> [0xdbe58000 - 0xdbe70000]
> > [ 4.900709] IOMMU: Setting identity map for device 0000:00:1a.0
> [0xdbe58000 - 0xdbe70000]
> > [ 4.908928] IOMMU: Setting identity map for device 0000:00:1a.1
> [0xdbe58000 - 0xdbe70000]
> > [ 4.917150] IOMMU: Setting identity map for device 0000:00:1a.2
> [0xdbe58000 - 0xdbe70000]
> > [ 4.925390] IOMMU: Setting identity map for device 0000:00:1a.7
> [0xdbe58000 - 0xdbe70000]
> > [ 4.933612] IOMMU: Prepare 0-16MiB unity mapping for LPC
> > [ 4.938938] IOMMU: Setting identity map for device 0000:00:1f.0
> [0x0 - 0x1000000]
> > [ 4.946651] VT-d detected invalid descriptor: low=11, high=0
> >
> > Then it hangs. This is on a Dell T7500 quad-core Xeon with the latest
> Dell BIOS (rev. A03). Should I try the suggested patch, or any
> particular command line or build options? Should I dump the DMAR
> tables?
> >
> Your issue is different. It's caused by enabling VT-d in pv-ops dom0.
> but pv-ops dom0 should not see DMAR table because its signature is
> zapped after xen enables it. Pls have a try with turn off VT-d in
> pvops config (# CONFIG_DMAR is not set) , it should solve your issue. But we
> need to find why pv-ops dom0 still sees DMAR table in ACPI. Pls dump
> DMAR tables.
Changing CONFIG_DMAR as you say fixes the hang. I've also attached the DMAR table dump as you requested, does this look OK?
Thanks again,
Ed
[-- Attachment #2: DellT7500_BIOS_A03-dmar.bin --]
[-- Type: application/octet-stream, Size: 248 bytes --]
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
2010-04-05 18:00 ` Nadolski, Ed
@ 2010-04-07 1:43 ` Weidong Han
0 siblings, 0 replies; 33+ messages in thread
From: Weidong Han @ 2010-04-07 1:43 UTC (permalink / raw)
To: Nadolski, Ed; +Cc: xen-devel, Keir Fraser, Jan Beulich, Cui, Dexuan
Nadolski, Ed wrote:
>>> I'm also seeing a hang on boot with 4.0.0-rc7, but I am not clear if
>>>
>> this is the same issue. Here is the tail end of the trace:
>>
>>> [ 4.802862] NetLabel: unlabeled traffic allowed by default
>>> [ 4.808653] DMAR:Host address width 40
>>> [ 4.812310] DMAR:DRHD base: 0x000000dfffe000 flags: 0x0
>>> [ 4.817604] IOMMU dfffe000: ver 1:0 cap c90780106f0462 ecap f020fe
>>> [ 4.823816] DMAR:DRHD base: 0x000000fedc0000 flags: 0x1
>>> [ 4.829105] IOMMU fedc0000: ver 1:0 cap c90780106f0462 ecap f020f6
>>> [ 4.835325] DMAR:RMRR base: 0x000000dbe58000 end: 0x000000dbe6ffff
>>> [ 4.841556] DMAR:ATSR flags: 0x0
>>> [ 4.844844] DMAR:ATSR flags: 0x0
>>> [ 4.848133] Not all IO-APIC's listed under remapping hardware
>>> [ 4.854028] IOMMU 0xdfffe000: using Queued invalidation
>>> [ 4.859217] IOMMU 0xfedc0000: using Queued invalidation
>>> [ 4.864493] IOMMU: Setting RMRR:
>>> [ 4.867778] IOMMU: Setting identity map for device 0000:00:1d.0
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.876053] IOMMU: Setting identity map for device 0000:00:1d.1
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.884264] IOMMU: Setting identity map for device 0000:00:1d.2
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.892485] IOMMU: Setting identity map for device 0000:00:1d.7
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.900709] IOMMU: Setting identity map for device 0000:00:1a.0
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.908928] IOMMU: Setting identity map for device 0000:00:1a.1
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.917150] IOMMU: Setting identity map for device 0000:00:1a.2
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.925390] IOMMU: Setting identity map for device 0000:00:1a.7
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.933612] IOMMU: Prepare 0-16MiB unity mapping for LPC
>>> [ 4.938938] IOMMU: Setting identity map for device 0000:00:1f.0
>>>
>> [0x0 - 0x1000000]
>>
>>> [ 4.946651] VT-d detected invalid descriptor: low=11, high=0
>>>
>>> Then it hangs. This is on a Dell T7500 quad-core Xeon with the latest
>>>
>> Dell BIOS (rev. A03). Should I try the suggested patch, or any
>> particular command line or build options? Should I dump the DMAR
>> tables?
>>
>> Your issue is different. It's caused by enabling VT-d in pv-ops dom0.
>> but pv-ops dom0 should not see DMAR table because its signature is
>> zapped after xen enables it. Pls have a try with turn off VT-d in
>> pvops config (# CONFIG_DMAR is not set) , it should solve your issue. But we
>> need to find why pv-ops dom0 still sees DMAR table in ACPI. Pls dump
>> DMAR tables.
>>
>
> Changing CONFIG_DMAR as you say fixes the hang. I've also attached the DMAR table dump as you requested, does this look OK?
>
> Thanks again,
> Ed
>
>
When use "iasl" to disassemble attached file, it prompted:
Loading Acpi table from file DellT7500_BIOS_A03-dmar.bin
Table signature [DMAR] is invalid or not supported
Could not get table from the file
Did you dump it on dom0 (not native Linux)? if so, that means DMAR
signature is already zapped, dom0 should not detect it and won't go to
enable it.
Regards,
Weidong
>
>
>
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2010-04-07 1:43 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-23 14:27 Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing Pasi Kärkkäinen
2010-03-23 14:40 ` Jan Beulich
2010-03-23 14:40 ` Pasi Kärkkäinen
2010-03-23 14:48 ` Keir Fraser
2010-03-23 19:37 ` Pasi Kärkkäinen
2010-03-23 19:54 ` Keir Fraser
2010-03-23 20:05 ` Pasi Kärkkäinen
2010-03-24 0:40 ` Weidong Han
2010-03-24 1:52 ` Cui, Dexuan
2010-03-24 8:24 ` Jan Beulich
2010-03-24 8:54 ` Cui, Dexuan
2010-03-24 9:02 ` Weidong Han
2010-03-24 9:10 ` Pasi Kärkkäinen
2010-03-24 9:46 ` Jan Beulich
2010-03-24 11:00 ` Weidong Han
2010-03-24 11:11 ` Jan Beulich
2010-03-25 0:55 ` Weidong Han
2010-03-25 8:43 ` Jan Beulich
2010-03-25 9:05 ` Weidong Han
2010-03-25 9:16 ` Jan Beulich
2010-03-25 9:21 ` Weidong Han
2010-03-25 9:30 ` Jan Beulich
2010-03-25 9:34 ` Pasi Kärkkäinen
2010-03-25 9:44 ` Keir Fraser
2010-03-26 19:20 ` Pasi Kärkkäinen
2010-03-29 6:42 ` Cui, Dexuan
2010-03-24 17:34 ` Nadolski, Ed
2010-03-25 0:04 ` Weidong Han
2010-04-05 18:00 ` Nadolski, Ed
2010-04-07 1:43 ` Weidong Han
2010-03-24 8:50 ` Pasi Kärkkäinen
2010-03-26 19:45 ` Pasi Kärkkäinen
2010-03-29 6:48 ` Cui, Dexuan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.