Messages in this thread | | | Subject | Re: [RFC v2 08/32] x86/traps: Add #VE support for TDX guest | From | Dave Hansen <> | Date | Tue, 8 Jun 2021 10:53:43 -0700 |
| |
On 6/8/21 10:48 AM, Sean Christopherson wrote: > On Tue, Jun 08, 2021, Dave Hansen wrote: >> On 4/26/21 11:01 AM, Kuppuswamy Sathyanarayanan wrote: >>> +#ifdef CONFIG_INTEL_TDX_GUEST >>> +DEFINE_IDTENTRY(exc_virtualization_exception) >>> +{ >>> + struct ve_info ve; >>> + int ret; >>> + >>> + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU"); >>> + >>> + /* >>> + * Consume #VE info before re-enabling interrupts. It will be >>> + * re-enabled after executing the TDGETVEINFO TDCALL. >>> + */ >>> + ret = tdg_get_ve_info(&ve); >> Is it safe to have *anything* before the tdg_get_ve_info()? For >> instance, say that RCU_LOCKDEP_WARN() triggers. Will anything in there >> do MMIO? > I doubt it's safe, anything that's doing printing has the potential to trigger > #VE. Even if we can prove it's safe for all possible paths, I can't think of a > reason to allow anything that's not absolutely necessary before retrieving the > #VE info.
What about tracing? Can I plop a kprobe in here or turn on ftrace?
| |