[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0f346274-e45e-1701-2b74-4438e4db4276@intel.com>
Date: Tue, 24 Aug 2021 10:36:34 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Borislav Petkov <bp@...en8.de>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Peter H Anvin <hpa@...or.com>,
Tony Luck <tony.luck@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
Andi Kleen <ak@...ux.intel.com>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 07/12] x86/traps: Add #VE support for TDX guest
On 8/24/21 10:32 AM, Kuppuswamy, Sathyanarayanan wrote:
>>> + if (fixup_exception(regs, X86_TRAP_VE, error_code, 0))
>>
>> There are exception table entries which can trigger a #VE?
>
> It is required to handle #VE exceptions raised by unhandled MSR
> read/writes.
Is that really the *complete* set of reasons that a #VE can be triggered
from the kernel?
Just off the top of my head, I could imagine the kernel doing a
copy_{to,from}_user() which touched user-mapped MMIO causing a #VE.
Powered by blists - more mailing lists