Re: [Xen-devel] [xen-unstable test] 18784: regressions - trouble: broken/fail/pass

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.08.13 at 11:00, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> At first I thought this ought to be a regression from either or both
> of 850188e1 and d838ac25 ("x86: don't allow Dom0 access to the
> MSI/HT address range"; those at least seem the most likely
> candidates to cause an early Dom0 death), but checking
> test-amd64-amd64-xl-win7-amd64 the same kernel (afaict) boots
> fine there. The MSI change clearly isn't machine specific; the HT
> one of course gets used on AMD systems only (and indeed the
> failures are all on either of the two frogs, which are AMD
> systems, but iirc they're not the only ones - Ian?).
> [...]
> And in any case the question of course is whether a failure with
> this old a Dom0 kernel really counts as a regression. It needs to
> be considered whether re-opening the latent problem these two
> changes address (and the HT one much more so than the MSI
> one, where from the above it looks like the MSI one isn't causing
> problems) is really better than rendering very old Dom0 kernels
> unusable.

So I want and booted the very kernel supposedly used there on
one of my AMD boxes. Afaict it gets farther than on the frogs,
but eventually crashes nevertheless, due to a very obvious bug:
It tries to relocate the memory overlapping non-RAM regions in
the machine memory map to physical addresses beyond the
highest E820 entry (which with said patch is guaranteed to be no
less than 1Tb), but at the same time its __set_phys_to_machine()
BUG()s on any PFN beyond 512Gb.

So - do we need to support this kind of a buggy kernel, and hence
continue to rely on Dom0 to avoid the HT area when assigning
MMIO regions (guaranteeing of which Linux, including when
running native, up to now neglects altogether)?

From all I can tell modern pv-ops relocates the overlapping
memory into higher RAM regions mentioned in the machine E820,
i.e. should not be susceptible to this change.

Jan


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