qemu-devel
[Top][All Lists]
Advanced

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

Re: [PULL 11/26] vfio/spapr: Allow backing bigger guest IOMMU pages with


From: David Gibson
Subject: Re: [PULL 11/26] vfio/spapr: Allow backing bigger guest IOMMU pages with smaller physical pages
Date: Tue, 24 Mar 2020 15:24:25 +1100

On Tue, Mar 24, 2020 at 03:08:22PM +1100, Alexey Kardashevskiy wrote:
> 
> 
> On 23/03/2020 21:55, Peter Maydell wrote:
> > On Tue, 21 Aug 2018 at 05:33, David Gibson <address@hidden> wrote:
> >>
> >> From: Alexey Kardashevskiy <address@hidden>
> >>
> >> At the moment the PPC64/pseries guest only supports 4K/64K/16M IOMMU
> >> pages and POWER8 CPU supports the exact same set of page size so
> >> so far things worked fine.
> >>
> >> However POWER9 supports different set of sizes - 4K/64K/2M/1G and
> >> the last two - 2M and 1G - are not even allowed in the paravirt interface
> >> (RTAS DDW) so we always end up using 64K IOMMU pages, although we could
> >> back guest's 16MB IOMMU pages with 2MB pages on the host.
> >>
> >> This stores the supported host IOMMU page sizes in VFIOContainer and uses
> >> this later when creating a new DMA window. This uses the system page size
> >> (64k normally, 2M/16M/1G if hugepages used) as the upper limit of
> >> the IOMMU pagesize.
> >>
> >> This changes the type of @pagesize to uint64_t as this is what
> >> memory_region_iommu_get_min_page_size() returns and clz64() takes.
> >>
> >> There should be no behavioral changes on platforms other than pseries.
> >> The guest will keep using the IOMMU page size selected by the PHB pagesize
> >> property as this only changes the underlying hardware TCE table
> >> granularity.
> > 
> > Hi; Coverity has raised an issue (CID 1421903) on this code and
> > I'm not sure if it's correct or not.
> > 
> > 
> >> @@ -144,9 +145,27 @@ int vfio_spapr_create_window(VFIOContainer *container,
> >>  {
> >>      int ret;
> >>      IOMMUMemoryRegion *iommu_mr = IOMMU_MEMORY_REGION(section->mr);
> >> -    unsigned pagesize = memory_region_iommu_get_min_page_size(iommu_mr);
> >> +    uint64_t pagesize = memory_region_iommu_get_min_page_size(iommu_mr);
> >>      unsigned entries, pages;
> >>      struct vfio_iommu_spapr_tce_create create = { .argsz = sizeof(create) 
> >> };
> >> +    long systempagesize = qemu_getrampagesize();
> >> +
> >> +    /*
> >> +     * The host might not support the guest supported IOMMU page size,
> >> +     * so we will use smaller physical IOMMU pages to back them.
> >> +     */
> >> +    if (pagesize > systempagesize) {
> >> +        pagesize = systempagesize;
> >> +    }
> 
> pagesize cannot be zero here (I checked possible code paths)...
> 
> 
> 
> >> +    pagesize = 1ULL << (63 - clz64(container->pgsizes &
> >> +                                   (pagesize | (pagesize - 1))));
> >> If the argument to clz64() is zero then it will return 64, and
> > then we will try to do a shift by -1, which is undefined
> > behaviour.
> 
> ... but the clz64() argument can if lets say container->pgsizes=1<<30
> (comes from VFIO) and pagesize=1<<16 (decided by QEMU or guest).
> 
> 
> I'll sent a patch to handle clz64()=>64. Thanks,

Thanks, Alexey.

Peter, I don't think this is urgent however - it's really unlikely in
practice.

> 
> 
> > Can the expression ever be zero? It's not immediately obvious to me
> > that it can't be, so my suggestion would be that if it is
> > impossible then an assert() of that would be helpful, and if it
> > is possible then the code needs to avoid the illegal shift.
> 
> >> +    if (!pagesize) {
> >> +        error_report("Host doesn't support page size 0x%"PRIx64
> >> +                     ", the supported mask is 0x%lx",
> >> +                     memory_region_iommu_get_min_page_size(iommu_mr),
> >> +                     container->pgsizes);
> >> +        return -EINVAL;
> >> +    }
> > 
> > thanks
> > -- PMM
> > 
> 

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

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