Re: [Xen-devel] Current staging crashes on boot on an AMD EPYC 7251

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.09.18 at 13:18, <roger.pau@xxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxx> wrote:
>> > > On 9/21/18 1:41 PM, Jan Beulich wrote:
>> > >>>>> On 21.09.18 at 12:15, <roger.pau@xxxxxxxxxx> 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.

Oh, right you are.

Jan


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