qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v3 1/1] memory: Skip bad range assertion if notifier supports a


From: Peter Xu
Subject: Re: [RFC v3 1/1] memory: Skip bad range assertion if notifier supports arbitrary masks
Date: Tue, 1 Sep 2020 15:35:04 -0400

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]