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

RE: [PATCH v1 06/13] xen/arm: assign shared memory to owner when host address not provided


  • To: Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Penny Zheng <Penny.Zheng@xxxxxxx>
  • Date: Tue, 10 Jan 2023 03:38:24 +0000
  • Accept-language: 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=3e9AB8zKSikcyZ/BJHR3Insf+vBAyU5ZbNaFxgDySyY=; b=ifkVRWah4P9d/Cosh9S1jsy7nPqJqaRMR+AOxdXe4aDmPm3psmCHxEIJa8i7nYTCqGauQRvPlX2xXLyPEbRDv1TQ6+B2Xh9i7gsFa4pUxrIkPNYtiuvTjJd4EVOqIdB83G8+p8WZ0+KnCtS+t/P8414WpI2JdaLAlrh8eMAEC3B3IwNw97J3Boewc5ZMSvOGIun4DtiD1ng5Hg8GQiMszfsMk5FbeORcB0bkE5LwUo01IRQkGgUhBkC6IzcfvDmQ+6T6WIcU8U4BcEfSeM+79+PnYOIFx1WCeO6qJ8cysk3s7f/2gYMdXTi7MSiwIBP5TJxZD6gXBxGX7XauPUShTg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cMa+DMhSjSeids7d8uTD+vobVs+TebXxHUZZbFPBzkRot52ZUlw36Zf/BnIesVFEmdIsKGMBEeYuCqpfyF3LYjRjfv1AC2PhjPOXy2k0IEa0i+n7FvoBSAh3plGHNhEMmtJbr1mLW/nXTjXkWsYEPf39IDY4oZ3ahC6OLe13RR74f1woJ6VSlV5dNNkH/A/GJ5EIq4Efl1c08zJWr2sPjcDeDmGcLtmUbygjj/ct9ekGgMv0KiT3vGnC6uzWBLgUBUgzYdW4kGSTIyNBE/V6dv7ik33FBwUcKX65CIBjM0FRf8z2zFOdyCMn2fLZ9MVMqTB+4Uu3Gg4yL/uvgALotQ==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Wei Chen <Wei.Chen@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Tue, 10 Jan 2023 03:38:55 +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: AQHY+J1pmmYEajWz5UynKX+c5rdEZK6UzwiAgAEQoXCAAGGAAIAACRWAgABzZYCAAJEhAA==
  • Thread-topic: [PATCH v1 06/13] xen/arm: assign shared memory to owner when host address not provided

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Sent: Tuesday, January 10, 2023 2:23 AM
> To: Penny Zheng <Penny.Zheng@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Wei Chen <Wei.Chen@xxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; Bertrand Marquis <Bertrand.Marquis@xxxxxxx>;
> Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
> Subject: Re: [PATCH v1 06/13] xen/arm: assign shared memory to owner
> when host address not provided
> 
> Hi Penny,

Hi Julien,

