linux-kernel - Re: [PATCH] kvm mmu: reduce 50% memory usage

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

Date:	Fri, 30 Apr 2010 13:00:25 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Lai Jiangshan <laijs@...fujitsu.com>
CC:	Marcelo Tosatti <mtosatti@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>, kvm@...r.kernel.org
Subject: Re: [PATCH] kvm mmu: reduce 50% memory usage

On 04/30/2010 11:54 AM, Lai Jiangshan wrote:
> Avi Kivity wrote:
>    
>> On 04/30/2010 05:25 AM, Lai Jiangshan wrote:
>>      
>>>        
>>>> It's unrelated to TDP, same issue with shadow.  I think the calculation
>>>> is correct.  For example the 4th spte for a level=2 page will yield
>>>> gfn=4*512.
>>>>
>>>>          
>>> Avi, Marcelo
>>> Thank you very much.
>>>
>>> The calculation I used is correct.
>>>
>>>        
>> Yes.  btw, can you update the patch to also correct mmu.txt?
>>      
> The corresponding content in mmu.txt are:
>    role.direct:
>      If set, leaf sptes reachable from this page are for a linear range.
>      Examples include real mode translation, large guest pages backed by small
>      host pages, and gpa->hpa translations when NPT or EPT is active.
>      The linear range starts at (gfn<<  PAGE_SHIFT) and its size is determined
>      by role.level (2MB for first level, 1GB for second level, 0.5TB for third
>      level, 256TB for fourth level)
>      If clear, this page corresponds to a guest page table denoted by the gfn
>      field.
>
>    gfn:
>      Either the guest page table containing the translations shadowed by this
>      page, or the base page frame for linear translations.  See role.direct.
>
> These are correct. My patch is fully base on this document.
> I think it is not need to be fixed.
>
> Did I miss something?
>
>    

sp->gfns can now be NULL, so the documentation of this field needs to be 
updated.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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