| 9ee8f7e4 | 02-Sep-2022 |
Matthew Rosato <mjrosato@linux.ibm.com> |
s390x/pci: reflect proper maxstbl for groups of interpreted devices
The maximum supported store block length might be different depending
on whether the instruction is interpretively executed (firmw
s390x/pci: reflect proper maxstbl for groups of interpreted devices
The maximum supported store block length might be different depending
on whether the instruction is interpretively executed (firmware-reported
maximum) or handled via userspace intercept (host kernel API maximum).
Choose the best available value during group creation.
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Message-Id: <20220902172737.170349-8-mjrosato@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
| 30dcf4f7 | 02-Sep-2022 |
Matthew Rosato <mjrosato@linux.ibm.com> |
s390x/pci: let intercept devices have separate PCI groups
Let's use the reserved pool of simulated PCI groups to allow intercept
devices to have separate groups from interpreted devices as some grou
s390x/pci: let intercept devices have separate PCI groups
Let's use the reserved pool of simulated PCI groups to allow intercept
devices to have separate groups from interpreted devices as some group
values may be different. If we run out of simulated PCI groups, subsequent
intercept devices just get the default group.
Furthermore, if we encounter any PCI groups from hostdevs that are marked
as simulated, let's just assign them to the default group to avoid
conflicts between host simulated groups and our own simulated groups.
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Message-Id: <20220902172737.170349-7-mjrosato@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
| 15d0e794 | 02-Sep-2022 |
Matthew Rosato <mjrosato@linux.ibm.com> |
s390x/pci: don't fence interpreted devices without MSI-X
Lack of MSI-X support is not an issue for interpreted passthrough
devices, so let's let these in. This will allow, for example, ISM
devices
s390x/pci: don't fence interpreted devices without MSI-X
Lack of MSI-X support is not an issue for interpreted passthrough
devices, so let's let these in. This will allow, for example, ISM
devices to be passed through -- but only when interpretation is
available and being used.
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Message-Id: <20220902172737.170349-5-mjrosato@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
| dd1d5fd9 | 02-Sep-2022 |
Matthew Rosato <mjrosato@linux.ibm.com> |
s390x/pci: enable for load/store interpretation
If the ZPCI_OP ioctl reports that is is available and usable, then the
underlying KVM host will enable load/store intepretation for any guest
device w
s390x/pci: enable for load/store interpretation
If the ZPCI_OP ioctl reports that is is available and usable, then the
underlying KVM host will enable load/store intepretation for any guest
device without a SHM bit in the guest function handle. For a device that
will be using interpretation support, ensure the guest function handle
matches the host function handle; this value is re-checked every time the
guest issues a SET PCI FN to enable the guest device as it is the only
opportunity to reflect function handle changes.
By default, unless interpret=off is specified, interpretation support will
always be assumed and exploited if the necessary ioctl and features are
available on the host kernel. When these are unavailable, we will silently
revert to the interception model; this allows existing guest configurations
to work unmodified on hosts with and without zPCI interpretation support,
allowing QEMU to choose the best support model available.
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20220902172737.170349-4-mjrosato@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
| 1d41de5f | 27-Jul-2022 |
Christian Borntraeger <borntraeger@linux.ibm.com> |
s390x/cpumodel: add stfl197 processor-activity-instrumentation extension 1
Add stfle 197 (processor-activity-instrumentation extension 1) to the
gen16 default model and fence it off for 7.1 and olde
s390x/cpumodel: add stfl197 processor-activity-instrumentation extension 1
Add stfle 197 (processor-activity-instrumentation extension 1) to the
gen16 default model and fence it off for 7.1 and older.
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <20220727135120.12784-1-borntraeger@linux.ibm.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
| 9e43a830 | 09-Jun-2022 |
Paolo Bonzini <pbonzini@redhat.com> |
virtio: stop ioeventfd on reset
All calls to virtio_bus_reset are preceded by virtio_bus_stop_ioeventfd,
move the call in virtio_bus_reset: that makes sense and clarifies
that the vdc->reset functio
virtio: stop ioeventfd on reset
All calls to virtio_bus_reset are preceded by virtio_bus_stop_ioeventfd,
move the call in virtio_bus_reset: that makes sense and clarifies
that the vdc->reset function is called with ioeventfd already stopped.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| 7a523d96 | 28-Mar-2022 |
Paolo Bonzini <pbonzini@redhat.com> |
virtio-ccw: move vhost_ccw_scsi to a separate file
Remove unecessary use of #ifdef CONFIG_VHOST_SCSI, instead just use a
separate file and a separate rule in meson.build.
Reviewed-by: Thomas Huth <
virtio-ccw: move vhost_ccw_scsi to a separate file
Remove unecessary use of #ifdef CONFIG_VHOST_SCSI, instead just use a
separate file and a separate rule in meson.build.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|