[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220520101322.flxf52mg6vkkbc7r@box.shutemov.name>
Date: Fri, 20 May 2022 13:13:22 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Peter Zijlstra <peterz@...radead.org>,
Isaku Yamahata <isaku.yamahata@...el.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
frederic@...nel.org, paulmck@...nel.org, rjw@...ysocki.net,
x86@...nel.org, linux-kernel@...r.kernel.org, jpoimboe@...nel.org
Subject: Re: [RFC][PATCH 9/9] arch/idle: Change arch_cpu_idle() IRQ behaviour
On Fri, May 20, 2022 at 09:06:14AM +0200, Peter Zijlstra wrote:
> On Fri, May 20, 2022 at 05:20:52AM +0300, Kirill A. Shutemov wrote:
> > On Fri, May 20, 2022 at 12:03:49AM +0200, Peter Zijlstra wrote:
> > >
> > > On Thu, May 19, 2022 at 11:27:59PM +0200, Peter Zijlstra wrote:
> > > > --- a/arch/x86/coco/tdx/tdx.c
> > > > +++ b/arch/x86/coco/tdx/tdx.c
> > > > @@ -178,6 +178,9 @@ void __cpuidle tdx_safe_halt(void)
> > > > */
> > > > if (__halt(irq_disabled, do_sti))
> > > > WARN_ONCE(1, "HLT instruction emulation failed\n");
> > > > +
> > > > + /* XXX I can't make sense of what @do_sti actually does */
> > > > + raw_local_irq_disable();
> > > > }
> > > >
> > >
> > > Kirill, Dave says I should prod you :-)
> >
> > It calls STI just before doing TDCALL that requests HLT.
> > See comment above $TDX_HCALL_ISSUE_STI usage in __tdx_hypercall()[1].
>
> Yes, it says that, but it's useless information since it doesn't
> actually tell me the behaviour.
>
> What I'm interested in is the behavour of the hypercall when:
> .irq_disabled=false, .do_sti=false
>
> From what I can tell, irq_disabled=false should have the hypercall wake
> on interrupt, do_sti=false should have it not enable interrupts.
>
> But what does it actually do ? Because HLT without STI is a dead
> machine, but this hypercall looks more like mwait with the irq_disabled
> argument...
+Isaku.
So you want to call call the HLT hypercall with .irq_disabled=false and
.do_sti=false, but actual RFLAGS.IF in the guest is 0 and avoid CLI on
wake up expecting it to be cleared already, right?
My reading of the spec is "don't do that". But actual behaviour is up to
VMM and TDX module implementation. VMM doens't have access to the guest
register file, so it *may* work, I donno.
Sorry for not being helpful :/
Isaku, maybe you can clarify this?
--
Kirill A. Shutemov
Powered by blists - more mailing lists