On 08/04/2014 07:51 PM, Greg KH wrote:
On Mon, Aug 04, 2014 at 04:39:19PM -0700, H. Peter Anvin wrote:
On 08/04/2014 04:37 PM, Greg KH wrote:
On Mon, Aug 04, 2014 at 04:21:52PM -0700, H. Peter Anvin wrote:
On 08/04/2014 10:38 AM, Greg KH wrote:
On Fri, Jul 18, 2014 at 02:59:02PM -0700, Andrew Lutomirski wrote:
Still not ready :(
This should now be resolved with commit
7209a75d2009dbf7745e2fd354abf25c3deb3ca3 (x86_64/entry/xen: Do not
invoke espfix64 on Xen), right?
Yes... although it reintroduces the original problem on Xen PV. It
simply isn't fixable in the kernel; it has to be fixed in the Xen
hypervisor.
Ok, so what do I do here? 7209a75d2009dbf7745e2fd354abf25c3deb3ca3
doesn't apply to 3.15 and older due to the previous set of changes (this
thread) is not there. Am I supposed to wait some random amount of time
and hope some other project gets around to updating their code?
Any reason why I can't apply this series now, and then if the Xen people
care about this, they will fix their server up when they get the chance
to?
No, we should do exactly that (and we -- meaning myself and/or Andy)
will have to massage it to fit.
Ok, I'll queue these patches up again and let's see what happens :)
Greg,
What about 8762e5092828c4dc0f49da5a47a644c670df77f3 (x86/espfix/xen: Fix
allocation of pages for paravirt page tables)?
You sent a note a couple of weeks ago that it wouldn't apply to 3.15 and
I wonder whether this was because some of the other espfix patches
haven't made it to your queue. Now that everything seems to be there,
can this commit be applied?
Thanks.
-boris
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html