[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101008160749.GA31315@amt.cnet>
Date: Fri, 8 Oct 2010 13:07:49 -0300
From: Marcelo Tosatti <mtosatti@...hat.com>
To: Gleb Natapov <gleb@...hat.com>
Cc: kvm@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, avi@...hat.com, mingo@...e.hu,
a.p.zijlstra@...llo.nl, tglx@...utronix.de, hpa@...or.com,
riel@...hat.com, cl@...ux-foundation.org
Subject: Re: [PATCH v6 03/12] Retry fault before vmentry
On Thu, Oct 07, 2010 at 08:44:57PM +0200, Gleb Natapov wrote:
> On Wed, Oct 06, 2010 at 11:20:50AM -0300, Marcelo Tosatti wrote:
> > On Wed, Oct 06, 2010 at 01:07:04PM +0200, Gleb Natapov wrote:
> > > > Can't you set a bit in vcpu->requests instead, and handle it in "out:"
> > > > at the end of vcpu_enter_guest?
> > > >
> > > > To have a single entry point for pagefaults, after vmexit handling.
> > > Jumping to "out:" will skip vmexit handling anyway, so we will not reuse
> > > same call site anyway. I don't see yet why the way you propose will have
> > > an advantage.
> >
> > What i meant was to call pagefault handler after vmexit handling.
> >
> > Because the way it is in your patch now, with pre pagefault on entry,
> > one has to make an effort to verify ordering wrt other events on entry
> > processing.
> >
> What events do you have in mind?
TLB flushing, event injection, etc.
> > With pre pagefault after vmexit, its more natural.
> >
> I do not see non-ugly way to pass information that is needed to perform
> the prefault to the place you want me to put it. We can skip guest entry
> in case prefault was done which will have the same effect as your
> proposal, but I want to have a good reason to do so since otherwise we
> will just do more work for nothing on guest entry.
The reason is that it becomes similar to normal pagefault handling. I
don't have a specific bug to give you as example.
>
> > Does that make sense?
>
> --
> Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists