lkml.org 
[lkml]   [2009]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [00/15] swiotlb cleanup
From
Date
On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> I don't think that we need to take account of dom0 support; we don't
> have a clear idea about an acceptable dom0 design (it needs to use
> swiotlb code? I don't know yet), we don't even know we will have dom0
> support in mainline. That's why I didn't CC this patchset to Xen
> camp.

The core domain 0 patches which were the subject of the discussions a
few week back are completely orthogonal to the swiotlb side of things
and whatever form they eventually take I do not think it will have any
impact on the shape of the solution which we arrive at for swiotlb. I
don't think that assuming that domain 0 can never be done in a way which
everyone finds acceptable and therefore discounting all consideration of
it is a useful way to make progress with these issues.

The DMA use case is much more tightly tied to the paravirtualized MMU
(which is already in the kernel for domU purposes) than it is to "the
domain 0" patches anyway. Although domain 0 is probably the main use
case, at least today, swiotlb support is also used in a Xen domU as part
of the support for direct assignment of PCI devices to paravirtualised
guests (pci passthrough).

The pci frontend driver depends on some bits of the domain 0 physical
interrupt patches as well as swiotlb which is why I/we haven't tried to
upstream that particular series yet.

Ian.




\
 
 \ /
  Last update: 2009-07-10 16:05    [W:0.092 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site