[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e402502-acbc-2718-26d4-cbcf83697c15@citrix.com>
Date: Thu, 18 Jul 2019 18:36:25 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Juergen Gross <jgross@...e.com>, <xen-devel@...ts.xenproject.org>,
<linux-kernel@...r.kernel.org>
CC: Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Stefano Stabellini <sstabellini@...nel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/gntdev: replace global limit of
mapped pages by limit per call
On 18/07/2019 07:52, Juergen Gross wrote:
> Today there is a global limit of pages mapped via /dev/xen/gntdev set
> to 1 million pages per default.
The Xen default limit even for dom0 is 1024 pages * 16 entries per page,
which is far lower than this limit.
> There is no reason why that limit is
> existing, as total number of foreign mappings is limited by the
s/foreign/grant/ ?
> hypervisor anyway and preferring kernel mappings over userspace ones
> doesn't make sense.
Its probably also worth stating that this a root-only device, which
further brings in to question the user/kernel split.
>
> Additionally checking of that limit is fragile, as the number of pages
> to map via one call is specified in a 32-bit unsigned variable which
> isn't tested to stay within reasonable limits (the only test is the
> value to be <= zero, which basically excludes only calls without any
> mapping requested). So trying to map e.g. 0xffff0000 pages while
> already nearly 1000000 pages are mapped will effectively lower the
> global number of mapped pages such that a parallel call mapping a
> reasonable amount of pages can succeed in spite of the global limit
> being violated.
>
> So drop the global limit and introduce per call limit instead.
Its probably worth talking about this new limit. What is it trying to
protect?
~Andrew
Powered by blists - more mailing lists