[libvirt] libvirt python binding and strange errors in logs
by Vasiliy Tolstov
I'm use libvirt-python binding to export some metrics to ganglia from libvirt.
python code http://paste.debian.net/422944/
when this script is running i get many erros in libvirtd.log like this:
error : virNetSocketReadWire:1613 : End of file while reading data:
Input/output error
При этом открывается сокет:
virNetSocketNew:277 : RPC_SOCKET_NEW: sock=0x7fced8036ae0 fd=27
errfd=-1 pid=0 localAddr=::1;16509, remoteAddr=::1;39962
As i understand libvirt try to determine client alive and fails, my
code properly close libvirt connection, but may be it not freed? Or
something else broken with my code?
i'm use libvirt-python from 1.2.1 to 1.2.9 and libvirt from 1.3.0 to 1.3.3
--
Vasiliy Tolstov,
e-mail: v.tolstov(a)selfip.ru
8 years, 7 months
[libvirt] [PATCH] virDomain{Get, Set}PerfEvents: Tweak documentation
by Michal Privoznik
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/libvirt-domain.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 3e144b6..4f473c9 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -9695,11 +9695,13 @@ virDomainOpenChannel(virDomainPtr dom,
* @domain: a domain object
* @params: where to store perf events setting
* @nparams: number of items in @params
- * @flags: extra flags; not used yet, so callers should always pass 0
+ * @flags: bitwise-OR of virDomainModificationImpact
*
- * Get all perf events setting. Possible fields returned in @params are
- * defined by VIR_DOMAIN_PERF_* macros and new fields will likely be
- * introduced in the future.
+ * Get all Linux perf events setting. Possible fields returned in
+ * @params are defined by VIR_PERF_EVENT_* macros and new fields
+ * will likely be introduced in the future.
+ *
+ * Linux perf events are performance analyzing tool in Linux.
*
* Returns -1 in case of failure, 0 in case of success.
*/
@@ -9743,9 +9745,13 @@ int virDomainGetPerfEvents(virDomainPtr domain,
* @params: pointer to perf events parameter object
* @nparams: number of perf event parameters (this value can be the same
* less than the number of parameters supported)
- * @flags: extra flags; not used yet, so callers should always pass 0
+ * @flags: bitwise-OR of virDomainModificationImpact
*
- * Enable or disable the particular list of perf events you care about.
+ * Enable or disable the particular list of Linux perf events you
+ * care about. The @params argument should contain any subset of
+ * VIR_PERF_EVENT_ macros.
+ *
+ * Linux perf events are performance analyzing tool in Linux.
*
* Returns -1 in case of error, 0 in case of success.
*/
--
2.7.3
8 years, 7 months
[libvirt] [PATCH v4 0/5] migration: add multithread compression
by Nikolay Shirokovskiy
Add means to turn multithread compression on during migration.
Add means to pass compression parameters in migration command.
Changes from v3
===============
1. HMP support is dropped.
2. Switch to a different implementation of setting migration parameters.
Version 3 sets all parameters when configuring migration compression.
If parameter is not specified explicitly it is set to hardcoded default
value. New version set only explicitly specified parameters instead.
This has some reproducibility drawbacks which are nevertheless could
be overcomed and this issue will be addressed in another series.
3. Unspecified values are presented by bitset fields rather then
specific values of parameters itself. This is a bit more tedious
implementation to use but if we take it we can pass all parameter
values checking to QEMU.
4. Misc minor changes on Jiri comments.
Eli Qiao (1):
qemumonitorjsontest: add test for getting multithread compress params
Nikolay Shirokovskiy (2):
migration: add compress method option
qemu: migration: add compression options
ShaoHe Feng (2):
qemu monitor: add multithread compress parameters accessors
virsh: add compression options for migration
include/libvirt/libvirt-domain.h | 44 +++++++
src/qemu/qemu_driver.c | 29 ++++-
src/qemu/qemu_migration.c | 246 ++++++++++++++++++++++++++++++++++-----
src/qemu/qemu_migration.h | 30 +++++
src/qemu/qemu_monitor.c | 24 +++-
src/qemu/qemu_monitor.h | 18 +++
src/qemu/qemu_monitor_json.c | 110 +++++++++++++++++
src/qemu/qemu_monitor_json.h | 5 +
tests/qemumonitorjsontest.c | 53 +++++++++
tools/virsh-domain.c | 83 +++++++++++++
tools/virsh.pod | 25 +++-
11 files changed, 628 insertions(+), 39 deletions(-)
--
1.8.3.1
8 years, 7 months
[libvirt] [PATCH] host-validate: Improve CPU flags processing
by Andrea Bolognani
Instead of relying on substring search, tokenize the input
and process each CPU flag separately. This ensures CPU flag
detection will continue to work correctly even if we start
looking for CPU flags whose name might appear as part of
other CPU flags' names.
The result of processing is stored in a virBitmap, which
means we don't have to parse /proc/cpuinfo in its entirety
for each single CPU flag we want to check.
Moreover, use of the newly-introduced virHostValidateCPUFlag
enumeration ensures we don't go looking for random CPU flags
which might actually be simple typos.
---
The concern was raised by John in
https://www.redhat.com/archives/libvir-list/2016-March/msg01301.html
when discussing a new check on the "sie" CPU flag.
tools/virt-host-validate-common.c | 50 +++++++++++++++++++++++++++++----------
tools/virt-host-validate-common.h | 13 +++++++++-
tools/virt-host-validate-qemu.c | 12 ++++++++--
3 files changed, 60 insertions(+), 15 deletions(-)
diff --git a/tools/virt-host-validate-common.c b/tools/virt-host-validate-common.c
index 8ebf73e..57fa332 100644
--- a/tools/virt-host-validate-common.c
+++ b/tools/virt-host-validate-common.c
@@ -31,7 +31,6 @@
#endif /* HAVE_MNTENT_H */
#include <sys/stat.h>
-#include "virutil.h"
#include "viralloc.h"
#include "virfile.h"
#include "virt-host-validate-common.h"
@@ -39,6 +38,10 @@
#define VIR_FROM_THIS VIR_FROM_NONE
+VIR_ENUM_IMPL(virHostValidateCPUFlag, VIR_HOST_VALIDATE_CPU_FLAG_LAST,
+ "vmx",
+ "svm");
+
static bool quiet;
void virHostMsgSetQuiet(bool quietFlag)
@@ -188,29 +191,47 @@ int virHostValidateNamespace(const char *hvname,
}
-bool virHostValidateHasCPUFlag(const char *name)
+virBitmapPtr virHostValidateGetCPUFlags(void)
{
- FILE *fp = fopen("/proc/cpuinfo", "r");
- bool ret = false;
+ FILE *fp;
+ virBitmapPtr flags;
- if (!fp)
- return false;
+ if (!(fp = fopen("/proc/cpuinfo", "r")))
+ return NULL;
+
+ if (!(flags = virBitmapNewQuiet(VIR_HOST_VALIDATE_CPU_FLAG_LAST)))
+ return NULL;
do {
char line[1024];
+ char *saveptr;
+ char *token;
if (!fgets(line, sizeof(line), fp))
break;
- if (strstr(line, name)) {
- ret = true;
- break;
+ if (!(token = strtok_r(line, " \t\n", &saveptr)))
+ continue;
+
+ /* The line we're interested in is marked either as "flags" or
+ * as "Features" depending on the architecture, so check both
+ * prefixes. It's very unlikely that there will be no whitespace
+ * between the line name and the colon, but handle that as well */
+ if (strcmp(token, "flags") && strcmp(token, "flags:") &&
+ strcmp(token, "Features") && strcmp(token, "Features:"))
+ continue;
+
+ while ((token = strtok_r(NULL, " \t\n", &saveptr))) {
+ int value;
+
+ if ((value = virHostValidateCPUFlagTypeFromString(token)) >= 0)
+ ignore_value(virBitmapSetBit(flags, value));
}
} while (1);
VIR_FORCE_FCLOSE(fp);
- return ret;
+ return flags;
}
@@ -359,15 +380,20 @@ int virHostValidateCGroupController(const char *hvname,
int virHostValidateIOMMU(const char *hvname,
virHostValidateLevel level)
{
+ virBitmapPtr flags;
struct stat sb;
const char *bootarg = NULL;
bool isAMD = false, isIntel = false;
- if (virHostValidateHasCPUFlag("vmx"))
+ flags = virHostValidateGetCPUFlags();
+
+ if (flags && virBitmapIsBitSet(flags, VIR_HOST_VALIDATE_CPU_FLAG_VMX))
isIntel = true;
- else if (virHostValidateHasCPUFlag("svm"))
+ else if (flags && virBitmapIsBitSet(flags, VIR_HOST_VALIDATE_CPU_FLAG_SVM))
isAMD = true;
+ virBitmapFree(flags);
+
virHostMsgCheck(hvname, "%s", _("for device assignment IOMMU support"));
if (isIntel) {
diff --git a/tools/virt-host-validate-common.h b/tools/virt-host-validate-common.h
index d4c4759..26e006b 100644
--- a/tools/virt-host-validate-common.h
+++ b/tools/virt-host-validate-common.h
@@ -23,6 +23,8 @@
# define __VIRT_HOST_VALIDATE_COMMON_H__
# include "internal.h"
+# include "virutil.h"
+# include "virbitmap.h"
typedef enum {
VIR_HOST_VALIDATE_FAIL,
@@ -32,6 +34,15 @@ typedef enum {
VIR_HOST_VALIDATE_LAST,
} virHostValidateLevel;
+typedef enum {
+ VIR_HOST_VALIDATE_CPU_FLAG_VMX = 0,
+ VIR_HOST_VALIDATE_CPU_FLAG_SVM,
+
+ VIR_HOST_VALIDATE_CPU_FLAG_LAST,
+} virHostValidateCPUFlag;
+
+VIR_ENUM_DECL(virHostValidateCPUFlag);
+
extern void virHostMsgSetQuiet(bool quietFlag);
extern void virHostMsgCheck(const char *prefix,
@@ -53,7 +64,7 @@ extern int virHostValidateDeviceAccessible(const char *hvname,
virHostValidateLevel level,
const char *hint);
-extern bool virHostValidateHasCPUFlag(const char *name);
+extern virBitmapPtr virHostValidateGetCPUFlags(void);
extern int virHostValidateLinuxKernel(const char *hvname,
int version,
diff --git a/tools/virt-host-validate-qemu.c b/tools/virt-host-validate-qemu.c
index a9f6c1e..b96b020 100644
--- a/tools/virt-host-validate-qemu.c
+++ b/tools/virt-host-validate-qemu.c
@@ -24,14 +24,20 @@
#include "virt-host-validate-qemu.h"
#include "virt-host-validate-common.h"
+#include "virbitmap.h"
int virHostValidateQEMU(void)
{
+ virBitmapPtr flags;
int ret = 0;
virHostMsgCheck("QEMU", "%s", ("for hardware virtualization"));
- if (virHostValidateHasCPUFlag("svm") ||
- virHostValidateHasCPUFlag("vmx")) {
+
+ flags = virHostValidateGetCPUFlags();
+
+ if (flags &&
+ (virBitmapIsBitSet(flags, VIR_HOST_VALIDATE_CPU_FLAG_SVM) ||
+ virBitmapIsBitSet(flags, VIR_HOST_VALIDATE_CPU_FLAG_VMX))) {
virHostMsgPass();
if (virHostValidateDeviceExists("QEMU", "/dev/kvm",
VIR_HOST_VALIDATE_FAIL,
@@ -48,6 +54,8 @@ int virHostValidateQEMU(void)
_("Only emulated CPUs are available, performance will be significantly limited"));
}
+ virBitmapFree(flags);
+
if (virHostValidateDeviceExists("QEMU", "/dev/vhost-net",
VIR_HOST_VALIDATE_WARN,
_("Load the 'vhost_net' module to improve performance "
--
2.5.5
8 years, 7 months
[libvirt] [PATCH 0/6] Couple of perf events APIs fixes
by Michal Privoznik
I really like to see these in before release and thus APIs get
written in the stone.
One note though regarding the last patch: while writing it I've
noticed couple of other getter APIs don't grab any job at all. I
think they should grab _QUERY job though. So maybe those will
need some fixing too.
Michal Privoznik (6):
remoteDomainGetPerfEvents: Re-indent
virDomain{Get,Set}PerfEvents: Add @flags argument
virsh: Prefer VIRSH_COMMON_OPT_DOMAIN_FULL over full enumeration
virsh: Make perf accept event list separated by commas
virDomain{Get,Set}PerfEvents: support --config --live --current
virDomain{Get,Set}PerfEvents: Grab job
daemon/remote.c | 2 +-
include/libvirt/libvirt-domain.h | 6 ++-
src/driver-hypervisor.h | 6 ++-
src/libvirt-domain.c | 22 +++++----
src/qemu/qemu_driver.c | 99 +++++++++++++++++++++++++++++-----------
src/remote/remote_driver.c | 12 +++--
src/remote/remote_protocol.x | 2 +
tools/virsh-domain.c | 27 +++++++----
tools/virsh.pod | 25 ++++++----
9 files changed, 141 insertions(+), 60 deletions(-)
--
2.7.3
8 years, 7 months
[libvirt] Join
by Tim Streit
Im having problems with my install. Debian Jessie (8.3), but using libvirt and kernel from back ports (for enhanced vt-d support, passing through a USB card). Guest is a windows xp sp3 box. Initially I had hardware time set to UTC, and I set the RealTimeIsUtc=1 in the registry. But it would periodically reset itself ahead 6 hours (CST), and since we just changed day light savings time now its jumping 5 hours. Every morning. I have a similarly configured system running a win7 guest, time works fine.
Someone on #kvm suggested that maybe I need to set my hwclock to local time, and so I went through all that - changed it, appended LOCAL to /etc/adjtime etc. I then changed the RealTimeIsUtc=0, and for the first boot it seemed okay.
Now, whenever I boot, it is constantly 5 hours ahead. I can reset it but when you reboot, its back.
Im stumped. Help...
8 years, 7 months
Re: [libvirt] [PATCH V4 4/6] libxl: support creating domain with VF assignment from a pool
by Jim Fehlig
On 03/30/2016 03:38 AM, Chun Yan Liu wrote:
>
>>>> On 3/29/2016 at 08:05 AM, in message <56F9C6D0.5000702(a)suse.com>, Jim Fehlig
> <jfehlig(a)suse.com> wrote:
>> On 03/21/2016 02:11 AM, Chunyan Liu wrote:
>>> Add codes to support creating domain with network defition of assigning
>>> SRIOV VF from a pool.
>>>
>>> Signed-off-by: Chunyan Liu <cyliu(a)suse.com>
>>> ---
>>> src/libxl/libxl_domain.c | 50
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>> tests/Makefile.am | 3 +++
>>> 2 files changed, 53 insertions(+)
>>>
>>> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
>>> index c8d09b1..d11bf3a 100644
>>> --- a/src/libxl/libxl_domain.c
>>> +++ b/src/libxl/libxl_domain.c
>>> @@ -36,6 +36,7 @@
>>> #include "virtime.h"
>>> #include "locking/domain_lock.h"
>>> #include "xen_common.h"
>>> +#include "network/bridge_driver.h"
>>>
>>> #define VIR_FROM_THIS VIR_FROM_LIBXL
>>>
>>> @@ -764,6 +765,10 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
>>> if (net->ifname &&
>>> STRPREFIX(net->ifname, LIBXL_GENERATED_PREFIX_XEN))
>>> VIR_FREE(net->ifname);
>>> +
>>> + /* cleanup actual device */
>>> + virDomainNetRemoveHostdev(vm->def, net);
>>> + networkReleaseActualDevice(vm->def, net);
>>> }
>>> }
>>>
>>> @@ -960,6 +965,48 @@ libxlDomainCreateIfaceNames(virDomainDefPtr def,
>> libxl_domain_config *d_config)
>>> }
>>> }
>>>
>>> +static int
>>> +libxlNetworkPrepareDevices(virDomainDefPtr def)
>>> +{
>>> + int ret = -1;
>>> + size_t i;
>>> +
>>> + for (i = 0; i < def->nnets; i++) {
>>> + virDomainNetDefPtr net = def->nets[i];
>>> + int actualType;
>>> +
>>> + /* If appropriate, grab a physical device from the configured
>>> + * network's pool of devices, or resolve bridge device name
>>> + * to the one defined in the network definition.
>>> + */
>>> + if (networkAllocateActualDevice(def, net) < 0)
>>> + goto cleanup;
>>> +
>>> + actualType = virDomainNetGetActualType(net);
>>> + if (actualType == VIR_DOMAIN_NET_TYPE_HOSTDEV &&
>>> + net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
>>> + /* Each type='hostdev' network device must also have a
>>> + * corresponding entry in the hostdevs array. For netdevs
>>> + * that are hardcoded as type='hostdev', this is already
>>> + * done by the parser, but for those allocated from a
>>> + * network / determined at runtime, we need to do it
>>> + * separately.
>>> + */
>>> + virDomainHostdevDefPtr hostdev =
>> virDomainNetGetActualHostdev(net);
>>> + virDomainHostdevSubsysPCIPtr pcisrc =
>> &hostdev->source.subsys.u.pci;
>>> +
>>> + if (hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS &&
>>> + hostdev->source.subsys.type ==
>> VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI)
>>> + pcisrc->backend = VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN;
>>> +
>>> + if (virDomainHostdevInsert(def, hostdev) < 0)
>>> + goto cleanup;
>>> + }
>>> + }
>>> + ret = 0;
>>> + cleanup:
>>> + return ret;
>>
>> Nothing to cleanup here. I think we should just return -1 on failure paths
>> and 0
>> on success.
>>
>>> +}
>>>
>>> /*
>>> * Start a domain through libxenlight.
>>> @@ -1036,6 +1083,9 @@ libxlDomainStart(libxlDriverPrivatePtr driver,
>> virDomainObjPtr vm,
>>> vm, true) < 0)
>>> goto cleanup;
>>>
>>> + if (libxlNetworkPrepareDevices(vm->def) < 0)
>>> + goto cleanup;
>>
>> I accessed a machine to test this series and have found a few problems.
>>
>> 1. When attaching an SR-IOV vf from a pool, the attach appears successful.
>> I see that xen's pciback driver is bound to the device in the host. I
>> didn't see the device in the guest (could be a guest problem),
> For pv guest, from testing, it is shown in guest. For HVM, seems
> xl pci-attach has the same result.
Yes, I'm seeing the same thing. Looks like a bug in libxl or qemu.
>> nor in
>> dumpxml or /var/run/libvirt/libxl/<dom-name>.xml.
> Ah, there is a mistake during a review change to original patch 1/6.
> Didn't notice that earlier.
>
> In libxlDomainAttachNetDevice:
> The if (!ret) is needed, maybe cleanup is not proper.
> Since for actual type is hostdev case, after a successful
> libxlDomainAttachHostDevice, we need to
> update vm->def->nets too.
>
> cleanup:
> libxl_device_nic_dispose(&nic);
> - out:
> - if (!ret)
> + if (!ret) {
> vm->def->nets[vm->def->nnets++] = net;
> + } else {
> + virDomainNetRemoveHostdev(vm->def, net);
> + networkReleaseActualDevice(vm->def, net);
> + }
>
> Similar for libxDomainDetachNetDevice cleanup:
> Original is still needed.
>
> cleanup:
> libxl_device_nic_dispose(&nic);
> - if (!ret)
> + if (!ret) {
> + networkReleaseActualDevice(vm->def, detach);
> virDomainNetRemove(vm->def, detachidx);
> + }
Yikes! I should have looked at the code closer before making those changes -
lesson learned. I sent a small series to fix it
https://www.redhat.com/archives/libvir-list/2016-March/msg01470.html
>> Not surprisingly,
>> this causes problems with device-detach
>>
>> # virsh detach-device dom sriov-pool-vif.xml
>> error: Failed to detach device from sriov-pool-vif.xml
>> error: operation failed: no device matching mac address 00:16:3e:7a:35:df
>> found
>>
>> 2. After starting a domain containing an interface from sr-iov vf pool, the
>> interface xml is changed from type='network' to type='hostdev'. E.g.
>> before creating domain
>>
>> <interface type='network'>
>> <source network='passthrough'/>
>> <mac address='00:16:3e:7a:35:df'/>
>> </interface>
>>
>> after creating domain
>>
>> <interface type='hostdev' managed='yes'>
>> <mac address='00:16:3e:7a:35:df'/>
>> <driver name='xen'/>
>> <source>
>> <address type='pci' domain='0x0000' bus='0x0a' slot='0x11'
>> function='0x1'/>
>> </source>
>> </interface>
>>
>> Maybe this is intended behavior, but it seems odd.
> This is intended.
>
>>
>> 3. I started a domain containing an interface from sr-iov vf pool. Looks
>> good. I then tried 'virsh detach-device ...', which never returned
>> until keepalive timeout. The device was removed from the guest, but
>> libvirtd got hung up in the process. Oddly, I wasn't able to interrupt
>> libvirtd with gdb to see what its threads were doing.
> This is libxl problem. With xl pci-detach, it has the same issue.
Yep, another bug in xen-unstable libxl. With the small fixes in the series I
mentioned above, this patch looks and tests good :-). Since it has been around
for quite some time, I've asked for permission to commit it even though we are
in 1.3.3 freeze.
Regards,
Jim
8 years, 7 months
[libvirt] [PATCH 0/3] qemu: fix automatic NUMA pinning with memory hotplug
by Peter Krempa
We forgot to propagate the automatic nodeset and reported non-ideal errors.
Peter Krempa (3):
qemu: command: Pass numad nodeset when formatting memory devices at
boot
qemu: command: Split up formatting of -numa and memory devices
qemu: hotplug: Improve error when hotpluging memory with
auto-placement
src/conf/numa_conf.c | 20 +++++++++++++++++---
src/conf/numa_conf.h | 1 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_command.c | 27 ++++++++++++++-------------
src/qemu/qemu_hotplug.c | 7 +++++++
5 files changed, 40 insertions(+), 16 deletions(-)
--
2.7.3
8 years, 8 months
[libvirt] [PATCH v7 0/4] ARM: add query-gic-capabilities QMP command
by Peter Xu
v7 changes:
- patch 1
- add more to commit log, about how to use the results [Markus]
- change interface from dict back to array [Markus, Eric]
- patch 2
- kvm_arm_create_scratch_host_vcpu should raise error when init
non-zero, but failed to find a good CPU model [Sergey]
- patch 3
- rename function to kvm_device_supported [Sergey]
- patch 4
- comment line from "FIXME" to "TODO" [Sergey]
- make kvm-related part another function [Sergey]
- change result to array to follow patch 1's change
v6 changes:
- patch 1 (squashed into patch 2)
- explain more about the following in commit message: why we need
this command, and what does the entries mean [Markus]
- explain what GIC is [Eric]
- squash this patch into patch 2 [Eric]
- patch 2 (new patch 1)
- fix "does not implement" english error [Eric]
- remove useless headers in target-arm/monitor.c [Markus]
- remove this command from whitelist [Markus, Eric]
- return dict rather than array, with single key points to the
original array results [Markus, Eric]
- patch 5 (new patch 4)
- tiny change in implementation to suite the new interface.
v5 changes:
- patch 2: moved to target-arm/monitor.c (from target-arm/machine.c)
[Peter]
- patch 3: splitted into three patches: [all from Peter's comments]
- patch 3 (new): leverage kvm_arm_create_scratch_host_vcpu(), tiny
enhancement of old one to suite our need
- patch 4: introduce kvm_support_device() in kvm-all.c
- patch 5: do the implementation.
v4 changes:
- all: rename query-gic-capability to query-gic-capabilities [Andrea]
- patch 3: rename helper function to kvm_support_device, make it
inline and lighter. [Drew]
v3 changes:
- patch 2: remove func declaration, add qmp header [Drew]
- patch 3: being able to detect KVM GIC capabilities even without
kvm enabled [Andrea]: this is a little bit hacky, need some more
review on this.
v2 changes:
- result layout change: use array and dict for the capability bits
rather than a single array of strings [Andrea/Markus]
- spelling out what GIC is in doc [Eric]
This patch is to add ARM-specific command "query-gic-capability".
The new command can report which kind of GIC device the host/QEMU
support. The returned result is in the form of array.
Sample command and output:
{"execute": "query-gic-capability"}
{"return": [{"emulated": false, "version": 3, "kernel": false},
{"emulated": true, "version": 2, "kernel": true}]}
Testing:
Smoke tests on both x86 (emulated) and another moonshot ARM server.
Peter Xu (4):
arm: qmp: add query-gic-capabilities interface
arm: enhance kvm_arm_create_scratch_host_vcpu
kvm: add kvm_device_supported() helper function
arm: implement query-gic-capabilities
include/sysemu/kvm.h | 9 ++++++
kvm-all.c | 15 +++++++++
monitor.c | 8 +++++
qapi-schema.json | 36 +++++++++++++++++++++
qmp-commands.hx | 27 ++++++++++++++++
target-arm/Makefile.objs | 2 +-
target-arm/kvm.c | 14 +++++++-
target-arm/kvm_arm.h | 6 ++--
target-arm/monitor.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++
9 files changed, 197 insertions(+), 4 deletions(-)
create mode 100644 target-arm/monitor.c
--
2.4.3
8 years, 8 months
[libvirt] [PATCH] docs: Don't use bold text in headers and menu items
by Andrea Bolognani
Now that headers and menu items are using a bigger font and more
generous spacing, they don't really need to be bold to stand out.
---
This applies on top of Cole's series
https://www.redhat.com/archives/libvir-list/2016-March/msg00323.html
docs/apps.html.in | 2 +-
docs/generic.css | 2 +-
docs/libvirt.css | 11 +----------
3 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/docs/apps.html.in b/docs/apps.html.in
index 39fb78d..b8337b9 100644
--- a/docs/apps.html.in
+++ b/docs/apps.html.in
@@ -2,7 +2,7 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
- <h1>Applications using <strong>libvirt</strong></h1>
+ <h1>Applications using libvirt</h1>
<p>
This page provides an illustration of the wide variety of
diff --git a/docs/generic.css b/docs/generic.css
index e862fe0..94b9612 100644
--- a/docs/generic.css
+++ b/docs/generic.css
@@ -45,7 +45,7 @@ dl dd {
h1, h2, h3, h4, h5, h6 {
- font-weight: bold;
+ font-weight: normal;
margin: 0px;
padding: 0px;
margin-top: 0.5em;
diff --git a/docs/libvirt.css b/docs/libvirt.css
index 17ecbb4..3b65f4c 100644
--- a/docs/libvirt.css
+++ b/docs/libvirt.css
@@ -1,12 +1,4 @@
-h1 {
- font-weight: normal;
- color: #3c857c;
-}
-h1 strong {
- font-weight: bold;
-}
-
-h2, h3, h4, h5, h6 {
+h1, h2, h3, h4, h5, h6 {
color: #3c857c;
}
@@ -55,7 +47,6 @@ h2, h3, h4, h5, h6 {
padding: 0px;
margin: 0px;
border: 0px;
- font-weight: bold;
font-size: 1.2em;
}
--
2.5.0
8 years, 8 months
