linux-kernel - Re: [Xen-devel] [PATCH RFC 4/4] xen-block: introduce a new request type to unmap grants

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51DFD67E.6000507@citrix.com>
Date:	Fri, 12 Jul 2013 11:12:14 +0100
From:	David Vrabel <david.vrabel@...rix.com>
To:	Roger Pau Monné <roger.pau@...rix.com>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	<linux-kernel@...r.kernel.org>, <xen-devel@...ts.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 4/4] xen-block: introduce a new request
 type to unmap grants

On 11/07/13 16:48, Roger Pau Monné wrote:
> On 11/07/13 17:26, David Vrabel wrote:
>> On 11/07/13 16:12, Roger Pau Monné wrote:
>>> On 11/07/13 15:48, David Vrabel wrote:
>>>> It also seems odd to have the backend decide how much frontend resource
>>>> can be consumed at anyone time.  It's not clear how the backend is
>>>> supposed to know how many persistent grants it should hang on to.
>>>
>>> blkfront has to at least persistently map the same grants as the
>>> backend. blkfront could persistently map all grants, but then we will
>>> have grant shortage, and I doubt there's much performance gain from
>>> persistently mapping grants in blkfront but not blkback (since the
>>> biggest performance penalty comes from the unmapping done in blkback and
>>> TLB flush involved).
>>
>> I'm saying that the frontend needs to be able to set a cap on the number
>> of persistent grants kept by the backend.  If other demands on a
>> domain's grant table resource means it can only spare G grants for a
>> particular frontend it needs to be able to ensure this (with the
>> cooperation of the backend).
> 
> We could easily negotiate the maximum number of persistent grants with
> the backend using a xenstore node, but how is blkfront going to decide
> how many persistent grants it wants to use? Should we coordinate this
> somehow with all the users of the grant table?
> 
> Doing it in the backend doesn't seem to me like a really bad approach,
> the admin of the host should know the maximum number of disks/nics a
> guest can have, and thus set the maximum number of persistent grants
> appropriately (and also tune gnttab_max_nr_frames if needed).

That sounds reasonable.  The host admin doesn't necessarily know how
many grant entries the guest might use for inter-domain communication
but they can certainly allow for a reasonable of spare entries for this.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/