[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <16e50239-39b2-4fb4-5110-18f13ba197fe@amd.com>
Date: Thu, 12 Jan 2023 08:43:23 +0100
From: "Gupta, Pankaj" <pankaj.gupta@....com>
To: Tianyu Lan <ltykernel@...il.com>, luto@...nel.org,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
seanjc@...gle.com, pbonzini@...hat.com, jgross@...e.com,
tiala@...rosoft.com, kirill@...temov.name,
jiangshan.ljs@...group.com, peterz@...radead.org,
ashish.kalra@....com, srutherford@...gle.com,
akpm@...ux-foundation.org, anshuman.khandual@....com,
pawan.kumar.gupta@...ux.intel.com, adrian.hunter@...el.com,
daniel.sneddon@...ux.intel.com, alexander.shishkin@...ux.intel.com,
sandipan.das@....com, ray.huang@....com, brijesh.singh@....com,
michael.roth@....com, thomas.lendacky@....com,
venu.busireddy@...cle.com, sterritt@...gle.com,
tony.luck@...el.com, samitolvanen@...gle.com, fenghua.yu@...el.com
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-hyperv@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [RFC PATCH V2 15/18] x86/sev: Add a #HV exception handler
>>> + * To make this work the #HV entry code tries its best to pretend it
>>> doesn't use
>>> + * an IST stack by switching to the task stack if coming from
>>> user-space (which
>>> + * includes early SYSCALL entry path) or back to the stack in the
>>> IRET frame if
>>> + * entered from kernel-mode.
>>> + *
>>> + * If entered from kernel-mode the return stack is validated first,
>>> and if it is
>>> + * not safe to use (e.g. because it points to the entry stack) the
>>> #HV handler
>>> + * will switch to a fall-back stack (HV2) and call a special handler
>>> function.
>>> + *
>>> + * The macro is only used for one vector, but it is planned to be
>>> extended in
>>> + * the future for the #HV exception.
>>
>> Noticed same comment line in the #VC exception handling section (macro
>> idtentry_vc). Just wondering we need to remove this line as the patch
>> being proposed for the #HV exception handling? unless this is planned
>> to be extended in some other way.
>
> Nice catch! Will remove this in the next version.
Thanks. Just a note: the referred 'idtentry_vc' macro has some
instructions added/moved (e.g CLD is moved at start of IDT entry, ENDBR
added) plus some additional comments added later. Don't know what all of
them are required to be replicated in 'idtentry_hv', just want to share
my observation.
Thanks,
Pankaj
Powered by blists - more mailing lists