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