Re: Where do we stand with the Xen patches?

[Ingo Molnar <mingo@elte.hu>]

* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> On Mon, 18 May 2009 10:40:52 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> > 
> > > On Thu, 14 May 2009 12:54:54 -0700
> > > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> > > 
> > > > Hi Ingo,
> > > > 
> > > > Over the last week or so, I've set out pull requests for the following 
> > > > branches in git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git :
> > > > 
> > > > for-ingo/xen/dom0/core
> > > > 
> > > >     You made two comments about the first post of this set:
> > > > 
> > > >        1. The // comments in the mtrr code.  Now fixed.
> > > >        2. A query about when Xen can support PAT.  In progress; when its
> > > >           done, we can remove the unconditional PAT disable.
> > > > 
> > > > for-ingo/xen/dom0/pci
> > > > for-ingo/xen/dom0/swiotlb
> > > > 
> > > >     Updated with Joerg Roedel, FUJITA Tomonori and Matthew Wilcox's
> > > >     comments,  Acked-by and Reviewed-bys as appropriate.
> > > 
> > > The original code added dom0-specific dma mapping stuff in the 
> > > generic place, which is completely wrong. I asked you to move the 
> > > hacky stuff to Xen-specific code and ack'ed the patchset.
> > > 
> > > But as I said again and again, the dom0 changes to the generic dma 
> > > mapipng code is really ugly and I don't like them at all. I didn't 
> > > ack'ed such changes.
> > 
> > How should it be solved instead? Can you see a clean way to achieve 
> > it? (maybe you already explained it in past threads - if yes then 
> > have you got subject lines or URIs to that?)
> 
> 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?

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.

Hm?

	Ingo