On Tue, Sep 01, 2020 at 11:05:18AM +0800, Jason Wang wrote: > > On 2020/8/21 下午10:12, Peter Xu wrote: > > On Thu, Aug 20, 2020 at 10:28:00AM +0800, Jason Wang wrote: > > > On 2020/8/19 下午11:50, Peter Xu wrote: > > > > On Wed, Aug 19, 2020 at 03:15:26PM +0800, Jason Wang wrote: > > > > > Yes, actually, I feel confused after reading the codes. Is > > > > > notifier->start > > > > > IOVA or GPA? > > > > > > > > > > In vfio.c, we did: > > > > > > > > > > iommu_notifier_init(&giommu->n, vfio_iommu_map_notify, > > > > > IOMMU_NOTIFIER_ALL, > > > > > section->offset_within_region, > > > > > int128_get64(llend), > > > > > iommu_idx); > > > > > > > > > > So it looks to me the start and end are GPA, but the assertion above > > > > > check > > > > > it against IOVA which seems to be wrong .... > > > > It should be iova; both section->offset_within_region and llend are for > > > > the > > > > device's iova address space. Thanks, > > > > > > > Interesting, how can memory region know which IOVA is used by guest? > > Does it need to know? :) > > > > AFAICT what we do here is only register with the whole possible IOVA address > > space (e.g., across the whole 64bit address space). Then vfio will get > > notifications when there're new iova ranges mapped into it. > > > Right, but the whole IOVA address space should be something vIOMMU specific, > e.g for Intel it should be calculated by GAW, but I found: > > memory_region_init_iommu(&vtd_dev_as->iommu, > sizeof(vtd_dev_as->iommu), > TYPE_INTEL_IOMMU_MEMORY_REGION, OBJECT(s), > name, UINT64_MAX); > > which assumes UINT64_MAX.
Right. AFAICT it can be reduced to gaw width, but I don't see a problem either even with UINT64_MAX (as long as it covers the range specified by gaw). Or did I miss something? Thanks, -- Peter Xu
