Starting with Linux 4.18, there is new device node for issuing
hypercalls from user space - /dev/xen/hypercall (partially duplicating
functionality of /dev/xen/privcmd). New Xen tools (4.12) make use of it,
so make it available for them. Otherwise such tools will fail the
operation (there is no fallback to privcmd on EACCESS).
When root device is available read-write (TemplateVM/StandaloneVM), its
mounted directly, instead of using device-mapper layer. But
/dev/mapper/dmroot still needs to exists (it is pointed from
/etc/fstab), otherwise various tools, including grub-mkconfig get
confused.
Create a symlink using udev rule. It is already done in initramfs, and
in case of Fedora that udev rule/symlink survive switching to
non-initramfs udev, but not on Debian. So, add appropriate udev rules
file.
FixesQubesOS/qubes-issues#3178
The script call is quite expensive (it does multiple things, including
checking device-mapper, qubesdb etc). Don't call it for devices we (or
else) already excluded earlier.
This is the most relevant for dom0, where udev "change" event is
triggered quite often, for multiple LVM volumes - all excluded, because
being VM's disks.
Controller sysfs path have changed in recent kernels ('vhci_hcd' ->
'vhci_hcd.0'), look for vhci_hcd prefix, not exact this name.
QubesOS/qubes-issues#3455
Getting loop device backing file path was broken:
${NAME%p*} for not-partitioned devices will cut the actual device name.
Use full name instead. This probably breaks handling partitioned
devices, but such devices should not appear in a directory flagged to be
ignored (VM images)
QubesOS/qubes-issues#3084
1. Do not detach device forcefully when it's removed. This breaks
libvirt (which thinks the device is still there). After this change, it
is possible to detach device using libvirt, even if it was already
removed physically from backend domain (unless it is dom0 - in which
case it is still broken). So, this is partial fix for
QubesOS/qubes-issues#1082.
2. Do not trigger "change" udev event when only QubesDB state needs to
be updated - this leads to massive udev events queue, and heavy I/O
usage - for example scanning all LVM many times. In some cases it even
caused infinite event queue.
3. Do not use QUBES_EXPOSED udev property - it was needed a while back
before QubesDB, because concurrent xenstore accesses are expensive
(because of transactions). It isn't the problem on QubesDB.
4. Cache information about device-mapper, so it is possible to
reconstruct it at device remove - when the actual device cannot be
queried anymore. This is specifically about list of lower layer devices
used.
5. Allow excluding loop devices pointing at a file in directory marked
with ".qubes-exclude-block-devices" file. This is more generic than
hardcoding /var/lib/qubes.
QubesOS/qubes-issues#3084FixesQubesOS/qubes-issues#3073QubesOS/qubes-issues#1082
For example do not exclude (from exposing to qvm-block) loop devices
with this flag set, otherwise `qvm-block -l` would not list just
attached disk image files.
FixesQubesOS/qubes-issues#2453
For example, attaching a device-mapper device to another VM increases
its "dmsetup info" open count in is_used(), which triggered its removal
from qvm-block.
The canonical device name is not necessarily used in /proc/mounts or
/proc/self/mountinfo, see /dev/dm-0 vs. /dev/mapper/dmroot. (And only
checking by major:minor is not possible in the case of btrfs.)
Also fixes another bug where e.g. dm-10 would match when really only
dm-1 was mounted, or when the mountpoint path included the device name,
etc.
Also catches enabled swap.
Apparently some devices do not comply with standards (there is no such
thing as USB version 2.01), but other than that works fine. So take into
account only the major number of bcdUSB field.
FixesQubesOS/qubes-issues#2158
Those devices are most likely attached using "PV USB" from another
domain, so it doesn't make sense to list them as available for further
passthrough.
QubesOS/qubes-issues#531
Even if particular PV USB implementation doesn't support it, still have
it included in QubesDB. It should be up to attaching code to decide.
Also, don't fail if xen-usbback module doesn't exist. This isn't the
only option (the other one is usbip over qrexec).
QubesOS/qubes-issues#531
During early dom0 boot, before xenstored is started any access to it
through /proc/xen/xenbus (or /dev/xen/xenbus) will wait until xenstored
is started. If that happens in script ordered to start before xenstored,
we have a deadlock. Prevent this by using `xenstore-ls -s` in dom0,
which will fail immediately when xenstored isn't running yet. This fail
isn't a problem, because when xenstored isn't running yet, surely device
isn't attached anywhere.
QubesOS/qubes-issues#1081
This prevents simultaneous attachment of the same device (in practice)
to multiple VMs.
This change to be effective requires udev action being called when such
device is attached/detached to some domain. Script
/etc/xen/scripts/block will take care of it.
FixesQubesOS/qubes-issues#1081
Exclude exclude device if mounted/part of other device, or any of its
partition is used (same definition). Update this state whenever device
or it's partition receives udev event.
FixesQubesOS/qubes-issues#1600
When device becomes non-attachable (for example because it gets mounted,
or used as part of LVM/RAID/whatever), it should be removed from
advertised available devices. The code for removing QubesDB entry was
buggy - the device is actually a directory in QubesDB, not a single
entry.
QubesOS/qubes-issues#1600
There are already some other rules to ignore not interesting devices.
This includes device-mapper assembled in initramfs manually. 'dmroot'
isn't properly detected as mounted because /dev/mapper/dmroot isn't a
symlink to /dev/dm-0 and /proc/mounts contains the former name, while
udev event the later.
FixesQubesOS/qubes-issues#1586
Since migration to QubesDB, it isn't needed anymore (QubesDB have no
problem with concurrent writes, as transactions are not supported).
This should speedup system startup.
Recently we've switched all xenstore access to the new interface
(instead of deprecated /proc/xen/xenbus). Mostly because of deadlock in
/proc/xen/xenbus implementation.
It can happen during device reconfiguration - do not decide to expose
the device until its known what device it will be.
This fixes bug where root.img was visible in qvm-block as normal device
and could be detached.
xenstored does handle concurrent writes very harshly - it aborts the
whole transaction if any other write happened the same time. For udev
(which process all the events almost at once) it means hundreds of
retries and in some times even exceed udev timeout (60s or so).
To prevent this problem, add locking to allow only one such event being
processed at once. It looks like it should slow down the system startup,
but actually it does otherwise.
