Re: Current staging crashes on boot on an AMD EPYC 7251

["Roger Pau Monné" <roger.pau@citrix.com>]

On Fri, Sep 21, 2018 at 01:05:42PM +0200, Roger Pau Monné wrote:
> On Fri, Sep 21, 2018 at 05:00:54AM -0600, Jan Beulich wrote:
> > >>> On 21.09.18 at 12:48, <rcojocaru@bitdefender.com> wrote:
> > > On 9/21/18 1:41 PM, Jan Beulich wrote:
> > >>>>> On 21.09.18 at 12:15, <roger.pau@citrix.com> wrote:
> > >>> On Fri, Sep 21, 2018 at 12:45:18PM +0300, Razvan Cojocaru wrote:
> > >>>> While doing my best to make sure what I understand to be George's
> > >>>> proposed changes for the altp2m series I've tried to boot Xen staging on
> > >>>> an AMD host, but it crashes in an unrelated place (I've tested this by
> > >>>> stashing my changes and booting a "vanilla" staging):
> > >>>
> > >>> Can you apply the following debug patch and paste the full boot log?
> > >> 
> > >> Well, not having provided the full boot log right away is clearly
> > >> unhelpful, as from that alone we should be able to tell what's
> > >> going on here (unless we e.g. screw up the E820 map somewhere).
> > >> However, it is already clear that ...
> > >> 
> > >>> --- a/xen/arch/x86/mm.c
> > >>> +++ b/xen/arch/x86/mm.c
> > >>> @@ -465,6 +465,8 @@ unsigned int page_get_ram_type(mfn_t mfn)
> > >>>              break;
> > >>>  
> > >>>          default:
> > >>> +printk("[%#lx, %#lx) type: %u\n", e820.map[i].addr,
> > >>> +       e820.map[i].addr + e820.map[i].size, e820.map[i].type);
> > >>>              ASSERT_UNREACHABLE();
> > >> 
> > >> ... this assertion needs to go away, as it would trigger for both
> > >> E820_TYPE_PMEM and E820_TYPE_PRAM (using the Linux
> > >> naming), or the unnamed type 6 mentioned in their header. It
> > >> would also trigger for types which may get added down the road.
> > > 
> > > I have attached the full log, as requested by Roger.
> > 
> > And there we go:
> > 
> > (XEN)  00000000dabf2000 - 00000000dacdf000 type 20
> > 
> > Whatever that is. I think for the purposes of the function here all
> > unknown types should be mapped into UNUSABLE.
> 
> Oh, I sent a patch to map them to RAM_TYPE_UNKNOWN, but maybe UNUSABLE
> would be better?
> 
> For the current usage of page_get_ram_type both will accomplish the
> same.

Scratch that, they won't accomplish the same. If we decide to use
UNUSABLE it won't be mapped in the inclusive case, if UNKNOWN is used
it will be mapped in the inclusive case.

Previous behavior (when using page_is_ram_type instead of
page_get_ram_type) won't mark unknown range types as UNUSABLE, so
UNKNOWN should be the same behavior as before.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel