lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yqb4N3iwh1X7378o@hirez.programming.kicks-ass.net>
Date:   Mon, 13 Jun 2022 10:41:27 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Lai Jiangshan <jiangshanlai@...il.com>
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 Mon, Jun 13, 2022 at 04:26:01PM +0800, Lai Jiangshan wrote:
> 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.

Correct; on real hardware. But this is virt...

> 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.

All we need the VMM to do is wake the vCPU, and it can do that,
irrespective of the guest's IF.

So the VMM can (and does) know if there's an interrupt pending, and
that's all that's needed to wake from this hypercall. Once the vCPU is
back up and running again, we'll eventually set IF again and the pending
interrupt will get delivered and all's well.

Think of this like MWAIT with ECX[0] set if you will.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