Re: [PATCH 15/18] xen/arm: Resume memory management on Xen resume

From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xen.org, dm@aggios.com,
	saeed.nowshadi@xilinx.com, xen-devel@lists.xenproject.org,
	stefano.stabellini@xilinx.com,
	Mirela Simonovic <mirela.simonovic@aggios.com>
Subject: Re: [PATCH 15/18] xen/arm: Resume memory management on Xen resume
Date: Tue, 13 Nov 2018 22:24:58 +0000	[thread overview]
Message-ID: <93c7aa4b-11be-4b43-1e3f-fce2a1a629e3@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1811131246450.8259@sstabellini-ThinkPad-X260>

Hi,

On 11/13/18 9:35 PM, Stefano Stabellini wrote:
> On Tue, 13 Nov 2018, Julien Grall wrote:
>> On 13/11/2018 01:36, Stefano Stabellini wrote:
>>> On Mon, 12 Nov 2018, Julien Grall wrote:
>>>> On 11/12/18 11:30 AM, Mirela Simonovic wrote:
>>> We can turn this assembly code into a .macro, so that at least when we
>>> get around to it, we just need to fix it one place. In fact, I noticed
>>> that the code sequence right before "mmu_resumed" and the one right
>>> after are both indentical to the ones head.S, it would be good to avoid
>>> the duplication if possible.
>>
>> This does not address my concern. We want to have suspend/resume compliant to
>> the Arm architecture (at least to our best knowledge). Hiding it in a
>> macro/function is not going to make it compliant.
>>
>> Nobody wants its platform randomly crashing on suspend/resume because the Arm
>> Arm was knowingly not followed. This is more critical than the boot one as we
>> are going to call that more often. So what is the action plan to correctly
>> resume memory management in this series?
> 
> My suggestion does not address your concern, but at least it limits the
> spreading of errors code-wise.

You can't build a great building on a weak foundation.

> It is only natural for a contributor to start from existing code to
> write new code. It just happens that the existing code is broken, thus, > the new code is broken too. We can't really expect any different :)

I didn't expect anything different. In fact, I explained why the code is 
wrong and asked what is the plan to fix it. I would have expect you or 
the contributor to come back with suggestion how to fix this.

Instead you suggested to keep wrong code in Xen with no plan to resolve it.

> 
> If we want the contributor to fix this, given that the change is a
> difficult modification to delicate assembly code, we need to provide
> detailed documentation and/or sample code. Otherwise I can't see how it
> can go well.

I don't think it is that difficult at least compare to implementing 
suspend/resume. There are far more corner case in the latter.

The rules are fairly simple here:
	1) You cannot switch between TTBR without disabling the MMU and 
therefore use an ID map
	2) We always need to keep an ID map in place to allow turning off the MMU
	3) Replacing a valid mapping should follow the break-before make
	4) Memory written with MMU/cache off should be precede by clean and 
followed by invalidate

The best example might be KVM boot code yet the page-tables are very 
simplistic compare to Xen. Linux is not a good example because EL1 
supports 2 set of page-tables.

I am happy to provide more details if someone is going to look at it.

Cheers,

-- 
Julien Grall

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