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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 9/21/18 2:18 PM, Roger Pau Monné 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.

FWIW, I've tested it with UNUSABLE and it boots, so assuming that you go
with that:

Tested-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>


Thanks,
Razvan

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