linux-kernel - Re: [Xen-devel] [PATCH] xen: Add __GFP_DMA flag when xen_swiotlb

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]

Date:	Tue, 21 Apr 2015 11:36:57 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Ian Campbell <Ian.Campbell@...rix.com>
CC:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Chen Baozi <cbz@...zis.org>, <xen-devel@...ts.xen.org>,
	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	Roger Pau Monne <roger.pau@...rix.com>
Subject: Re: [Xen-devel] [PATCH] xen: Add __GFP_DMA flag when xen_swiotlb_init
 gets free pages.

On Tue, 21 Apr 2015, Ian Campbell wrote:
> On Mon, 2015-04-20 at 18:54 +0100, Stefano Stabellini wrote:
> > This should definitely be done only on ARM and ARM64, as on x86 PVH
> > assumes the presence of an IOMMU. We need an ifdef.
> > 
> > Also we need to figure out a way to try without GFP_DMA in case no ram
> > under 4g is available at all, as some arm64 platforms don't have any. Of
> > course in those cases we don't need to worry about devices and their dma
> > masks.  Maybe we could use memblock for that?
> 
> It's pretty ugly, but I've not got any better ideas.
> 
> It would perhaps be less ugly as a an arch-specific
> get_me_a_swiotlb_region type function, with the bare __get_free_pages as
> the generic fallback.

We could do that, but even open code like this isn't too bad: it might
be ugly but at least is very obvious.


> >  Something like:
> > 
> >     struct memblock_region *reg;
> >     gfp_t flags = __GFP_NOWARN;
> > 
> > #if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> > 	for_each_memblock(memory, reg) {
> > 		unsigned long start = memblock_region_memory_base_pfn(reg);
> > 
> >         if (start < 4G) {
> >             flags |= __GFP_DMA;
> >             break;
> >         }
> >     }
> > #endif
> > 
> >     [...]
> > 
> >     xen_io_tlb_start = (void *)__get_free_pages(flags, order);
> >     
> > 
> > 
> > 
> > 
> > > This is also conceptually wrong since it doesn't matter where the pages
> > > are in PFN space,  but where they are in bus address (MFN) space (which
> > > is what the subsequent hypercall is required to sort out).
> > 
> > Actually on ARM dom0 is mapped 1:1, so it is the same thing.
> 
> On a system with a fully functional SMMU dom0 may not be 1:1 mapped, but
> I think that dom0 can still treat that as 1:1 mapped for these purposes,
> since the SMMU will provide that illusion.
> 
> Dumb question, and this might affect PVH too, if you have an IOMMU and a
> device with a limited DMA range, I suppose you need to provide DMA
> addresses in the <4G for the input to the IOMMU (i.e. PFN) and not the
> output (i.e. MFN) space (since the device only sees PFNs).

I think you mean "for the input to the device (PFN)", but I presume the
same.


> So even for x86 PVH isn't something required here to ensure that the
> swiotlb has suitable pages under 4GB in PFN space too?
> 
> (On ARM PFN==IPA and MFN==PA)

I guess that is true. PVH people, any thoughts?


> Second dumb question, on x86 PVH or ARM with an SMMU, would we even hit
> the Xen swiotlb code, or would we want to arrange to go via the native
> swiotlb paths? I initially thought the latter, but does e.g. grant
> mappings still need some special handling?

In both cases I think it would be simpler to just go through the normal
swiotlb.

FYI at the moment there is no knowledge about SMMUs availability on ARM.
The code is still missing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/