11:56 a.m.
This patch series introduces the support for new s390x 'loadparm'
feature. The 'loadparm' can be used to select the boot entry to
boot from, for a boot device.
Here is a link to the QEMU patches:
https://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg00192.html
ChangeLog
---------
v1 -> v2:
- Rebased the patch series on the latest master, commit
2f69dd3 virfiletest: include linux/falloc.h
Thanks
Farhan Ali
Farhan Ali (3):
conf : Add loadparm boot option for a boot device
qemu : Add loadparm to qemu command line string
tests : Testcases for loadparm
docs/formatdomain.html.in | 8 ++-
docs/news.xml | 9 +++
docs/schemas/domaincommon.rng | 7 +++
src/conf/device_conf.h | 1 +
src/conf/domain_conf.c | 69 +++++++++++++++++++++-
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 37 ++++++++++++
...-machine-loadparm-multiple-disks-nets-s390.args | 28 +++++++++
...v-machine-loadparm-multiple-disks-nets-s390.xml | 43 ++++++++++++++
.../qemuxml2argv-machine-loadparm-net-s390.args | 20 +++++++
.../qemuxml2argv-machine-loadparm-net-s390.xml | 26 ++++++++
...xml2argv-machine-loadparm-s390-char-invalid.xml | 26 ++++++++
...uxml2argv-machine-loadparm-s390-len-invalid.xml | 26 ++++++++
.../qemuxml2argv-machine-loadparm-s390.args | 20 +++++++
.../qemuxml2argv-machine-loadparm-s390.xml | 26 ++++++++
tests/qemuxml2argvtest.c | 19 ++++++
17 files changed, 364 insertions(+), 4 deletions(-)
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.args
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.xml
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-char-invalid.xml
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-len-invalid.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.xml
--
1.9.1
11:56 a.m.
New subject: [libvirt] [PATCH v2 1/3] conf : Add loadparm boot option for a boot device
Update the per device boot schema to add an optional loadparm parameter.
Extend the virDomainDeviceInfo to support loadparm option.
Modify the appropriate functions to parse loadparm from boot device xml.
Signed-off-by: Farhan Ali <alifm(a)linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
---
docs/formatdomain.html.in | 8 +++--
docs/news.xml | 9 ++++++
docs/schemas/domaincommon.rng | 7 +++++
src/conf/device_conf.h | 1 +
src/conf/domain_conf.c | 69 +++++++++++++++++++++++++++++++++++++++++--
5 files changed, 90 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 3135db4..016febe 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -3022,8 +3022,12 @@
<dt><code>boot</code></dt>
<dd>Specifies that the disk is bootable. The <code>order</code>
attribute determines the order in which devices will be tried during
- boot sequence. The per-device <code>boot</code> elements cannot be
- used together with general boot elements in
+ boot sequence. On S390 architecture only the first boot device is used.
+ The optional <code>loadparm</code> attribute can be used to select a
+ boot entry for S390 architecture.
+ <span class="since">Since 3.4.0</span>
+ The per-device <code>boot</code> elements cannot be used together
+ with general boot elements in
<a href="#elementsOSBIOS">BIOS bootloader</a> section.
<span class="since">Since 0.8.8</span>
</dd>
diff --git a/docs/news.xml b/docs/news.xml
index 52915ee..bc6b070 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -37,6 +37,15 @@
<section title="New features">
<change>
<summary>
+ qemu: Add support for loadparm for a boot device
+ </summary>
+ <description>
+ Add an optional boot parameter 'loadparm' for a boot device.
+ On S390 architecture the loadparm is used to select a boot entry.
+ </description>
+ </change>
+ <change>
+ <summary>
Improved streams to efficiently transfer sparseness
</summary>
<description>
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index f88e84a..c885aec 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -5026,6 +5026,13 @@
<attribute name="order">
<ref name="positiveInteger"/>
</attribute>
+ <optional>
+ <attribute name="loadparm">
+ <data type="string">
+ <param name="pattern">[a-zA-Z0-9.\s]{1,8}</param>
+ </data>
+ </attribute>
+ </optional>
<empty/>
</element>
</define>
diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
index a20de85..48782be 100644
--- a/src/conf/device_conf.h
+++ b/src/conf/device_conf.h
@@ -167,6 +167,7 @@ struct _virDomainDeviceInfo {
* assignment, never saved and never reported.
*/
int pciConnectFlags; /* enum virDomainPCIConnectFlags */
+ char *loadparm;
};
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 8c62673..dbf6108 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -3520,6 +3520,7 @@ void virDomainDeviceInfoClear(virDomainDeviceInfoPtr info)
memset(&info->addr, 0, sizeof(info->addr));
info->type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE;
VIR_FREE(info->romfile);
+ VIR_FREE(info->loadparm);
}
@@ -5199,6 +5200,48 @@ virDomainDefValidate(virDomainDefPtr def,
return 0;
}
+/**
+ * virDomainDeviceLoadparmIsValid
+ * @loadparm : The string to validate
+ *
+ * The valid set of values for loadparm are [a-zA-Z0-9.]
+ * and blank spaces.
+ * The maximum allowed length is 8 characters.
+ * An empty string is considered invalid
+ */
+static bool
+virDomainDeviceLoadparmIsValid(const char *loadparm)
+{
+ size_t i;
+
+ if (virStringIsEmpty(loadparm)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("loadparm cannot be an empty string"));
+ return false;
+ }
+
+ if (strlen(loadparm) > 8) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("loadparm '%s' exceeds 8 characters"),
loadparm);
+ return false;
+ }
+
+ for (i = 0; i < strlen(loadparm); i++) {
+ uint8_t c = loadparm[i];
+
+ if (('A' <= c && c <= 'Z') || ('0' <= c
&& c <= '9') ||
+ (c == '.') || (c == ' ')) {
+ continue;
+ } else {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("invalid loadparm char '%c', expecting
chars"
+ " in set of [a-zA-Z0-9.] and blank spaces"), c);
+ return false;
+ }
+ }
+
+ return true;
+}
/* Generate a string representation of a device address
* @info address Device address to stringify
@@ -5208,9 +5251,14 @@ virDomainDeviceInfoFormat(virBufferPtr buf,
virDomainDeviceInfoPtr info,
unsigned int flags)
{
- if ((flags & VIR_DOMAIN_DEF_FORMAT_ALLOW_BOOT) && info->bootIndex)
- virBufferAsprintf(buf, "<boot order='%u'/>\n",
info->bootIndex);
+ if ((flags & VIR_DOMAIN_DEF_FORMAT_ALLOW_BOOT) && info->bootIndex) {
+ virBufferAsprintf(buf, "<boot order='%u'",
info->bootIndex);
+ if (info->loadparm)
+ virBufferAsprintf(buf, " loadparm='%s'",
info->loadparm);
+
+ virBufferAddLit(buf, "/>\n");
+ }
if (info->alias &&
!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) {
virBufferAsprintf(buf, "<alias name='%s'/>\n",
info->alias);
@@ -5636,6 +5684,7 @@ virDomainDeviceBootParseXML(xmlNodePtr node,
virHashTablePtr bootHash)
{
char *order;
+ char *loadparm;
int ret = -1;
if (!(order = virXMLPropString(node, "order"))) {
@@ -5664,10 +5713,26 @@ virDomainDeviceBootParseXML(xmlNodePtr node,
goto cleanup;
}
+ loadparm = virXMLPropString(node, "loadparm");
+ if (loadparm) {
+ if (virStringToUpper(&info->loadparm, loadparm) != 1) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Failed to convert loadparm '%s' to upper
case"),
+ loadparm);
+ goto cleanup;
+ }
+
+ if (!virDomainDeviceLoadparmIsValid(info->loadparm)) {
+ VIR_FREE(info->loadparm);
+ goto cleanup;
+ }
+ }
+
ret = 0;
cleanup:
VIR_FREE(order);
+ VIR_FREE(loadparm);
return ret;
}
--
1.9.1
1:40 p.m.
New subject: [libvirt] [PATCH v2 1/3] conf : Add loadparm boot option for a boot device
On 05/19/2017 06:56 PM, Farhan Ali wrote:
Update the per device boot schema to add an optional loadparm
parameter.
Extend the virDomainDeviceInfo to support loadparm option.
Modify the appropriate functions to parse loadparm from boot device xml.
Signed-off-by: Farhan Ali <alifm(a)linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
---
docs/formatdomain.html.in | 8 +++--
docs/news.xml | 9 ++++++
docs/schemas/domaincommon.rng | 7 +++++
src/conf/device_conf.h | 1 +
src/conf/domain_conf.c | 69 +++++++++++++++++++++++++++++++++++++++++--
5 files changed, 90 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 3135db4..016febe 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -3022,8 +3022,12 @@
<dt><code>boot</code></dt>
<dd>Specifies that the disk is bootable. The <code>order</code>
attribute determines the order in which devices will be tried during
- boot sequence. The per-device <code>boot</code> elements cannot be
- used together with general boot elements in
+ boot sequence. On S390 architecture only the first boot device is used.
+ The optional <code>loadparm</code> attribute can be used to select
a
+ boot entry for S390 architecture.
+ <span class="since">Since 3.4.0</span>
+ The per-device <code>boot</code> elements cannot be used together
+ with general boot elements in
<a href="#elementsOSBIOS">BIOS bootloader</a> section.
<span class="since">Since 0.8.8</span>
</dd>
diff --git a/docs/news.xml b/docs/news.xml
index 52915ee..bc6b070 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -37,6 +37,15 @@
<section title="New features">
<change>
<summary>
+ qemu: Add support for loadparm for a boot device
+ </summary>
+ <description>
+ Add an optional boot parameter 'loadparm' for a boot device.
+ On S390 architecture the loadparm is used to select a boot entry.
I would change that description and refer more to the architectural meaning
(8 byte parameter that can be queried by the guest via sclp and diag 308).
The linux use case of the selecting a boot entry withing that disk can be mentioned
but it certainly is not the only use case.
1:51 p.m.
New subject: [libvirt] [PATCH v2 1/3] conf : Add loadparm boot option for a boot device
On 05/19/2017 02:40 PM, Christian Borntraeger wrote:
On 05/19/2017 06:56 PM, Farhan Ali wrote:
> Update the per device boot schema to add an optional loadparm parameter.
> Extend the virDomainDeviceInfo to support loadparm option.
> Modify the appropriate functions to parse loadparm from boot device xml.
>
> Signed-off-by: Farhan Ali <alifm(a)linux.vnet.ibm.com>
> Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com>
> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com>
> Reviewed-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
> ---
> docs/formatdomain.html.in | 8 +++--
> docs/news.xml | 9 ++++++
> docs/schemas/domaincommon.rng | 7 +++++
> src/conf/device_conf.h | 1 +
> src/conf/domain_conf.c | 69 +++++++++++++++++++++++++++++++++++++++++--
> 5 files changed, 90 insertions(+), 4 deletions(-)
>
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 3135db4..016febe 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -3022,8 +3022,12 @@
> <dt><code>boot</code></dt>
> <dd>Specifies that the disk is bootable. The
<code>order</code>
> attribute determines the order in which devices will be tried during
> - boot sequence. The per-device <code>boot</code> elements cannot
be
> - used together with general boot elements in
> + boot sequence. On S390 architecture only the first boot device is used.
> + The optional <code>loadparm</code> attribute can be used to
select a
> + boot entry for S390 architecture.
> + <span class="since">Since 3.4.0</span>
> + The per-device <code>boot</code> elements cannot be used
together
> + with general boot elements in
> <a href="#elementsOSBIOS">BIOS bootloader</a>
section.
> <span class="since">Since 0.8.8</span>
> </dd>
> diff --git a/docs/news.xml b/docs/news.xml
> index 52915ee..bc6b070 100644
> --- a/docs/news.xml
> +++ b/docs/news.xml
> @@ -37,6 +37,15 @@
> <section title="New features">
> <change>
> <summary>
> + qemu: Add support for loadparm for a boot device
> + </summary>
> + <description>
> + Add an optional boot parameter 'loadparm' for a boot device.
> + On S390 architecture the loadparm is used to select a boot entry.
I would change that description and refer more to the architectural meaning
(8 byte parameter that can be queried by the guest via sclp and diag 308).
The linux use case of the selecting a boot entry withing that disk can be mentioned
but it certainly is not the only use case.
Sure, will update the description.
11:56 a.m.
New subject: [libvirt] [PATCH v2 2/3] qemu : Add loadparm to qemu command line string
Introduce a new QEMU capability for loadparm and if the capability is
supported by QEMU then append the loadparm value to "-machine" string
of qemu command line.
Signed-off-by: Farhan Ali <alifm(a)linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 37 +++++++++++++++++++++++++++++++++++++
3 files changed, 40 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 546dfd7..e3bd445 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -371,6 +371,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
"kernel-irqchip.split",
"intel-iommu.intremap",
"intel-iommu.caching-mode",
+ "loadparm",
);
@@ -3144,6 +3145,7 @@ static struct virQEMUCapsCommandLineProps virQEMUCapsCommandLine[] =
{
{ "drive", "throttling.group", QEMU_CAPS_DRIVE_IOTUNE_GROUP },
{ "spice", "rendernode", QEMU_CAPS_SPICE_RENDERNODE },
{ "machine", "kernel_irqchip", QEMU_CAPS_MACHINE_KERNEL_IRQCHIP
},
+ { "machine", "loadparm", QEMU_CAPS_LOADPARM },
};
static int
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index aa99fda..a18c61c 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -409,6 +409,7 @@ typedef enum {
QEMU_CAPS_MACHINE_KERNEL_IRQCHIP_SPLIT, /* -machine kernel_irqchip=split */
QEMU_CAPS_INTEL_IOMMU_INTREMAP, /* intel-iommu.intremap */
QEMU_CAPS_INTEL_IOMMU_CACHING_MODE, /* intel-iommu.caching-mode */
+ QEMU_CAPS_LOADPARM, /* -machine loadparm */
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 4c1a266..6ae07dc 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -7237,6 +7237,41 @@ qemuAppendKeyWrapMachineParms(virBuffer *buf, virQEMUCapsPtr
qemuCaps,
return true;
}
+static void
+qemuAppendLoadparmMachineParm(virBuffer *buf,
+ const virDomainDef *def,
+ virQEMUCapsPtr qemuCaps)
+{
+ size_t i = 0;
+
+ if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_BOOTINDEX) ||
+ !virQEMUCapsGet(qemuCaps, QEMU_CAPS_LOADPARM))
+ return;
+
+ for (i = 0; i < def->ndisks; i++) {
+ virDomainDiskDefPtr disk = def->disks[i];
+
+ if (disk->info.bootIndex == 1) {
+ if (disk->info.loadparm)
+ virBufferAsprintf(buf, ",loadparm=%s",
disk->info.loadparm);
+
+ return;
+ }
+ }
+
+ /* Network boot device*/
+ for (i = 0; i < def->nnets; i++) {
+ virDomainNetDefPtr net = def->nets[i];
+
+ if (net->info.bootIndex == 1) {
+ if (net->info.loadparm)
+ virBufferAsprintf(buf, ",loadparm=%s", net->info.loadparm);
+
+ return;
+ }
+ }
+}
+
static int
qemuBuildNameCommandLine(virCommandPtr cmd,
virQEMUDriverConfigPtr cfg,
@@ -7326,6 +7361,8 @@ qemuBuildMachineCommandLine(virCommandPtr cmd,
virCommandAddArg(cmd, "-machine");
virBufferAdd(&buf, def->os.machine, -1);
+ qemuAppendLoadparmMachineParm(&buf, def, qemuCaps);
+
if (def->virtType == VIR_DOMAIN_VIRT_QEMU)
virBufferAddLit(&buf, ",accel=tcg");
else if (def->virtType == VIR_DOMAIN_VIRT_KVM)
--
1.9.1
11:56 a.m.
New subject: [libvirt] [PATCH v2 3/3] tests : Testcases for loadparm
Add testcases for loadparm
Signed-off-by: Farhan Ali <alifm(a)linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
---
...-machine-loadparm-multiple-disks-nets-s390.args | 28 ++++++++++++++
...v-machine-loadparm-multiple-disks-nets-s390.xml | 43 ++++++++++++++++++++++
.../qemuxml2argv-machine-loadparm-net-s390.args | 20 ++++++++++
.../qemuxml2argv-machine-loadparm-net-s390.xml | 26 +++++++++++++
...xml2argv-machine-loadparm-s390-char-invalid.xml | 26 +++++++++++++
...uxml2argv-machine-loadparm-s390-len-invalid.xml | 26 +++++++++++++
.../qemuxml2argv-machine-loadparm-s390.args | 20 ++++++++++
.../qemuxml2argv-machine-loadparm-s390.xml | 26 +++++++++++++
tests/qemuxml2argvtest.c | 19 ++++++++++
9 files changed, 234 insertions(+)
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.args
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.xml
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-char-invalid.xml
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-len-invalid.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.xml
diff --git
a/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.args
b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.args
new file mode 100644
index 0000000..c9e9061
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.args
@@ -0,0 +1,28 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-s390x \
+-name QEMUGuest1 \
+-S \
+-machine s390-ccw-virtio,loadparm=SYSTEM1,accel=tcg \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-QEMUGuest1/monitor.sock,server,nowait \
+-drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk0 \
+-device virtio-blk-ccw,devno=fe.0.0002,drive=drive-virtio-disk0,\
+id=virtio-disk0,bootindex=1 \
+-drive file=/dev/HostVG/QEMUGuest2,format=raw,if=none,id=drive-virtio-disk1 \
+-device virtio-blk-ccw,devno=fe.0.0003,drive=drive-virtio-disk1,\
+id=virtio-disk1,bootindex=3 \
+-device virtio-net-ccw,vlan=0,id=net0,mac=00:11:22:33:44:54,devno=fe.0.0000,\
+bootindex=2 \
+-net user,vlan=0,name=hostnet0 \
+-device virtio-net-ccw,vlan=1,id=net1,mac=00:11:22:33:42:36,devno=fe.0.0004 \
+-net user,vlan=1,name=hostnet1 \
+-device virtio-balloon-ccw,id=balloon0,devno=fe.0.0001
diff --git
a/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.xml
b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.xml
new file mode 100644
index 0000000..df442e9
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.xml
@@ -0,0 +1,43 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219136</memory>
+ <currentMemory>219136</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='s390x' machine='s390-ccw-virtio'>hvm</type>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-s390x</emulator>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='virtio'/>
+ <boot order='1' loadparm='system1'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x2'/>
+ </disk>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest2'/>
+ <target dev='hdb' bus='virtio'/>
+ <boot order='3' loadparm='3'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x3'/>
+ </disk>
+ <interface type='user'>
+ <mac address='00:11:22:33:44:54'/>
+ <model type='virtio'/>
+ <boot order='2' loadparm='2.lp'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0'/>
+ </interface>
+ <interface type='user'>
+ <mac address='00:11:22:33:42:36'/>
+ <model type='virtio'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x4'/>
+ </interface>
+ <memballoon model='virtio'>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x1'/>
+ </memballoon>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.args
b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.args
new file mode 100644
index 0000000..4ca2865
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.args
@@ -0,0 +1,20 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-s390x \
+-name QEMUGuest1 \
+-S \
+-machine s390-ccw-virtio,loadparm=2,accel=tcg \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-QEMUGuest1/monitor.sock,server,nowait \
+-device virtio-net-ccw,vlan=0,id=net0,mac=00:11:22:33:44:54,devno=fe.0.0000,\
+bootindex=1 \
+-net user,vlan=0,name=hostnet0 \
+-device virtio-balloon-ccw,id=balloon0,devno=fe.0.0001
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.xml
b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.xml
new file mode 100644
index 0000000..ca682af
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.xml
@@ -0,0 +1,26 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219136</memory>
+ <currentMemory>219136</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='s390x' machine='s390-ccw-virtio'>hvm</type>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-s390x</emulator>
+ <interface type='user'>
+ <mac address='00:11:22:33:44:54'/>
+ <model type='virtio'/>
+ <boot order='1' loadparm='2'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0'/>
+ </interface>
+ <memballoon model='virtio'>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x1'/>
+ </memballoon>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-char-invalid.xml
b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-char-invalid.xml
new file mode 100644
index 0000000..5cca5f9
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-char-invalid.xml
@@ -0,0 +1,26 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219136</memory>
+ <currentMemory>219136</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='s390x' machine='s390-ccw-virtio'>hvm</type>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-s390x</emulator>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='virtio'/>
+ <boot order='1' loadparm='sys1?'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0'/>
+ </disk>
+ <memballoon model='virtio'>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x1'/>
+ </memballoon>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-len-invalid.xml
b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-len-invalid.xml
new file mode 100644
index 0000000..ddc4baa
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-len-invalid.xml
@@ -0,0 +1,26 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219136</memory>
+ <currentMemory>219136</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='s390x' machine='s390-ccw-virtio'>hvm</type>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-s390x</emulator>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='virtio'/>
+ <boot order='1' loadparm='loadparm1'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0'/>
+ </disk>
+ <memballoon model='virtio'>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x1'/>
+ </memballoon>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.args
b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.args
new file mode 100644
index 0000000..34855e9
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.args
@@ -0,0 +1,20 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-s390x \
+-name QEMUGuest1 \
+-S \
+-machine s390-ccw-virtio,loadparm=2,accel=tcg \
+-m 214 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-nographic \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-QEMUGuest1/monitor.sock,server,nowait \
+-drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-virtio-disk0 \
+-device virtio-blk-ccw,devno=fe.0.0000,drive=drive-virtio-disk0,\
+id=virtio-disk0,bootindex=1 \
+-device virtio-balloon-ccw,id=balloon0,devno=fe.0.0001
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.xml
b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.xml
new file mode 100644
index 0000000..96db020
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.xml
@@ -0,0 +1,26 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219136</memory>
+ <currentMemory>219136</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='s390x' machine='s390-ccw-virtio'>hvm</type>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-s390x</emulator>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='virtio'/>
+ <boot order='1' loadparm='2'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0'/>
+ </disk>
+ <memballoon model='virtio'>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x1'/>
+ </memballoon>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 4269598..690cd55 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -2460,6 +2460,25 @@ mymain(void)
QEMU_CAPS_MACHINE_OPT, QEMU_CAPS_VIRTIO_SCSI,
QEMU_CAPS_VIRTIO_CCW, QEMU_CAPS_VIRTIO_S390);
+ DO_TEST("machine-loadparm-s390", QEMU_CAPS_MACHINE_OPT,
+ QEMU_CAPS_VIRTIO_CCW, QEMU_CAPS_VIRTIO_S390,
+ QEMU_CAPS_BOOTINDEX, QEMU_CAPS_LOADPARM);
+ DO_TEST("machine-loadparm-net-s390", QEMU_CAPS_MACHINE_OPT,
+ QEMU_CAPS_VIRTIO_CCW, QEMU_CAPS_VIRTIO_S390,
+ QEMU_CAPS_BOOTINDEX, QEMU_CAPS_LOADPARM);
+ DO_TEST("machine-loadparm-multiple-disks-nets-s390",
+ QEMU_CAPS_MACHINE_OPT, QEMU_CAPS_VIRTIO_CCW,
+ QEMU_CAPS_VIRTIO_S390, QEMU_CAPS_BOOTINDEX,
+ QEMU_CAPS_LOADPARM);
+ DO_TEST_PARSE_ERROR("machine-loadparm-s390-char-invalid",
+ QEMU_CAPS_MACHINE_OPT, QEMU_CAPS_VIRTIO_CCW,
+ QEMU_CAPS_VIRTIO_S390, QEMU_CAPS_BOOTINDEX,
+ QEMU_CAPS_LOADPARM);
+ DO_TEST_PARSE_ERROR("machine-loadparm-s390-len-invalid",
+ QEMU_CAPS_MACHINE_OPT, QEMU_CAPS_VIRTIO_CCW,
+ QEMU_CAPS_VIRTIO_S390, QEMU_CAPS_BOOTINDEX,
+ QEMU_CAPS_LOADPARM);
+
DO_TEST("qemu-ns-domain-ns0", NONE);
DO_TEST("qemu-ns-domain-commandline", NONE);
DO_TEST("qemu-ns-domain-commandline-ns0", NONE);
--
1.9.1
12:01 p.m.
Please ignore v1 tag on the email. It's actually v2, sorry about that
On 05/19/2017 12:56 PM, Farhan Ali wrote:
This patch series introduces the support for new s390x
'loadparm'
feature. The 'loadparm' can be used to select the boot entry to
boot from, for a boot device.
Here is a link to the QEMU patches:
https://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg00192.html
ChangeLog
---------
v1 -> v2:
- Rebased the patch series on the latest master, commit
2f69dd3 virfiletest: include linux/falloc.h
Thanks
Farhan Ali
Farhan Ali (3):
conf : Add loadparm boot option for a boot device
qemu : Add loadparm to qemu command line string
tests : Testcases for loadparm
docs/formatdomain.html.in | 8 ++-
docs/news.xml | 9 +++
docs/schemas/domaincommon.rng | 7 +++
src/conf/device_conf.h | 1 +
src/conf/domain_conf.c | 69 +++++++++++++++++++++-
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 37 ++++++++++++
...-machine-loadparm-multiple-disks-nets-s390.args | 28 +++++++++
...v-machine-loadparm-multiple-disks-nets-s390.xml | 43 ++++++++++++++
.../qemuxml2argv-machine-loadparm-net-s390.args | 20 +++++++
.../qemuxml2argv-machine-loadparm-net-s390.xml | 26 ++++++++
...xml2argv-machine-loadparm-s390-char-invalid.xml | 26 ++++++++
...uxml2argv-machine-loadparm-s390-len-invalid.xml | 26 ++++++++
.../qemuxml2argv-machine-loadparm-s390.args | 20 +++++++
.../qemuxml2argv-machine-loadparm-s390.xml | 26 ++++++++
tests/qemuxml2argvtest.c | 19 ++++++
17 files changed, 364 insertions(+), 4 deletions(-)
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.args
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-multiple-disks-nets-s390.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-net-s390.xml
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-char-invalid.xml
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390-len-invalid.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-loadparm-s390.xml
12:34 p.m.
On Fri, May 19, 2017 at 12:56:44PM -0400, Farhan Ali wrote:
This patch series introduces the support for new s390x
'loadparm'
feature. The 'loadparm' can be used to select the boot entry to
boot from, for a boot device.
Why do we need / want any of this when we already have bootindex=NN
support. Inventing a S390-only way to select the boot device order
is pretty horrible IMHO
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
1:15 p.m.
On 05/19/2017 01:34 PM, Daniel P. Berrange wrote:
On Fri, May 19, 2017 at 12:56:44PM -0400, Farhan Ali wrote:
> This patch series introduces the support for new s390x 'loadparm'
> feature. The 'loadparm' can be used to select the boot entry to
> boot from, for a boot device.
Why do we need / want any of this when we already have bootindex=NN
support. Inventing a S390-only way to select the boot device order
is pretty horrible IMHO
Regards,
Daniel
Hi Daniel,
The bootindex is used to select a boot device, the loadparm used to
select a boot entry within that boot device.
Loadparm is not a way to select boot device order. Bootindex is still
used to select the boot device order.
Hope this clears it up.
Thanks
Farhan
1:22 p.m.
On 05/19/2017 07:34 PM, Daniel P. Berrange wrote:
On Fri, May 19, 2017 at 12:56:44PM -0400, Farhan Ali wrote:
> This patch series introduces the support for new s390x 'loadparm'
> feature. The 'loadparm' can be used to select the boot entry to
> boot from, for a boot device.
Why do we need / want any of this when we already have bootindex=NN
support. Inventing a S390-only way to select the boot device order
is pretty horrible IMHO
loadparm is an 8 byte character parameter for s390 systems and available
on all other hypervisors (LPAR/z/VM). It is really a part of the architecture.
Linux does use it to select a boot entry within a disk, but for other guest
operating systems it is used to pass along other kind of parameters for the
ipl process,
e.g. check
https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zsyspro...
to see what z/OS uses.
Not having it was really a missing part of the s390 support.
2744
days inactive
2744
days old
9 comments
3 participants
participants (3)
-
Christian Borntraeger -
Daniel P. Berrange -
Farhan Ali