linux-kernel - Re: [RFC PATCH v4 4/8] x86/apic: Introduce Remote Action Request Operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aF1w1RLgA9w7tRUg@google.com>
Date: Thu, 26 Jun 2025 09:09:57 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: Rik van Riel <riel@...riel.com>, linux-kernel@...r.kernel.org, kernel-team@...a.com, 
	dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org, 
	bp@...en8.de, x86@...nel.org, nadav.amit@...il.com, tglx@...utronix.de, 
	mingo@...nel.org, Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [RFC PATCH v4 4/8] x86/apic: Introduce Remote Action Request Operations

On Thu, Jun 26, 2025, Kirill A. Shutemov wrote:
> On Thu, Jun 19, 2025 at 04:03:56PM -0400, Rik van Riel wrote:
> > From: Yu-cheng Yu <yu-cheng.yu@...el.com>
> > 
> > RAR TLB flushing is started by sending a command to the APIC.
> > This patch adds Remote Action Request commands.
> > 
> > Because RAR_VECTOR is hardcoded at 0xe0, POSTED_MSI_NOTIFICATION_VECTOR
> > has to be lowered to 0xdf, reducing the number of available vectors by
> > 13.
> > 
> > [riel: refactor after 6 years of changes, lower POSTED_MSI_NOTIFICATION_VECTOR]
> 
> But why? Because it is used as FIRST_SYSTEM_VECTOR?

The Posted MSI Notifications vector should be the lowest of the system vectors
so that device IRQs are NOT prioritized over "real" system vectors.

> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@...el.com>
> > Signed-off-by: Rik van Riel <riel@...riel.com>
> > ---
> >  arch/x86/include/asm/apicdef.h     | 1 +
> >  arch/x86/include/asm/irq_vectors.h | 7 ++++++-
> >  arch/x86/include/asm/smp.h         | 1 +
> >  arch/x86/kernel/apic/ipi.c         | 5 +++++
> >  arch/x86/kernel/apic/local.h       | 3 +++
> >  5 files changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/include/asm/apicdef.h b/arch/x86/include/asm/apicdef.h
> > index 094106b6a538..b152d45af91a 100644
> > --- a/arch/x86/include/asm/apicdef.h
> > +++ b/arch/x86/include/asm/apicdef.h
> > @@ -92,6 +92,7 @@
> >  #define		APIC_DM_LOWEST		0x00100
> >  #define		APIC_DM_SMI		0x00200
> >  #define		APIC_DM_REMRD		0x00300
> > +#define		APIC_DM_RAR		0x00300
> 
> Hm. Do we conflict with APIC_DM_REMRD here?

Yes and no.  Yes, it literally conflicts, but it's easy enough to define the behavior
of APIC_DM_{REMRD,RAR} based on feature support.  E.g. KVM is likely going to add
support for Remote Read, which would conflict with KVM's bastardization of
APIC_DM_REMRD for PV kicks.  But as Paolo pointed out[*], KVM's PV unhalt/kick
can simply be gated on KVM_FEATURE_PV_UNHALT.  Any code that cares should be able
to do the same thing for RAR.  E.g. KVM's code could end up being something like:

	case APIC_DM_REMRD:
		if (guest_pv_has(vcpu, KVM_FEATURE_PV_UNHALT)) {
			result = 1;
			vcpu->arch.pv.pv_unhalted = 1;
			kvm_make_request(KVM_REQ_EVENT, vcpu);
			kvm_vcpu_kick(vcpu);
		} else if (guest_has_rar(vcpu)) {
			<magic!>
		} else {
			<emulate legacy Remote Read>;
		}
		break;

For the kernel itself, there's nothing to do, because Linux doesn't use Remote Read.

[*] https://lore.kernel.org/all/CABgObfadZZ5sXYB0xR5OcLDw_eVUmXTOTFSWkVpkgiCJmNnFRQ@mail.gmail.com