mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sathyanarayanan Kuppuswamy  <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@intel.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Andi Kleen <ak@linux.intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Juergen Gross <jgross@suse.com>, Deep Shah <sdeep@vmware.com>,
	"VMware, Inc." <pv-drivers@vmware.com>
Subject: Re: [PATCH] x86/paravirt: Fix build PARAVIRT_XXL=y without XEN_PV
Date: Wed, 17 Nov 2021 15:57:09 -0800	[thread overview]
Message-ID: <ea41adcc-aeb4-136a-c723-077454ae2390@linux.intel.com> (raw)
In-Reply-To: <20211117232329.GD174703@worktop.programming.kicks-ass.net>



On 11/17/21 3:23 PM, Peter Zijlstra wrote:
> On Wed, Nov 17, 2021 at 03:04:11PM -0800, Sathyanarayanan Kuppuswamy wrote:
> 
>> We need PV support to handle halt() and safe_halt() cases.
>>
>> HLT instruction is generally used in cases like reboot, idle and
>> exception fixup handlers.
> 
> Which exception calls hlt? Because idle and reboot can easily be done.

It is called in early_fixup_exception().

> 
>> In TDX guest, to support HLT instruction, it has to be emulated using
>> a hypercall (aka TDVMCALL).
>>
>> We have the following three ways to emulate the HLT instruction:
>>
>> 1. Directly substitute TDVMCALLs in places where we require emulation.
>> 2. Use #VE exception handler to emulate it (In TDX guest, executing HLT
>>     will lead to #VE exception).
>> 3. Emulate it using pv_ops
>>
>> Since option#1 is not a scalable approach, it can be ignored. Option #2
>> is also not preferred because, we cannot differentiate between safe
>> halt and normal halt use cases in the exception handler.
> 
> Would not regs->flags & IF provide clue? I know STI normally has a
> shadow, but wouldn't a trap in that shadow still get the flag straight?
> I'm sure there's fun bugs around this, but surely TDX is new and doesn't
> have these bugs.

We have attempted this approach, but it failed some performance tests.

Yes, if we use option # 2, for safe_halt() use case, STI will leave the
interrupts in the desired state. But, between the STI instruction and
the actual emulation of the HLT instruction, interrupts will be left in
the enabled state. So any interrupt that happen in that window will
delay the HLT operation for a long time.

With above consideration, we thought PV ops is error free and a simpler
solution.

> 

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

  reply	other threads:[~2021-11-17 23:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17 18:14 Kirill A. Shutemov
2021-11-17 18:35 ` Peter Zijlstra
2021-11-17 18:42   ` Kirill A. Shutemov
2021-11-17 18:46     ` Sathyanarayanan Kuppuswamy
2021-11-17 18:48       ` Borislav Petkov
2021-11-17 19:11         ` Dave Hansen
2021-11-17 19:13         ` Sathyanarayanan Kuppuswamy
2021-11-17 19:57           ` Dave Hansen
2021-11-17 20:54             ` Sathyanarayanan Kuppuswamy
2021-11-17 21:09               ` Borislav Petkov
2021-11-17 23:04                 ` Sathyanarayanan Kuppuswamy
2021-11-17 23:23                   ` Peter Zijlstra
2021-11-17 23:57                     ` Sathyanarayanan Kuppuswamy [this message]
2021-11-17 23:33                   ` Dave Hansen
2021-11-18  1:26                     ` Sathyanarayanan Kuppuswamy
2021-11-18  9:13                       ` Borislav Petkov
2021-11-17 19:02       ` Peter Zijlstra
2021-11-18  6:23 ` Juergen Gross
2021-11-19 10:21   ` Kirill A. Shutemov
2021-11-19  7:51 ` Lai Jiangshan
2021-11-19 10:20   ` Kirill A. Shutemov
2021-11-19 10:27     ` Juergen Gross
2021-11-20  1:23     ` Lai Jiangshan
2021-11-22 12:55       ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea41adcc-aeb4-136a-c723-077454ae2390@linux.intel.com \
    --to=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=jgross@suse.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pv-drivers@vmware.com \
    --cc=sdeep@vmware.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®