Repository navigation
Backport #102 to 6.18-lts: Drivers: hv: balloon: refuse to bind on a Xen PV dom0 nested under Hyper-V - #106
Merged
Conversation
…per-V The Hyper-V-on-Xen series translates GPADLs, SynIC pages, hypercall arguments and netvsc buffers to the machine (L1-physical) frames the L0 host expects, but hv_balloon was never taught about nested mode. It hands L0 page_to_pfn() ranges straight from dom0's pseudo-physical address space, in balloon responses, free-page reports and hot-add requests, and L0 reads each of those numbers as a Xen machine frame. On a PV dom0 nested on Hyper-V the device autoloads from the VMBus offer, Xen proxies POST_MESSAGE and SIGNAL_EVENT, and the dynamic memory protocol runs end to end. A DM_BALLOON_REQUEST from the host then has L0 reclaim whichever machine frames dom0's PFNs happen to name: Xen's own memory, another domain's, or unrelated dom0 memory, with no error anywhere. A hot-add does the reverse and calls add_memory() on a host range that dom0's physmap does not back, so dom0 oopses on first touch. Translating the ranges would not make this correct either. A PV dom0 does not own the machine memory it runs on, Xen does, and the memory an L1 VM returns to or takes from L0 has to be accounted for in Xen's heap, not handed over behind its back by one of its domains. Dynamic memory for the L1 VM is a job for Xen itself. Refuse the probe when nested on Xen, so the offer stays unbound and dom0 does not speak the protocol at all. Nothing changes when not nested: hyperv_nested_on_xen is a build-time false without CONFIG_XEN_PV. Signed-off-by: Ariadne Conill <[email protected]> (cherry picked from commit 98e8637)
…t be bound hyperv_xen_vpci_root_domain() frees the named fwnode when creating the irq domain fails, but not when cpuhp_setup_state() fails afterwards: irq_domain_remove() does not free the fwnode its domain was created with, so that path leaked it. Free it there too. Signed-off-by: Ariadne Conill <[email protected]> (cherry picked from commit 7ef9c69)
kaniini
approved these changes
Nov 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #102 from
edera/mainlinetoedera/6.18-lts(492d0ef30003), prepared by Claude. Run log.Merge with Rebase and merge, so
edera/6.18-ltsstays linear.Independent checks
Builds: success (x86_64 and arm64 vmlinux with the Edera features built in).
492d0ef300035a9e2ae8cafbClaude's report
Summary
Two commits were requested from #102 and both are backported unchanged, in order, with
cherry-pick -x. Both applied cleanly to492d0ef30003.hyperv_nested_on_xenalready exists on 6.18-lts: it is declared inarch/x86/include/asm/mshyperv.handinclude/asm-generic/mshyperv.h, and is a build-timefalsewithoutCONFIG_XEN_PV. Thefnlocal and the error path inhyperv_xen_vpci_root_domain()are the same as on mainline, so no adaptation was needed.verify-backport.shpasses: the branch fast-forwards, is linear, and has both commits in order with matching subjects and identical +/- lines.The REQUEST file and the PENDING file list different SHAs for these two commits:
98e86378/7ef9c692in REQUEST,109e385a/a779e3fein PENDING.git range-diffshows the patches are identical. The two pairs differ only in committer date, which looks like the PR branch versus the rebased copy. The(cherry picked from commit …)trailers name the REQUEST SHAs.Needs a decision
None.
Adapted commits
None.
Left out
None.
Builds
BUILD_RESULTS