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 questio
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 all
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 ch
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 re
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 co
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
