Re: [PATCH v2 3/10] KVM: MMU: fix direct sp's access corruptted

From: Avi Kivity
Date: Tue Jun 29 2010 - 03:06:51 EST

On 06/29/2010 04:17 AM, Xiao Guangrong wrote:

If B is writeable-and-dirty, then it's D bit is already set, and we
don't need to do anything.

If B is writeable-and-clean, then we'll have an spte pointing to a
read-only sp, so we'll get a write fault on access and an opportunity to
set the D bit.

Sorry, a typo in my reply, i mean mapping A and B both are writable-and-clean,
while A occurs write-#PF, we should change A's spte map to writable sp, if we
only update the spte in writable-and-clean sp(form readonly to writable), the B's
D bit will miss set.


We need to update something to notice this:

- FNAME(fetch)() to replace the spte
- FNAME(walk_addr)() to invalidate the spte

I think FNAME(walk_addr) is the right place, we're updating the gpte, so we should update the spte at the same time, just like a guest write. But that will be expensive (there could be many sptes, so we have to call kvm_mmu_pte_write()), so perhaps FNAME(fetch) is easier.

We have now

if (is_shadow_present_pte(*sptep) && !is_large_pte(*sptep))

So we need to add a check, if sp->role.access doesn't match pt_access & pte_access, we need to get a new sp with the correct access (can only change read->write).

Anyway, i think we should re-intall the mapping when the state is
changed. :-(

When the gpte is changed from read-only to writeable or from clean to
dirty, we need to update the spte, yes. But that's true for other sptes
as well, not just large gptes.

I think the indirect sp is not hurt by this bug since for the indirect sp, the access
just form its upper-level, and the D bit is only in the last level, when we change the
pte's access, is not affect its sp's access.

But for direct sp, the sp's access is form all level. and different mapping that not share
the last mapping page will have the same last sp.


I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at