Re: [xen-unstable test] 64494: regressions - FAIL

[Wei Liu <wei.liu2@citrix.com>]

On Thu, Nov 19, 2015 at 01:29:01PM +0100, Juergen Gross wrote:
[...]
> > To be precise, the problem is in mini-os, which is used by rump kernel
> > as well. :-(
> > 
> >> pvgrub is making assumptions about the page table allocation scheme
> >> of the toolset starting pvgrub. It is calculating the first not yet
> >> mapped pfn by:
> >>
> >> pfn_to_map =
> >>     (start_info.nr_pt_frames - NOT_L1_FRAMES) * L1_PAGETABLE_ENTRIES;
> >>
> >> NOT_L1_FRAMES is 3 for 64 bit and 32 bit:
> >>
> >> 64 bit: 1 level 4 + 1 level 4 + 1 level 2
> >> 32 bit: 1 level 3 + 2 level 2 (assuming level 2 pt are allocated
> >>   for the first and the last GB)
> >>
> >> This is wrong now, as for 32 bit I'm allocating all level 2 page
> >> tables from the lowest needed address up to 0xffffffff, resulting
> >> in 4 level 2 page tables in pvgrub case.
> >>
> >> Setting NOT_L1_FRAMES to 5 for 32 bit pvgrub makes the system boot
> >> again.
> >>
> >> I think it is wrong for pvgrub to assume a fixed allocation scheme
> >> of the page tables. The question is how to fix it: either via
> >> changing NOT_L1_FRAMES or by doing it in a clean but more complicated
> >> way.
> >>
> > 
> > In the mean time, shall we revert the series and think about this a bit
> > more?
> > 
> > How complicated will be clean fix be?
> 
> I think I can fix it today. I can just count the not_l1_frames
> dynamically by walking through the higher level page tables. This

This seems sensible.

> will work for 32 and 64 bit and with and without my patch series
> and even for 32 bit mini-os started via grub-xen.
> 
> > Does changing NOT_L1_FRAMES break mini-os boot with toolstack prior to
> > your series?
> 
> Yes.
> 

In that case I think a clean fix is required.

Wei.

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