lkml.org 
[lkml]   [2013]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 04/15] KVM: MMU: flush tlb out of mmu lock when write-protect the sptes

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 its not an issue, but its so subtle that
> it should be improved.
>
> Can you add a fat comment on top of is_writeable_bit describing this?
> (and explain why is_writable_pte users do not make an assumption
> about (*).
>
> "Writeable bit of locklessly modifiable sptes might be cleared
> but TLBs not flushed: so whenever reading locklessly modifiable sptes
> you cannot assume TLBs are flushed".
>
> For example this one is unclear:
>
> if (!can_unsync && is_writable_pte(*sptep))
> goto set_pte;
> And:
>
> if (!is_writable_pte(spte) &&
> !(pt_protect && spte_is_locklessly_modifiable(spte)))
> return false;
>
> This is safe because get_dirty_log/kvm_mmu_slot_remove_write_access are
> serialized by a single mutex (if there were two mutexes, it would not be
> safe). Can you add an assert to both
> kvm_mmu_slot_remove_write_access/kvm_vm_ioctl_get_dirty_log
> for (slots_lock) is locked, and explain?
>
> So just improve the comments please, thanks (no need to resend whole
> series).

Thank you very much for your time to review it and really appreciate
for you detailed the issue so clearly to me.

I will do it on the top of this patchset or after it is merged
(if it's possiable).






\
 
 \ /
  Last update: 2013-11-14 07:01    [W:0.685 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site