[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH V6 1/2] xen/gnttab: Store frame GFN in struct page_info on Arm
- To: Julien Grall <julien@xxxxxxx>, Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 24 Jun 2022 08:45:59 +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=eQDrSFZylcM5YAFa8zNM1v4ZA0XXyJhh/B28gevNPj0=; b=TDMCy9Xl7ie8wP083yBTl32G9ZAoInqqpY1ngdoq7oIHl0gP/Huca91kk+B4q2pKsHokrv2M3pVQw07T60DM7dou1QIyq4Oe5WM1DC8+ZGiG9Yiw4nhuthGrcBgRpCKAxFw7BTJldE3dZrOxpk6Rz19eWhG+tndQlY9qiifPXOAQAZHSwn+gegjAJduLPNgX9RpkG7dCA0QJr5nM7e9qb0mwbn0ixClq8H/gLnptLUU8zpX1O4ZG665njF1eucTGOQEd8j8JSUSw4WYoWa2j3vgVuNKBGq3v/reTSuOPipuG/9xJYBdxHVoiBHvbwR4BSw4XVYV3R7BeH1gcV9XOcA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V8Mj9VMISWfAtQoqGfW002w7ULaSqIRbGkTCtLSDHbftVNWShqEHCniDEGpkr5TOApYegtttguErv9I24ZjhJkcSHXnu9KOPCVN9Ep1lubmbQKdyTRXYYiGlO7oagipMeYunUsKpaqLbafaRJnFnlxzqvs/Io+mluYiQf77xDCDwviAnc0EPH57+ed9q6N4TrYdjQspG4H35Sn8Q6NgWRMabqftDETAALtAlLBuBX4FyfzoJaS7Qwdhg9QVRRQQZeknS5Kx4y5mZLFMAKYbE36TnXhWTcx6GFSToAHZQ5O7xDwapB28txavVKKjhhHLHbJwrxE6ZWZBZ5sPFBMfGSw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Fri, 24 Jun 2022 06:46:16 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 23.06.2022 19:50, Julien Grall wrote:
> On 11/05/2022 19:47, Oleksandr Tyshchenko wrote:
>> @@ -1505,7 +1507,23 @@ int xenmem_add_to_physmap_one(
>> }
>>
>> /* Map at new location. */
>> - rc = guest_physmap_add_entry(d, gfn, mfn, 0, t);
>
>> + if ( !p2m_is_ram(t) || !is_xen_heap_mfn(mfn) )
>> + rc = guest_physmap_add_entry(d, gfn, mfn, 0, t);
>
> I would expand the comment above to explain why you need a different
> path for xenheap mapped as RAM. AFAICT, this is because we need to call
> page_set_xenheap_gfn().
>
>> + else
>> + {
>> + struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +
>> + p2m_write_lock(p2m);
>> + if ( gfn_eq(page_get_xenheap_gfn(mfn_to_page(mfn)), INVALID_GFN) )
>
> Sorry to only notice it now. This check will also change the behavior
> for XENMAPSPACE_shared_info. Now, we are only allowed to map the shared
> info once.
>
> I believe this is fine because AFAICT x86 already prevents it. But this
> is probably something that ought to be explained in the already long
> commit message.
If by "prevent" you mean x86 unmaps the page from its earlier GFN, then
yes. But this means that Arm would better follow that model instead of
returning -EBUSY in this case. Just think of kexec-ing or a boot loader
wanting to map shared info or grant table: There wouldn't necessarily
be an explicit unmap.
Jan
|
