[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJhGHyCnu_BsKf5STMMJKMWm0NVZ8qXT8Qh=BhhCjSSgwchL3Q@mail.gmail.com>
Date: Mon, 13 Jun 2022 16:26:01 +0800
From: Lai Jiangshan <jiangshanlai@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Richard Henderson <rth@...ddle.net>, ink@...assic.park.msu.ru,
mattst88@...il.com, vgupta@...nel.org, linux@...linux.org.uk,
ulli.kroll@...glemail.com, linus.walleij@...aro.org,
shawnguo@...nel.org, Sascha Hauer <s.hauer@...gutronix.de>,
kernel@...gutronix.de, festevam@...il.com, linux-imx@....com,
tony@...mide.com, khilman@...nel.org, catalin.marinas@....com,
Will Deacon <will@...nel.org>, guoren@...nel.org,
bcain@...cinc.com, Huacai Chen <chenhuacai@...nel.org>,
kernel@...0n.name, geert@...ux-m68k.org, sammy@...my.net,
monstr@...str.eu, tsbogend@...ha.franken.de, dinguyen@...nel.org,
jonas@...thpole.se, stefan.kristiansson@...nalahti.fi,
shorne@...il.com, James.Bottomley@...senpartnership.com,
deller@....de, Michael Ellerman <mpe@...erman.id.au>,
benh@...nel.crashing.org, paulus@...ba.org,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, hca@...ux.ibm.com,
gor@...ux.ibm.com, agordeev@...ux.ibm.com,
borntraeger@...ux.ibm.com, svens@...ux.ibm.com,
ysato@...rs.sourceforge.jp, dalias@...c.org, davem@...emloft.net,
Richard Weinberger <richard@....at>,
anton.ivanov@...bridgegreys.com,
Johannes Berg <johannes@...solutions.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
acme <acme@...nel.org>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
jolsa@...nel.org, Namhyung Kim <namhyung@...nel.org>,
Juergen Gross <jgross@...e.com>, srivatsa@...il.mit.edu,
amakhalov@...are.com, VMware Inc <pv-drivers@...are.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>, chris@...kel.net,
jcmvbkbc@...il.com, rafael@...nel.org, lenb@...nel.org,
pavel@....cz, gregkh@...uxfoundation.org, mturquette@...libre.com,
sboyd@...nel.org, daniel.lezcano@...aro.org, lpieralisi@...nel.org,
sudeep.holla@....com, agross@...nel.org,
bjorn.andersson@...aro.org, Anup Patel <anup@...infault.org>,
thierry.reding@...il.com, jonathanh@...dia.com,
jacob.jun.pan@...ux.intel.com, Arnd Bergmann <arnd@...db.de>,
yury.norov@...il.com,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
linux@...musvillemoes.dk, rostedt@...dmis.org, pmladek@...e.com,
senozhatsky@...omium.org, john.ogness@...utronix.de,
paulmck@...nel.org, frederic@...nel.org, quic_neeraju@...cinc.com,
josh@...htriplett.org, mathieu.desnoyers@...icios.com,
joel@...lfernandes.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
bsegall@...gle.com, mgorman@...e.de, bristot@...hat.com,
vschneid@...hat.com, jpoimboe@...nel.org,
linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-snps-arc@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
linux-csky@...r.kernel.org, linux-hexagon@...r.kernel.org,
linux-ia64@...r.kernel.org, linux-m68k@...ts.linux-m68k.org,
linux-mips@...r.kernel.org, openrisc@...ts.librecores.org,
linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
linux-sh@...r.kernel.org, sparclinux@...r.kernel.org,
linux-um@...ts.infradead.org, linux-perf-users@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
xen-devel@...ts.xenproject.org, linux-xtensa@...ux-xtensa.org,
linux-acpi@...r.kernel.org, linux-pm@...r.kernel.org,
linux-clk@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-tegra@...r.kernel.org, linux-arch@...r.kernel.org,
rcu@...r.kernel.org, Isaku Yamahata <isaku.yamahata@...il.com>,
kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH 21/36] x86/tdx: Remove TDX_HCALL_ISSUE_STI
On Wed, Jun 8, 2022 at 10:48 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> Now that arch_cpu_idle() is expected to return with IRQs disabled,
> avoid the useless STI/CLI dance.
>
> Per the specs this is supposed to work, but nobody has yet relied up
> this behaviour so broken implementations are possible.
I'm totally newbie here.
The point of safe_halt() is that STI must be used and be used
directly before HLT to enable IRQ during the halting and stop
the halting if there is any IRQ.
In TDX case, STI must be used directly before the hypercall.
Otherwise, no IRQ can come and the vcpu would be stalled forever.
Although the hypercall has an "irq_disabled" argument.
But the hypervisor doesn't (and can't) touch the IRQ flags no matter
what the "irq_disabled" argument is. The IRQ is not enabled during
the halting if the IRQ is disabled before the hypercall even if
irq_disabled=false.
The "irq_disabled" argument is used for workaround purposes:
https://lore.kernel.org/kvm/c020ee0b90c424a7010e979c9b32a28e9c488a51.1651774251.git.isaku.yamahata@intel.com/
Hope my immature/incorrect reply elicits a real response from
others.
Thanks
Lai
Powered by blists - more mailing lists