On 1/22/24 5:49 AM, Thomas Huth wrote:
> On 22/01/2024 11.31, Michael Tokarev wrote:
>> 22.01.2024 13:18, Michael Tokarev :
>> ..
>>> Is it this a material for -stable, or there's no need to bother?
>>
>> Actually it's been Cc'd to qemu-stable@ already, I haven't noticed.
>> Still there's a
On 22/01/2024 11.31, Michael Tokarev wrote:
22.01.2024 13:18, Michael Tokarev :
..
Is it this a material for -stable, or there's no need to bother?
Actually it's been Cc'd to qemu-stable@ already, I haven't noticed.
Still there's a question which branches should get which patches.
...
So
22.01.2024 13:18, Michael Tokarev :
..
Is it this a material for -stable, or there's no need to bother?
Actually it's been Cc'd to qemu-stable@ already, I haven't noticed.
Still there's a question which branches should get which patches.
(changes 1 and 2 applies to 7.2 (while 2 fixes later
18.01.2024 21:51, Matthew Rosato :
Commit ef1535901a0 (re-)introduced an issue where passthrough ISM devices
on s390x would enter an error state after reboot. This was previously fixed
by 03451953c79e, using device reset callbacks, however the change in
ef1535901a0 effectively triggers a cold
On 1/18/24 19:51, Matthew Rosato wrote:
Commit ef1535901a0 (re-)introduced an issue where passthrough ISM devices
on s390x would enter an error state after reboot. This was previously fixed
by 03451953c79e, using device reset callbacks, however the change in
ef1535901a0 effectively triggers a
Commit ef1535901a0 (re-)introduced an issue where passthrough ISM devices
on s390x would enter an error state after reboot. This was previously fixed
by 03451953c79e, using device reset callbacks, however the change in
ef1535901a0 effectively triggers a cold reset of the pci bus before the
device
