is already a large patch series, it is better
to leave
it alone for now unless we find a compelling reason to change it
immediately.
Regards,
Jared Rossi
Reviewed-by: Jared Rossi
On 7/9/25 4:34 AM, Thomas Huth wrote:
From: Thomas Huth
Show a simple boot menu for pxelinux.cfg, too, if the user requested it.
Signed-off-by: Thomas Huth
---
pc-bios/s390-ccw/netmain.c | 26 ++
1 file changed, 26 insertions(+)
diff
Reviewed-by: Jared Rossi
On 7/9/25 4:34 AM, Thomas Huth wrote:
From: Thomas Huth
We are going to reuse this function for selecting an entry from
the pxelinux.cfg menu, so rename this function with a "menu_"
prefix and make it available globally.
Signed-off-by: Thomas Huth
---
Reviewed-by: Jared Rossi
On 7/9/25 4:34 AM, Thomas Huth wrote:
From: Thomas Huth
Check the various ways of booting a kernel via pxelinux.cfg file,
e.g. by specifying the config file name via the MAC address or the
UUID of the guest. Also check whether we can successfully load an
alternate
Reviewed-by: Jared Rossi
On 7/9/25 4:34 AM, Thomas Huth wrote:
From: Thomas Huth
Since we're linking the network booting code into the main firmware
binary nowadays, we can support the "loadparm" parameter now quite
easily for pxelinux.cfg config files that contain multiple e
Reviewed-by: Jared Rossi
On 7/9/25 4:34 AM, Thomas Huth wrote:
From: Thomas Huth
We're going to support a menu for the pxelinux.cfg code, and to be able
to reuse some functionality from menu.c, we should align the maximum
amount of possible entries with the MAX_BOOT_ENTRIES constant th
On 7/8/25 8:56 AM, Thomas Huth wrote:
From: Thomas Huth
Since we're linking the network booting code into the main firmware
binary nowadays, we can support the "loadparm" parameter now quite
easily for pxelinux.cfg config files that contain multiple entries.
Signed-off-by: Thomas Huth
---
On 6/20/25 11:45 AM, Zhuoying Cai wrote:
On 6/6/25 10:00 AM, Daniel P. Berrangé wrote:
On Wed, Jun 04, 2025 at 05:56:29PM -0400, Zhuoying Cai wrote:
Add boot-certificates as a parameter of s390-ccw-virtio machine type option.
The `boot-certificates=/path/dir:/path/file` parameter is impleme
On 6/24/25 2:27 AM, Thomas Huth wrote:
On 23/06/2025 22.12, jro...@linux.ibm.com wrote:
From: Jared Rossi
Replace a recently introduced legacy API call with the preferred API
call.
fixes: 0927875 (hw/s390x: Build an IPLB for each boot device)
Signed-off-by: Jared Rossi
---
hw/s390x
On 6/23/25 12:00 PM, Matthew Rosato wrote:
To improve review coverage, assign additional people as reviewers for
multiple s390 sections.
Signed-off-by: Matthew Rosato
Acked-by: Jared Rossi
---
MAINTAINERS | 12
1 file changed, 12 insertions(+)
diff --git a/MAINTAINERS b
Hi Philippe,
I update this to use the proper API call.
Regards,
Jared Rossi
On 6/16/25 6:04 AM, Philippe Mathieu-Daudé wrote:
Hi,
On 23/10/24 15:17, Thomas Huth wrote:
From: Jared Rossi
Build an IPLB for any device with a bootindex (up to a maximum of 8
devices).
The IPLB chain is
On 4/16/25 6:11 PM, Collin Walling wrote:
On 4/8/25 11:55 AM, Zhuoying Cai wrote:
If secure boot in audit mode or True Secure IPL mode is enabled without
specifying a boot device, the boot process will terminate with an error.
Signed-off-by: Zhuoying Cai
---
hw/s390x/ipl.c | 10 ++
On 4/8/25 11:55 AM, Zhuoying Cai wrote:
Enable secure IPL in audit mode, which performs signature verification,
but any error does not terminate the boot process. Only warnings will be
logged to the console instead.
Add a comp_len variable to store the length of a segment in
zipl_load_segment
On 4/11/25 10:46 AM, Thomas Huth wrote:
On 08/04/2025 17.55, Zhuoying Cai wrote:
The IPL Information Report Block (IIRB) immediately follows the IPL
Parameter Block (IPLB).
The IPLB struct is allocated 4KB in memory, and iplb->len indicates
the amount of memory currently used by the IPLB.
T
Thanks Thomas,
Looks good to me. I've tested and verified that the problem is fixed.
Tested-by: Jared Rossi
On 1/16/25 6:58 AM, Thomas Huth wrote:
The boot can currently fail after the s390-ccw bios used a network
device since we do not properly shut down the device afterwards, so
Reviewed-by: Jared Rossi
On 1/16/25 6:58 AM, Thomas Huth wrote:
The code in net_init_ip() currently bails out early if "rc" is less
than 0, so the if-statements that check for negative "rc" codes to
print out some specific error messages with regards to the TFTP server
are
Reviewed-by: Jared Rossi
On 1/16/25 6:58 AM, Thomas Huth wrote:
When we are trying to boot from virtio-net devices, the
s390-ccw bios currently leaves the virtio-net device enabled
after using it. That means that the receiving virt queues will
continue to happily write incoming network packets
Reviewed-by: Jared Rossi
On 1/16/25 6:58 AM, Thomas Huth wrote:
To be able to properly silence a virtio device after using it,
we need a global function to reset the device.
Signed-off-by: Thomas Huth
---
pc-bios/s390-ccw/virtio.h | 1 +
pc-bios/s390-ccw/virtio.c | 7 ++-
2 files
));
+lp_str = g_malloc0(strlen(value) + 1);
if (!qdev_prop_sanitize_s390x_loadparm(lp_str, value, errp)) {
g_free(lp_str);
return;
Reviewed-by Jared Rossi
On 11/18/24 12:12 PM, Christian Borntraeger wrote:
Am 18.11.24 um 16:53 schrieb Jared Rossi:
Loadparm set with boot index works properly and I confirmed the
getter/setter are working as well.
So this is a Tested-by: then?
Yes.
Tested-by Jared Rossi
Reviewed-by Jared Rossi
On 11/18
Loadparm set with boot index works properly and I confirmed the
getter/setter are working as well.
On 11/18/24 10:29 AM, Jared Rossi wrote:
Looks OK to me.
Reviewed-by Jared Rossi
On 11/15/24 9:12 AM, Thomas Huth wrote:
While adding the new flexible boot order feature on s390x recently,
we
Looks OK to me.
Reviewed-by Jared Rossi
On 11/15/24 9:12 AM, Thomas Huth wrote:
While adding the new flexible boot order feature on s390x recently,
we missed to add the "loadparm" property to the scsi-hd and scsi-cd
devices. This property is required on s390x to pass the informat
With documentation of per-device loadparm behavior during device probing
similar to suggestion here:
https://lore.kernel.org/qemu-devel/20241115002742.3576842-1-jro...@linux.ibm.com/
Reviewed-by: Jared Rossi
On 11/14/24 7:29 AM, Thomas Huth wrote:
While adding the new flexible boot order
On 11/14/24 12:47 PM, Thomas Huth wrote:
On 14/11/2024 16.55, Jared Rossi wrote:
On 11/14/24 7:29 AM, Thomas Huth wrote:
While adding the new flexible boot order feature on s390x recently,
we missed to add the "loadparm" property to the scsi-hd and scsi-cd
devices. This p
On 11/14/24 7:39 AM, Thomas Huth wrote:
On 13/11/2024 15.49, Jared Rossi wrote:
...
Hi Thomas,
Thanks for putting this fix together. As we previously discussed, I
do agree
that my naive implementation of the “loadparm” property at the top-level
CcwDevice was not satisfactory, and
On 11/14/24 7:29 AM, Thomas Huth wrote:
While adding the new flexible boot order feature on s390x recently,
we missed to add the "loadparm" property to the scsi-hd and scsi-cd
devices. This property is required on s390x to pass the information
to the boot loader about which kernel should be st
*),
#endif
+DEFINE_PROP_CCW_LOADPARM("loadparm", CcwDevice, loadparm),
DEFINE_PROP_END_OF_LIST(),
};
Thomas,
Please disregard my previous response to this patch.
While I do think per-device loadparm will need further revision, I
believe it
will be in addition to these changes, not in place of them.
Thanks again for putting this together!
Reviewed-by: Jared Rossi
d in this patch if you want to
include it
now, but I expect per-device loadparm will require further revision
regardless.
Please let me know how you would like to proceed. Thanks again,
Jared Rossi
-net.c
@@ -51,6 +51,8 @@ int virtio_net_init(void *mac_addr)
void *buf;
int i;
+rx_last_idx = 0;
+
vdev->guest_features[0] = VIRTIO_NET_F_MAC_BIT;
virtio_setup_ccw(vdev);
Thanks Thomas!
Reviewed-by: Jared Rossi
On 11/6/24 6:10 AM, Thomas Huth wrote:
On 05/11/2024 17.42, Jared Rossi wrote:
Hi Thomas, Sebastian,
It looks like this is simply caused by the "is_cdrom" value only ever
being set
to true. I think it is a one-line fix that just makes sure to
initialize the
value to false ea
On 10/31/24 4:45 AM, Thomas Huth wrote:
On 20/10/2024 03.29, jro...@linux.ibm.com wrote:
From: Jared Rossi
Add a loadparm property to the VirtioCcwDevice object so that different
loadparms can be defined on a per-device basis for CCW boot devices.
The machine/global loadparm is still
tch (iplb.pbt) {
I tested it with the two scenarios you mention and with the existing qtests,
and it seems to work correctly now.
Thanks for finding the mistake,
Jared Rossi
On 10/31/24 11:50 AM, Thomas Huth wrote:
On 20/10/2024 03.29, jro...@linux.ibm.com wrote:
From: Jared Rossi
changes v4 -
On 10/23/24 12:51 AM, Thomas Huth wrote:
On 22/10/2024 22.12, Jared Rossi wrote:
On 10/22/24 1:36 PM, Thomas Huth wrote:
On 20/10/2024 03.29, jro...@linux.ibm.com wrote:
From: Jared Rossi
We are already using the libc from SLOF for the s390-netboot.img, and
this libc implementation is
On 10/22/24 1:36 PM, Thomas Huth wrote:
On 20/10/2024 03.29, jro...@linux.ibm.com wrote:
From: Jared Rossi
We are already using the libc from SLOF for the s390-netboot.img, and
this libc implementation is way more complete and accurate than the
simple implementation that we currently use
On 10/22/24 9:13 AM, Thomas Huth wrote:
On 20/10/2024 03.29, jro...@linux.ibm.com wrote:
From: Jared Rossi
Build an IPLB for any device with a bootindex (up to a maximum of 8
devices).
The IPLB chain is placed immediately before the BIOS in memory.
Because this
is not a fixed address
On 10/9/24 5:46 AM, Thomas Huth wrote:
On 08/10/2024 03.15, jro...@linux.ibm.com wrote:
From: Jared Rossi
Remove panic-on-error from IPL ISO El Torito specific functions so
that error
recovery may be possible in the future.
Functions that would previously panic now provide a return code
On 10/9/24 7:35 AM, Thomas Huth wrote:
On 08/10/2024 03.15, jro...@linux.ibm.com wrote:
From: Jared Rossi
Remove panic-on-error from Netboot specific functions so that error
recovery
may be possible in the future.
Functions that would previously panic now provide a return code.
Signed
On 10/9/24 8:48 AM, Thomas Huth wrote:
On 08/10/2024 03.15, jro...@linux.ibm.com wrote:
From: Jared Rossi
Add two new qtests to verify that a valid IPL device can successfully
boot after
failed IPL attempts from one or more invalid devices.
cdrom-test/as-fallback-device: Defines the
On 10/9/24 7:18 AM, Thomas Huth wrote:
On 08/10/2024 03.15, jro...@linux.ibm.com wrote:
+ if (!vs_io_assert(virtio_run(vdev, VR_REQUEST, cmd) == 0, title)) {
+ puts(title);
Should there be a "return" with a non-0 value here? ...
+ }
+
+ return 0;
}
/* SCSI protocol i
On 10/9/24 6:53 AM, Thomas Huth wrote:
On 08/10/2024 03.15, jro...@linux.ibm.com wrote:
[snip...]
load_eckd_segments() returns a value of type block_number_t which is
an unsigned type, so returning a negative error value will likely not
work as expected...
...
@@ -317,21 +352,28 @@ stat
On 10/7/24 9:15 PM, jro...@linux.ibm.com wrote:
[snip...]
switch (vdev->senseid.cu_model) {
case VIRTIO_ID_NET:
puts("Network boot device detected");
@@ -271,11 +275,9 @@ static void ipl_boot_device(void)
dasd_ipl(blk_schid, cutype);
break;
case
On 9/30/24 9:14 AM, Thomas Huth wrote:
On 27/09/2024 02.50, jro...@linux.ibm.com wrote:
From: Jared Rossi
...
Thanks, this looks already much better than the "jump back to start"
stuff in v1 !
One thing I noticed while testing your patches: Booting from ISO
images seems to
On 9/30/24 9:08 AM, Thomas Huth wrote:
On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
From: Jared Rossi
Allow attempts to boot from multiple IPL devices. If the first device
fails to
IPL, select the pre-built IPLB for the next device in the boot order
and attempt
to IPL from it
On 9/30/24 8:32 AM, Thomas Huth wrote:
On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
From: Jared Rossi
-/*
- * No boot device has been specified, so we have to scan through the
- * channels to find one.
- */
-static void probe_boot_device(void)
-{
- int ssid, sch_no, ret
On 9/30/24 8:15 AM, Thomas Huth wrote:
On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
From: Jared Rossi ...
@@ -661,35 +629,33 @@ IplParameterBlock *s390_ipl_get_iplb(void)
return &ipl->iplb;
}
-void s390_ipl_reset_request(CPUState *cs, enum s390_reset reset_type)
+stat
On 9/30/24 7:59 AM, Thomas Huth wrote:
On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
From: Jared Rossi
...
@@ -484,8 +499,8 @@ static bool s390_gen_initial_iplb(S390IPLState *ipl)
lp = S390_CCW_MACHINE(qdev_get_machine())->loadp
On 9/30/24 6:42 AM, Thomas Huth wrote:
On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
...
+
+struct IPLBlockPVComp {
+ uint64_t tweak_pref;
+ uint64_t addr;
+ uint64_t size;
+} QEMU_PACKED;
Could you please replace the two spaces in front of QEMU_PACKED with
just one place? (als
On 9/30/24 6:11 AM, Thomas Huth wrote:
On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
From: Jared Rossi
...
unsigned long virtio_load_direct(unsigned long rec_list1, unsigned
long rec_list2,
@@ -73,13 +73,13 @@ unsigned long virtio_load_direct(unsigned long
rec_list1, unsigned long
On 9/30/24 5:39 AM, Thomas Huth wrote:
On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
From: Jared Rossi
Remove panic-on-error from Netboot specific functions so that error
recovery
may be possible in the future.
Functions that would previously panic now provide a return code.
Signed
closer look at my test coverage, because the mismatched
error
conditions should always cause incorrect IPL behavior here, which seems to
indicate this code path was not properly exercised...
Jared Rossi
On 9/27/24 11:29 AM, Thomas Huth wrote:
On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
From: Jared Rossi
Remove panic-on-error from ECKD block device IPL specific functions
so that
error recovery may be possible in the future.
Functions that would previously panic now provide a return
On 9/27/24 11:02 AM, Thomas Huth wrote:
On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
From: Jared Rossi
Remove panic-on-error from IPL ISO El Torito specific functions so
that error
recovery may be possible in the future.
Functions that would previously panic now provide a return
r patches in my series. I will get all that
put together and submit a V2 after QEMU 9.1 is squared away.
Thanks again,
Jared Rossi
proceed. Let me
know if there is anything I can do to help with test/review of the changes from
your side.
Thanks,
Jared Rossi
On 6/21/24 4:24 AM, Thomas Huth wrote:
We originally built a separate binary for the netboot code since it
was considered as experimental and we could not be sure that the
want to try to maintain some
amount of consistency until we do a total conversion, or if you are OK
with a mix of sclp_print() and printf() throughout in the meantime.
Regards,
Jared Rossi
.
I'm not sure if that is the only place though. Otherwise it looks good
to me. I can work on a v2 of the boot order support that assumes the
network bootloader is integrated. Regards, Jared Rossi
Thomas Huth (7):
pc-bios/s390-ccw: Remove duplicated LDFLAGS
hw/s390x/ipl: Provide mor
On 6/7/24 1:57 AM, Thomas Huth wrote:
On 05/06/2024 16.48, Jared Rossi wrote:
diff --git a/pc-bios/s390-ccw/s390-ccw.h b/pc-bios/s390-ccw/s390-ccw.h
index c977a52b50..de3d1f0d5a 100644
--- a/pc-bios/s390-ccw/s390-ccw.h
+++ b/pc-bios/s390-ccw/s390-ccw.h
@@ -43,6 +43,7 @@ typedef unsigned
On 6/7/24 2:19 AM, Thomas Huth wrote:
On 06/06/2024 21.22, Jared Rossi wrote:
On 6/5/24 4:02 AM, Thomas Huth wrote:
On 29/05/2024 17.43, jro...@linux.ibm.com wrote:
From: Jared Rossi
This patch set primarily adds support for the specification of
multiple boot
devices, allowing for the
On 6/5/24 4:02 AM, Thomas Huth wrote:
On 29/05/2024 17.43, jro...@linux.ibm.com wrote:
From: Jared Rossi
This patch set primarily adds support for the specification of
multiple boot
devices, allowing for the guest to automatically use an alternative
device on
a failed boot without
On 6/4/24 2:26 PM, Thomas Huth wrote:
On 29/05/2024 17.43, jro...@linux.ibm.com wrote:
From: Jared Rossi
Write a chain of IPLBs into memory for future use.
The IPLB chain is placed immediately before the BIOS in memory at the
highest
unused page boundary providing sufficient space to fit
ssible I've overlooked something, but as
far as I can tell a jump is necessary in that particular case at least.
Netboot could perhaps be handled as a special case where the jump back
is permitted whereas other device types return, but I don't think that
actually solves the main issue.
uch,
s390_ipl_set_loadparm() is changed to a void function and the check is
removed.
Regards,
Jared Rossi
Sounds good. Thanks Thomas.
Regards,
Jared Rossi
On 3/6/23 7:12 AM, Thomas Huth wrote:
On 21/02/2023 18.45, jro...@linux.ibm.com wrote:
From: Jared Rossi
Check for a List Directed IPL Boot Record, which would supersede the
CCW type
entries. If the record is valid, proceed to use the new
On 2/20/23 10:45 AM, Thomas Huth wrote:
On 20/02/2023 16.13, Jared Rossi wrote:
Hi,
Pinging this patch since v2.26.0 of s390-tools adds ECKD DASD
list-directed IPL.
This patch set allows QEMU to utilize that new boot pointer format.
Any feedback about what needs to be changed for acceptance
Hi,
Pinging this patch since v2.26.0 of s390-tools adds ECKD DASD list-directed IPL.
This patch set allows QEMU to utilize that new boot pointer format.
Any feedback about what needs to be changed for acceptance is much appreciated.
Thanks,
Jared Rossi
On 1/30/23 4:24 PM, Jared Rossi wrote
I've exercised the error paths and it appears to all work correctly.
On 7/19/21 11:09 AM, Jared Rossi wrote:
I will take a look and see if I can exercise the error paths.
Regards,
Jared Rossi
On 7/19/21 10:16 AM, Matthew Rosato wrote:
On 7/5/21 12:39 PM, Cornelia Huck wrote:
This
I will take a look and see if I can exercise the error paths.
Regards,
Jared Rossi
On 7/19/21 10:16 AM, Matthew Rosato wrote:
On 7/5/21 12:39 PM, Cornelia Huck wrote:
This is a followup on the first version (which I had sent out in May,
and which kind of fell through the cracks.) While the
On 2020-05-14 11:20, Cornelia Huck wrote:
On Tue, 12 May 2020 14:15:35 -0400
Jared Rossi wrote:
Remove the explicit prefetch check when using vfio-ccw devices.
This check does not trigger in practice as all Linux channel programs
are intended to use prefetch.
It is no longer required to
Remove the explicit prefetch check when using vfio-ccw devices.
This check does not trigger in practice as all Linux channel programs
are intended to use prefetch.
It is no longer required to force the PFCH flag when using vfio-ccw
devices.
Signed-off-by: Jared Rossi
---
hw/vfio/ccw.c | 13
...@linux.ibm.com/
It is no longer required to force the PFCH flag, but the option is
still supported.
Jared Rossi (1):
vfio-ccw: allow non-prefetch ORBs
hw/vfio/ccw.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
--
2.17.0
On 2020-04-20 08:29, Cornelia Huck wrote:
On Mon, 20 Apr 2020 14:26:17 +0200
Cornelia Huck wrote:
On Fri, 17 Apr 2020 14:38:38 -0400
Jared Rossi wrote:
> Remove the explicit prefetch check when using vfio-ccw devices.
> This check is not needed as all Linux channel programs are in
Remove the explicit prefetch check when using vfio-ccw devices.
This check is not needed as all Linux channel programs are intended
to use prefetch and will be executed in the same way regardless.
Jared Rossi (1):
vfio-ccw: Enable transparent CCW IPL from DASD
hw/vfio/ccw.c | 13
Remove the explicit prefetch check when using vfio-ccw devices.
This check is not needed as all Linux channel programs are intended
to use prefetch and will be executed in the same way regardless.
Signed-off-by: Jared Rossi
---
hw/vfio/ccw.c | 13 +++--
1 file changed, 3 insertions
73 matches
Mail list logo
