[libvirt PATCH 0/2] Fix some nodedev documentation
by Jonathon Jongsma
In response to a comment by Daniel Berrange about documentation on my previous
patch series, I noticed that the node device xml format documentation appears
to be split between two different pages. It seems better to document the schema
fully on the formatdomain page and refer to it from the other page. Another
small patch fixes a documentation error.
Jonathon Jongsma (2):
docs: Fix names for PF and VF PCI device capabilities
docs: Document full node device xml in formatnode.html.in
docs/drvnodedev.html.in | 127 ++++------------------------------------
docs/formatnode.html.in | 74 +++++++++++++++++++++--
2 files changed, 83 insertions(+), 118 deletions(-)
--
2.21.3
4 years, 6 months
[libvirt PATCH] docs: drvnodedev: Fix a few closing XML elements in the examples
by Erik Skultety
Signed-off-by: Erik Skultety <eskultet(a)redhat.com>
---
Pushed as trivial.
docs/drvnodedev.html.in | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/drvnodedev.html.in b/docs/drvnodedev.html.in
index 71a8a57b0c..a9c86f9fc7 100644
--- a/docs/drvnodedev.html.in
+++ b/docs/drvnodedev.html.in
@@ -184,7 +184,7 @@
<address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</capability>
...
-<device></pre>
+</device></pre>
<h3><a id="MDEVCap">MDEV capability</a></h3>
<p>
@@ -300,8 +300,8 @@
<capability type='mdev'>
<type id='nvidia-11'/>
<iommuGroup number='12'/>
- <capability/>
-<device/></pre>
+ </capability>
+</device></pre>
<p>
The support of mediated device's framework in libvirt's node device driver
--
2.25.4
4 years, 6 months
[libvirt PATCH 0/4] scripts: improve API docs handing of enums
by Daniel P. Berrangé
In attempting to refactor the Go API bindings to be partially
auto-generated, I'm encountering missing information in the enum
descriptions.
The effects of this series are shown in this diff:
--- libvirt-api.xml 2020-05-19 12:47:22.003489289 +0100
+++ docs/libvirt-api.xml 2020-05-19 12:47:27.156476186 +0100
@@ -1,4 +1,4 @@
-<?xml version=3D"1.0" encoding=3D"ISO-8859-1"?>
+<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<api name=3D'libvirt'>
<files>
<file name=3D'libvirt-domain-checkpoint'>
@@ -2089,13 +2089,13 @@
</file>
</files>
<symbols>
- <macro name=3D'LIBVIR_CHECK_VERSION' file=3D'libvirt-common'>
+ <macro name=3D'LIBVIR_CHECK_VERSION' file=3D'libvirt-common' params=3D'm=
ajor,minor,micro' raw=3D'((major) * 1000000 + (minor) * 1000 + (micro) <=3D L=
IBVIR_VERSION_NUMBER)'>
<info><![CDATA[Macro for developers to easily check what version of th=
e library their code is compiling against. e.g. #if LIBVIR_CHECK_VERSION(1,1,=
3) // some code that only works in 1.1.3 and newer #endif]]></info>
<arg name=3D'major' info=3D'major component of the version number'/>
<arg name=3D'minor' info=3D'minor component of the version number'/>
<arg name=3D'micro' info=3D'micro component of the version number'/>
</macro>
- <macro name=3D'LIBVIR_VERSION_NUMBER' file=3D'libvirt-common'>
+ <macro name=3D'LIBVIR_VERSION_NUMBER' file=3D'libvirt-common' raw=3D'600=
4000'>
<info><![CDATA[Macro providing the version of the library as version *=
1,000,000 + minor * 1000 + micro]]></info>
</macro>
<macro name=3D'VIR_CONNECT_IDENTITY_GROUP_NAME' file=3D'libvirt-host' st=
ring=3D'group-name'>
@@ -2125,25 +2125,25 @@
<macro name=3D'VIR_CONNECT_IDENTITY_X509_DISTINGUISHED_NAME' file=3D'lib=
virt-host' string=3D'x509-distinguished-name'>
<info><![CDATA[The TLS x509 certificate distinguished named as VIR_TYP=
ED_PARAM_STRING]]></info>
</macro>
- <macro name=3D'VIR_COPY_CPUMAP' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_COPY_CPUMAP' file=3D'libvirt-domain' params=3D'cpumap=
s,maplen,vcpu,cpumap' raw=3D'memcpy(cpumap, VIR_GET_CPUMAP(cpumaps, maplen, v=
cpu), maplen)'>
<info><![CDATA[This macro is to be used in conjunction with virDomainG=
etVcpus() and virDomainPinVcpu() APIs. VIR_COPY_CPUMAP macro extracts the cpu=
map of the specified vcpu from cpumaps array and copies it into cpumap to be =
used later by virDomainPinVcpu() API.]]></info>
<arg name=3D'cpumaps' info=3D'pointer to an array of cpumap (in 8-bit =
bytes) (IN)'/>
<arg name=3D'maplen' info=3D'the length (in bytes) of one cpumap'/>
<arg name=3D'vcpu' info=3D'the virtual CPU number'/>
<arg name=3D'cpumap' info=3D'pointer to a cpumap (in 8-bit bytes) (OUT=
) This cpumap must be previously allocated by the caller (ie: malloc(maplen))=
'/>
</macro>
- <macro name=3D'VIR_CPU_MAPLEN' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_CPU_MAPLEN' file=3D'libvirt-domain' params=3D'cpu' ra=
w=3D''>
<info><![CDATA[This macro is to be used in conjunction with virDomainP=
inVcpu() API. It returns the length (in bytes) required to store the complete=
CPU map between a single virtual & all physical CPUs of a domain.]]></info>
<arg name=3D'cpu' info=3D'number of physical CPUs'/>
</macro>
- <macro name=3D'VIR_CPU_USABLE' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_CPU_USABLE' file=3D'libvirt-domain' params=3D'cpumaps=
,maplen,vcpu,cpu' raw=3D'VIR_CPU_USED(VIR_GET_CPUMAP(cpumaps, maplen, vcpu), =
cpu)'>
<info><![CDATA[This macro is to be used in conjunction with virDomainG=
etVcpus() API. VIR_CPU_USABLE macro returns a non-zero value (true) if the cp=
u is usable by the vcpu, and 0 otherwise.]]></info>
<arg name=3D'cpumaps' info=3D'pointer to an array of cpumap (in 8-bit =
bytes) (IN)'/>
<arg name=3D'maplen' info=3D'the length (in bytes) of one cpumap'/>
<arg name=3D'vcpu' info=3D'the virtual CPU number'/>
<arg name=3D'cpu' info=3D'the physical CPU number'/>
</macro>
- <macro name=3D'VIR_CPU_USED' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_CPU_USED' file=3D'libvirt-domain' params=3D'cpumap,cp=
u' raw=3D'((cpumap)[(cpu) / 8] & (1 << ((cpu) % 8)))'>
<info><![CDATA[This macro can be used in conjunction with virNodeGetCP=
UMap() API. It returns non-zero if the bit of the related CPU is set.]]></inf=
o>
<arg name=3D'cpumap' info=3D'pointer to a bit map of real CPUs (in 8-b=
it bytes) (IN)'/>
<arg name=3D'cpu' info=3D'the physical CPU number'/>
@@ -2184,7 +2184,7 @@
<macro name=3D'VIR_DOMAIN_BLKIO_DEVICE_WRITE_IOPS' file=3D'libvirt-domai=
n' string=3D'device_write_iops_sec'>
<info><![CDATA[Macro for the blkio tunable throttle.write_iops_device:=
it represents the number of writing the block device per second, as a string=
. The string is parsed as a series of /path/to/device, write_iops elements, s=
eparated by ','.]]></info>
</macro>
- <macro name=3D'VIR_DOMAIN_BLKIO_FIELD_LENGTH' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_DOMAIN_BLKIO_FIELD_LENGTH' file=3D'libvirt-domain' ra=
w=3D'VIR_TYPED_PARAM_FIELD_LENGTH'>
<info><![CDATA[Macro providing the field length of virBlkioParameter. =
Provided for backwards compatibility; VIR_TYPED_PARAM_FIELD_LENGTH is the pr=
eferred value since 0.9.2.]]></info>
</macro>
<macro name=3D'VIR_DOMAIN_BLKIO_WEIGHT' file=3D'libvirt-domain' string=
=3D'weight'>
@@ -2262,7 +2262,7 @@
<macro name=3D'VIR_DOMAIN_BLOCK_STATS_ERRS' file=3D'libvirt-domain' stri=
ng=3D'errs'>
<info><![CDATA[In Xen this returns the mysterious 'oo_req', as an llon=
g.]]></info>
</macro>
- <macro name=3D'VIR_DOMAIN_BLOCK_STATS_FIELD_LENGTH' file=3D'libvirt-doma=
in'>
+ <macro name=3D'VIR_DOMAIN_BLOCK_STATS_FIELD_LENGTH' file=3D'libvirt-doma=
in' raw=3D'VIR_TYPED_PARAM_FIELD_LENGTH'>
<info><![CDATA[Macro providing the field length of parameter names whe=
n using virDomainBlockStatsFlags().]]></info>
</macro>
<macro name=3D'VIR_DOMAIN_BLOCK_STATS_FLUSH_REQ' file=3D'libvirt-domain'=
string=3D'flush_operations'>
@@ -2301,7 +2301,7 @@
<macro name=3D'VIR_DOMAIN_CPU_STATS_VCPUTIME' file=3D'libvirt-domain' st=
ring=3D'vcpu_time'>
<info><![CDATA[vcpu usage in nanoseconds (cpu_time excluding hyperviso=
r time), as a ullong]]></info>
</macro>
- <macro name=3D'VIR_DOMAIN_EVENT_CALLBACK' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_DOMAIN_EVENT_CALLBACK' file=3D'libvirt-domain' params=
=3D'cb' raw=3D''>
<info><![CDATA[Used to cast the event specific callback into the gener=
ic one for use for virConnectDomainEventRegisterAny()]]></info>
</macro>
<macro name=3D'VIR_DOMAIN_IOTHREAD_POLL_GROW' file=3D'libvirt-domain' st=
ring=3D'poll_grow'>
@@ -2421,7 +2421,7 @@
<macro name=3D'VIR_DOMAIN_LAUNCH_SECURITY_SEV_MEASUREMENT' file=3D'libvi=
rt-domain' string=3D'sev-measurement'>
<info><![CDATA[Macro represents the launch measurement of the SEV gues=
t, as VIR_TYPED_PARAM_STRING.]]></info>
</macro>
- <macro name=3D'VIR_DOMAIN_MEMORY_FIELD_LENGTH' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_DOMAIN_MEMORY_FIELD_LENGTH' file=3D'libvirt-domain' r=
aw=3D'VIR_TYPED_PARAM_FIELD_LENGTH'>
<info><![CDATA[Macro providing the field length of virMemoryParameter.=
Provided for backwards compatibility; VIR_TYPED_PARAM_FIELD_LENGTH is the p=
referred value since 0.9.2.]]></info>
</macro>
<macro name=3D'VIR_DOMAIN_MEMORY_HARD_LIMIT' file=3D'libvirt-domain' str=
ing=3D'hard_limit'>
@@ -2430,7 +2430,7 @@
<macro name=3D'VIR_DOMAIN_MEMORY_MIN_GUARANTEE' file=3D'libvirt-domain' =
string=3D'min_guarantee'>
<info><![CDATA[Macro for the memory tunable min_guarantee: it represen=
ts the minimum memory guaranteed to be reserved for the guest, as a ullong.]]=
></info>
</macro>
- <macro name=3D'VIR_DOMAIN_MEMORY_PARAM_UNLIMITED' file=3D'libvirt-domain=
'>
+ <macro name=3D'VIR_DOMAIN_MEMORY_PARAM_UNLIMITED' file=3D'libvirt-domain=
' raw=3D'9007199254740991LL /* =3D INT64_MAX >> 10 */'>
<info><![CDATA[Macro providing the virMemoryParameter value that indic=
ates "unlimited"]]></info>
</macro>
<macro name=3D'VIR_DOMAIN_MEMORY_SOFT_LIMIT' file=3D'libvirt-domain' str=
ing=3D'soft_limit'>
@@ -2487,10 +2487,10 @@
<macro name=3D'VIR_DOMAIN_SCHEDULER_WEIGHT' file=3D'libvirt-domain' stri=
ng=3D'weight'>
<info><![CDATA[Macro represents the relative weight, when using the c=
redit scheduler, as a uint.]]></info>
</macro>
- <macro name=3D'VIR_DOMAIN_SCHED_FIELD_LENGTH' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_DOMAIN_SCHED_FIELD_LENGTH' file=3D'libvirt-domain' ra=
w=3D'VIR_TYPED_PARAM_FIELD_LENGTH'>
<info><![CDATA[Macro providing the field length of virSchedParameter. =
Provided for backwards compatibility; VIR_TYPED_PARAM_FIELD_LENGTH is the pr=
eferred value since 0.9.2.]]></info>
</macro>
- <macro name=3D'VIR_DOMAIN_SEND_KEY_MAX_KEYS' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_DOMAIN_SEND_KEY_MAX_KEYS' file=3D'libvirt-domain' raw=
=3D'16'>
<info><![CDATA[Maximum number of keycodes that can be sent in one virD=
omainSendKey() call.]]></info>
</macro>
<macro name=3D'VIR_DOMAIN_TUNABLE_BLKDEV_DISK' file=3D'libvirt-domain' s=
tring=3D'blkdeviotune.disk'>
@@ -2592,13 +2592,13 @@
<macro name=3D'VIR_DOMAIN_TUNABLE_CPU_VCPU_QUOTA' file=3D'libvirt-domain=
' string=3D'cputune.vcpu_quota'>
<info><![CDATA[Macro represents the maximum bandwidth to be used withi=
n a period for vcpus only, when using the posix scheduler, as VIR_TYPED_PARAM=
_LLONG.]]></info>
</macro>
- <macro name=3D'VIR_GET_CPUMAP' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_GET_CPUMAP' file=3D'libvirt-domain' params=3D'cpumaps=
,maplen,vcpu' raw=3D'(&((cpumaps)[(vcpu) * (maplen)]))'>
<info><![CDATA[This macro is to be used in conjunction with virDomainG=
etVcpus() and virDomainPinVcpu() APIs. VIR_GET_CPUMAP macro returns a pointer=
to the cpumap of the specified vcpu from cpumaps array.]]></info>
<arg name=3D'cpumaps' info=3D'pointer to an array of cpumap (in 8-bit =
bytes) (IN)'/>
<arg name=3D'maplen' info=3D'the length (in bytes) of one cpumap'/>
<arg name=3D'vcpu' info=3D'the virtual CPU number'/>
</macro>
- <macro name=3D'VIR_KEYCODE_SET_RFB' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_KEYCODE_SET_RFB' file=3D'libvirt-domain' raw=3D'VIR_K=
EYCODE_SET_QNUM'>
<info><![CDATA[Compatibility alias for VIR_KEYCODE_SET_QNUM, which rep=
laced it since 4.2.0.]]></info>
</macro>
<macro name=3D'VIR_MIGRATE_PARAM_AUTO_CONVERGE_INCREMENT' file=3D'libvir=
t-domain' string=3D'auto_converge.increment'>
@@ -2658,7 +2658,7 @@
<macro name=3D'VIR_MIGRATE_PARAM_URI' file=3D'libvirt-domain' string=3D'=
migrate_uri'>
<info><![CDATA[virDomainMigrate* params field: URI to use for initiati=
ng domain migration as VIR_TYPED_PARAM_STRING. It takes a hypervisor specific=
format. The uri_transports element of the hypervisor capabilities XML includ=
es details of the supported URI schemes. When omitted libvirt will auto-gener=
ate suitable default URI. It is typically only necessary to specify this URI =
if the destination host has multiple interfaces and a specific interface is r=
equired to transmit migration data. This field may not be used when VIR_MIGR=
ATE_TUNNELLED flag is set.]]></info>
</macro>
- <macro name=3D'VIR_NETWORK_EVENT_CALLBACK' file=3D'libvirt-network'>
+ <macro name=3D'VIR_NETWORK_EVENT_CALLBACK' file=3D'libvirt-network' para=
ms=3D'cb' raw=3D''>
<info><![CDATA[Used to cast the event specific callback into the gener=
ic one for use for virConnectNetworkEventRegisterAny()]]></info>
</macro>
<macro name=3D'VIR_NETWORK_PORT_BANDWIDTH_IN_AVERAGE' file=3D'libvirt-ne=
twork' string=3D'inbound.average'>
@@ -2682,11 +2682,11 @@
<macro name=3D'VIR_NETWORK_PORT_BANDWIDTH_OUT_PEAK' file=3D'libvirt-netw=
ork' string=3D'outbound.peak'>
<info><![CDATA[Macro represents the outbound peak of NIC bandwidth, as=
a uint.]]></info>
</macro>
- <macro name=3D'VIR_NODEINFO_MAXCPUS' file=3D'libvirt-host'>
+ <macro name=3D'VIR_NODEINFO_MAXCPUS' file=3D'libvirt-host' params=3D'nod=
einfo' raw=3D''>
<info><![CDATA[This macro is to calculate the total number of CPUs sup=
ported but not necessary active in the host.]]></info>
<arg name=3D'nodeinfo' info=3D'virNodeInfo instance'/>
</macro>
- <macro name=3D'VIR_NODE_CPU_STATS_FIELD_LENGTH' file=3D'libvirt-host'>
+ <macro name=3D'VIR_NODE_CPU_STATS_FIELD_LENGTH' file=3D'libvirt-host' ra=
w=3D'80'>
<info><![CDATA[Macro providing the field length of virNodeCPUStats]]><=
/info>
</macro>
<macro name=3D'VIR_NODE_CPU_STATS_IDLE' file=3D'libvirt-host' string=3D'=
idle'>
@@ -2707,7 +2707,7 @@
<macro name=3D'VIR_NODE_CPU_STATS_UTILIZATION' file=3D'libvirt-host' str=
ing=3D'utilization'>
<info><![CDATA[The CPU utilization of a node. The usage value is in pe=
rcent and 100% represents all CPUs of the node.]]></info>
</macro>
- <macro name=3D'VIR_NODE_DEVICE_EVENT_CALLBACK' file=3D'libvirt-nodedev'>
+ <macro name=3D'VIR_NODE_DEVICE_EVENT_CALLBACK' file=3D'libvirt-nodedev' =
params=3D'cb' raw=3D'((virConnectNodeDeviceEventGenericCallback)(cb))'>
<info><![CDATA[Used to cast the event specific callback into the gener=
ic one for use for virConnectNodeDeviceEventRegisterAny()]]></info>
</macro>
<macro name=3D'VIR_NODE_MEMORY_SHARED_FULL_SCANS' file=3D'libvirt-host' =
string=3D'shm_full_scans'>
@@ -2740,7 +2740,7 @@
<macro name=3D'VIR_NODE_MEMORY_STATS_CACHED' file=3D'libvirt-host' strin=
g=3D'cached'>
<info><![CDATA[Macro for the cached memory: On Linux, it is only retur=
ned in case of VIR_NODE_MEMORY_STATS_ALL_CELLS.]]></info>
</macro>
- <macro name=3D'VIR_NODE_MEMORY_STATS_FIELD_LENGTH' file=3D'libvirt-host'>
+ <macro name=3D'VIR_NODE_MEMORY_STATS_FIELD_LENGTH' file=3D'libvirt-host'=
raw=3D'80'>
<info><![CDATA[Macro providing the field length of virNodeMemoryStats]=
]></info>
</macro>
<macro name=3D'VIR_NODE_MEMORY_STATS_FREE' file=3D'libvirt-host' string=
=3D'free'>
@@ -2827,45 +2827,45 @@
<macro name=3D'VIR_PERF_PARAM_TASK_CLOCK' file=3D'libvirt-domain' string=
=3D'task_clock'>
<info><![CDATA[Macro for typed parameter name that represents task_clo=
ck perf event which can be used to measure the count of task clock time by ap=
plications running on the platform. It corresponds to the "perf.task_clock" f=
ield in the *Stats APIs.]]></info>
</macro>
- <macro name=3D'VIR_SECRET_EVENT_CALLBACK' file=3D'libvirt-secret'>
+ <macro name=3D'VIR_SECRET_EVENT_CALLBACK' file=3D'libvirt-secret' params=
=3D'cb' raw=3D'((virConnectSecretEventGenericCallback)(cb))'>
<info><![CDATA[Used to cast the event specific callback into the gener=
ic one for use for virConnectSecretEventRegisterAny()]]></info>
</macro>
- <macro name=3D'VIR_SECURITY_DOI_BUFLEN' file=3D'libvirt-host'>
+ <macro name=3D'VIR_SECURITY_DOI_BUFLEN' file=3D'libvirt-host' raw=3D'(25=
6 + 1)'>
<info><![CDATA[Macro providing the maximum length of the virSecurityMo=
del doi string.]]></info>
</macro>
- <macro name=3D'VIR_SECURITY_LABEL_BUFLEN' file=3D'libvirt-host'>
+ <macro name=3D'VIR_SECURITY_LABEL_BUFLEN' file=3D'libvirt-host' raw=3D'(=
4096 + 1)'>
<info><![CDATA[Macro providing the maximum length of the virSecurityLa=
bel label string. Note that this value is based on that used by Labeled NFS.]=
]></info>
</macro>
- <macro name=3D'VIR_SECURITY_MODEL_BUFLEN' file=3D'libvirt-host'>
+ <macro name=3D'VIR_SECURITY_MODEL_BUFLEN' file=3D'libvirt-host' raw=3D'(=
256 + 1)'>
<info><![CDATA[Macro providing the maximum length of the virSecurityMo=
del model string.]]></info>
</macro>
- <macro name=3D'VIR_STORAGE_POOL_EVENT_CALLBACK' file=3D'libvirt-storage'>
+ <macro name=3D'VIR_STORAGE_POOL_EVENT_CALLBACK' file=3D'libvirt-storage'=
params=3D'cb' raw=3D'((virConnectStoragePoolEventGenericCallback)(cb))'>
<info><![CDATA[Used to cast the event specific callback into the gener=
ic one for use for virConnectStoragePoolEventRegisterAny()]]></info>
</macro>
- <macro name=3D'VIR_TYPED_PARAM_FIELD_LENGTH' file=3D'libvirt-common'>
+ <macro name=3D'VIR_TYPED_PARAM_FIELD_LENGTH' file=3D'libvirt-common' raw=
=3D'80'>
<info><![CDATA[Macro providing the field length of virTypedParameter n=
ame]]></info>
</macro>
- <macro name=3D'VIR_UNUSE_CPU' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_UNUSE_CPU' file=3D'libvirt-domain' params=3D'cpumap,c=
pu' raw=3D'((cpumap)[(cpu) / 8] &=3D ~(1 << ((cpu) % 8)))'>
<info><![CDATA[This macro is to be used in conjunction with virDomainP=
inVcpu() API. It resets the bit (CPU not usable) of the related cpu in cpumap=
.]]></info>
<arg name=3D'cpumap' info=3D'pointer to a bit map of real CPUs (in 8-b=
it bytes) (IN/OUT)'/>
<arg name=3D'cpu' info=3D'the physical CPU number'/>
</macro>
- <macro name=3D'VIR_USE_CPU' file=3D'libvirt-domain'>
+ <macro name=3D'VIR_USE_CPU' file=3D'libvirt-domain' params=3D'cpumap,cpu=
' raw=3D'((cpumap)[(cpu) / 8] |=3D (1 << ((cpu) % 8)))'>
<info><![CDATA[This macro is to be used in conjunction with virDomainP=
inVcpu() API. It sets the bit (CPU usable) of the related cpu in cpumap.]]></=
info>
<arg name=3D'cpumap' info=3D'pointer to a bit map of real CPUs (in 8-b=
it bytes) (IN/OUT)'/>
<arg name=3D'cpu' info=3D'the physical CPU number'/>
</macro>
- <macro name=3D'VIR_UUID_BUFLEN' file=3D'libvirt-host'>
+ <macro name=3D'VIR_UUID_BUFLEN' file=3D'libvirt-host' raw=3D'(16)'>
<info><![CDATA[This macro provides the length of the buffer required f=
or virDomainGetUUID()]]></info>
</macro>
- <macro name=3D'VIR_UUID_STRING_BUFLEN' file=3D'libvirt-host'>
+ <macro name=3D'VIR_UUID_STRING_BUFLEN' file=3D'libvirt-host' raw=3D'(36+=
1)'>
<info><![CDATA[This macro provides the length of the buffer required f=
or virDomainGetUUIDString()]]></info>
</macro>
- <macro name=3D'_virBlkioParameter' file=3D'libvirt-domain'>
+ <macro name=3D'_virBlkioParameter' file=3D'libvirt-domain' raw=3D'_virTy=
pedParameter'>
</macro>
- <macro name=3D'_virMemoryParameter' file=3D'libvirt-domain'>
+ <macro name=3D'_virMemoryParameter' file=3D'libvirt-domain' raw=3D'_virT=
ypedParameter'>
</macro>
- <macro name=3D'_virSchedParameter' file=3D'libvirt-domain'>
+ <macro name=3D'_virSchedParameter' file=3D'libvirt-domain' raw=3D'_virTy=
pedParameter'>
</macro>
<enum name=3D'VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES' file=3D'libvirt-=
host' value=3D'1' value_hex=3D'0x1' value_bitshift=3D'0' type=3D'virConnectBa=
selineCPUFlags' info=3D'show all features'/>
<enum name=3D'VIR_CONNECT_BASELINE_CPU_MIGRATABLE' file=3D'libvirt-host'=
value=3D'2' value_hex=3D'0x2' value_bitshift=3D'1' type=3D'virConnectBaselin=
eCPUFlags' info=3D'filter out non-migratable features'/>
Daniel P. Berrang=C3=A9 (4):
scripts: use UTF-8 for API XML files
scripts: fix tokenizing of enum parameters in API builder
scripts: emit enum parameters in API build description
scripts: emit raw enum value in API build description
scripts/apibuild.py | 47 ++++++++++++++++++++++++++++++++++++++-------
1 file changed, 40 insertions(+), 7 deletions(-)
--=20
2.26.2
4 years, 6 months
[PATCH] testCompareXMLToArgvValidateSchema: Construct @vm from scratch
by Michal Privoznik
Currently, the @vm is passed in as an argument and
testCompareXMLToArgvCreateArgs() is called over it which means
under the hood qemuProcessPrepareDomain() is called. But at the
point where ValidateSchema() is called, the domain object is
already 'prepared', i.e. all device aliases are assigned and so
on. But our code is not prepared to 'prepare' a domain twice - it
simply overwrites all the pointers leading to a memory leak.
Fortunately, this is only the problem of this test.
Resolve this by constructing the domain object from scratch.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tests/qemuxml2argvtest.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 4f613e8f1a..3103cac884 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -482,16 +482,17 @@ testCompareXMLToArgvCreateArgs(virQEMUDriverPtr drv,
static int
testCompareXMLToArgvValidateSchema(virQEMUDriverPtr drv,
- virDomainObjPtr vm,
const char *migrateURI,
struct testQemuInfo *info,
unsigned int flags)
{
VIR_AUTOSTRINGLIST args = NULL;
+ g_autoptr(virDomainObj) vm = NULL;
size_t nargs = 0;
size_t i;
g_autoptr(virHashTable) schema = NULL;
g_autoptr(virCommand) cmd = NULL;
+ unsigned int parseFlags = info->parseFlags;
if (info->schemafile)
schema = testQEMUSchemaLoad(info->schemafile);
@@ -504,6 +505,15 @@ testCompareXMLToArgvValidateSchema(virQEMUDriverPtr drv,
if (!schema)
return 0;
+ if (!(vm = virDomainObjNew(driver.xmlopt)))
+ return -1;
+
+ parseFlags |= VIR_DOMAIN_DEF_PARSE_INACTIVE;
+ if (!(vm->def = virDomainDefParseFile(info->infile,
+ driver.xmlopt,
+ NULL, parseFlags)))
+ return -1;
+
if (!(cmd = testCompareXMLToArgvCreateArgs(drv, vm, migrateURI, info, flags,
true)))
return -1;
@@ -651,7 +661,7 @@ testCompareXMLToArgv(const void *data)
goto cleanup;
}
- if (testCompareXMLToArgvValidateSchema(&driver, vm, migrateURI, info, flags) < 0)
+ if (testCompareXMLToArgvValidateSchema(&driver, migrateURI, info, flags) < 0)
goto cleanup;
if (!(actualargv = virCommandToString(cmd, false)))
--
2.26.2
4 years, 6 months
[libvirt PATCH 0/6] src: make virObject inherit from GObject
by Daniel P. Berrangé
This series attempts to make the conversion from virObject to
GObject less dangerous, by making the former inherit from the
latter.
The way we setup inheritance with virObject means we have to
make some moderately gross games with registering virClass
instances as GObjectClass instances. Empirically it seems to
work and pass the basic TCK test suite.
Ultimately virObject should be deleted entirely, so the gross
bits shouldn't live too long.
Daniel P. Berrangé (6):
qemu: stop checking virObjectUnref return value
src: make virObjectUnref return void
test: allocate numa cells separately from driver
src: don't include ref count in debug messages / probes
src: don't use VIR_FREE on an object allocation
src: make virObject inherit from GObject
src/admin/libvirt-admin.c | 7 +-
src/datatypes.c | 26 ++++
src/datatypes.h | 6 +
src/interface/interface_backend_netcf.c | 7 +-
src/libvirt-domain-checkpoint.c | 3 +-
src/libvirt-domain-snapshot.c | 3 +-
src/libvirt-domain.c | 2 +-
src/libvirt-host.c | 2 +-
src/libvirt-interface.c | 2 +-
src/libvirt-network.c | 6 +-
src/libvirt-nodedev.c | 2 +-
src/libvirt-nwfilter.c | 6 +-
src/libvirt-secret.c | 3 +-
src/libvirt-storage.c | 4 +-
src/libvirt-stream.c | 3 +-
src/libvirt.c | 4 +-
src/libvirt_qemu_probes.d | 8 +-
src/qemu/qemu_domain.c | 4 +-
src/qemu/qemu_monitor.c | 21 +++-
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_process.c | 30 ++---
src/rpc/virnettlscontext.c | 5 +-
src/test/test_driver.c | 15 ++-
src/util/virfdstream.c | 6 +-
src/util/virobject.c | 150 ++++++++++++++----------
src/util/virobject.h | 27 ++---
src/vbox/vbox_common.c | 10 +-
27 files changed, 210 insertions(+), 155 deletions(-)
--
2.24.1
4 years, 6 months
[PATCH v2 00/13] audio: deprecate -soundhw
by Gerd Hoffmann
v2:
- use g_assert_not_reached() for stubs.
- add deprecation notice.
Gerd Hoffmann (13):
stubs: add isa_create_simple
stubs: add pci_create_simple
audio: add deprecated_register_soundhw
audio: deprecate -soundhw ac97
audio: deprecate -soundhw es1370
audio: deprecate -soundhw adlib
audio: deprecate -soundhw cs4231a
audio: deprecate -soundhw gus
audio: deprecate -soundhw sb16
audio: deprecate -soundhw hda
audio: deprecate -soundhw pcspk
audio: add soundhw deprecation notice
[RFC] audio: try use onboard audiodev for pcspk
include/hw/audio/soundhw.h | 2 ++
hw/audio/ac97.c | 9 ++-------
hw/audio/adlib.c | 8 +-------
hw/audio/cs4231a.c | 8 +-------
hw/audio/es1370.c | 9 ++-------
hw/audio/gus.c | 8 +-------
hw/audio/intel-hda.c | 3 +++
hw/audio/pcspk.c | 27 ++++++++++++++++++++++++---
hw/audio/sb16.c | 9 ++-------
hw/audio/soundhw.c | 24 +++++++++++++++++++++++-
qdev-monitor.c | 2 ++
stubs/isa-bus.c | 7 +++++++
stubs/pci-bus.c | 7 +++++++
docs/system/deprecated.rst | 9 +++++++++
stubs/Makefile.objs | 2 ++
15 files changed, 88 insertions(+), 46 deletions(-)
create mode 100644 stubs/isa-bus.c
create mode 100644 stubs/pci-bus.c
--
2.18.4
4 years, 6 months
[PATCH v4 00/10] Introducing TPM Proxy device support for PPC64
by Daniel Henrique Barboza
changes in v4:
- patch 1: added missing <code> tags
- comma-escaped the path string in qemu_command.c (patch 8)
- moved validations not-XML-parsing related from domain_conf.c to qemu_validate.c
- new patches 3 and 4: cleanups
- patch 5 (former 3): changed the approach to use a def->tpms array instead of
def->tpmproxy pointer
- new patch 6: qemu_validate changes to not clog patch 5 with changes
- added Jano's and Stefan's r-b when applicable
v3 link: https://www.redhat.com/archives/libvir-list/2020-May/msg00642.html
v2 link: https://www.redhat.com/archives/libvir-list/2020-May/msg00604.html
v1 link: https://www.redhat.com/archives/libvir-list/2020-May/msg00604.html
Daniel Henrique Barboza (10):
docs: documentation and schema for the new TPM Proxy model
qemu: Extend QEMU capabilities with 'spapr-tpm-proxy'
qemu_extdevice.c: remove unneeded 'ret' variable
qemu_tpm, security, tests: change 'switch' clauses for 'if'
conf, qemu, security, tests: introducing 'def->tpms' array
qemu_validate.c: add validation for TPM Proxy model
tests: add XML schema tests for the TPM Proxy device
qemu: build command line for the TPM Proxy device
tests/qemuxml2argvtest.c: add TPM Proxy command line tests
docs/news.xml: update for the new TPM Proxy device
docs/formatdomain.html.in | 19 ++++-
docs/news.xml | 17 +++++
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_audit.c | 4 +-
src/conf/domain_conf.c | 72 +++++++++++++-----
src/conf/domain_conf.h | 6 +-
src/qemu/qemu_alias.c | 9 ++-
src/qemu/qemu_capabilities.c | 4 +
src/qemu/qemu_capabilities.h | 3 +
src/qemu/qemu_cgroup.c | 10 ++-
src/qemu/qemu_command.c | 59 +++++++++++---
src/qemu/qemu_domain.c | 31 +++++---
src/qemu/qemu_domain_address.c | 11 ++-
src/qemu/qemu_extdevice.c | 24 +++---
src/qemu/qemu_tpm.c | 76 +++++++++----------
src/qemu/qemu_validate.c | 19 +++++
src/security/security_dac.c | 8 +-
src/security/security_selinux.c | 44 +++++------
src/security/virt-aa-helper.c | 14 ++--
.../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
tests/qemuxml2argvdata/ppc64-tpm-double.xml | 34 +++++++++
.../ppc64-tpmproxy-double.xml | 38 ++++++++++
.../ppc64-tpmproxy-single.ppc64-latest.args | 34 +++++++++
.../ppc64-tpmproxy-single.xml | 33 ++++++++
.../ppc64-tpmproxy-with-tpm.ppc64-latest.args | 37 +++++++++
.../ppc64-tpmproxy-with-tpm.xml | 36 +++++++++
tests/qemuxml2argvtest.c | 33 +++++---
.../ppc64-tpmproxy-single.ppc64-latest.xml | 42 ++++++++++
.../ppc64-tpmproxy-with-tpm.ppc64-latest.xml | 46 +++++++++++
tests/qemuxml2xmltest.c | 2 +
31 files changed, 616 insertions(+), 152 deletions(-)
create mode 100644 tests/qemuxml2argvdata/ppc64-tpm-double.xml
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-double.xml
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-single.ppc64-latest.args
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-single.xml
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-with-tpm.ppc64-latest.args
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy-with-tpm.xml
create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy-single.ppc64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy-with-tpm.ppc64-latest.xml
--
2.26.2
4 years, 6 months
[PATCH v2 0/2] introduces qemu_job_wait_time option
by MIKI Nobuhiro
This series introduces qemu_job_wait_time option to configuration file.
MIKI Nobuhiro (2):
conf: Add qemu_job_wait_time option
news: add support for qemu_job_wait_time configuration
docs/news.xml | 9 +++++++++
src/qemu/libvirtd_qemu.aug | 1 +
src/qemu/qemu.conf | 3 +++
src/qemu/qemu_conf.c | 3 +++
src/qemu/qemu_conf.h | 2 ++
src/qemu/qemu_domain.c | 7 ++-----
src/qemu/test_libvirtd_qemu.aug.in | 1 +
7 files changed, 21 insertions(+), 5 deletions(-)
--
1.8.3.1
4 years, 6 months
[PATCH v3 00/21] PCI Multifunction hotplug/unplug support
by Daniel Henrique Barboza
This is the v3 of the same support sent to the mailing list
a few months ago. No major changes were made. Refer to the
v2 cover letter for a general view of the design used
across the patches.
Changes in v3:
- rebase to master at d265171b5784
- minor typo fixes
link to v2: https://www.redhat.com/archives/libvir-list/2020-January/msg01377.html
link to v1: https://www.redhat.com/archives/libvir-list/2020-January/msg01377.html
Daniel Henrique Barboza (4):
utils: PCI multifunction detection helpers
qemu_hotplug.c: tune unplugTimeout for multifunction detach
qemu_hotplug: do not hotplug/hotunplug 'unassigned' hostdevs
qemu_hotplug.c: use enhanced multifunction unplug if available
Shivaprasad G Bhat (17):
qemu: address: Separate the slots into multiple aggregates
virhostdev: Introduce virHostdevPCIDevicesBelongToSameSlot
qemu: address: Enable auto addressing multifunction cards
conf: qemu: validate multifunction hostdevice domain configs
conf: Add helper to get active functions of a slot of domain
qemu: hostdev: Move the hostdev preparation to a separate function
qemu: hotplug: Move the detach of PCI device to the beginning of live
hotplug
qemu: hotplug: move assignment outside qemuDomainAttachHostPCIDevice
Introduce virDomainDeviceDefParseXMLMany
Introduce qemuDomainDeviceParseXMLMany
qemu: refactor qemuDomain[Attach|Detach]DeviceConfig
qemu: refactor qemuDomain[Attach|Detach]DeviceLive
qemu: hotplug: Queue and wait for multiple devices
domain: addr: Introduce virDomainPCIAddressEnsureMultifunctionAddress
qemu: hotplug: Implement multifunction device hotplug
qemu: hotplug: Prevent updates to multifunction device
qemu: hotplug: Implement multifunction device unplug
src/conf/device_conf.h | 7 +
src/conf/domain_addr.c | 130 +++++-
src/conf/domain_addr.h | 43 +-
src/conf/domain_conf.c | 224 ++++++++-
src/conf/domain_conf.h | 38 ++
src/hypervisor/virhostdev.c | 29 ++
src/hypervisor/virhostdev.h | 2 +
src/libvirt_private.syms | 10 +
src/qemu/qemu_domain.c | 75 +++
src/qemu/qemu_domain.h | 21 +-
src/qemu/qemu_domain_address.c | 311 ++++++++++++-
src/qemu/qemu_domain_address.h | 17 +
src/qemu/qemu_driver.c | 243 +++++++---
src/qemu/qemu_hotplug.c | 431 +++++++++++++++---
src/qemu/qemu_hotplug.h | 14 +
src/qemu/qemu_validate.c | 56 +++
src/qemu/qemu_validate.h | 1 +
src/util/virpci.c | 17 +
src/util/virpci.h | 4 +
tests/qemuhotplugtest.c | 66 ++-
...emuhotplug-multifunction-hostdev-pci-2.xml | 14 +
...plug-multifunction-hostdev-pci-partial.xml | 27 ++
.../qemuhotplug-multifunction-hostdev-pci.xml | 26 ++
...live+multifunction-hostdev-pci-partial.xml | 82 ++++
...ug-base-live+multifunction-hostdev-pci.xml | 82 ++++
...-base-live+multifunction-hostdev-pci-2.xml | 59 +++
...es-base-live+multifunction-hostdev-pci.xml | 69 +++
.../hostdev-pci-address-unassigned.args | 9 +-
.../hostdev-pci-multifunction.args | 18 +-
.../hostdev-pci-multifunction.xml | 8 +-
.../hostdev-pci-no-primary-function.xml | 23 +
.../hostdev-pci-validate.args | 30 ++
.../qemuxml2argvdata/hostdev-pci-validate.xml | 29 ++
.../qemuxml2argvdata/pseries-hostdevs-1.args | 5 +-
.../qemuxml2argvdata/pseries-hostdevs-3.args | 5 +-
tests/qemuxml2argvtest.c | 14 +-
.../hostdev-pci-address-unassigned.xml | 8 +-
.../hostdev-pci-multifunction.xml | 24 +-
.../qemuxml2xmloutdata/pseries-hostdevs-1.xml | 4 +-
.../qemuxml2xmloutdata/pseries-hostdevs-3.xml | 4 +-
tests/virpcitestdata/0005-90-01.1.config | Bin 256 -> 256 bytes
tests/virpcitestdata/0005-90-01.2.config | Bin 256 -> 256 bytes
tests/virpcitestdata/0005-90-01.3.config | Bin 0 -> 256 bytes
43 files changed, 2022 insertions(+), 257 deletions(-)
create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-multifunction-hostdev-pci-2.xml
create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-multifunction-hostdev-pci-partial.xml
create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-multifunction-hostdev-pci.xml
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+multifunction-hostdev-pci-partial.xml
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+multifunction-hostdev-pci.xml
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+multifunction-hostdev-pci-2.xml
create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-pseries-base-live+multifunction-hostdev-pci.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-pci-no-primary-function.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-pci-validate.args
create mode 100644 tests/qemuxml2argvdata/hostdev-pci-validate.xml
create mode 100644 tests/virpcitestdata/0005-90-01.3.config
--
2.26.2
4 years, 6 months
Exposing -fw_cfg?
by Michal Privoznik
List,
QEMU has capability to inject various blobs into firmware that configure
how firmware configures itself. However, it can be also used to
passthrough a specific file into the guest. For instance:
-fw_cfg value=name=opt/com.example,file=/tmp/ign
will make the /tmp/ign file accessible in the guest under:
/sys/firmware/qemu_fw_cfg/by_name/opt/com.example/raw
the @name is important here as it defines what knob is touched. For
instance, /opt/ovmf tweaks OVMF, /bootorder changes the boot order, and
so on. But, if the @name is in /opt/reverse.fully.qualified.domain form
than this is a blob that is exposed into the guest and does not affect
ACPI, SMBIOS, ... And IMO this is what makes the interface horrible.
While I definitely would not expose the FW configuration knobs (we
already provide a way to configure things like bootroder), the file
passthrough is actually used. So far I have found out that RHCOS uses it
to give the guest so called ignition file (for the sake of argument we
can assume it's like a kickstart that the OS reads on the first boot and
configures itself up), but there are some other potential users (for
users it looks intriguing, it's a simple API that makes a file show up
at well defined location inside the guest).
Therefore I vouch for exposing the file passthorugh (and definitely do
not mention firmware in the element or docs in any way, to not encourage
users to use FW tweaking mode). However, before I design something, I'd
like to hear your opinion.
Michal
4 years, 6 months
