Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Andrew Cooper <Andrew.Cooper3@citrix.com>,
        LKML <linux-kernel@vger.kernel.org>
Cc:     "x86@kernel.org" <x86@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Josh Poimboeuf <jpoimboe@kernel.org>,
        Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
        Johannes Wikner <kwikner@ethz.ch>,
        Alyssa Milburn <alyssa.milburn@linux.intel.com>,
        Jann Horn <jannh@google.com>, "H.J. Lu" <hjl.tools@gmail.com>,
        Joao Moreira <joao.moreira@intel.com>,
        Joseph Nuzman <joseph.nuzman@intel.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Juergen Gross <jgross@suse.com>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        "kys@microsoft.com" <kys@microsoft.com>,
        "haiyangz@microsoft.com" <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Wei Liu <wei.liu@kernel.org>,
        "decui@microsoft.com" <decui@microsoft.com>,
        Michael Kelley <mikelley@microsoft.com>
Subject: Re: Virt Call depth tracking mitigation
In-Reply-To: <261e141a-7e7f-ce26-60fe-df1957e393df@citrix.com>
References: <20220716230344.239749011@linutronix.de>
 <4ca4a4ab-6ea0-d94a-59cc-1ab99ff869d5@citrix.com> <87a695ur5v.ffs@tglx>
 <261e141a-7e7f-ce26-60fe-df1957e393df@citrix.com>
Date:   Tue, 19 Jul 2022 23:17:12 +0200
Message-ID: <877d48vm3r.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Tue, Jul 19 2022 at 16:23, Andrew Cooper wrote:
> On 19/07/2022 15:13, Thomas Gleixner wrote:
>> Well, that makes the guest side "safe", but isn't a deep hypercall > 16
>> already underflowing in the hypervisor code before it returns to the
>> guest?
>
> Yeah, but that's the hypervisor's problem to deal with, in whatever
> manner it sees fit.
>
> And if the hypervisor is using IBeeRS then the first ret in guest
> context will underflow.

I have a look tomorrow.

>>> That said, after a return from the hypervisor, Linux has no idea what
>>> state the RSB is in, so the only safe course of action is to re-stuff.
>> Indeed.
>>
>> Another proof for my claim that virt creates more problems than it
>> solves.
>
> So how did you like debugging the gsbase crash on native hardware. :)

First of all I said it's creating more problems than it solves, which
means it solves some problems.

But more important, I'm not a wimp.

Thanks,

        tglx