[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140318081403.GC28075@gmail.com>
Date: Tue, 18 Mar 2014 09:14:03 +0100
From: Ingo Molnar <mingo@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Jan Beulich <JBeulich@...e.com>,
George Dunlap <George.Dunlap@...citrix.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
Ingo Molnar <mingo@...hat.com>,
David Vrabel <david.vrabel@...rix.com>,
Sarah Newman <srn@...mr.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Xen-devel] [PATCHv1] x86: don't schedule when handling #NM
exception
* H. Peter Anvin <hpa@...or.com> wrote:
> On 03/17/2014 10:05 AM, Jan Beulich wrote:
> >
> > I don't think so - while it (as we now see) disallows certain things
> > inside the guest, back at the time when this was designed there was
> > no sign of any sort of allocation/scheduling being done inside the
> > #NM handler. And furthermore, a PV specification is by its nature
> > allowed to define deviations from real hardware behavior, or else it
> > wouldn't be needed in the first place.
> >
>
> And this is exactly the sort of thing about Xen that make me want to
> go on murderous rampage. You think you can just take the current
> Linux implementation at whatever time you implement the code and
> later come back and say "don't change that, we hard-coded it in
> Xen."
And the solution is that we just ignore that kind of crap in the
native kernel and let Xen sort it out as best as it can.
When Xen (and PV) was merged it was promised that a PV interface can
always adopt to whatever Linux does, without restricting the kernel on
the native side in any fashion - time to check on that promise.
Thanks,
Ingo
--
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