[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200425191032.GK21900@8bytes.org>
Date: Sat, 25 Apr 2020 21:10:32 +0200
From: Joerg Roedel <joro@...tes.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: Joerg Roedel <jroedel@...e.de>,
Dave Hansen <dave.hansen@...el.com>,
Tom Lendacky <thomas.lendacky@....com>,
Mike Stunes <mstunes@...are.com>,
Dan Williams <dan.j.williams@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, Juergen Gross <jgross@...e.com>,
Jiri Slaby <jslaby@...e.cz>, Kees Cook <keescook@...omium.org>,
kvm list <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Hellstrom <thellstrom@...are.com>,
Linux Virtualization <virtualization@...ts.linux-foundation.org>,
X86 ML <x86@...nel.org>,
Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [PATCH] Allow RDTSC and RDTSCP from userspace
On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote:
> shift_ist is gross. What's it for? If it's not needed, I'd rather
> not use it, and I eventually want to get rid of it for #DB as well.
The #VC handler needs to be able to nest, there is no way around that
for various reasons, the two most important ones are:
1. The #VC -> NMI -> #VC case. #VCs can happen in the NMI
handler, for example (but not exclusivly) for RDPMC.
2. In case of an error the #VC handler needs to print out error
information by calling one of the printk wrappers. Those will
end up doing IO to some console/serial port/whatever which
will also cause #VC exceptions to emulate the access to the
output devices.
Using shift_ist is perfect for that, the only problem is the race
condition with the NMI handler, as shift_ist does not work well with
exceptions that can also trigger within the NMI handler. But I have
taken care of that for #VC.
Regards,
Joerg
Powered by blists - more mailing lists