[libvirt] AMD SEV's /dev/sev permissions and probing QEMU for capabilities
by Erik Skultety
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
6 years, 1 month
[libvirt] [PATCH for-4.0 v4 0/2] virtio: Provide version-specific variants of virtio PCI devices
by Eduardo Habkost
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
6 years, 1 month
[libvirt] Configuring pflash devices for OVMF firmware
by Markus Armbruster
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<U>, 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.
6 years, 1 month
[libvirt] [PATCH v4 RESEND] openvswitch: Add new port VLAN mode "dot1q-tunnel"(802.1ad double-tagged)
by luzhipeng＠uniudc.com
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
<b><tag id='42'/></b>
<b><tag id='123' nativeMode='untagged'/></b>
<b></vlan></b>
- ...
</interface>
+ <interface type='bridge'>
+ <b><vlan trunk='yes'></b>
+ <b><tag id='42'/></b>
+ <b><tag id='123' nativeMode='dot1q-tunnel'/></b>
+ <b></vlan></b>
+ </interface>
+...
</devices>
...</pre>
@@ -6122,11 +6128,13 @@ qemu-kvm -net nic,model=? /dev/null
</p>
<p>
For network connections using Open vSwitch it is also possible
- to configure 'native-tagged' and 'native-untagged' VLAN modes
- <span class="since">Since 1.1.0.</span> 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'
+ <span class="since">Since 1.1.0.</span> and 'dot1q-tunnel'
+ (802.1ad double-tagged) <span class="since">Since 5.0.0.</span>
+ 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 @@
</p>
<p>
For network connections using Open vSwitch it is also possible
- to configure 'native-tagged' and 'native-untagged' VLAN modes
- <span class="since">Since 1.1.0.</span> 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'
+ <span class="since">Since 1.1.0.</span>
+ and 'dot1q-tunnel'(802.1ad double-tagged) VLAN modes.
+ <span class="since">Since 5.0.0.</span> 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.
</p>
<p>
<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
6 years, 2 months
[libvirt] [PATCH 0/2] A couple of capabilities related adjustments
by John Ferlan
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
6 years, 2 months
[libvirt] [PATCH 0/3] bhyve: implement MSRs ignore unknown writes feature
by Roman Bogorodskiy
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
6 years, 2 months
[libvirt] [PATCH 0/4] qemu: clean up qemuDomainBlockJobAbort/Pivot (blockdev-add saga)
by Peter Krempa
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
6 years, 2 months
[libvirt] [PATCH 0/5] Couple of LXC fixes
by Michal Privoznik
*** 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
6 years, 2 months
[libvirt] [PATCH] conf: Remove iothreads restriction in virDomainDefCheckABIStabilityFlags
by Jie Wang
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
6 years, 2 months
[libvirt] [PATCH] storage: fix volume perms when it is not specified.
by Julio Faracco
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
6 years, 2 months
