linux-kernel - Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2006091246350.2815@sstabellini-ThinkPad-T480s>
Date:   Tue, 9 Jun 2020 14:50:46 -0700 (PDT)
From:   Stefano Stabellini <sstabellini@...nel.org>
To:     Christoph Hellwig <hch@...radead.org>
cc:     Stefano Stabellini <sstabellini@...nel.org>, jgross@...e.com,
        boris.ostrovsky@...cle.com, konrad.wilk@...cle.com,
        xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
        tamas@...engyel.com, roman@...eda.com,
        Stefano Stabellini <stefano.stabellini@...inx.com>
Subject: Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys
 translations

On Mon, 8 Jun 2020, Christoph Hellwig wrote:
> On Mon, Jun 08, 2020 at 04:06:57PM -0700, Stefano Stabellini wrote:
> > I understand what you are suggesting about having something like:
> > 
> >     xen_phys_to_dma(...)
> >     {
> >         phys_addr_t phys = xen_phys_to_bus(dev, paddr)
> >         return phys_to_dma(phys);
> >     }
> > 
> > I thought about it myself. I'll do it.
> 
> "something", yes. Except that I think the bus is a little confusing,
> isn't it?  What is the Xen term for these addresses?

Xen reasons in terms of frame numbers. Xen calls them "dfn" for device
frame number. They were supposed to be called "bfn" but eventually they
settled for a different name when the series was committed.

I could s/bfn/dfn/g to match the terminology, if that helps.


> Also we probably don't need the extra local variable.

Sure


> > But I don't think I understood the comment about XEN_PFN_PHYS.
> 
> There is a comment above xen_phys_to_bus that it avoids using
> XEN_PFN_PHYS because XEN_PFN_PHYS of the phys_addr_t vs dma_addr_t
> mismatch.  But XEN_PFN_PHYS could just use a u64 instead of the
> phys_addr_t and then we could use it.   Especially as XEN_PFN_PHYS
> isn't actually used anywhere except in swiotlb-xen.c.  Or we could
> remove XEN_PFN_PHYS enirely, as it isn't all that useful to start
> with.

I'll remove it.