From: Emerson Busson <[email protected]> Sent: Wednesday, October 7, 2026 12:08 PM > > This series moves VMBus ring backing to the chunk allocator and keeps the > allocation, GPADL ownership, and mapping references together. It preserves > the exported four-argument interfaces while allowing the private allocation > paths to carry ownership and sharing policy. > > A review of the original vzalloc fallback noted that CCA and TDX guests > without a paravisor need direct-map page transitions. This revision uses > contiguous chunks for buffers that must be host-shared, transitions each > page through page_address(), and combines the chunks with vmap(). Ordinary > guest-private buffers retain vzalloc-style allocation. > > Allocation and compatibility > ---------------------------- > > Every ring allocation uses the chunk allocator. Ordinary guests and buffers > kept private by channel policy use vzalloc(). For host-shared buffers in an > encrypted or isolated guest, the allocator uses contiguous chunks and > transitions them page by page. Guest-memory encryption is selected > independently of Hyper-V isolation. > > Ring consumers select co_ring_buffer. External buffers and the legacy > allocator select co_external_memory. The exported allocator and caller- > decrypted GPADL prototypes retain four arguments throughout all fourteen > patches. UIO migration follows its release support. > > The address, page and chunk arrays, and embedded GPADL belong to one buffer. > The allocation extent, host-described GPADL extent, and retained allocation > extent remain distinct. Interior GPADL duplication preserves the existing > exported interfaces. Prepared owned buffers avoid repeat decryption, and > HV_GPADL_BUFFER_DECRYPTED is removed. > > Lifetime and host acknowledgement > --------------------------------- > > A host rescind alone does not prove GPADL revocation. For a known-live GPADL > whose channel identifier is still held, teardown posts a request and waits > for a matching GPADL_TORNDOWN message before clearing ownership. Synthetic > rescind notification cannot replace this acknowledgement. Unknown creates, > local removal, invalid identifiers, failed posting, and timeouts retain > ownership. > > Waiter removal shares the response-list lock with matching replies so a late > acknowledgement cannot use a freed waiter. Released owners retain pages > across mapping references and failed page-state restoration. Reclaimer > shutdown cancels pending timers under the owner lock and requeues only work > that was actually canceled; running callbacks drain through workqueue > destruction without re-executing freed embedded work. > > Sysfs mappings install no vm_ops and release the bridge pin on every setup > outcome. UIO mappings hold their pin through VMA close. Page, count, and > protection snapshots share the owner-lock boundary. New tests call the real > sysfs wrapper, insert actual PTEs, and check readable bytes and page > references through success and partial -EBUSY. They do not execute a full > kernfs syscall or full device destruction. > > The final four fixes use vzalloc() for guest-private requestor arrays and > bitmaps, kvzalloc_obj() for guest-private RNDIS descriptors, handle NULL > control requests on empty NetVSC completions, and use kvzalloc_obj()/kvfree() > for the large guest-private NetVSC device object. > > Qualification on the exact fourteen-patch series > ------------------------------------------------ > > The code mails are pinned by series/SHA256SUMS. Applying all fourteen to > 93f51579e7df248780214094418f205253383cc5 produces source tree > e6fe523ca92ce30ea7edb265b8a26bf20a867c47. > > The VMBus workflow builds x86_64 and arm64 with W=1 and C=2, passes sparse, > and passes all 69 linked x86_64 QEMU KUnit cases. The distinct WSL backport > passes all 26 of its KUnit cases. CoCo source invariants pass on both > architectures; these are necessary static checks, not confidential-hardware > qualification. > > Exact-source Hyper-V runtime, including controlled host rescind: > https://github.com/emersonbusson/WSL2-Linux-Kernel/actions/runs/37650468077 > > On both windows-2025 and windows-latest, the candidate passes 100 bind/unbind > cycles, bounded buddy fragmentation, channel rebind, UIO mapping teardown, > and the controlled host-origin NIC removal. Each report records > HYPERV_DRILL_HOST_RESCIND status=PASS, target_absent=yes, > matching_events=1. Both report zero splats and faults, restore the measured > kernel settings, and return lifecycle map accounting to the settled > operational > baseline. Captured owner accounting reports 722 created, zero unobserved > creates, 715 reclaimed, and seven still active; active owners are not > classified as leaks. Trace capture has no overruns or dropped events, and > the disposable VM, VHD, and switch cleanup passes. > > The baseline is an intentional negative control. It reproduces the expected > fragmented-allocation failure without guest faults; the workflow accepts > that exact signature as a passing control. It is not a candidate result. > > WSL backport runtime matrix: > https://github.com/emersonbusson/WSL2-Linux-Kernel/actions/runs/37645708153 > > That separate backport passes the actual Windows candidate matrix. Each > runner completes 64 commands with matching teardown acknowledgements, > zero unacknowledged requests, no backing or tail growth, and all six > shutdown checks. The shutdown retry path is covered by 40 local parser and > refusal regressions; the live candidate runs required zero retries. These > results qualify the WSL backport's measured ordinary behavior, not the > mainline mail series. > > Qualification limits > -------------------- > > The Hyper-V runtime uses the ordinary x86_64 vzalloc path. It does not > execute confidential chunk transitions. Full memory saturation, the > chunked CoCo fallback on hardware, SEV-SNP, TDX without a paravisor, Arm > CCA, and complete VMBus module unload and retained-owner destruction remain > unqualified. The exact mainline series has not been installed or booted on > the daily WSL host; the installed kernel and Windows WSL matrix are a separate > backport. The baseline is one intentional fragmentation negative control, > not a matched same-configuration diagnostic-count comparison for every patch. > No confidential-platform result is inferred from ordinary Hyper-V or static > checks. > > --- > Emerson Busson (14): > hv: vmbus: convert ring backing through the chunk allocator > hv: vmbus: validate chunk buffer allocation and cleanup > uio: hv_generic: describe buffers for owned allocation > hv: vmbus: add KUnit tests for GPADL post failure injection > hv: vmbus: add KUnit test for order-zero allocation fallback > hv: vmbus: cover all shared-page policy combinations > hv: vmbus: distinguish host rescind from local channel unload > hv: vmbus: retain backing until ownership and references clear > hv: use owned VMBus buffers in NetVSC and UIO > hv: vmbus: pin buffer pages across UIO mmap to close the reclaim race > hv: vmbus: vmalloc requestor metadata > hv: netvsc: allocate RNDIS request descriptors with kvzalloc_obj() > hv: netvsc: handle a NULL request address on empty completions > hv: netvsc: use kvzalloc for device state
This patch set has become huge in going from your original v1 to this v2. The v1 diffstat was 101 insertions and 12 deletions. This v2 has 4515 insertions and 427 deletions, which is too big to be effectively reviewed. (For some reason this v2 cover letter doesn't have the diffstat, while your v1 series did.) The elapsed time from my comments on v1 to this v2 is a little over 2 weeks, so it's clear that most of this code must be AI generated, which is itself a red flag. I'll also comment further down on the commit messages and this cover page summary, which I find difficult to comprehend and assume must have been mostly AI-generated as well. At a top level, I think this needs to be broken into multiple patch sets, each with a clear focus. I can see these areas: 1) Ensure ring buffer allocations don't fail when memory is fragmented 2) Ensure other allocations by VMBus infrastructure and drivers (netvsc) don't fail when memory is fragmented 3) Deal with failures in GPADL teardown, ensuring that the memory is leaked (I think this is what you are calling "ownership"). This can be a tricky area, especially if the host doesn't respond within the guest's timeout period. There's an existing VMBus mechanism to help with this case but it has not been applied widely. The VMBus code mostly just assumes that if there's no response in the timeout period, there will never be a response. Handling a "late" response is a separate issue that already exists, and could be dealt with in a separate patch set if it's judged to be worth the trouble. 4) It looks like there are other bugs you are also fixing (UIO mmap and reclaim race?). If such bugs already existed, it's usually better to fix them as a separate patch or patch set, rather than folding the fixes into a patch set that is focused on a different issue. That's particularly true if the complexity of the fix is moderate to high. 5) Kunit tests. There are 2651 lines added in the new *test.c files, plus there are hooks and supporting infrastructure in the main source code files. So over half the code in this patch set is for tests. I'm rather ambivalent about this. Having unit tests is good. But as you can tell, not much effort has been invested to date in doing VMBus unit tests, with one reason being that it requires a relatively high level of invasiveness. As a result, it's a lot of test code that adds to the maintenance burden over time. Probably should get a read from the Hyper-V maintainers on whether they want to take on that burden. There may be some interdependencies between the above areas. The trick is to figure out a sequencing that makes conceptual sense while allowing the code to be added incrementally. It's OK to design an earlier step in the sequence with a later step in mind but hopefully not add the code until the later step. Caveat: My list of 5 areas above is based on my high-level read of your v2 patch set. As the author, you have to deal with the details, and there may be reasons that combining two of the areas actually does make sense. Feel free to make that such a case -- don't take my statement as absolute truth. Commit messages (and this cover letter) must focus on the "Why?" question. What is the problem scenario? Has the problem been seen in the real world, or it is the result of code inspection or an AI report? And then, what is the proposed fix? I know that memory allocation failure due to fragmentation has happened in the real world, so I'm on-board with the general approach to fixing it. Alternatively, if the patch set is adding a new feature/function, why is it needed? What problem is solved or new capability is provided, and why is that valuable? For large patch sets, cover letters also often explain the sequencing and purpose of the patches in the patch set. E.g., Patches 1 thru 3 do some preliminary code reorganization; patches 4 thru 8 are the core of the patch set and fix the core XXXXX issue; patches 9 and 10 remove XXXXX existing functionality that was made obsolete by the new code. The goal is to give the reviewer a roadmap. Read through postings to the linux-hyperv and linux-kernel mailing lists to get a feel for how commit messages read. You want yours to fit in with existing style and terminology (e.g., use "testing", not "qualification"). I could provide more detailed feedback on the commit messages, but would prefer to spend my time on a closer review once they are more in alignment with typical practices. Bottom-line: My recommendation is to go back to the original problem from v1 of your patch set, and provide a good solution to that problem, with modest refactoring so it fits naturally in the existing code base and hopefully simplifies some of the complexity that has built-up over time. Skip the Kunit tests for now. Separately (and perhaps in parallel), deal with my #2, which is other high-order allocations that could fail when memory is fragmented. Feel free to use AI as an assistant, but don't just pass-thru AI-generated code and commit messages. Put effort into making sure the code is good and tight -- don't push that effort onto reviewers from the mailing list. You've got to "own" the result before submitting it. Michael
