On Aug 3, 2013, at 4:27 AM, Marcelo Tosatti <mtosa...@redhat.com> wrote:
> On Fri, Aug 02, 2013 at 11:42:19PM +0800, Xiao Guangrong wrote: >> >> On Aug 2, 2013, at 10:55 PM, Marcelo Tosatti <mtosa...@redhat.com> wrote: >> >>> On Tue, Jul 30, 2013 at 09:02:01PM +0800, Xiao Guangrong wrote: >>>> Currently, kvm zaps the large spte if write-protected is needed, the later >>>> read can fault on that spte. Actually, we can make the large spte readonly >>>> instead of making them un-present, the page fault caused by read access can >>>> be avoided >>>> >>>> The idea is from Avi: >>>> | As I mentioned before, write-protecting a large spte is a good idea, >>>> | since it moves some work from protect-time to fault-time, so it reduces >>>> | jitter. This removes the need for the return value. >>>> >>>> [ >>>> It has fixed the issue reported in 6b73a9606 by stopping fast page fault >>>> marking the large spte to writable >>>> ] >>> >>> Xiao, >>> >>> Can you please write a comment explaining why are the problems >>> with shadow vs large read-only sptes (can't recall anymore), >>> and then why it is now safe to do it. >> >> Hi Marcelo, >> >> Thanks for your review. Yes. The bug reported in 6b73a9606 is, in this >> patch, >> we mark the large spte as readonly when the pages are dirt logged and the >> readonly spte can be set to writable by fast page fault, but on that path, >> it failed >> to check dirty logging, so it will set the large spte to writable but only >> set the first >> page to the dirty bitmap. >> >> For example: >> >> 1): KVM maps 0 ~ 2M memory to guest which is pointed by SPTE and SPTE >> is writable. >> >> 2): KVM dirty log 0 ~ 2M, then set SPTE to readonly >> >> 3): fast page fault set SPTE to writable and set page 0 to the dirty bitmap. >> >> Then 4K ~ 2M memory is not dirty logged. > > Ok can you write a self contained summary of read-only large sptes (when > they are created, when destroyed, from which point they can't be created, > etc), and the interaction with shadow write protection and creation of > writeable sptes? > Its easy to get lost. Okay, will do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
