January 2019 - Devel - libvirt List Archives

[libvirt] AMD SEV's /dev/sev permissions and probing QEMU for capabilities
by Erik Skultety 15 Mar '19

15 Mar '19

Hi, this is a summary of a private discussion I've had with guys CC'd on this email about finding a solution to [1] - basically, the default permissions on /dev/sev (below) make it impossible to query for SEV platform capabilities, since by default we run QEMU as qemu:qemu when probing for capabilities. It's worth noting is that this is only relevant to probing, since for a proper QEMU VM we create a mount namespace for the process and chown all the nodes (needs a SEV fix though). # ll /dev/sev crw-------. 1 root root I suggested either force running QEMU as root for probing (despite the obvious security implications) or using namespaces for probing too. Dan argued that this would have a significant perf impact and suggested we ask systemd to add a global udev rule. I proceeded with cloning [1] to systemd and creating an udev rule that I planned on submitting to systemd upstream - the initial idea was to mimic /dev/kvm and make it world accessible to which Brijesh from AMD expressed a concern that regular users might deplete the resources (limit on the number of guests allowed by the platform). But since the limit is claimed to be around 4, Dan discouraged me to continue with restricting the udev rule to only the 'kvm' group which Laszlo suggested earlier as the limit is so small that a malicious QEMU could easily deplete this during probing. This fact also ruled out any kind of ACL we could create dynamically. Instead, he suggested that we filter out the kvm-capable QEMU and put only that one in the namespace without a significant perf impact. - my take on this is that there could potentially be more than a single kvm-enabled QEMU and therefore we'd need to create more than just a single namespace. - I also argued that I can image that the same kind of DOS attack might be possible from within the namespace, even if we created the /dev/sev node only in SEV-enabled guests (which we currently don't). All of us have agreed that allowing /dev/sev in the namespace for only SEV-enabled guests is worth doing nonetheless. In the meantime, Christophe went through the kernel code to verify how the SEV resources are managed and what protection is currently in place to mitigate the chance of a process easily depleting the limit on SEV guests. He found that ASID, which determines the encryption key, is allocated from a single ASID bitmap and essentially guarded by a single 'sev->active' flag. So, in conclusion, we absolutely need input from Brijesh (AMD) whether there was something more than the low limit on number of guests behind the default permissions. Also, we'd like to get some details on how the limit is managed, helping to assess the approaches mentioned above. Thanks and please do share your ideas, Erik [1] https://bugzilla.redhat.com/show_bug.cgi?id=1665400 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1561113

4 25

[libvirt] [PATCH for-4.0 v4 0/2] virtio: Provide version-specific variants of virtio PCI devices
by Eduardo Habkost 06 Mar '19

06 Mar '19

Existing modern-only device types are not being touched by v3, as they don't need separate variants. However, I plan to implement separate cleanups in the code that calls virtio_pci_force_virtio_1(), first, and then propose additional changes (e.g. deprecating disable-legacy and disable-modern in those device types). Changes v3 -> v4: * Trivial comment fixes (Cornelia Huck) * Test code update (Caio Carrara) Changes v2 -> v3: * Split into two separate patches (type registration helper and introduction of new types) * Rewrote virtio_pci_types_register() completely: * Replaced magic generation of type names with explicit fields in VirtioPCIDeviceTypeInfo * Removed modern_only field (not necessary anymore) * Don't register a separate base type unless necessary Changes v1 -> v2: * Removed *-0.9 devices. Nobody will want to use them, if transitional devices work with legacy drivers (Gerd Hoffmann, Michael S. Tsirkin) * Drop virtio version from name: rename -1.0-transitional to -transitional (Michael S. Tsirkin) * Renamed -1.0 to -non-transitional * Don't add any extra variants to modern-only device types (they don't need it) * Fix typo on TYPE_VIRTIO_INPUT_HOST_PCI (crash reported by Cornelia Huck) * No need to change cast macros for modern-only devices * Rename virtio_register_types() to virtio_pci_types_register() Original patch description: Many of the current virtio-*-pci device types actually represent 3 different types of devices: * virtio 1.0 non-transitional devices * virtio 1.0 transitional devices * virtio 0.9 ("legacy device" in virtio 1.0 terminology) That would be just an annoyance if it didn't break our device/bus compatibility QMP interfaces. With this multi-purpose device type, there's no way to tell management software that transitional devices and legacy devices require a Conventional PCI bus. The multi-purpose device types would also prevent us from telling management software what's the PCI vendor/device ID for them, because their PCI IDs change at runtime depending on the bus where they were plugged. This patch adds separate device types for each of those virtio device flavors: * virtio-*-pci: the existing multi-purpose device types * virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers * virtio-*-pci-non-transitional: modern-only Reference to previous discussion that originated this idea: https://www.mail-archive.com/qemu-devel@nongnu.org/msg558389.html Eduardo Habkost (2): virtio: Helper for registering virtio device types virtio: Provide version-specific variants of virtio PCI devices hw/virtio/virtio-pci.h | 78 +++++++-- hw/display/virtio-gpu-pci.c | 7 +- hw/display/virtio-vga.c | 7 +- hw/virtio/virtio-crypto-pci.c | 7 +- hw/virtio/virtio-pci.c | 267 ++++++++++++++++++++++------- tests/acceptance/virtio_version.py | 176 +++++++++++++++++++ 6 files changed, 452 insertions(+), 90 deletions(-) create mode 100644 tests/acceptance/virtio_version.py -- 2.18.0.rc1.1.g3f1ff2140

