On 12/15/2015 05:03 PM, Xiao Guangrong wrote:
On 12/15/2015 04:11 PM, Kai Huang wrote:
On 12/01/2015 02:26 AM, Xiao Guangrong wrote:
The page fault caused by write access on the write tracked page can not
be fixed, it always need to be emulated. page_fault_handle_page_track()
is the fast path we introduce here to skip holding mmu-lock and shadow
page table walking
Why can it be out side of mmu-lock? Is it OK that some other thread
removes tracking of this page
simultaneously? Shall we assuming the emulation code should handle
this case?
What your mentioned is the worst case, if that happen the vcpu will spend
longer time to emulate the access rather then retry it. It is bad but
it is
the rare contention. It is worth speeding up the common / most case.
My concern is when this case happen, whether emulating the access is
still the right behavior, you know, after other thread removed the GFN
from tracking..
And as the notifier's track_write call back will be called in the
emulating code, won't there be problem if the GFN has been removed from
tracking by other thread?
Thanks,
-Kai
Even it works for write protection, is it OK for other purpose
tracking (as your tracking framework
can be extended for other purpose)?
We only need to make sure that no track event is lost, i.e, we can not
skip the case that the index is changed from 0 to 1.
If we see index is 0, the vcpu can hold the mmu-lock and go to slow path
anyway so no track event will be lost.
However, if the page table is not present, it is worth making the page
table entry present and readonly to make the read access happy
It's fine for tracking write from guest. But what if I want to track
every read from guest?
Probably I am exaggerating :)
Then we do not go to the real page fault handler, just keep the shadow
page entry non-present.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
