| Message ID | 50AAC7CE.2050506@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Nov 20, 2012 at 07:59:10AM +0800, Xiao Guangrong wrote: > Currently, reexecute_instruction refused to retry all instructions. If > nested npt is used, the emulation may be caused by shadow page, it can > be fixed by dropping the shadow page > > Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> > --- > arch/x86/kvm/x86.c | 14 ++++++++------ > 1 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 7be8452..5fe72cc 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -4469,17 +4469,19 @@ static int handle_emulation_failure(struct kvm_vcpu *vcpu) > return r; > } > > -static bool reexecute_instruction(struct kvm_vcpu *vcpu, gva_t gva) > +static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2) > { > - gpa_t gpa; > + gpa_t gpa = cr2; > pfn_t pfn; > > - if (tdp_enabled) > + if (!ACCESS_ONCE(vcpu->kvm->arch.indirect_shadow_pages)) > return false; How is indirect_shadow_pages protected? Why is ACCESS_ONCE() being used to read it? > - gpa = kvm_mmu_gva_to_gpa_read(vcpu, gva, NULL); > - if (gpa == UNMAPPED_GVA) > - return true; /* let cpu generate fault */ > + if (!vcpu->arch.mmu.direct_map) { > + gpa = kvm_mmu_gva_to_gpa_read(vcpu, cr2, NULL); > + if (gpa == UNMAPPED_GVA) > + return true; /* let cpu generate fault */ > + } > > /* > * if emulation was due to access to shadowed page table > -- > 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/27/2012 06:37 AM, Marcelo Tosatti wrote: > On Tue, Nov 20, 2012 at 07:59:10AM +0800, Xiao Guangrong wrote: >> Currently, reexecute_instruction refused to retry all instructions. If >> nested npt is used, the emulation may be caused by shadow page, it can >> be fixed by dropping the shadow page >> >> Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> >> --- >> arch/x86/kvm/x86.c | 14 ++++++++------ >> 1 files changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index 7be8452..5fe72cc 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -4469,17 +4469,19 @@ static int handle_emulation_failure(struct kvm_vcpu *vcpu) >> return r; >> } >> >> -static bool reexecute_instruction(struct kvm_vcpu *vcpu, gva_t gva) >> +static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2) >> { >> - gpa_t gpa; >> + gpa_t gpa = cr2; >> pfn_t pfn; >> >> - if (tdp_enabled) >> + if (!ACCESS_ONCE(vcpu->kvm->arch.indirect_shadow_pages)) >> return false; > > How is indirect_shadow_pages protected? Why is ACCESS_ONCE() being used > to read it? Hi Marcelo, It is protected by mmu-lock for it only be changed when mmu-lock is hold. And ACCESS_ONCE is used on read path avoiding magic optimization from compiler. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 27, 2012 at 11:13:11AM +0800, Xiao Guangrong wrote: > >> +static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2) > >> { > >> - gpa_t gpa; > >> + gpa_t gpa = cr2; > >> pfn_t pfn; > >> > >> - if (tdp_enabled) > >> + if (!ACCESS_ONCE(vcpu->kvm->arch.indirect_shadow_pages)) > >> return false; > > > > How is indirect_shadow_pages protected? Why is ACCESS_ONCE() being used > > to read it? > > Hi Marcelo, > > It is protected by mmu-lock for it only be changed when mmu-lock is hold. And > ACCESS_ONCE is used on read path avoiding magic optimization from compiler. Please switch to mmu_lock protection, there is no reason to have access to this variable locklessly - not performance critical. For example, there is no use of barriers when modifying the variable. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/28/2012 07:32 AM, Marcelo Tosatti wrote: > On Tue, Nov 27, 2012 at 11:13:11AM +0800, Xiao Guangrong wrote: >>>> +static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2) >>>> { >>>> - gpa_t gpa; >>>> + gpa_t gpa = cr2; >>>> pfn_t pfn; >>>> >>>> - if (tdp_enabled) >>>> + if (!ACCESS_ONCE(vcpu->kvm->arch.indirect_shadow_pages)) >>>> return false; >>> >>> How is indirect_shadow_pages protected? Why is ACCESS_ONCE() being used >>> to read it? >> >> Hi Marcelo, >> >> It is protected by mmu-lock for it only be changed when mmu-lock is hold. And >> ACCESS_ONCE is used on read path avoiding magic optimization from compiler. > > Please switch to mmu_lock protection, there is no reason to have access > to this variable locklessly - not performance critical. > > For example, there is no use of barriers when modifying the variable. This is not bad, the worst case is, the direct mmu failed to unprotect the shadow pages, (meet indirect_shadow_pages = 0, but there has shadow pages being shadowed.), after enter to guest, we will go into reexecute_instruction again, then it will remove shadow pages. But, i do not have strong opinion on it, i respect your idea! :) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 28, 2012 at 11:15:13AM +0800, Xiao Guangrong wrote: > On 11/28/2012 07:32 AM, Marcelo Tosatti wrote: > > On Tue, Nov 27, 2012 at 11:13:11AM +0800, Xiao Guangrong wrote: > >>>> +static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2) > >>>> { > >>>> - gpa_t gpa; > >>>> + gpa_t gpa = cr2; > >>>> pfn_t pfn; > >>>> > >>>> - if (tdp_enabled) > >>>> + if (!ACCESS_ONCE(vcpu->kvm->arch.indirect_shadow_pages)) > >>>> return false; > >>> > >>> How is indirect_shadow_pages protected? Why is ACCESS_ONCE() being used > >>> to read it? > >> > >> Hi Marcelo, > >> > >> It is protected by mmu-lock for it only be changed when mmu-lock is hold. And > >> ACCESS_ONCE is used on read path avoiding magic optimization from compiler. > > > > Please switch to mmu_lock protection, there is no reason to have access > > to this variable locklessly - not performance critical. > > > > For example, there is no use of barriers when modifying the variable. > > This is not bad, the worst case is, the direct mmu failed to unprotect the shadow > pages, (meet indirect_shadow_pages = 0, but there has shadow pages being shadowed.), > after enter to guest, we will go into reexecute_instruction again, then it will > remove shadow pages. > Isn't the same scenario can happen even with mmu lock around indirect_shadow_pages access? > But, i do not have strong opinion on it, i respect your idea! :) > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/28/2012 10:01 PM, Gleb Natapov wrote: > On Wed, Nov 28, 2012 at 11:15:13AM +0800, Xiao Guangrong wrote: >> On 11/28/2012 07:32 AM, Marcelo Tosatti wrote: >>> On Tue, Nov 27, 2012 at 11:13:11AM +0800, Xiao Guangrong wrote: >>>>>> +static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2) >>>>>> { >>>>>> - gpa_t gpa; >>>>>> + gpa_t gpa = cr2; >>>>>> pfn_t pfn; >>>>>> >>>>>> - if (tdp_enabled) >>>>>> + if (!ACCESS_ONCE(vcpu->kvm->arch.indirect_shadow_pages)) >>>>>> return false; >>>>> >>>>> How is indirect_shadow_pages protected? Why is ACCESS_ONCE() being used >>>>> to read it? >>>> >>>> Hi Marcelo, >>>> >>>> It is protected by mmu-lock for it only be changed when mmu-lock is hold. And >>>> ACCESS_ONCE is used on read path avoiding magic optimization from compiler. >>> >>> Please switch to mmu_lock protection, there is no reason to have access >>> to this variable locklessly - not performance critical. >>> >>> For example, there is no use of barriers when modifying the variable. >> >> This is not bad, the worst case is, the direct mmu failed to unprotect the shadow >> pages, (meet indirect_shadow_pages = 0, but there has shadow pages being shadowed.), >> after enter to guest, we will go into reexecute_instruction again, then it will >> remove shadow pages. >> > Isn't the same scenario can happen even with mmu lock around > indirect_shadow_pages access? Hmm..., i also think it is no different. Even using mmu-lock, we can not prevent the target pfn can not be write-protected later. Marcelo? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 28, 2012 at 10:55:26PM +0800, Xiao Guangrong wrote: > On 11/28/2012 10:01 PM, Gleb Natapov wrote: > > On Wed, Nov 28, 2012 at 11:15:13AM +0800, Xiao Guangrong wrote: > >> On 11/28/2012 07:32 AM, Marcelo Tosatti wrote: > >>> On Tue, Nov 27, 2012 at 11:13:11AM +0800, Xiao Guangrong wrote: > >>>>>> +static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2) > >>>>>> { > >>>>>> - gpa_t gpa; > >>>>>> + gpa_t gpa = cr2; > >>>>>> pfn_t pfn; > >>>>>> > >>>>>> - if (tdp_enabled) > >>>>>> + if (!ACCESS_ONCE(vcpu->kvm->arch.indirect_shadow_pages)) > >>>>>> return false; > >>>>> > >>>>> How is indirect_shadow_pages protected? Why is ACCESS_ONCE() being used > >>>>> to read it? > >>>> > >>>> Hi Marcelo, > >>>> > >>>> It is protected by mmu-lock for it only be changed when mmu-lock is hold. And > >>>> ACCESS_ONCE is used on read path avoiding magic optimization from compiler. > >>> > >>> Please switch to mmu_lock protection, there is no reason to have access > >>> to this variable locklessly - not performance critical. > >>> > >>> For example, there is no use of barriers when modifying the variable. > >> > >> This is not bad, the worst case is, the direct mmu failed to unprotect the shadow > >> pages, (meet indirect_shadow_pages = 0, but there has shadow pages being shadowed.), > >> after enter to guest, we will go into reexecute_instruction again, then it will > >> remove shadow pages. > >> > > Isn't the same scenario can happen even with mmu lock around > > indirect_shadow_pages access? > > Hmm..., i also think it is no different. Even using mmu-lock, we can not > prevent the target pfn can not be write-protected later. Marcelo? In this particular case, it appears to be harmless (unsure if kvm_mmu_pte_write one is safe). The point is, lockless access should not be special. Lockless access must be carefully documented (access protocol to variables documented, all possible cases listed), and done when necessary due to performance. Otherwise, don't do it. On this case, its not necessary. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 7be8452..5fe72cc 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4469,17 +4469,19 @@ static int handle_emulation_failure(struct kvm_vcpu *vcpu) return r; } -static bool reexecute_instruction(struct kvm_vcpu *vcpu, gva_t gva) +static bool reexecute_instruction(struct kvm_vcpu *vcpu, unsigned long cr2) { - gpa_t gpa; + gpa_t gpa = cr2; pfn_t pfn; - if (tdp_enabled) + if (!ACCESS_ONCE(vcpu->kvm->arch.indirect_shadow_pages)) return false; - gpa = kvm_mmu_gva_to_gpa_read(vcpu, gva, NULL); - if (gpa == UNMAPPED_GVA) - return true; /* let cpu generate fault */ + if (!vcpu->arch.mmu.direct_map) { + gpa = kvm_mmu_gva_to_gpa_read(vcpu, cr2, NULL); + if (gpa == UNMAPPED_GVA) + return true; /* let cpu generate fault */ + } /* * if emulation was due to access to shadowed page table
Currently, reexecute_instruction refused to retry all instructions. If nested npt is used, the emulation may be caused by shadow page, it can be fixed by dropping the shadow page Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> --- arch/x86/kvm/x86.c | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-)