[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: Wed, 22 Mar 2023 02:31:09 +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=7jX1oG3+XeOgGd/2zNpMQRzPXLeF5fWkKbcjXabcumg=; b=l0ydcZjOjAF8zUDlzClfR7s3aB9hpvLoA5YoSErOg633JM2MjcTJRtiy4t+tucsXXRI/PZSi8MdR0OnJ4lAhTQ8Q2H0QeYR7SvV8BVprKbHFOXRK+Gdu7D/lCR5fRgGJDcie/gbvpaKcEJpM6ucsg1qk+5KW1oKvpAy4JYTbeTwPEKSn/tij8NDx5gihbQpMAjQSywCaXcOzWY/5+80GzmT7/1ZFRmrfQgv6nc18FEQxQesjzJn52SYkfbE6i+cPO2iSFo+JM/bppH+7PMY+Nit61Es3p6z2XEfoNDc9NXm+41UnW99e+cokdSgvRBSWgqA7kiESXLpC9J++XiX43g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=isaYhQaO8WkrY6ptLLPvOE6kKv26qRXGII1aG/WnQ245+4e8Dep6cVs6w+RFX7LzAjybyqDAxejnQH8V39x1WAM9Vh5iiC4wPQgrXDwFlD5PyQlPsOxFj7WcHbowC/7G17dmPuTVUTC8JmOEXLJ1UPvtOCqzC8S8GLty5gkGRhiyd3mZQj9FlDMXTaJRaL7nDpZlb8574+6T0Me9ihRj3fqprNqFUbtjfREZIJJZkFAYCE/XU6Ck/rn5RBx6xEHcJraZzhIqBMMTjhWY8ADNeeNGf05IcIV70PsLi2Cm1xDeMK2G6MKCx1HdzFLjtf9bOWRV+uCunfHIOnUws1Eo1A==
- 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: Wed, 22 Mar 2023 02:31:39 +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+mzqer9SysH68EWvQAgACL1MCAAMYdAIAAtLIg
- Thread-topic: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until the first access
Hi Julien,
> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Subject: Re: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until
> the first access
>
> > gfn_to_gaddr(gfn) >= d->arch.vgic.cbase ||
> > gfn_to_gaddr(gfn) < d->arch.vgic.cbase + d->arch.vgic.csize
>
> ... use the size in the check. With the || switch to &&, my preference
> would be to use:
>
> ((d->arch.vgic.cbase - gfn_to_addr(gfn)) < d->arch.vgic.csize)
>
> to avoid a potential overflow in the unlikely case the CPU interface is
> at the top of the address space.
Oh I like the idea of using the "minus approach" to avoid the overflow
very much. Thanks! I will keep this in mind in my future development.
One more question, since this "minus approach" is directly derived from
`gfn_to_gaddr(gfn) < d->arch.vgic.cbase + d->arch.vgic.csize`,
shouldn't it be
`(gfn_to_addr(gfn) - d->arch.vgic.cbase) < d->arch.vgic.csize` instead?
Otherwise I think `d->arch.vgic.cbase - gfn_to_addr(gfn)` will produce
a huge u64 and this check would always fail?
Kind regards,
Henry
>
> Cheers,
>
> --
> Julien Grall
|
