On Mon, Jan 10, 2022 at 02:26:18PM +0100, Juergen Gross wrote:
> Thomas, another ping. Didn't you want to take this patch more than a
> month ago? Cc-ing the other x86 maintainers, too.
I'll have a look after the merge window is over.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org
On 23.11.21 10:52, Juergen Gross via Virtualization wrote:
On 23.11.21 10:29, Jan Beulich wrote:
On 05.10.2021 09:43, Juergen Gross wrote:
On 30.09.21 14:40, Jan Beulich via Virtualization wrote:
While using a plain (constant) address works, its use needlessly
invokes
a SIB addressing mode, m
On 23.11.21 10:29, Jan Beulich wrote:
On 05.10.2021 09:43, Juergen Gross wrote:
On 30.09.21 14:40, Jan Beulich via Virtualization wrote:
While using a plain (constant) address works, its use needlessly invokes
a SIB addressing mode, making every call site one byte larger than
necessary. Instead
On 05.10.2021 09:43, Juergen Gross wrote:
> On 30.09.21 14:40, Jan Beulich via Virtualization wrote:
>> While using a plain (constant) address works, its use needlessly invokes
>> a SIB addressing mode, making every call site one byte larger than
>> necessary. Instead of using an "i" constraint wit
On 30.09.21 14:40, Jan Beulich via Virtualization wrote:
While using a plain (constant) address works, its use needlessly invokes
a SIB addressing mode, making every call site one byte larger than
necessary. Instead of using an "i" constraint with address-of operator
and a 'c' operand modifier, s
While using a plain (constant) address works, its use needlessly invokes
a SIB addressing mode, making every call site one byte larger than
necessary. Instead of using an "i" constraint with address-of operator
and a 'c' operand modifier, simply use an ordinary "m" constraint, which
the 64-bit comp
