Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Hi Guangrong, Thanks a lot! I will reopen a new discussion next time. Does that means once the level 1 guest page table entry is modified, the host should make a decision in page fault handler whether the page sync or unsync? My question is that since all level 1 guest page tables are writable, when the entry in the page table is modified. there is no page fault will happen, how can the mmu_need_write_protect to be called to make whether sync or unsync decision? Thanks for your time! Best Wishes, Yaohui On Wed, Mar 26, 2014 at 1:07 AM, Xiao Guangrong wrote: > On 03/26/2014 12:40 PM, Hu Yaohui wrote: >> Hi all, >> I hope you have a good day! >> I have debugged the code myself. I have called dump_stack() in >> function "__kvm_unsync_page" >> and function "invlpg". Actually every time before invlpg is called, >> the page fault handled will call "__kvm_unsync_page" before invlpg to >> mark the specified sp as unsynced. (correct me if I am wrong). I am >> wondering why there is a page fault. AFAIK when calling flush_tlb_page >> in the guest os. it will issue invlpg instruction directly, I did not >> see any operation which could always cause the page fault.I would >> really appreciate if if someone could shed me some lights on it. >> Thanks for your time! > > Page fault is used to map a page into guest and set the proper permission > on for it so this is the right place to make decision if the page need be > writable. > > Tlb flush is used when guest wants to have a clean tlb so that host syncs the > unsync page tables when it is happing. > -- 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
On 03/26/2014 12:40 PM, Hu Yaohui wrote: > Hi all, > I hope you have a good day! > I have debugged the code myself. I have called dump_stack() in > function "__kvm_unsync_page" > and function "invlpg". Actually every time before invlpg is called, > the page fault handled will call "__kvm_unsync_page" before invlpg to > mark the specified sp as unsynced. (correct me if I am wrong). I am > wondering why there is a page fault. AFAIK when calling flush_tlb_page > in the guest os. it will issue invlpg instruction directly, I did not > see any operation which could always cause the page fault.I would > really appreciate if if someone could shed me some lights on it. > Thanks for your time! Page fault is used to map a page into guest and set the proper permission on for it so this is the right place to make decision if the page need be writable. Tlb flush is used when guest wants to have a clean tlb so that host syncs the unsync page tables when it is happing. -- 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
A suggestion: please send a new mail to ask question, especially, when your question is not related to the patches, so that others will probably discover the topic and join the discussion. On 03/26/2014 12:25 AM, Hu Yaohui wrote: > Hi Guangrong, > Since you have written in the kvm/mmu.txt. > > > unsync: > If true, then the translations in this page may not match the guest's > translation. This is equivalent to the state of the tlb when a pte is > changed but before the tlb entry is flushed. Accordingly, unsync ptes > are synchronized when the guest executes invlpg or flushes its tlb by > other means. Valid for leaf pages. > > > > This make sense to me, my question is when those unsync bits will be > set? When the guest writes to the level 1 guest page tables, it will > not cause a page fault. Those unsync bit is unlikely to be set when > the entry is modified. (correct me if I am wrong). The bit is set in mmu_need_write_protect() where the host makes decision if the page need to be write-protected (!unsync) or to be unsynced. -- 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Hi all,
I hope you have a good day!
I have debugged the code myself. I have called dump_stack() in
function "__kvm_unsync_page"
and function "invlpg". Actually every time before invlpg is called,
the page fault handled will call "__kvm_unsync_page" before invlpg to
mark the specified sp as unsynced. (correct me if I am wrong). I am
wondering why there is a page fault. AFAIK when calling flush_tlb_page
in the guest os. it will issue invlpg instruction directly, I did not
see any operation which could always cause the page fault.I would
really appreciate if if someone could shed me some lights on it.
Thanks for your time!
Best Wishes,
Yaohui
On Tue, Mar 25, 2014 at 12:25 PM, Hu Yaohui wrote:
> Hi Guangrong,
> Since you have written in the kvm/mmu.txt.
>
>
> unsync:
> If true, then the translations in this page may not match the guest's
> translation. This is equivalent to the state of the tlb when a pte is
> changed but before the tlb entry is flushed. Accordingly, unsync ptes
> are synchronized when the guest executes invlpg or flushes its tlb by
> other means. Valid for leaf pages.
>
>
>
> This make sense to me, my question is when those unsync bits will be
> set? When the guest writes to the level 1 guest page tables, it will
> not cause a page fault. Those unsync bit is unlikely to be set when
> the entry is modified. (correct me if I am wrong).
>
>
> static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva)
> {
> ...
> for_each_shadow_entry(vcpu, gva, iterator) {
> level = iterator.level;
> sptep = iterator.sptep;
>
> sp = page_header(__pa(sptep));
> if (is_last_spte(*sptep, level)) {
> int offset, shift;
>
> if (!sp->unsync)
> break;
> ...
>
> When guest called invlpg, kvm invlpg will navigate to to the last
> level, if the sp->unsync is not set to 1, since the initial value is
> zero. it will just break. It's not straight forward to me that the
> specified sp will be synced with the guest page table.
>
> I think I have missed something or misunderstood the whole mechanism,
> I would really appreciate it if you could shed some lights on that.
>
> Best Wishes,
> Yaohui Hu
>
> On Mon, Mar 10, 2014 at 10:01 AM, Xiao Guangrong
> wrote:
>> This patchset is splited from my previous patchset:
>> [PATCH v3 00/15] KVM: MMU: locklessly write-protect
>> that can be found at:
>> https://lkml.org/lkml/2013/10/23/265
>>
>> Changelog v4 :
>> - add more comments for patch 5 and thank for Marcelo's review
>>
>> Xiao Guangrong (5):
>> Revert "KVM: Simplify kvm->tlbs_dirty handling"
>> KVM: MMU: properly check last spte in fast_page_fault()
>> KVM: MMU: lazily drop large spte
>> KVM: MMU: flush tlb if the spte can be locklessly modified
>> KVM: MMU: flush tlb out of mmu lock when write-protect the sptes
>>
>> arch/x86/kvm/mmu.c | 72
>> ++
>> arch/x86/kvm/mmu.h | 14 +
>> arch/x86/kvm/paging_tmpl.h | 7 ++---
>> arch/x86/kvm/x86.c | 20 ++---
>> include/linux/kvm_host.h | 4 +--
>> virt/kvm/kvm_main.c| 5 +++-
>> 6 files changed, 85 insertions(+), 37 deletions(-)
>>
>> --
>> 1.8.1.4
>>
>> --
>> 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 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Hi Guangrong,
Since you have written in the kvm/mmu.txt.
unsync:
If true, then the translations in this page may not match the guest's
translation. This is equivalent to the state of the tlb when a pte is
changed but before the tlb entry is flushed. Accordingly, unsync ptes
are synchronized when the guest executes invlpg or flushes its tlb by
other means. Valid for leaf pages.
This make sense to me, my question is when those unsync bits will be
set? When the guest writes to the level 1 guest page tables, it will
not cause a page fault. Those unsync bit is unlikely to be set when
the entry is modified. (correct me if I am wrong).
static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva)
{
...
for_each_shadow_entry(vcpu, gva, iterator) {
level = iterator.level;
sptep = iterator.sptep;
sp = page_header(__pa(sptep));
if (is_last_spte(*sptep, level)) {
int offset, shift;
if (!sp->unsync)
break;
...
When guest called invlpg, kvm invlpg will navigate to to the last
level, if the sp->unsync is not set to 1, since the initial value is
zero. it will just break. It's not straight forward to me that the
specified sp will be synced with the guest page table.
I think I have missed something or misunderstood the whole mechanism,
I would really appreciate it if you could shed some lights on that.
Best Wishes,
Yaohui Hu
On Mon, Mar 10, 2014 at 10:01 AM, Xiao Guangrong
wrote:
> This patchset is splited from my previous patchset:
> [PATCH v3 00/15] KVM: MMU: locklessly write-protect
> that can be found at:
> https://lkml.org/lkml/2013/10/23/265
>
> Changelog v4 :
> - add more comments for patch 5 and thank for Marcelo's review
>
> Xiao Guangrong (5):
> Revert "KVM: Simplify kvm->tlbs_dirty handling"
> KVM: MMU: properly check last spte in fast_page_fault()
> KVM: MMU: lazily drop large spte
> KVM: MMU: flush tlb if the spte can be locklessly modified
> KVM: MMU: flush tlb out of mmu lock when write-protect the sptes
>
> arch/x86/kvm/mmu.c | 72
> ++
> arch/x86/kvm/mmu.h | 14 +
> arch/x86/kvm/paging_tmpl.h | 7 ++---
> arch/x86/kvm/x86.c | 20 ++---
> include/linux/kvm_host.h | 4 +--
> virt/kvm/kvm_main.c| 5 +++-
> 6 files changed, 85 insertions(+), 37 deletions(-)
>
> --
> 1.8.1.4
>
> --
> 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 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Il 25/03/2014 04:29, Xiao Guangrong ha scritto: Ping.. Hi Xiao, I'll look at these patches soon. I plan to merge them for 3.16. Paolo On 03/10/2014 10:01 PM, Xiao Guangrong wrote: This patchset is splited from my previous patchset: [PATCH v3 00/15] KVM: MMU: locklessly write-protect that can be found at: https://lkml.org/lkml/2013/10/23/265 Changelog v4 : - add more comments for patch 5 and thank for Marcelo's review Xiao Guangrong (5): Revert "KVM: Simplify kvm->tlbs_dirty handling" KVM: MMU: properly check last spte in fast_page_fault() KVM: MMU: lazily drop large spte KVM: MMU: flush tlb if the spte can be locklessly modified KVM: MMU: flush tlb out of mmu lock when write-protect the sptes arch/x86/kvm/mmu.c | 72 ++ arch/x86/kvm/mmu.h | 14 + arch/x86/kvm/paging_tmpl.h | 7 ++--- arch/x86/kvm/x86.c | 20 ++--- include/linux/kvm_host.h | 4 +-- virt/kvm/kvm_main.c| 5 +++- 6 files changed, 85 insertions(+), 37 deletions(-) -- 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Il 25/03/2014 04:29, Xiao Guangrong ha scritto: Ping.. Hi Xiao, I'll look at these patches soon. I plan to merge them for 3.16. Paolo On 03/10/2014 10:01 PM, Xiao Guangrong wrote: This patchset is splited from my previous patchset: [PATCH v3 00/15] KVM: MMU: locklessly write-protect that can be found at: https://lkml.org/lkml/2013/10/23/265 Changelog v4 : - add more comments for patch 5 and thank for Marcelo's review Xiao Guangrong (5): Revert KVM: Simplify kvm-tlbs_dirty handling KVM: MMU: properly check last spte in fast_page_fault() KVM: MMU: lazily drop large spte KVM: MMU: flush tlb if the spte can be locklessly modified KVM: MMU: flush tlb out of mmu lock when write-protect the sptes arch/x86/kvm/mmu.c | 72 ++ arch/x86/kvm/mmu.h | 14 + arch/x86/kvm/paging_tmpl.h | 7 ++--- arch/x86/kvm/x86.c | 20 ++--- include/linux/kvm_host.h | 4 +-- virt/kvm/kvm_main.c| 5 +++- 6 files changed, 85 insertions(+), 37 deletions(-) -- 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Hi Guangrong,
Since you have written in the kvm/mmu.txt.
quote
unsync:
If true, then the translations in this page may not match the guest's
translation. This is equivalent to the state of the tlb when a pte is
changed but before the tlb entry is flushed. Accordingly, unsync ptes
are synchronized when the guest executes invlpg or flushes its tlb by
other means. Valid for leaf pages.
/quote
This make sense to me, my question is when those unsync bits will be
set? When the guest writes to the level 1 guest page tables, it will
not cause a page fault. Those unsync bit is unlikely to be set when
the entry is modified. (correct me if I am wrong).
code
static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva)
{
...
for_each_shadow_entry(vcpu, gva, iterator) {
level = iterator.level;
sptep = iterator.sptep;
sp = page_header(__pa(sptep));
if (is_last_spte(*sptep, level)) {
int offset, shift;
if (!sp-unsync)
break;
...
/code
When guest called invlpg, kvm invlpg will navigate to to the last
level, if the sp-unsync is not set to 1, since the initial value is
zero. it will just break. It's not straight forward to me that the
specified sp will be synced with the guest page table.
I think I have missed something or misunderstood the whole mechanism,
I would really appreciate it if you could shed some lights on that.
Best Wishes,
Yaohui Hu
On Mon, Mar 10, 2014 at 10:01 AM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
This patchset is splited from my previous patchset:
[PATCH v3 00/15] KVM: MMU: locklessly write-protect
that can be found at:
https://lkml.org/lkml/2013/10/23/265
Changelog v4 :
- add more comments for patch 5 and thank for Marcelo's review
Xiao Guangrong (5):
Revert KVM: Simplify kvm-tlbs_dirty handling
KVM: MMU: properly check last spte in fast_page_fault()
KVM: MMU: lazily drop large spte
KVM: MMU: flush tlb if the spte can be locklessly modified
KVM: MMU: flush tlb out of mmu lock when write-protect the sptes
arch/x86/kvm/mmu.c | 72
++
arch/x86/kvm/mmu.h | 14 +
arch/x86/kvm/paging_tmpl.h | 7 ++---
arch/x86/kvm/x86.c | 20 ++---
include/linux/kvm_host.h | 4 +--
virt/kvm/kvm_main.c| 5 +++-
6 files changed, 85 insertions(+), 37 deletions(-)
--
1.8.1.4
--
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 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Hi all,
I hope you have a good day!
I have debugged the code myself. I have called dump_stack() in
function __kvm_unsync_page
and function invlpg. Actually every time before invlpg is called,
the page fault handled will call __kvm_unsync_page before invlpg to
mark the specified sp as unsynced. (correct me if I am wrong). I am
wondering why there is a page fault. AFAIK when calling flush_tlb_page
in the guest os. it will issue invlpg instruction directly, I did not
see any operation which could always cause the page fault.I would
really appreciate if if someone could shed me some lights on it.
Thanks for your time!
Best Wishes,
Yaohui
On Tue, Mar 25, 2014 at 12:25 PM, Hu Yaohui loki2...@gmail.com wrote:
Hi Guangrong,
Since you have written in the kvm/mmu.txt.
quote
unsync:
If true, then the translations in this page may not match the guest's
translation. This is equivalent to the state of the tlb when a pte is
changed but before the tlb entry is flushed. Accordingly, unsync ptes
are synchronized when the guest executes invlpg or flushes its tlb by
other means. Valid for leaf pages.
/quote
This make sense to me, my question is when those unsync bits will be
set? When the guest writes to the level 1 guest page tables, it will
not cause a page fault. Those unsync bit is unlikely to be set when
the entry is modified. (correct me if I am wrong).
code
static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva)
{
...
for_each_shadow_entry(vcpu, gva, iterator) {
level = iterator.level;
sptep = iterator.sptep;
sp = page_header(__pa(sptep));
if (is_last_spte(*sptep, level)) {
int offset, shift;
if (!sp-unsync)
break;
...
/code
When guest called invlpg, kvm invlpg will navigate to to the last
level, if the sp-unsync is not set to 1, since the initial value is
zero. it will just break. It's not straight forward to me that the
specified sp will be synced with the guest page table.
I think I have missed something or misunderstood the whole mechanism,
I would really appreciate it if you could shed some lights on that.
Best Wishes,
Yaohui Hu
On Mon, Mar 10, 2014 at 10:01 AM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
This patchset is splited from my previous patchset:
[PATCH v3 00/15] KVM: MMU: locklessly write-protect
that can be found at:
https://lkml.org/lkml/2013/10/23/265
Changelog v4 :
- add more comments for patch 5 and thank for Marcelo's review
Xiao Guangrong (5):
Revert KVM: Simplify kvm-tlbs_dirty handling
KVM: MMU: properly check last spte in fast_page_fault()
KVM: MMU: lazily drop large spte
KVM: MMU: flush tlb if the spte can be locklessly modified
KVM: MMU: flush tlb out of mmu lock when write-protect the sptes
arch/x86/kvm/mmu.c | 72
++
arch/x86/kvm/mmu.h | 14 +
arch/x86/kvm/paging_tmpl.h | 7 ++---
arch/x86/kvm/x86.c | 20 ++---
include/linux/kvm_host.h | 4 +--
virt/kvm/kvm_main.c| 5 +++-
6 files changed, 85 insertions(+), 37 deletions(-)
--
1.8.1.4
--
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 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
A suggestion: please send a new mail to ask question, especially, when your question is not related to the patches, so that others will probably discover the topic and join the discussion. On 03/26/2014 12:25 AM, Hu Yaohui wrote: Hi Guangrong, Since you have written in the kvm/mmu.txt. quote unsync: If true, then the translations in this page may not match the guest's translation. This is equivalent to the state of the tlb when a pte is changed but before the tlb entry is flushed. Accordingly, unsync ptes are synchronized when the guest executes invlpg or flushes its tlb by other means. Valid for leaf pages. /quote This make sense to me, my question is when those unsync bits will be set? When the guest writes to the level 1 guest page tables, it will not cause a page fault. Those unsync bit is unlikely to be set when the entry is modified. (correct me if I am wrong). The bit is set in mmu_need_write_protect() where the host makes decision if the page need to be write-protected (!unsync) or to be unsynced. -- 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
On 03/26/2014 12:40 PM, Hu Yaohui wrote: Hi all, I hope you have a good day! I have debugged the code myself. I have called dump_stack() in function __kvm_unsync_page and function invlpg. Actually every time before invlpg is called, the page fault handled will call __kvm_unsync_page before invlpg to mark the specified sp as unsynced. (correct me if I am wrong). I am wondering why there is a page fault. AFAIK when calling flush_tlb_page in the guest os. it will issue invlpg instruction directly, I did not see any operation which could always cause the page fault.I would really appreciate if if someone could shed me some lights on it. Thanks for your time! Page fault is used to map a page into guest and set the proper permission on for it so this is the right place to make decision if the page need be writable. Tlb flush is used when guest wants to have a clean tlb so that host syncs the unsync page tables when it is happing. -- 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Hi Guangrong, Thanks a lot! I will reopen a new discussion next time. Does that means once the level 1 guest page table entry is modified, the host should make a decision in page fault handler whether the page sync or unsync? My question is that since all level 1 guest page tables are writable, when the entry in the page table is modified. there is no page fault will happen, how can the mmu_need_write_protect to be called to make whether sync or unsync decision? Thanks for your time! Best Wishes, Yaohui On Wed, Mar 26, 2014 at 1:07 AM, Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote: On 03/26/2014 12:40 PM, Hu Yaohui wrote: Hi all, I hope you have a good day! I have debugged the code myself. I have called dump_stack() in function __kvm_unsync_page and function invlpg. Actually every time before invlpg is called, the page fault handled will call __kvm_unsync_page before invlpg to mark the specified sp as unsynced. (correct me if I am wrong). I am wondering why there is a page fault. AFAIK when calling flush_tlb_page in the guest os. it will issue invlpg instruction directly, I did not see any operation which could always cause the page fault.I would really appreciate if if someone could shed me some lights on it. Thanks for your time! Page fault is used to map a page into guest and set the proper permission on for it so this is the right place to make decision if the page need be writable. Tlb flush is used when guest wants to have a clean tlb so that host syncs the unsync page tables when it is happing. -- 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Ping.. On 03/10/2014 10:01 PM, Xiao Guangrong wrote: > This patchset is splited from my previous patchset: > [PATCH v3 00/15] KVM: MMU: locklessly write-protect > that can be found at: > https://lkml.org/lkml/2013/10/23/265 > > Changelog v4 : > - add more comments for patch 5 and thank for Marcelo's review > > Xiao Guangrong (5): > Revert "KVM: Simplify kvm->tlbs_dirty handling" > KVM: MMU: properly check last spte in fast_page_fault() > KVM: MMU: lazily drop large spte > KVM: MMU: flush tlb if the spte can be locklessly modified > KVM: MMU: flush tlb out of mmu lock when write-protect the sptes > > arch/x86/kvm/mmu.c | 72 > ++ > arch/x86/kvm/mmu.h | 14 + > arch/x86/kvm/paging_tmpl.h | 7 ++--- > arch/x86/kvm/x86.c | 20 ++--- > include/linux/kvm_host.h | 4 +-- > virt/kvm/kvm_main.c| 5 +++- > 6 files changed, 85 insertions(+), 37 deletions(-) > -- 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/
Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Ping.. On 03/10/2014 10:01 PM, Xiao Guangrong wrote: This patchset is splited from my previous patchset: [PATCH v3 00/15] KVM: MMU: locklessly write-protect that can be found at: https://lkml.org/lkml/2013/10/23/265 Changelog v4 : - add more comments for patch 5 and thank for Marcelo's review Xiao Guangrong (5): Revert KVM: Simplify kvm-tlbs_dirty handling KVM: MMU: properly check last spte in fast_page_fault() KVM: MMU: lazily drop large spte KVM: MMU: flush tlb if the spte can be locklessly modified KVM: MMU: flush tlb out of mmu lock when write-protect the sptes arch/x86/kvm/mmu.c | 72 ++ arch/x86/kvm/mmu.h | 14 + arch/x86/kvm/paging_tmpl.h | 7 ++--- arch/x86/kvm/x86.c | 20 ++--- include/linux/kvm_host.h | 4 +-- virt/kvm/kvm_main.c| 5 +++- 6 files changed, 85 insertions(+), 37 deletions(-) -- 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/
[PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
This patchset is splited from my previous patchset: [PATCH v3 00/15] KVM: MMU: locklessly write-protect that can be found at: https://lkml.org/lkml/2013/10/23/265 Changelog v4 : - add more comments for patch 5 and thank for Marcelo's review Xiao Guangrong (5): Revert "KVM: Simplify kvm->tlbs_dirty handling" KVM: MMU: properly check last spte in fast_page_fault() KVM: MMU: lazily drop large spte KVM: MMU: flush tlb if the spte can be locklessly modified KVM: MMU: flush tlb out of mmu lock when write-protect the sptes arch/x86/kvm/mmu.c | 72 ++ arch/x86/kvm/mmu.h | 14 + arch/x86/kvm/paging_tmpl.h | 7 ++--- arch/x86/kvm/x86.c | 20 ++--- include/linux/kvm_host.h | 4 +-- virt/kvm/kvm_main.c| 5 +++- 6 files changed, 85 insertions(+), 37 deletions(-) -- 1.8.1.4 -- 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/
[PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
This patchset is splited from my previous patchset: [PATCH v3 00/15] KVM: MMU: locklessly write-protect that can be found at: https://lkml.org/lkml/2013/10/23/265 Changelog v4 : - add more comments for patch 5 and thank for Marcelo's review Xiao Guangrong (5): Revert KVM: Simplify kvm-tlbs_dirty handling KVM: MMU: properly check last spte in fast_page_fault() KVM: MMU: lazily drop large spte KVM: MMU: flush tlb if the spte can be locklessly modified KVM: MMU: flush tlb out of mmu lock when write-protect the sptes arch/x86/kvm/mmu.c | 72 ++ arch/x86/kvm/mmu.h | 14 + arch/x86/kvm/paging_tmpl.h | 7 ++--- arch/x86/kvm/x86.c | 20 ++--- include/linux/kvm_host.h | 4 +-- virt/kvm/kvm_main.c| 5 +++- 6 files changed, 85 insertions(+), 37 deletions(-) -- 1.8.1.4 -- 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/
