[libvirt] [PATCH 0/2] Couple of test_driver fixes
by Michal Privoznik
I was too eager to minimize patch 89320788ac4 and did some mistakes.
Here are the fixes.
Michal Prívozník (2):
test_driver: Don't access @vm after it was set to NULL
test_driver: Don't report VIR_DOMAIN_DISK_ERROR_NONE
src/test/test_driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.21.0
5 years, 4 months
[libvirt] [PATCH v2 8/9] docs: Deprecate CPU model runnability guarantees
by Eduardo Habkost
Document that CPU model runnability guarantees won't apply to
unversioned CPU models anymore.
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
Changes v1 -> v2:
* (none)
Cc: libvir-list(a)redhat.com
---
qemu-deprecated.texi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 9cba82d5ec..18f85f70e1 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -276,3 +276,22 @@ Note that if you are exposing the export via /dev/nbd0, it is easier
to just export the entire image and then mount only /dev/nbd0p1 than
it is to reinvoke @command{qemu-nbd -c /dev/nbd0} limited to just a
subset of the image.
+
+@section Backwards compatibility
+
+@subsection Runnability guarantee of CPU models (since 4.1.0)
+
+Previous versions of QEMU never changed existing CPU models in
+ways that introduced additional host software or hardware
+requirements to the VM. This allowed management software to
+safely change the machine type of an existing VM without
+introducing new requirements ("runnability guarantee"). This
+prevented CPU models from being updated to include CPU
+vulnerability mitigations, leaving guests vulnerable in the
+default configuration.
+
+The CPU model runnability guarantee won't apply anymore to
+existing CPU models. Management software that needs runnability
+guarantees must resolve the CPU model aliases using te
+``alias-of'' field returned by the ``query-cpu-definitions'' QMP
+command.
--
2.18.0.rc1.1.g3f1ff2140
5 years, 4 months
[libvirt] mdevctl: A shoestring mediated device management and persistence utility
by Alex Williamson
Hi,
Currently mediated device management, much like SR-IOV VF management,
is largely left as an exercise for the user. This is an attempt to
provide something and see where it goes. I doubt we'll solve
everyone's needs on the first pass, but maybe we'll solve enough and
provide helpers for the rest. Without further ado, I'll point to what
I have so far:
https://github.com/awilliam/mdevctl
This is inspired by driverctl, which is also a bash utility. mdevctl
uses udev and systemd to record and recreate mdev devices for
persistence and provides a command line utility for querying, listing,
starting, stopping, adding, and removing mdev devices. Currently, for
better or worse, it considers anything created to be persistent. I can
imagine a global configuration option that might disable this and
perhaps an autostart flag per mdev device, such that mdevctl might
simply "know" about some mdevs but not attempt to create them
automatically. Clearly command line usage help, man pages, and
packaging are lacking as well, release early, release often, plus this
is a discussion starter to see if perhaps this is sufficient to meet
some needs.
Originally I thought about making a utility to manage both mdev and
SR-IOV VFs all in one, but it seemed more natural to start here
(besides, I couldn't think of a good name for the combined utility).
If this seems useful, maybe I'll start on a vfctl for SR-IOV and we'll
see whether they have enough synergy to become one.
It would be really useful if s390 folks could help me understand
whether it's possible to glean all the information necessary to
recreate a ccw or ap mdev device from sysfs. I expect the file where
we currently only store the mdev_type to evolve into something that
includes more information to facilitate more complicated devices. For
now I make no claims to maintaining compatibility of recorded mdev
devices, it will absolutely change, but I didn't want to get bogged
down in making sure I don't accidentally source a root kit hidden in an
mdev config file.
I'm also curious how or if libvirt or openstack might use this. If
nothing else, it makes libvirt hook scripts easier to write, especially
if we add an option not to autostart mdevs, or if users don't mind
persistent mdevs, maybe there's nothing more to do.
BTW, feel free to clean up by bash, I'm a brute force and ignorance
shell coder ;) Thanks,
Alex
5 years, 4 months
[libvirt] [PATCH v2] test_driver: implement virDomainGetNumaParameters
by Ilias Stamatis
Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com>
---
src/test/test_driver.c | 52 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 4b1f2724a0..dc6d3b078c 100755
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -2405,6 +2405,57 @@ testDomainCoreDump(virDomainPtr domain,
}
+static int
+testDomainGetNumaParameters(virDomainPtr dom,
+ virTypedParameterPtr params,
+ int *nparams,
+ unsigned int flags)
+{
+ virDomainObjPtr vm = NULL;
+ virDomainDefPtr def = NULL;
+ virDomainNumatuneMemMode mode = VIR_DOMAIN_NUMATUNE_MEM_STRICT;
+ VIR_AUTOFREE(char *) nodeset = NULL;
+ int ret = -1;
+
+ virCheckFlags(VIR_DOMAIN_AFFECT_LIVE |
+ VIR_DOMAIN_AFFECT_CONFIG |
+ VIR_TYPED_PARAM_STRING_OKAY, -1);
+
+ if ((*nparams) == 0) {
+ *nparams = 2;
+ return 0;
+ }
+
+ if (!(vm = testDomObjFromDomain(dom)))
+ goto cleanup;
+
+ if (!(def = virDomainObjGetOneDef(vm, flags)))
+ goto cleanup;
+
+ ignore_value(virDomainNumatuneGetMode(def->numa, -1, &mode));
+ if (*nparams > 0 &&
+ virTypedParameterAssign(¶ms[0], VIR_DOMAIN_NUMA_MODE, VIR_TYPED_PARAM_INT, mode) < 0)
+ goto cleanup;
+
+ nodeset = virDomainNumatuneFormatNodeset(def->numa, NULL, -1);
+ if (*nparams > 1 && (!nodeset ||
+ virTypedParameterAssign(¶ms[1],
+ VIR_DOMAIN_NUMA_NODESET,
+ VIR_TYPED_PARAM_STRING,
+ nodeset) < 0))
+ goto cleanup;
+ nodeset = NULL;
+
+ if (*nparams > 2)
+ *nparams = 2;
+
+ ret = 0;
+ cleanup:
+ virDomainObjEndAPI(&vm);
+ return ret;
+}
+
+
static char *
testDomainGetOSType(virDomainPtr dom ATTRIBUTE_UNUSED)
{
@@ -7251,6 +7302,7 @@ static virHypervisorDriver testHypervisorDriver = {
.domainReboot = testDomainReboot, /* 0.1.1 */
.domainDestroy = testDomainDestroy, /* 0.1.1 */
.domainDestroyFlags = testDomainDestroyFlags, /* 4.2.0 */
+ .domainGetNumaParameters = testDomainGetNumaParameters, /* 5.6.0 */
.domainGetOSType = testDomainGetOSType, /* 0.1.9 */
.domainGetLaunchSecurityInfo = testDomainGetLaunchSecurityInfo, /* 5.5.0 */
.domainGetMaxMemory = testDomainGetMaxMemory, /* 0.1.4 */
--
2.22.0
5 years, 4 months
[libvirt] [PATCH] docs: fix acl permission docs
by Ján Tomko
We have been grouping network-port and nwfilter-binding permissions
under virNetworkPtr and virNWFilterPtr respectively.
Add the two missing classes that were matched because they contain
a substring of others.
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
docs/genaclperms.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/genaclperms.pl b/docs/genaclperms.pl
index d878321a90..34c526021c 100755
--- a/docs/genaclperms.pl
+++ b/docs/genaclperms.pl
@@ -22,7 +22,8 @@ use warnings;
my @objects = (
"CONNECT", "DOMAIN", "INTERFACE",
- "NETWORK","NODE_DEVICE", "NWFILTER",
+ "NETWORK_PORT", "NETWORK", "NODE_DEVICE",
+ "NWFILTER_BINDING", "NWFILTER",
"SECRET", "STORAGE_POOL", "STORAGE_VOL",
);
--
2.20.1
5 years, 4 months
[libvirt] [PATCH] test_driver: virDomainGetPerfEvents
by Ilias Stamatis
Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com>
---
src/test/test_driver.c | 48 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 4b1f2724a0..215171839c 100755
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -3293,6 +3293,53 @@ static int testDomainGetDiskErrors(virDomainPtr dom,
return ret;
}
+
+static int
+testDomainGetPerfEvents(virDomainPtr dom,
+ virTypedParameterPtr *params,
+ int *nparams,
+ unsigned int flags)
+{
+ virDomainObjPtr vm = NULL;
+ virDomainDefPtr def = NULL;
+ virTypedParameterPtr par = NULL;
+ size_t i;
+ int maxpar = 0;
+ int npar = 0;
+ int ret = -1;
+
+ virCheckFlags(VIR_DOMAIN_AFFECT_LIVE |
+ VIR_DOMAIN_AFFECT_CONFIG |
+ VIR_TYPED_PARAM_STRING_OKAY, -1);
+
+ if (!(vm = testDomObjFromDomain(dom)))
+ goto cleanup;
+
+ if (virDomainObjUpdateModificationImpact(vm, &flags) < 0)
+ goto cleanup;
+
+ if (!(def = virDomainObjGetOneDef(vm, flags)))
+ goto cleanup;
+
+ for (i = 0; i < VIR_PERF_EVENT_LAST; i++) {
+ if (virTypedParamsAddBoolean(&par, &npar, &maxpar,
+ virPerfEventTypeToString(i),
+ def->perf.events[i] == VIR_TRISTATE_BOOL_YES) < 0)
+ goto cleanup;
+ }
+
+ VIR_STEAL_PTR(*params, par);
+ *nparams = npar;
+ npar = 0;
+
+ ret = 0;
+ cleanup:
+ virDomainObjEndAPI(&vm);
+ virTypedParamsFree(par, npar);
+ return ret;
+}
+
+
static char *testDomainGetSchedulerType(virDomainPtr domain ATTRIBUTE_UNUSED,
int *nparams)
{
@@ -7287,6 +7334,7 @@ static virHypervisorDriver testHypervisorDriver = {
.domainGetAutostart = testDomainGetAutostart, /* 0.3.2 */
.domainSetAutostart = testDomainSetAutostart, /* 0.3.2 */
.domainGetDiskErrors = testDomainGetDiskErrors, /* 5.4.0 */
+ .domainGetPerfEvents = testDomainGetPerfEvents, /* 5.6.0 */
.domainGetSchedulerType = testDomainGetSchedulerType, /* 0.3.2 */
.domainGetSchedulerParameters = testDomainGetSchedulerParameters, /* 0.3.2 */
.domainGetSchedulerParametersFlags = testDomainGetSchedulerParametersFlags, /* 0.9.2 */
--
2.22.0
5 years, 4 months
[libvirt] [PATCH] qemu: add bochs-display device
by Jonathon Jongsma
qemu provides the bochs-display video device since 3.0. This patch adds
support for this device in libvirt. See Gerd's post for more details:
https://www.kraxel.org/blog/2018/10/qemu-vga-emulation-and-bochs-display/
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1643404
Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com>
---
Note that the documentation may need to be changed depending on which version the patch makes it
into. I suppose it'll miss 5.5.0 since we're in freeze right now.
Note: depending on which distribution you're using, you may need to copy the vgabios into place in
order to test. For example:
$ sudo ln -s /path/to/qemu/pc-bios/vgabios-bochs-display.bin /usr/share/qemu/
docs/formatdomain.html.in | 5 +--
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 2 ++
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 4 +++
src/qemu/qemu_capabilities.h | 3 ++
src/qemu/qemu_command.c | 18 +++++++----
src/qemu/qemu_domain.c | 1 +
src/qemu/qemu_domain_address.c | 1 +
.../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 1 +
.../caps_3.0.0.x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 1 +
.../caps_3.1.0.x86_64.xml | 1 +
.../caps_4.0.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 +
.../caps_4.0.0.riscv32.xml | 1 +
.../caps_4.0.0.riscv64.xml | 1 +
.../caps_4.0.0.x86_64.xml | 1 +
.../caps_4.1.0.x86_64.xml | 1 +
.../video-bochs-display-device.args | 32 +++++++++++++++++++
.../video-bochs-display-device.xml | 29 +++++++++++++++++
tests/qemuxml2argvtest.c | 3 ++
22 files changed, 102 insertions(+), 8 deletions(-)
create mode 100644 tests/qemuxml2argvdata/video-bochs-display-device.args
create mode 100644 tests/qemuxml2argvdata/video-bochs-display-device.xml
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index a7a6ec32a5..9298ee7b16 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -6990,8 +6990,9 @@ qemu-kvm -net nic,model=? /dev/null
attribute which takes the value "vga", "cirrus", "vmvga", "xen",
"vbox", "qxl" (<span class="since">since 0.8.6</span>),
"virtio" (<span class="since">since 1.3.0</span>),
- "gop" (<span class="since">since 3.2.0</span>), or
- "none" (<span class="since">since 4.6.0</span>)
+ "gop" (<span class="since">since 3.2.0</span>),
+ "none" (<span class="since">since 4.6.0</span>, or "bochs-display"
+ (<span class="since">since 5.5.0</span>)
depending on the hypervisor features available.
The purpose of the type <code>none</code> is to instruct libvirt not
to add a default video device in the guest (see the paragraph above).
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 31db599ab9..2ccb393432 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -3584,6 +3584,7 @@
<value>virtio</value>
<value>gop</value>
<value>none</value>
+ <value>bochs-display</value>
</choice>
</attribute>
<group>
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 3323c9a5b1..f6da230c18 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -738,6 +738,7 @@ VIR_ENUM_IMPL(virDomainVideo,
"virtio",
"gop",
"none",
+ "bochs-display",
);
VIR_ENUM_IMPL(virDomainVideoVGAConf,
@@ -15158,6 +15159,7 @@ virDomainVideoDefaultRAM(const virDomainDef *def,
case VIR_DOMAIN_VIDEO_TYPE_VGA:
case VIR_DOMAIN_VIDEO_TYPE_CIRRUS:
case VIR_DOMAIN_VIDEO_TYPE_VMVGA:
+ case VIR_DOMAIN_VIDEO_TYPE_BOCHS_DISPLAY:
if (def->virtType == VIR_DOMAIN_VIRT_VBOX)
return 8 * 1024;
else if (def->virtType == VIR_DOMAIN_VIRT_VMWARE)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index c1b5fc1337..e8e468426b 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1385,6 +1385,7 @@ typedef enum {
VIR_DOMAIN_VIDEO_TYPE_VIRTIO,
VIR_DOMAIN_VIDEO_TYPE_GOP,
VIR_DOMAIN_VIDEO_TYPE_NONE,
+ VIR_DOMAIN_VIDEO_TYPE_BOCHS_DISPLAY,
VIR_DOMAIN_VIDEO_TYPE_LAST
} virDomainVideoType;
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 02e84edc15..ec68d05112 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -533,6 +533,9 @@ VIR_ENUM_IMPL(virQEMUCaps,
"x86-max-cpu",
"cpu-unavailable-features",
"canonical-cpu-features",
+
+ /* 330 */
+ "bochs-display",
);
@@ -1121,6 +1124,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "virtio-serial-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-serial-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "max-x86_64-cpu", QEMU_CAPS_X86_MAX_CPU },
+ { "bochs-display", QEMU_CAPS_DEVICE_BOCHS_DISPLAY },
};
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioBalloon[] = {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 915ba6cb2e..3cb56e63f4 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -515,6 +515,9 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check */
QEMU_CAPS_CPU_UNAVAILABLE_FEATURES, /* "unavailable-features" CPU property */
QEMU_CAPS_CANONICAL_CPU_FEATURES, /* avoid CPU feature aliases */
+ /* 335 */
+ QEMU_CAPS_DEVICE_BOCHS_DISPLAY, /* -device bochs-display */
+
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 688dc324c6..5455b42f4a 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -111,6 +111,7 @@ VIR_ENUM_IMPL(qemuVideo,
"", /* no need for virtio */
"" /* don't support gop */,
"" /* 'none' doesn't make sense here */,
+ "bochs-display",
);
VIR_ENUM_DECL(qemuDeviceVideo);
@@ -128,6 +129,7 @@ VIR_ENUM_IMPL(qemuDeviceVideo,
"virtio-vga",
"" /* don't support gop */,
"" /* 'none' doesn't make sense here */,
+ "bochs-display",
);
VIR_ENUM_DECL(qemuDeviceVideoSecondary);
@@ -145,6 +147,7 @@ VIR_ENUM_IMPL(qemuDeviceVideoSecondary,
"virtio-gpu",
"" /* don't support gop */,
"" /* 'none' doesn't make sense here */,
+ "bochs-display",
);
VIR_ENUM_DECL(qemuSoundCodec);
@@ -4748,13 +4751,16 @@ qemuBuildDeviceVideoStr(const virDomainDef *def,
if (video->heads)
virBufferAsprintf(&buf, ",max_outputs=%u", video->heads);
}
- } else if (video->vram &&
- ((video->type == VIR_DOMAIN_VIDEO_TYPE_VGA &&
- virQEMUCapsGet(qemuCaps, QEMU_CAPS_VGA_VGAMEM)) ||
- (video->type == VIR_DOMAIN_VIDEO_TYPE_VMVGA &&
- virQEMUCapsGet(qemuCaps, QEMU_CAPS_VMWARE_SVGA_VGAMEM)))) {
+ } else if (video->vram) {
+ if ((video->type == VIR_DOMAIN_VIDEO_TYPE_VGA &&
+ virQEMUCapsGet(qemuCaps, QEMU_CAPS_VGA_VGAMEM)) ||
+ (video->type == VIR_DOMAIN_VIDEO_TYPE_VMVGA &&
+ virQEMUCapsGet(qemuCaps, QEMU_CAPS_VMWARE_SVGA_VGAMEM))) {
- virBufferAsprintf(&buf, ",vgamem_mb=%u", video->vram / 1024);
+ virBufferAsprintf(&buf, ",vgamem_mb=%u", video->vram / 1024);
+ } else if (video->type == VIR_DOMAIN_VIDEO_TYPE_BOCHS_DISPLAY) {
+ virBufferAsprintf(&buf, ",vgamem=%uk", video->vram);
+ }
}
if (qemuBuildDeviceAddressStr(&buf, def, &video->info, qemuCaps) < 0)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index d71d9b3273..4e7ed45ff9 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4969,6 +4969,7 @@ qemuDomainDeviceDefValidateVideo(const virDomainVideoDef *video)
case VIR_DOMAIN_VIDEO_TYPE_VMVGA:
case VIR_DOMAIN_VIDEO_TYPE_QXL:
case VIR_DOMAIN_VIDEO_TYPE_VIRTIO:
+ case VIR_DOMAIN_VIDEO_TYPE_BOCHS_DISPLAY:
case VIR_DOMAIN_VIDEO_TYPE_LAST:
break;
}
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 4b99e8ca93..677a3f0499 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -929,6 +929,7 @@ qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
case VIR_DOMAIN_VIDEO_TYPE_VBOX:
case VIR_DOMAIN_VIDEO_TYPE_QXL:
case VIR_DOMAIN_VIDEO_TYPE_PARALLELS:
+ case VIR_DOMAIN_VIDEO_TYPE_BOCHS_DISPLAY:
return pciFlags;
case VIR_DOMAIN_VIDEO_TYPE_DEFAULT:
diff --git a/tests/qemucapabilitiesdata/caps_3.0.0.ppc64.xml b/tests/qemucapabilitiesdata/caps_3.0.0.ppc64.xml
index 40718981a8..61be1df782 100644
--- a/tests/qemucapabilitiesdata/caps_3.0.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_3.0.0.ppc64.xml
@@ -151,6 +151,7 @@
<flag name='memory-backend-memfd.hugetlb'/>
<flag name='iothread.poll-max-ns'/>
<flag name='memory-backend-file.align'/>
+ <flag name='bochs-display'/>
<version>2012050</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900757</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml
index c6394db602..7a322030bd 100644
--- a/tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml
@@ -198,6 +198,7 @@
<flag name='memory-backend-file.align'/>
<flag name='nvdimm.unarmed'/>
<flag name='x86-max-cpu'/>
+ <flag name='bochs-display'/>
<version>3000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100757</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_3.1.0.ppc64.xml b/tests/qemucapabilitiesdata/caps_3.1.0.ppc64.xml
index ee6921ff92..400dc45be4 100644
--- a/tests/qemucapabilitiesdata/caps_3.1.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_3.1.0.ppc64.xml
@@ -156,6 +156,7 @@
<flag name='memory-backend-file.align'/>
<flag name='memory-backend-file.pmem'/>
<flag name='overcommit'/>
+ <flag name='bochs-display'/>
<version>3000091</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900758</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_3.1.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_3.1.0.x86_64.xml
index a8cb061bf3..434c644ad4 100644
--- a/tests/qemucapabilitiesdata/caps_3.1.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_3.1.0.x86_64.xml
@@ -201,6 +201,7 @@
<flag name='nvdimm.unarmed'/>
<flag name='overcommit'/>
<flag name='x86-max-cpu'/>
+ <flag name='bochs-display'/>
<version>3000092</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100758</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml b/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml
index 250b7edd52..8fe369f518 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml
@@ -163,6 +163,7 @@
<flag name='machine.virt.iommu'/>
<flag name='bitmap-merge'/>
<flag name='nbd-bitmap'/>
+ <flag name='bochs-display'/>
<version>4000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>61700758</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml b/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml
index 24b55002a6..2df230c4f7 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml
@@ -168,6 +168,7 @@
<flag name='query-current-machine'/>
<flag name='bitmap-merge'/>
<flag name='nbd-bitmap'/>
+ <flag name='bochs-display'/>
<version>4000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900758</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml b/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml
index 230e1e7c99..f4acda457a 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml
@@ -166,6 +166,7 @@
<flag name='query-current-machine'/>
<flag name='bitmap-merge'/>
<flag name='nbd-bitmap'/>
+ <flag name='bochs-display'/>
<version>4000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>0</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml b/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml
index 4b2f4cf628..e71d83ee06 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml
@@ -166,6 +166,7 @@
<flag name='query-current-machine'/>
<flag name='bitmap-merge'/>
<flag name='nbd-bitmap'/>
+ <flag name='bochs-display'/>
<version>4000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>0</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml
index 716b756979..1d44a5a1ba 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml
@@ -205,6 +205,7 @@
<flag name='bitmap-merge'/>
<flag name='nbd-bitmap'/>
<flag name='x86-max-cpu'/>
+ <flag name='bochs-display'/>
<version>4000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100758</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml
index 9cbf65b405..f336aeb48c 100644
--- a/tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml
@@ -207,6 +207,7 @@
<flag name='x86-max-cpu'/>
<flag name='cpu-unavailable-features'/>
<flag name='canonical-cpu-features'/>
+ <flag name='bochs-display'/>
<version>4000050</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100759</microcodeVersion>
diff --git a/tests/qemuxml2argvdata/video-bochs-display-device.args b/tests/qemuxml2argvdata/video-bochs-display-device.args
new file mode 100644
index 0000000000..f88e9ccb04
--- /dev/null
+++ b/tests/qemuxml2argvdata/video-bochs-display-device.args
@@ -0,0 +1,32 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/tmp/lib/domain--1-QEMUGuest1 \
+USER=test \
+LOGNAME=test \
+XDG_DATA_HOME=/tmp/lib/domain--1-QEMUGuest1/.local/share \
+XDG_CACHE_HOME=/tmp/lib/domain--1-QEMUGuest1/.cache \
+XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-i686 \
+-name QEMUGuest1 \
+-S \
+-machine pc,accel=tcg,usb=off,dump-guest-core=off \
+-m 1024 \
+-realtime mlock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\
+server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-no-acpi \
+-usb \
+-drive file=/var/lib/libvirt/images/QEMUGuest1,format=qcow2,if=none,\
+id=drive-ide0-0-0,cache=none \
+-device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 \
+-device bochs-display,id=video0,vgamem=16384k,bus=pci.0,addr=0x2 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
diff --git a/tests/qemuxml2argvdata/video-bochs-display-device.xml b/tests/qemuxml2argvdata/video-bochs-display-device.xml
new file mode 100644
index 0000000000..f64fed4c7e
--- /dev/null
+++ b/tests/qemuxml2argvdata/video-bochs-display-device.xml
@@ -0,0 +1,29 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory unit='KiB'>1048576</memory>
+ <currentMemory unit='KiB'>1048576</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='i686' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-i686</emulator>
+ <disk type='file' device='disk'>
+ <driver name='qemu' type='qcow2' cache='none'/>
+ <source file='/var/lib/libvirt/images/QEMUGuest1'/>
+ <target dev='hda' bus='ide'/>
+ <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+ </disk>
+ <controller type='ide' index='0'/>
+ <video>
+ <model type='bochs-display' vram='16384' heads='1'/>
+ </video>
+ <memballoon model='virtio'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 91ca35d469..07b3689776 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -2006,6 +2006,9 @@ mymain(void)
QEMU_CAPS_DEVICE_VIRTIO_VGA,
QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS);
+ DO_TEST("video-bochs-display-device",
+ QEMU_CAPS_DEVICE_BOCHS_DISPLAY,
+ QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
DO_TEST("video-none-device",
QEMU_CAPS_VNC);
DO_TEST_PARSE_ERROR("video-invalid-multiple-devices", NONE);
--
2.20.1
5 years, 4 months
[libvirt] [PATCH] virDomainGetPerfEvents docstring: virTypedParameterFlags are also supported
by Ilias Stamatis
Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com>
---
src/libvirt-domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 50767a75ed..e2594a3392 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -9730,7 +9730,7 @@ virDomainOpenChannel(virDomainPtr dom,
* @domain: a domain object
* @params: where to store perf events setting
* @nparams: number of items in @params
- * @flags: bitwise-OR of virDomainModificationImpact
+ * @flags: bitwise-OR of virDomainModificationImpact and virTypedParameterFlags
*
* Get all Linux perf events setting. Possible fields returned in
* @params are defined by VIR_PERF_EVENT_* macros and new fields
--
2.22.0
5 years, 4 months
[libvirt] [PATCH] SpaprVio addresses are 32-bit, not 64-bit
by David Gibson
spapr-vio addresses are used on POWER platform qemu guests, which are based
on the PAPR specification. PAPR specifies a number of virtual devices (but
not virtio protocol) which are addressed in an abstract namespace.
Currently, libvirt encodes these addresses as 64-bit values. This is not
correct: spapr-vio addresses are, and always have been 32-bit. That's true
both by the PAPR specification and the qemu implementation.
Therefore, change this in libvirt.
This looks like it would be a breaking change, but it actually isn't.
Because these have always been 32-bit at the lower levels, any attempt to
use a value here > 0xffffffff would always have failed in any case, this
will just make it fail earlier and more clearly.
Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au>
---
src/conf/device_conf.c | 2 +-
src/conf/device_conf.h | 2 +-
src/conf/domain_conf.c | 2 +-
src/qemu/qemu_command.c | 4 ++--
src/qemu/qemu_domain_address.c | 2 +-
src/qemu/qemu_parse_command.c | 4 ++--
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
index 2f82bdc2a7..42f83b0344 100644
--- a/src/conf/device_conf.c
+++ b/src/conf/device_conf.c
@@ -582,7 +582,7 @@ virDomainDeviceSpaprVioAddressParseXML(xmlNodePtr node,
reg = virXMLPropString(node, "reg");
if (reg) {
- if (virStrToLong_ull(reg, NULL, 16, &addr->reg) < 0) {
+ if (virStrToLong_ul(reg, NULL, 16, &addr->reg) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Cannot parse <address> 'reg' attribute"));
ret = -1;
diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index b3299ac69d..02cf8c70ad 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -101,7 +101,7 @@ struct _virDomainDeviceUSBAddress {
typedef struct _virDomainDeviceSpaprVioAddress virDomainDeviceSpaprVioAddress;
typedef virDomainDeviceSpaprVioAddress *virDomainDeviceSpaprVioAddressPtr;
struct _virDomainDeviceSpaprVioAddress {
- unsigned long long reg;
+ unsigned long reg;
bool has_reg;
};
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 97ba8bd53a..02e58dc54d 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -7135,7 +7135,7 @@ virDomainDeviceInfoFormat(virBufferPtr buf,
case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO:
if (info->addr.spaprvio.has_reg)
- virBufferAsprintf(&attrBuf, " reg='0x%llx'", info->addr.spaprvio.reg);
+ virBufferAsprintf(&attrBuf, " reg='0x%lx'", info->addr.spaprvio.reg);
break;
case VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW:
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 59dc134785..fab622f533 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -395,7 +395,7 @@ qemuBuildDeviceAddressStr(virBufferPtr buf,
}
} else if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO) {
if (info->addr.spaprvio.has_reg)
- virBufferAsprintf(buf, ",reg=0x%llx", info->addr.spaprvio.reg);
+ virBufferAsprintf(buf, ",reg=0x%lx", info->addr.spaprvio.reg);
} else if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) {
if (info->addr.ccw.assigned)
virBufferAsprintf(buf, ",devno=%x.%x.%04x",
@@ -4332,7 +4332,7 @@ qemuBuildNVRAMDevStr(virDomainNVRAMDefPtr dev)
if (dev->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO &&
dev->info.addr.spaprvio.has_reg) {
- virBufferAsprintf(&buf, "spapr-nvram.reg=0x%llx",
+ virBufferAsprintf(&buf, "spapr-nvram.reg=0x%lx",
dev->info.addr.spaprvio.reg);
} else {
virReportError(VIR_ERR_XML_ERROR, "%s",
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index 4b99e8ca93..19562c9311 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -204,7 +204,7 @@ qemuDomainAssignSpaprVIOAddress(virDomainDefPtr def,
while (ret != 0) {
if (user_reg) {
virReportError(VIR_ERR_XML_ERROR,
- _("spapr-vio address %#llx already in use"),
+ _("spapr-vio address %#lx already in use"),
info->addr.spaprvio.reg);
return -EEXIST;
}
diff --git a/src/qemu/qemu_parse_command.c b/src/qemu/qemu_parse_command.c
index fc3f70fcde..35d1df8ceb 100644
--- a/src/qemu/qemu_parse_command.c
+++ b/src/qemu/qemu_parse_command.c
@@ -2549,8 +2549,8 @@ qemuParseCommandLine(virFileCachePtr capsCache,
def->nvram->info.addr.spaprvio.has_reg = true;
val += strlen("spapr-nvram.reg=");
- if (virStrToLong_ull(val, NULL, 16,
- &def->nvram->info.addr.spaprvio.reg) < 0) {
+ if (virStrToLong_ul(val, NULL, 16,
+ &def->nvram->info.addr.spaprvio.reg) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("cannot parse nvram's address '%s'"), val);
goto error;
--
2.21.0
5 years, 4 months
[libvirt] [PATCH] docs: Provide documentation for SEV launch security (DO NOT PUSH)
by Erik Skultety
---
I sent this as a patch to get a review on the contents itself, but I believe it
should live as an article on our wiki page afterwards.
docs/launch_security_sev.html.in | 536 +++++++++++++++++++++++++++++++
1 file changed, 536 insertions(+)
create mode 100644 docs/launch_security_sev.html.in
diff --git a/docs/launch_security_sev.html.in b/docs/launch_security_sev.html.in
new file mode 100644
index 0000000000..42db10b33a
--- /dev/null
+++ b/docs/launch_security_sev.html.in
@@ -0,0 +1,536 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta charset="UTF-8"/>
+ <meta name="viewport" content="width=device-width, initial-scale=1"/>
+ <link rel="stylesheet" type="text/css" href="main.css"/>
+ <link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png"/>
+ <link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png"/>
+ <link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png"/>
+ <link rel="manifest" href="/manifest.json"/>
+ <meta name="theme-color" content="#ffffff"/>
+ <title>libvirt: Launch security with AMD SEV</title>
+ <meta name="description" content="libvirt, virtualization, virtualization API"/>
+ <script type="text/javascript" src="js/main.js">
+ <!--// forces non-empty element-->
+ </script>
+ </head>
+ <body onload="pageload()">
+ <div id="body">
+ <div id="content">
+ <h1>Launch security with AMD SEV</h1>
+ <ul>
+ <li>
+ <a href="#Host">Enabling SEV on the host</a>
+ </li>
+ <li>
+ <a href="#Virt">Checking SEV support in the virt stack</a>
+ </li>
+ <li>
+ <a href="#Configuration">VM Configuration</a>
+ </li>
+ <li>
+ <a href="#Limitations">Limitations</a>
+ </li>
+ <li>
+ <a href="#Examples">Full domain XML examples</a>
+ </li>
+ </ul>
+ </div>
+ <p>
+ Storage encryption in modern public cloud computing is a common practice.
+ However, from the point of view of a user of these cloud workloads, a
+ significant amount of trust needs to be put in the cloud platform security as
+ well as integrity (was the hypervisor tampered?). For this reason there's ever
+ rising demand for securing data in use, i.e. memory encryption.
+ One of the solutions addressing this matter is AMD SEV.
+ </p>
+ <h2>AMD SEV</h2>
+ <p>
+ SEV (Secure Encrypted Virtualization) is a feature extension of AMD's SME (Secure
+ Memory Encryption) intended for KVM virtual machines which is supported
+ primarily on AMD's EPYC CPU line. In contrast to SME, SEV uses a unique memory encryption
+ key for each VM. The whole encryption of memory pages is completely transparent
+ to the hypervisor and happens in the AMD firmware.
+ For more details about the technology itself, you can visit
+ <a href="https://developer.amd.com/sev/">AMD's developer portal</a>.
+ </p>
+ <h3>
+ <a id="Host">Enabling SEV on the host</a>
+ <a class="headerlink" href="#Host" title="Permalink to this headline">¶</a>
+ </h3>
+ <p>
+ Before VMs can make use of the SEV feature you need to make sure your
+ AMD CPU does support SEV. You can check whether SEV is among the CPU
+ flags with:
+ </p>
+
+ <pre>
+$ cat /proc/cpuinfo | grep sev
+...
+sme ssbd sev ibpb</pre>
+
+ <p>
+ Next step is to enable SEV in the kernel, because it is disabled by default.
+ This is done by putting the following onto the kernel command line:
+ </p>
+ <pre>
+mem_encrypt=on kvm_amd.sev=1
+ </pre>
+
+ <p>
+ To make the changes persistent, append the above to the variable holding
+ parameters of the kernel command line in
+ <code>/etc/default/grub</code> to preserve SEV settings across reboots
+ </p>
+
+ <pre>
+$ cat /etc/default/grub
+...
+GRUB_CMDLINE_LINUX="... mem_encrypt=on kvm_amd.sev=1"
+$ grub2-mkconfig -o /boot/efi/EFI/<distro>/grub.cfg</pre>
+
+ <p>
+ <code>mem_encrypt=on</code> turns on the SME memory encryption feature on
+ the host which is required for SEV to work. The <code>kvm_amd.sev</code>
+ parameter actually enables SEV in the kvm module. It can be set on the
+ command line alongside <code>mem_encrypt</code> like shown above, or it
+ can be put into a module config under <code>/etc/modprobe.d/</code>
+ </p>
+ <pre>
+$ cat /etc/modprobe.d/sev.conf
+options kvm_amd sev=1
+ </pre>
+ <p>
+ After rebooting the host, you should see SEV being enabled in the kernel:
+ </p>
+ <pre>
+$ cat /sys/module/kvm_amd/parameters/sev
+1
+ </pre>
+
+ <h2>
+ <a id="Virt">Checking SEV support in the virt stack</a>
+ <a class="headerlink" href="#Virt" title="Permalink to this headline">¶</a>
+ </h2>
+ <p>
+ <b>Note: All of the commands bellow need to be run with root privileges.</b>
+ </p>
+ <p>
+ First make sure you have the following packages in the specified versions:
+ </p>
+ <ul>
+ <li>
+ libvirt >= 4.5.0 (>5.1.0 recommended due to additional SEV bugfixes)
+ </li>
+ <li>
+ QEMU >= 2.12.0
+ </li>
+ </ul>
+ <p>
+ To confirm that the virtualization stack supports SEV, run the following:
+ </p>
+ <pre>
+# virsh domcapabilities
+<domainCapabilities>
+...
+ <features>
+ ...
+ <sev supported='yes'>
+ <cbitpos>47</cbitpos>
+ <reducedPhysBits>1</reducedPhysBits>
+ </sev>
+ ...
+ </features>
+</domainCapabilities></pre>
+ <p>
+ Note that if libvirt was already installed and libvirtd running before enabling SEV in the kernel followed by the host reboot you need to force libvirtd
+ to re-probe both the host and QEMU capabilities. First stop libvirtd:
+ </p>
+ <pre>
+# systemctl stop libvirtd.service
+ </pre>
+ <p>
+ Now you need to clean the capabilities cache:
+ </p>
+ <pre>
+# rm -f /var/cache/libvirt/qemu/capabilities/*
+ </pre>
+ <p>
+ If you now restart libvirtd, it will re-probe the capabilities and if
+ you now run:
+ </p>
+ <pre>
+# virsh domcapabilities
+ </pre>
+ <p>
+ SEV should be listed as supported. If you still see:
+ </p>
+ <pre>
+<sev supported='no'/>
+ </pre>
+ <p>
+ it means one of two things:
+ <ol>
+ <li>
+ libvirt does support SEV, but either QEMU or the host does not
+ </li>
+ <li>
+ you have libvirt <=5.1.0 which suffered from getting a
+ <code>'Permission denied'</code> on <code>/dev/sev</code> because
+ of the default permissions on the character device which prevented
+ QEMU from opening it during capabilities probing - you can either
+ manually tweak the permissions so that QEMU has access to it or
+ preferably install libvirt 5.1.0 or higher
+ </li>
+ </ol>
+ </p>
+ <h2>
+ <a id="Configuration">VM Configuration</a>
+ <a class="headerlink" href="#Configuration" title="Permalink to this headline">¶</a>
+ </h2>
+ <p>
+ SEV is enabled in the XML by specifying the
+ <a href="https://libvirt.org/formatdomain.html#launchSecurity"><launchSecurity> </a> element. However, specifying <code>launchSecurity</code> isn't
+ enough to boot an SEV VM. Further configuration requirements are discussed
+ below.
+ </p>
+
+ <h3>Machine type</h3>
+ <p>
+ Even though both Q35 and legacy PC machine types (for PC see also
+ "virtio") can be used with SEV, usage of the legacy PC machine type is
+ strongly discouraged, since depending on how your OVMF package was
+ built (e.g. including features like SecureBoot or SMM) Q35 may even be
+ required.
+ </p>
+
+ <h5>Q35</h5>
+<pre>
+...
+<os>
+ <type arch='x86_64' machine='pc-q35-3.0'>hvm</type>
+ ...
+</os>
+...</pre>
+
+ <h5>i440fx (discouraged)</h5>
+ <pre>
+...
+<os>
+ <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type>
+ ...
+</os>
+...
+ </pre>
+
+ <h3>Boot loader</h3>
+ <p>
+ SEV is only going to work with OVMF (UEFI), so you'll need to point libvirt to
+ the correct OVMF binary.
+ </p>
+ <pre>
+...
+<os>
+ <type arch='x86_64' machine='pc-q35-3.0'>hvm</type>
+ <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader>
+</os>
+...</pre>
+
+ <h3>Memory</h3>
+ <p>
+ Internally, SEV expects that the encrypted memory pages won't be swapped out or move
+ around so the VM memory needs to be pinned in physical RAM which will be
+ handled by QEMU. Apart from that, certain memory regions allocated by QEMU
+ itself (UEFI pflash, device ROMs, video RAM, etc.) have to be encrypted as
+ well. This causes a conflict in how libvirt tries to protect the host.
+ By default, libvirt enforces a memory hard limit on each VM's cgroup in order
+ to protect the host from malicious QEMU to allocate and lock all the available
+ memory. This limit corresponds to the total memory allocation for the VM given
+ by <code><currentMemory></code> element. However, trying to account for the additional
+ memory regions QEMU allocates when calculating the limit in an automated manner
+ is non-deterministic. One way to resolve this is to set the hard limit manually.
+
+ <p>
+ Note: Figuring out the right number so that your guest boots and isn't killed is
+ challenging, but 256MiB extra memory over the total guest RAM should suffice for
+ most workloads and may serve as a good starting point.
+
+ For example, a domain with 4GB memory with a 256MiB extra hard limit would look
+ like this:
+ </p>
+ </p>
+ <pre>
+# virsh edit <domain>
+<domain>
+ ...
+ <currentMemory unit='KiB'>4194304</currentMemory>
+ <memtune>
+ <hard_limit unit='KiB'>4456448</hard_limit>
+ </memtune>
+ ...
+</domain></pre>
+ <p>
+ There's another, preferred method of taking care of the limits by
+ using the<code><memoryBacking></code> element along with the
+ <code><locked/></code> subelement:
+ </p>
+ <pre>
+<domain>
+ ...
+ <memoryBacking>
+ <locked/>
+ </memoryBacking>
+ ...
+</domain></pre>
+ <p>
+ What that does is that it tells libvirt not to force any hard limit (well,
+ unlimited) upon the VM cgroup. The obvious advantage is that one doesn't need
+ to determine the hard limit for every single SEV-enabled VM. However, there is
+ a significant security-related drawback to this approach. Since no hard limit
+ is applied, a malicious QEMU could perform a DoS attack by locking all of the
+ host's available memory. The way to avoid this issue and to protect the host is
+ to enforce a bigger hard limit on the master cgroup containing all of the VMs
+ - on systemd this is <code>machine.slice</code>.
+ </p>
+ <pre>
+# systemctl set-property machine.slice MemoryHigh=<value></pre>
+ <p>
+ To put even stricter measures in place which would involve the OOM killer, use
+ <pre>
+# systemctl set-property machine.slice MemoryMax=<value></pre>
+ instead. Alternatively, you can create a systemd config (don't forget
+ to reload systemd configuration in this case):
+ <pre>
+# cat << EOF > /etc/systemd/system.control/machine.slice.d/90-MemoryMax.conf
+MemoryMax=<value>
+EOF</pre>
+ The trade-off to keep in mind with the second approach is that the VMs
+ can still perform DoS on each other.
+ </p>
+ <h3>Virtio</h3>
+ <p>
+ In order to make virtio devices work, we need to enable emulated IOMMU
+ on the devices so that virtual DMA can work.
+ </p>
+ <pre>
+# virsh edit <domain>
+<domain>
+ ...
+ <controller type='virtio-serial' index='0'>
+ <driver iommu='on'/>
+ </controller>
+ <controller type='scsi' index='0' model='virtio-scsi'>
+ <driver iommu='on'/>
+ </controller>
+ ...
+ <memballoon model='virtio'>
+ <driver iommu='on'/>
+ </memballoon>
+ <rng model='virtio'>
+ <backend model='random'>/dev/urandom</backend>
+ <driver iommu='on'/>
+ </rng>
+ ...
+<domain></pre>
+ <p>
+ If you for some reason want to use the legacy PC machine type, further changes
+ to the virtio
+ configuration is required, because SEV will not work with Virtio <1.0. In
+ libvirt, this is handled by using the virtio-non-transitional device model
+ (libvirt >= 5.2.0 required).
+
+ <p>
+ Note: some devices like video devices don't
+ support non-transitional model, which means that virtio GPU cannot be used.
+ </p>
+ </p>
+ <pre>
+<domain>
+ ...
+ <devices>
+ ...
+ <memballoon model='virtio-non-transitional'>
+ <driver iommu='on'/>
+ </memballoon>
+ </devices>
+ ...
+</domain></pre>
+
+
+ <h2>
+ <a id="Limitations">Limitations</a>
+ <a class="headerlink" href="#Limitations" title="Permalink to this headline">¶</a>
+ </h2>
+ <p>
+ Currently, the boot disk cannot be of type virtio-blk, instead, virtio-scsi
+ needs to be used if virtio is desired. This limitation is expected to be lifted
+ with future releases of kernel (the kernel used at the time of writing the
+ article is 5.0.14).
+ If you still cannot start an SEV VM, it could be because of wrong SELinux label on the <code>/dev/sev</code> device with selinux-policy <3.14.2.40 which prevents QEMU from touching the device. This can be resolved by upgrading the package, tuning the selinux policy rules manually to allow svirt_t to access the device (see <code>audit2allow</code> on how to do that) or putting SELinux into permissive mode (discouraged).
+ </p>
+ <h2>
+ <a id="Examples">Full domain XML examples</a>
+ <a class="headerlink" href="#Examples" title="Permalink to this headline">¶</a>
+ </h2>
+ <h5>Q35 machine</h5>
+ <pre>
+<domain type='kvm'>
+ <name>sev-dummy</name>
+ <memory unit='KiB'>4194304</memory>
+ <currentMemory unit='KiB'>4194304</currentMemory>
+ <memoryBacking>
+ <locked/>
+ </memoryBacking>
+ <vcpu placement='static'>4</vcpu>
+ <os>
+ <type arch='x86_64' machine='pc-q35-3.0'>hvm</type>
+ <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader>
+ <nvram>/var/lib/libvirt/qemu/nvram/sev-dummy_VARS.fd</nvram>
+ </os>
+ <features>
+ <acpi/>
+ <apic/>
+ <vmport state='off'/>
+ </features>
+ <cpu mode='host-model' check='partial'>
+ <model fallback='allow'/>
+ </cpu>
+ <clock offset='utc'>
+ <timer name='rtc' tickpolicy='catchup'/>
+ <timer name='pit' tickpolicy='delay'/>
+ <timer name='hpet' present='no'/>
+ </clock>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <pm>
+ <suspend-to-mem enabled='no'/>
+ <suspend-to-disk enabled='no'/>
+ </pm>
+ <devices>
+ <emulator>/usr/bin/qemu-kvm</emulator>
+ <disk type='file' device='disk'>
+ <driver name='qemu' type='qcow2'/>
+ <source file='/var/lib/libvirt/images/sev-dummy.qcow2'/>
+ <target dev='sda' bus='scsi'/>
+ <boot order='1'/>
+ </disk>
+ <controller type='virtio-serial' index='0'>
+ <driver iommu='on'/>
+ </controller>
+ <controller type='scsi' index='0' model='virtio-scsi'>
+ <driver iommu='on'/>
+ </controller>
+ <interface type='network'>
+ <mac address='52:54:00:cc:56:90'/>
+ <source network='default'/>
+ <model type='virtio'/>
+ <driver iommu='on'/>
+ </interface>
+ <graphics type='spice' autoport='yes'>
+ <listen type='address'/>
+ <gl enable='no'/>
+ </graphics>
+ <video>
+ <model type='qxl'/>
+ </video>
+ <memballoon model='virtio'>
+ <driver iommu='on'/>
+ </memballoon>
+ <rng model='virtio'>
+ <driver iommu='on'/>
+ </rng>
+ </devices>
+ <launchSecurity type='sev'>
+ <cbitpos>47</cbitpos>
+ <reducedPhysBits>1</reducedPhysBits>
+ <policy>0x0003</policy>
+ </launchSecurity>
+</domain></pre>
+
+ <h5>PC-i440fx machine:</h5>
+ <pre>
+<domain type='kvm'>
+ <name>sev-dummy-legacy</name>
+ <memory unit='KiB'>4194304</memory>
+ <currentMemory unit='KiB'>4194304</currentMemory>
+ <memtune>
+ <hard_limit unit='KiB'>5242880</hard_limit>
+ </memtune>
+ <vcpu placement='static'>4</vcpu>
+ <os>
+ <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type>
+ <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader>
+ <nvram>/var/lib/libvirt/qemu/nvram/sev-dummy_VARS.fd</nvram>
+ <boot dev='hd'/>
+ </os>
+ <features>
+ <acpi/>
+ <apic/>
+ <vmport state='off'/>
+ </features>
+ <cpu mode='host-model' check='partial'>
+ <model fallback='allow'/>
+ </cpu>
+ <clock offset='utc'>
+ <timer name='rtc' tickpolicy='catchup'/>
+ <timer name='pit' tickpolicy='delay'/>
+ <timer name='hpet' present='no'/>
+ </clock>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <pm>
+ <suspend-to-mem enabled='no'/>
+ <suspend-to-disk enabled='no'/>
+ </pm>
+ <devices>
+ <emulator>/usr/bin/qemu-kvm</emulator>
+ <disk type='file' device='disk'>
+ <driver name='qemu' type='qcow2'/>
+ <source file='/var/lib/libvirt/images/sev-dummy-seabios.qcow2'/>
+ <target dev='sda' bus='sata'/>
+ </disk>
+ <interface type='network'>
+ <mac address='52:54:00:d8:96:c8'/>
+ <source network='default'/>
+ <model type='virtio-non-transitional'/>
+ </interface>
+ <serial type='pty'>
+ <target type='isa-serial' port='0'>
+ <model name='isa-serial'/>
+ </target>
+ </serial>
+ <console type='pty'>
+ <target type='serial' port='0'/>
+ </console>
+ <input type='tablet' bus='usb'>
+ <address type='usb' bus='0' port='1'/>
+ </input>
+ <input type='mouse' bus='ps2'/>
+ <input type='keyboard' bus='ps2'/>
+ <graphics type='spice' autoport='yes'>
+ <listen type='address'/>
+ <gl enable='no'/>
+ </graphics>
+ <video>
+ <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
+ </video>
+ <memballoon model='virtio-non-transitional'>
+ <driver iommu='on'/>
+ </memballoon>
+ <rng model='virtio-non-transitional'>
+ <driver iommu='on'/>
+ </rng>
+ </devices>
+ <launchSecurity type='sev'>
+ <cbitpos>47</cbitpos>
+ <reducedPhysBits>1</reducedPhysBits>
+ <policy>0x0003</policy>
+ </launchSecurity>
+</domain></pre>
+ </div>
+</body>
+</html>
--
2.21.0
5 years, 4 months
