From: Thomas Huth <thuth@redhat.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>, qemu-s390x@nongnu.org
Cc: farman@linux.ibm.com, schnelle@linux.ibm.com,
pasic@linux.ibm.com, borntraeger@linux.ibm.com,
richard.henderson@linaro.org, david@redhat.com,
iii@linux.ibm.com, clegoate@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH 0/2] s390x/pci: relax I/O address translation requirement
Date: Fri, 13 Dec 2024 10:24:56 +0100 [thread overview]
Message-ID: <f1aff4c3-6395-46da-a19e-f5e7e46f1a2a@redhat.com> (raw)
In-Reply-To: <9b143fc7-9ac7-4b87-8089-5209aab186ec@linux.ibm.com>
On 12/12/2024 15.42, Matthew Rosato wrote:
> 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.
>>>
>>> With this series, QEMU can indicate to the guest that an IOMMU is not
>>> strictly required for a zPCI device. This would subsequently allow a
>>> guest linux to use iommu.passthrough=1 and bypass their guest IOMMU for
>>> PCI devices.
>>>
>>> When this occurs, QEMU will note the behavior via an intercepted MPCIFC
>>> instruction and will fill the host iommu with mappings of the entire
>>> guest address space in response.
>>>
>>> There is a kernel series [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-mjrosato@linux.ibm.com/
>>>
>>> Matthew Rosato (2):
>>> s390x/pci: add support for guests that request direct mapping
>>> s390x/pci: indicate QEMU supports relaxed translation for passthrough
>>
>> Hi again!
>>
>> One more thought: This is a guest-visible feature, isn't it? So do we also need some migration handling for this? For example, what happens if you start a guest that is aware of this feature on a host that has a QEMU with this feature, and then try to live-migrate the guest to a QEMU that does not have this feature? I guess the guest will crash? It would be better to fail the migration instead. At least we should disable the feature in older machine types and only allow it for the latest one.
>
> zPCI devices are currently marked as unmigratable in s390_pci_device_vmstate so it's not a reproducible issue yet.
Ah, right, I forgot about that migration blocker, so we should be fine, indeed!
> Re: disabling the feature for older machines, OK -- Shall I fence similar to what we did for interpret/forwarding-assist with a new device property that is default to off on older machines ("relax-translation"? alternative suggestions welcome)
Sounds reasonable!
Thomas
prev parent reply other threads:[~2024-12-13 9:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 19:29 [PATCH 0/2] s390x/pci: relax I/O address translation requirement Matthew Rosato
2024-12-09 19:29 ` [PATCH 1/2] s390x/pci: add support for guests that request direct mapping Matthew Rosato
2024-12-09 21:01 ` David Hildenbrand
2024-12-09 21:45 ` Matthew Rosato
2024-12-09 22:09 ` David Hildenbrand
2024-12-09 23:22 ` Matthew Rosato
2024-12-10 8:58 ` David Hildenbrand
2024-12-13 22:46 ` Matthew Rosato
2024-12-11 11:34 ` Thomas Huth
2024-12-11 14:40 ` Cédric Le Goater
2024-12-11 15:17 ` Matthew Rosato
2024-12-09 19:29 ` [PATCH 2/2] s390x/pci: indicate QEMU supports relaxed translation for passthrough Matthew Rosato
2024-12-11 11:40 ` Thomas Huth
2024-12-12 9:10 ` [PATCH 0/2] s390x/pci: relax I/O address translation requirement Thomas Huth
2024-12-12 14:42 ` Matthew Rosato
2024-12-13 9:07 ` Cédric Le Goater
2024-12-13 9:24 ` Thomas Huth [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f1aff4c3-6395-46da-a19e-f5e7e46f1a2a@redhat.com \
--to=thuth@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=clegoate@redhat.com \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=schnelle@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).