[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABV8kRwyik_5nB3JSxSJxKqpepENNeK2NCJUf5QqE+m+H12P0w@mail.gmail.com>
Date: Tue, 7 Apr 2020 14:06:11 -0400
From: Keno Fischer <keno@...iacomputing.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Kyle Huey <khuey@...ehuey.com>,
"Robert O'Callahan" <robert@...llahan.org>
Subject: Re: [RFC PATCH v2] x86/arch_prctl: Add ARCH_SET_XCR0 to set XCR0 per-thread
Hi Andi,
> The rationale from that post should have been in this description.
Yes, sorry.
> You can already do what you want using the clearcpuid= boot flags using the
> infrastructure in [1], which is in newer kernels.
Yes, that it useful, but doesn't solve the problem where
we're trying to jointly replay traces with differing XCR0 values
(as mentioned before, this is useful for recordings from multiple
nodes of a distributed system). Even for the single trace
case, having to reboot the system or boot a virtual machine
manually for every bug report I get would be operationally
annoying. A potential solution to the operational problem would
be using the raw kvm API to get a very lightweight VM
with modified XCR0 but that has performance
and complexity concerns.
Powered by blists - more mailing lists