> 
> On 09/01/2023 11:58, Penny Zheng wrote:
> >> -----Original Message-----
> >> From: Julien Grall <julien@xxxxxxx>
> >> Sent: Monday, January 9, 2023 6:58 PM
> >> To: Penny Zheng <Penny.Zheng@xxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> >> Cc: Wei Chen <Wei.Chen@xxxxxxx>; Stefano Stabellini
> >> <sstabellini@xxxxxxxxxx>; Bertrand Marquis
> >> <Bertrand.Marquis@xxxxxxx>; Volodymyr Babchuk
> >> <Volodymyr_Babchuk@xxxxxxxx>
> >> Subject: Re: [PATCH v1 06/13] xen/arm: assign shared memory to owner
> >> when host address not provided
> >>
> >>
> >>
> >> On 09/01/2023 07:49, Penny Zheng wrote:
> >>> Hi Julien
> >>
> >> Hi Penny,
> >>
> >>> Happy new year~~~~
> >>
> >> Happy new year too!
> >>
> >>>> -----Original Message-----
> >>>> From: Julien Grall <julien@xxxxxxx>
> >>>> Sent: Sunday, January 8, 2023 8:53 PM
> >>>> To: Penny Zheng <Penny.Zheng@xxxxxxx>; xen-
> >> devel@xxxxxxxxxxxxxxxxxxxx
> >>>> Cc: Wei Chen <Wei.Chen@xxxxxxx>; Stefano Stabellini
> >>>> <sstabellini@xxxxxxxxxx>; Bertrand Marquis
> >>>> <Bertrand.Marquis@xxxxxxx>; Volodymyr Babchuk
> >>>> <Volodymyr_Babchuk@xxxxxxxx>
> >>>> Subject: Re: [PATCH v1 06/13] xen/arm: assign shared memory to
> >>>> owner when host address not provided
> >>>>
> >>>> Hi,
> >>>>
> >>>
> >>> A few concerns explained why I didn't choose "struct meminfo" over
> >>> two pointers "struct membank*" and "struct meminfo*".
> >>> 1) memory usage is the main reason.
> >>> If we use "struct meminfo" over the current "struct membank*" and
> >>> "struct meminfo*", "struct shm_meminfo" will become a array of 256
> >>> "struct shm_membank", with "struct shm_membank" being also an 256-
> >> item
> >>> array, that is 256 * 256, too big for a structure and If I
> >>> remembered clearly,
> >> it will lead to "more than PAGE_SIZE" compiling error.
> >>
> >> I am not aware of any place where we would restrict the size of kinfo
> >> in upstream. Can you give me a pointer?
> >>
> >
> > If I remembered correctly, my first version of "struct shm_meminfo" is
> > this
> > "big"(256 * 256) structure, and it leads to the whole xen binary is
> >. ;\
> 
> Ah so the problem is because shm_mem is used in bootinfo. Then I think we
> should create a distinct structure when dealing with domain information.
> 

Yes, If I use the latter "struct shm_info", keeping the shm memory info out of 
the bootinfo,
I think we could avoid "bigger than 2MB" error.

Hmm, out of curiosity, The way to create "distinct" structure is like creating 
another section
for these distinct structures in lds, just like the existing .dtb section?
 
> >
> >>> FWIT, either reworking meminfo or using a different structure, are
> >>> both leading to sizing down the array, hmmm, I don't know which size
> >>> is suitable. That's why I prefer pointer and dynamic allocation.
> >>
> >> I would expect that in most cases, you will need only one bank when
> >> the host address is not provided. So I think this is a bit odd to me to
> impose a "large"
> >> allocation for them.
> >>
> >
> > Only if user is not defining size as something like (2^a + 2^b + 2^c +
> > ...). ;\ So maybe 8 or 16 is enough?
> > struct new_meminfo {
> 
> "new" is a bit strange. The name would want to be changed. Or maybe better
> the structure been defined within the next structure and anonymized.
> 
> >      unsigned int nr_banks;
> >      struct membank bank[8];
> > };
> >
> > Correct me if I'm wrong:
> > The "struct shm_membank" you are suggesting is looking like this, right?
> > struct shm_membank {
> >      char shm_id[MAX_SHM_ID_LENGTH];
> >      unsigned int nr_shm_borrowers;
> >      struct new_meminfo shm_banks;
> >      unsigned long total_size;
> > };
> 
> AFAIU, shm_membank would still be used to get the information from the
> host device-tree. If so, then I am afraid this is not an option to me because 
> it
> would make the code to reserve memory more complex.
> 
> Instead, we should create a separate structure that will only be used for
> domain shared memory information.
>

Ah, so you are suggesting we should extract the domain shared memory 
information only
when dealing with the information from the host device-tree, something like 
this:
struct shm_info {
      char shm_id[MAX_SHM_ID_LENGTH];
      unsigned int nr_shm_borrowers;
}

I'll try and may *bother* you when encountering any problem~ 
 
> Cheers,
> 
> --
> Julien Grall

 


Rackspace

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