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
59 matches
Mail list logo
