Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/02/17 11:37, Jan Beulich wrote:
>>>> On 28.02.17 at 10:20, <roger.pau@xxxxxxxxxx> wrote:
>> It seems that your changes are causing issues when booting a 32bit Dom0, it
>> seems there are several IOMMU faults that prevent Dom0 from booting at all.
>> AFAICT this only happens when using a 32bit Dom0. The bisector has pointed
>> several times at this change, so it looks like the culprit.
>>
>> See for example:
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/106186/ 
>>
>> This is the serial log of the box failing to boot:
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/106186/test-amd64-i386-migr 
>> upgrade/serial-chardonnay0.log.0
>>
>> Search for "[VT-D]DMAR:[DMA Read] Request device [0000:01:00.0] fault addr
>> 7cd3f000, iommu reg = ffff82c00021b000" to get to the first IOMMU fault.
> And I think this is due to xen_in_range() (used by
> vtd_set_hwdom_mapping()) not having got adjusted to cover the
> freed part of .bss. Oddly enough the AMD equivalent _still_ does
> not use it, but instead blindly maps everything.
>
> Along those lines I would then also expect tboot to be broken, due
> to its treatment of the [__bss_start,__bss_end) range.
>
> Andrew, it looks like your b4cd59fea0 ("x86: reorder .data and
> .init when linking") did also introduce breakage here, as
> [_stext,__init_begin) no longer covers .data.

Hmm.  So it seems.  Let me put together a patch.

~Andrew

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