All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>, linux-kernel@vger.kernel.org
Cc: bp@alien8.de, mingo@redhat.com, dave.hansen@linux.intel.com,
	Thomas.Lendacky@amd.com, nikunj@amd.com, Santosh.Shukla@amd.com,
	Vasant.Hegde@amd.com, Suravee.Suthikulpanit@amd.com,
	David.Kaplan@amd.com, x86@kernel.org, hpa@zytor.com,
	peterz@infradead.org, seanjc@google.com, pbonzini@redhat.com,
	kvm@vger.kernel.org, kirill.shutemov@linux.intel.com,
	huibo.wang@amd.com, naveen.rao@amd.com,
	francescolavra.fl@gmail.com
Subject: Re: [PATCH v4 06/18] x86/apic: Add update_vector callback for Secure AVIC
Date: Thu, 17 Apr 2025 12:50:04 +0200	[thread overview]
Message-ID: <87a58frrj7.ffs@tglx> (raw)
In-Reply-To: <20250417091708.215826-7-Neeraj.Upadhyay@amd.com>

On Thu, Apr 17 2025 at 14:46, Neeraj Upadhyay wrote:
> Add update_vector callback to set/clear ALLOWED_IRR field in
> a vCPU's APIC backing page for external vectors. The ALLOWED_IRR
> field indicates the interrupt vectors which the guest allows the
> hypervisor to send (typically for emulated devices). Interrupt
> vectors used exclusively by the guest itself and the vectors which
> are not emulated by the hypervisor, such as IPI vectors, are part
> of system vectors and are not set in the ALLOWED_IRR.

Please structure changelogs properly in paragraphs:

  https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#changelog

>  arch/x86/include/asm/apic.h         |  9 +++++
>  arch/x86/kernel/apic/vector.c       | 53 ++++++++++++++++++++++-------
>  arch/x86/kernel/apic/x2apic_savic.c | 35 +++++++++++++++++++

And split this patch up into two:

  1) Do the modifications in vector.c which is what the $Subject line
     says

  2) Add the SAVIC specific bits

> @@ -471,6 +473,12 @@ static __always_inline bool apic_id_valid(u32 apic_id)
>  	return apic_id <= apic->max_apic_id;
>  }
>  
> +static __always_inline void apic_update_vector(unsigned int cpu, unsigned int vector, bool set)
> +{
> +	if (apic->update_vector)
> +		apic->update_vector(cpu, vector, set);
> +}

This is in the public header because it can?
  
> -static void apic_update_vector(struct irq_data *irqd, unsigned int newvec,
> -			       unsigned int newcpu)
> +static int irq_alloc_vector(const struct cpumask *dest, bool resvd, unsigned int *cpu)
> +{
> +	int vector;
> +
> +	vector = irq_matrix_alloc(vector_matrix, dest, resvd, cpu);

        int vector = irq_matrix_alloc(...);

> +
> +	if (vector >= 0)
> +		apic_update_vector(*cpu, vector, true);
> +
> +	return vector;
> +}
> +
> +static int irq_alloc_managed_vector(unsigned int *cpu)
> +{
> +	int vector;
> +
> +	vector = irq_matrix_alloc_managed(vector_matrix, vector_searchmask, cpu);
> +
> +	if (vector >= 0)
> +		apic_update_vector(*cpu, vector, true);
> +
> +	return vector;
> +}

I completely fail to see the value of these two functions. Each of them
has exactly _ONE_ call site and both sites invoke apic_update_vector()
when the allocation succeeded. Why can't you just do the obvious and
leave the existing code alone and add

      if (apic->update_vector)
      		apic->update_vector();

into apic_update_vector()? But then you have another place where you
need the update, which does not invoke apic_update_vector().

Now if you look deeper, then you notice that all places which invoke
apic_update_vector() invoke apic_update_irq_cfg(), which is also called
at this other place, no?

