linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@intel.com>
To: "corbet@lwn.net" <corbet@lwn.net>, "bp@alien8.de" <bp@alien8.de>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"shuah@kernel.org" <shuah@kernel.org>,
	"sathyanarayanan.kuppuswamy@linux.intel.com" 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"x86@kernel.org" <x86@kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>
Cc: "Yu, Guorui" <guorui.yu@linux.alibaba.com>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"wander@redhat.com" <wander@redhat.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"chongc@google.com" <chongc@google.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"qinkun@apache.org" <qinkun@apache.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	"dionnaglaze@google.com" <dionnaglaze@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Du, Fan" <fan.du@intel.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] x86/tdx: Add TDX Guest event notify interrupt support
Date: Wed, 26 Apr 2023 01:59:12 +0000	[thread overview]
Message-ID: <40b6ca5df5988305fea734e559fe5c8b3a22df78.camel@intel.com> (raw)
In-Reply-To: <0da37de8-6036-f475-d80d-92c77fb7cbaa@linux.intel.com>

On Tue, 2023-04-25 at 16:47 -0700, Sathyanarayanan Kuppuswamy wrote:
> Hi Kai,
> 
> On 4/14/23 6:34 AM, Huang, Kai wrote:
> > On Wed, 2023-04-12 at 20:41 -0700, Kuppuswamy Sathyanarayanan wrote:
> > > Host-guest event notification via configured interrupt vector is useful
> > > in cases where a guest makes an asynchronous request and needs a
> > > callback from the host to indicate the completion or to let the host
> > > notify the guest about events like device removal. One usage example is,
> > > callback requirement of GetQuote asynchronous hypercall.
> > > 
> > > In TDX guest, SetupEventNotifyInterrupt hypercall can be used by the
> > > guest to specify which interrupt vector to use as an event-notify
> > > vector from the VMM. Details about the SetupEventNotifyInterrupt
> > > hypercall can be found in TDX Guest-Host Communication Interface
> > > (GHCI) Specification, section "VP.VMCALL<SetupEventNotifyInterrupt>".
> > > 
> > > As per design, VMM will post the event completion IRQ using the same
> > > CPU on which SetupEventNotifyInterrupt hypercall request is received.
> > > So allocate an IRQ vector from "x86_vector_domain", and set the CPU
> > > affinity of the IRQ vector to the CPU on which
> > > SetupEventNotifyInterrupt hypercall is made.
> > > 
> > > Add tdx_register_event_irq_cb()/tdx_unregister_event_irq_cb()
> > > interfaces to allow drivers register/unregister event noficiation
> > 			      ^
> > 			      to register/unregister
> > > handlers.
> > > 
> > > 
> > 
> > [...]
> > 
> 
> With suggested changes, the final version looks like below.
> 
> +/**
> + * tdx_event_irq_init() - Register IRQ for event notification from the VMM to
> + *                       the TDX Guest.
> + *
> + * Use SetupEventNotifyInterrupt TDVMCALL to register the event notification
> + * IRQ with the VMM, which is used by the VMM to notify the TDX guest when
> + * needed, for instance, when VMM finishes the GetQuote request from the TDX
> + * guest. The VMM always notifies the TDX guest via the same CPU on which the
> + * SetupEventNotifyInterrupt TDVMCALL is called. For simplicity, just allocate
> + * an IRQ (and a vector) directly from x86_vector_domain for such notification
> + * and pin the IRQ to the same CPU on which TDVMCALL is called.

I think "for simplicity" applies to allocate IRQ/vector "from BSP using
early_initcall()" (so TDVMCALL is easily guaranteed to be called on the same cpu
where vector is allocated), but doesn't apply to allocate IRQ/vector from
x86_vector_domain and "pin the IRQ to the same CPU on which TDVMCALAL is
called".  The latter is something you must do (otherwise you need to allocate
the same vector on all cpus), but not something that you do "for simplicity".

> + *
> + * Since tdx_event_irq_init() is triggered via early_initcall(), it will be
> + * called before secondary CPUs bring up, so no special logic is required to
> + * ensure that the same CPU is used for SetupEventNotifyInterrupt TDVMCALL and
> + * IRQ allocation.

IMHO the second paragraph is obvious and no need to mention.

As explained above, I guess you just need to at somewhere simply mention
something like: "for simplicity use early_initcall() to allocate and pin the
IRQ/vector on BSP and also call the TDVMCALL on BSP".  Or probably "also call
the TDVMCALL on BSP" can also be omitted as it's kinda already explained in the
nature of the TDVMCALL.

> + */
> +static int __init tdx_event_irq_init(void)
> +{
> +       struct irq_affinity_desc desc;
> +       struct irq_alloc_info info;
> +       struct irq_cfg *cfg;
> +       int irq;
> +
> +       if (!cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
> +               return 0;
> +
> +       init_irq_alloc_info(&info, NULL);
> +
> +       cpumask_set_cpu(smp_processor_id(), &desc.mask);
> +
> +       irq = __irq_domain_alloc_irqs(x86_vector_domain, -1, 1, cpu_to_node(0),

cpu_to_node(smp_processor_id())?

> +                                     &info, false, &desc);
> +       if (irq <= 0) {
> +               pr_err("Event notification IRQ allocation failed %d\n", irq);
> +               return -EIO;
> +       }
> +
> +       irq_set_handler(irq, handle_edge_irq);
> +
> +       /*
> +        * The IRQ cannot be migrated because VMM always notifies the TDX
> +        * guest on the same CPU on which the SetupEventNotifyInterrupt
> +        * TDVMCALL is called. Set the IRQ with IRQF_NOBALANCING to prevent
> +        * its affinity from being changed.
> +        */
> +       if (request_irq(irq, tdx_event_irq_handler, IRQF_NOBALANCING,
> +                       "tdx_event_irq", NULL)) {
> +               pr_err("Event notification IRQ request failed\n");
> +               goto err_free_domain_irqs;
> +       }
> +
> +       cfg = irq_cfg(irq);
> +
> +       if (_tdx_hypercall(TDVMCALL_SETUP_NOTIFY_INTR, cfg->vector, 0, 0, 0)) {
> +               pr_err("Event notification hypercall failed\n");
> +               goto err_free_irqs;
> +       }
> +
> +       tdx_event_irq = irq;
> +
> +       return 0;
> +
> +err_free_irqs:
> +       free_irq(irq, NULL);
> +err_free_domain_irqs:
> +       irq_domain_free_irqs(irq, 1);
> +
> +       return -EIO;
> +}
> +early_initcall(tdx_event_irq_init)
> 
> 
> 
> 
> -- 
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer



  reply	other threads:[~2023-04-26  1:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13  3:41 [PATCH v2 0/3] TDX Guest Quote generation support Kuppuswamy Sathyanarayanan
2023-04-13  3:41 ` [PATCH v2 1/3] x86/tdx: Add TDX Guest event notify interrupt support Kuppuswamy Sathyanarayanan
2023-04-14 13:34   ` Huang, Kai
2023-04-25 23:47     ` Sathyanarayanan Kuppuswamy
2023-04-26  1:59       ` Huang, Kai [this message]
2023-04-26  6:07         ` Sathyanarayanan Kuppuswamy
2023-04-28 13:50           ` Huang, Kai
2023-04-13  3:41 ` [PATCH v2 2/3] virt: tdx-guest: Add Quote generation support Kuppuswamy Sathyanarayanan
2023-04-26 15:40   ` Dionna Amalie Glaze
2023-04-27 18:27     ` Sathyanarayanan Kuppuswamy
2023-04-28  1:29       ` Dionna Amalie Glaze
2023-04-28 13:49   ` Huang, Kai
2023-05-01  6:03     ` Sathyanarayanan Kuppuswamy
2023-05-01 12:48       ` Huang, Kai
2023-05-04  7:12         ` Sathyanarayanan Kuppuswamy
2023-05-04 12:00           ` Huang, Kai
2023-05-02 22:27   ` Chong Cai
2023-04-13  3:41 ` [PATCH v2 3/3] selftests/tdx: Test GetQuote TDX attestation feature Kuppuswamy Sathyanarayanan
2023-04-26 15:47   ` Dionna Amalie Glaze
2023-04-27 19:10     ` Sathyanarayanan Kuppuswamy
2023-04-27 19:56       ` Dave Hansen
2023-04-27 19:53     ` Dave Hansen
2023-05-10  0:10 ` [PATCH v2 0/3] TDX Guest Quote generation support Erdem Aktas
2023-05-10  0:14   ` Sathyanarayanan Kuppuswamy

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=40b6ca5df5988305fea734e559fe5c8b3a22df78.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=bp@alien8.de \
    --cc=chongc@google.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dionnaglaze@google.com \
    --cc=erdemaktas@google.com \
    --cc=fan.du@intel.com \
    --cc=guorui.yu@linux.alibaba.com \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=qinkun@apache.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=wander@redhat.com \
    --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;
as well as URLs for NNTP newsgroup(s).