linux-kernel - Re: Where do we stand with the Xen patches?

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:	Wed, 20 May 2009 00:30:17 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	mingo@...e.hu
Cc:	fujita.tomonori@....ntt.co.jp, jeremy@...p.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
	gregkh@...e.de, okir@...e.de
Subject: Re: Where do we stand with the Xen patches?

On Tue, 19 May 2009 15:03:00 +0200
Ingo Molnar <mingo@...e.hu> wrote:

> > If we really need to merge dom0 support, then dom0 should have the 
> > own IOMMU implementation instead of adding any hacks to swiotlb 
> > (as I said long time ago). Yeah, there might be some duplication 
> > between swiotlb and the Xen IOMMU but IMO it's better to have 
> > clean code with some duplication rather than ugly unified code; 
> > unification makes sense only if we do cleanly.
> 
> Well, but since we merged PowerPC highmem support ... the precedent 
> is there already that the swiotlb code can be librarized and 
> generalized some more, right?

No,

The highmem support is ok for me (I was against the initial highmem
patchset but Becky's highmem patchset was much cleaner and we merged
it).

Due to dom0 support, we can't use architecture abstraction (such as
arch/include/asm/):

http://marc.info/?l=linux-kernel&m=124271086910299&w=2


We also need hacks for memory allocation due to dom0 support.


> What is the fundamental difference between a DMA32 device on native 
> hardware using lib/swiotlb.c to bounce IO directed to/from a high 
> address over buffers in a low, DMA-capable address, and between a 
> Xen Dom0 instance using the same functionality to DMA buffers?
> 
> The payback is significant: Linux drivers can be used basically 
> as-is (as far as their DMA functionality goes) in a Xen dom0 guest.
> 
> There's really just two non-standard Xen features compared to the 
> PowerPC-highmem use:
> 
>  - special allocation
> 
>  - non-standard virtual/physical/bus memory translations
> 
> The latter is understandable - Xen cannot do the (mostly-) linear 
> transformations that (most) platforms can do in their address 
> transformation primitives. But other than the non-linearity, it's a 
> "mapping" just as much.
> 
> The special allocator is arguably a bit of a hack - Xen should 
> _probably_ recognize GFP_DMA32 allocations at the page allocator 
> level and rearrange buffers there.
> 
> So realizing that dom0 _has_ to have guest OS help here, the best 
> possible design seems to be to minimalize the Xen cross section to 
> Linux, while still keeping it fast enough. And that seems to be 
> these two straightforward hooks: 'ready buffers for DMA' and 'map 
> addresses'. As long as we'll want to have swiotlb code in the 
> kernel, we'll deal with such primitives anyway - so there doesnt 
> seem to be a significant mainteinance drag here.

We need these hooks but as I wrote above, they are
architecture-specific and we should handle them with the architecture
abstraction (as we handle similar problems) however we can't due to
dom0 support.
--
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/