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

Re: [PATCH] xen/device-tree: Allow exact match for overlapping regions


  • To: Julien Grall <julien@xxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Wed, 13 Nov 2024 14:33:52 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • 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=2; 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=p59MGlsfjfPY47MfXr6614MlMjhJ6jAXW3whboewMcc=; b=J+Tefuox3oNmrphR3Q+T5wvzwhcHyTN4upjWVbjDnTf/QLRKyGoWGaBT67PfgWbBE9r9JxOv33uuZ0WKHkBJOIQrpcRNV1XUdMRW00PtTmT3995if82N6QzzU4LOKa8c0CBG5Jx/soJFU8hjlgIDNKGFPTLA9nmgqXYWwKOEyn11LXfferuZFUQeNaZcUJF6JF+D15JiAnGWXB+hOqGbcNpfaTwrtpeQY0wR9In3C/cKScwRJPfx7G9ufUpl7qIH9kVDn5mVKgQifQ2sUhCnPcbD2D5ltonQy4IcWnSBqk5NaYwHbquEeDTWs4/4SZL3kflwwZdvZYnVXfJYCfAdEw==
  • 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=p59MGlsfjfPY47MfXr6614MlMjhJ6jAXW3whboewMcc=; b=xM6u50rlP2v3VcJtCyVgqs24fcUXzjpU4J9CDhvsMI3tzCa3rwAY1ehRRDKY9PqaYz3d1kIwITkSZvypaeRcLdOYXLSQGk82vx8I+RGI50qsgZXmIL6RCMs7FH/KNpYT3wzXst80G10K4aMkjlrlbi93B3Gk3ZfHQKG4sJjzS/S3IrSoBx78PVVEil+A3RfMCJu4OVWpkNh4OacKzwA19MO/T4ys98C7FALmqi7bTSXDqJ/mgyKNO//EKlSufEK1OanJ2gmiQSQxH9Qck7Te1e2EBFo6ZjawQztFOywxWH/46uMtlqY0a3PLt7Pv4sUyHBftT2Na+1JqikoioUFDoQ==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=uezLU80t3/9tNXR6q7nyNCue99w4bBTM728eT/+iw6Kh/6ADhmmQ3TmJ3WJL5uAb6rULi+Qi75t6hs5YT9IGXMu79XMBbhtL7ZScHPUa6zXRRf/1rBLQOL3G2bcWOcW66HN7Rj0CvUIWwnNdVzzbaKzj39sFHNf6lgsX+fZCE4SaBcRHyiSINxoi/j/fkQc3lY6PseGUqkhMZGRsAreIKt+x75QRhqFu8T0ZboRIZmRz26u06kmqD7xkt70LFCgr5dJA0l/e03236GS1hXXUUS2SEFWqHH50DYDKev8sydNwiGUdkBZQCvXL6s8OBZDNkbWjff5FPzIL8QfsJP9fhA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V6TOAI0oZNCZAD67WKpMoP45FsUx8CMIAar6/OxUTAVTsPLSIDKYgEXS/xLxPafdajs9VAekO3ZkEJa7c3hc3aGE1jefR6rg3x3N/PpRzI5/+YW1IAmFVZvemFKrQedRwrDyicJWdy2NlPeiyye1Nc2NnOcIFCRNl1OW+WweGVlr73HNVno1fBkqFrzOGTZmq72Ohys72ExUZ4zKNV4WtlALdN92sfZ9+2NHyjKQiL8nhyvyJ3nmEJBzwXn8w2kk6TMvYT8DPYTwl0R6yD9evdiPb2C4WkQf6a1juK38nNt3/DLPR2BIT8aW0ZfSFn8m7tcBAriIHZDGgTn2dNFhLw==
  • 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>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>, Grygorii Strashko <grygorii_strashko@xxxxxxxx>
  • Delivery-date: Wed, 13 Nov 2024 14:34:20 +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: AQHbNdR4b2V2aTQ740yGxnKF6IdbXLK1RlIA
  • Thread-topic: [PATCH] xen/device-tree: Allow exact match for overlapping regions

Hi Julien,

> On 13 Nov 2024, at 14:01, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Luca,
> 
> On 06/11/2024 13:41, Luca Fancellu wrote:
>> There are some cases where the device tree exposes a memory range
>> in both /memreserve/ and reserved-memory node, in this case the
>> current code will stop Xen to boot since it will find that the
>> latter range is clashing with the already recorded /memreserve/
>> ranges.
>> Furthermore, u-boot lists boot modules ranges, such as ramdisk,
>> in the /memreserve/ part and even in this case this will prevent
>> Xen to boot since it will see that the module memory range that
>> it is going to add in 'add_boot_module' clashes with a /memreserve/
>> range.
>> When Xen populate the data structure that tracks the memory ranges,
>> it also adds a memory type described in 'enum membank_type', so
>> in order to fix this behavior, allow the 'check_reserved_regions_overlap'
>> function to check for exact memory range match given a specific memory
>> type; allowing reserved-memory node ranges and boot modules to have an
>> exact match with ranges from /memreserve/.
>> While there, set a type for the memory recorded during ACPI boot.
> 
> I am a bit confused which you mention only ACPI boot. Isn't the path also 
> used when booting using Device-Tree?

