> From: Shameerali Kolothum Thodi > [mailto:shameerali.kolothum.thodi@xxxxxxxxxx] > > Hi Kevin, > > Thanks for taking a look at this series. > > > -----Original Message----- > > From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx] > > Sent: Monday, March 19, 2018 8:29 AM > > To: Shameerali Kolothum Thodi > <shameerali.kolothum.thodi@xxxxxxxxxx>; > > alex.williamson@xxxxxxxxxx; eric.auger@xxxxxxxxxx; > > pmorel@xxxxxxxxxxxxxxxxxx > > Cc: kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; xuwei (O) > > <xuwei5@xxxxxxxxxx>; Linuxarm <linuxarm@xxxxxxxxxx>; > > iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx > > Subject: RE: [PATCH v5 0/7] vfio/type1: Add support for valid iova list > > management > > > > > From: Shameer Kolothum > > > Sent: Friday, March 16, 2018 12:35 AM > > > > > > This series introduces an iova list associated with a vfio > > > iommu. The list is kept updated taking care of iommu apertures, > > > and reserved regions. Also this series adds checks for any conflict > > > with existing dma mappings whenever a new device group is attached > to > > > the domain. > > > > > > User-space can retrieve valid iova ranges using > VFIO_IOMMU_GET_INFO > > > ioctl capability chains. Any dma map request outside the valid iova > > > range will be rejected. > > > > GET_INFO is done at initialization time which is good for cold attached > > devices. If a hotplugged device may cause change of valid iova ranges > > at run-time, then there could be potential problem (which however is > > difficult for user space or orchestration stack to figure out in advance) > > Can we do some extension like below to make hotplug case cleaner? > > As I understand, in case a hotplugged device results in an update to the > valid > Iova ranges then the Qemu, vfio_connect_container() --> > memory_listner_register() > will fail if there is a conflict as patch #4 checks for invalid dma map requests. OK, possibly Qemu can do another GET_INFO upon any dma map error to get latest ranges and then allocate a new valid iova to redo the map. this should work if valid ranges shrink due to new hotplugged device. But if hot-removing a device may result in more valid ranges, so far there is no way for Qemu to pick up. I'm not sure whether we want to go that far though... > > Not sure, your concern is preventing hotplug much before this happens or > not. > yes, my earlier thought is more to catch the problem in attach phase. Thanks Kevin
