Re: [Minios-devel] [UNIKRAFT PATCHv5 20/46] plat/common: Add early debug console library for Arm64

["Wei Chen (Arm Technology China)" <Wei.Chen@xxxxxxx>]

> -----Original Message-----
> From: Julien Grall <julien.grall@xxxxxxx>
> Sent: 2018年9月12日 18:27
> To: Wei Chen (Arm Technology China) <Wei.Chen@xxxxxxx>; Julien Grall
> <julien.grall@xxxxxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
> simon.kuenzer@xxxxxxxxx
> Cc: Kaly Xin (Arm Technology China) <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> Subject: Re: [Minios-devel] [UNIKRAFT PATCHv5 20/46] plat/common: Add early
> debug console library for Arm64
> 
> Hi Wei,
> 
> On 09/12/2018 03:58 AM, Wei Chen (Arm Technology China) wrote:
> >
> >
> >> -----Original Message-----
> >> From: Julien Grall <julien.grall@xxxxxxx>
> >> Sent: 2018年9月11日 18:37
> >> To: Wei Chen (Arm Technology China) <Wei.Chen@xxxxxxx>; Julien Grall
> >> <julien.grall@xxxxxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
> >> simon.kuenzer@xxxxxxxxx
> >> Cc: Kaly Xin (Arm Technology China) <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> >> Subject: Re: [Minios-devel] [UNIKRAFT PATCHv5 20/46] plat/common: Add early
> >> debug console library for Arm64
> >>
> >> Hi Wei,
> >>
> >> On 11/09/18 06:35, Wei Chen (Arm Technology China) wrote:
> >>>>> Oh, You beat me. Yes, PL011 start at IPA 0 is possible. But I don't know
> >>>>> how to distinguish PL011 at IPA 0 or #ifndef
> >>>> CONFIG_KVM_EARLY_DEBUG_PL011_UART.
> >>>>> I had tried not to check (!pl011_uart_bas), it will generate an
> exception,
> >>>>> and the exception entry will call PL011 to print message. It's an
> infinite
> >>>> loop.
> >>>>
> >>>> If I understand correctly, KVM_EARLY_DEBUG_PL011_UART will exist if
> >>>> KVM_DEBUG_SERIAL_CONSOLE is set. So one solution would be to introduce
> >>>> an extra variable to check whether the UART has been initialized.
> >>>>
> >>>> This would be set to 1 at boot when KVM_DEBUG_SERIAL_CONSOLE is set.
> >>>>
> >>>
> >>> Ok, I understand now.
> >>>
> >>> Just a digression, if an IPA 0 is possible, so I think most of the NULL
> >>> Check would be unreliable. For example, lots of fdt_get_property will
> >>> return a pointer. You know, most of us will use the if(!pointer) to check
> >>> the return value.
> >> Well, that the drawback with building page-table with VA == PA. You have
> >> somehow to ensure that VA 0 is never mapped.
> >>
> >> For now, you could just check whether the VA 0 has been mapped and print
> >> a warning. This would need to be properly fixed sooner or later as it
> >> looks like some hardware have PA 0 valid.
> >>
> >
> > Yes, at least I know that boot rom (flash) of QEMU/KVM is starting from IPA
> 0.
> > And we have already mapped it, because we have mapped 0 - 0x3FFFFFFF as
> device
> > MMIO. But I think only flash code need to care about the valid IPA 0, other
> code
> > can use NULL as normal. For Unikraft, I don’t think we would implement the
> > library for QEMU/KVM boot rom in recently.
> 
> NULL pointer is not only about check in the code. It is also here to
> generate a fault if a NULL pointer is dereferenced (i.e because of a
> missing check). If you have the VA 0 mapped, then you will read/write
> the content. This is going to be extremely difficult to debug such code
> if it is ever noticed.
> 

Hmm, it seems we have to consider this special case later. Remapping first 4K
to other VA or other methods. But currently, let keep it in TODO : )


> >
> > Above comment is about current code for QEMU/KVM. I know some SoC would use
> PA0
> > for RAM, that would be more crazy : )
> 
> Have a look under arch/arm64/dts, you may find quite a few with RAM
> starting a 0 ;).
> 
> Cheers,
> 
> --
> Julien Grall
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel