[libvirt] [PATCH 0/3] Couple of improvements
by Michal Privoznik
*** BLURB HERE ***
Michal Privoznik (3):
vsh: Make self-test more robust
tools: Set CFLAGS for wireshark properly
tools: Enable warnings for more binaries/libs
tools/Makefile.am | 19 ++++++++++---------
tools/vsh.c | 29 ++++++++++++++++++++++-------
2 files changed, 32 insertions(+), 16 deletions(-)
--
2.13.6
7 years
[libvirt] [PATCH] nodedev: Restore setting of privileged
by John Ferlan
Commit id '36555364' removed the setting of the driver->privileged,
which the udevProcessPCI would need in order to read the PCI device
configs.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
Not quite sure after seeing other issues how I missed this during
review of the series to change the udev nodedev code to use a thread.
I tripped across this while "investigating" a recurring issue I'm
having with the udev code in an avocado nwfilter test where during
a libvirtd restart the udev initialization "hangs" and cannot be killed
resulting in a <defunct> process and the only recovery is reboot. Still
trying to hack through that, but figured this should go into 3.10 at
least. So far only 3.9 would be affected, but only to not get PCI
device details.
src/node_device/node_device_udev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c
index 35df13b153..1e1b71742b 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -1933,6 +1933,8 @@ nodeStateInitialize(bool privileged,
return -1;
}
+ driver->privileged = privileged;
+
if (!(driver->devs = virNodeDeviceObjListNew()) ||
!(priv = udevEventDataNew()))
goto cleanup;
--
2.13.6
7 years
[libvirt] [PATCH 0/4] Convert virStoragePoolObj into virObjectLockable
by John Ferlan
Next in the push to get the storage pool objects to be more common
is to use the virObjectLockable for the Pool objects. The patches
describe the transformation.
John Ferlan (4):
storage: Introduce virStoragePoolObjEndAPI
storage: Introduce virStoragePoolObjListForEach
storage: Introduce virStoragePoolObjListSearch
storage: Convert virStoragePoolObj into virObjectLockable
src/conf/virstorageobj.c | 194 +++++++++++-----
src/conf/virstorageobj.h | 27 ++-
src/libvirt_private.syms | 5 +-
src/storage/storage_backend_scsi.c | 2 +-
src/storage/storage_driver.c | 446 +++++++++++++++++++------------------
src/test/test_driver.c | 158 +++++++------
tests/storagevolxml2argvtest.c | 4 +-
7 files changed, 476 insertions(+), 360 deletions(-)
--
2.13.6
7 years
[libvirt] [PATCH 0/3] qemu: Fix error reporting from QEMU log
by Jiri Denemark
Jiri Denemark (3):
qemu: Properly skip "char device redirected to" in QEMU log
vierror: Define VIR_ERROR_MAX_LENGTH macro
qemu: Use the end of QEMU log for reporting errors
src/qemu/qemu_process.c | 36 +++++++++++++++++++++++++++++++-----
src/util/virerror.c | 6 +++---
src/util/virerror.h | 2 ++
3 files changed, 36 insertions(+), 8 deletions(-)
--
2.15.0
7 years
[libvirt] [PATCH v2 0/5] qemu: Support setting NUMA distances
by Michal Privoznik
diff to v1:
- Renamed & simplified function in 2/5
- Other small nits fixed as raised in review
Michal Privoznik (5):
virDomainNumaGetNodeDistance: Fix input arguments validation
numa: Introduce virDomainNumaNodeDistanceIsUsingDefaults
qemu_capabilities: Introcude QEMU_CAPS_NUMA_DIST
qemu: Support setting NUMA distances
news: Document which drivers support NUMA distances
docs/formatdomain.html.in | 2 +-
docs/news.xml | 2 +-
src/conf/numa_conf.c | 25 ++++++++-
src/conf/numa_conf.h | 4 ++
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 5 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 39 ++++++++++++-
.../caps_2.10.0-gicv2.aarch64.xml | 1 +
.../caps_2.10.0-gicv3.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 +
.../qemuxml2argv-numatune-distances.args | 63 +++++++++++++++++++++
.../qemuxml2argv-numatune-distances.xml | 65 ++++++++++++++++++++++
tests/qemuxml2argvtest.c | 2 +
16 files changed, 209 insertions(+), 5 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-distances.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-distances.xml
--
2.13.6
7 years, 1 month
[libvirt] Speak at FOSDEM18 Virt & IaaS Devroom!
by Stefan Hajnoczi
FOSDEM 2018 will be held in Brussels, Belgium on February 3 & 4, 2018.
The Virt & Iaas Devroom is hosting talks on KVM, Libvirt, QEMU,
OpenStack, and more.
The submission deadline for talks is 1 December 2017. See the Call
For Papers below for details.
I hope to see you there!
Stefan
---
I am excited to announce that the call for proposals is now open for the
Virtualization & IaaS devroom at the upcoming FOSDEM 2018, to be hosted
on February 3 and 4, 2018.
This year will mark FOSDEM’s 18th anniversary as one of the longest-running
free and open source software developer events, attracting thousands of
developers and users from all over the world. FOSDEM will be held once
again in Brussels, Belgium, on February 3 & 4, 2018.
This devroom is a collaborative effort, and is organized by dedicated
folks from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM,
libvirt, and Foreman. We would like to invite all those who are involved
in these fields to submit your proposals by December 1st, 2017.
About the Devroom
The Virtualization & IaaS devroom will feature session topics such as open
source hypervisors and virtual machine managers such as Xen Project, KVM,
bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as
Apache CloudStack, OpenStack, oVirt, QEMU, OpenNebula, and Ganeti.
This devroom will host presentations that focus on topics of shared
interest, such as KVM; libvirt; shared storage; virtualized networking;
cloud security; clustering and high availability; interfacing with multiple
hypervisors; hyperconverged deployments; and scaling across hundreds or
thousands of servers.
Presentations in this devroom will be aimed at developers working on these
platforms who are looking to collaborate and improve shared infrastructure
or solve common problems. We seek topics that encourage dialog between
projects and continued work post-FOSDEM.
Important Dates
Submission deadline: 01 December 2017
Acceptance notifications: 14 December 2017
Final schedule announcement: 21 December 2017
Devroom: 03 and 04 February 2018 (two days- different rooms)
Submit Your Proposal
All submissions must be made via the Pentabarf event planning site[1]. If
you have not used Pentabarf before, you will need to create an account. If
you submitted proposals for FOSDEM in previous years, you can use your
existing account.
After creating the account, select Create Event to start the submission
process. Make sure to select Virtualization and IaaS devroom from the Track
list. Please fill out all the required fields, and provide a meaningful
abstract and description of your proposed session.
Submission Guidelines
We expect more proposals than we can possibly accept, so it is vitally
important that you submit your proposal on or before the deadline. Late
submissions are unlikely to be considered.
All presentation slots are 45 minutes, with 35 minutes planned for
presentations, and 10 minutes for Q&A.
All presentations will be recorded and made available under Creative
Commons licenses. In the Submission notes field, please indicate that you
agree that your presentation will be licensed under the CC-By-SA-4.0 or
CC-By-4.0 license and that you agree to have your presentation recorded.
For example:
"If my presentation is accepted for FOSDEM, I hereby agree to license all
recordings, slides, and other associated materials under the Creative
Commons Attribution Share-Alike 4.0 International License. Sincerely,
<NAME>."
In the Submission notes field, please also confirm that if your talk is
accepted, you will be able to attend FOSDEM and deliver your presentation.
We will not consider proposals from prospective speakers who are unsure
whether they will be able to secure funds for travel and lodging to attend
FOSDEM. (Sadly, we are not able to offer travel funding for prospective
speakers.)
Speaker Mentoring Program
As a part of the rising efforts to grow our communities and encourage a
diverse and inclusive conference ecosystem, we're happy to announce that
we'll be offering mentoring for new speakers. Our mentors can help you with
tasks such as reviewing your abstract, reviewing your presentation outline
or slides, or practicing your talk with you.
You may apply to the mentoring program as a newcomer speaker if you:
Never presented before or
Presented only lightning talks or
Presented full-length talks at small meetups (<50 ppl)
Submission Guidelines
Mentored presentations will have 25-minute slots, where 20 minutes will
include the presentation and 5 minutes will be reserved for questions.
The number of newcomer session slots is limited, so we will probably not be
able to accept all applications.
You must submit your talk and abstract to apply for the mentoring program,
our mentors are volunteering their time and will happily provide feedback
but won't write your presentation for you!
If you are experiencing problems with Pentabarf, the proposal submission
interface, or have other questions, you can email our devroom mailing
list[2] and we will try to help you.
How to Apply
In addition to agreeing to video recording and confirming that you can
attend FOSDEM in case your session is accepted, please write "speaker
mentoring program application" in the "Submission notes" field, and list
any prior speaking experience or other relevant information for your
application.
Call for Mentors
Interested in mentoring newcomer speakers? We'd love to have your help!
Please email iaas-virt-devroom at lists.fosdem.org with a short speaker
biography and any specific fields of expertise (for example, KVM,
OpenStack, storage, etc.) so that we can match you with a newcomer speaker
from a similar field. Estimated time investment can be as low as a 5-10
hours in total, usually distributed weekly or bi-weekly.
Never mentored a newcomer speaker but interested to try? As the mentoring
program coordinator, email Brian Proffitt[3] and he will be happy to answer
your questions!
Code of Conduct
Following the release of the updated code of conduct for FOSDEM, we'd like
to remind all speakers and attendees that all of the presentations and
discussions in our devroom are held under the guidelines set in the CoC and
we expect attendees, speakers, and volunteers to follow the CoC at all
times.
If you submit a proposal and it is accepted, you will be required to
confirm that you accept the FOSDEM CoC. If you have any questions about the
CoC or wish to have one of the devroom organizers review your presentation
slides or any other content for CoC compliance, please email us and we will
do our best to assist you.
Call for Volunteers
We are also looking for volunteers to help run the devroom. We need
assistance watching time for the speakers, and helping with video for the
devroom. Please contact me, Brian Proffitt, for more information.
Questions?
If you have any questions about this devroom, please send your questions to
our devroom mailing list. You can also subscribe to the list to receive
updates about important dates, session announcements, and to connect with
other attendees.
See you all at FOSDEM!
[1] <https://penta.fosdem.org/submission/FOSDEM18>
https://penta.fosdem.org/submission/FOSDEM18
[2] iaas-virt-devroom at lists.fosdem.org
<https://lists.fosdem.org/listinfo/fosdem>
[3] bkp at redhat.com
7 years, 1 month
[libvirt] [PATCH] util: Fix leak in virStringTrimOptionalNewline
by Martin Kletzander
Do not access any data if strlen() == 0.
Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
---
src/util/virstring.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/util/virstring.c b/src/util/virstring.c
index eac4774b533e..b2ebce27ff49 100644
--- a/src/util/virstring.c
+++ b/src/util/virstring.c
@@ -1394,9 +1394,13 @@ virStringEncodeBase64(const uint8_t *buf, size_t buflen)
*/
void virStringTrimOptionalNewline(char *str)
{
- char *tmp = str + strlen(str) - 1;
- if (*tmp == '\n')
- *tmp = '\0';
+ size_t len = strlen(str);
+
+ if (!len)
+ return;
+
+ if (str[len - 1] == '\n')
+ str[len - 1] = '\0';
}
--
2.15.0
7 years, 1 month
[libvirt] [PATCH v2 0/9] qemu: command: Refactor handling of disk drive arguments (blockdev-add saga)
by Peter Krempa
Version 2 only prepares for the move of the arguments to -device which
will be used together with -blockdev rather than switching right away.
This will prevent breaking old qemu support since individual parameters
were moved to -device in separate instances.
Peter Krempa (9):
qemu: command: Split out geometry frontend attribute formatting from
-drive
tests: qemuxml2xml: Run the 'disk-serial' test
tests: qemuxml2argv: Test SD card with serial number
qemu: command: Move disk 'serial' into frontend parameter formatter
qemu: command: Move around order of generating -drive arguments
qemu: command: Refactor logic when formatting -drive
qemu: command: Move disk trhottling argument building into a separate
function
qemu: command: Move formatting of disk io error policy from -drive
qemu: command: Anotate formatting of the frontend attributes with
-drive
src/qemu/qemu_command.c | 241 ++++++++++++---------
.../qemuxml2argvdata/qemuxml2argv-boot-cdrom.args | 2 +-
.../qemuxml2argv-boot-complex-bootindex.args | 2 +-
.../qemuxml2argv-boot-complex.args | 2 +-
...xml2argv-boot-menu-disable-drive-bootindex.args | 2 +-
.../qemuxml2argv-boot-menu-disable-drive.args | 2 +-
.../qemuxml2argv-boot-menu-disable.args | 2 +-
.../qemuxml2argv-boot-menu-enable-bootindex.args | 2 +-
...qemuxml2argv-boot-menu-enable-with-timeout.args | 2 +-
.../qemuxml2argv-boot-menu-enable.args | 2 +-
.../qemuxml2argvdata/qemuxml2argv-boot-multi.args | 2 +-
.../qemuxml2argvdata/qemuxml2argv-boot-order.args | 2 +-
.../qemuxml2argvdata/qemuxml2argv-boot-strict.args | 2 +-
.../qemuxml2argv-controller-order.args | 2 +-
tests/qemuxml2argvdata/qemuxml2argv-disk-aio.args | 4 +-
.../qemuxml2argv-disk-cdrom-empty.args | 2 +-
.../qemuxml2argv-disk-cdrom-network-ftp.args | 2 +-
.../qemuxml2argv-disk-cdrom-network-ftps.args | 2 +-
.../qemuxml2argv-disk-cdrom-network-http.args | 2 +-
.../qemuxml2argv-disk-cdrom-network-https.args | 2 +-
.../qemuxml2argv-disk-cdrom-network-tftp.args | 2 +-
...qemuxml2argv-disk-cdrom-tray-no-device-cap.args | 2 +-
.../qemuxml2argv-disk-cdrom-tray.args | 4 +-
.../qemuxml2argvdata/qemuxml2argv-disk-cdrom.args | 2 +-
.../qemuxml2argv-disk-copy_on_read.args | 2 +-
.../qemuxml2argv-disk-drive-boot-cdrom.args | 4 +-
.../qemuxml2argv-disk-drive-boot-disk.args | 4 +-
.../qemuxml2argv-disk-drive-cache-directsync.args | 4 +-
.../qemuxml2argv-disk-drive-cache-unsafe.args | 4 +-
.../qemuxml2argv-disk-drive-cache-v2-none.args | 4 +-
.../qemuxml2argv-disk-drive-cache-v2-wb.args | 4 +-
.../qemuxml2argv-disk-drive-cache-v2-wt.args | 4 +-
.../qemuxml2argv-disk-drive-detect-zeroes.args | 2 +-
.../qemuxml2argv-disk-drive-discard.args | 2 +-
...uxml2argv-disk-drive-error-policy-enospace.args | 6 +-
.../qemuxml2argv-disk-drive-error-policy-stop.args | 6 +-
...gv-disk-drive-error-policy-wreport-rignore.args | 6 +-
.../qemuxml2argv-disk-drive-fmt-qcow.args | 4 +-
.../qemuxml2argv-disk-drive-no-boot.args | 4 +-
.../qemuxml2argv-disk-drive-readonly-disk.args | 2 +-
...qemuxml2argv-disk-drive-readonly-no-device.args | 2 +-
.../qemuxml2argv-disk-drive-shared.args | 4 +-
.../qemuxml2argv-disk-ioeventfd.args | 2 +-
.../qemuxml2argvdata/qemuxml2argv-disk-order.args | 4 +-
.../qemuxml2argvdata/qemuxml2argv-disk-serial.args | 1 +
.../qemuxml2argvdata/qemuxml2argv-disk-serial.xml | 5 +
.../qemuxml2argv-disk-snapshot.args | 4 +-
.../qemuxml2argv-disk-source-pool-mode.args | 12 +-
.../qemuxml2argv-disk-source-pool.args | 4 +-
.../qemuxml2argvdata/qemuxml2argv-disk-virtio.args | 4 +-
tests/qemuxml2argvdata/qemuxml2argv-event_idx.args | 2 +-
.../qemuxml2argv-graphics-spice-timeout.args | 2 +-
.../qemuxml2argv-hugepages-numa.args | 2 +-
.../qemuxml2argv-pci-autoadd-addr.args | 4 +-
.../qemuxml2argv-pci-autoadd-idx.args | 4 +-
.../qemuxml2argv-pci-autofill-addr.args | 4 +-
.../qemuxml2argvdata/qemuxml2argv-pci-bridge.args | 4 +-
tests/qemuxml2argvdata/qemuxml2argv-pci-many.args | 4 +-
.../qemuxml2argv-user-aliases.args | 2 +-
.../qemuxml2xmlout-disk-serial.xml | 47 ++++
tests/qemuxml2xmltest.c | 2 +
61 files changed, 280 insertions(+), 192 deletions(-)
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-serial.xml
--
2.14.3
7 years, 1 month
[libvirt] [PATCH] qemu: domain: Don't call namespace setup for storage already accessed by vm
by Peter Krempa
When doing block commit we need to allow write for members of the
backing chain so that we can commit the data into them.
qemuDomainDiskChainElementPrepare was used for this which since commit
786d8d91b4 calls qemuDomainNamespaceSetupDisk which has very adverse
side-effects, namely it relabels the nodes to the same label it has in
the main namespace. This was messing up permissions for the commit
operation since its touching various parts of a single backing chain.
Since we are are actually not introducing new images at that point add a
flag for qemuDomainDiskChainElementPrepare which will refrain from
calling to the namespace setup function.
Calls from qemuDomainSnapshotCreateSingleDiskActive and
qemuDomainBlockCopyCommon do introduce new members all calls from
qemuDomainBlockCommit do not, so the calls are anotated accordingly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1506072
---
src/qemu/qemu_domain.c | 17 ++++++++++++++---
src/qemu/qemu_domain.h | 3 ++-
src/qemu/qemu_driver.c | 12 ++++++------
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index cc7596bad1..f12450cc69 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -6146,15 +6146,25 @@ qemuDomainDiskChainElementRevoke(virQEMUDriverPtr driver,
/**
* qemuDomainDiskChainElementPrepare:
+ * @driver: qemu driver data
+ * @vm: domain object
+ * @elem: source structure to set access for
+ * @readonly: setup read-only access if true
+ * @newSource: @elem describes a storage source which @vm can't access yet
*
* Allow a VM access to a single element of a disk backing chain; this helper
* ensures that the lock manager, cgroup device controller, and security manager
- * labelling are all aware of each new file before it is added to a chain */
+ * labelling are all aware of each new file before it is added to a chain.
+ *
+ * When modifying permissions of @elem which @vm can already access (is in the
+ * backing chain) @newSource needs to be set to false.
+ */
int
qemuDomainDiskChainElementPrepare(virQEMUDriverPtr driver,
virDomainObjPtr vm,
virStorageSourcePtr elem,
- bool readonly)
+ bool readonly,
+ bool newSource)
{
bool was_readonly = elem->readonly;
virQEMUDriverConfigPtr cfg = NULL;
@@ -6167,7 +6177,8 @@ qemuDomainDiskChainElementPrepare(virQEMUDriverPtr driver,
if (virDomainLockImageAttach(driver->lockManager, cfg->uri, vm, elem) < 0)
goto cleanup;
- if (qemuDomainNamespaceSetupDisk(driver, vm, elem) < 0)
+ if (newSource &&
+ qemuDomainNamespaceSetupDisk(driver, vm, elem) < 0)
goto cleanup;
if (qemuSetupImageCgroup(vm, elem) < 0)
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index e021da51fc..9066f5d0f5 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -689,7 +689,8 @@ void qemuDomainDiskChainElementRevoke(virQEMUDriverPtr driver,
int qemuDomainDiskChainElementPrepare(virQEMUDriverPtr driver,
virDomainObjPtr vm,
virStorageSourcePtr elem,
- bool readonly);
+ bool readonly,
+ bool newSource);
int qemuDomainCleanupAdd(virDomainObjPtr vm,
qemuDomainCleanupCallback cb);
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 3a0e3b6cec..809863be57 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -14570,7 +14570,7 @@ qemuDomainSnapshotCreateSingleDiskActive(virQEMUDriverPtr driver,
}
/* set correct security, cgroup and locking options on the new image */
- if (qemuDomainDiskChainElementPrepare(driver, vm, dd->src, false) < 0) {
+ if (qemuDomainDiskChainElementPrepare(driver, vm, dd->src, false, true) < 0) {
qemuDomainDiskChainElementRevoke(driver, vm, dd->src);
goto cleanup;
}
@@ -17165,7 +17165,7 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm,
keepParentLabel) < 0)
goto endjob;
- if (qemuDomainDiskChainElementPrepare(driver, vm, mirror, false) < 0) {
+ if (qemuDomainDiskChainElementPrepare(driver, vm, mirror, false, true) < 0) {
qemuDomainDiskChainElementRevoke(driver, vm, mirror);
goto endjob;
}
@@ -17558,9 +17558,9 @@ qemuDomainBlockCommit(virDomainPtr dom,
* operation succeeds, but doing that requires tracking the
* operation in XML across libvirtd restarts. */
clean_access = true;
- if (qemuDomainDiskChainElementPrepare(driver, vm, baseSource, false) < 0 ||
+ if (qemuDomainDiskChainElementPrepare(driver, vm, baseSource, false, false) < 0 ||
(top_parent && top_parent != disk->src &&
- qemuDomainDiskChainElementPrepare(driver, vm, top_parent, false) < 0))
+ qemuDomainDiskChainElementPrepare(driver, vm, top_parent, false, false) < 0))
goto endjob;
/* Start the commit operation. Pass the user's original spelling,
@@ -17604,9 +17604,9 @@ qemuDomainBlockCommit(virDomainPtr dom,
if (ret < 0 && clean_access) {
virErrorPtr orig_err = virSaveLastError();
/* Revert access to read-only, if possible. */
- qemuDomainDiskChainElementPrepare(driver, vm, baseSource, true);
+ qemuDomainDiskChainElementPrepare(driver, vm, baseSource, true, false);
if (top_parent && top_parent != disk->src)
- qemuDomainDiskChainElementPrepare(driver, vm, top_parent, true);
+ qemuDomainDiskChainElementPrepare(driver, vm, top_parent, true, false);
if (orig_err) {
virSetError(orig_err);
--
2.14.3
7 years, 1 month
[libvirt] [PATCH 0/5] qemu: Support setting NUMA distances
by Michal Privoznik
Now that XML parsing & formatting is merged this is fairly trivial.
Michal Privoznik (5):
virDomainNumaGetNodeDistance: Fix input arguments validation
numa: Introduce virDomainNumaNodeDistanceSpecified
qemu_capabilities: Introcude QEMU_CAPS_NUMA_DIST
qemu: Support setting NUMA distances
news: Document which drivers support NUMA distances
docs/news.xml | 2 +-
src/conf/numa_conf.c | 15 ++++-
src/conf/numa_conf.h | 4 ++
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 5 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 36 +++++++++++-
.../caps_2.10.0-gicv2.aarch64.xml | 1 +
.../caps_2.10.0-gicv3.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 +
.../qemuxml2argv-numatune-distances.args | 63 +++++++++++++++++++++
.../qemuxml2argv-numatune-distances.xml | 65 ++++++++++++++++++++++
tests/qemuxml2argvtest.c | 2 +
15 files changed, 196 insertions(+), 3 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-distances.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-distances.xml
--
2.13.6
7 years, 1 month
