Repository navigation
Conversation
An SM driver that attaches a block device and asks for blkback leaves
params as the device ("/dev/loop0") and publishes vdi-uuid and
mem-pool under backend/vbd/<dom>/<dev>/sm-data, the same keys SM writes
for vbd3. The fallback only looked there for vbd3, so such a disk was
grouped under an SR named "/dev" and its real SR showed no VBDs.
Seen on a RISC-V XCP-ng dom0 whose file SR serves VDIs through loop
devices and blkback. Plain Xen hosts have no sm-data, so the extra
read returns nothing there and the backing stays the path.
The path is kept: once mem-pool names the SR, Backing::group() uses
the SR; without mem-pool the disk still groups by its directory, as
before, and only gains the VDI.
Signed-off-by: Bruno Verachten <gounthar@gmail.com>
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
1 participant
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.
On the RISC-V XCP-ng dom0 we're bringing up, the file SR serves VDIs through a loop device and blkback, not tapdisk. The VBD lives under
backend/vbd,paramsis/dev/loop0, and SM publishesvdi-uuidandmem-poolundersm-data, the same keys it writes for vbd3. Thesm-datafallback inStorageMaponly ran forVbdKind::Vbd3, so the guest disk ended up under an SR called/devand the real SR showed no VBDs.This drops the vbd3 condition. The path stays: when
mem-poolis there,Backing::group()picks the SR, and when it isn't, the disk groups by directory as before and only gains the VDI. If you'd rather keep the fallback narrower (blkback with a/dev/...params only, say), I can change it.On the dom0, with
mem-poolpresent on the VBD node:DiskVBDs/devDisk/trixie-rootWithout
mem-poolit stays under/devwith the VDI filled in. 101/101 tests pass on x86_64 and on a native riscv64 build, clippy and fmt clean. I haven't run it on a plain Xen host; there's nosm-datathere, so the extra read should return nothing.The rawfile driver on our side now writes
mem-pooltoo (baptleduc/hypervisor-dev#11).This work was assisted by an LLM.