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. 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.