9 13

[libvirt] Configuring pflash devices for OVMF firmware
by Markus Armbruster 22 Feb '19

22 Feb '19

We configure OVMF firmware for PC machine types with -drive if=pflash. This is pretty much the last remaining use of -drive in libvirt we can't yet replace by -blockdev. Such a replacement is desirable, because -blockdev + -device is more flexible than -drive if=pflash. Also, once we don't need -drive with new QEMU anymore, the path for deleting all -drive code in libvirt some day is open. As with all desirables, the benefit needs to exceed the cost. I'm going to describe the status quo, how we got there (briefly and much simplified), then sketch how to replace -drive if=pflash. I'm afraid this is fairly long; sorry. Please correct misunderstandings. Beware, my libvirt and OVMF fu is much weaker than my QEMU fu. In the beginning, board code read the BIOS from a fixed file and mapped it into the guest's address space. Life was simple. On physical hardware, the BIOS can persist a bit of state across (cold) reboots by storing it in (non-volatile) CMOS RAM. We didn't bother. Simple. Fast forward several years, and The Law of OS Envy (every program wants to grow into a full-blown operating system) has asserted itself: PC Firmware has grown from an 8KiB ROM using a few bytes of volatile and non-volatile RAM into a multi-megabyte beast with much more complex storage needs. On today's physical PC hardware, firmware is stored in flash memory. There's code, and there's persistent data. For obvious reasons, the code should be write-protected except when doing an upgrade. "Secure boot" additionally needs to restrict data writes to system management mode (SMM). Here's our first iteration of OVMF support, at QEMU level: -drive if=pflash,format=raw,file=/where/ever/OVMF.fd Generic code creates a block backend for it. Magic board code picks up the backend, creates a frontend (a cfi.pflash01 device), and maps it into the guest's address space. At libvirt level: <loader type="pflash">/where/ever/OVMF.fd</loader> Problem: while the flash device model provides read-only capability, it's all-or-nothing. You can't tell it to write-protect just the part holding code. The examples above don't write-protect anything. /where/ever/OVMF.fd better be writable exclusively. The flash device model could be enhanced, but we went down a different path: we split the single OVMF image OVMF.fd ("unified build") into a code image OVMF_CODE.fd and a data image OVMF_VARS.fd ("split build"). At QEMU level: -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=/where/ever/OVMF_VARS.fd OVMF_CODE.fd must be unit 0, and OVMF_VARS.fd must be unit 1. Generic code creates two block backends. Magic board code picks them up, creates a frontend (a cfi.pflash01 device) for each, and maps them into the guest's address space. Note there are *two* virtual flash devices now, whereas physical hardware commonly has just one. At libvirt level: <loader type="pflash" readonly="yes">/usr/share/OVMF/OVMF_CODE.fd</loader> <nvram template="/usr/share/OVMF/OVMF_VARS.fd">/var/libvirt/nvram/${guest}_VARS.fd</nvram> This treats OVMF_VARS.fd as a read-only template, and gives each guest its own writable copy, which is nice. The flash device model supports restricting writes to SMM (remember, that's required for secure boot). It's controlled by cfi.pflash01 property secure, off by default. If we created the device model with -device, we'd simply pass secure=on. But since we create it with -drive if=pflash, we can't. Instead we have to use -global driver=cfi.pflash01,property=secure,value=on This flips the global default value. Awkward, but works out okay, because (1) the flash device holding OVMF_VARS.fd wants this value, and (2) the flash device holding OVMF_CODE.fd doesn't care (it's read-only), and (3) there is no way to create additional flash devices. At the libvirt level, we add secure='yes' to the loader element. We also have to enable SMM emulation. At QEMU level: -machine smm=on At libvirt level: <features> <smm state='on'/> </features> Note that the above configuration examples involve selecting OVMF images. A bit of an inconvenience compared to BIOS, where the default "use the BIOS shipped with QEMU" pretty much just works. To add annoyance to inconvenience, different distributions have different ideas on where to install OVMF images. And because that's not complicated enough, we also have to pair code with data images. And because that's still not complicated enough, any specific machine type may work only with a subset of the available firmwares. The proposed way to deal with all that works as follows. Each set of firmware images comes with a descriptor file. These are JSON and conform to the QAPI schema docs/interop/firmware.json. Among the descriptors that declare support for the kind of machine we want, we pick (really: the management application picks) the one with the highest priority. The distribution provides default priorities, which system administrator and user can override. firmware.json documents this in much more detail. I wrote "proposed", because as far as I can tell, neither distributions nor libvirt are there, yet. After all this text, I'm finally ready to curve towards -blockdev. Going from -drive if=T, T!=none to -blockdev involves two steps. The first step replaces if=T with if=none and -device. The second step replaces -drive if=none with -blockdev. That step is "obvious" (it took us a few years to get to obvious, but I digress). The difficulty is in the first step. Two issues: (1) cfi.pflash01 isn't available with -device. (2) "Magic board code picks up the backend [created for -drive if=pflash], creates a frontend (a cfi.pflash01 device), and maps it into the guest's address space." When we replace if=pflash by if=none, we get to replicate that magic on top of -device. Issue (1) isn't too hard: we add the device to the dynamic sysbus device white-list, move a sysbus_mmio_map() from pflash_cfi01_realize() into pflash_cfi01_realize(). The latter requires a new device property to configure the base address. I got a working prototype. Since this makes the device model's name and properties ABI, review would be advisable. To solve (2), we first have to understand the magic. Device cfi.pflash01 has the following properties: num-blocks Size of the device in blocks sector-length Size of a block (admire the choice of names) width Bank width big-endian Endianess (d'oh) id0, id1, id2, id3 Some kind of device ID, guest-visible, default to zero, few boards change it name Memory region name (why is this even configurable?) phys-addr Physical base address (this is the new device property mentioned above) secure For restricting access to firmware, default off device-width you don't want to know, there is a default, but it's documented as "bad, do not use", yet pretty much all boards use it max-device-width defaults to device-width not actually set anywhere old-multiple-chip-handling back-compat gunk for machine types 2.8 and older The magic board code in hw/i386/pc_sysfw.c configures as follows: num-blocks computed from backend size sector-length 4096 width 1 big-endian 0 id0, id1, id2, id3 all 0 name system.pflash, where U is -drive's unit number phys-addr computed so unit 0 ends right below 0x100000000, unit n+1 ends at right below unit n "secure", "device-width", "max-device-width", "old-multiple-chip-handling" are left at the default. One additional bit of magic is actually in libvirt: it configures "secure" by flipping its default with -global driver=cfi.pflash01,property=secure,value=on. Now let's consider how to replicate this magic on top of device. Perhaps machine-type specific defaults could take care of sector-length, width, big-endian, id0, id1, id2, id3. Leaves num-blocks, name, and phys-addr. Perhaps the realize() method could default num-blocks to size of backend. But that doesn't really help the management application, because it needs to mess with the size anyway to compute phys-addr. So scratch that idea. Moving the magic code to compute num-blocks, phys-addr and name to the management application is certainly possible, but ugly. Note that the values computed are fixed when the firmware gets deployed. If we record them in the firmware descriptor, the management application doesn't need magic, it can simply pass on the values obtained from the descriptor. We'd want to include sector-length in the descriptor then, to ensure num-block has a defined meaning. Same technique could take care of width, big-endian, ... in case machine-type specific defaults turn out to be inadequate for them. Opinions? One more problem: the magic board code does a bit more than just configure the cfi.pflash01 device. That additional magic needs to be generalized to work regardless of whether the device gets configured with -drive if=pflash or with -device. I got a working prototype.

7 44

[libvirt] [PATCH v4 RESEND] openvswitch: Add new port VLAN mode "dot1q-tunnel"(802.1ad double-tagged)
by luzhipeng＠uniudc.com 13 Feb '19

13 Feb '19

From: ZhiPeng Lu <luzhipeng(a)uniudc.com> This patch adds functionality to allow libvirt to configure the 'dot1q-tunnel' modes(802.1ad double-tagged) on openvswitch networks. For example: <interface type='bridge'> <mac address='2c:da:41:1d:05:42'/> <source bridge='ovs0'/> <vlan> <tag id='41' nativeMode='dot1q-tunnel'/> </vlan> <virtualport type='openvswitch'> <parameters interfaceid='6401a152-0b99-40b5-92be-858810aa6d37'/> </virtualport> <model type='virtio'/> <driver name='vhost'/> <alias name='net0'/> </interface> Signed-off-by: ZhiPeng Lu <luzhipeng(a)uniudc.com> --- v1->v2: 1. Fix "make syntax-check" failure v2->v3: 1. remove other_config when updating vlan v3->v4: 1. add commit message that has a brief description of the new feature 2. add tests for 'dot1q-tunnel' vlan mode docs/formatdomain.html.in | 20 ++++++++++++++------ docs/formatnetwork.html.in | 20 +++++++++++--------- docs/schemas/networkcommon.rng | 1 + src/conf/netdev_vlan_conf.c | 2 +- src/util/virnetdevopenvswitch.c | 7 +++++++ src/util/virnetdevvlan.h | 1 + tests/networkxml2xmlin/openvswitch-net.xml | 9 +++++++++ tests/networkxml2xmlout/openvswitch-net.xml | 9 +++++++++ .../openvswitch-net-modified.xml | 9 +++++++++ .../openvswitch-net-more-portgroups.xml | 9 +++++++++ .../openvswitch-net-without-alice.xml | 9 +++++++++ 11 files changed, 80 insertions(+), 16 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 84259c4..ced21c0 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -6085,8 +6085,14 @@ qemu-kvm -net nic,model=? /dev/null <tag id='42'/> <tag id='123' nativeMode='untagged'/> </vlan> - ... </interface> + <interface type='bridge'> + <vlan trunk='yes'> + <tag id='42'/> + <tag id='123' nativeMode='dot1q-tunnel'/> + </vlan> + </interface> +... </devices> ...</pre> @@ -6122,11 +6128,13 @@ qemu-kvm -net nic,model=? /dev/null For network connections using Open vSwitch it is also possible - to configure 'native-tagged' and 'native-untagged' VLAN modes - Since 1.1.0. This is done with the - optional <code>nativeMode</code> attribute on - the <code><tag></code> subelement: <code>nativeMode</code> - may be set to 'tagged' or 'untagged'. The <code>id</code> + to configure 'native-tagged' and 'native-untagged' + Since 1.1.0. and 'dot1q-tunnel' + (802.1ad double-tagged) Since 5.0.0. + VLAN modes This is done with the optional <code>nativeMode</code> + attribute on the <code><tag></code> subelement: + <code>nativeMode</code> may be set to 'tagged' or 'untagged' or + 'dot1q-tunnel'. The <code>id</code> attribute of the <code><tag></code> subelement containing <code>nativeMode</code> sets which VLAN is considered to be the "native" VLAN for this interface, and diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index 363a72b..d9ac9f7 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -688,16 +688,18 @@ For network connections using Open vSwitch it is also possible - to configure 'native-tagged' and 'native-untagged' VLAN modes - Since 1.1.0. This is done with the - optional <code>nativeMode</code> attribute on - the <code><tag></code> subelement: <code>nativeMode</code> - may be set to 'tagged' or 'untagged'. The <code>id</code> - attribute of the <code><tag></code> subelement - containing <code>nativeMode</code> sets which VLAN is considered - to be the "native" VLAN for this interface, and + to configure 'native-tagged' and 'native-untagged' + Since 1.1.0. + and 'dot1q-tunnel'(802.1ad double-tagged) VLAN modes. + Since 5.0.0. This is done with the + optional <code>nativeMode</code> attribute on the + <code><tag></code> subelement: <code>nativeMode</code> + may be set to 'tagged' or 'untagged' or 'dot1q-tunnel'. + The <code>id</code> attribute of the <code><tag></code> + subelement containing <code>nativeMode</code> sets which VLAN is + considered to be the "native" VLAN for this interface, and the <code>nativeMode</code> attribute determines whether or not - traffic for that VLAN will be tagged. + traffic for that VLAN will be tagged or QinQ. <code><vlan></code> elements can also be specified in diff --git a/docs/schemas/networkcommon.rng b/docs/schemas/networkcommon.rng index 2699555..11c48ff 100644 --- a/docs/schemas/networkcommon.rng +++ b/docs/schemas/networkcommon.rng @@ -223,6 +223,7 @@ <choice> <value>tagged</value> <value>untagged</value> + <value>dot1q-tunnel</value> </choice> </attribute> </optional> diff --git a/src/conf/netdev_vlan_conf.c b/src/conf/netdev_vlan_conf.c index dff49c6..79710d9 100644 --- a/src/conf/netdev_vlan_conf.c +++ b/src/conf/netdev_vlan_conf.c @@ -29,7 +29,7 @@ #define VIR_FROM_THIS VIR_FROM_NONE VIR_ENUM_IMPL(virNativeVlanMode, VIR_NATIVE_VLAN_MODE_LAST, - "default", "tagged", "untagged") + "default", "tagged", "untagged", "dot1q-tunnel") int virNetDevVlanParse(xmlNodePtr node, xmlXPathContextPtr ctxt, virNetDevVlanPtr def) diff --git a/src/util/virnetdevopenvswitch.c b/src/util/virnetdevopenvswitch.c index 8fe06fd..2cc576f 100644 --- a/src/util/virnetdevopenvswitch.c +++ b/src/util/virnetdevopenvswitch.c @@ -91,6 +91,11 @@ virNetDevOpenvswitchConstructVlans(virCommandPtr cmd, virNetDevVlanPtr virtVlan) virCommandAddArg(cmd, "vlan_mode=native-untagged"); virCommandAddArgFormat(cmd, "tag=%d", virtVlan->nativeTag); break; + case VIR_NATIVE_VLAN_MODE_DOT1Q_TUNNEL: + virCommandAddArg(cmd, "vlan_mode=dot1q-tunnel"); + virCommandAddArg(cmd, "other_config:qinq-ethtype=802.1q"); + virCommandAddArgFormat(cmd, "tag=%d", virtVlan->nativeTag); + break; case VIR_NATIVE_VLAN_MODE_DEFAULT: default: break; @@ -504,6 +509,8 @@ int virNetDevOpenvswitchUpdateVlan(const char *ifname, "--", "--if-exists", "clear", "Port", ifname, "tag", "--", "--if-exists", "clear", "Port", ifname, "trunk", "--", "--if-exists", "clear", "Port", ifname, "vlan_mode", + "--", "--if-exists", "remove", "Port", ifname, "other_config", + "qinq-ethtype", "--", "--if-exists", "set", "Port", ifname, NULL); if (virNetDevOpenvswitchConstructVlans(cmd, virtVlan) < 0) diff --git a/src/util/virnetdevvlan.h b/src/util/virnetdevvlan.h index be85f59..0667f9d 100644 --- a/src/util/virnetdevvlan.h +++ b/src/util/virnetdevvlan.h @@ -29,6 +29,7 @@ typedef enum { VIR_NATIVE_VLAN_MODE_DEFAULT = 0, VIR_NATIVE_VLAN_MODE_TAGGED, VIR_NATIVE_VLAN_MODE_UNTAGGED, + VIR_NATIVE_VLAN_MODE_DOT1Q_TUNNEL, VIR_NATIVE_VLAN_MODE_LAST } virNativeVlanMode; diff --git a/tests/networkxml2xmlin/openvswitch-net.xml b/tests/networkxml2xmlin/openvswitch-net.xml index 2f6084d..0952859 100644 --- a/tests/networkxml2xmlin/openvswitch-net.xml +++ b/tests/networkxml2xmlin/openvswitch-net.xml @@ -30,4 +30,13 @@ <parameters profileid='native-profile'/> </virtualport> </portgroup> + <portgroup name='8021ad'> + <vlan trunk='yes'> + <tag id='555' nativeMode='dot1q-tunnel'/> + <tag id='666'/> + </vlan> + <virtualport> + <parameters profileid='8021ad-profile'/> + </virtualport> + </portgroup> </network> diff --git a/tests/networkxml2xmlout/openvswitch-net.xml b/tests/networkxml2xmlout/openvswitch-net.xml index 2f6084d..0952859 100644 --- a/tests/networkxml2xmlout/openvswitch-net.xml +++ b/tests/networkxml2xmlout/openvswitch-net.xml @@ -30,4 +30,13 @@ <parameters profileid='native-profile'/> </virtualport> </portgroup> + <portgroup name='8021ad'> + <vlan trunk='yes'> + <tag id='555' nativeMode='dot1q-tunnel'/> + <tag id='666'/> + </vlan> + <virtualport> + <parameters profileid='8021ad-profile'/> + </virtualport> + </portgroup> </network> diff --git a/tests/networkxml2xmlupdateout/openvswitch-net-modified.xml b/tests/networkxml2xmlupdateout/openvswitch-net-modified.xml index cc0c344..e5794fc 100644 --- a/tests/networkxml2xmlupdateout/openvswitch-net-modified.xml +++ b/tests/networkxml2xmlupdateout/openvswitch-net-modified.xml @@ -30,4 +30,13 @@ <parameters profileid='native-profile'/> </virtualport> </portgroup> + <portgroup name='8021ad'> + <vlan trunk='yes'> + <tag id='555' nativeMode='dot1q-tunnel'/> + <tag id='666'/> + </vlan> + <virtualport> + <parameters profileid='8021ad-profile'/> + </virtualport> + </portgroup> </network> diff --git a/tests/networkxml2xmlupdateout/openvswitch-net-more-portgroups.xml b/tests/networkxml2xmlupdateout/openvswitch-net-more-portgroups.xml index 7c19ad9..3df0b96 100644 --- a/tests/networkxml2xmlupdateout/openvswitch-net-more-portgroups.xml +++ b/tests/networkxml2xmlupdateout/openvswitch-net-more-portgroups.xml @@ -41,4 +41,13 @@ <parameters profileid='native-profile'/> </virtualport> </portgroup> + <portgroup name='8021ad'> + <vlan trunk='yes'> + <tag id='555' nativeMode='dot1q-tunnel'/> + <tag id='666'/> + </vlan> + <virtualport> + <parameters profileid='8021ad-profile'/> + </virtualport> + </portgroup> </network> diff --git a/tests/networkxml2xmlupdateout/openvswitch-net-without-alice.xml b/tests/networkxml2xmlupdateout/openvswitch-net-without-alice.xml index 4104424..38846aa 100644 --- a/tests/networkxml2xmlupdateout/openvswitch-net-without-alice.xml +++ b/tests/networkxml2xmlupdateout/openvswitch-net-without-alice.xml @@ -20,4 +20,13 @@ <parameters profileid='native-profile'/> </virtualport> </portgroup> + <portgroup name='8021ad'> + <vlan trunk='yes'> + <tag id='555' nativeMode='dot1q-tunnel'/> + <tag id='666'/> + </vlan> + <virtualport> + <parameters profileid='8021ad-profile'/> + </virtualport> + </portgroup> </network> -- 1.8.3.1

2 1

[libvirt] [PATCH 0/2] A couple of capabilities related adjustments
by John Ferlan 08 Feb '19

08 Feb '19

Peeling the onion in my series to update the QEMU capabilites replies: https://www.redhat.com/archives/libvir-list/2019-January/msg00793.html resulted in consideration of a possible alternative to how the SEV capability checking "works". As it turns out, the initial changes "massaged" the .replies output to add a "fake" reply on an Intel CPU for what amounts to AMD specific output. This naturally resulted in a "problem" when the next batch of a capabilites was created and there was no sev output, so an adjustment was made to limit what was tested to one capabilities version. Since there isn't separate Intel/AMD x86_64 output, the first patch in the series will alter the return for virQEMUCapsProbeQMPSEVCapabilities so that 0 would "change" into 1 for the mocked environment and allow the sev-guest bit to be set which allows QEMU_CAPS_SEV_GUEST to be set for any x86_64 arch environment. This only affects how qemuxml2argvtest handles generation of DO_TEST_CAPS_LATEST for launch-security-sev. The XML generated isn't modified, nor is the reply output data since that's separate. The key is the "0" return meaning a GenericError which is assumed to be returned when compiled-in support for SEV isn't there, but *could* be if the underlying hardware arch supported it. For the test purpose we have, that doesn't matter unless someone wants to go through the trouble of separating the caps*.replies files into "Intel" and "AMD" specific output. So yes a "workaround" of sorts, but nonetheless an alternative to the current static checking of what's been deemed incorrect reply data. The second somewhat unrelated patch is fallout of the review discussion about having a consistent process. I suspect it's a "starting point" from which we can evolve to create a consistent/repeatable process to create caps*.replies. John Ferlan (2): tests: Add mocking for qemuMonitorJSONGetSEVCapabilities tests: Document procedure to build QEMU for *.replies generation tests/qemucapabilitiestest.c | 34 ++++++++++++- tests/qemucapsprobemock.c | 50 +++++++++++++++++++ ...=> launch-security-sev.x86_64-latest.args} | 0 tests/qemuxml2argvtest.c | 2 +- 4 files changed, 83 insertions(+), 3 deletions(-) rename tests/qemuxml2argvdata/{launch-security-sev.x86_64-2.12.0.args => launch-security-sev.x86_64-latest.args} (100%) -- 2.20.1

4 8

[libvirt] [PATCH 0/3] bhyve: implement MSRs ignore unknown writes feature
by Roman Bogorodskiy 07 Feb '19

07 Feb '19

Roman Bogorodskiy (3): conf: introduce 'msrs' feature bhyve: implement MSRs ignore unknown writes feature news: document bhyve msrs feature docs/drvbhyve.html.in | 16 +++++++++ docs/formatdomain.html.in | 1 + docs/news.xml | 11 ++++++ docs/schemas/domaincommon.rng | 14 ++++++++ src/bhyve/bhyve_command.c | 4 +++ src/conf/domain_conf.c | 33 +++++++++++++++++ src/conf/domain_conf.h | 8 +++++ src/qemu/qemu_domain.c | 1 + .../bhyvexml2argvdata/bhyvexml2argv-msrs.args | 10 ++++++ .../bhyvexml2argv-msrs.ldargs | 3 ++ .../bhyvexml2argvdata/bhyvexml2argv-msrs.xml | 26 ++++++++++++++ tests/bhyvexml2argvtest.c | 1 + .../bhyvexml2xmlout-msrs.xml | 36 +++++++++++++++++++ tests/bhyvexml2xmltest.c | 1 + 14 files changed, 165 insertions(+) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-msrs.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-msrs.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-msrs.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-msrs.xml -- 2.20.1

3 8

[libvirt] [PATCH 0/4] qemu: clean up qemuDomainBlockJobAbort/Pivot (blockdev-add saga)
by Peter Krempa 07 Feb '19

07 Feb '19

Peter Krempa (4): qemu: Always save status XML in qemuDomainBlockJobAbort qemu: Move shareable disk check for block copy qemu: Remove unused 'cfg' qemuDomainBlockPivot qemu: Use data in qemuBlockJobDataPtr instead of re-generating job name src/qemu/qemu_driver.c | 46 +++++++++++++++--------------------------- 1 file changed, 16 insertions(+), 30 deletions(-) -- 2.20.1

2 8

[libvirt] [PATCH 0/5] Couple of LXC fixes
by Michal Privoznik 07 Feb '19

07 Feb '19

*** BLURB HERE *** Michal Prívozník (5): lxc: Use correct job type for destroying a domain vircgroup: Try harder to kill cgroup lxc: Restore seclabels after the container is killed virinitctl: Expose fifo paths and allow caller to chose one lxc: Don't reboot host on virDomainReboot src/libvirt_private.syms | 1 + src/lxc/lxc_domain.c | 77 ++++++++++++++++++++++++++++++++++++++++ src/lxc/lxc_domain.h | 4 +++ src/lxc/lxc_driver.c | 19 ++-------- src/lxc/lxc_process.c | 22 ++++++------ src/util/vircgroup.c | 15 ++++---- src/util/virinitctl.c | 66 +++++++++++++++++++++------------- src/util/virinitctl.h | 6 +++- 8 files changed, 152 insertions(+), 58 deletions(-) -- 2.19.2

3 12

[libvirt] [PATCH] conf: Remove iothreads restriction in virDomainDefCheckABIStabilityFlags
by Jie Wang 06 Feb '19

06 Feb '19

The number of iothreads is not part of the vm state sent during migration, nor exposed to the guest ABI, so this restriction is a mistaken in libvirt. Let's remove that bit of code. Signed-off-by: Jie Wang <wangjie88(a)huawei.com> --- src/conf/domain_conf.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index ae8fb5a501..ac4eeaec5e 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -22927,14 +22927,6 @@ virDomainDefCheckABIStabilityFlags(virDomainDefPtr src, if (!virDomainDefVcpuCheckAbiStability(src, dst)) goto error; - if (src->niothreadids != dst->niothreadids) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("Target domain iothreads count %zu does not " - "match source %zu"), - dst->niothreadids, src->niothreadids); - goto error; - } - if (src->os.type != dst->os.type) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Target domain OS type %s does not match source %s"), -- 2.16.2.windows.1

2 1

[libvirt] [PATCH] storage: fix volume perms when it is not specified.
by Julio Faracco 06 Feb '19

06 Feb '19

This commit adds permissions inheritance to volume from main pool when it is not explicitly added by command or XML definition. It permissions are defined into XML, they should be respected. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=677242 Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com> --- src/storage/storage_driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 4a13e90481..5961d35f26 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -1850,6 +1850,16 @@ storageVolCreateXML(virStoragePoolPtr pool, goto cleanup; } + /* Inherit perms and mode from pool when they are not defined. */ + if (voldef->target.perms->uid == (uid_t)-1) + voldef->target.perms->uid = def->target.perms.uid; + + if (voldef->target.perms->gid == (gid_t)-1) + voldef->target.perms->gid = def->target.perms.gid; + + if (voldef->target.perms->mode == (mode_t)-1) + voldef->target.perms->mode = def->target.perms.mode; + if (virStorageVolCreateXMLEnsureACL(pool->conn, def, voldef) < 0) goto cleanup; -- 2.19.1

3 2