> +static void irq_free_vector(unsigned int cpu, unsigned int vector, bool managed)
> +{
> +	apic_update_vector(cpu, vector, false);
> +	irq_matrix_free(vector_matrix, cpu, vector, managed);
> +}

This one makes sense, but please name it: apic_free_vector()

Something like the uncompiled below, no?

Thanks,

        tglx
---
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -134,9 +134,19 @@ static void apic_update_irq_cfg(struct i
 
 	apicd->hw_irq_cfg.vector = vector;
 	apicd->hw_irq_cfg.dest_apicid = apic->calc_dest_apicid(cpu);
+
+	if (apic->update_vector)
+		apic->update_vector(cpu, vector, true);
+
 	irq_data_update_effective_affinity(irqd, cpumask_of(cpu));
-	trace_vector_config(irqd->irq, vector, cpu,
-			    apicd->hw_irq_cfg.dest_apicid);
+	trace_vector_config(irqd->irq, vector, cpu, apicd->hw_irq_cfg.dest_apicid);
+}
+
+static void apic_free_vector(unsigned int cpu, unsigned int vector, bool managed)
+{
+	if (apic->update_vector)
+		apic->update_vector(cpu, vector, false);
+	irq_matrix_free(vector_matrix, cpu, vector, managed);
 }
 
 static void apic_update_vector(struct irq_data *irqd, unsigned int newvec,
@@ -174,8 +184,7 @@ static void apic_update_vector(struct ir
 		apicd->prev_cpu = apicd->cpu;
 		WARN_ON_ONCE(apicd->cpu == newcpu);
 	} else {
-		irq_matrix_free(vector_matrix, apicd->cpu, apicd->vector,
-				managed);
+		apic_free_vector(apicd->cpu, apicd->vector, managed);
 	}
 
 setnew:
@@ -183,6 +192,7 @@ static void apic_update_vector(struct ir
 	apicd->cpu = newcpu;
 	BUG_ON(!IS_ERR_OR_NULL(per_cpu(vector_irq, newcpu)[newvec]));
 	per_cpu(vector_irq, newcpu)[newvec] = desc;
+	apic_update_irq_cfg(irqd, newvec, newcpu);
 }
 
 static void vector_assign_managed_shutdown(struct irq_data *irqd)
@@ -261,8 +271,6 @@ assign_vector_locked(struct irq_data *ir
 	if (vector < 0)
 		return vector;
 	apic_update_vector(irqd, vector, cpu);
-	apic_update_irq_cfg(irqd, vector, cpu);
-
 	return 0;
 }
 
@@ -338,7 +346,6 @@ assign_managed_vector(struct irq_data *i
 	if (vector < 0)
 		return vector;
 	apic_update_vector(irqd, vector, cpu);
-	apic_update_irq_cfg(irqd, vector, cpu);
 	return 0;
 }
 
@@ -357,7 +364,7 @@ static void clear_irq_vector(struct irq_
 			   apicd->prev_cpu);
 
 	per_cpu(vector_irq, apicd->cpu)[vector] = VECTOR_SHUTDOWN;
-	irq_matrix_free(vector_matrix, apicd->cpu, vector, managed);
+	apic_free_vector(apicd->cpu, vector, managed);
 	apicd->vector = 0;
 
 	/* Clean up move in progress */
@@ -366,7 +373,7 @@ static void clear_irq_vector(struct irq_
 		return;
 
 	per_cpu(vector_irq, apicd->prev_cpu)[vector] = VECTOR_SHUTDOWN;
-	irq_matrix_free(vector_matrix, apicd->prev_cpu, vector, managed);
+	apic_free_vector(apicd->prev_cpu, vector, managed);
 	apicd->prev_vector = 0;
 	apicd->move_in_progress = 0;
 	hlist_del_init(&apicd->clist);
@@ -905,7 +912,7 @@ static void free_moved_vector(struct api
 	 *    affinity mask comes online.
 	 */
 	trace_vector_free_moved(apicd->irq, cpu, vector, managed);
-	irq_matrix_free(vector_matrix, cpu, vector, managed);
+	apic_free_vector(cpu, vector, managed);
 	per_cpu(vector_irq, cpu)[vector] = VECTOR_UNUSED;
 	hlist_del_init(&apicd->clist);
 	apicd->prev_vector = 0;

  reply	other threads:[~2025-04-17 10:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17  9:16 [PATCH v4 00/18] AMD: Add Secure AVIC Guest Support Neeraj Upadhyay
2025-04-17  9:16 ` [PATCH v4 01/18] KVM: x86: Move find_highest_vector() to a common header Neeraj Upadhyay
2025-04-17  9:16 ` [PATCH v4 02/18] x86/apic: Add new driver for Secure AVIC Neeraj Upadhyay
2025-04-17  9:16 ` [PATCH v4 03/18] x86/apic: Initialize Secure AVIC APIC backing page Neeraj Upadhyay
2025-04-17  9:16 ` [PATCH v4 04/18] x86/apic: Populate .read()/.write() callbacks of Secure AVIC driver Neeraj Upadhyay
2025-04-17  9:16 ` [PATCH v4 05/18] x86/apic: Initialize APIC ID for Secure AVIC Neeraj Upadhyay
2025-04-17  9:16 ` [PATCH v4 06/18] x86/apic: Add update_vector callback " Neeraj Upadhyay
2025-04-17 10:50   ` Thomas Gleixner [this message]
2025-04-17 12:00     ` Neeraj Upadhyay
2025-04-17 16:51       ` Thomas Gleixner
2025-04-17 10:52   ` Thomas Gleixner
2025-04-17 12:12     ` Neeraj Upadhyay
2025-04-17 16:52       ` Thomas Gleixner
2025-04-17  9:16 ` [PATCH v4 07/18] x86/apic: Add support to send IPI " Neeraj Upadhyay
2025-04-17  9:16 ` [PATCH v4 08/18] x86/apic: Support LAPIC timer " Neeraj Upadhyay
2025-04-17  9:16 ` [PATCH v4 09/18] x86/sev: Initialize VGIF for secondary VCPUs " Neeraj Upadhyay
2025-04-17  9:17 ` [PATCH v4 10/18] x86/apic: Add support to send NMI IPI " Neeraj Upadhyay
2025-04-17  9:17 ` [PATCH v4 11/18] x86/apic: Allow NMI to be injected from hypervisor " Neeraj Upadhyay
2025-04-17  9:17 ` [PATCH v4 12/18] x86/sev: Enable NMI support " Neeraj Upadhyay
2025-04-17  9:17 ` [PATCH v4 13/18] x86/apic: Read and write LVT* APIC registers from HV for SAVIC guests Neeraj Upadhyay
2025-04-17  9:17 ` [PATCH v4 14/18] x86/apic: Handle EOI writes " Neeraj Upadhyay
2025-04-17  9:17 ` [PATCH v4 15/18] x86/apic: Add kexec support for Secure AVIC Neeraj Upadhyay
2025-04-17  9:17 ` [PATCH v4 16/18] x86/apic: Enable Secure AVIC in Control MSR Neeraj Upadhyay
2025-04-17  9:17 ` [PATCH v4 17/18] x86/sev: Prevent SECURE_AVIC_CONTROL MSR interception for Secure AVIC guests Neeraj Upadhyay
2025-04-17  9:17 ` [PATCH v4 18/18] x86/sev: Indicate SEV-SNP guest supports Secure AVIC Neeraj Upadhyay

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=87a58frrj7.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=David.Kaplan@amd.com \
    --cc=Neeraj.Upadhyay@amd.com \
    --cc=Santosh.Shukla@amd.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=Vasant.Hegde@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=francescolavra.fl@gmail.com \
    --cc=hpa@zytor.com \
    --cc=huibo.wang@amd.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=naveen.rao@amd.com \
    --cc=nikunj@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=seanjc@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.