[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86emul: recognize CLDEMOTE
- To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Tue, 25 Jan 2022 16:18:54 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=/XhgzduY13boTbMtLpSWIYSwbrlIyQh6KYBTB+9CXds=; b=EQaCUUz+IFqOVo8LsmqP2tiaJXk4R6BTkqa0D7qLfKcfsVTlZUtYBOplzKRaVuE5xyPxH/G6iTo+YS3ZqKA7YHn1PRKMKZ50CGWTojcRu3L9/lSyWN3oQRoKpk6X/hBnAWNv6envr1jyvvtz/izReDlL7R7ewbS2rczBKCR56E8KZzMo1qmPDjQIpxaHJIDgq6QWsNb5glN/2Vs/jfvJZJuhVYDQOo1jj0G+HeC+0zY2aMrDDdx5xEHJp+67mWIyIblgkaJXB/cFs4Eu35WVxtH40yOpl7dvTXAltIhUln8/UKK3npnbJpQvAPtVFMXrhRmehZUEb+xN19Bhj6qqZw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ahmc6QyEEcHR4sNC8Z2mILJ3fTgLDjxUyEbcudL1tSy1+2DneXli8XQJLc0ZOIjARbbegkmlQsznAcbrDWB6Qh/UWs6VZrgXnKXvjwkYJFwgCFxcbZoZp9kV49Mr527Y8Fi8WC/Wy8U+iqod2C4h6tAAF7FhaCVWm6G5F1/QBc2fpsEDBYoh6in3z7j8LUf4ffE4ZuGrI6SdurS/QuDkfdIgnyJW4GnkBipNGgOoOoPXjzAxZ4EhP+/oipzL7ogX9TetgRNGU8fIywKTtqjJkm6JQXCaKLTbwN9MJirJqV3tgRcFGTE1SQGJ98pWL2jMNBFCoe/8+0ByIQqc6tNqKA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 25 Jan 2022 15:19:06 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 25.01.2022 16:09, Andrew Cooper wrote:
> On 25/01/2022 14:22, Jan Beulich wrote:
>> We claim to support the insn, but so far the emulator has been handling
>> it as a NOP.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> Treating CLDEMOTE as a NOP is going to be more efficient than actually
> setting up the mapping to execute a real CLDEMOTE instruction on the
> line in question. CLDEMOTE is very specifically an optimisation for
> software producer/consumer pairs.
Some similar argument could likely be made for treating CLFLUSH etc as
just a NOP then?
> If we want to take this patch, it should Fix[es]: ad3abc47dd23c which
> made the claim that CLDEMOTE needed no further additions.
Added.
> The only issue on whether we can treat it as a NOP completely is whether
> we believe the exception list. I'm not sure I believe the absence of
> AGU faults,
I also was puzzled by this, but I have no way to verify one way or the
other. Hence the implementation follows what the SDM says.
> but the instruction is taken from hint-nop space so
> guaranteed to behave similarly to clflush/clwb.
I'm confused: CLFLUSH / CLWB specifically do not live in NOP space:
The former are under 0FAE, while NOP space is 0F18 ... 0F1F (with
CLDEMOTE being 0F1C).
Jan
|
