On Fri, Nov 15, 2013 at 03:09:13PM +0800, Xiao Guangrong wrote:
> On 11/15/2013 02:39 AM, Marcelo Tosatti wrote:
> > On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
> >>
> >> Hi Marcelo,
> >>
> >> On 11/14/2013 08:36 AM, Marcelo Tosatti wrote:
> >>
> >>>
> >>> Any code location whic
On 11/15/2013 02:39 AM, Marcelo Tosatti wrote:
> On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
>>
>> Hi Marcelo,
>>
>> On 11/14/2013 08:36 AM, Marcelo Tosatti wrote:
>>
>>>
>>> Any code location which reads the writable bit in the spte and assumes if
>>> its not
>>> set, that the
On Thu, Nov 14, 2013 at 01:15:24PM +0800, Xiao Guangrong wrote:
>
> Hi Marcelo,
>
> On 11/14/2013 08:36 AM, Marcelo Tosatti wrote:
>
> >
> > Any code location which reads the writable bit in the spte and assumes if
> > its not
> > set, that the translation which the spte refers to is not cache
Hi Marcelo,
On 11/14/2013 08:36 AM, Marcelo Tosatti wrote:
>
> Any code location which reads the writable bit in the spte and assumes if its
> not
> set, that the translation which the spte refers to is not cached in a
> remote CPU's TLB can become buggy. (*)
>
> It might be the case that now
On Wed, Oct 23, 2013 at 09:29:22PM +0800, Xiao Guangrong wrote:
> Now we can flush all the TLBs out of the mmu lock without TLB corruption when
> write-proect the sptes, it is because:
> - we have marked large sptes readonly instead of dropping them that means we
> just change the spte from writa
Now we can flush all the TLBs out of the mmu lock without TLB corruption when
write-proect the sptes, it is because:
- we have marked large sptes readonly instead of dropping them that means we
just change the spte from writable to readonly so that we only need to care
the case of changing spte
6 matches
Mail list logo