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]

Message-ID: <4A143885.1050502@goop.org>
Date:	Wed, 20 May 2009 10:06:13 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ian Campbell <ijc@...lion.org.uk>
CC:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>, mingo@...e.hu,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	xen-devel@...ts.xensource.com, gregkh@...e.de, okir@...e.de,
	Becky Bruce <beckyb@...nel.crashing.org>
Subject: 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
--
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/