linux-kernel - Re: [PATCH hyperv-next] x86/hyperv: Fix APIC ID and VP ID confusion in hv_snp_boot

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <aA7QZPFS7WWOsahp@liuwe-devbox-ubuntu-v2.tail21d00.ts.net>
Date: Mon, 28 Apr 2025 00:48:36 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Michael Kelley <mhklinux@...look.com>
Cc: Roman Kisel <romank@...ux.microsoft.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"decui@...rosoft.com" <decui@...rosoft.com>,
	"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"kys@...rosoft.com" <kys@...rosoft.com>,
	"mikelley@...rosoft.com" <mikelley@...rosoft.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"tiala@...rosoft.com" <tiala@...rosoft.com>,
	"wei.liu@...nel.org" <wei.liu@...nel.org>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"apais@...rosoft.com" <apais@...rosoft.com>,
	"benhill@...rosoft.com" <benhill@...rosoft.com>,
	"bperkins@...rosoft.com" <bperkins@...rosoft.com>,
	"sunilmut@...rosoft.com" <sunilmut@...rosoft.com>
Subject: Re: [PATCH hyperv-next] x86/hyperv: Fix APIC ID and VP ID confusion
 in hv_snp_boot_ap()

On Fri, Apr 25, 2025 at 04:55:42PM +0000, Michael Kelley wrote:
> From: Roman Kisel <romank@...ux.microsoft.com> Sent: Friday, April 25, 2025 9:36 AM
> > 
> > On 4/25/2025 8:12 AM, Michael Kelley wrote:
> > > From: Roman Kisel <romank@...ux.microsoft.com> Sent: Thursday, April 24, 2025 2:58 PM
> > >>
> > >> To start an application processor in SNP-isolated guest, a hypercall
> > >> is used that takes a virtual processor index. The hv_snp_boot_ap()
> > >> function uses that START_VP hypercall but passes as VP ID to it what
> > >> it receives as a wakeup_secondary_cpu_64 callback: the APIC ID.
> > >>
> > >> As those two aren't generally interchangeable, that may lead to hung
> > >> APs if VP IDs and APIC IDs don't match, e.g. APIC IDs might be sparse
> > >> whereas VP IDs never are.
> > >
> > > I agree that VP IDs (a.k.a. VP indexes) and APIC IDs don't necessary match,
> > > and that APIC IDs might be sparse. But I'm not aware of any statement
> > > in the TLFS about the nature of VP indexes, except that
> > >
> > >     "A virtual processor index must be less than the maximum number of
> > >     virtual processors per partition."
> > >
> > > But that maximum is the Hyper-V implementation maximum, not the
> > > maximum for a particular VM. So the statement does not imply
> > > denseness unless the number of CPUs in the VM is equal to the
> > > Hyper-V implementation max. In other parts of Linux kernel code,
> > > we assume that VP indexes might be sparse as well.
> > >
> > > All that said, this is just a comment about the precise accuracy of
> > > your commit message, and doesn't affect the code.
> > >
> > 
> > I appreciate your help with the precision. I used loose language,
> > agreed, would like to fix that. The patch was applied though but not yet
> > sent to the Linus'es tree as I understand. I'd appreciate guidance on
> > the process! Should I send a v2 nevertheless and explain the situation
> > in the cover letter?
> > 
> > IOW, how do I make this easier for the maintainer(s)?
> 
> Wei Liu should give his preferences. But in the past, I think he has
> just replaced a patch that was updated. If that's the case, you can 
> send a v2 without a lot of additional explanation.
> 

Normally if you need to send a new version because the original
patch is buggy, you can just update your patch.

If only a commit message or comment needs to be updated, I will let the
submitter know either to send a new version or not. Sometimes I will
just make the changes myself to save the submitter some time.

Wei.