linux-kernel - Re: [PATCH v2 1/7] swiotlb: Make io_tlb_end a physical address instead of a virtual one

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] [day] [month] [year] [list]

Date:	Fri, 19 Oct 2012 09:21:41 -0700
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Konrad Rzeszutek Wilk <konrad@...nel.org>,
	Hillf Danton <dhillf@...il.com>, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, rob@...dley.net,
	akpm@...ux-foundation.org, joerg.roedel@....com,
	bhelgaas@...gle.com, shuahkhan@...il.com,
	fujita.tomonori@....ntt.co.jp, linux-kernel@...r.kernel.org,
	x86@...nel.org
Subject: Re: [PATCH v2 1/7] swiotlb: Make io_tlb_end a physical address instead
 of a virtual one

On 10/19/2012 07:18 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 18, 2012 at 08:53:33AM -0700, Alexander Duyck wrote:
>> end to be physical instead of virtual.  I reviewed the code and realized
>> that I wasn't saving anything by removing it since the overall code was
>> larger as a result so I just converted it to a physical address.  There
>> are no users of io_tlb_end that are accessing it as a virtual value so
>> all I did is just change it to a physical one and drop the virt_to_phys
>> calls that were made on it.  If I am not mistaken by the second patch
>> the is_swiotlb_buffer call is literally what you have described above. 
>> Here is the snippet from the 2nd patch:
>>
>> static int is_swiotlb_buffer(phys_addr_t paddr)
>>  {
>> -	return paddr >= virt_to_phys(io_tlb_start) && paddr < io_tlb_end;
>> +	return paddr >= io_tlb_start && paddr < io_tlb_end;
>>  }
>>
>>
>> As far as the number of patches I decided to do this incrementally
>> instead of trying to do it all at once.  That way it is clearer to the
>> reviewer what I am doing in each step and it can be more easily bisected
>> in case I messed up somewhere.  If you want fewer patches I can do that
>> but I don't see the point in combining patches since they are all just
>> going to result in the same total change anyway.
> No that is OK. BTW, I did a testing of your V2 patches with Xen-SWIOTLB
> and they worked. But it was on non-debug env. The debug one does such
> evil things as make the initial domain memory start at the end physical
> memory and put the underlaying MFNs (machine frame numbers, the real
> physical frames) in reverse order. So for example pfn 100, ends up being
> mfn 0xf00d, and pfn 101 ends up being oxf00c.

Glad to hear they are working under Xen.  As I said I am pretty sure if
it was working before it should still be working after these changes
since the only difference is that instead of working with virtual
addresses and having to call virt_to_phys to get the pseudo-physical
addresses we are just working with the pseudo-physical addresses directly.

Thanks,

Alex




--
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/