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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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