linux-kernel - Re: [PATCH 00 of 14] swiotlb/x86: lay groundwork for xen dom0 use of swiotlb

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]

Date:	Thu, 18 Dec 2008 01:56:01 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	jeremy@...p.org
Cc:	fujita.tomonori@....ntt.co.jp, mingo@...e.hu,
	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
	x86@...nel.org, ian.campbell@...rix.com, jbeulich@...ell.com,
	joerg.roedel@....com
Subject: Re: [PATCH 00 of 14] swiotlb/x86: lay groundwork for xen dom0 use
 of swiotlb

On Wed, 17 Dec 2008 08:31:43 -0800
Jeremy Fitzhardinge <jeremy@...p.org> wrote:

> > I think that the whole patchset is against the swiotlb design. swiotlb
> > is designed to be used as a library. Each architecture implements the
> > own swiotlb by using swiotlb library
> > (e.g. arch/x86/kernel/pci-swiotlb_64.c).
> >   
> 
> The whole patchset?  The bulk of the changes to lib/swiotlb.c are 
> relatively minor to remove the unwarranted assumptions it is making in 
> the face of a new user.  They will have no effect on other existing 
> users, including non-Xen x86 builds.
> 
> If you have specific objections we can discuss those, but I don't think 
> there's anything fundamentally wrong with making lib/swiotlb.c a bit 
> more generically useful.

Sorry, but the highmem support is not generically useful.

I'm especially against the highmem support. As you said, the rest
looks fine but if you go with pci-swiotlb_32.c, I think that you don't
need the most of them.


> > For example, adding the following code (9/14) for just Xen that the
> > majority of swiotbl users (x86_64 and IA64) don't need to the library
> > is against the design.
> >   
> 
> If the architecture doesn't support highmem then this code will compile 
> to nothing - PageHighMem() will always evaluate to 0.  It will therefore 

I'm not talking about it will be complied or not. As I wrote in
another mail, I'm talking about the maintainability and readability of
the common library.


> have zero effect on the code generated for IA64 or x86-64.  This is not 
> really a Xen-specific change, but a result of adding swiotlb support for 
> i386.  Other architectures which support a notion of highmem would also 
> need this code if they wanted to use swiotlb.

Can you be more specific? What architecture is plan to use highmem
support in swiotlb?
--
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/