On 02/26/2018 04:59 PM, Paolo Bonzini wrote:
On 26/02/2018 08:38, Xiao Guangrong wrote:
And i do not think the case can happen as we have called gfn_to_pfn()
to check if the gfn is MMIO (see if it exists in memeslots) before
mapping it into rmap. During it, the srcu prevents any memslot
to go away.
It cannot be freed, but it can return NULL the second time. RCU does not
guarantee that no change happen; if you want consistent reads you need to
read each pointer at most once.
That is the reason why invalid memslot comes in.
KVM sets the memslot as invalid first then mmu will see the invalid slot
rather than NULL. A new call of #PF handler will see 'invalid' bit is set
that make the handler directly exit.
How can this be guaranteed? First, KVM_MEMSLOT_INVALID is not even set
under any lock.
Yes, so the user can see either the valid memslot or the invalid memslot
, under both cases the memslot can be be NULL, that's okay.
Second, that doesn't fix the problem that KVM accesses
the memslots array twice---the first before KVM_MEMSLOT_INVALID is set,
and the second time after the new array has been installed.
The user can not go across between the invalid memslot and new installed memslot, as
the user should hold the srcu lock during its operation and __kvm_set_memory_region()
always waits a SRCU grace period for each status update for the memslot, i.e,
__kvm_set_memory_region() vCPU 0
set memslot invalid
srcu-lock
gfn_to_pfn
add gfn to rmap
srcu-unlock
synchronize_srcu_expedited()
srcu-lock
case 1: see the memslot is invalid, then directly exits
delete the memslot or add new memslot
case 2: see the memslot is gone treat it as mmio OR
a normal memslot
synchronize_srcu_expedited()
