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

Re: [PATCH v2] xen/arm: p2m: Populate pages for GICv2 mapping in arch_domain_create()


  • To: Henry Wang <Henry.Wang@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 14 Oct 2022 11:21:08 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=03wwF/dVQjIzfT260xxVyDdVXv1EHXZkwy2odbHHj3M=; b=IupBgLlWXgprui/vuvyw+2mqUYC8GyLNJoZQWxASd0KxY2O0OG09/gyoaAr+364AMkdBUCT2XyJm3HzCA7cVUiu1Xgy0ijF7OEAWevU+Iwr023WJdO+wcWboOjxJA06jXjAW0mFBnQ/WPI3tX8OJPjqFb2MlOTGKE5cs5aYOxZrZDaV1ZJSEJ4AMJblIWuAK/Wg0BbNDFfDrsH1zK4wj0H3liX2nfWl39Dk1lXXxyLQ1JAumSg5+w5EF9SCvBYr7UcryliLjVfYVsLNk0UA8YnohBY3CtY9PmniqVfV6DmzdmXadKxtPKc6GBAZKzCblzCzG2t5TG1uvbT5otyHDaw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LmBjyOZdWnrSonQfF/WZcFhJsTa4WrvQLlXBTHGIrmUgQLVQJBYLaxWSCQJW/i0xfyJ2dCLegQSgAOo5UhndIK+zK9kIfSFlUzbLLC4fMtG5nWgBmbDYV+RIQ/RSg6QZ24pBwcxX09kKjoWZGAfyJCUnUkOaJSZdUAbUkQv+/U4e+vFaob7HW4hSDJVat4eNd9FgGmGGI1EZDpUT9GhqAif4hCQqzcnb62h/qMPFmkOfdF1PflteYpklR766WNBGt9gMAt9ELXAy4zAYVt1uyslRH/1sjWe+sdtfqPLahyo5o+b8UJjqma+nd2C3YGfPz3sRuMNWuOABDyhMhu0F8w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Wei Chen <wei.chen@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 14 Oct 2022 09:21:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 14.10.2022 10:09, Henry Wang wrote:
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -740,6 +740,20 @@ int arch_domain_create(struct domain *d,
>          BUG();
>      }
>  
> +    /*
> +     * Hardware using GICv2 needs to create a P2M mapping of 8KB GICv2 area
> +     * when the domain is created. Considering the worst case for page
> +     * tables and keep a buffer, populate 16 pages to the P2M pages pool 
> here.
> +     * For GICv3, the above-mentioned P2M mapping is not necessary, but since
> +     * the allocated 16 pages here would not be lost, hence populate these
> +     * pages unconditionally.
> +     */
> +    spin_lock(&d->arch.paging.lock);
> +    rc = p2m_set_allocation(d, 16, NULL);
> +    spin_unlock(&d->arch.paging.lock);
> +    if ( rc != 0 )
> +        goto fail;

Putting this level of knowledge here feels like a layering violation to
me. My first suggestion would be to move this call somewhere under
p2m_init(). If that's not possible for some reason, I'd like to suggest
passing 1 here as the count and then adding a min-acceptable check to
p2m_set_allocation() along the lines of x86'es shadow_set_allocation().
That way you'd also guarantee the minimum number of pages in case a
subsequent tiny allocation request came in via domctl.

> @@ -1736,6 +1736,17 @@ void p2m_final_teardown(struct domain *d)
>      if ( !p2m->domain )
>          return;
>  
> +    if ( !page_list_empty(&p2m->pages) )
> +        p2m_teardown(d, false);
> +
> +    if ( d->arch.paging.p2m_total_pages != 0 )
> +    {
> +        spin_lock(&d->arch.paging.lock);
> +        p2m_set_allocation(d, 0, NULL);
> +        spin_unlock(&d->arch.paging.lock);
> +        ASSERT(d->arch.paging.p2m_total_pages == 0);
> +    }

Is it intentional to largely open-code p2m_teardown_allocation() here?

Jan



 


Rackspace

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