On 06/02/20 23:47, Mauro Carvalho Chehab wrote: >> >> But the two headers should be "CPU 0" and "CPU 1", and it's worth >> changing that while we're at it. Same for the table below. > > Ok. > > Maybe we could append the enclosed patch to this one. I suspect it would > visually be better. Looks good to me, thanks. Paolo > > Cheers, > Mauro > > --- > > diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst > index 428cb3412ecc..82322a4c9fde 100644 > --- a/Documentation/virt/kvm/locking.rst > +++ b/Documentation/virt/kvm/locking.rst > @@ -57,18 +57,18 @@ But we need carefully check these cases: > > The mapping from gfn to pfn may be changed since we can only ensure the pfn > is not changed during cmpxchg. This is a ABA problem, for example, below case > -will happen: > +will happen:: > > -At the beginning:: > + At the beginning: > > gpte = gfn1 > gfn1 is mapped to pfn1 on host > spte is the shadow page table entry corresponding with gpte and > spte = pfn1 > > - VCPU 0 VCPU0 > + On fast page fault path: > > -on fast page fault path:: > + CPU 0 CPU 1 > > old_spte = *spte; > pfn1 is swapped out: > @@ -80,6 +80,7 @@ on fast page fault path:: > gfn2 by the guest: > spte = pfn1; > > + > if (cmpxchg(spte, old_spte, old_spte+W) > mark_page_dirty(vcpu->kvm, gfn1) > OOPS!!! > @@ -107,16 +108,16 @@ spte is read-only and the Accessed bit has already been set since the > Accessed bit and Dirty bit can not be lost. > > But it is not true after fast page fault since the spte can be marked > -writable between reading spte and updating spte. Like below case: > +writable between reading spte and updating spte. Like below case:: > > -At the beginning:: > + At the beginning: > > spte.W = 0 > spte.Accessed = 1 > > - VCPU 0 VCPU0 > + CPU 0 CPU 1 > > -In mmu_spte_clear_track_bits():: > + In mmu_spte_clear_track_bits(): > > old_spte = *spte; > >
