Re: [Minios-devel] [UNIKRAFT PATCH 16/22] plat/kvm: Disable D-Cache before doing any change for Arm64

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

Hi Julien,

> -----Original Message-----
> From: Julien Grall <julien.grall@xxxxxxx>
> Sent: 2018年11月8日 20:20
> To: Wei Chen (Arm Technology China) <Wei.Chen@xxxxxxx>; minios-
> devel@xxxxxxxxxxxxxxxxxxxx; simon.kuenzer@xxxxxxxxx
> Cc: Kaly Xin (Arm Technology China) <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> Subject: Re: [Minios-devel] [UNIKRAFT PATCH 16/22] plat/kvm: Disable D-Cache
> before doing any change for Arm64
> 
> Hi,
> 
> On 11/8/18 9:51 AM, Wei Chen wrote:
> > Disable the D-Cache before doing anything change, This will
> > help us to avoid doing clean the D-Cache for changed area.
> 
> NAcked-by: Julien Grall <julien.grall@xxxxxxx>
> 
> I am pretty sure we discussed about it in the previous series. D-Cache
> disable means the cache will be bypassed. The processor may still
> speculatively load cache line behind your back.
> 
> So if you change memory with cache disable, then you need to invalidate
> the cache to ensure there are no stall data in it.
> 
> Furthermore, for data you write with cache disabled,  you need to know
> whether the cache was cleaned to PoC for the region you modify. The
> protocol you use should tell you what is the guarantee here.
> 
> If there are no guarantee, then you need to clean to PoC the region you
> are about to modify.
> 
> For instance, the Linux Image protocol will guarantee that the DTB,
> Kernel, Initramfs will be clean to PoC. The rest of the memory is unknown.
> 
> As you use ELF, I invite you to look at what are the guarantees here.
> 

I think I had mis-understood your previous comment. So I call
clean_and_invalidate_dcache_range at the very beginning, should I cover the
whole RAM area? Because I don't know the areas that had been cached.
And I do clean_and_invalidate_dcache_range at the very beginning, should I
Keep the clean_and_invalidate_dcache_range operation in start MMU function?

> Cheers,
> 
> --
> Julien Grall
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel