[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 10/13] xen/arm: remove shm holes from extended regions
- To: Michal Orzel <michal.orzel@xxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Wed, 10 Apr 2024 14:08:05 +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=armh.onmicrosoft.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=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=ltsPFWhJLxKQAabjmdEhyDMnVaRfWXK24rj3aHIp5FU=; b=oXSgdWcM3tUX1vMJ5E/LUi10uzdgADK/ZWbBF9SRszE6fdEdHsLn8BUoBHdtalCj5roVfm4Lw4vAb5dFl/E+UDP2P/caidSNVqLm2SjiZRCjVDeLzjErfW2TKBpSZt9xcGLYnz636/ZTnGGmqZh6Loih1hRO7ZVgb/tabShyYOF6VYQzf97K6FgG97Mlx8b4ScqcmekK79Vb08KNcL6fwjAytqKkx/kNkHZeQoulra6OwANAIBghTttlI0FkDAcLKrHlDeJhyMLhQnTBdZroDGiI5X7HzlatuxQzLGcXNrLulvzYLGahbxQbvsPUtBnDH4AHDOUXFaT7Xqq36eZZsw==
- 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=ltsPFWhJLxKQAabjmdEhyDMnVaRfWXK24rj3aHIp5FU=; b=PyciLrR5d3NpGsDL1bjeXv4RDcvBp5OPwkF+D0FMrM29CRIYuur/UVsH23axc87Z7WunhQEGhi2dEG9pr7lIIkxA6JsQXjkEFNBd+JASsv1IrOA2quKc4pgWnClPn2L1fi6aQxqs+4zeEbkrRz5YkK9v246iRHcpeF3G50XWthXXvP7MTWlzit1vXDLgBfjeS7JOOI5ax2qnibmI5KDkzYJ6Go69c/26Nu1Yop59M0bTZm7IinjL6he2lWHGVekJujXKWneJxKk7Lydw8BefGTElI8cF0i60ZCK67IIhKmjmZ+xlgDYigYtoRng6rxnvWkGejHx4GsmJ0wVF8Zfm0g==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=N3a/xfIG6ZnJGM+GNqxw0f8CZWpCgMuuWT8KLDMcz+NphEPyWBs9VrLDuZrmP2I9JiTsEty0PS3rVOY3mcGGBrC+Uf087sRr+EboK6y0z9vH9E9up8NTiedGuSpMKb3eG5+heUwZ8ciIrtfedDr1sb5mPwBTAZfcwhWZfx8e51SEar6W5bKLg+gE266eafzavo8B15WWEZDTnZEdm9F/YLJGKJUXPXfyAfm5BiP4js3djl85/8ST7PIqyFZxgbfFuG7NJcaUe0lpQFX/VMZpoliB1Yjjkk8v9SqBv+wxcuNUADEBlUhAKVa4Mc0V28RThCk4Z4w0zrslHI/Tffg/9Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N/J2D10s15aAfFWh6lS341EJHzN0nycYtwZvzThIHEE4+0mj16C3MBDWARb7oPXu9PmZDiHWETFok1FDRot0dZBzMiiwRi5vh8MDuDPfaAydioGa/m4WwuMalby1LnYT/Ju1TRW31bztjJE+Z5r+T9/4O3wBcxL+9U9HuZjcE0AFH3PujA4KQ5QndMbhtBqibUYYTlmP7sR4hpUd0QytjE1DiZ3S8w81g9U/QsPNhRPUcg626rAVi6SoDjsHpBlK2MSBo48RrbcaURAfj38D2pdyE/MDjfal3zdg8Pc52qZnfm2dKF/aC0anlcOFpE8xu6Nf0TM+eSOifSzG70171g==
- Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Penny Zheng <Penny.Zheng@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
- Delivery-date: Wed, 10 Apr 2024 14:08:36 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Thread-index: AQHainORNadX2Zn/QkSGO7PTdS59ZLFhXAaAgAAwCoA=
- Thread-topic: [PATCH v2 10/13] xen/arm: remove shm holes from extended regions
Hi Michal,
>>
>> For direct-map domain with iommu on, after we get guest shm info from
>> "kinfo",
>> we use "remove_shm_from_rangeset" to remove static shm.
>>
>> For direct-map domain with iommu off, as static shm has already been taken
>> care of through reserved memory banks, we do nothing.
> Stale info given that shmem is no longer part of reserved memory banks. It's
> been taken care
> of by removing shmem regions in find_unallocated_memory()
Sure, will amend for this:
>>
>> +int __init remove_shm_from_rangeset(const struct kernel_info *kinfo,
>> + struct rangeset *rangeset)
>> +{
>> + const struct membanks *shm_mem = &kinfo->shm_mem.common;
>> + unsigned int i;
>> +
>> + /* Remove static shared memory regions */
>> + for ( i = 0; i < shm_mem->nr_banks; i++ )
>> + {
>> + paddr_t start, end;
>> + int res;
>> +
>> + start = shm_mem->bank[i].start;
>> + end = shm_mem->bank[i].start + shm_mem->bank[i].size - 1;
> If you look at other rangeset_remove_range use cases and error messages, 1 is
> subtracted
> in PFN_DOWN() so that the error message contains end unchanged. Please adhere
> to that so that
> printed messages are consistent.
Yes I will change it to have -1 inside PFN_DOWN(), here and in the other
occurrences
>>
>> + /* Remove static shared memory regions */
>> + res = remove_shm_from_rangeset(kinfo, guest_holes);
>> + if ( res )
>> + goto out;
>> +
> Could you please add a comment explaining here what's done below?
Is it ok something like this:
/*
* Take the interval of memory starting from the first extended region bank
* start address and ending to the end of the last extended region bank.
* The interval will be passed to rangeset_report_ranges to allow it to
* create, by the add_ext_regions callback, a set of extended memory region
* banks from the guest_holes rangeset, which contains the original extended
* memory region ranges where the static shared memory ranges are carved
* out.
*/
>> + i = ext_regions->nr_banks - 1;
>> + start = ext_regions->bank[0].start;
>> + end = ext_regions->bank[i].start + ext_regions->bank[i].size - 1;
>> +
>> + /* Reset original extended regions to hold new value */
>> + ext_regions->nr_banks = 0;
>> + res = rangeset_report_ranges(guest_holes, PFN_DOWN(start),
>> PFN_DOWN(end),
>> + add_ext_regions, ext_regions);
>> + if ( res )
>> + ext_regions->nr_banks = 0;
>> + else if ( !ext_regions->nr_banks )
>> + res = -ENOENT;
>> +
>> + out:
>> + rangeset_destroy(guest_holes);
>> +
>> + return res;
>> +}
>> +
>> /*
>> * Local variables:
>> * mode: C
>> --
>> 2.34.1
>>
>
> ~Michal
>
Cheers,
Luca
|