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

Re: [for-4.20] Re: [PATCH v12 12/12] xen/arm: add cache coloring support for Xen image


  • To: Julien Grall <julien@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "Carlo Nonato" <carlo.nonato@xxxxxxxxxxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Tue, 7 Jan 2025 17:51:29 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=pMNDAyDegdFg5HceiyDc3R+eEYZtHl+PLMdUQ/z85EU=; b=BhrSGpJ1qId8Tz2sDZ+F35j6955hPYf6V6j2uN5zRfm/QjDfU1lguLk2E5v8JsimHBde5c6xVeO0GrerkkOdNUUcZ6HckpqR442GoMQltLVEpQI7wePGADcVjToxZdmtlF8TMezO3XvMfV1a6TwpMWJE1Hwf9r0DSufhPtb756gGB40U7wMQxGB+EqYN3Rdz4f93qyoQA5Vc/2E4PY6cJ49CfeF+n3dDosiJkpzpGQyeflgm6O8zD27Wcl0+6E5crtSImJg+2pmCR/2cIj/55gruvmCz62M7HO6+IK/RT2Jjhk7apV3yu2zC55UBI1TKuQy05/LfLBYymprrC6wNvg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=M1//WkqFWFrLQ37qdUoWZT/1WQJRpNgjY36df5KeoT1Y7OPPQn9RWKtYrqGVngnuPrEBQQPTNr1ypXaOvk6TCZbFUfo2WcR+GjsLvhjBdkwlXv1aYpZ4eMR308qJKvr2FtXl38UxHU/Pl+MQUnbdqk21HE/KCyvO3aBJERm3esDRntOEuafieG6o/NOQRfJP/ZkP8TgmaXhgoQ6DLjqnTRylMzRtBEJw79SKtteZSaiTpyqtACdB2psVFz7UsFYqV66x0+rLv6VpXrhjF2n0lFdxTbAu2u/L+VU5/yBtLuH9AA3erWCcUsCYiXePdNdJAnWqi8JrfCaQ8ZE7h18RWA==
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <andrea.bastoni@xxxxxxxxxxxxxxx>, <marco.solieri@xxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Oleksii <oleksii.kurochko@xxxxxxxxx>
  • Delivery-date: Tue, 07 Jan 2025 16:51:55 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 07/01/2025 17:42, Julien Grall wrote:
> 
> 
> Hi,
> 
> On 16/12/2024 14:36, Jan Beulich wrote:
>> On 16.12.2024 15:28, Carlo Nonato wrote:
>>> On Mon, Dec 16, 2024 at 2:56 PM Michal Orzel <michal.orzel@xxxxxxx> wrote:
>>>> On 13/12/2024 17:28, Carlo Nonato wrote:
>>>>> --- a/xen/arch/arm/arm64/mmu/mm.c
>>>>> +++ b/xen/arch/arm/arm64/mmu/mm.c
>>>>> @@ -1,6 +1,7 @@
>>>>>   /* SPDX-License-Identifier: GPL-2.0-only */
>>>>>
>>>>>   #include <xen/init.h>
>>>>> +#include <xen/llc-coloring.h>
>>>>>   #include <xen/mm.h>
>>>>>   #include <xen/pfn.h>
>>>>>
>>>>> @@ -138,8 +139,36 @@ void update_boot_mapping(bool enable)
>>>>>   }
>>>>>
>>>>>   extern void switch_ttbr_id(uint64_t ttbr);
>>>>> +extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t 
>>>>> len);
>>>>>
>>>>>   typedef void (switch_ttbr_fn)(uint64_t ttbr);
>>>>> +typedef void (relocate_xen_fn)(uint64_t ttbr, void *src, void *dst, 
>>>>> size_t len);
>>>>> +
>>>>> +void __init relocate_and_switch_ttbr(uint64_t ttbr) {
>>>> CODING_STYLE: { needs to be on its own line
>>>>
>>>> Also, this function is only executed in case of LLC coloring, so shouldn't 
>>>> it
>>>> be #ifdef protected.
>>>
>>> Here and in other places (patch #8) I'm relying on DCE to remove functions
>>> that are not called. This was a suggestion from Jan in that patch. Can we
>>> adopt the same here?
>>
>> Yet how would the compiler spot that the function is unused? That would only
>> work with LTO / WPO. DCE (as I did suggest elsewhere) requires the functions
>> in question to be static (allowing the compiler to see enough of the whole
>> picture).
> 
> Sorry for the late answer. I was away with limited e-mail access. While
> looking what was committing recently, I noticed that a dummy function
> was introduced:
> 
> void __init relocate_and_switch_ttbr(uint64_t ttbr) {}
> 
> If a function is not supposed to be called, then it should contain a
> BUG_ON() to catch any misusage. Otherwise, this is a recipe for
> disaster. In this case, it would not be trivial to notice the TTBR was
> not switched...
> 
> That said I would have actually considered to remove the empty stub. I
> am a bit surprised that DCE wouldn't work in this case because the call
> is protected with "if ( llc_coloring_enabled )". When cache coloring is
> not enabled, this would turn to an "if ( false )" and therefore all the
> code should be removed. What did I miss?
> 
> Note that this is what we already rely on for arm32 because there is no
> stub... So if this is problem then we definitely need to fix it on arm32
> as well...
> 
> IOW, we either introduce a stub (including the BUG_ON) for both arm32
> and arm64 in the header or we remove the stub completely.
> 
> Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.
I did a test with GCC 13.2 and I can compile it fine with stub removed. That 
said,
I'm not a compiler expert and I'm not sure if this behavior stays the same with 
different
compiler options/optimizations. So it's more like a question to Jan. I'm happy 
either way.

~Michal




 


Rackspace

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