WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Where do we stand with the Xen patches?

Ian Campbell wrote:
On Wed, 2009-05-20 at 00:30 +0900, FUJITA Tomonori wrote:
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.

I don't understand this. What exactly about the dom0 support patch
prevents future abstraction here?

The dom0 hooks would simply move into the per-arch abstractions as
appropriate, wouldn't they?

Fujita-san's suggestion to me was that swiotlb could just use the normal (albeit deprecated) phys_to_bus()/bus_to_phys() interfaces rather than defining its own. That would be perfectly OK for Xen; we have a single global translation which is unaffected by the target device, etc.

But I'm not sure it would work for powerpc; Becky's patches which added swiotlb_bus_to_phys/phys_bus made them take a device argument, because (apparently) the bus/phys offset can differ on a per-device or per-bus basis. The powerpc side of swiotlb doesn't seem to be in mainline yet, so I'm not sure what the details are here (maybe it can be handled with a single big runtime switch, if the offset is always constant on a given machine).

(Hm, now that I look I see that they're defined as virt_to_bus/bus_to_virt, which doesn't work for highmem at all; it would need to be phys.)

But I may have misinterpreted what he meant.
   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>