[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201119115059.dns4hvull3l3dwx3@shindev.dhcp.fujisawa.hgst.com>
Date: Thu, 19 Nov 2020 11:51:00 +0000
From: Shinichiro Kawasaki <shinichiro.kawasaki@....com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Jürgen Groß <jgross@...e.com>,
Andy Lutomirski <luto@...nel.org>,
Andrew Cooper <andrew.cooper3@...rix.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Nicholas Piggin <npiggin@...il.com>,
Damien Le Moal <Damien.LeMoal@....com>,
X86 ML <x86@...nel.org>
Subject: Re: WARNING: can't access registers at asm_common_interrupt
On Nov 18, 2020 / 09:22, Peter Zijlstra wrote:
> On Wed, Nov 18, 2020 at 07:47:36AM +0100, Jürgen Groß wrote:
> > On 16.11.20 14:04, Peter Zijlstra wrote:
> > > On Mon, Nov 16, 2020 at 12:56:32PM +0100, Jürgen Groß wrote:
> > > > > > > > > > static inline notrace unsigned long arch_local_save_flags(void)
> > > > > > > > > > {
> > > > > > > > > > PVOP_CALL_ARGS;
> > > > > > > > > > PVOP_TEST_NULL(irq.save_fl);
> > > > > > > > > > asm_inline volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL),
> > > > > > > > > > "PUSHF; POP _ASM_AX",
> > > > > > > > > > X86_FEATURE_NATIVE)
> > > >
> > > > I am wondering whether we really want a new feature (basically "not
> > > > XENPV). We could use ~X86_FEATURE_XENPV and teach apply_alternatives()
> > > > to understand negated features (yes, this limits the number of features
> > > > to 32767, but I don't think this is a real problem for quite some time).
> > > >
> > > > Thoughts?
> > >
> > > I went with the simple thing for now... If we ever want/need another
> > > negative alternative I suppose we can do as you suggest...
> > >
> > > I was still poking at objtool to actually dtrt though..
> >
> > I'd like to include this part in my series (with a different solution
> > for the restore_fl part, as suggested by Andy before).
> >
> > Peter, are you fine with me taking your patch and adding your SoB?
>
> Sure, note that I only compile tested it, as it was my test-bed for
> playing with objtool (which I still haven't managed to get back to and
> finish :/).
>
> So if it actually _works_ feel free to take it, otherwise you can have
> whatever bits and pieces remain after you've butchered it to do as you
> want.
All, thank you for the actions.
I tried Peter's patch in my test system and result looks good. The warning is
still observed with 5.10-rc4. With the patch on top of 5.10-rc4, the warning
disappeared.
Of note is that when I built kernel with the patch, objtool reported many
warnings, as follows:
arch/x86/events/intel/core.o: warning: objtool: .altinstr_replacement+0x0: alternative modifies stack
arch/x86/events/core.o: warning: objtool: .altinstr_replacement+0x0: alternative modifies stack
--
Best Regards,
Shin'ichiro Kawasaki
Powered by blists - more mailing lists