right, maybe this should be:

“While there, set a type for the memory recorded using meminfo_add_bank() from 
eft-boot.h."

>> 
>>  static bool __init meminfo_overlap_check(const struct membanks *mem,
>>                                           paddr_t region_start,
>> -                                         paddr_t region_size)
>> +                                         paddr_t region_size,
>> +                                         enum membank_type allow_match_type)
> 
> Looking at the callers, you only seem to pass MEMBANK_FDT_RESVMEM or 
> MEMBANK_NONE. So I wonder whether it actually make sense to introduce 
> MEMBANK_NONE. Wouldn't it be better to have a boolean indicating whether we 
> are looking for FDT_RESVMEM?

I wanted to give a more generic approach, but you are right, we could have a 
boolean like allow_match_memreserve.


> 
>>  {
>>      paddr_t bank_start = INVALID_PADDR, bank_end = 0;
>>      paddr_t region_end = region_start + region_size;
>> @@ -113,12 +114,16 @@ static bool __init meminfo_overlap_check(const struct 
>> membanks *mem,
>>          if ( INVALID_PADDR == bank_start || region_end <= bank_start ||
>>               region_start >= bank_end )
>>              continue;
>> -        else
>> -        {
>> -            printk("Region: [%#"PRIpaddr", %#"PRIpaddr") overlapping with 
>> bank[%u]: [%#"PRIpaddr", %#"PRIpaddr")\n",
>> -                   region_start, region_end, i, bank_start, bank_end);
>> -            return true;
>> -        }
>> +
>> +        if ( (allow_match_type != MEMBANK_NONE) &&
>> +             (region_start == bank_start) && (region_end == bank_end) &&
> 
> Why is this only an exact match?

Apparently what we are fixing is only a case where memreserve regions matches 
exactly modules or reserved_mem nodes.

> 
>> +             (allow_match_type == mem->bank[i].type) )
>> +            continue;
>> +
>> +        printk("Region: [%#"PRIpaddr", %#"PRIpaddr") overlapping with 
>> bank[%u]: [%#"PRIpaddr", %#"PRIpaddr")\n",
>> +                region_start, region_end, i, bank_start, bank_end);
>> +        return true;
>> +
>>      }
>>        return false;
>> @@ -169,9 +174,14 @@ void __init fw_unreserved_regions(paddr_t s, paddr_t e,
>>   * with the existing reserved memory regions defined in bootinfo.
>>   * Return true if the input physical address range is overlapping with any
>>   * existing reserved memory regions, otherwise false.
>> + * The 'allow_match_type' parameter can be used to allow exact match of a
>> + * region with another memory region already recorded, but it needs to be 
>> used
>> + * only on memory regions that allows a type (reserved_mem, acpi). For all 
>> the
>> + * other cases, passing 'MEMBANK_NONE' will disable the exact match.
>>   */
>>  bool __init check_reserved_regions_overlap(paddr_t region_start,
>> -                                           paddr_t region_size)
>> +                                           paddr_t region_size,
>> +                                           enum membank_type 
>> allow_match_type)
>>  {
>>      const struct membanks *mem_banks[] = {
>>          bootinfo_get_reserved_mem(),
>> @@ -190,8 +200,21 @@ bool __init check_reserved_regions_overlap(paddr_t 
>> region_start,
>>       * shared memory banks (when static shared memory feature is enabled)
>>       */
>>      for ( i = 0; i < ARRAY_SIZE(mem_banks); i++ )
>> -        if ( meminfo_overlap_check(mem_banks[i], region_start, region_size) 
>> )
>> +    {
>> +        enum membank_type type = allow_match_type;
>> +
>> +#ifdef CONFIG_STATIC_SHM
>> +        /*
>> +         * Static shared memory banks don't have a type, so for them disable
>> +         * the exact match check.
>> +         */
> 
> This feels a bit of a hack. Why can't we had a default type like you did in 
> meminfo_add_bank()?

This is the structure:

struct membank {
    paddr_t start;
    paddr_t size;
    union {
        enum membank_type type;
#ifdef CONFIG_STATIC_SHM
        struct shmem_membank_extra *shmem_extra;
#endif
    };
};

we did that in order to save space when static shared memory is not enabled, so 
we can’t have the
type for these banks because we are already writing shmem_extra.

We could remove the union but in that case we would waste space when static 
shared memory is
enabled.

Cheers,
Luca


 


Rackspace

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