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

RE: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until the first access


  • To: Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Henry Wang <Henry.Wang@xxxxxxx>
  • Date: Tue, 21 Mar 2023 03:57:47 +0000
  • Accept-language: zh-CN, 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=xb3UNfuZqvbXOKhi0QGLZ8JbSSwquB9K/9g1hl4rZDw=; b=JbqBUE6TJVWC1DEliBsWrgJmyzpYCN9j0tWbwF16+eZggPpYcPzyJyvfrz+LL9u4oA2yrCTu2COGEgQ7IkgmKWYSxoRvkuwnRI/G5sLx3UFcuNHJZD7FfHsIfd+eMCTgff+3TYgMA8qJloGSNqaVpM1abiEjh+0xIs+EXMQM8X4Lw7oJshI6FrU0KpHLUzZ45YGJT5JTTUPTaV0F4kcxrB+eZ5j1oxeohTBpdKmfyzGQgVw4IygpZ9MUGHryI6CY0PBJbiRmkon1BNuNhAG0Vp8oeMIk7xtUy1QBLMsTqzxGtxGKlUzaF9LObRvlRo0XR/XIUnGQEE5TWXmytY07tQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qt/7O6u//XEWBDnQWsQRJn5ewBRNHXCrKUQ3V+UHU1L2V2yM+0/yMH7cqqu5cMdWN6VKLafFXVO6Lka0hnV/PQZy/91TqARMS83C8NYyjiiftLQ7dFEgQaQFnBvwoVqYTeXmXGEIlCSUdXjN1DFI3b0dWbjLBjopNR5YgTWNPH7hwuky7Scmto9KbEmHUwRJU7o2NCA7JA8K/vW0KkcHLT8tuwz0JJxl3arGXYUERhHBFEA5Hl3sZNNUK15k1yorX98BJ60G3zcAE7xb4RK5HhC+VOjDv+x1BSOy7LsrG4SBifwBI3p4sSRLgLfxt+Q0fz4V2n/26pBlvD6UzHbkcQ==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Tue, 21 Mar 2023 03:58:22 +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: AQHZNGBES9GND13bPU+mzqer9SysH68EWvQAgACL1MA=
  • Thread-topic: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until the first access

Hi Julien,

Thanks very much for your time and review :)

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Subject: Re: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until
> the first access
> 
> Hi Henry,
> 
> On 30/01/2023 04:06, Henry Wang wrote:
> > Since the hardware domain (Dom0) has an unlimited size P2M pool, the
> > gicv2_map_hwdom_extra_mappings() is also not touched by this patch.
> 
> I didn't notice this in the previous version. The fact that dom0 has
> unlimited size P2M pool doesn't matter here (this could also change in
> the future). Even if the P2M pool was limited, then it would be fine
> because the extra mappings happen after domain_create(). So there is no
> need to map them on-demand as the code could be order the way we want.
> 
> So this paragraph needs to be reworded.

Sure, I've reworded this paragraph to below:
"Since gicv2_map_hwdom_extra_mappings() happens after domain_create(),
so there is no need to map the extra mappings on-demand, and therefore
keep the hwdom extra mappings as untouched."

> 
> > +    /*
> > +     * Map the GICv2 virtual CPU interface in the GIC CPU interface
> > +     * region of the guest on the first access of the MMIO region.
> > +     */
> > +    if ( d->arch.vgic.version == GIC_V2 &&
> > +         gfn_eq(gfn, gaddr_to_gfn(d->arch.vgic.cbase)) )
> 
> The CPU interface size is 8KB (bigger in some cases) but here you only
> check for the access to be in the first 4KB.

Yeah indeed, gfn might fall into the range between 4KB and 8KB, sorry
about that.

Considering that the CPU interface is continuous (I suppose), I have two
ways of rewriting the gfn check, we can do either:

gfn_eq(gfn, gaddr_to_gfn(d->arch.vgic.cbase)) ||
gfn_eq(gfn, gfn_add(gaddr_to_gfn(d->arch.vgic.cbase), 1))

or

gfn_to_gaddr(gfn) >= d->arch.vgic.cbase ||
gfn_to_gaddr(gfn) < d->arch.vgic.cbase + d->arch.vgic.csize

May I ask which one would you think is better? Thanks!

Kind regards,
Henry

> 
> Cheers,
> 
> --
> Julien Grall

 


Rackspace

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