On Wed, Sep 12, 2018 at 11:15:32AM -0600, Alex Williamson wrote: > On Wed, 12 Sep 2018 12:44:15 -0400 > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > On Wed, Sep 12, 2018 at 10:34:43AM -0600, Alex Williamson wrote: > > > On Wed, 12 Sep 2018 12:14:44 -0400 > > > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > > > > > On Wed, Sep 12, 2018 at 04:04:00PM +0800, Tiwei Bie wrote: > > > > > On Mon, Jul 30, 2018 at 12:30:58PM +0300, Michael S. Tsirkin wrote: > > > > > [...] > > > > > > > > > > > > I generally wonder how are restarts of the backend handled > > > > > > with this approach: closing the VFIO device tends to reset > > > > > > the whole device. > > > > > > > > > > Hi Michael, > > > > > > > > > > I missed this comment previously.. This is a good point! > > > > > In this RFC, before sending the VFIO group fd to QEMU, > > > > > backend needs to close the VFIO device and unset the VFIO > > > > > container first. Otherwise, QEMU won't be able to set the > > > > > VFIO container for the VFIO group. > > > > > > > > > > Another option is to share the container fd instead of > > > > > the group fd to QEMU. In this case, backend won't need > > > > > to close any fd. But there is one problem that, it's > > > > > hard to unmap the old mappings, especially when QEMU > > > > > crashes. > > > > > > > > What are these old mappings and who creates them? > > > > If you want to just reset everything the way it was > > > > on open, surely it would be easy to add such a reset ioctl. > > > > > > > > > Do you have any suggestions? Thanks! > > > > > > > > > > Best regards, > > > > > Tiwei Bie > > > > > > > > Donnu. Alex, any thoughts? Which approach would you prefer? > > > > > > The existing UNMAP_DMA ioctl for the vfio type1 IOMMU only requires > > > that an unmap does not bisect previous mappings, ie. a previous mapping > > > cannot be partially unmapped. Therefore you can already dump the > > > entire IOVA space for a container with one UNMAP_DMA call, iova = 0, > > > size = (u64)-1. Thanks, > > > > > > Alex > > > > Hmm this would exclude the last byte (address (u64)-1). > > VTD does not support such iova values for now but something > > to keep in mind e.g. for virtio-iommu with nested virt > > which does. > > Yes, technically you'd need another ioctl to get the last byte,
It will violate the requirement of not unmapping part of a region, won't it? So it won't work. > the > ioctls should have used start and end rather than start and size, but > it's too late to change. Thanks, > > Alex At some point we'll have to fix above issue in some way. Maybe when we add support for atomic remaps. -- MST
