[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 4/8] x86: Initial support for WRMSRNS
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Mon, 16 Jan 2023 12:21:31 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=nEPNbfV9fzYc4e65rLHeg4BPShBWBRDdYMMKbn3od6Q=; b=KSgvm27VD2utYYCEbIJOAZD0V5ggB8GXtFohXDaD/fHuTWMFQsoH6zQ5fZZhYEz+0AZ07hm2hSYvJo2SbN3aKWhCzshdpRJaUsy2+/ViuDVT75l5abFRJSeOuvFbzgQ5yDYXdbnib/AV0w12e61rY1K9OWG7QlfKcLrq7sNdLpwU6trH9hxnRvd5bCmVBLYV9WBUlqet2UvWAlXYOw0PMI3z61ZZMAFRUietkr7Vwenb4vd4xZ3JanPPhMWN2bBb82I4UAm+43kelskBYvSElLLhyXbOLriJB+VIqLOQEutKjAswgHLlv9gp64UL7swi1istJVB+ZBv2ZjfzQEJCHg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vcs8wcCY628QBMJzdk3hFoddwGfM1WcxcrZUyhMvAqeE4Qwj7aV6hT4Yk2iWAxRxtc3BNz1suJeJgjwAk5Fn+5zBu5nvvvY0amS3zlPaFDi6h+lkPMCbGl4KCpAVWJDGpmPckHhKJrPCqFqdEYPsRWobbG9CNNL4zw12ZH0wzDZSqQdUAcO77s8yREcRXi0LZI0gBEaKVEtt/4O2fiW6tTYjn/uBn9AiWyD+6Pjf0ALXJ+LpO5v8J5GO1b+PjX5ScK5wGolmHpetYjc2QjwdfAErsNy8hmRRw51hqaHm/zMdP+ygFRU/MBdByYQJiCkg4cAb9XhXW2Nydb0r8cSpLg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 16 Jan 2023 12:21:46 +0000
- Ironport-data: A9a23:+9uPiKjKU+XsfJXwzJFeiWjYX161QhEKZh0ujC45NGQN5FlHY01je htvUTjUOf3YYTTyKt0gYYvi8B4FvpCEyoVkHgpuqCw8E3kb9cadCdqndUqhZCn6wu8v7q5Ex 55HNoSfdpBcolv0/ErF3m3J9CEkvU2wbuOgTrWCYmUpH1QMpB4J0XpLg/Q+jpNjne+3CgaMv cKai8DEMRqu1iUc3lg8sspvkzsy+qWt0N8klgZmP6sT5QaAzyB94K83fsldEVOpGuG4IcbiL wrz5OnR1n/U+R4rFuSknt7TGqHdauePVeQmoiM+t5mK2nCulARrukoIHKN0hXNsoyeIh7hMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL1yDwyjaMKVBktubD12i+ tQkFgsxYDml29uy55GhUPgv3NYSd8jSadZ3VnFIlVk1DN4AaLWaGuDgw48d2z09wMdTAfzZe swVLyJ1awjNaAFOPVFRD48imOCvhT/0dDgwRFC9/PJrpTSMilEhluGzYLI5efTTLSlRtm+eq njL4CLSBRYCOcbE4TGE7mitlqnEmiaTtIc6Refnp6U63gb7Kmo7JBIbX0meuveF13HiBIoDG XAV4i4PlP1nnKCsZpynN/Gim1aGtBMBX9tbE8Uh9RqAjKHT5m6xGWwsXjNHLts8u6ceVTEsk 1OEgd7tLThuq6GOD2KQ8K+OqjG/MjRTKnUNDRLoViMA6tjn5Ys13hTGS486FLbv14OlXzbt3 zqNsS4ywa0JitIG3Lm6+laBhC+wop/OTUg+4QC/sn+Z0z6VrbWNP+SAgWU3J94aRGpFZjFtZ EQ5pvU=
- Ironport-hdrordr: A9a23:csPa16FT++L2WV8QpLqEGMeALOsnbusQ8zAXPiBKJCC9E/bo8/ xG+c5w6faaslkssR0b9+xoW5PwJE80l6QFgrX5VI3KNGXbUQ2TTb2KhbGI/9SKIVydygcy78 ddmtNFebrN5VgRt7eH3OG7eexQv+VuJsqT9JnjJ3QGd3AaV0l5hT0JbDpyiidNNXN77ZxSLu vk2uN34wCOVF4wdcqBCnwMT4H41qD2fMKPW29/O/Y/gjP+9g+V1A==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZJRefYU5gP8dknEybN3m0hZOPA66awNaAgAAQ7QCAABRFgIAGGeqA
- Thread-topic: [PATCH v2 4/8] x86: Initial support for WRMSRNS
On 12/01/2023 3:11 pm, Jan Beulich wrote:
> On 12.01.2023 14:58, Andrew Cooper wrote:
>> On 12/01/2023 12:58 pm, Jan Beulich wrote:
>>> Do you have any indications towards a CS prefix being the least risky
>>> one to use here (or in general)?
>> Yes.
>>
>> Remember it's the prefix recommended for, and used by,
>> -mbranches-within-32B-boundaries to work around the Skylake jmp errata.
>>
>> And based on this justification, its also the prefix we use for padding
>> on various jmp/call's for retpoline inlining purposes.
> While I'm okay with the reply, I'd like to point out that in those cases
> address or operand size prefix simply could not have been used, for the
> insns in question having explicit operands which would be affected. Which
> is unlike the case here.
A CS prefix *is* the option which the architects deemed was the safest,
and subsequent workarounds are using CS because it had previously passed
muster.
Various toolchain codegen options will result in `cs wrmsr` being emitted.
There are a subset of instructions for which other prefixes work for
padding purposes, but by not following the recommendation and choosing
CS, you're betting against the people who make new meanings for
instruction encodings.
~Andrew
|
