On 02.05.23 15:43, Matthew Rosato wrote:
On 5/2/23 9:39 AM, David Hildenbrand wrote:
On 02.05.23 15:36, Jason Gunthorpe wrote:
On Tue, May 02, 2023 at 03:28:40PM +0200, David Hildenbrand wrote:
On 02.05.23 15:10, Jason Gunthorpe wrote:
On Tue, May 02, 2023 at 03:04:27PM +0200, Christian Borntraeger wrote:
\> > We can reintroduce a flag to permit exceptions if this is really broken, are you
able to test? I don't have an s390 sat around :)
Matt (Rosato on cc) probably can. In the end, it would mean having
<memoryBacking>
<source type="file"/>
</memoryBacking>
This s390 code is the least of the problems, after this series VFIO
won't startup at all with this configuration.
Good question if the domain would fail to start. I recall that IOMMUs for
zPCI are special on s390x. [1]
Not upstream they aren't.
Well, zPCI is special. I cannot immediately tell when we would trigger
long-term pinning.
zPCI uses the standard IOMMU stuff, so it uses a normal VFIO container
and the normal pin_user_pages() path.
@Christian, Matthew: would we pin all guest memory when starting the domain (IIRC, like on x86-64) and fail early, or only when the guest issues rpcit instructions to map individual pages?
Eventually we want to implement a mechanism where we can dynamically pin in response to RPCIT.
Okay, so IIRC we'll fail starting the domain early, that's good. And if
we pin all guest memory (instead of small pieces dynamically), there is
little existing use for file-backed RAM in such zPCI configurations
(because memory cannot be reclaimed either way if it's all pinned), so
likely there are no real existing users.
However, per Jason's prior suggestion, the initial implementation for s390 nesting via iommufd will pin all of guest memory when starting the domain. I have something already working via iommufd built on top of the nesting infrastructure patches and QEMU iommufd series that are floating around; needs some cleanup, hoping to send an RFC in the coming weeks. I can CC you if you'd like.
Yes, please.
--
Thanks,
David / dhildenb
