68c691ca | 18-Jan-2024 |
Matthew Rosato <mjrosato@linux.ibm.com> |
s390x/pci: drive ISM reset from subsystem reset
ISM devices are sensitive to manipulation of the IOMMU, so the ISM device needs to be reset before the vfio-pci device is reset (triggering a full UNM
s390x/pci: drive ISM reset from subsystem reset
ISM devices are sensitive to manipulation of the IOMMU, so the ISM device needs to be reset before the vfio-pci device is reset (triggering a full UNMAP). In order to ensure this occurs, trigger ISM device resets from subsystem_reset before triggering the PCI bus reset (which will also trigger vfio-pci reset). This only needs to be done for ISM devices which were enabled for use by the guest. Further, ensure that AIF is disabled as part of the reset event.
Fixes: ef1535901a ("s390x: do a subsystem reset before the unprotect on reboot") Fixes: 03451953c7 ("s390x/pci: reset ISM passthrough devices on shutdown and system reset") Reported-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20240118185151.265329-4-mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
30e35258 | 18-Jan-2024 |
Matthew Rosato <mjrosato@linux.ibm.com> |
s390x/pci: refresh fh before disabling aif
Typically we refresh the host fh during CLP enable, however it's possible that the device goes through multiple reset events before the guest performs anot
s390x/pci: refresh fh before disabling aif
Typically we refresh the host fh during CLP enable, however it's possible that the device goes through multiple reset events before the guest performs another CLP enable. Let's handle this for now by refreshing the host handle from vfio before disabling aif.
Fixes: 03451953c7 ("s390x/pci: reset ISM passthrough devices on shutdown and system reset") Reported-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20240118185151.265329-3-mjrosato@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
7af0cc14 | 21-Dec-2023 |
Zhao Liu <zhao1.liu@intel.com> |
hw/s390x/ccw: Replace dirname() with g_path_get_dirname()
As commit 3e015d815b3f ("use g_path_get_basename instead of basename") said, g_path_get_dirname() should be preferred over dirname() since t
hw/s390x/ccw: Replace dirname() with g_path_get_dirname()
As commit 3e015d815b3f ("use g_path_get_basename instead of basename") said, g_path_get_dirname() should be preferred over dirname() since the former is a portable utility function that has the advantage of not modifying the string argument.
Replace dirname() with g_path_get_dirname().
Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20231221171921.57784-3-zhao1.liu@linux.intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
469897ed | 21-Dec-2023 |
Zhao Liu <zhao1.liu@intel.com> |
hw/s390x/ccw: Replace basename() with g_path_get_basename()
g_path_get_basename() is a portable utility function that has the advantage of not modifying the string argument, so it should be preferre
hw/s390x/ccw: Replace basename() with g_path_get_basename()
g_path_get_basename() is a portable utility function that has the advantage of not modifying the string argument, so it should be preferred over basename().
And also to avoid potential compile breakage with the Musl C library similar to [1], replace basename() with g_path_get_basename().
[1]: https://lore.kernel.org/all/20231212010228.2701544-1-raj.khem@gmail.com/
Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-ID: <20231221171921.57784-2-zhao1.liu@linux.intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
8011b508 | 10-Nov-2023 |
Matthew Rosato <mjrosato@linux.ibm.com> |
s390x/pci: only limit DMA aperture if vfio DMA limit reported
If the host kernel lacks vfio DMA limit reporting, do not attempt to shrink the guest DMA aperture.
Fixes: df202e3ff3 ("s390x/pci: shri
s390x/pci: only limit DMA aperture if vfio DMA limit reported
If the host kernel lacks vfio DMA limit reporting, do not attempt to shrink the guest DMA aperture.
Fixes: df202e3ff3 ("s390x/pci: shrink DMA aperture to be bound by vfio DMA limit") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20231110175108.465851-3-mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
6d3910c9 | 06-Nov-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/s390x/sclp: Have sclp_service_call[_protected]() take S390CPU*
"hw/s390x/sclp.h" is a header used by target-agnostic objects (such hw/char/sclpconsole[-lm].c), thus can not use target-specific ty
hw/s390x/sclp: Have sclp_service_call[_protected]() take S390CPU*
"hw/s390x/sclp.h" is a header used by target-agnostic objects (such hw/char/sclpconsole[-lm].c), thus can not use target-specific types, such CPUS390XState.
Have sclp_service_call[_protected]() take a S390CPU pointer, which is target-agnostic.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231106114500.5269-3-philmd@linaro.org>
show more ...
|