|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH V2] xen/dom0less: Calculate guest DTB size based on MAX_VIRT_CPUS
On 04.12.25 16:21, Julien Grall wrote: Hello Julien > > > On 03/12/2025 22:25, Oleksandr Tyshchenko wrote: >> >> >> On 03.12.25 23:10, Julien Grall wrote: >>> Hi, >> >> Hello Julien >> >>> >>> On 03/12/2025 18:58, Oleksandr Tyshchenko wrote: >>>> Creating a dom0less guest with a high vCPU count (e.g., >32) fails >>>> because the fixed 4KiB device tree buffer (DOMU_DTB_SIZE) overflows >>>> during creation. >>>> >>>> The FDT nodes for each vCPU are the primary consumer of space, >>>> and the previous fixed-size buffer was insufficient. >>>> >>>> This patch replaces the fixed size with a formula that calculates >>>> the required buffer size based on a fixed baseline plus a scalable >>>> portion for each potential vCPU up to the MAX_VIRT_CPUS limit. >>>> >>>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx> >>>> --- >>>> V1: https://eur01.safelinks.protection.outlook.com/? >>>> url=https%3A%2F%2Fpatchew.org%2FXen%2F20251202193246.3357821-1- >>>> oleksandr._5Ftyshchenko%40epam.com%2F&data=05%7C02%7COleksandr_Tyshchenko%40epam.com%7C57bf7711ac4747de3d2f08de32b069ce%7Cb41b72d04e9f4c268a69f949f367c91d%7C1%7C0%7C639003930443970639%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=u6pp39%2FVto2vU7Hp5aXl46VF4zDvD8C79Xp09bbowS4%3D&reserved=0 >>>> >>>> V2: >>>> - update commit subj/desc >>>> - use a formula that accounts MAX_VIRT_CPUS >>>> - add BUILD_BUG_ON >>>> --- >>>> --- >>>> xen/common/device-tree/dom0less-build.c | 16 +++++++++++++--- >>>> 1 file changed, 13 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/ >>>> device-tree/dom0less-build.c >>>> index 3f5b987ed8..38a5830813 100644 >>>> --- a/xen/common/device-tree/dom0less-build.c >>>> +++ b/xen/common/device-tree/dom0less-build.c >>>> @@ -461,15 +461,25 @@ static int __init >>>> domain_handle_dtb_boot_module(struct domain *d, >>>> /* >>>> * The max size for DT is 2MB. However, the generated DT is small >>>> (not including >>>> - * domU passthrough DT nodes whose size we account separately), 4KB >>>> are enough >>>> - * for now, but we might have to increase it in the future. >>>> + * domU passthrough DT nodes whose size we account separately). The >>>> size is >>>> + * calculated from a fixed baseline plus a scalable portion for each >>>> potential >>>> + * vCPU node up to the system limit (MAX_VIRT_CPUS), as the vCPU >>>> nodes are >>>> + * the primary consumer of space. >>>> + * >>>> + * The baseline of 2KiB is a safe buffer for all non-vCPU FDT content. >>> >>> What if the use decides to pass a DTB fragment? How do we know this will >>> fit in the 2KiB? >> >> If a partial device tree is provided then it will be accounted >> separately. There is a code, non-visible is the context, so I think, we >> are good here. > > Ah yes! I missed that code. Sorry for the noise. > >> >> >>> >>>> + * Empirical testing with the maximum number of other device tree >>>> nodes shows >>>> + * a final compacted base size of ~1.5KiB. The 128 bytes per vCPU is >>>> derived >>>> + * from a worst-case analysis of the FDT construction-time size for a >>>> single >>>> + * vCPU node. >>> >>> For in-code documentation, this is ok to just provide some numbers. But >>> this needs a bit more details in the commit message with the exact tests >>> you did. This would be helpful if we ever need to change the size (for >>> instance we could have extra emulated devices or we need another >>> property per CPU). >> >> ok, I will add my testing details into the commit description. >> >>> >>>> */ >>>> -#define DOMU_DTB_SIZE 4096 >>>> +#define DOMU_DTB_SIZE (2048 + (MAX_VIRT_CPUS * 128)) >>> >>> On Arm32, MAX_VIRT_CPUS is 8. This means the new DOMU_DTB_SIZE is going >>> to be smaller than 4096. Why is it ok? >> >> You are correct to question the impact on Arm32, where MAX_VIRT_CPUS is >> smaller, leading to a calculated buffer size of 3072 bytes, which is >> less than the original 4096 bytes. >> >> Unfortunately, I have no possibility to test on Arm32. But, I do not see >> much difference between Arm64 and Arm32 in the context of DomU device >> tree generation by looking into the code. >> >> I simulated this exact environment on my Arm64 setup to validate that >> the new size remains sufficient. To do this, I temporarily switched >> MAX_VIRT_CPUS to 8 and ran tests with 1 and 8 vCPUs. > > Thanks for doing that! I also see Luca is going to help. If he also > confirms the size is good then can you mention the change for Arm 32-bit? Yes, sure > > Cheers, >
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |