On Sat, Feb 16, 2013 at 10:57:22AM -0500, Sanjay Lal wrote:
>
> On Feb 15, 2013, at 1:41 PM, Gleb Natapov wrote:
>
> > On Fri, Feb 15, 2013 at 01:19:29PM -0500, Sanjay Lal wrote:
> >>
> >> On Feb 6, 2013, at 7:08 AM, Gleb Natapov wrote:
> >>
> >>>>
> >>>> +static void kvm_mips_map_page(struct kvm *kvm, gfn_t gfn)
> >>>> +{
> >>>> + pfn_t pfn;
> >>>> +
> >>>> + if (kvm->arch.guest_pmap[gfn] != KVM_INVALID_PAGE)
> >>>> + return;
> >>>> +
> >>>> + pfn =kvm_mips_gfn_to_pfn(kvm, gfn);
> >>> This call should be in srcu read section since it access memory slots which
> >>> are srcu protected. You should test with RCU debug enabled.
> >>
> >> kvm_mips_gfn_to_pfn just maps to gfn_to_pfn. I don't see an instance where gfn_to_pfn is in a scru read section?
> >>
> > Where are you looking? On x86 if vcpu is not in a guest mode it is in
> > srcu read section. The lock is taken immediately after exit and released
> > before entry. This is because x86 access memory slots a lot. Other
> > arches, that do not access memory slots as much, take the lock around
> > each individual access. As far as I see this is the only place in MIPS
> > kvm where this is needed.
>
> Ah I see what you mean. I'll wrap the access in a scru read section.
>
Thanks.
I think there is userspace triggerable panic() in kvm_mips_map_page().
See my original reply. Just making sure you haven't missed it :)
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
