Re: [PATCH hyperv-next] x86/hyperv: Fix APIC ID and VP ID confusion in hv_snp_boot_ap()

[Wei Liu <wei.liu@kernel.org>]

On Fri, Apr 25, 2025 at 04:55:42PM +0000, Michael Kelley wrote:
> From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, April 25, 2025 9:36 AM
> > 
> > On 4/25/2025 8:12 AM, Michael Kelley wrote:
> > > From: Roman Kisel <romank@linux.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.