[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 4/4] xen/version: Introduce non-truncating XENVER_* subops
- To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 6 Jan 2023 08:56:48 +0100
- 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=JRhZxzzZ3J6kJnMtHAlWdvDXceG75enGMlLVUHsUWvE=; b=fNYmCoNc4IGsnFAbChKwC90zH872QGfWjPuiMTwy2mkVB8vyznxWf2Y+rAJDSMaP7+/W08kk66j6XKQEVhiHf0Ct73fstaeiHZ+DazZp+J9IAd077BaWNJ81uZOz8stlnLgzZIdH1P3UPoVI0xM2S9hMCQ2E51tbIfuXzaacAKIf4Ys7tP+0E1g7oCn+pAy7dyJj7VsxXnV3/sUML4OFRGq6/asPV0UKqjlohy9M9m96V4w5tLyH+o7Yp2j6lvB+BCWdH2dyi4C4KqPKPqXRlpTb4c70r0mvJ8EFcwxhveZ1v2Xk+whbGpMgB3cxwyhOL0dV4aQ7FRWBdzusFyaLeA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d9JQ8z+niPqPw2LkBL00+4xDnfDwMmHDHKyCSDQk/T0nikroYfuh3ZgXS1NXf9gOurmZmf4h7EmWUsLpC/nvGYTexIhi+2p4hLmtz8fOX6uF9ayQnwwvhMDL0zg8BPjreoUUy8l0NO6jnWVXVUS3Xjgetyk0YlCsezviNFxIjH3iYukwZUDCSYpBT4+tzlVtT6XrRqLs04saEpKlAs4dlfM0GbSPpl0IeRf/4EtwQ4YxRCV+GTZWK3un/aXybgQ5nvUqZo3iy4cLPLKB4M5b2DVI9vhmj5K7H1eZ6nuIylTEgZyH/iDNDcHqNaYcxsB47O/WIS8d7v2jPeWaSE5NCQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 06 Jan 2023 07:56:55 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 05.01.2023 23:28, Andrew Cooper wrote:
> On 05/01/2023 8:15 am, Jan Beulich wrote:
>> On 04.01.2023 19:34, Andrew Cooper wrote:
>>> On 04/01/2023 5:04 pm, Jan Beulich wrote:
>>>> On 03.01.2023 21:09, Andrew Cooper wrote:
>>>>> + if ( sz > INT32_MAX )
>>>>> + return -E2BIG; /* Compat guests. 2G ought to be plenty. */
>>>> While the comment here and in the public header mention compat guests,
>>>> the check is uniform. What's the deal?
>>> Well its either this, or a (comat ? INT32_MAX : INT64_MAX) check, along
>>> with the ifdefary and predicates required to make that compile.
>>>
>>> But there's not a CPU today which can actually move 2G of data (which is
>>> 4G of L1d bandwidth) without suffering the watchdog (especially as we've
>>> just read it once for strlen(), so that's 6G of bandwidth), nor do I
>>> expect this to change in the forseeable future.
>>>
>>> There's some boundary (probably far lower) beyond which we can't use the
>>> algorithm here.
>>>
>>> There wants to be some limit, and I don't feel it is necessary to make
>>> it variable on the guest type.
>> Sure. My question was merely because of the special mentioning of 32-bit /
>> compat guests. I'm fine with the universal limit, and I'd also be fine
>> with a lower (universal) bound. All I'm after is that the (to me at least)
>> confusing comments be adjusted.
>
> How about 16k then?
Might be okay. If I was to pick a value, I'd use 64k.
Jan
|