Re: Where do we stand with the Xen patches?

[FUJITA Tomonori]

On Mon, 18 May 2009 10:40:52 +0200
Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> * FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote:
> 
> > On Thu, 14 May 2009 12:54:54 -0700
> > Jeremy Fitzhardinge <jeremy@xxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/