[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F82EB3B.8000204@linux.vnet.ibm.com>
Date: Mon, 09 Apr 2012 21:59:23 +0800
From: Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
To: Avi Kivity <avi@...hat.com>
CC: Xiao Guangrong <xiaoguangrong.eric@...il.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, KVM <kvm@...r.kernel.org>
Subject: Re: [PATCH 00/13] KVM: MMU: fast page fault
On 04/09/2012 09:20 PM, Avi Kivity wrote:
> On 04/06/2012 08:24 AM, Xiao Guangrong wrote:
>>
>> Foolish me, i should be crazy. Sorry for my mistake. :(
>>
>> Unfortunately, it can not work, we can not get a stable gfn from gpte or
>> sp->gfns[]. For example:
>>
>> beginning:
>> Gpte = Gfn1
>> gfn_to_pfn(Gfn1) = Pfn
>> Spte = Pfn
>> Gfn1 is write-free
>> Gfn2 is write-protected
>>
>>
>> VCPU 0 VCPU 1 VCPU 2
>>
>> fault on gpte
>> fast page fault path:
>> set Spte.fast_pf
>> get Gfn1 from Gpte/sp->gfns[]
>> if (Gfn1 is writable)
>> Pfn is swapped out:
>> Spte = 0
>> Gpte is modified to Gfn2,
>> and Pfn is realloced and remapped
>> to Gfn2, so:
>> Spte = Pfn
>>
>> fast page fault path:
>> set Spte.fast_pf
>>
>> cmpxchg Spte+w
>> OOPS!!!
>> <we see Spte is not changed and
>> happily make it writable, so gfn2 can be writable>
>>
>> It seems only a unique identification can prevent this. :(
>>
>
> Ouch.
>
> What about restricting this to role.direct=1? Then gfn is stable?
>
Yes.
The gfn of direct sp is stable since it is calculated by sp->gfn which is
independent with gpte.
--
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/
Powered by blists - more mailing lists