On 7/15/25 5:26 AM, Mark Cave-Ayland wrote:
> Use QOM casts to cast to VFIOPCIDevice instead of using container_of().
>
> Signed-off-by: Mark Cave-Ayland
> ---
> hw/s390x/s390-pci-vfio.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
Reviewed-by: Matthew Rosato
09
> Signed-off-by: Peter Maydell
> ---
> Disclaimer: only tested with 'make check/make check-functional'
Reviewed-by: Matthew Rosato
Also to sanity check I ran various tests with s390x guests and a few different
PCI passthrough devices using a guest IOMMU to drive table_translate frequently.
On 6/26/25 12:19 PM, Matthew Rosato wrote:
> On 6/9/25 12:44 PM, Rorie Reyes wrote:
>> Handle interception of the CHSC SEI instruction for requests
>> indicating the guest's AP configuration has changed.
>>
>> If configuring --without-default-devices, hw/s390x/ap
>>
>> AFAICT this portion of the handler including mutex should be moved out of
>> ap.c into chsc_sei_nt0_get_event(). When vfio_ap is not in use, we can't
>> call into it. Can't you also build without VFIO_AP? I didn't try it but
>> that sure seems like it would cause issues too.
>
> If t
On 6/9/25 12:44 PM, Rorie Reyes wrote:
> Handle interception of the CHSC SEI instruction for requests
> indicating the guest's AP configuration has changed.
>
> If configuring --without-default-devices, hw/s390x/ap-stub.c
> was created to handle such circumstance. Also added the
> following to hw/
To improve review coverage, assign additional people as reviewers for
multiple s390 sections.
Signed-off-by: Matthew Rosato
---
MAINTAINERS | 12
1 file changed, 12 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 94c4076127..3ce6fce8ce 100644
--- a/MAINTAINERS
+++ b
On 5/14/25 5:32 AM, Thomas Huth wrote:
> On 13/05/2025 15.42, Matthew Rosato wrote:
>> On 5/13/25 2:50 AM, Christian Borntraeger wrote:
>>> Am 29.04.25 um 16:09 schrieb Matthew Rosato:
>>>> On 4/29/25 3:45 AM, Christian Borntraeger wrote:
>>>>> A
On 5/13/25 2:50 AM, Christian Borntraeger wrote:
> Am 29.04.25 um 16:09 schrieb Matthew Rosato:
>> On 4/29/25 3:45 AM, Christian Borntraeger wrote:
>>> Am 29.04.25 um 09:37 schrieb David Hildenbrand:
>>> [...]
>>>> The only problem I see is with vfio device
On 4/29/25 3:45 AM, Christian Borntraeger wrote:
> Am 29.04.25 um 09:37 schrieb David Hildenbrand:
> [...]
>> The only problem I see is with vfio devices is the new "memory pinned" mode.
>> [1]
>>
>> There, we'd have to check if any such device is around (discarding of ram is
>> disabled?), and f
: Matthew Rosato
---
hw/s390x/s390-pci-bus.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 6cc0e7538a..c41c88f88e 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -1147,6 +1147,12 @@ static void s390_pcihost_plug
In the unlikely event that we must fail hotplug of a PCI passthrough
device, ensure appropriate clean up of the associated zPCI device is
performed.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-bus.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git
the associated S390PCIBusDevice were not properly
cleaned up. So let's fix that too.
Matthew Rosato (2):
s390x/pci: fix cleanup of failed hotplug
s390x/pci: add message for ISM without zPCI interpretation
hw/s390x/s390-pci-bus.c | 27 +--
1 file change
Specifying this bit in the guest CLP response indicates that the guest
can optionally choose to skip translation and instead use
identity-mapped operations.
Tested-by: Niklas Schnelle
Reviewed-by: Niklas Schnelle
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c| 5
Add a new MPCIFC failure case when direct-mapping requested but
the relax-translation property is set to off.
- For direct mapping, use a memory alias to handle the SMDA offset and
then just let vfio handle the pinning of memory.
Matthew Rosato (2):
s390x/pci: add support for guests that r
, allowing them to be used as lookup into the host
iommu table.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-bus.c | 39 +++--
hw/s390x/s390-pci-inst.c| 13 +--
hw/s390x/s390-pci-vfio.c| 23 +++
hw/s390x/s390-virtio-ccw.c
Specifying this bit in the guest CLP response indicates that the guest
can optionally choose to skip translation and instead use
identity-mapped operations.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c| 5 -
include/hw/s390x/s390-pci-clp.h | 1 +
2 files changed, 5
ias to handle the SMDA offset and
then just let vfio handle the pinning of memory.
Matthew Rosato (2):
s390x/pci: add support for guests that request direct mapping
s390x/pci: indicate QEMU supports relaxed translation for passthrough
hw/s390x/s390-pci-bus.c |
, allowing them to be used as lookup into the host
iommu table.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-bus.c | 38 +++--
hw/s390x/s390-pci-inst.c| 13 +--
hw/s390x/s390-pci-vfio.c| 23
hw/s390x/s390-virtio
>>
>> static void s390_pci_iommu_free(S390pciState *s, PCIBus *bus, int32_t devfn)
>> @@ -1488,6 +1518,8 @@ static const Property s390_pci_device_properties[] = {
>> DEFINE_PROP_BOOL("interpret", S390PCIBusDevice, interp, true),
>> DEFINE_PROP_BOOL("forwarding-assist", S390PCIBusDevi
>> #include "hw/s390x/s390-pci-bus.h"
>> @@ -1008,17 +1009,25 @@ static int reg_ioat(CPUS390XState *env,
>> S390PCIBusDevice *pbdev, ZpciFib fib,
>> }
>> /* currently we only support designation type 1 with translation */
>> - if (!(dt == ZPCI_IOTA_RTTO && t)) {
>> + if (t
>> +void s390_pci_iommu_dm_enable(S390PCIIOMMU *iommu)
>> +{
>> + MachineState *ms = MACHINE(qdev_get_machine());
>> + S390CcwMachineState *s390ms = S390_CCW_MACHINE(ms);
>> +
>> + /*
>> + * For direct-mapping we must map the entire guest address space.
>> Rather
>> + * than
, allowing them to be used as lookup into the host
iommu table.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-bus.c | 36 +++--
hw/s390x/s390-pci-inst.c| 13 ++--
hw/s390x/s390-pci-vfio.c| 15 ++
hw/s390x/s390-virtio-ccw.c
Specifying this bit in the guest CLP response indicates that the guest
can optionally choose to skip translation and instead use
identity-mapped operations.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c| 5 -
include/hw/s390x/s390-pci-clp.h | 1 +
2 files changed, 5
and
then just let vfio handle the pinning of memory.
Matthew Rosato (2):
s390x/pci: add support for guests that request direct mapping
s390x/pci: indicate QEMU supports relaxed translation for passthrough
hw/s390x/s390-pci-bus.c | 36 +++--
hw/s390x/s390
On 12/16/24 12:29 PM, David Hildenbrand wrote:
> On 16.12.24 18:26, Matthew Rosato wrote:
>>
>>>> Good point. Using s390_get_memory_limit() sounds good to me; That will
>>>> make v3 of this series dependent on the s390x virtio-mem series but sounds
>>&g
>> Good point. Using s390_get_memory_limit() sounds good to me; That will make
>> v3 of this series dependent on the s390x virtio-mem series but sounds like
>> you're sending that sometime this week anyway.
>
> If my testing is good and there are no further comments, I'll queue it
> directly
>>> +{
>>> + MachineState *ms = MACHINE(qdev_get_machine());
>>> +
>>> + /*
>>> + * For direct-mapping we must map the entire guest address space.
>>> Rather
>>> + * than using an iommu, create a memory region alias that maps GPA X to
>>> + * iova X + SDMA. VFIO will handle p
Specifying this bit in the guest CLP response indicates that the guest
can optionally choose to skip translation and instead use
identity-mapped operations.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c| 5 -
include/hw/s390x/s390-pci-clp.h | 1 +
2 files changed, 5
to be of the format
guest_phys+sdma, allowing them to be used as lookup into the host
iommu table.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-bus.c | 34 +++--
hw/s390x/s390-pci-inst.c| 13 +++--
hw/s390x/s390-virtio-ccw.c | 5
machines
- Add a new MPCIFC failure case when direct-mapping requested but
the relax-translation property is set to off.
- For direct mapping, use a memory alias to handle the SMDA offset and
then just let vfio handle the pinning of memory.
Matthew Rosato (2):
s390x/pci: add support for guests
On 12/10/24 3:58 AM, David Hildenbrand wrote:
> Maybe there is a reason s390x needs to handle this using
> memory_region_notify_iommu() callbacks instead of doing it similar to "struct
> vfio_memory_listener" when registered on &address_space_memory without a
> viommu.
>
Hi David,
I think I
On 12/12/24 4:10 AM, Thomas Huth wrote:
> On 09/12/2024 20.29, Matthew Rosato wrote:
>> This series introduces the concept of the relaxed translation requirement
>> for s390x guests in order to allow bypass of the guest IOMMU for more
>> efficient PCI passthrough.
>>
&g
On 12/11/24 9:40 AM, Cédric Le Goater wrote:
> On 12/9/24 20:29, Matthew Rosato wrote:
>> static int reg_ioat(CPUS390XState *env, S390PCIBusDevice *pbdev, ZpciFib
>> fib,
>> uintptr_t ra)
>> {
>> @@ -1008,7 +1036,7 @@ stati
On 12/9/24 5:09 PM, David Hildenbrand wrote:
> On 09.12.24 22:45, Matthew Rosato wrote:
>> On 12/9/24 4:01 PM, David Hildenbrand wrote:
>>> On 09.12.24 20:29, Matthew Rosato wrote:
>>>
>>> Hi,
>>>
>>> Trying to wrap my head around that ... y
On 12/9/24 4:01 PM, David Hildenbrand wrote:
> On 09.12.24 20:29, Matthew Rosato wrote:
>
> Hi,
>
> Trying to wrap my head around that ... you mention that "pin the entirety of
> guest memory".
>
> Do you mean that we will actually end up longterm pinn
[1] that adds the relevant behavior needed to
exploit this new feature from within a s390x linux guest.
[1]:
https://lore.kernel.org/linux-s390/20241209192403.107090-1-mjros...@linux.ibm.com/
Matthew Rosato (2):
s390x/pci: add support for guests that request direct mapping
s390x/pci: indicate
Specifying this bit in the guest CLP response indicates that the guest
can optionally choose to skip translation and instead use
identity-mapped operations.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c| 4 +++-
include/hw/s390x/s390-pci-clp.h | 1 +
2 files changed, 4
to be of the format
guest_phys+sdma, allowing them to be used as lookup into the host
iommu table.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-bus.c | 23 ++
hw/s390x/s390-pci-inst.c| 42 +++--
include/hw/s390x/s390-pci-bus.h
On 9/11/24 11:15 AM, Akihiko Odaki wrote:
> On 2024/09/11 22:53, Matthew Rosato wrote:
>> On 9/11/24 6:58 AM, Akihiko Odaki wrote:
>>> On 2024/09/11 18:38, Cédric Le Goater wrote:
>>>> +Matthew +Eric
>>>>
>>>> Side note for the maintainers :
On 9/11/24 6:58 AM, Akihiko Odaki wrote:
> On 2024/09/11 18:38, Cédric Le Goater wrote:
>> +Matthew +Eric
>>
>> Side note for the maintainers :
>>
>> Before this change, the igb device, which is multifunction, was working
>> fine under Linux.
>>
>> Was there a fix in Linux since :
>>
>> 57da367b
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 1/19/24 4:07 PM, Halil Pasic wrote:
> On Thu, 18 Jan 2024 13:51:51 -0500
> Matthew Rosato wrote:
>
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index eaf61d3640..c99682b07d 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>>
390x/pci: reset ISM passthrough devices on shutdown and
system reset")
Reported-by: Cédric Le Goater
Reviewed-by: Eric Farman
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-kvm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/s390x/s390-pci-kvm.c b/hw/s390x/s390-pci-kv
ISM passthrough devices on shutdown and
system reset")
Reported-by: Cédric Le Goater
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-bus.c | 26 +-
hw/s390x/s390-virtio-ccw.c | 8
include/hw/s390x/s390-pci-bus.h | 1 +
3 files changed,
reted devices")
Reported-by: Cédric Le Goater
Reviewed-by: Eric Farman
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-kvm.c | 25 +++--
include/hw/s390x/s390-pci-bus.h | 1 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/hw/s390x/s390-pci-
y did not detect and
issue a warning for this scenario.
Changes for v2:
- Fold a typo fix from patch 2 into patch 1 where it belongs
- Add block comment re: timing of ISM reset
- Add review tags
Matthew Rosato (3):
s390x/pci: avoid double enable/disable of aif
s390x/pci: refresh fh b
On 1/17/24 10:19 AM, Matthew Rosato wrote:
> On 1/17/24 6:01 AM, Cédric Le Goater wrote:
>> Adding Alex,
>>
>> On 1/16/24 23:31, Matthew Rosato wrote:
>>> ISM devices are sensitive to manipulation of the IOMMU, so the ISM device
>>> needs to be reset before t
On 1/17/24 5:31 AM, Cédric Le Goater wrote:
> Hello Matthew,
>
> On 1/16/24 23:31, Matthew Rosato wrote:
>> Typically we refresh the host fh during CLP enable, however it's possible
>> that the device goes through multiple reset events before the guest
>> per
On 1/17/24 6:01 AM, Cédric Le Goater wrote:
> Adding Alex,
>
> On 1/16/24 23:31, Matthew Rosato wrote:
>> 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
On 1/17/24 5:40 AM, Cédric Le Goater wrote:
> On 1/16/24 23:31, Matthew Rosato wrote:
>> 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. Le
On 1/17/24 5:54 AM, Cédric Le Goater wrote:
> On 1/16/24 23:31, Matthew Rosato wrote:
>> Use a flag to keep track of whether AIF is currently enabled. This can be
>> used to avoid enabling/disabling AIF multiple times as well as to determine
>> whether or not it should be
>> - return kvm_vm_ioctl(kvm_state, KVM_S390_ZPCI_OP, &args);
>> + if (!pbdev->aif) {
>> + return -EINVAL;
>> + }
>> +
>> + rc = kvm_vm_ioctl(kvm_state, KVM_S390_ZPCI_OP, &args);
>> + if (rc == 0) {
>> + pbev->aif = false;
>
> s/pbev/pbdev/
>
> You fix this in patch
On 1/16/24 10:01 PM, Eric Farman wrote:
> On Tue, 2024-01-16 at 17:31 -0500, Matthew Rosato wrote:
>>
>> +void s390_pci_ism_reset(void)
>> +{
>> + S390pciState *s = s390_get_phb();
>> +
>> + S390PCIBusDevice *pbdev, *next;
>> +
>> +
390x/pci: reset ISM passthrough devices on shutdown and
system reset")
Reported-by: Cédric Le Goater
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-kvm.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/hw/s390x/s390-pci-kvm.c b/hw/s390x/s390-pci-kv
y did not detect and
issue a warning for this scenario.
Matthew Rosato (3):
s390x/pci: avoid double enable/disable of aif
s390x/pci: refresh fh before disabling aif
s390x/pci: drive ISM reset from subsystem reset
hw/s390x/s390-pci-bus.c | 26 -
hw/s390x/s39
reted devices")
Reported-by: Cédric Le Goater
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-kvm.c | 25 +++--
include/hw/s390x/s390-pci-bus.h | 1 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/hw/s390x/s390-pci-kvm.c b/hw/s390x/s390-pci-k
ISM passthrough devices on shutdown and
system reset")
Reported-by: Cédric Le Goater
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-bus.c | 26 +-
hw/s390x/s390-virtio-ccw.c | 2 ++
include/hw/s390x/s390-pci-bus.h | 1 +
3 files changed, 20 insert
On 1/11/24 4:43 AM, Cédric Le Goater wrote:
> OK. this condition is considered serious enough to be reported to a
> management level. This seems a bit excessive since the recovery can be
> handled by software, but manually. Are there any plans to address this
> problem ?
Yes, eventually. Current
On 1/11/24 5:18 AM, Christian Borntraeger wrote:
>
>
> Am 11.01.24 um 10:43 schrieb Cédric Le Goater:
> [...]
>>
>>
>> On a side note, I am also seeing :
>
> Michael?
>
Hmm, it looks like this warning is tripping because we have a path in PCI
passthrough where we don't unregister the gisc. T
On 1/10/24 1:30 PM, Cédric Le Goater wrote:
> On 9/12/23 13:41, Thomas Huth wrote:
>> From: Janosch Frank
>>
>> Bound APQNs have to be reset before tearing down the secure config via
>> s390_machine_unprotect(). Otherwise the Ultravisor will return a error
>> code.
>>
>> So let's do a subsystem_re
On 11/13/23 4:24 PM, Michael Tokarev wrote:
> 10.11.2023 20:51, Matthew Rosato wrote:
>> 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 vf
bug as it's possible
for an older host kernel to be missing this support today; so ideally this one
should be targeted for 8.2 regardless.
Changes for v2:
- minor style changes (Phil, Thomas)
Matthew Rosato (2):
s390x/pci: bypass vfio DMA counting when using cdev
s390x/pci: only limit
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
---
hw/s390x/s390-pci-vfio.c | 2 +-
1 file changed, 1 insertion(+),
The current code assumes that there is always a vfio group, but
that's no longer guaranteed with the iommufd backend when using
cdev. In this case, we don't need to track the vfio dma limit
anyway.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c | 4
1 file
4c068d7960..26ad104485 100644
> --- a/hw/s390x/Kconfig
> +++ b/hw/s390x/Kconfig
> @@ -6,6 +6,7 @@ config S390_CCW_VIRTIO
> imply VFIO_CCW
> imply WDT_DIAG288
> imply PCIE_DEVICES
> +imply IOMMUFD
> select PCI_EXPRESS
> select S390_FLIC
>
On 11/9/23 6:45 AM, Zhenzhong Duan wrote:
> This gives management tools like libvirt a chance to open the vfio
> cdev with privilege and pass FD to qemu. This way qemu never needs
> to have privilege to open a VFIO or iommu cdev node.
>
> Signed-off-by: Zhenzhong Duan
Revie
ccw device options:
>
> -object iommufd,id=iommufd0
> -device vfio-ccw,sysfsdev=/sys/bus/mdev/devices/XXX,iommufd=iommufd0
>
> Suggested-by: Alex Williamson
> Signed-off-by: Zhenzhong Duan
Reviewed-by: Matthew Rosato
-ap device options:
>
> -object iommufd,id=iommufd0
> -device vfio-ap,sysfsdev=/sys/bus/mdev/devices/XXX,iommufd=iommufd0
>
> Suggested-by: Alex Williamson
> Signed-off-by: Zhenzhong Duan
Reviewed-by: Matthew Rosato
On 11/9/23 6:45 AM, Zhenzhong Duan wrote:
> This gives management tools like libvirt a chance to open the vfio
> cdev with privilege and pass FD to qemu. This way qemu never needs
> to have privilege to open a VFIO or iommu cdev node.
>
> Signed-off-by: Zhenzhong Duan
Revie
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
---
hw/s390x/s390-pci-vfio.c | 2 +-
1 file changed, 1 insertion(+),
The current code assumes that there is always a vfio group, but
that's no longer guaranteed with the iommufd backend when using
cdev. In this case, we don't need to track the vfio dma limit
anyway.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c | 6 +-
1 file
bug as it's possible
for an older host kernel to be missing this support today; so ideally this one
should be targeted for 8.2 regardless.
Matthew Rosato (2):
s390x/pci: bypass vfio DMA counting when using cdev
s390x/pci: only limit DMA aperture if vfio DMA limit reported
hw/s390x/s390-p
On 11/7/23 1:28 PM, Cédric Le Goater wrote:
> On 11/2/23 08:12, Zhenzhong Duan wrote:
>> Hi,
>>
>> Thanks all for giving guides and comments on previous series, here is
>> the v4 of pure iommufd support part.
>>
>> Based on Cédric's suggestion, this series includes an effort to remove
>> spapr code
On 11/2/23 3:12 AM, Zhenzhong Duan wrote:
> From: Yi Liu
>
> Add the iommufd backend. The IOMMUFD container class is implemented
> based on the new /dev/iommu user API. This backend obviously depends
> on CONFIG_IOMMUFD.
>
> So far, the iommufd backend doesn't support dirty page sync yet due
> t
passing errp into
vfio_attach_device and that should have an error propogated when ret!=0,
meaning we won't get the dc->unrealize() later. Device wasn't attached, but we
did allocate memory for vbasedev->name already so we need to undo that part
ourselves. That could be inlin
gt; Signed-off-by: Eric Auger
> Signed-off-by: Yi Liu
> Signed-off-by: Zhenzhong Duan
>
> ---
> v2 -> v3:
> - Hopefully fix confusion beteen vbasedev->name, mdevid and sysfsdev
> while keeping into account Matthew's comment
>
> https://lore.kernel.org/qe
On 10/3/23 11:25 AM, Cédric Le Goater wrote:
> On 10/3/23 12:14, Eric Auger wrote:
>> Let the vfio-ap device use vfio_attach_device() and
>> vfio_detach_device(), hence hiding the details of the used
>> IOMMU backend.
>>
>> We take the opportunity to use g_path_get_basename() which
>> is prefered,
On 9/27/23 8:09 AM, Duan, Zhenzhong wrote:
>
>
>> -Original Message-
>> From: Eric Auger
>> Sent: Wednesday, September 27, 2023 6:00 PM
>> Subject: Re: [PATCH v2 09/12] vfio/ccw: Use vfio_[attach/detach]_device
>>
>>
>>
>> On 9/26/23 13:32, Zhenzhong Duan wrote:
>>> From: Eric Auger
>>>
been on my todo list for a while. Message contents
look fine, so with Thomas's minor nit:
Reviewed-by: Matthew Rosato
On 7/5/23 10:54 AM, Matthew Rosato wrote:
> On 6/4/23 2:16 AM, Sam Li wrote:
>> The g_file_get_contents() function returns a g_boolean. If it fails, the
>> returned value will be 0 instead of -1. Solve the issue by skipping
>> assigning ret value.
>>
>> This issue
oller, which all support MSI-X. Devices only supporting
> INTx won't work on s390x.
>
> Signed-off-by: Cédric Le Goater
Acked-by: Matthew Rosato
> ---
>
> v3: PCI -> PCI_EXPRESS
> v2: select -> imply
>
> hw/s390x/Kconfig | 5 -
> 1 file changed
On 6/4/23 2:16 AM, Sam Li wrote:
> The g_file_get_contents() function returns a g_boolean. If it fails, the
> returned value will be 0 instead of -1. Solve the issue by skipping
> assigning ret value.
>
> This issue was found by Matthew Rosato using virtio-blk-{pci,ccw} back
On 7/4/23 9:33 AM, Philippe Mathieu-Daudé wrote:
> On 4/7/23 14:32, Cédric Le Goater wrote:
>> On 7/4/23 14:09, Philippe Mathieu-Daudé wrote:
>>> On 4/7/23 14:01, Cédric Le Goater wrote:
It is useful to extend the number of available PCI devices to KVM guests
for passthrough scenarios and
On 6/4/23 2:16 AM, Sam Li wrote:
> The g_file_get_contents() function returns a g_boolean. If it fails, the
> returned value will be 0 instead of -1. Solve the issue by skipping
> assigning ret value.
>
> This issue was found by Matthew Rosato using virtio-blk-{pci,ccw} back
On 6/2/23 2:18 PM, Sam Li wrote:
> Matthew Rosato 于2023年6月1日周四 02:21写道：
>>
>> On 5/15/23 12:04 PM, Stefan Hajnoczi wrote:
>>> From: Sam Li
>>>
>>> Use get_sysfs_str_val() to get the string value of device
>>> zoned model. Then get_sysfs_zoned_m
On 5/15/23 12:04 PM, Stefan Hajnoczi wrote:
> From: Sam Li
>
> Use get_sysfs_str_val() to get the string value of device
> zoned model. Then get_sysfs_zoned_model() can convert it to
> BlockZoneModel type of QEMU.
>
> Use get_sysfs_long_val() to get the long value of zoned device
> information.
On 5/31/23 8:52 AM, Anthony Krowiak wrote:
>
>
> On 5/30/23 8:56 PM, Matthew Rosato wrote:
>> On 5/30/23 6:55 PM, Tony Krowiak wrote:
>>> Signed-off-by: Tony Krowiak
>>> ---
>>> linux-headers/linux/vfio.h | 9 +
>>> 1 file changed,
On 5/30/23 6:55 PM, Tony Krowiak wrote:
> Signed-off-by: Tony Krowiak
> ---
> linux-headers/linux/vfio.h | 9 +
> 1 file changed, 9 insertions(+)
Worth nothing here that linux-headers patches should be generated using
scripts/update-linux-headers.sh.
Since this linux-headers update inc
lex Williamson
> Signed-off-by: Zhenzhong Duan
Reviewed-by: Matthew Rosato
Also verified that this resolves an issue seen on s390, as we were seeing not
just garbage logs but QEMU crashes in certain cases e.g. during device unplug.
Thanks!
> ---
> v2: "toke" -> &q
On 5/9/23 5:59 PM, Alex Williamson wrote:
> From: Minwoo Im
>
> VF token was introduced [1] to kernel vfio-pci along with SR-IOV
> support [2]. This patch adds support VF token among PF and VF(s). To
> passthu PCIe VF to a VM, kernel >= v5.7 needs this.
>
> It can be configured with UUID like:
On 1/31/23 3:52 PM, Eric Auger wrote:
> Let the vfio-ccw device use vfio_attach_device() and
> vfio_detach_device(), hence hiding the details of the used
> IOMMU backend.
>
> Also now all the devices have been migrated to use the new
> vfio_attach_device/vfio_detach_device API, let's turn the
> le
On 12/12/22 6:34 AM, Thomas Huth wrote:
> On 09/12/2022 20.57, Matthew Rosato wrote:
>> ISM device firmware stores unique state information that can
>> can cause a wholesale unmap of the associated IOMMU (e.g. when
>> we get a termination signal for QEMU) to trigger firmw
; this is enough to indicate to firmware that the IOMMU
is no longer in-use by the guest OS, making it safe to invalidate any
associated IOMMU entries.
Fixes: 15d0e7942d3b ("s390x/pci: don't fence interpreted devices without MSI-X")
Signed-off-by: Matthew Rosato
---
hw/s390x
> Thanks,
>
> C.
Thanks Cedric.
For the series:
Reviewed-by: Matthew Rosato
Also did a quick test on top of
https://gitlab.com/thuth/qemu.git tags/pull-request-2022-11-06
to verify that zPCI interpretation/forwarding is available as expected with
machine 7.2 and off by default
ned-off-by: Peter Jin
>
> We've talked previously about clearing this within the
> do_subchannel_work_passthrough routine in order to keep the _virtual
> paths untouched, but this seems like a reasonable approach to me.
>
> The commit message is probably fine either way, but a
The following series fixes an issue with guest RPCIT processing discovered
during development of [1] as well as proposes a few additional optimizations
to the current RPCIT codepath.
[1]
https://lore.kernel.org/linux-s390/20221019144435.369902-1-schne...@linux.ibm.com/
Matthew Rosato (3
Currently, each unmapped page is handled as an individual iommu
region notification. Attempt to group contiguous unmap operations
into fewer notifications to reduce overhead.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-inst.c | 51
1 file
)
Reported-by: Niklas Schnelle
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-inst.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 20a9bcc7af..7cc4bcf850 100644
--- a/hw/s390x/s390-
e and host limit far less likely and more indicitive
of an error.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-pci-vfio.c| 11 +++
include/hw/s390x/s390-pci-bus.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/hw/s390x/s390-pci-vfio.c b/hw/s390x/s390-pci-vfio.c
index 2aefa
Peter Maydell
> ---
> NB: tested only with 'make check' and 'make check-avocado', which
> probably don't exercise this codepath.
>
I exercised the codepath by triggering the associated clp using both virtio and
vfio pci devices on s390x; looks good to me.
R
1 - 100 of 544 matches
Mail list logo
