Re: [libvirt] Making containers creation easy
On 03/08/2017 06:16 PM, Cedric Bosdonnat wrote: > Hi all, > > I've worked on making the containers rootfs creation easy. > Here is a wrap-up of my work: > > http://bosdonnat.fr/system-container-images.html > > Any opinion on that? Anything to do to move it forward? Awesome. I always felt like preparing rootfs for my containers was overwhelming. Now, with your tool I can use docker images at least. BTW: should we have the repo hosted on libvirt.org? Or at least link yours from our docs? Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3 0/2] Allow saving VM state to pipe
This series introduce flag VIR_DOMAIN_SAVE_DIRECT to enable command 'save' to write to PIPE. This will write QEMU_SAVE_MAGIC directly. Base upon patches from Roy Keene with some fixes. Change from original patch: 1) Check whether the specified path is a PIPE. 2) Rebase on upstream. 3) Add doc for virsh command v3: add doc/news.xml rebase on upstream v2-resend: rebase on upstream v2: rename VIR_DOMAIN_SAVE_PIPE to VIR_DOMAIN_SAVE_DIRECT remove S_ISFIFO check Chen Hanxiao (2): qemu: Allow qemuDomainSaveMemory saving VM state to a pipe virsh: introduce flage --direct for save command docs/news.xml| 9 +++ include/libvirt/libvirt-domain.h | 1 + src/qemu/qemu_driver.c | 54 ++-- tools/virsh-domain.c | 6 + tools/virsh.pod | 5 +++- 5 files changed, 56 insertions(+), 19 deletions(-) -- 2.7.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3 1/2] qemu: Allow qemuDomainSaveMemory saving VM state to a pipe
From: Chen Hanxiao
Base upon patches from Roy Keene
Currently qemuDomainSaveMemory can save vm's config
and memory to fd.
It write a magic QEMU_SAVE_PARTIAL firstly,
then re-open it to change QEMU_SAVE_PARTIAL as QEMU_SAVE_MAGIC.
For pipes this is not possible, attempting to re-open the pipe
will not connect you to the same consumer.
Seeking is also not possible on a pipe.
This patch introduce VIR_DOMAIN_SAVE_DIRECT
If set, write QEMU_SAVE_MAGIC directly.
This is useful to me for saving a VM state directly to
Ceph RBD images without having an intermediate file.
Signed-off-by: Roy Keene
Signed-off-by: Chen Hanxiao
---
v3:
add news.xml
v2-resend:
rebase on upstream
v2:
rename VIR_DOMAIN_SAVE_PIPE to VIR_DOMAIN_SAVE_DIRECT
remove S_ISFIFO check for dst path
docs/news.xml| 9 +++
include/libvirt/libvirt-domain.h | 1 +
src/qemu/qemu_driver.c | 54 ++--
3 files changed, 46 insertions(+), 18 deletions(-)
diff --git a/docs/news.xml b/docs/news.xml
index 9515395..57088db 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -37,6 +37,15 @@
applications running on the platform.
+
+
+ qemu: Allow qemuDomainSaveMemory saving VM state to a pipe
+
+
+Introduce flag VIR_DOMAIN_SAVE_DIRECT to enable command 'save'
+to write to PIPE, for PIPE can't be reopened.
+
+
diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index c490d71..f58fe2c 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -1169,6 +1169,7 @@ typedef enum {
VIR_DOMAIN_SAVE_BYPASS_CACHE = 1 << 0, /* Avoid file system cache
pollution */
VIR_DOMAIN_SAVE_RUNNING = 1 << 1, /* Favor running over paused */
VIR_DOMAIN_SAVE_PAUSED = 1 << 2, /* Favor paused over running */
+VIR_DOMAIN_SAVE_DIRECT = 1 << 3, /* Write QEMU_SAVE_MAGIC directly */
} virDomainSaveRestoreFlags;
int virDomainSave (virDomainPtr domain,
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 2032fac..29b7677 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3059,6 +3059,7 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
virQEMUSaveHeader header;
bool bypassSecurityDriver = false;
bool needUnlink = false;
+bool canReopen = true;
int ret = -1;
int fd = -1;
int directFlag = 0;
@@ -3066,7 +3067,6 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
unsigned int wrapperFlags = VIR_FILE_WRAPPER_NON_BLOCKING;
memset(&header, 0, sizeof(header));
-memcpy(header.magic, QEMU_SAVE_PARTIAL, sizeof(header.magic));
header.version = QEMU_SAVE_VERSION;
header.was_running = was_running ? 1 : 0;
header.compressed = compressed;
@@ -3082,6 +3082,7 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
goto cleanup;
}
}
+
fd = qemuOpenFile(driver, vm, path,
O_WRONLY | O_TRUNC | O_CREAT | directFlag,
&needUnlink, &bypassSecurityDriver);
@@ -3094,6 +3095,20 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
if (!(wrapperFd = virFileWrapperFdNew(&fd, path, wrapperFlags)))
goto cleanup;
+/* Set the header magic.
+ * Setting flags VIR_DOMAIN_SAVE_DIRECT will write
+ * magic QEMU_SAVE_MAGIC directly.
+ * For PIPE, we should do this because it can't be reopen.
+ * Otherwise we'll update the magic after
+ * the saving completes successfully.
+ */
+if (flags & VIR_DOMAIN_SAVE_DIRECT) {
+canReopen = false;
+memcpy(header.magic, QEMU_SAVE_MAGIC, sizeof(header.magic));
+} else {
+memcpy(header.magic, QEMU_SAVE_PARTIAL, sizeof(header.magic));
+}
+
/* Write header to file, followed by XML */
if (qemuDomainSaveHeader(fd, path, domXML, &header) < 0)
goto cleanup;
@@ -3102,28 +3117,30 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
if (qemuMigrationToFile(driver, vm, fd, compressedpath, asyncJob) < 0)
goto cleanup;
-/* Touch up file header to mark image complete. */
+if (canReopen) {
+/* Touch up file header to mark image complete. */
-/* Reopen the file to touch up the header, since we aren't set
- * up to seek backwards on wrapperFd. The reopened fd will
- * trigger a single page of file system cache pollution, but
- * that's acceptable. */
-if (VIR_CLOSE(fd) < 0) {
-virReportSystemError(errno, _("unable to close %s"), path);
-goto cleanup;
-}
+/* Reopen the file to touch up the header, since we aren't set
+* up to seek backwards on wrapperFd. The reopened fd will
+* trigger a single page of file system cache pollution, but
+* that's acceptable. */
+if (VIR_CLOSE(fd) < 0) {
+virReportSystemErro
[libvirt] [PATCH v3 2/2] virsh: introduce flage --direct for save command
From: Chen Hanxiao
Base upon patches from Roy Keene
This patch introduces --direct flag for save command.
We could use this flag to save vm to a PIPE.
We could saving a VM state directly to Ceph RBD images
without having an intermediate file.
How to test:
fifo="$(mktemp -u)"; mkfifo "${fifo}" && virsh save --pipe cirros "${fifo}" &
cat "${fifo}" | rbd --id cinder import - hotsnapshot/test1234 & wait; rm -f
"${fifo}"
Signed-off-by: Roy Keene
Signed-off-by: Chen Hanxiao
---
v3:
rebase on upstream
v2-resend:
rebase on upstream
v2:
rename VIR_DOMAIN_SAVE_PIPE to VIR_DOMAIN_SAVE_DIRECT
tools/virsh-domain.c | 6 ++
tools/virsh.pod | 5 -
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 09a9f82..d96e894 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -4192,6 +4192,10 @@ static const vshCmdOptDef opts_save[] = {
.type = VSH_OT_BOOL,
.help = N_("set domain to be paused on restore")
},
+{.name = "direct",
+ .type = VSH_OT_BOOL,
+ .help = N_("write the file directly, needed by PIPE/FIFO")
+},
{.name = "verbose",
.type = VSH_OT_BOOL,
.help = N_("display the progress of save")
@@ -4228,6 +4232,8 @@ doSave(void *opaque)
flags |= VIR_DOMAIN_SAVE_RUNNING;
if (vshCommandOptBool(cmd, "paused"))
flags |= VIR_DOMAIN_SAVE_PAUSED;
+if (vshCommandOptBool(cmd, "direct"))
+flags |= VIR_DOMAIN_SAVE_DIRECT;
if (vshCommandOptStringReq(ctl, cmd, "xml", &xmlfile) < 0)
goto out;
diff --git a/tools/virsh.pod b/tools/virsh.pod
index ee79046..9dcb527 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -1928,7 +1928,7 @@ have also reverted all storage volumes back to the same
contents as when
the state file was created.
=item B I I [I<--bypass-cache>] [I<--xml> B]
-[{I<--running> | I<--paused>}] [I<--verbose>]
+[{I<--running> | I<--paused>}] [I<--direct>] [I<--verbose>]
Saves a running domain (RAM, but not disk state) to a state file so that
it can be restored
@@ -1943,6 +1943,9 @@ with B command (sent by another virsh
instance). Another option
is to send SIGINT (usually with C) to the virsh process running
B command. I<--verbose> displays the progress of save.
+Usually B command will save the domain's state as a regular file.
+If you want to save it into a PIPE/FIFO, then flag I<--direct> must be set.
+
This is roughly equivalent to doing a hibernate on a running computer,
with all the same limitations. Open network connections may be
severed upon restore, as TCP timeouts may have expired.
--
2.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] ANNOUNCE: virt-manager 1.4.1 released
I'm happy to announce the release of virt-manager 1.4.1! virt-manager is a desktop application for managing KVM, Xen, and LXC virtualization via libvirt. The release can be downloaded from: http://virt-manager.org/download/ This release includes: - storage/nodedev event API support (Jovanka Gulicoska) - UI options for enabling spice GL (Marc-André Lureau) - Add default virtio-rng /dev/urandom for supported guest OS - Cloning and rename support for UEFI VMs (Pavel Hrdina) - libguestfs inspection UI improvements (Pino Toscano) - virt-install: Add --qemu-commandline - virt-install: Add --network vhostuser (Chen Hanxiao) - virt-install: Add --sysinfo (Charles Arnold) Thanks to everyone who has contributed to this release through testing, bug reporting, submitting patches, and otherwise sending in feedback! Thanks, Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Revisiting qemu monitor timeout on VM start
Hi All, Encountering a qemu monitor timeout when starting a VM has been discussed here before, e.g. https://www.redhat.com/archives/libvir-list/2014-January/msg00060.html https://www.redhat.com/archives/libvir-list/2014-January/msg00408.html Recently I've received reports of the same when starting large memory VMs backed by 1G huge pages. In one of the reports, Matt timed how long it takes to allocate 402GB worth of hugetlbfs pages (these are 1G pages, but the time is similar for 2M): real 105.47 user 0.05 sys 105.42 The time is spent entirely in the kernel zero'ing pages and as you can see it exceeds the 30 second monitor timeout in libvirt. Do folks have any suggestions on how to avoid the timeout? Obviously one solution is to introduce a knob in qemu.conf to control the timeout, as was proposed in the above threads. Another solution that came to mind is changing qemu to open the monitor earlier, making it available while the kernel is off scrubbing pages. I'm not familiar enough with qemu code to know if such a change is possible, but given the amount of initialization done in main() prior to calling mon_init_func(), my confidence in this idea is low. Perhaps someone more familiar with qemu initialization can comment on that. Thanks in advance for comments on these ideas or alternate proposals! Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] doc: Correct the default werror policy
Hello, Am 08.03.2017 um 17:28 schrieb Martin Kletzander: > On Wed, Mar 01, 2017 at 08:44:54PM +0100, Philipp Hahn wrote: >> The documentation is plain wrong about the default write_error policy, >> as its only implemented by QEMU (src/vz/vz_utils.c is the only other >> case, which simply explodes, is anything except other then >> VIR_DOMAIN_DISK_ERROR_POLICY_DEFAULT is used). >> > > Sounds like bashing about some problem. Is there any bug somewhere? It > does not add any useful information to the commit message, so I'll strip > it off before pushing. My problem is, that the documentation does not match the implementation and from reading that documentation you get a wrong impression: The documentation claims, that the default is "report", while the QEMU internal default is "ENOSPC". This has a sever difference, namely that your VM gets suspended when your host systems file systems get full. This is a good default, as you don't loose any data, but on the other hand your VM disappears from the network until you free some space and resume the VM. I have seen this happen multiple times and I know the behaviour by now, but others have reported this "strange" behaviour to me several times: they keep wondering why their VM suddenly gets paused, while the libvirt documentation tells them that the VM would see all errors (report). So lets please tell those people to look at the QEMU code and not the libvirt code. > So my question is; is there anything in that driver that needs fixing > WRT this patch? The default is okay and the most save regarding data loss, but might not be okay if service availability is more important to you. We can even apply the following change on top, as QEMU is the only driver implementing a configurable error policy: > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > index dc44a55..025007f 100644 > --- a/docs/formatdomain.html.in > +++ b/docs/formatdomain.html.in > @@ -2744,13 +2744,14 @@ > The optional error_policy attribute controls > how the hypervisor will behave on a disk read or write > error, possible values are "stop", "report", "ignore", and > -"enospace".Since 0.8.0, "report" since > +"enospace".Since 0.8.0 (QEMU and KVM only), > "report" since > 0.9.7 The default is left to the discretion of the > hypervisor. > There is also an > optional rerror_policy that controls behavior > for read errors only. Since > -0.9.7. If no rerror_policy is given, error_policy > +0.9.7 (QEMU and KVM only). > +If no rerror_policy is given, error_policy > is used for both read and write errors. If rerror_policy > is given, it overrides the error_policy for > read errors. Also note that "enospace" is not a valid And "report" is the default for QEMU since release_0_10_0~298 ,which made the policy configurable, but the commit message claims "report" was even the default before that: > commit 428c570512c1d9298b52dc9fc1a541b542a5c117 > Author: aliguori > Date: Wed Jan 21 18:59:04 2009 + > > Stop VM on ENOSPC error. (Gleb Natapov) > > This version of the patch adds new option "werror" to -drive flag. > Possible values are: > > report- report errors to a guest as IO errors > ignore- continue as if nothing happened > stop - stop VM on any error and retry last command on resume > enospc- stop vm on ENOSPC error and retry last command on resume > all other errors are reported to a guest. > > Default is "report" to maintain current behaviour. > > Signed-off-by: Gleb Natapov > Signed-off-by: Anthony Liguori > > > git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6388 > c046a42c-6fe2-441c-8c8c-71466251a162 Philipp -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: Rename variable
Rename 'secretUsageType' to 'usageType' since it's superfluous in an
API qemu*Secret*
Signed-off-by: John Ferlan
---
Pushed as trivial - based upon Jirka's review comment from patch 1 of
the "Alter TLS/UUID algorithms to be a bit more generic" series.
src/qemu/qemu_domain.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index bffb8ac..4d184d3 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -965,7 +965,7 @@ qemuDomainChrSourcePrivateDispose(void *obj)
/* qemuDomainSecretPlainSetup:
* @conn: Pointer to connection
* @secinfo: Pointer to secret info
- * @secretUsageType: The virSecretUsageType
+ * @usageType: The virSecretUsageType
* @username: username to use for authentication (may be NULL)
* @seclookupdef: Pointer to seclookupdef data
*
@@ -976,7 +976,7 @@ qemuDomainChrSourcePrivateDispose(void *obj)
static int
qemuDomainSecretPlainSetup(virConnectPtr conn,
qemuDomainSecretInfoPtr secinfo,
- virSecretUsageType secretUsageType,
+ virSecretUsageType usageType,
const char *username,
virSecretLookupTypeDefPtr seclookupdef)
{
@@ -984,7 +984,7 @@ qemuDomainSecretPlainSetup(virConnectPtr conn,
if (VIR_STRDUP(secinfo->s.plain.username, username) < 0)
return -1;
-return virSecretGetSecretString(conn, seclookupdef, secretUsageType,
+return virSecretGetSecretString(conn, seclookupdef, usageType,
&secinfo->s.plain.secret,
&secinfo->s.plain.secretlen);
}
@@ -995,7 +995,7 @@ qemuDomainSecretPlainSetup(virConnectPtr conn,
* @priv: pointer to domain private object
* @secinfo: Pointer to secret info
* @srcalias: Alias of the disk/hostdev used to generate the secret alias
- * @secretUsageType: The virSecretUsageType
+ * @usageType: The virSecretUsageType
* @username: username to use for authentication (may be NULL)
* @seclookupdef: Pointer to seclookupdef data
* @isLuks: True/False for is for luks (alias generation)
@@ -1009,7 +1009,7 @@ qemuDomainSecretAESSetup(virConnectPtr conn,
qemuDomainObjPrivatePtr priv,
qemuDomainSecretInfoPtr secinfo,
const char *srcalias,
- virSecretUsageType secretUsageType,
+ virSecretUsageType usageType,
const char *username,
virSecretLookupTypeDefPtr seclookupdef,
bool isLuks)
@@ -1038,7 +1038,7 @@ qemuDomainSecretAESSetup(virConnectPtr conn,
goto cleanup;
/* Grab the unencoded secret */
-if (virSecretGetSecretString(conn, seclookupdef, secretUsageType,
+if (virSecretGetSecretString(conn, seclookupdef, usageType,
&secret, &secretlen) < 0)
goto cleanup;
@@ -1072,7 +1072,7 @@ qemuDomainSecretAESSetup(virConnectPtr conn,
* @priv: pointer to domain private object
* @secinfo: Pointer to secret info
* @srcalias: Alias of the disk/hostdev used to generate the secret alias
- * @secretUsageType: The virSecretUsageType
+ * @usageType: The virSecretUsageType
* @username: username to use for authentication (may be NULL)
* @seclookupdef: Pointer to seclookupdef data
* @isLuks: True when is luks (generates different alias)
@@ -1089,22 +1089,22 @@ qemuDomainSecretSetup(virConnectPtr conn,
qemuDomainObjPrivatePtr priv,
qemuDomainSecretInfoPtr secinfo,
const char *srcalias,
- virSecretUsageType secretUsageType,
+ virSecretUsageType usageType,
const char *username,
virSecretLookupTypeDefPtr seclookupdef,
bool isLuks)
{
if (virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC) &&
virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_OBJECT_SECRET) &&
-(secretUsageType == VIR_SECRET_USAGE_TYPE_CEPH ||
- secretUsageType == VIR_SECRET_USAGE_TYPE_VOLUME ||
- secretUsageType == VIR_SECRET_USAGE_TYPE_TLS)) {
+(usageType == VIR_SECRET_USAGE_TYPE_CEPH ||
+ usageType == VIR_SECRET_USAGE_TYPE_VOLUME ||
+ usageType == VIR_SECRET_USAGE_TYPE_TLS)) {
if (qemuDomainSecretAESSetup(conn, priv, secinfo, srcalias,
- secretUsageType, username,
+ usageType, username,
seclookupdef, isLuks) < 0)
return -1;
} else {
-if (qemuDomainSecretPlainSetup(conn, secinfo, secretUsageType,
+if (qemuDomainSecretPlainSetup(conn, secinfo, usageType,
username, seclookupdef) < 0
Re: [libvirt] [PATCH 1/6] bhyve: virBhyveProbeCaps: BHYVE_CAP_LPC_BOOTROM
On 08.03.2017 18:19, Michal Privoznik wrote: > ACK, but we really need a better way to detect capabilites. For instance > now, bhyve binary is executed 4 times just to find out whether it > supports 4 capabilities. That's just madness. Maybe we can get in touch > with bhyve developers and ask them? Maybe it could have a monitor just > like qemu has, or something. There's a patch[1] for it, but it would need to be moved along. Unfortunately, we would still need to somehow fall back to this for backwards compatibility... Fabian [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210111 -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] tests: Add storagevol tests for format=iso
On Tue, Mar 07, 2017 at 10:59:42AM -0500, Cole Robinson wrote: > Demonstrates the bug fix in commit 0e5db762627 > --- > tests/storagevolxml2argvdata/iso-input.argv | 1 + > tests/storagevolxml2argvdata/iso.argv | 1 + > tests/storagevolxml2argvtest.c | 7 +++ > tests/storagevolxml2xmlin/vol-file-iso.xml | 10 ++ > tests/storagevolxml2xmlout/vol-file-iso.xml | 11 +++ > tests/storagevolxml2xmltest.c | 1 + > 6 files changed, 31 insertions(+) > create mode 100644 tests/storagevolxml2argvdata/iso-input.argv > create mode 100644 tests/storagevolxml2argvdata/iso.argv > create mode 100644 tests/storagevolxml2xmlin/vol-file-iso.xml > create mode 100644 tests/storagevolxml2xmlout/vol-file-iso.xml > > diff --git a/tests/storagevolxml2argvdata/iso-input.argv > b/tests/storagevolxml2argvdata/iso-input.argv > new file mode 100644 > index 000..333d7e6 > --- /dev/null > +++ b/tests/storagevolxml2argvdata/iso-input.argv > @@ -0,0 +1 @@ > +qemu-img convert -f raw -O raw /var/lib/libvirt/images/test.iso > /var/lib/libvirt/images/sparse.img This line is too long and syntax-check isn't happy about that. > \ No newline at end of file > diff --git a/tests/storagevolxml2argvdata/iso.argv > b/tests/storagevolxml2argvdata/iso.argv > new file mode 100644 > index 000..40b99c5 > --- /dev/null > +++ b/tests/storagevolxml2argvdata/iso.argv > @@ -0,0 +1 @@ > +qemu-img create -f raw /var/lib/libvirt/images/test.iso 1024K > \ No newline at end of file For some reason both .argv files have no "\n" at the end of a file, reported by syntax-check. ACK with that fixed. Pavel signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Make use of PERF_COUNT_HW_REF_CPU_CYCLES conditional
On Fri, Dec 16, Daniel P. Berrange wrote:
> The PERF_COUNT_HW_REF_CPU_CYCLES constant is not available
> on all Linux distros libvirt targets, so its use must be
> made conditional. Other constant have existed long enough
> that we can assume they exist, as we don't support very
> old distros like RHEL-5 any more.
> +# ifdef PERF_COUNT_HW_REF_CPU_CYCLES
How can this fix the error?
This and PERF_COUNT_HW_STALLED_CYCLES_FRONTEND/BACKEND are part of an
'enum', which is ordinary code for cpp. Unfortunately this is correct
because the code is written in C, not CPP.
I will deal with the compile errors like that:
Index: libvirt-20170308T173307.d7dcea6/src/util/virperf.c
===
--- libvirt-20170308T173307.d7dcea6.orig/src/util/virperf.c
+++ libvirt-20170308T173307.d7dcea6/src/util/virperf.c
@@ -76,6 +76,12 @@ struct virPerfEventAttr {
unsigned long long attrConfig;
};
+#ifndef PERF_ATTR_SIZE_VER2
+#define PERF_COUNT_HW_STALLED_CYCLES_FRONTEND 7
+#define PERF_COUNT_HW_STALLED_CYCLES_BACKEND8
+#define PERF_COUNT_HW_REF_CPU_CYCLES9
+#endif
+
static struct virPerfEventAttr attrs[] = {
{.type = VIR_PERF_EVENT_CMT, .attrType = 0, .attrConfig = 1},
{.type = VIR_PERF_EVENT_MBMT, .attrType = 0, .attrConfig = 2},
Olaf
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 1/2] qemu: Advertise ACPI support for aarch64 guests
On 03/08/17 18:12, Daniel P. Berrange wrote: > On Wed, Mar 08, 2017 at 06:05:02PM +0100, Andrea Bolognani wrote: >> On Wed, 2017-03-08 at 16:00 +, Daniel P. Berrange wrote: So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. >>> >>> IIUC, it only supports ACPI if using the AAVMF firmware, right ? >> >> My current understanding is that ACPI on aarch64 requires >> UEFI, not necessarily AAVMF. I'll admit I haven't really >> considered other QEMU-compatible UEFI implementations, >> though, assuming they exist. >> >> Laszlo? :) >> >>> I know that is the preferred firmware for aarch64, but IIUC it is >>> not a hard requirement by QEMU. So even if we advertize it in the >>> capabilities, we might need to still validate during CLI building >>> that we're actually using AAVMF firmware. >> >> We currently require that ACPI is available when using UEFI, >> even though as mentioned above I believe it should really >> be the other way around. >> >> In any case, how would we validate that the pflash file >> we're passing to QEMU does indeed contain AAVMF? > > I don't think we can, at least not right now. > > For the secure boot problem, we previously discussed create a standardized > metadata file to accompany firmware images, which would declare what QEMU > features the firmware supported. ACPI could fit into that world. > > It is probably time we got serious about actually doing this > > Meanwhile, we can just assume it supports ACPI. > > The scenario I was actually thinking of was direct kernel boot, > rather than non-AAVMF impls of UEFI. > > IOW, where you just pass -kernel/-initrd/-dtb to QEMU and no firmware > file. In that case, we should report an error if is requested > in the XML IIUC. Direct kernel boot without UEFI firmware should indeed conflict with , yes; there's no firmware to install the tables for the kernel. Direct kernel boot with UEFI firmware should permit . The firmware starts, does its thing (including installation of ACPI tables), then grabs the kernel from fw_cfg, and launches it. The kernel will see the tables. Thanks Laszlo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 1/2] qemu: Advertise ACPI support for aarch64 guests
On 03/08/17 18:05, Andrea Bolognani wrote:
> On Wed, 2017-03-08 at 16:00 +, Daniel P. Berrange wrote:
>>> So far, libvirt has assumed that only x86 supports ACPI,
>>> but that's inaccurate since aarch64 supports it too.
>>
>> IIUC, it only supports ACPI if using the AAVMF firmware, right ?
>
> My current understanding is that ACPI on aarch64 requires
> UEFI, not necessarily AAVMF.
That's technically correct, yes. ("The best kind of correct" :))
> I'll admit I haven't really
> considered other QEMU-compatible UEFI implementations,
> though, assuming they exist.
>
> Laszlo? :)
I'm unaware of any others.
>
>> I know that is the preferred firmware for aarch64, but IIUC it is
>> not a hard requirement by QEMU. So even if we advertize it in the
>> capabilities, we might need to still validate during CLI building
>> that we're actually using AAVMF firmware.
>
> We currently require that ACPI is available when using UEFI,
> even though as mentioned above I believe it should really
> be the other way around.
For x86, the requirement looks correct. You won't find an x86 platform
that supports/exhibits UEFI but doesn't support/exhibit ACPI.
For aarch64, it's different. You can have UEFI with DT only. And, if you
see ACPI, it implies both that you have UEFI and that you are on aarch64.
>
> In any case, how would we validate that the pflash file
> we're passing to QEMU does indeed contain AAVMF?
You wouldn't. There isn't exactly a plethora of guest firmware,
especially of standardized & open source firmware. IMO equating
loader/@type == 'pflash'
with
guest uses UEFI
with
guest uses OVMF or AAVMF (as appropriate for the guest arch)
is good enough.
Laszlo
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virt-host-validate: add bhyve support
On 02/25/2017 02:30 PM, Roman Bogorodskiy wrote: > Add bhyve support to virt-host-validate(1). It checks for the > essential kernel modules to be available so that user can actually > start VMs, have networking and console access. > > It uses the kldnext(2)/kldstat(2) routines to retrieve modules list. > As bhyve is only available on FreeBSD and these routines were available > long before bhyve appeared, not adding any specific configure checks > for that. > --- > po/POTFILES.in | 1 + > tools/Makefile.am| 1 + > tools/virt-host-validate-bhyve.c | 78 > > tools/virt-host-validate-bhyve.h | 27 ++ > tools/virt-host-validate.c | 12 +++ > tools/virt-host-validate.pod | 4 +-- > 6 files changed, 121 insertions(+), 2 deletions(-) > create mode 100644 tools/virt-host-validate-bhyve.c > create mode 100644 tools/virt-host-validate-bhyve.h > > diff --git a/po/POTFILES.in b/po/POTFILES.in > index 9f66697d7..51b5859cb 100644 > --- a/po/POTFILES.in > +++ b/po/POTFILES.in > @@ -306,6 +306,7 @@ tools/virsh-snapshot.c > tools/virsh-volume.c > tools/virsh.c > tools/virt-admin.c > +tools/virt-host-validate-bhyve.c > tools/virt-host-validate-common.c > tools/virt-host-validate-lxc.c > tools/virt-host-validate-qemu.c > diff --git a/tools/Makefile.am b/tools/Makefile.am > index e6ae15025..a8bd3d1c2 100644 > --- a/tools/Makefile.am > +++ b/tools/Makefile.am > @@ -142,6 +142,7 @@ virt_host_validate_SOURCES = \ > virt-host-validate-common.c virt-host-validate-common.h \ > virt-host-validate-qemu.c virt-host-validate-qemu.h \ > virt-host-validate-lxc.c virt-host-validate-lxc.h \ > + virt-host-validate-bhyve.c virt-host-validate-bhyve.h \ This will need a condition. virt-host-validate-bhyve.c is not really able to compile on Linux. Other sources should be conditionally included too. Something among these lines: diff --git i/tools/Makefile.am w/tools/Makefile.am index a8bd3d1c2..64d3af4f0 100644 --- i/tools/Makefile.am +++ w/tools/Makefile.am @@ -139,11 +139,28 @@ libvirt_shell_la_SOURCES = vsh.c vsh.h virt_host_validate_SOURCES = \ virt-host-validate.c \ - virt-host-validate-common.c virt-host-validate-common.h \ - virt-host-validate-qemu.c virt-host-validate-qemu.h \ - virt-host-validate-lxc.c virt-host-validate-lxc.h \ - virt-host-validate-bhyve.c virt-host-validate-bhyve.h \ - $(NULL) + virt-host-validate-common.c virt-host-validate-common.h + +VIRT_HOST_VALIDATE_QEMU = virt-host-validate-qemu.c virt-host-validate-qemu.h +VIRT_HOST_VALIDATE_LXC = virt-host-validate-lxc.c virt-host-validate-lxc.h +VIRT_HOST_VALIDATE_BHYVE = virt-host-validate-bhyve.c virt-host-validate-bhyve.h +if WITH_QEMU +virt_host_validate_SOURCES += $(VIRT_HOST_VALIDATE_QEMU) +else ! WITH_QEMU +EXTRA_DIST += $(VIRT_HOST_VALIDATE_QEMU) +endif ! WITH_QEMU + +if WITH_LXC +virt_host_validate_SOURCES += $(VIRT_HOST_VALIDATE_LXC) +else ! WITH_LXC +EXTRA_DIST += $(VIRT_HOST_VALIDATE_LXC) +endif ! WITH_LXC + +if WITH_BHYVE +virt_host_validate_SOURCES += $(VIRT_HOST_VALIDATE_BHYVE) +else ! WITH_BHYVE +EXTRA_DIST += $(VIRT_HOST_VALIDATE_BHYVE) +endif ! WITH_BHYVE virt_host_validate_LDFLAGS = \ $(AM_LDFLAGS) \ ACK with this squashed in. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Making containers creation easy
Hi all, I've worked on making the containers rootfs creation easy. Here is a wrap-up of my work: http://bosdonnat.fr/system-container-images.html Any opinion on that? Anything to do to move it forward? -- Cedric -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/6] bhyve: add support for booting from UEFI
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote:
> From: Fabian Freyer
>
> Allow to boot using UEFI rather than using an external boot loader
> such as bhyveload or grub-bhyve.
>
> Also, make LPC PCI-ISA bridge handling more flexible as now it's
> needed not only for serial ports, but for bootrom as well.
>
> Signed-off-by: Roman Bogorodskiy
> ---
> src/bhyve/bhyve_command.c | 30 +-
> src/bhyve/bhyve_driver.c | 27 +++
> src/bhyve/bhyve_process.c | 55
> +--
> 3 files changed, 81 insertions(+), 31 deletions(-)
>
> diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c
> index e7131625c..450800920 100644
> --- a/src/bhyve/bhyve_command.c
> +++ b/src/bhyve/bhyve_command.c
> @@ -163,7 +163,6 @@ bhyveBuildConsoleArgStr(const virDomainDef *def,
> virCommandPtr cmd)
> return -1;
> }
>
> -virCommandAddArgList(cmd, "-s", "1,lpc", NULL);
> virCommandAddArg(cmd, "-l");
> virCommandAddArgFormat(cmd, "com%d,%s",
> chr->target.port + 1,
> chr->source->data.file.path);
> @@ -283,6 +282,14 @@ bhyveBuildVirtIODiskArgStr(const virDomainDef *def
> ATTRIBUTE_UNUSED,
> return 0;
> }
>
> +static int
> +bhyveBuildLPCArgStr(const virDomainDef *def ATTRIBUTE_UNUSED,
> +virCommandPtr cmd)
> +{
> +virCommandAddArgList(cmd, "-s", "1,lpc", NULL);
> +return 0;
> +}
> +
> virCommandPtr
> virBhyveProcessBuildBhyveCmd(virConnectPtr conn,
> virDomainDefPtr def, bool dryRun)
> @@ -296,6 +303,7 @@ virBhyveProcessBuildBhyveCmd(virConnectPtr conn,
> *vm0
> */
> size_t i;
> +bool add_lpc = false;
>
> virCommandPtr cmd = virCommandNew(BHYVE);
>
> @@ -350,6 +358,21 @@ virBhyveProcessBuildBhyveCmd(virConnectPtr conn,
> virCommandAddArg(cmd, "-P"); /* vmexit from guest on pause */
>
> virCommandAddArgList(cmd, "-s", "0:0,hostbridge", NULL);
> +
> +if (def->os.bootloader == NULL &&
> +def->os.loader) {
> +if ((bhyveDriverGetCaps(conn) & BHYVE_CAP_LPC_BOOTROM)) {
> +virCommandAddArg(cmd, "-l");
> +virCommandAddArgFormat(cmd, "bootrom,%s", def->os.loader->path);
> +add_lpc = true;
> +} else {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> + _("Installed bhyve binary does not support "
> + "UEFI loader"));
> +goto error;
> +}
> +}
> +
> /* Devices */
> for (i = 0; i < def->ncontrollers; i++) {
> virDomainControllerDefPtr controller = def->controllers[i];
> @@ -389,8 +412,13 @@ virBhyveProcessBuildBhyveCmd(virConnectPtr conn,
> goto error;
> }
> }
> +
> +if (add_lpc || def->nserials)
> +bhyveBuildLPCArgStr(def, cmd);
> +
> if (bhyveBuildConsoleArgStr(def, cmd) < 0)
> goto error;
> +
> virCommandAddArg(cmd, def->name);
>
> return cmd;
> diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c
> index f4ccef32b..0f9961ae0 100644
> --- a/src/bhyve/bhyve_driver.c
> +++ b/src/bhyve/bhyve_driver.c
> @@ -734,15 +734,34 @@ bhyveConnectDomainXMLToNative(virConnectPtr conn,
> if (bhyveDomainAssignAddresses(def, NULL) < 0)
> goto cleanup;
>
> -if (!(loadcmd = virBhyveProcessBuildLoadCmd(conn, def, "",
> +if (def->os.bootloader == NULL &&
> +def->os.loader) {
> +
> +if ((def->os.loader->readonly != VIR_TRISTATE_BOOL_YES)
> +|| (def->os.loader->type != VIR_DOMAIN_LOADER_TYPE_PFLASH)) {
Please move the or operator at the end of the previous line.
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> + _("Only read-only pflash is supported."));
> +goto cleanup;
> +}
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 6/6] bhyve: test cases for VNC
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote: > Signed-off-by: Roman Bogorodskiy > --- > tests/bhyvexml2argvdata/bhyvexml2argv-vnc.args | 12 +++ > tests/bhyvexml2argvdata/bhyvexml2argv-vnc.ldargs | 1 + > tests/bhyvexml2argvdata/bhyvexml2argv-vnc.xml| 26 > > tests/bhyvexml2argvtest.c| 7 ++- > 4 files changed, 45 insertions(+), 1 deletion(-) > create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc.args > create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc.ldargs > create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc.xml > ACK Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/6] bhyve: enumerate UEFI firmwares
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote: > From: Fabian Freyer > > Signed-off-by: Roman Bogorodskiy > --- > src/bhyve/bhyve_capabilities.c | 28 > 1 file changed, 28 insertions(+) > ACK Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 5/6] bhyve: add video support
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote: > From: Fabian Freyer > > bhyve supports 'gop' video device that allows clients to connect > to VMs using VNC clients. This commit adds support for that to > the bhyve driver: > > - Introducr 'gop' video device type > - Add capabilities probing for the 'fbuf' device that's >responsible for graphics > - Update command builder routines to let users configure >domain's VNC via gop graphics. > > Signed-off-by: Roman Bogorodskiy > --- > docs/formatdomain.html.in | 3 +- > docs/schemas/domaincommon.rng | 1 + > po/POTFILES.in | 1 + > src/bhyve/bhyve_capabilities.c | 40 +++ > src/bhyve/bhyve_capabilities.h | 1 + > src/bhyve/bhyve_command.c | 100 > > src/bhyve/bhyve_device.c| 11 > src/conf/domain_conf.c | 5 +- > src/conf/domain_conf.h | 1 + > src/qemu/qemu_command.c | 9 ++-- > src/qemu/qemu_domain_address.c | 1 + > tests/domaincapsschemadata/full.xml | 1 + > 12 files changed, 169 insertions(+), 5 deletions(-) > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > index 0a115f5dc..b853a7245 100644 > --- a/docs/formatdomain.html.in > +++ b/docs/formatdomain.html.in > @@ -5812,8 +5812,9 @@ qemu-kvm -net nic,model=? /dev/null > >The model element has a mandatory type >attribute which takes the value "vga", "cirrus", "vmvga", "xen", > - "vbox", "qxl" (since 0.8.6) or > + "vbox", "qxl" (since 0.8.6), >"virtio" (since 1.3.0) > + or "gop" (since 3.1.0) since 3.2.0 actually :-) >depending on the hypervisor features available. > > ACK Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/6] bhyve: virBhyveProbeCaps: BHYVE_CAP_LPC_BOOTROM
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote:
> From: Fabian Freyer
>
> Implement the BHACE_CAP_LPC_BOOTROM capability by checking the stderr
> output of 'bhyve -l bootrom'. If the bootrom option is unsupported, this
> will contain the following output:
>
> bhyve: invalid lpc device configuration 'bootrom'
>
> On newer bhyve versions that do support specifying a bootrom image, the
> standard help will be printed.
> ---
> src/bhyve/bhyve_capabilities.c | 25 +
> src/bhyve/bhyve_capabilities.h | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
> index 1dc0593af..13b4835a8 100644
> --- a/src/bhyve/bhyve_capabilities.c
> +++ b/src/bhyve/bhyve_capabilities.c
> @@ -239,6 +239,28 @@ bhyveProbeCapsNetE1000(unsigned int *caps, char *binary)
> return ret;
> }
>
> +static int
> +bhyveProbeCapsLPC_Bootrom(unsigned int *caps, char *binary)
> +{
> +char *error;
> +virCommandPtr cmd = NULL;
> +int ret = -1, exit;
> +
> +cmd = virCommandNew(binary);
> +virCommandAddArgList(cmd, "-l", "bootrom", NULL);
> +virCommandSetErrorBuffer(cmd, &error);
> +if (virCommandRun(cmd, &exit) < 0)
> +goto cleanup;
> +
> +if (strstr(error, "bhyve: invalid lpc device configuration 'bootrom'")
> == NULL)
> +*caps |= BHYVE_CAP_LPC_BOOTROM;
> +
> + cleanup:
> +VIR_FREE(error);
> +virCommandFree(cmd);
> +return ret;
> +}
> +
> int
> virBhyveProbeCaps(unsigned int *caps)
> {
> @@ -260,6 +282,9 @@ virBhyveProbeCaps(unsigned int *caps)
> if ((ret = bhyveProbeCapsNetE1000(caps, binary)))
> goto out;
>
> +if ((ret = bhyveProbeCapsLPC_Bootrom(caps, binary)))
> +goto out;
> +
> out:
> VIR_FREE(binary);
> return ret;
> diff --git a/src/bhyve/bhyve_capabilities.h b/src/bhyve/bhyve_capabilities.h
> index 690feadb8..746c77181 100644
> --- a/src/bhyve/bhyve_capabilities.h
> +++ b/src/bhyve/bhyve_capabilities.h
> @@ -40,6 +40,7 @@ typedef enum {
> BHYVE_CAP_RTC_UTC = 1 << 0,
> BHYVE_CAP_AHCI32SLOT = 1 << 1,
> BHYVE_CAP_NET_E1000 = 1 << 2,
> +BHYVE_CAP_LPC_BOOTROM = 1 << 3,
> } virBhyveCapsFlags;
>
> int virBhyveProbeGrubCaps(virBhyveGrubCapsFlags *caps);
>
ACK, but we really need a better way to detect capabilites. For instance
now, bhyve binary is executed 4 times just to find out whether it
supports 4 capabilities. That's just madness. Maybe we can get in touch
with bhyve developers and ask them? Maybe it could have a monitor just
like qemu has, or something.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/6] bhyve: test cases for UEFI bhyvexml2argvtest
On 02/12/2017 04:12 PM, Roman Bogorodskiy wrote:
> From: Fabian Freyer
>
> Signed-off-by: Roman Bogorodskiy
> ---
> tests/bhyvexml2argvdata/bhyvexml2argv-uefi.args | 11 +++
> tests/bhyvexml2argvdata/bhyvexml2argv-uefi.ldargs | 1 +
> tests/bhyvexml2argvdata/bhyvexml2argv-uefi.xml| 23
> +++
> tests/bhyvexml2argvtest.c | 13 +++--
> 4 files changed, 46 insertions(+), 2 deletions(-)
> create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi.args
> create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi.ldargs
> create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi.xml
>
> diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-uefi.args
> b/tests/bhyvexml2argvdata/bhyvexml2argv-uefi.args
> new file mode 100644
> index 0..8ff8673ed
> --- /dev/null
> +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-uefi.args
> @@ -0,0 +1,11 @@
> +/usr/sbin/bhyve \
> +-c 1 \
> +-m 214 \
> +-u \
> +-H \
> +-P \
> +-s 0:0,hostbridge \
> +-l bootrom,/path/to/test.fd \
> +-s 2:0,ahci,hd:/tmp/freebsd.img \
> +-s 3:0,virtio-net,faketapdev,mac=52:54:00:00:00:00 \
> +-s 1,lpc bhyve
> diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-uefi.ldargs
> b/tests/bhyvexml2argvdata/bhyvexml2argv-uefi.ldargs
> new file mode 100644
> index 0..421376db9
> --- /dev/null
> +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-uefi.ldargs
> @@ -0,0 +1 @@
> +dummy
> diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-uefi.xml
> b/tests/bhyvexml2argvdata/bhyvexml2argv-uefi.xml
> new file mode 100644
> index 0..0b7d6bd27
> --- /dev/null
> +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-uefi.xml
> @@ -0,0 +1,23 @@
> +
> + bhyve
> + df3be7e7-a104-11e3-aeb0-50e5492bd3dc
> + 219136
> + 1
> +
> +hvm
> +/path/to/test.fd
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> + function='0x0'/>
> +
> +
> +
> diff --git a/tests/bhyvexml2argvtest.c b/tests/bhyvexml2argvtest.c
> index fb404f9fb..8567ceeae 100644
> --- a/tests/bhyvexml2argvtest.c
> +++ b/tests/bhyvexml2argvtest.c
> @@ -52,9 +52,13 @@ static int testCompareXMLToArgvFiles(const char *xml,
> conn->privateData = &driver;
>
> cmd = virBhyveProcessBuildBhyveCmd(conn, vmdef, false);
> -ldcmd = virBhyveProcessBuildLoadCmd(conn, vmdef, "",
> +if (!vmdef->os.loader)
> +ldcmd = virBhyveProcessBuildLoadCmd(conn, vmdef, "",
> &actualdm);
Misaligned line.
>
> +if ((ldcmd == NULL) && (vmdef->os.loader))
> +ldcmd = virCommandNew("dummy");
> +
Or:
if (vmdef->os.loader)
ldcmd = virCommandNew("dummy");
else
ldcmd = virBhyveProcessBuildLoadCmd(conn, vmdef, "",
&actualdm);
ACK if you fix it.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 1/2] qemu: Advertise ACPI support for aarch64 guests
On Wed, Mar 08, 2017 at 06:05:02PM +0100, Andrea Bolognani wrote: > On Wed, 2017-03-08 at 16:00 +, Daniel P. Berrange wrote: > > > So far, libvirt has assumed that only x86 supports ACPI, > > > but that's inaccurate since aarch64 supports it too. > > > > IIUC, it only supports ACPI if using the AAVMF firmware, right ? > > My current understanding is that ACPI on aarch64 requires > UEFI, not necessarily AAVMF. I'll admit I haven't really > considered other QEMU-compatible UEFI implementations, > though, assuming they exist. > > Laszlo? :) > > > I know that is the preferred firmware for aarch64, but IIUC it is > > not a hard requirement by QEMU. So even if we advertize it in the > > capabilities, we might need to still validate during CLI building > > that we're actually using AAVMF firmware. > > We currently require that ACPI is available when using UEFI, > even though as mentioned above I believe it should really > be the other way around. > > In any case, how would we validate that the pflash file > we're passing to QEMU does indeed contain AAVMF? I don't think we can, at least not right now. For the secure boot problem, we previously discussed create a standardized metadata file to accompany firmware images, which would declare what QEMU features the firmware supported. ACPI could fit into that world. It is probably time we got serious about actually doing this Meanwhile, we can just assume it supports ACPI. The scenario I was actually thinking of was direct kernel boot, rather than non-AAVMF impls of UEFI. IOW, where you just pass -kernel/-initrd/-dtb to QEMU and no firmware file. In that case, we should report an error if is requested in the XML IIUC. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 1/2] qemu: Advertise ACPI support for aarch64 guests
On Wed, 2017-03-08 at 16:00 +, Daniel P. Berrange wrote: > > So far, libvirt has assumed that only x86 supports ACPI, > > but that's inaccurate since aarch64 supports it too. > > IIUC, it only supports ACPI if using the AAVMF firmware, right ? My current understanding is that ACPI on aarch64 requires UEFI, not necessarily AAVMF. I'll admit I haven't really considered other QEMU-compatible UEFI implementations, though, assuming they exist. Laszlo? :) > I know that is the preferred firmware for aarch64, but IIUC it is > not a hard requirement by QEMU. So even if we advertize it in the > capabilities, we might need to still validate during CLI building > that we're actually using AAVMF firmware. We currently require that ACPI is available when using UEFI, even though as mentioned above I believe it should really be the other way around. In any case, how would we validate that the pflash file we're passing to QEMU does indeed contain AAVMF? -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] domain_conf: move iothread check for address type back to qemu_command
This partially reverts commit c96bd78e4e.
If an API virDomainAttachDevice(Flags) is used the device address
is assigned after the validation and the address type may not be set.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430275
Signed-off-by: Pavel Hrdina
---
src/conf/domain_conf.c | 18 --
src/qemu/qemu_command.c | 22 ++
2 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 97d42fe993..747706e673 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -4769,12 +4769,10 @@ virDomainDiskDefValidate(const virDomainDef *def,
}
if (disk->iothread > 0) {
-if (disk->bus != VIR_DOMAIN_DISK_BUS_VIRTIO ||
-(disk->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI &&
- disk->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW)) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("IOThreads are only available for virtio pci and "
- "virtio ccw disk"));
+if (disk->bus != VIR_DOMAIN_DISK_BUS_VIRTIO) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("IOThreads are not available for bus '%s', disk
'%s'"),
+ virDomainDiskBusTypeToString(disk->bus), disk->dst);
return -1;
}
@@ -4850,14 +4848,6 @@ virDomainControllerDefValidate(const virDomainDef *def,
return -1;
}
-if (cont->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI &&
-cont->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) {
-virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("IOThreads are only available for virtio pci and "
- "virtio ccw controllers"));
-return -1;
-}
-
if (!virDomainIOThreadIDFind(def, cont->iothread)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("Invalid IOThread id '%u' for controller '%s'"),
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 6545a93259..b49242a7df 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -1871,6 +1871,21 @@ qemuBuildDriveStr(virDomainDiskDefPtr disk,
}
+static int
+qemuBuildCheckIOThreadAddress(virDomainDeviceInfo info)
+{
+if (info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI &&
+info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("IOThreads are only available for virtio pci and "
+ "virtio ccw"));
+return -1;
+}
+
+return 0;
+}
+
+
char *
qemuBuildDriveDevStr(const virDomainDef *def,
virDomainDiskDefPtr disk,
@@ -1889,6 +1904,9 @@ qemuBuildDriveDevStr(const virDomainDef *def,
if (!qemuCheckCCWS390AddressSupport(def, disk->info, qemuCaps, disk->dst))
goto error;
+if (disk->iothread > 0 && qemuBuildCheckIOThreadAddress(disk->info) < 0)
+goto error;
+
switch (disk->bus) {
case VIR_DOMAIN_DISK_BUS_IDE:
if (disk->info.addr.drive.target != 0) {
@@ -2571,6 +2589,8 @@ qemuBuildControllerDevStr(const virDomainDef *domainDef,
if (def->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) {
virBufferAddLit(&buf, "virtio-scsi-ccw");
if (def->iothread) {
+if (qemuBuildCheckIOThreadAddress(def->info) < 0)
+goto error;
virBufferAsprintf(&buf, ",iothread=iothread%u",
def->iothread);
}
@@ -2583,6 +2603,8 @@ qemuBuildControllerDevStr(const virDomainDef *domainDef,
} else {
virBufferAddLit(&buf, "virtio-scsi-pci");
if (def->iothread) {
+if (qemuBuildCheckIOThreadAddress(def->info) < 0)
+goto error;
virBufferAsprintf(&buf, ",iothread=iothread%u",
def->iothread);
}
--
2.12.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] configure: disable scsi stroage driver on non-Linux
On 03/05/2017 03:20 PM, Roman Bogorodskiy wrote: > Even though scsi storage driver builds fine on non-Linux, it > will not work properly because it relies on Linux procfs, so > disable that in configure if we're not building for Linux. > --- > configure.ac | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure.ac b/configure.ac > index e61ab7ba6..cf50422d5 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -192,6 +192,7 @@ if test $with_linux = no; then > with_lxc=no > fi > with_dtrace=no > +with_storage_scsi=no > fi > > if test $with_freebsd = yes; then > ACK Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] doc: Correct the default werror policy
On Wed, Mar 01, 2017 at 08:44:54PM +0100, Philipp Hahn wrote: The documentation is plain wrong about the default write_error policy, as its only implemented by QEMU (src/vz/vz_utils.c is the only other case, which simply explodes, is anything except other then VIR_DOMAIN_DISK_ERROR_POLICY_DEFAULT is used). Sounds like bashing about some problem. Is there any bug somewhere? It does not add any useful information to the commit message, so I'll strip it off before pushing. So my question is; is there anything in that driver that needs fixing WRT this patch? And QEMUs default is VIR_DOMAIN_DISK_ERROR_POLICY_ENOSPACE. Signed-off-by: Philipp Hahn --- Osier Yang proposed v1 on 2011-10-24, which never got applied due to discussions of "enospace" vs. "enospc". v2: Remove internal QEMU default docs/formatdomain.html.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 02ce792..dc44a55 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -2745,7 +2745,8 @@ how the hypervisor will behave on a disk read or write error, possible values are "stop", "report", "ignore", and "enospace".Since 0.8.0, "report" since -0.9.7 The default setting of error_policy is "report". +0.9.7 The default is left to the discretion of the +hypervisor. There is also an optional rerror_policy that controls behavior for read errors only. Since @@ -2755,8 +2756,7 @@ read errors. Also note that "enospace" is not a valid policy for read errors, so if error_policy is set to "enospace" and no rerror_policy is -given, the read error policy will be left at its default, -which is "report". +given, the read error policy will be left at its default. The optional io attribute controls specific -- 2.1.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] doc: fix writing of QEMU
On Tue, Mar 07, 2017 at 06:09:58PM +0100, Philipp Hahn wrote: QEMU should be written all upper or all lower case. --- v2: Drop docs/news-* as they are historic. Drop po/*.po files as they are from extern. ChangeLog-old | 4 ++-- I also dropped this as it's even marked 'old' :) docs/formatnwfilter.html.in | 6 +++--- docs/storage.html.in | 12 ++-- libvirt.spec.in | 2 +- po/libvirt.pot| 2 +- This will be refreshed on release, so I dropped that as well. Even though I get why it would make sense, it would need a full refresh of all .po files and it will be refreshed during release anyway. Will push this in a while with those two changes dropped. signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 1/2] qemu: Advertise ACPI support for aarch64 guests
On Wed, Mar 08, 2017 at 04:56:30PM +0100, Andrea Bolognani wrote: > So far, libvirt has assumed that only x86 supports ACPI, > but that's inaccurate since aarch64 supports it too. > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509 > --- > Advertising ACPI support in capabilities means that tools > such as virt-manager will start automatically adding the > element for new guests. > > However, existing guests are likely to lack that element > and will suddenly lose ACPI capabilities: that could make > them unbootable if the guest OS only supports booting via > ACPI, which on the other hand is AFAIK not the case for > current mainstream OSs. Current Linux policy is to boot based on Device Tree, if both Device Tree & ACPI are advertized to the guest. If we stop advertizing ACPI for guests without , then QEMU would only present Device Tree, which is what any Linux guest will have already been using. So while you're right that this is a semantic change, I think it is reasonable to make this, as I expect the fallout to be minimal, and it is easy to deal with by just adding if it turned out to be a problem for specific guest OS types. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 1/2] qemu: Advertise ACPI support for aarch64 guests
On Wed, Mar 08, 2017 at 04:56:30PM +0100, Andrea Bolognani wrote: > So far, libvirt has assumed that only x86 supports ACPI, > but that's inaccurate since aarch64 supports it too. IIUC, it only supports ACPI if using the AAVMF firmware, right ? I know that is the preferred firmware for aarch64, but IIUC it is not a hard requirement by QEMU. So even if we advertize it in the capabilities, we might need to still validate during CLI building that we're actually using AAVMF firmware. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC PATCH 2/2] tests: Initialize basic capabilities properly
The capabilities used in test cases should match those used
during normal operation for the tests to make any sense.
---
src/qemu/qemu_capabilities.c | 2 ++
.../qemuxml2argv-balloon-ccw-deflate.args| 1 -
tests/qemuxml2argvdata/qemuxml2argv-console-sclp.args| 1 -
.../qemuxml2argv-console-virtio-ccw.args | 1 -
.../qemuxml2argv-console-virtio-s390.args| 1 -
.../qemuxml2argvdata/qemuxml2argv-cpu-s390-features.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-cpu-s390-zEC12.args | 1 -
.../qemuxml2argv-disk-virtio-ccw-many.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-ccw.args | 1 -
.../qemuxml2argvdata/qemuxml2argv-disk-virtio-s390.args | 1 -
.../qemuxml2argv-disk-virtio-scsi-ccw.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-fs9p-ccw.args| 1 -
.../qemuxml2argv-hostdev-scsi-vhost-scsi-ccw.args| 1 -
tests/qemuxml2argvdata/qemuxml2argv-hugepages-numa.args | 1 +
.../qemuxml2argv-iothreads-disk-virtio-ccw.args | 1 -
.../qemuxml2argv-iothreads-virtio-scsi-ccw.args | 1 -
.../qemuxml2argv-machine-aeskeywrap-off-cap.args | 1 -
.../qemuxml2argv-machine-aeskeywrap-off-caps.args| 1 -
.../qemuxml2argv-machine-aeskeywrap-on-cap.args | 1 -
.../qemuxml2argv-machine-aeskeywrap-on-caps.args | 1 -
.../qemuxml2argv-machine-deakeywrap-off-cap.args | 1 -
.../qemuxml2argv-machine-deakeywrap-off-caps.args| 1 -
.../qemuxml2argv-machine-deakeywrap-on-cap.args | 1 -
.../qemuxml2argv-machine-deakeywrap-on-caps.args | 1 -
.../qemuxml2argv-machine-keywrap-none-caps.args | 1 -
.../qemuxml2argv-machine-keywrap-none.args | 1 -
.../qemuxml2argv-memory-hotplug-ppc64-nonuma.args| 1 -
tests/qemuxml2argvdata/qemuxml2argv-net-virtio-ccw.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-net-virtio-s390.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args | 1 -
.../qemuxml2argv-pseries-cpu-compat.args | 1 -
.../qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-le.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-pseries-nvram.args | 1 -
.../qemuxml2argv-pseries-panic-missing.args | 1 -
.../qemuxml2argv-pseries-panic-no-address.args | 1 -
.../qemuxml2argv-pseries-usb-default.args| 1 -
tests/qemuxml2argvdata/qemuxml2argv-pseries-usb-kbd.args | 1 -
.../qemuxml2argvdata/qemuxml2argv-pseries-usb-multi.args | 1 -
.../qemuxml2argv-pseries-vio-user-assigned.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args | 1 -
.../qemuxml2argv-q35-virt-manager-basic.args | 1 +
.../qemuxml2argv-s390-allow-bogus-usb-controller.args| 1 -
.../qemuxml2argv-s390-allow-bogus-usb-none.args | 1 -
.../qemuxml2argv-s390-panic-missing.args | 1 -
.../qemuxml2argv-s390-panic-no-address.args | 1 -
tests/qemuxml2argvdata/qemuxml2argv-virtio-rng-ccw.args | 1 -
.../qemuxml2argvdata/qemuxml2argv-watchdog-diag288.args | 1 -
tests/qemuxml2argvtest.c | 16 ++--
51 files changed, 18 insertions(+), 49 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 4ec34f8..a2d8e9e 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -4231,6 +4231,8 @@ virQEMUCapsInitArchQMPBasic(virQEMUCapsPtr qemuCaps,
goto cleanup;
}
+/* Important: keep this in sync with testUpdateQEMUCaps() */
+
/* ACPI only works on x86 and aarch64 */
if (ARCH_IS_X86(qemuCaps->arch) ||
qemuCaps->arch == VIR_ARCH_AARCH64) {
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-balloon-ccw-deflate.args
b/tests/qemuxml2argvdata/qemuxml2argv-balloon-ccw-deflate.args
index 8565071..c8bb726 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-balloon-ccw-deflate.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-balloon-ccw-deflate.args
@@ -15,6 +15,5 @@ QEMU_AUDIO_DRV=none \
-nodefconfig \
-nodefaults \
-monitor unix:/tmp/lib/domain--1-QEMUGuest1/monitor.sock,server,nowait \
--no-acpi \
-boot c \
-device virtio-balloon-ccw,id=balloon0,devno=fe.0.000a,deflate-on-oom=on
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-console-sclp.args
b/tests/qemuxml2argvdata/qemuxml2argv-console-sclp.args
index dc9f7af..17f6055 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-console-sclp.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-console-sclp.args
@@ -17,7 +17,6 @@ QEMU_AUDIO_DRV=none \
-chardev
socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\
server,nowait \
-mon chardev=charmonitor,id=monitor,mode=readline \
-
[libvirt] [RFC PATCH 0/2] qemu: Fix ACPI on aarch64
Posted as RFC due to the concerns outlined in patch 1. Andrea Bolognani (2): qemu: Advertise ACPI support for aarch64 guests tests: Initialize basic capabilities properly src/qemu/qemu_capabilities.c | 30 +- .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + .../qemuxml2argv-balloon-ccw-deflate.args | 1 - .../qemuxml2argv-console-sclp.args | 1 - .../qemuxml2argv-console-virtio-ccw.args | 1 - .../qemuxml2argv-console-virtio-s390.args | 1 - .../qemuxml2argv-cpu-s390-features.args| 1 - .../qemuxml2argv-cpu-s390-zEC12.args | 1 - .../qemuxml2argv-disk-virtio-ccw-many.args | 1 - .../qemuxml2argv-disk-virtio-ccw.args | 1 - .../qemuxml2argv-disk-virtio-s390.args | 1 - .../qemuxml2argv-disk-virtio-scsi-ccw.args | 1 - tests/qemuxml2argvdata/qemuxml2argv-fs9p-ccw.args | 1 - .../qemuxml2argv-hostdev-scsi-vhost-scsi-ccw.args | 1 - .../qemuxml2argv-hugepages-numa.args | 1 + .../qemuxml2argv-iothreads-disk-virtio-ccw.args| 1 - .../qemuxml2argv-iothreads-virtio-scsi-ccw.args| 1 - .../qemuxml2argv-machine-aeskeywrap-off-cap.args | 1 - .../qemuxml2argv-machine-aeskeywrap-off-caps.args | 1 - .../qemuxml2argv-machine-aeskeywrap-on-cap.args| 1 - .../qemuxml2argv-machine-aeskeywrap-on-caps.args | 1 - .../qemuxml2argv-machine-deakeywrap-off-cap.args | 1 - .../qemuxml2argv-machine-deakeywrap-off-caps.args | 1 - .../qemuxml2argv-machine-deakeywrap-on-cap.args| 1 - .../qemuxml2argv-machine-deakeywrap-on-caps.args | 1 - .../qemuxml2argv-machine-keywrap-none-caps.args| 1 - .../qemuxml2argv-machine-keywrap-none.args | 1 - .../qemuxml2argv-memory-hotplug-ppc64-nonuma.args | 1 - .../qemuxml2argv-net-virtio-ccw.args | 1 - .../qemuxml2argv-net-virtio-s390.args | 1 - tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args | 1 - .../qemuxml2argv-ppce500-serial.args | 1 - .../qemuxml2argv-pseries-basic.args| 1 - .../qemuxml2argv-pseries-cpu-compat.args | 1 - .../qemuxml2argv-pseries-cpu-exact.args| 1 - .../qemuxml2argv-pseries-cpu-le.args | 1 - .../qemuxml2argv-pseries-nvram.args| 1 - .../qemuxml2argv-pseries-panic-missing.args| 1 - .../qemuxml2argv-pseries-panic-no-address.args | 1 - .../qemuxml2argv-pseries-usb-default.args | 1 - .../qemuxml2argv-pseries-usb-kbd.args | 1 - .../qemuxml2argv-pseries-usb-multi.args| 1 - .../qemuxml2argv-pseries-vio-user-assigned.args| 1 - .../qemuxml2argvdata/qemuxml2argv-pseries-vio.args | 1 - .../qemuxml2argv-q35-virt-manager-basic.args | 1 + ...muxml2argv-s390-allow-bogus-usb-controller.args | 1 - .../qemuxml2argv-s390-allow-bogus-usb-none.args| 1 - .../qemuxml2argv-s390-panic-missing.args | 1 - .../qemuxml2argv-s390-panic-no-address.args| 1 - .../qemuxml2argv-virtio-rng-ccw.args | 1 - .../qemuxml2argv-watchdog-diag288.args | 1 - tests/qemuxml2argvtest.c | 16 ++-- 53 files changed, 41 insertions(+), 56 deletions(-) -- 2.7.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC PATCH 1/2] qemu: Advertise ACPI support for aarch64 guests
So far, libvirt has assumed that only x86 supports ACPI,
but that's inaccurate since aarch64 supports it too.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
---
Advertising ACPI support in capabilities means that tools
such as virt-manager will start automatically adding the
element for new guests.
However, existing guests are likely to lack that element
and will suddenly lose ACPI capabilities: that could make
them unbootable if the guest OS only supports booting via
ACPI, which on the other hand is AFAIK not the case for
current mainstream OSs.
src/qemu/qemu_capabilities.c | 28 --
.../caps_2.6.0-gicv2.aarch64.xml | 1 +
.../caps_2.6.0-gicv3.aarch64.xml | 1 +
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 5a3b4ac..4ec34f8 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1038,13 +1038,17 @@ virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
machines = NULL;
nmachines = 0;
+}
+if ((ARCH_IS_X86(guestarch) || guestarch == VIR_ARCH_AARCH64) &&
+virCapabilitiesAddGuestFeature(guest, "acpi", true, true) == NULL) {
+goto cleanup;
}
if (ARCH_IS_X86(guestarch) &&
-(virCapabilitiesAddGuestFeature(guest, "acpi", true, true) == NULL ||
- virCapabilitiesAddGuestFeature(guest, "apic", true, false) == NULL))
+virCapabilitiesAddGuestFeature(guest, "apic", true, false) == NULL) {
goto cleanup;
+}
if ((guestarch == VIR_ARCH_I686) &&
(virCapabilitiesAddGuestFeature(guest, "pae", true, false) == NULL ||
@@ -4122,10 +4126,15 @@ virQEMUCapsInitHelp(virQEMUCapsPtr qemuCaps, uid_t
runUid, gid_t runGid, const c
qmperr) < 0)
goto cleanup;
-/* -no-acpi is not supported on non-x86
- * even if qemu reports it in -help */
-if (!ARCH_IS_X86(qemuCaps->arch))
+/* Older QEMU versions reported -no-acpi in the output of -help even
+ * though it was not supported by the architecture. The issue has since
+ * been fixed, but to maintain compatibility with all release we still
+ * need to filter out the capability for architectures that we know
+ * don't support the feature, eg. anything but x86 and aarch64 */
+if (!ARCH_IS_X86(qemuCaps->arch) &&
+qemuCaps->arch != VIR_ARCH_AARCH64) {
virQEMUCapsClear(qemuCaps, QEMU_CAPS_NO_ACPI);
+}
/* virQEMUCapsExtractDeviceStr will only set additional caps if qemu
* understands the 0.13.0+ notion of "-device driver,". */
@@ -4222,9 +4231,14 @@ virQEMUCapsInitArchQMPBasic(virQEMUCapsPtr qemuCaps,
goto cleanup;
}
-/* ACPI/HPET/KVM PIT are x86 specific */
-if (ARCH_IS_X86(qemuCaps->arch)) {
+/* ACPI only works on x86 and aarch64 */
+if (ARCH_IS_X86(qemuCaps->arch) ||
+qemuCaps->arch == VIR_ARCH_AARCH64) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI);
+}
+
+/* HPET and KVM PIT are x86 specific */
+if (ARCH_IS_X86(qemuCaps->arch)) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_HPET);
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
}
diff --git a/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
b/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
index 0aed651..b64a6f8 100644
--- a/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.6.0-gicv2.aarch64.xml
@@ -40,6 +40,7 @@
+
diff --git a/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
b/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
index 1041a12..46e368f 100644
--- a/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.6.0-gicv3.aarch64.xml
@@ -40,6 +40,7 @@
+
--
2.7.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 8/8] qemu: Introduce qemuDomainGetTLSObjects
On Wed, Mar 01, 2017 at 18:30:26 -0500, John Ferlan wrote: > Split apart and rename qemuDomainGetChardevTLSObjects in order to make a > more generic API that can create the TLS JSON prop objects (secret and > tls-creds-x509) to be used to create the objects > > Signed-off-by: John Ferlan > --- > src/qemu/qemu_hotplug.c | 55 > ++--- > src/qemu/qemu_hotplug.h | 11 ++ > 2 files changed, 40 insertions(+), 26 deletions(-) ACK Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 7/8] qemu: Move qemuDomainPrepareChardevSourceTLS call
On Wed, Mar 01, 2017 at 18:30:25 -0500, John Ferlan wrote: > Move the call to inside the qemuDomainAddChardevTLSObjects in order to > further converge the code. > > Signed-off-by: John Ferlan > --- > src/qemu/qemu_hotplug.c | 31 --- > 1 file changed, 12 insertions(+), 19 deletions(-) ACK Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 6/8] qemu: Move qemuDomainSecretChardevPrepare call
On Wed, Mar 01, 2017 at 18:30:24 -0500, John Ferlan wrote: > Move the call to inside the qemuDomainAddChardevTLSObjects in order to > further converge the code. > > Signed-off-by: John Ferlan > --- > src/qemu/qemu_hotplug.c | 33 +++-- > 1 file changed, 15 insertions(+), 18 deletions(-) ACK Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 5/8] qemu: Refactor qemuDomainGetChardevTLSObjects to converge code
On Wed, Mar 01, 2017 at 18:30:23 -0500, John Ferlan wrote: > Create a qemuDomainAddChardevTLSObjects which will encapsulate the > qemuDomainGetChardevTLSObjects and qemuDomainAddTLSObjects so that > the callers don't need to worry about the props. > > Move the dev->type and haveTLS checks in to the Add function to avoid > an unnecessary call to qemuDomainAddTLSObjects > > Signed-off-by: John Ferlan > --- > src/qemu/qemu_hotplug.c | 80 > ++--- > 1 file changed, 43 insertions(+), 37 deletions(-) ACK Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 0/3] libxl: nestedhvm support
On 03/08/2017 03:07 PM, Daniel P. Berrange wrote: > On Wed, Mar 08, 2017 at 03:09:11PM +, Joao Martins wrote: >> On 03/08/2017 02:13 PM, Daniel P. Berrange wrote: >>> On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote: From: Wim ten Have This patch enhances host-passthrough capability to advertise the required vendor CPU virtualization feature which will be used to enable 'nestedhvm' in the libxl driver. For Intel virtualization (VT-x) .. For AMD virtualization (AMD-V) .. >>> >>> If using host-passthrough or host-model, and the host's CPU includes >>> vmx or svm, then I would expecte nested-HVM to be enabled, without >>> needing any extra flag in the XML. That would match the >>> semantics used with the QEMU driver. >>> >>> The only time we would need to use is if using mode=custom >>> along with a named CPU model which lacks vmx/svm flags. >> Ah OK - I was kinda off unclear on that. So using host-passthrough should be >> enough then. (while making sure libxl checks if host->cpu does have vmx or >> svm >> in its features) >> >>> BTW, I wonder how hard it would be to wire up the libxl driver to use >>> the CPU model infrastructure in src/cpu ? It feels a little odd to use >>> XML if we're not then making sure it >>> actually uses host-passthrough when configuring the guest. >> While xen libxl do allow to mangle the cpuid, it is meant for disabling >> features >> at this point. libxl follows a "host-model" first, meaning the default is to >> expose as much as features as possible to the guest (depending on whether >> it's >> PV or HVM). However, nested virt is a slightly special case since the >> toolstack >> will do more than simply unmasking vmx/svm bits (actually within libxl, a >> sysctl >> to Xen is performed to enable nested virt to the domain, in which case libxc >> will handle any vendor specific bits). IOW, even when we improve libxl cpuid >> policy management to the point we can wire up to libvirt cpu model >> infrastruture, we would still need to handle the nestedhvm special case >> (which >> btw this field would work even for ARM whenever supported). > > Yep, I see. So with libxl using host-model by default, then > > - If the host CPU includes svm/vmx, turn on nested virt in the guest > - Allow use of to block nested >virt in the guest, even if available in host CPU Cool, thanks! Joao -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 0/3] libxl: nestedhvm support
On Wed, Mar 08, 2017 at 03:09:11PM +, Joao Martins wrote: > On 03/08/2017 02:13 PM, Daniel P. Berrange wrote: > > On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote: > >> From: Wim ten Have > >> > >> This patch enhances host-passthrough capability to advertise the > >> required vendor CPU virtualization feature which will be used to > >> enable 'nestedhvm' in the libxl driver. > >> > >> For Intel virtualization (VT-x) > >> .. > >> > >> > >> > >> > >> For AMD virtualization (AMD-V) > >> .. > >> > >> > >> > > > > If using host-passthrough or host-model, and the host's CPU includes > > vmx or svm, then I would expecte nested-HVM to be enabled, without > > needing any extra flag in the XML. That would match the > > semantics used with the QEMU driver. > > > > The only time we would need to use is if using mode=custom > > along with a named CPU model which lacks vmx/svm flags. > Ah OK - I was kinda off unclear on that. So using host-passthrough should be > enough then. (while making sure libxl checks if host->cpu does have vmx or svm > in its features) > > > BTW, I wonder how hard it would be to wire up the libxl driver to use > > the CPU model infrastructure in src/cpu ? It feels a little odd to use > > XML if we're not then making sure it > > actually uses host-passthrough when configuring the guest. > While xen libxl do allow to mangle the cpuid, it is meant for disabling > features > at this point. libxl follows a "host-model" first, meaning the default is to > expose as much as features as possible to the guest (depending on whether it's > PV or HVM). However, nested virt is a slightly special case since the > toolstack > will do more than simply unmasking vmx/svm bits (actually within libxl, a > sysctl > to Xen is performed to enable nested virt to the domain, in which case libxc > will handle any vendor specific bits). IOW, even when we improve libxl cpuid > policy management to the point we can wire up to libvirt cpu model > infrastruture, we would still need to handle the nestedhvm special case (which > btw this field would work even for ARM whenever supported). Yep, I see. So with libxl using host-model by default, then - If the host CPU includes svm/vmx, turn on nested virt in the guest - Allow use of to block nested virt in the guest, even if available in host CPU Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 0/3] libxl: nestedhvm support
On 03/08/2017 02:13 PM, Daniel P. Berrange wrote: > On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote: >> From: Wim ten Have >> >> This patch enhances host-passthrough capability to advertise the >> required vendor CPU virtualization feature which will be used to >> enable 'nestedhvm' in the libxl driver. >> >> For Intel virtualization (VT-x) >> .. >> >> >> >> >> For AMD virtualization (AMD-V) >> .. >> >> >> > > If using host-passthrough or host-model, and the host's CPU includes > vmx or svm, then I would expecte nested-HVM to be enabled, without > needing any extra flag in the XML. That would match the > semantics used with the QEMU driver. > > The only time we would need to use is if using mode=custom > along with a named CPU model which lacks vmx/svm flags. Ah OK - I was kinda off unclear on that. So using host-passthrough should be enough then. (while making sure libxl checks if host->cpu does have vmx or svm in its features) > BTW, I wonder how hard it would be to wire up the libxl driver to use > the CPU model infrastructure in src/cpu ? It feels a little odd to use > XML if we're not then making sure it > actually uses host-passthrough when configuring the guest. While xen libxl do allow to mangle the cpuid, it is meant for disabling features at this point. libxl follows a "host-model" first, meaning the default is to expose as much as features as possible to the guest (depending on whether it's PV or HVM). However, nested virt is a slightly special case since the toolstack will do more than simply unmasking vmx/svm bits (actually within libxl, a sysctl to Xen is performed to enable nested virt to the domain, in which case libxc will handle any vendor specific bits). IOW, even when we improve libxl cpuid policy management to the point we can wire up to libvirt cpu model infrastruture, we would still need to handle the nestedhvm special case (which btw this field would work even for ARM whenever supported). Joao -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 4/8] qemu: Refactor hotplug to introduce qemuDomain{Add|Del}TLSObjects
On Wed, Mar 01, 2017 at 18:30:22 -0500, John Ferlan wrote: > Refactor the TLS object adding code to make two separate API's that will > handle the add/remove of the "secret" and "tls-creds-x509" objects including > the Enter/Exit monitor commands. > > Signed-off-by: John Ferlan > --- > src/qemu/qemu_hotplug.c | 165 > +++- > src/qemu/qemu_hotplug.h | 13 > 2 files changed, 107 insertions(+), 71 deletions(-) ACK Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemuTestDriverInit: Don't access live data
On Wed, Mar 08, 2017 at 10:48:15AM +0100, Michal Privoznik wrote:
On 03/08/2017 10:15 AM, Martin Kletzander wrote:
On Mon, Mar 06, 2017 at 08:38:00AM +0100, Michal Privoznik wrote:
Some of our tests (e.g. qemuhotplugtest) call
virDomainSaveConfig(). Now the problem is, qemuTestDriverInit()
creates a fake qemu driver and fills it with some fake
configuration. At least so we hoped. The truth is, it calls
regular virQEMUDriverConfigNew() and then fix couple of paths.
Literally. Therefore our tests see regular stateDir and configDir
for the user that is running the tests. Directories, where live
domain XMLs are stored. Let's just hope our test suite hasn't
mangled any of them.
Signed-off-by: Michal Privoznik
---
tests/testutilsqemu.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c
index 56a89c913..0726cd317 100644
--- a/tests/testutilsqemu.c
+++ b/tests/testutilsqemu.c
@@ -513,6 +513,10 @@ qemuTestParseCapabilities(virCapsPtr caps,
void qemuTestDriverFree(virQEMUDriver *driver)
{
virMutexDestroy(&driver->lock);
+if (driver->config) {
+virFileDeleteTree(driver->config->stateDir);
+virFileDeleteTree(driver->config->configDir);
+}
virQEMUCapsCacheFree(driver->qemuCapsCache);
virObjectUnref(driver->xmlopt);
virObjectUnref(driver->caps);
@@ -548,9 +552,14 @@ int qemuTestCapsCacheInsert(virQEMUCapsCachePtr
cache, const char *binary,
return ret;
}
+# define STATEDIRTEMPLATE abs_builddir "/qemustatedir-XX"
+# define CONFIGDIRTEMPLATE abs_builddir "/qemuconfigdir-XX"
+
int qemuTestDriverInit(virQEMUDriver *driver)
{
virSecurityManagerPtr mgr = NULL;
+char statedir[] = STATEDIRTEMPLATE;
+char configdir[] = CONFIGDIRTEMPLATE;
There's no point in creating these variables, otherwise ACK.
There is a point; mkdtemp() uses the passed variable for both input and
output. On function enter the file pattern is stored there, on function
return the actual dirname that was created is stored there. Calling
mkdir(STATEDIRTEMPLATE) would lead to sigsegv I guess. Let me try. Yeah,
my guess was right.
Pushed without any change. Thank you.
Stupid me, I totally forgot about the mkdtemp(), thanks for understanding.
Michal
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 3/8] qemu: Move exit monitor calls in failure paths
On Wed, Mar 01, 2017 at 18:30:21 -0500, John Ferlan wrote: > Since qemuDomainObjExitMonitor can also generate error messages, > let's move it inside any error message saving code on error paths > for various hotplug add activities. > > Signed-off-by: John Ferlan > --- > src/qemu/qemu_hotplug.c | 31 +++ > 1 file changed, 15 insertions(+), 16 deletions(-) ACK Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 2/8] qemu: Introduce qemuDomainSecretInfoTLSNew
On Wed, Mar 01, 2017 at 18:30:20 -0500, John Ferlan wrote: > Building upon the qemuDomainSecretInfoNew, create a helper which will > build the secret used for TLS. > > Signed-off-by: John Ferlan > --- > src/qemu/qemu_domain.c | 59 > ++ > 1 file changed, 40 insertions(+), 19 deletions(-) ACK Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 1/8] qemu: Introduce qemuDomainSecretInfoNew
On Wed, Mar 01, 2017 at 18:30:19 -0500, John Ferlan wrote: > Create a helper which will create the secinfo used for disks, hostdevs, > and chardevs. > > Signed-off-by: John Ferlan > --- > src/qemu/qemu_domain.c | 137 > + > 1 file changed, 71 insertions(+), 66 deletions(-) > > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c > index c187214..f8ac0f4 100644 > --- a/src/qemu/qemu_domain.c > +++ b/src/qemu/qemu_domain.c > @@ -1112,6 +1112,52 @@ qemuDomainSecretSetup(virConnectPtr conn, > } > > > +/* qemuDomainSecretInfoNew: > + * @conn: Pointer to connection > + * @priv: pointer to domain private object > + * @srcAlias: Alias base to use for TLS object > + * @lookupType: Type of secret lookup You forgot to change the documentation here. > + * @username: username for plain secrets (only) > + * @looupdef: lookup def describing secret > + * @isLuks: boolean for luks lookup > + * > + * Helper function to create a secinfo to be used for secinfo consumers > + * > + * Returns @secinfo on success, NULL on failure. Caller is responsible > + * to eventually free @secinfo. > + */ > +static qemuDomainSecretInfoPtr > +qemuDomainSecretInfoNew(virConnectPtr conn, > +qemuDomainObjPrivatePtr priv, > +const char *srcAlias, > +virSecretUsageType secretUsageType, secretUsageType seems to be a bit too verbose given that we are in a *SecretInfoNew function. Keep it if you like it or change it to usageType. > +const char *username, > +virSecretLookupTypeDefPtr lookupDef, > +bool isLuks) ... ACK Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 0/3] libxl: nestedhvm support
On Wed, Mar 08, 2017 at 03:07:12PM +0100, Wim Ten Have wrote: > From: Wim ten Have > > This patch enhances host-passthrough capability to advertise the > required vendor CPU virtualization feature which will be used to > enable 'nestedhvm' in the libxl driver. > > For Intel virtualization (VT-x) > .. > > > > > For AMD virtualization (AMD-V) > .. > > > If using host-passthrough or host-model, and the host's CPU includes vmx or svm, then I would expecte nested-HVM to be enabled, without needing any extra flag in the XML. That would match the semantics used with the QEMU driver. The only time we would need to use is if using mode=custom along with a named CPU model which lacks vmx/svm flags. BTW, I wonder how hard it would be to wire up the libxl driver to use the CPU model infrastructure in src/cpu ? It feels a little odd to use XML if we're not then making sure it actually uses host-passthrough when configuring the guest. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v1 0/3] libxl: nestedhvm support
From: Wim ten Have This patch enhances host-passthrough capability to advertise the required vendor CPU virtualization feature which will be used to enable 'nestedhvm' in the libxl driver. For Intel virtualization (VT-x) .. For AMD virtualization (AMD-V) .. Joao Martins (2): libxl: set nestedhvm when vmx|svm is required xenconfig: add conversion of domxml nestedhvm Wim ten Have (1): xlconfigtest: add test and data for 'nestedhvm' support src/libxl/libxl_conf.c | 9 src/xenconfig/xen_xl.c | 41 + tests/xlconfigdata/test-fullvirt-nestedhvm.cfg | 26 +++ tests/xlconfigdata/test-fullvirt-nestedhvm.xml | 61 ++ tests/xlconfigtest.c | 1 + 5 files changed, 138 insertions(+) create mode 100644 tests/xlconfigdata/test-fullvirt-nestedhvm.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-nestedhvm.xml -- 2.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v1 2/3] xenconfig: add conversion of domxml nestedhvm
From: Joao Martins
In other words, on configurations containing (within its
CPU element) one of the following for a host-passthrough
mode:
It will then generate (or parse) for nestedhvm=1 in/from xl format.
Signed-off-by: Joao Martins
Signed-off-by: Wim ten Have
---
src/xenconfig/xen_xl.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
index 74f68b3..738dcd0 100644
--- a/src/xenconfig/xen_xl.c
+++ b/src/xenconfig/xen_xl.c
@@ -106,6 +106,7 @@ xenParseXLOS(virConfPtr conf, virDomainDefPtr def,
virCapsPtr caps)
if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) {
const char *bios;
const char *boot;
+int val;
if (xenConfigGetString(conf, "bios", &bios, NULL) < 0)
return -1;
@@ -164,6 +165,35 @@ xenParseXLOS(virConfPtr conf, virDomainDefPtr def,
virCapsPtr caps)
}
def->os.nBootDevs++;
}
+
+if (xenConfigGetBool(conf, "nestedhvm", &val, 0) < 0) {
+return -1;
+} else if (val) {
+virCPUDefPtr cpu = NULL;
+
+if (VIR_ALLOC(cpu) < 0)
+return -1;
+
+if (VIR_ALLOC_N(cpu->features, 1) < 0)
+goto cleanup;
+
+cpu->features[0].policy = VIR_CPU_FEATURE_REQUIRE;
+if (VIR_STRDUP(cpu->features[0].name, "vmx") < 0)
+goto cleanup;
+
+cpu->nfeatures = cpu->nfeatures_max = 1;
+cpu->mode = VIR_CPU_MODE_HOST_PASSTHROUGH;
+cpu->type = VIR_CPU_TYPE_GUEST;
+def->cpu = cpu;
+cpu = NULL;
+
+ cleanup:
+if (cpu) {
+VIR_FREE(cpu->features);
+VIR_FREE(cpu);
+return -1;
+}
+}
} else {
if (xenConfigCopyStringOpt(conf, "bootloader", &def->os.bootloader) <
0)
return -1;
@@ -897,6 +927,17 @@ xenFormatXLOS(virConfPtr conf, virDomainDefPtr def)
if (xenConfigSetString(conf, "boot", boot) < 0)
return -1;
+if (def->cpu && def->cpu->nfeatures) {
+for (i = 0; i < def->cpu->nfeatures; i++) {
+if (def->cpu->features[i].policy == VIR_CPU_FEATURE_REQUIRE &&
+(STREQ(def->cpu->features[i].name, "vmx") ||
+ STREQ(def->cpu->features[i].name, "svm")))
+if (xenConfigSetInt(conf, "nestedhvm", 1) < 0)
+return -1;
+}
+}
+
+
/* XXX floppy disks */
} else {
if (def->os.bootloader &&
--
2.9.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v1 1/3] libxl: set nestedhvm when vmx|svm is required
From: Joao Martins
nestedhvm is the option on Xen 4.4+ which enables nested
virtualization on Xen. We set this field when one of the
following features is included in a host-passthrough CPU
element:
or:
Signed-off-by: Joao Martins
Signed-off-by: Wim ten Have
---
src/libxl/libxl_conf.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index f5b788b..8c4c511 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -374,6 +374,15 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
def->features[VIR_DOMAIN_FEATURE_ACPI] ==
VIR_TRISTATE_SWITCH_ON);
+if (def->cpu && def->cpu->nfeatures) {
+for (i = 0; i < def->cpu->nfeatures; i++) {
+if (def->cpu->features[i].policy == VIR_CPU_FEATURE_REQUIRE &&
+(STREQ(def->cpu->features[i].name, "vmx") ||
+ STREQ(def->cpu->features[i].name, "svm")))
+libxl_defbool_set(&b_info->u.hvm.nested_hvm, true);
+}
+}
+
if (def->nsounds > 0) {
/*
* Use first sound device. man xl.cfg(5) describes soundhw as
--
2.9.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v1 3/3] xlconfigtest: add test and data for 'nestedhvm' support
From: Wim ten Have
Configurations containing (within its CPU element) following:
Intel virtualization (VT-x):
AMD virtualization (AMD-V):
generate nestedhvm=1 in/from xl format.
Signed-off-by: Wim ten Have
---
tests/xlconfigdata/test-fullvirt-nestedhvm.cfg | 26 +++
tests/xlconfigdata/test-fullvirt-nestedhvm.xml | 61 ++
tests/xlconfigtest.c | 1 +
3 files changed, 88 insertions(+)
create mode 100644 tests/xlconfigdata/test-fullvirt-nestedhvm.cfg
create mode 100644 tests/xlconfigdata/test-fullvirt-nestedhvm.xml
diff --git a/tests/xlconfigdata/test-fullvirt-nestedhvm.cfg
b/tests/xlconfigdata/test-fullvirt-nestedhvm.cfg
new file mode 100644
index 000..281f126
--- /dev/null
+++ b/tests/xlconfigdata/test-fullvirt-nestedhvm.cfg
@@ -0,0 +1,26 @@
+name = "XenGuest2"
+uuid = "c7a5fdb2-cdaf-9455-926a-d65c16db1809"
+maxmem = 579
+memory = 394
+vcpus = 1
+pae = 1
+acpi = 1
+apic = 1
+viridian = 0
+rtc_timeoffset = 0
+localtime = 0
+on_poweroff = "destroy"
+on_reboot = "restart"
+on_crash = "restart"
+device_model = "/usr/lib/xen/bin/qemu-system-i386"
+sdl = 0
+vnc = 1
+vncunused = 1
+vnclisten = "127.0.0.1"
+vif = [ "mac=00:16:3e:66:92:9c,bridge=xenbr1,script=vif-bridge,model=e1000" ]
+parallel = "none"
+serial = "none"
+builder = "hvm"
+boot = "d"
+nestedhvm = 1
+disk = [
"format=raw,vdev=hda,access=rw,backendtype=phy,target=/dev/HostVG/XenGuest2",
"format=qcow2,vdev=hdb,access=rw,backendtype=qdisk,target=/var/lib/libvirt/images/XenGuest2-home",
"format=raw,vdev=hdc,access=ro,backendtype=qdisk,devtype=cdrom,target=/root/boot.iso"
]
diff --git a/tests/xlconfigdata/test-fullvirt-nestedhvm.xml
b/tests/xlconfigdata/test-fullvirt-nestedhvm.xml
new file mode 100644
index 000..a1f637a
--- /dev/null
+++ b/tests/xlconfigdata/test-fullvirt-nestedhvm.xml
@@ -0,0 +1,61 @@
+
+ XenGuest2
+ c7a5fdb2-cdaf-9455-926a-d65c16db1809
+ 592896
+ 403456
+ 1
+
+hvm
+/usr/lib/xen/boot/hvmloader
+
+
+
+
+
+
+
+
+
+
+
+ destroy
+ restart
+ restart
+
+/usr/lib/xen/bin/qemu-system-i386
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/tests/xlconfigtest.c b/tests/xlconfigtest.c
index e74e4d6..d2cc950 100644
--- a/tests/xlconfigtest.c
+++ b/tests/xlconfigtest.c
@@ -268,6 +268,7 @@ mymain(void)
DO_TEST("fullvirt-hpet-timer");
DO_TEST("fullvirt-tsc-timer");
DO_TEST("fullvirt-multi-timer");
+DO_TEST("fullvirt-nestedhvm");
DO_TEST("paravirt-cmdline");
DO_TEST_FORMAT("paravirt-cmdline-extra-root", false);
--
2.9.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 6/7] qemu: Report better host-model CPUs in domain caps
One of the main reasons for introducing host-model CPU definition in a
domain capabilities XML was the inability to express disabled features
in a host capabilities XML. That is, when a host CPU is, e.g., Haswell
without x2apic support, host capabilities XML will have to report it as
Westmere + a bunch of additional features., but we really want to use
Haswell - x2apic when creating a host-model CPU.
Unfortunately, I somehow forgot to do the last step and the code would
just copy the CPU definition found in the host capabilities XML. This
changed recently for new QEMU versions which allow us to query host CPU,
but any slightly older QEMU will not benefit from any change I did. This
patch makes sure the right CPU model is filled in the domain
capabilities even with old QEMU.
The issue was reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1426456
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_capabilities.c | 32
src/qemu/qemu_capspriv.h | 5 +
tests/Makefile.am| 11 +--
tests/domaincapstest.c | 6 ++
tests/qemucpumock.c | 35 +++
tests/qemuxml2argvtest.c | 6 --
6 files changed, 87 insertions(+), 8 deletions(-)
create mode 100644 tests/qemucpumock.c
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 08c66b088..70f9ed777 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1074,6 +1074,26 @@ virQEMUCapsProbeHostCPU(virCapsPtr caps)
}
+virCPUDefPtr
+virQEMUCapsProbeHostCPUForEmulator(virCapsPtr caps,
+ virQEMUCapsPtr qemuCaps,
+ virDomainVirtType type)
+{
+size_t nmodels;
+char **models;
+virCPUDefPtr cpu;
+
+if (virQEMUCapsGetCPUDefinitions(qemuCaps, type, &models, &nmodels) < 0)
+return NULL;
+
+cpu = virCPUGetHost(caps->host.arch, VIR_CPU_TYPE_GUEST, NULL,
+(const char **) models, nmodels);
+
+virStringListFreeCount(models, nmodels);
+return cpu;
+}
+
+
static int
virQEMUCapsInitPages(virCapsPtr caps)
{
@@ -3207,6 +3227,7 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
virCPUDefPtr cpu = NULL;
+virCPUDefPtr hostCPU = NULL;
int rc;
if (!caps || !virQEMUCapsGuestIsNative(caps->host.arch, qemuCaps->arch))
@@ -3223,11 +3244,11 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
if ((rc = virQEMUCapsInitCPUModel(qemuCaps, type, cpu)) < 0) {
goto error;
} else if (rc == 1) {
-VIR_DEBUG("No host CPU model info from QEMU; using host capabilities");
-if (!caps->host.cpu || !caps->host.cpu->model)
-goto error;
+VIR_DEBUG("No host CPU model info from QEMU; probing host CPU
directly");
-if (virCPUDefCopyModelFilter(cpu, caps->host.cpu, true,
+hostCPU = virQEMUCapsProbeHostCPUForEmulator(caps, qemuCaps, type);
+if (!hostCPU ||
+virCPUDefCopyModelFilter(cpu, hostCPU, true,
virQEMUCapsCPUFilterFeatures,
qemuCaps) < 0)
goto error;
@@ -3238,11 +3259,14 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
else
qemuCaps->tcgCPUModel = cpu;
+ cleanup:
+virCPUDefFree(hostCPU);
return;
error:
virCPUDefFree(cpu);
virResetLastError();
+goto cleanup;
}
diff --git a/src/qemu/qemu_capspriv.h b/src/qemu/qemu_capspriv.h
index e0544f273..ee29b8bba 100644
--- a/src/qemu/qemu_capspriv.h
+++ b/src/qemu/qemu_capspriv.h
@@ -87,4 +87,9 @@ void
virQEMUCapsSetCPUModelInfo(virQEMUCapsPtr qemuCaps,
virDomainVirtType type,
qemuMonitorCPUModelInfoPtr modelInfo);
+
+virCPUDefPtr
+virQEMUCapsProbeHostCPUForEmulator(virCapsPtr caps,
+ virQEMUCapsPtr qemuCaps,
+ virDomainVirtType type);
#endif
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 35e82abf5..af69a3a84 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -284,6 +284,7 @@ test_libraries += libqemumonitortestutils.la \
qemuxml2xmlmock.la \
qemucaps2xmlmock.la \
qemucapsprobemock.la \
+ qemucpumock.la \
$(NULL)
endif WITH_QEMU
@@ -549,10 +550,16 @@ libqemutestdriver_la_SOURCES =
libqemutestdriver_la_LDFLAGS = $(QEMULIB_LDFLAGS)
libqemutestdriver_la_LIBADD = $(qemu_LDADDS)
+qemucpumock_la_SOURCES = \
+ qemucpumock.c
+qemucpumock_la_CFLAGS = $(AM_CFLAGS)
+qemucpumock_la_LDFLAGS = $(MOCKLIBS_LDFLAGS)
+qemucpumock_la_LIBADD = $(MOCKLIBS_LIBS)
+
qemuxml2argvtest_SOURCES = \
qemuxml2argvtest.c testutilsqemu.c testutilsqemu.h \
testutils.c testutils.h
-qemuxml2argvtest_LDADD = $(qemu_LDADDS) $(LDADDS) $(LIBXML_LIBS)
+qem
[libvirt] [PATCH 7/7] cputest: New test for Intel Core i7-4510U
Signed-off-by: Jiri Denemark
---
Notes:
This is the host CPU which allowed me to find the missing functionality,
but I haven't quite figured out how to test this stuff all the way up
to domain capabilities XML. Let's just add it to the low level tests
for now.
tests/cputest.c| 1 +
.../x86_64-cpuid-Core-i7-4510U-guest.xml | 29 +++
.../x86_64-cpuid-Core-i7-4510U-host.xml| 44 +
.../x86_64-cpuid-Core-i7-4510U-json.xml| 15 ++
tests/cputestdata/x86_64-cpuid-Core-i7-4510U.json | 203 +
tests/cputestdata/x86_64-cpuid-Core-i7-4510U.xml | 34
6 files changed, 326 insertions(+)
create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-4510U-guest.xml
create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-4510U-host.xml
create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-4510U-json.xml
create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-4510U.json
create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-4510U.xml
diff --git a/tests/cputest.c b/tests/cputest.c
index 685aca152..5e205c501 100644
--- a/tests/cputest.c
+++ b/tests/cputest.c
@@ -827,6 +827,7 @@ mymain(void)
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-3740QM", true);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-3770", true);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-4600U", true);
+DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-4510U", true);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-5600U", true);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core2-E6850", true);
DO_TEST_CPUID(VIR_ARCH_X86_64, "Core2-Q9500", false);
diff --git a/tests/cputestdata/x86_64-cpuid-Core-i7-4510U-guest.xml
b/tests/cputestdata/x86_64-cpuid-Core-i7-4510U-guest.xml
new file mode 100644
index 0..bcce4ece1
--- /dev/null
+++ b/tests/cputestdata/x86_64-cpuid-Core-i7-4510U-guest.xml
@@ -0,0 +1,29 @@
+
+ Haswell-noTSX
+ Intel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/tests/cputestdata/x86_64-cpuid-Core-i7-4510U-host.xml
b/tests/cputestdata/x86_64-cpuid-Core-i7-4510U-host.xml
new file mode 100644
index 0..61bcefbfc
--- /dev/null
+++ b/tests/cputestdata/x86_64-cpuid-Core-i7-4510U-host.xml
@@ -0,0 +1,44 @@
+
+ x86_64
+ Westmere
+ Intel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/tests/cputestdata/x86_64-cpuid-Core-i7-4510U-json.xml
b/tests/cputestdata/x86_64-cpuid-Core-i7-4510U-json.xml
new file mode 100644
index 0..3ca3b0f24
--- /dev/null
+++ b/tests/cputestdata/x86_64-cpuid-Core-i7-4510U-json.xml
@@ -0,0 +1,15 @@
+
+ Haswell-noTSX
+ Intel
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/tests/cputestdata/x86_64-cpuid-Core-i7-4510U.json
b/tests/cputestdata/x86_64-cpuid-Core-i7-4510U.json
new file mode 100644
index 0..3cbcdff5c
--- /dev/null
+++ b/tests/cputestdata/x86_64-cpuid-Core-i7-4510U.json
@@ -0,0 +1,203 @@
+{
+ "return": {
+"model": {
+ "name": "base",
+ "props": {
+"pfthreshold": false,
+"pku": false,
+"rtm": false,
+"tsc_adjust": true,
+"tsc-deadline": true,
+"xstore-en": false,
+"tsc-scale": false,
+"sse": true,
+"smap": false,
+"stepping": 1,
+"tce": false,
+"kvm_steal_time": true,
+"smep": true,
+"rdpid": false,
+"xcrypt": false,
+"sse4_2": true,
+"monitor": false,
+"sse4_1": true,
+"kvm-mmu": false,
+"flushbyasid": false,
+"kvm-steal-time": true,
+"lm": true,
+"tsc": true,
+"adx": false,
+"fxsr": true,
+"sha-ni": false,
+"tm": false,
+"pclmuldq": true,
+"xgetbv1": false,
+"xstore": false,
+"vmcb_clean": false,
+"vme": true,
+"vendor": "GenuineIntel",
+"arat": true,
+"ffxsr": false,
+"de": true,
+"avx512f": false,
+"pse": true,
+"ds-cpl": false,
+"tbm": false,
+"ia64": false,
+"phe-en": false,
+"f16c": true,
+"ds": false,
+"mpx": false,
+"tsc-adjust": true,
+"aes": true,
+"avx2": true,
+"pbe": false,
+"cx16": true,
+"ds_cpl": false,
+"movbe": true,
+"perfctr-nb": false,
+"nrip_save": false,
+"kvm_mmu": false,
+"ospke": false,
+"avx512ifma": false,
+"vmx": true,
+"sep": true,
+"xsaveopt": true,
+"sse4a": false,
+"avx512dq": false,
+"i64": true,
+"avx512-4vnniw": false,
+"xsave": true,
+"erms": true,
+"hle": false,
+"nodeid_msr": false,
+"est": false,
+"svm_lock": false,
+"xop": false,
+"model-id": "Int
[libvirt] [PATCH 5/7] qemu: Refactor virQEMUCapsInitCPU
The function is now called virQEMUCapsProbeHostCPU. Both the refactoring
and the change of the name is done for consistency with a new function
which will be introduced in the following commit.
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_capabilities.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 319600c30..08c66b088 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1061,20 +1061,16 @@ virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
}
-static int
-virQEMUCapsInitCPU(virCapsPtr caps,
- virArch arch)
+static virCPUDefPtr
+virQEMUCapsProbeHostCPU(virCapsPtr caps)
{
virNodeInfo nodeinfo;
if (nodeGetInfo(&nodeinfo))
-return -1;
+return NULL;
-if (!(caps->host.cpu = virCPUGetHost(arch, VIR_CPU_TYPE_HOST,
- &nodeinfo, NULL, 0)))
-return -1;
-
-return 0;
+return virCPUGetHost(caps->host.arch, VIR_CPU_TYPE_HOST,
+ &nodeinfo, NULL, 0);
}
@@ -1120,7 +1116,7 @@ virCapsPtr virQEMUCapsInit(virQEMUCapsCachePtr cache)
VIR_WARN("Failed to query host NUMA topology, disabling NUMA
capabilities");
}
-if (virQEMUCapsInitCPU(caps, hostarch) < 0)
+if (!(caps->host.cpu = virQEMUCapsProbeHostCPU(caps)))
VIR_WARN("Failed to get host CPU");
/* Add the power management features of the host */
--
2.12.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/7] qemu: Report better host-model CPUs in domain caps
One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Jiri Denemark (7): Do not format in guest CPU XML cpu: Replace cpuNodeData with virCPUGetHost cpu: Add virCPUType parameter to virCPUGetHost cpu: Add list of allowed CPU models to virCPUGetHost qemu: Refactor virQEMUCapsInitCPU qemu: Report better host-model CPUs in domain caps cputest: New test for Intel Core i7-4510U src/bhyve/bhyve_capabilities.c | 35 +--- src/conf/cpu_conf.c| 2 +- src/cpu/cpu.c | 100 -- src/cpu/cpu.h | 16 +- src/cpu/cpu_arm.c | 1 - src/cpu/cpu_ppc64.c| 30 +-- src/cpu/cpu_s390.c | 1 - src/cpu/cpu_x86.c | 29 ++- src/libvirt_private.syms | 2 +- src/qemu/qemu_capabilities.c | 61 +++ src/qemu/qemu_capspriv.h | 5 + src/vmware/vmware_conf.c | 20 +- src/vz/vz_driver.c | 22 +-- tests/Makefile.am | 11 +- tests/cputest.c| 1 + tests/cputestdata/x86_64-cpuid-A10-5800K-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-A10-5800K-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Atom-D510-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Atom-N450-guest.xml | 1 - .../x86_64-cpuid-Core-i5-2500-guest.xml| 1 - .../cputestdata/x86_64-cpuid-Core-i5-2500-json.xml | 1 - .../x86_64-cpuid-Core-i5-2540M-guest.xml | 1 - .../x86_64-cpuid-Core-i5-2540M-json.xml| 1 - .../x86_64-cpuid-Core-i5-4670T-guest.xml | 1 - .../x86_64-cpuid-Core-i5-4670T-json.xml| 1 - .../x86_64-cpuid-Core-i5-6600-guest.xml| 1 - .../cputestdata/x86_64-cpuid-Core-i5-6600-json.xml | 1 - .../x86_64-cpuid-Core-i7-2600-guest.xml| 1 - .../cputestdata/x86_64-cpuid-Core-i7-2600-json.xml | 1 - .../x86_64-cpuid-Core-i7-3520M-guest.xml | 1 - .../x86_64-cpuid-Core-i7-3740QM-guest.xml | 1 - .../x86_64-cpuid-Core-i7-3740QM-json.xml | 1 - .../x86_64-cpuid-Core-i7-3770-guest.xml| 1 - .../cputestdata/x86_64-cpuid-Core-i7-3770-json.xml | 1 - .../x86_64-cpuid-Core-i7-4510U-guest.xml | 29 +++ .../x86_64-cpuid-Core-i7-4510U-host.xml| 44 + .../x86_64-cpuid-Core-i7-4510U-json.xml| 15 ++ tests/cputestdata/x86_64-cpuid-Core-i7-4510U.json | 203 + tests/cputestdata/x86_64-cpuid-Core-i7-4510U.xml | 34 .../x86_64-cpuid-Core-i7-4600U-guest.xml | 1 - .../x86_64-cpuid-Core-i7-4600U-json.xml| 1 - .../x86_64-cpuid-Core-i7-5600U-guest.xml | 1 - .../x86_64-cpuid-Core-i7-5600U-json.xml| 1 - .../cputestdata/x86_64-cpuid-Core2-E6850-guest.xml | 1 - .../cputestdata/x86_64-cpuid-Core2-E6850-json.xml | 1 - .../cputestdata/x86_64-cpuid-Core2-Q9500-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-FX-8150-guest.xml | 1 - .../x86_64-cpuid-Opteron-1352-guest.xml| 1 - .../x86_64-cpuid-Opteron-2350-guest.xml| 1 - .../cputestdata/x86_64-cpuid-Opteron-2350-json.xml | 1 - .../x86_64-cpuid-Opteron-6234-guest.xml| 1 - .../cputestdata/x86_64-cpuid-Opteron-6234-json.xml | 1 - .../x86_64-cpuid-Opteron-6282-guest.xml| 1 - .../x86_64-cpuid-Pentium-P6100-guest.xml | 1 - .../cputestdata/x86_64-cpuid-Phenom-B95-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Phenom-B95-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-5110-guest.xml | 1 - .../x86_64-cpuid-Xeon-E3-1245-guest.xml| 1 - .../cputestdata/x86_64-cpuid-Xeon-E3-1245-json.xml | 1 - .../x86_64-cpuid-Xeon-E5-2630-guest.xml| 1 - .../cputestdata/x86_64-cpuid-Xeon-E5-2630-json.xml | 1 - .../x86_64-cpuid-Xeon-E5-2650-guest.xml| 1 - .../cputestdata/
[libvirt] [PATCH 3/7] cpu: Add virCPUType parameter to virCPUGetHost
The parameter can be used to request either VIR_CPU_TYPE_HOST (which has
been assumed so far) or VIR_CPU_TYPE_GUEST definition.
Signed-off-by: Jiri Denemark
---
src/bhyve/bhyve_capabilities.c | 2 +-
src/cpu/cpu.c | 41 -
src/cpu/cpu.h | 1 +
src/qemu/qemu_capabilities.c | 2 +-
src/vmware/vmware_conf.c | 2 +-
src/vz/vz_driver.c | 3 ++-
6 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
index c2c9303d7..33e670c5c 100644
--- a/src/bhyve/bhyve_capabilities.c
+++ b/src/bhyve/bhyve_capabilities.c
@@ -47,7 +47,7 @@ virBhyveCapsInitCPU(virCapsPtr caps,
if (nodeGetInfo(&nodeinfo))
return -1;
-if (!(caps->host.cpu = virCPUGetHost(arch, &nodeinfo)))
+if (!(caps->host.cpu = virCPUGetHost(arch, VIR_CPU_TYPE_HOST, &nodeinfo)))
return -1;
return 0;
diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c
index c1666ed3b..110bb240c 100644
--- a/src/cpu/cpu.c
+++ b/src/cpu/cpu.c
@@ -360,9 +360,18 @@ virCPUDataFree(virCPUDataPtr data)
* virCPUGetHost:
*
* @arch: CPU architecture
+ * @type: requested type of the CPU
* @nodeInfo: simplified CPU topology (optional)
*
- * Create CPU definition describing the host's CPU. If @nodeInfo is not NULL,
+ * Create CPU definition describing the host's CPU.
+ *
+ * The @type (either VIR_CPU_TYPE_HOST or VIR_CPU_TYPE_GUEST) specifies what
+ * type of CPU definition should be created. Specifically, VIR_CPU_TYPE_HOST
+ * CPUs may contain only features without any policy attribute. Requesting
+ * VIR_CPU_TYPE_GUEST provides better results because the CPU is allowed to
+ * contain disabled features.
+ *
+ * If @nodeInfo is not NULL (which is only allowed for VIR_CPU_TYPE_HOST CPUs),
* the CPU definition will have topology (sockets, cores, threads) filled in
* according to the content of @nodeInfo. The function fails only if @nodeInfo
* was not passed in and the assigned CPU driver was not able to detect the
@@ -373,13 +382,14 @@ virCPUDataFree(virCPUDataPtr data)
*/
virCPUDefPtr
virCPUGetHost(virArch arch,
+ virCPUType type,
virNodeInfoPtr nodeInfo)
{
struct cpuArchDriver *driver;
virCPUDefPtr cpu = NULL;
-VIR_DEBUG("arch=%s, nodeInfo=%p",
- virArchToString(arch), nodeInfo);
+VIR_DEBUG("arch=%s, type=%s, nodeInfo=%p",
+ virArchToString(arch), virCPUTypeToString(type), nodeInfo);
if (!(driver = cpuGetSubDriver(arch)))
return NULL;
@@ -387,8 +397,29 @@ virCPUGetHost(virArch arch,
if (VIR_ALLOC(cpu) < 0)
return NULL;
-cpu->arch = arch;
-cpu->type = VIR_CPU_TYPE_HOST;
+switch (type) {
+case VIR_CPU_TYPE_HOST:
+cpu->arch = arch;
+cpu->type = type;
+break;
+
+case VIR_CPU_TYPE_GUEST:
+if (nodeInfo) {
+virReportError(VIR_ERR_INVALID_ARG,
+ _("cannot set topology for CPU type '%s'"),
+ virCPUTypeToString(type));
+goto error;
+}
+cpu->type = type;
+break;
+
+case VIR_CPU_TYPE_AUTO:
+case VIR_CPU_TYPE_LAST:
+virReportError(VIR_ERR_INVALID_ARG,
+ _("unsupported CPU type: %s"),
+ virCPUTypeToString(type));
+goto error;
+}
if (nodeInfo) {
cpu->sockets = nodeInfo->sockets;
diff --git a/src/cpu/cpu.h b/src/cpu/cpu.h
index cbbb45223..e5eca08c3 100644
--- a/src/cpu/cpu.h
+++ b/src/cpu/cpu.h
@@ -170,6 +170,7 @@ virCPUDataFree(virCPUDataPtr data);
virCPUDefPtr
virCPUGetHost(virArch arch,
+ virCPUType type,
virNodeInfoPtr nodeInfo);
char *
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index b0a4861c3..b39014224 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1070,7 +1070,7 @@ virQEMUCapsInitCPU(virCapsPtr caps,
if (nodeGetInfo(&nodeinfo))
return -1;
-if (!(caps->host.cpu = virCPUGetHost(arch, &nodeinfo)))
+if (!(caps->host.cpu = virCPUGetHost(arch, VIR_CPU_TYPE_HOST, &nodeinfo)))
return -1;
return 0;
diff --git a/src/vmware/vmware_conf.c b/src/vmware/vmware_conf.c
index d1444e462..cb6d60724 100644
--- a/src/vmware/vmware_conf.c
+++ b/src/vmware/vmware_conf.c
@@ -82,7 +82,7 @@ vmwareCapsInit(void)
NULL, NULL, 0, NULL) == NULL)
goto error;
-if (!(cpu = virCPUGetHost(caps->host.arch, NULL)))
+if (!(cpu = virCPUGetHost(caps->host.arch, VIR_CPU_TYPE_HOST, NULL)))
goto error;
/* x86_64 guests are supported if
diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
index f97a2045b..67ec2727b 100644
--- a/src/vz/vz_driver.c
+++ b/src/vz/vz_driver.c
@@ -129,7 +129,8 @@ vzBuildCapabilities(void)
if (nodeGetInfo(&nodeinfo))
goto error;
-
[libvirt] [PATCH 4/7] cpu: Add list of allowed CPU models to virCPUGetHost
When creating host CPU definition usable with a given emulator, the CPU
should not be defined using an unsupported CPU model. The new @models
and @nmodels parameters can be used to limit CPU models which can be
used in the result.
Signed-off-by: Jiri Denemark
---
src/bhyve/bhyve_capabilities.c | 3 ++-
src/cpu/cpu.c | 19 +++
src/cpu/cpu.h | 8 ++--
src/cpu/cpu_ppc64.c| 6 --
src/cpu/cpu_x86.c | 6 --
src/qemu/qemu_capabilities.c | 3 ++-
src/vmware/vmware_conf.c | 3 ++-
src/vz/vz_driver.c | 2 +-
8 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
index 33e670c5c..60db0b791 100644
--- a/src/bhyve/bhyve_capabilities.c
+++ b/src/bhyve/bhyve_capabilities.c
@@ -47,7 +47,8 @@ virBhyveCapsInitCPU(virCapsPtr caps,
if (nodeGetInfo(&nodeinfo))
return -1;
-if (!(caps->host.cpu = virCPUGetHost(arch, VIR_CPU_TYPE_HOST, &nodeinfo)))
+if (!(caps->host.cpu = virCPUGetHost(arch, VIR_CPU_TYPE_HOST,
+ &nodeinfo, NULL, 0)))
return -1;
return 0;
diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c
index 110bb240c..5b1940b47 100644
--- a/src/cpu/cpu.c
+++ b/src/cpu/cpu.c
@@ -362,6 +362,8 @@ virCPUDataFree(virCPUDataPtr data)
* @arch: CPU architecture
* @type: requested type of the CPU
* @nodeInfo: simplified CPU topology (optional)
+ * @models: list of CPU models that can be considered for host CPU
+ * @nmodels: number of CPU models in @models
*
* Create CPU definition describing the host's CPU.
*
@@ -378,18 +380,26 @@ virCPUDataFree(virCPUDataPtr data)
* host CPU model. In other words, a CPU definition containing just the
* topology is a successful result even if detecting the host CPU model fails.
*
+ * It possible to limit the CPU model which may appear in the created CPU
+ * definition by passing non-NULL @models list. This is useful when requesting
+ * a CPU model usable on a specific hypervisor. If @models is NULL, any CPU
+ * model known to libvirt may appear in the result.
+ *
* Returns host CPU definition or NULL on error.
*/
virCPUDefPtr
virCPUGetHost(virArch arch,
virCPUType type,
- virNodeInfoPtr nodeInfo)
+ virNodeInfoPtr nodeInfo,
+ const char **models,
+ unsigned int nmodels)
{
struct cpuArchDriver *driver;
virCPUDefPtr cpu = NULL;
-VIR_DEBUG("arch=%s, type=%s, nodeInfo=%p",
- virArchToString(arch), virCPUTypeToString(type), nodeInfo);
+VIR_DEBUG("arch=%s, type=%s, nodeInfo=%p, models=%p, nmodels=%u",
+ virArchToString(arch), virCPUTypeToString(type), nodeInfo,
+ models, nmodels);
if (!(driver = cpuGetSubDriver(arch)))
return NULL;
@@ -431,7 +441,8 @@ virCPUGetHost(virArch arch,
* filled in.
*/
if (driver->getHost) {
-if (driver->getHost(cpu) < 0 && !nodeInfo)
+if (driver->getHost(cpu, models, nmodels) < 0 &&
+!nodeInfo)
goto error;
} else if (nodeInfo) {
VIR_DEBUG("cannot detect host CPU model for %s architecture",
diff --git a/src/cpu/cpu.h b/src/cpu/cpu.h
index e5eca08c3..c329eb134 100644
--- a/src/cpu/cpu.h
+++ b/src/cpu/cpu.h
@@ -71,7 +71,9 @@ typedef void
(*cpuArchDataFree) (virCPUDataPtr data);
typedef int
-(*virCPUArchGetHost)(virCPUDefPtr cpu);
+(*virCPUArchGetHost)(virCPUDefPtr cpu,
+ const char **models,
+ unsigned int nmodels);
typedef virCPUDefPtr
(*cpuArchBaseline) (virCPUDefPtr *cpus,
@@ -171,7 +173,9 @@ virCPUDataFree(virCPUDataPtr data);
virCPUDefPtr
virCPUGetHost(virArch arch,
virCPUType type,
- virNodeInfoPtr nodeInfo);
+ virNodeInfoPtr nodeInfo,
+ const char **models,
+ unsigned int nmodels);
char *
cpuBaselineXML(const char **xmlCPUs,
diff --git a/src/cpu/cpu_ppc64.c b/src/cpu/cpu_ppc64.c
index bb715546b..6e16ffd13 100644
--- a/src/cpu/cpu_ppc64.c
+++ b/src/cpu/cpu_ppc64.c
@@ -716,7 +716,9 @@ virCPUppc64DataFree(virCPUDataPtr data)
static int
-virCPUppc64GetHost(virCPUDefPtr cpu)
+virCPUppc64GetHost(virCPUDefPtr cpu,
+ const char **models,
+ unsigned int nmodels)
{
virCPUDataPtr cpuData = NULL;
virCPUppc64Data *data;
@@ -738,7 +740,7 @@ virCPUppc64GetHost(virCPUDefPtr cpu)
#endif
data->pvr[0].mask = 0xul;
-ret = ppc64DriverDecode(cpu, cpuData, NULL, 0, NULL, 0);
+ret = ppc64DriverDecode(cpu, cpuData, models, nmodels, NULL, 0);
cleanup:
virCPUppc64DataFree(cpuData);
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index bddb169ba..6719acee2 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -2438,7 +2438,9 @@ cpuidSet(uint32_t base, virCPUDataPtr data)
static int
-virCPUx86GetHos
[libvirt] [PATCH 1/7] Do not format in guest CPU XML
This element is only allowed for host CPUs. Signed-off-by: Jiri Denemark --- src/conf/cpu_conf.c | 2 +- tests/cputestdata/x86_64-cpuid-A10-5800K-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-A10-5800K-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Atom-D510-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Atom-N450-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i5-2500-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i5-2500-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Core-i5-2540M-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i5-2540M-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i5-4670T-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i5-4670T-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i5-6600-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i5-6600-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Core-i7-2600-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i7-2600-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Core-i7-3520M-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i7-3740QM-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i7-3740QM-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i7-3770-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i7-3770-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Core-i7-4600U-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i7-4600U-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i7-5600U-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Core-i7-5600U-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Core2-E6850-guest.xml| 1 - tests/cputestdata/x86_64-cpuid-Core2-E6850-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Core2-Q9500-guest.xml| 1 - tests/cputestdata/x86_64-cpuid-FX-8150-guest.xml| 1 - tests/cputestdata/x86_64-cpuid-Opteron-1352-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Opteron-2350-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Opteron-2350-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Opteron-6234-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Opteron-6234-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Opteron-6282-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Pentium-P6100-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Phenom-B95-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Phenom-B95-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-5110-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-E3-1245-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-E3-1245-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-E5-2630-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Xeon-E7-4820-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-E7-4820-json.xml| 1 - tests/cputestdata/x86_64-cpuid-Xeon-E7-8890-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-W3520-guest.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-W3520-json.xml | 1 - tests/cputestdata/x86_64-cpuid-Xeon-X5460-guest.xml | 1 - 50 files changed, 1 insertion(+), 50 deletions(-) diff --git a/src/conf/cpu_conf.c b/src/conf/cpu_conf.c index 1bcceeda4..2724fa30a 100644 --- a/src/conf/cpu_conf.c +++ b/src/conf/cpu_conf.c @@ -536,7 +536,7 @@ virCPUDefFormatBufFull(virBufferPtr buf, /* Format children */ virBufferAdjustIndent(&childrenBuf, indent + 2); -if (def->arch) +if (def->type == VIR_CPU_TYPE_HOST && def->arch) virBufferAsprintf(&childrenBuf, "%s\n", virArchToString(def->arch)); if (virCPUDefFormatBuf(&childrenBuf, def, updateCPU) < 0) diff --git a/tests/cputestdata/x86_64-cpuid-A10-5800K-guest.xml b/tests/cputestdata/x86_64-cpuid-A10-5800K-guest.xml index dacf1d0eb..98a95e1c4 100644 --- a/tests/cputestdata/x86_64-cpuid-A10-5800K-guest.xml +++ b/tests/cputestdata/x86_64-cpuid-A10-5800K-guest.xml @@ -1,5 +1,4 @@ - x86_64 Opteron_G5 AMD diff --git a/tests/cputestdata/x86_64-cpuid-A10-5800K-json.xml b/tests/cputestdata/x86_64-cpuid-A10-5800K-json.xml index c021fcddf..fa61b7b60 100644 --- a/tests/cputestdata/x86_64-cpuid-A10-5800K-json.xml +++ b/tests/cputestdata/x86_64-cpuid-A10-5800K-json.xml @@ -1,5 +1,4 @@ - x86_64 Opteron_G5 AMD diff --git a/tests/cputestdata/x86_64-cpuid-Atom-D510-guest.xml b/tests/cputestdata/x86_64-cpuid-Atom-D510-guest.xml index 5e9efc7c0..caa0bfd53 100644 --- a/tests/cputestdata/x86_64-cpuid-Atom-D510-guest.xml +++ b/tests/cputestdata/x86_64-cpuid-Atom-D510-guest.xml @@ -1,5 +1,4 @@ - x86_64 core2duo Intel diff --git a/tests/cputestdata/x86_64-cpuid-Atom-N450-guest.xml b/tests/cputestdata/x86_64-cpuid-Atom-N450-guest.xml index be11b887d..e8f5c9388 100644 --- a/tests/cputestdata/x86_64-cpuid-Atom-N450-guest.xml +++ b/tests/cputestdata/x86_
[libvirt] [PATCH 2/7] cpu: Replace cpuNodeData with virCPUGetHost
cpuNodeData has always been followed by cpuDecode as no hypervisor
driver is really interested in raw CPUID data for a host CPU. Let's
create a new CPU driver API which returns virCPUDefPtr directly.
Signed-off-by: Jiri Denemark
---
src/bhyve/bhyve_capabilities.c | 34 -
src/cpu/cpu.c | 58 ++
src/cpu/cpu.h | 11
src/cpu/cpu_arm.c | 1 -
src/cpu/cpu_ppc64.c| 28 ++--
src/cpu/cpu_s390.c | 1 -
src/cpu/cpu_x86.c | 27 +---
src/libvirt_private.syms | 2 +-
src/qemu/qemu_capabilities.c | 32 +++
src/vmware/vmware_conf.c | 19 +++---
src/vz/vz_driver.c | 21 ++-
11 files changed, 95 insertions(+), 139 deletions(-)
diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c
index 52d6ca782..c2c9303d7 100644
--- a/src/bhyve/bhyve_capabilities.c
+++ b/src/bhyve/bhyve_capabilities.c
@@ -40,41 +40,17 @@ VIR_LOG_INIT("bhyve.bhyve_capabilities");
static int
virBhyveCapsInitCPU(virCapsPtr caps,
- virArch arch)
+virArch arch)
{
-virCPUDefPtr cpu = NULL;
-virCPUDataPtr data = NULL;
virNodeInfo nodeinfo;
-int ret = -1;
-
-if (VIR_ALLOC(cpu) < 0)
-goto error;
-
-cpu->arch = arch;
if (nodeGetInfo(&nodeinfo))
-goto error;
+return -1;
-cpu->type = VIR_CPU_TYPE_HOST;
-cpu->sockets = nodeinfo.sockets;
-cpu->cores = nodeinfo.cores;
-cpu->threads = nodeinfo.threads;
-caps->host.cpu = cpu;
+if (!(caps->host.cpu = virCPUGetHost(arch, &nodeinfo)))
+return -1;
-if (!(data = cpuNodeData(arch)) ||
-cpuDecode(cpu, data, NULL, 0, NULL) < 0)
-goto cleanup;
-
-ret = 0;
-
- cleanup:
-virCPUDataFree(data);
-
-return ret;
-
- error:
-virCPUDefFree(cpu);
-goto cleanup;
+return 0;
}
virCapsPtr
diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c
index 051a58040..c1666ed3b 100644
--- a/src/cpu/cpu.c
+++ b/src/cpu/cpu.c
@@ -357,30 +357,66 @@ virCPUDataFree(virCPUDataPtr data)
/**
- * cpuNodeData:
+ * virCPUGetHost:
*
* @arch: CPU architecture
+ * @nodeInfo: simplified CPU topology (optional)
*
- * Returns CPU data for host CPU or NULL on error.
+ * Create CPU definition describing the host's CPU. If @nodeInfo is not NULL,
+ * the CPU definition will have topology (sockets, cores, threads) filled in
+ * according to the content of @nodeInfo. The function fails only if @nodeInfo
+ * was not passed in and the assigned CPU driver was not able to detect the
+ * host CPU model. In other words, a CPU definition containing just the
+ * topology is a successful result even if detecting the host CPU model fails.
+ *
+ * Returns host CPU definition or NULL on error.
*/
-virCPUDataPtr
-cpuNodeData(virArch arch)
+virCPUDefPtr
+virCPUGetHost(virArch arch,
+ virNodeInfoPtr nodeInfo)
{
struct cpuArchDriver *driver;
+virCPUDefPtr cpu = NULL;
-VIR_DEBUG("arch=%s", virArchToString(arch));
+VIR_DEBUG("arch=%s, nodeInfo=%p",
+ virArchToString(arch), nodeInfo);
-if ((driver = cpuGetSubDriver(arch)) == NULL)
+if (!(driver = cpuGetSubDriver(arch)))
return NULL;
-if (driver->nodeData == NULL) {
-virReportError(VIR_ERR_NO_SUPPORT,
- _("cannot get node CPU data for %s architecture"),
- virArchToString(arch));
+if (VIR_ALLOC(cpu) < 0)
return NULL;
+
+cpu->arch = arch;
+cpu->type = VIR_CPU_TYPE_HOST;
+
+if (nodeInfo) {
+cpu->sockets = nodeInfo->sockets;
+cpu->cores = nodeInfo->cores;
+cpu->threads = nodeInfo->threads;
}
-return driver->nodeData(arch);
+/* Try to get the host CPU model, but don't really fail if nodeInfo is
+ * filled in.
+ */
+if (driver->getHost) {
+if (driver->getHost(cpu) < 0 && !nodeInfo)
+goto error;
+} else if (nodeInfo) {
+VIR_DEBUG("cannot detect host CPU model for %s architecture",
+ virArchToString(arch));
+} else {
+virReportError(VIR_ERR_NO_SUPPORT,
+ _("cannot detect host CPU model for %s architecture"),
+ virArchToString(arch));
+goto error;
+}
+
+return cpu;
+
+ error:
+virCPUDefFree(cpu);
+return NULL;
}
diff --git a/src/cpu/cpu.h b/src/cpu/cpu.h
index 0324284b9..cbbb45223 100644
--- a/src/cpu/cpu.h
+++ b/src/cpu/cpu.h
@@ -70,8 +70,8 @@ typedef int
typedef void
(*cpuArchDataFree) (virCPUDataPtr data);
-typedef virCPUDataPtr
-(*cpuArchNodeData) (virArch arch);
+typedef int
+(*virCPUArchGetHost)(virCPUDefPtr cpu);
typedef virCPUDefPtr
(*cpuArchBaseline) (virCPUDefPtr *cpus,
@@ -117,7 +117,7 @@ struct cpuArchDriver {
cpuArchDecode decode;
Re: [libvirt] [PATCH] qemu_process: don't probe iothreads if it's not supported by QEMU
On Wed, Mar 08, 2017 at 12:11:57 +0100, Pavel Hrdina wrote:
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430258
>
> Signed-off-by: Pavel Hrdina
> ---
> src/qemu/qemu_process.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 78d10099af..fcba7d3097 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -2098,6 +2098,11 @@ qemuProcessDetectIOThreadPIDs(virQEMUDriverPtr driver,
> int ret = -1;
> size_t i;
>
> +if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_OBJECT_IOTHREAD)) {
> +ret = 0;
> +goto cleanup;
> +}
> +
> /* Get the list of IOThreads from qemu */
> if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0)
> goto cleanup;
ACK
Jirka
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu_process: don't probe iothreads if it's not supported by QEMU
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1430258
Signed-off-by: Pavel Hrdina
---
src/qemu/qemu_process.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 78d10099af..fcba7d3097 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -2098,6 +2098,11 @@ qemuProcessDetectIOThreadPIDs(virQEMUDriverPtr driver,
int ret = -1;
size_t i;
+if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_OBJECT_IOTHREAD)) {
+ret = 0;
+goto cleanup;
+}
+
/* Get the list of IOThreads from qemu */
if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0)
goto cleanup;
--
2.12.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC v2 1/2] qemu_migration: don't allow ABI changes for persistent migration
On Wed, 2017-03-08 at 09:22 +0100, Peter Krempa wrote: > On Tue, Mar 07, 2017 at 18:45:23 +0100, Pavel Hrdina wrote: > > > > So far there is probably no change that is allowed to be done > > by the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE flag that would break > > guest ABI but this may change in the future. > > > > The other cases where this flag is used is only when we are > > defining new domain or adding new device into a domain. > > > > Signed-off-by: Pavel Hrdina > > --- > > > > This patch is a product of a discussion about the last patch in v1 [1]. > > Currently we allow ABI changes for persistent migration however it might > > be something that user don't expect to be done. > > > > Technically it defines new domain on the destination which would fall > > into the same category as defining new domain from scratch without > > migration but it may be unexpected behavior because for live migration > > we don't allow ABI changes (for obvious reasons). > > > > At first I though that this is correct and we are doing the right thing, > > but now I'm not so sure about that and IMHO it would be probably better > > to not do ABI updates in this case like we don't do if libvirtd is > > restarted (for example because of an update) and also it would be > > consistent with the live migration. > > This flag was invented so that libvirt could finally properly track the > total memory size of the VM when NUMA is used. Prior to that the > individual node sizes would not have to total up to the size declared in > the element. While migrating a live VM we can't change this but > other code expects that the size is correct. > > This patch would break this particular case. In general I'm not against > a change, but the recalculation of the memory sizes should not be > broken. I see. However, as it is now, we're granting blanket permission to update the guest ABI in whatever random way during a persistent migration, which at least to me feels like it's way too broad. Can we maybe introduce a less coarse-grained flag just for the memory update, and leave the broader ABI_UPDATE for cases such as defining an entirely new guest or attaching an entirely new device, eg. situations where any change we perform won't affect the existing guest? Or is it too late for that? -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemuTestDriverInit: Don't access live data
On 03/08/2017 10:15 AM, Martin Kletzander wrote:
> On Mon, Mar 06, 2017 at 08:38:00AM +0100, Michal Privoznik wrote:
>> Some of our tests (e.g. qemuhotplugtest) call
>> virDomainSaveConfig(). Now the problem is, qemuTestDriverInit()
>> creates a fake qemu driver and fills it with some fake
>> configuration. At least so we hoped. The truth is, it calls
>> regular virQEMUDriverConfigNew() and then fix couple of paths.
>> Literally. Therefore our tests see regular stateDir and configDir
>> for the user that is running the tests. Directories, where live
>> domain XMLs are stored. Let's just hope our test suite hasn't
>> mangled any of them.
>>
>> Signed-off-by: Michal Privoznik
>> ---
>> tests/testutilsqemu.c | 34 ++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c
>> index 56a89c913..0726cd317 100644
>> --- a/tests/testutilsqemu.c
>> +++ b/tests/testutilsqemu.c
>> @@ -513,6 +513,10 @@ qemuTestParseCapabilities(virCapsPtr caps,
>> void qemuTestDriverFree(virQEMUDriver *driver)
>> {
>> virMutexDestroy(&driver->lock);
>> +if (driver->config) {
>> +virFileDeleteTree(driver->config->stateDir);
>> +virFileDeleteTree(driver->config->configDir);
>> +}
>> virQEMUCapsCacheFree(driver->qemuCapsCache);
>> virObjectUnref(driver->xmlopt);
>> virObjectUnref(driver->caps);
>> @@ -548,9 +552,14 @@ int qemuTestCapsCacheInsert(virQEMUCapsCachePtr
>> cache, const char *binary,
>> return ret;
>> }
>>
>> +# define STATEDIRTEMPLATE abs_builddir "/qemustatedir-XX"
>> +# define CONFIGDIRTEMPLATE abs_builddir "/qemuconfigdir-XX"
>> +
>> int qemuTestDriverInit(virQEMUDriver *driver)
>> {
>> virSecurityManagerPtr mgr = NULL;
>> +char statedir[] = STATEDIRTEMPLATE;
>> +char configdir[] = CONFIGDIRTEMPLATE;
>>
>
> There's no point in creating these variables, otherwise ACK.
There is a point; mkdtemp() uses the passed variable for both input and
output. On function enter the file pattern is stored there, on function
return the actual dirname that was created is stored there. Calling
mkdir(STATEDIRTEMPLATE) would lead to sigsegv I guess. Let me try. Yeah,
my guess was right.
Pushed without any change. Thank you.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] qemu: Validate the domain after marking the current domain as transient
On Wed, Mar 08, 2017 at 10:32:32AM +0100, Marc Hartmayer wrote:
> On Mon, Feb 27, 2017 at 11:20 AM +0100, "Daniel P. Berrange"
> wrote:
> > On Mon, Feb 27, 2017 at 10:59:39AM +0100, Marc Hartmayer wrote:
> >> On Thu, Feb 23, 2017 at 05:36 PM +0100, "Daniel P. Berrange"
> >> wrote:
> >> > On Thu, Feb 23, 2017 at 05:22:44PM +0100, Marc Hartmayer wrote:
> >> >> On Thu, Feb 23, 2017 at 03:33 PM +0100, Michal Privoznik
> >> >> wrote:
> >> >> > On 02/23/2017 10:44 AM, Marc Hartmayer wrote:
> >> >> >> Validate the domain that actually will be started. It's semantically
> >> >> >> more clear and also it can detect failures that may have happened in
> >> >> >> virDomainObjSetDefTransient().
> >> >> >>
> >> >> >> Signed-off-by: Marc Hartmayer
> >> >> >> Reviewed-by: Bjoern Walk
> >> >> >> Reviewed-by: Boris Fiuczynski
> >> >> >> ---
> >> >> >> src/qemu/qemu_process.c | 6 +++---
> >> >> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >> >> >>
> >> >> >> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> >> >> >> index a57d136..bd3a8b8 100644
> >> >> >> --- a/src/qemu/qemu_process.c
> >> >> >> +++ b/src/qemu/qemu_process.c
> >> >> >> @@ -4746,9 +4746,6 @@ qemuProcessInit(virQEMUDriverPtr driver,
> >> >> >>
> >> >> >> vm->def->os.machine)))
> >> >> >> goto cleanup;
> >> >> >>
> >> >> >> -if (qemuProcessStartValidate(driver, vm, priv->qemuCaps, caps,
> >> >> >> flags) < 0)
> >> >> >> -goto cleanup;
> >> >> >> -
> >> >> >> /* Do this upfront, so any part of the startup process can add
> >> >> >> * runtime state to vm->def that won't be persisted. This let's
> >> >> >> us
> >> >> >> * report implicit runtime defaults in the XML, like vnc
> >> >> >> listen/socket
> >> >> >> @@ -4757,6 +4754,9 @@ qemuProcessInit(virQEMUDriverPtr driver,
> >> >> >> if (virDomainObjSetDefTransient(caps, driver->xmlopt, vm) < 0)
> >> >> >> goto cleanup;
> >> >> >>
> >> >> >> +if (qemuProcessStartValidate(driver, vm, priv->qemuCaps, caps,
> >> >> >> flags) < 0)
> >> >> >> +goto cleanup;
> >> >> >> +
> >> >> >
> >> >> > This needs to be goto stop for the reasons described in the previous
> >> >> > e-mail.
> >> >> >
> >> >> >> if (flags & VIR_QEMU_PROCESS_START_PRETEND) {
> >> >> >> if (qemuDomainSetPrivatePaths(driver, vm) < 0)
> >> >> >> goto cleanup;
> >> >> >>
> >> >> >
> >> >> > Honestly, I like what we have now better. I mean, SetDefTransient() is
> >> >> > very unlikely to fail. It's just doing a copy of domain definition
> >> >> > (in a
> >> >> > very stupid way, but lets save that for a different discussion).
> >> >> > Basically, it will fail on OOM only (which you will not get on a Linux
> >> >> > system, unless you really try).
> >> >>
> >> >> It's semantically more clear (at least for me) and for example it
> >> >> enables us to change some parts of the transient domain before
> >> >> validation (affect the transient domain only, not the persistent).
> >> >
> >> > What are you planning to change in the config before validation ?
> >> >
> >>
> >> I'm implementing a feature which allows to select the boot device at
> >> domain start time (something like 'virsh start --with-bootdevice sda
> >> domain1'). The main reason why we want this is because the s390
> >> architecture boots only from the first device specified in the boot
> >> order.
> >
> > There's no need to changes in the QEMU driver todo this. You can just
> > query the current XML config, change the boot device in it, and then
> > run virDomainCreateXML to launch the guest with the changed config,
> > or virDomainDefineXML again to make the changed boot device permanent.
> >
>
> First of all, I hope I understand you right :) (you can tell me as soon
> as you have read the following text)
>
> I've followed your advice and tried to add this functionality without
> any changes in the QEMU/hypervisor. For this I've created a new function
> in the remote driver which will call the needed functions (get current
> XML config for the domain, manipulate the XML config, and then use
> virDomainCreateXML for starting).
>
> To get the current XML config is straightforward as you've mentioned -
> just use 'virDomanGetXMLDesc(...)'.
>
> But how can I change the boot device?
> 1) I could use libxml2 for manipulating the XML string which we will get
> with calling 'virDomainGetXMLDesc(..)' but this is error-prone and just
> duplicate work as we have to parse the XML string and the information of
> it. Also, if there are any additions in the future for boot devices
> there will be no 'compile time reminder' that you have to edit this
> function.
Yes, this is the way it is normally done. There is a tradeoff here between
wanting to be reminded at compile time but seeing build breakage, and libvirt
wanting to be able to extend its config info without breaking apps. The
libvirt view is that the latter is more i
Re: [libvirt] [PATCH] qemuTestDriverInit: Don't access live data
On Mon, Mar 06, 2017 at 08:38:00AM +0100, Michal Privoznik wrote:
Some of our tests (e.g. qemuhotplugtest) call
virDomainSaveConfig(). Now the problem is, qemuTestDriverInit()
creates a fake qemu driver and fills it with some fake
configuration. At least so we hoped. The truth is, it calls
regular virQEMUDriverConfigNew() and then fix couple of paths.
Literally. Therefore our tests see regular stateDir and configDir
for the user that is running the tests. Directories, where live
domain XMLs are stored. Let's just hope our test suite hasn't
mangled any of them.
Signed-off-by: Michal Privoznik
---
tests/testutilsqemu.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c
index 56a89c913..0726cd317 100644
--- a/tests/testutilsqemu.c
+++ b/tests/testutilsqemu.c
@@ -513,6 +513,10 @@ qemuTestParseCapabilities(virCapsPtr caps,
void qemuTestDriverFree(virQEMUDriver *driver)
{
virMutexDestroy(&driver->lock);
+if (driver->config) {
+virFileDeleteTree(driver->config->stateDir);
+virFileDeleteTree(driver->config->configDir);
+}
virQEMUCapsCacheFree(driver->qemuCapsCache);
virObjectUnref(driver->xmlopt);
virObjectUnref(driver->caps);
@@ -548,9 +552,14 @@ int qemuTestCapsCacheInsert(virQEMUCapsCachePtr cache,
const char *binary,
return ret;
}
+# define STATEDIRTEMPLATE abs_builddir "/qemustatedir-XX"
+# define CONFIGDIRTEMPLATE abs_builddir "/qemuconfigdir-XX"
+
int qemuTestDriverInit(virQEMUDriver *driver)
{
virSecurityManagerPtr mgr = NULL;
+char statedir[] = STATEDIRTEMPLATE;
+char configdir[] = CONFIGDIRTEMPLATE;
There's no point in creating these variables, otherwise ACK.
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [GSOC] project libvirt fuzzing
On 03/07/2017 09:22 PM, D L wrote: > Hi Michal, > > Thank you so much for the detailed description. I will get back to you for > each point in detail next week. Sure, not problem. > > By the way, so nice to see the power of vi in a real project. http://vim.wikia.com/wiki/Browsing_programs_with_tags Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] [Changelog]:If there is a process with a client which registers event callbacks, and it calls libvirt's API which uses the same virConnectPtr in that callback function. When this pro
#0 0x7fda223d66d8 in virClassIsDerivedFrom (klass=0xdeadbeef,
parent=0x7fda24c81b40) at util/virobject.c:169
#1 0x7fda223d6a1e in virObjectIsClass
(anyobj=anyobj@entry=0x7fd9e575b400, klass=) at
util/virobject.c:365
#2 0x7fda223d6a44 in virObjectLock (anyobj=0x7fd9e575b400) at
util/virobject.c:317
#3 0x7fda22507f71 in virNetServerClientSendMessage
(client=client@entry=0x7fd9e575b400, msg=msg@entry=0x7fd9ec30de90)
at rpc/virnetserverclient.c:1422
#4 0x7fda230d714d in remoteDispatchObjectEventSend
(client=0x7fd9e575b400, program=0x7fda24c844e0, procnr=348,
proc=0x7fda2310e5e0 ,
data=0x7ffc3857fdb0) at remote.c:3803
#5 0x7fda230dd71b in remoteRelayDomainEventTunable (conn=, dom=0x7fda27cd7660, params=0x7fda27f3aae0,
nparams=1,opaque=0x7fd9e6c99e00) at remote.c:1033
#6 0x7fda224484cb in virDomainEventDispatchDefaultFunc
(conn=0x7fda27cd0120, event=0x7fda2736ea00,
cb=0x7fda230dd610 , cbopaque=0x7fd9e6c99e00)
at conf/domain_event.c:1910
#7 0x7fda22446871 in virObjectEventStateDispatchCallbacks
(callbacks=, callbacks=,
event=0x7fda2736ea00,state=0x7fda24ca3960) at conf/object_event.c:722
#8 virObjectEventStateQueueDispatch (callbacks=0x7fda24c65800,
queue=0x7ffc3857fe90, state=0x7fda24ca3960) at conf/object_event.c:736
#9 virObjectEventStateFlush (state=0x7fda24ca3960) at
conf/object_event.c:814
#10 virObjectEventTimer (timer=, opaque=0x7fda24ca3960) at
conf/object_event.c:560
#11 0x7fda223ae8b9 in virEventPollDispatchTimeouts () at
util/vireventpoll.c:458
#12 virEventPollRunOnce () at util/vireventpoll.c:654
#13 0x7fda223ad1d2 in virEventRunDefaultImpl () at util/virevent.c:314
#14 0x7fda225046cd in virNetDaemonRun (dmn=0x7fda24c775c0) at
rpc/virnetdaemon.c:818
#15 0x7fda230d6351 in main (argc=, argv=)
at libvirtd.c:1623
Let's clean all event callback when client close.
Signed-off-by: xinhua.Cao
this patch resolved the bug which reported by Wang King. and the prior
patch link is
http://www.redhat.com/archives/libvir-list/2017-February/msg00452.html
---
daemon/remote.c | 60 +++--
1 file changed, 28 insertions(+), 32 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 4aa43c223..22330307f 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -100,6 +100,7 @@ static void
make_nonnull_node_device(remote_nonnull_node_device *dev_dst, virNod
static void make_nonnull_secret(remote_nonnull_secret *secret_dst,
virSecretPtr secret_src);
static void make_nonnull_nwfilter(remote_nonnull_nwfilter *net_dst,
virNWFilterPtr nwfilter_src);
static void make_nonnull_domain_snapshot(remote_nonnull_domain_snapshot
*snapshot_dst, virDomainSnapshotPtr snapshot_src);
+static void remoteClientCleanEventCallbacks(struct daemonClientPrivate *priv);
static int
remoteSerializeDomainDiskErrors(virDomainDiskErrorPtr errors,
@@ -1389,24 +1390,15 @@ void remoteRelayConnectionClosedEvent(virConnectPtr
conn ATTRIBUTE_UNUSED, int r
&msg);
}
-/*
- * You must hold lock for at least the client
- * We don't free stuff here, merely disconnect the client's
- * network socket & resources.
- * We keep the libvirt connection open until any async
- * jobs have finished, then clean it up elsewhere
- */
-void remoteClientFreeFunc(void *data)
+static void remoteClientCleanEventCallbacks(struct daemonClientPrivate *priv)
{
-struct daemonClientPrivate *priv = data;
-
/* Deregister event delivery callback */
-if (priv->conn) {
-virIdentityPtr sysident = virIdentityGetSystem();
+if (priv && priv->conn) {
size_t i;
-
+virIdentityPtr sysident = virIdentityGetSystem();
virIdentitySetCurrent(sysident);
+virMutexLock(&priv->lock);
for (i = 0; i < priv->ndomainEventCallbacks; i++) {
int callbackID = priv->domainEventCallbacks[i]->callbackID;
if (callbackID < 0) {
@@ -1420,6 +1412,7 @@ void remoteClientFreeFunc(void *data)
VIR_WARN("unexpected domain event deregister failure");
}
VIR_FREE(priv->domainEventCallbacks);
+priv->ndomainEventCallbacks = 0;
for (i = 0; i < priv->nnetworkEventCallbacks; i++) {
int callbackID = priv->networkEventCallbacks[i]->callbackID;
@@ -1435,21 +1428,7 @@ void remoteClientFreeFunc(void *data)
VIR_WARN("unexpected network event deregister failure");
}
VIR_FREE(priv->networkEventCallbacks);
-
-for (i = 0; i < priv->nstorageEventCallbacks; i++) {
-int callbackID = priv->storageEventCallbacks[i]->callbackID;
-if (callbackID < 0) {
-VIR_WARN("unexpected incomplete storage pool callback %zu", i);
-continue;
-}
-VIR_DEBUG("Deregistering remote storage pool event relay %d",
-
Re: [libvirt] [RFC v2 1/2] qemu_migration: don't allow ABI changes for persistent migration
On Tue, Mar 07, 2017 at 18:45:23 +0100, Pavel Hrdina wrote: > So far there is probably no change that is allowed to be done > by the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE flag that would break > guest ABI but this may change in the future. > > The other cases where this flag is used is only when we are > defining new domain or adding new device into a domain. > > Signed-off-by: Pavel Hrdina > --- > > This patch is a product of a discussion about the last patch in v1 [1]. > Currently we allow ABI changes for persistent migration however it might > be something that user don't expect to be done. > > Technically it defines new domain on the destination which would fall > into the same category as defining new domain from scratch without > migration but it may be unexpected behavior because for live migration > we don't allow ABI changes (for obvious reasons). > > At first I though that this is correct and we are doing the right thing, > but now I'm not so sure about that and IMHO it would be probably better > to not do ABI updates in this case like we don't do if libvirtd is > restarted (for example because of an update) and also it would be > consistent with the live migration. This flag was invented so that libvirt could finally properly track the total memory size of the VM when NUMA is used. Prior to that the individual node sizes would not have to total up to the size declared in the element. While migrating a live VM we can't change this but other code expects that the size is correct. This patch would break this particular case. In general I'm not against a change, but the recalculation of the memory sizes should not be broken. signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
