[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2 of 5] xenpaging: map gfn before nomination



At 08:23 -0800 on 07 Dec (1323246231), Andres Lagar-Cavilla wrote:
> > At 10:27 +0100 on 07 Dec (1323253657), Olaf Hering wrote:
> >> On Tue, Dec 06, Andres Lagar-Cavilla wrote:
> >>
> >> > Ouch! You're absolutely tying the user space pager with the underlying
> >> xen
> >> > paging code. Most of your patches change the tools and the hypervisor
> >> in
> >> > lockstep.
> >>
> >> Yes, pager and hypervisor are bound closely together.
> >>
> >> > Patch 4 in your series is one such case. Short-cutting the state
> >> machine:
> >> > great. But what is the gain for the hypervisor in *not* sending the
> >> > EVICT_FAIL event. It's a good thing. It keeps the same interface to
> >> > user-space. Xenpaging may not need it, but the Xen paging code does
> >> not
> >> > exist solely for xenpaging.
> >>
> >> What IS the need to send yet another request? It adds just overhead for
> >> no obvious need. Please show the code that will benefit from the extra
> >> EVICT_FAIL message.
> >
> > While in general it's good to keep backward compatibility, I don't think
> > this interface has ever had a stable, usable release (that didn't
> > involve the consumer at least carrying hypervisor patches of their own)
> > so I think it's OK to make fairly large changes in it.
> Would you agree that targeting 4.2 as a reasonable long-term interface is
> a. feasible? b. worthy?

Yes, and yes. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.