[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH early-RFC 4/5] xen/arm: mm: Rework switch_ttbr()


  • To: Julien Grall <julien@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Fri, 25 Mar 2022 14:35:38 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TMsahgJoPgSUBzoOQKip4Nt31Wd5X598W91iqKan1rk=; b=b99+CnMCOdbchPjFgeUgcRKCqoYQir9kgG86WGA7sULYbAHYLULvc5CYjNJucKEXNOep5bUa9cD9bOFp4ddDvALU9CFtDwZQGzgrkNU6Occg624uK5T1+EOhyNSu+chDG4cjhH6i7lLQ4S+APb0rCaAoprnF+csNlNuK4LCL0LRuOQ32WC4+KBFwK/bxvOWS74hP2vJ99mMvpXexc475DBACorFOQkCDocM3mUnL79dWGrX9bWgjL3gDVED2NGhF21060c8ZuoEj71G+TwQ+yDXPb/nhb/keiNVChY/78C7Z6D0rMGQdDFpEy0oBTSheiuIPdUAZ6H6zOFKh6jtkmA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ntaPAXQjPKmp43sFpw0A3agh9V8IP7JzUZ73NhXThh+N0kJizsMnCFEy3GTZ5a6SVaXK2l83ocJ4EtCaFfBk4HkcCJXvxnwSvvuwdCi1Xsa8lyex1U6/7lRU7nyy98znVQO/XyY6VeXkOByMOfq2HdV32vnEoZR4vCzZM+jmjZR3BcnKw5cujGfe4rrvUw8KoEsdW6DlNimPECpGN8QjVepNee1RtDDy9P0kxOEwI2OyHrK63738dRgUr+N//KBhYhpeJFBgkihDwwJjoKruo2rsLmqh7t4s7fIfN/PJmgtl3WIBxY8jg5vL9Kw6ZVkmFxbGhYWuoFOFh5ik53fptA==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "marco.solieri@xxxxxxxxxxxxxxx" <marco.solieri@xxxxxxxxxxxxxxx>, "lucmiccio@xxxxxxxxx" <lucmiccio@xxxxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Fri, 25 Mar 2022 14:36:07 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYM6fbReeSkSu3okSScrrMlkjRu6zQNoyAgAAKUgCAAAMDAA==
  • Thread-topic: [PATCH early-RFC 4/5] xen/arm: mm: Rework switch_ttbr()

Hi Julien,

> On 25 Mar 2022, at 15:24, Julien Grall <julien@xxxxxxx> wrote:
> 
> 
> 
> On 25/03/2022 13:47, Bertrand Marquis wrote:
>> Hi Julien,
> 
> Hi Bertrand,
> 
>>> On 9 Mar 2022, at 12:20, Julien Grall <julien@xxxxxxx> wrote:
>>> 
>>> From: Julien Grall <jgrall@xxxxxxxxxx>
>>> 
>>> At the moment, switch_ttbr() is switching the TTBR whilst the MMU is
>>> still on.
>>> 
>>> Switching TTBR is like replacing existing mappings with new ones. So
>>> we need to follow the break-before-make sequence.
>>> 
>>> In this case, it means the MMU needs to be switched off while the
>>> TTBR is updated. In order to disable the MMU, we need to first
>>> jump to an identity mapping.
>>> 
>>> Rename switch_ttbr() to switch_ttbr_id() and create an helper on
>>> top to temporary map the identity mapping and call switch_ttbr()
>>> via the identity address.
>>> 
>>> switch_ttbr_id() is now reworked to temporarily turn off the MMU
>>> before updating the TTBR.
>>> 
>>> We also need to make sure the helper switch_ttbr() is part of the
>>> identity mapping. So move _end_boot past it.
>>> 
>>> Take the opportunity to instruction cache flush as the operation is
>>> only necessary when the memory is updated.
>> Your code is actually remove the instruction cache invalidation so
>> this sentence is a bit misleading.
> 
> I forgot to add the word "remove" in the sentence.

Ok (my sentence was also wrong by the way)

> 
>> Also an open question: shouldn’t we flush the data cache ?
> Do you mean clean/invalidate to PoC/PoU? Something else?

Yes, probably to PoU.

> 
>> As we switch from one TTBR to an other, there might be some data
>> in the cache dependent that could be flushed while the MMU is off 
> 
> I am a bit confused. Those flush could also happen with the MMU on. So how 
> turning off the MMU would result to a problem? Note that the data cache is 
> still enabled during the switch.

If the first level of cache is VIPT and we turn off the MMU, I am wondering if 
this could not create troubles and could require the cache to be flushed before 
turning the MMU off.
I have no idea if this is a problem or not, just raising the question.
I can try to dig on that at Arm when I am back in 10 days. 

> 
>> or
>> that would have no mapping once it is reactivated.
> The cache line will be flushed at some point in the future. I would argue if 
> the caller need it earlier, then it should make sure to issue the flush 
> before switch_ttbr().
Ok.

I will still try to check if there is some kind of recommandation to turn the 
MMU off.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.