[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f1ceb4d-72ba-db57-c468-5059c0227b6b@citrix.com>
Date: Wed, 14 Jun 2017 19:02:21 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Andy Lutomirski <luto@...nel.org>, Brian Gerst <brgerst@...il.com>
CC: X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>, Juergen Gross <jgross@...e.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH 3/3] x86/xen: Move paravirt IOPL switching to slow the
path
On 14/06/17 18:40, Andy Lutomirski wrote:
> On Wed, Jun 14, 2017 at 5:40 AM, Brian Gerst <brgerst@...il.com> wrote:
>> Since tasks using IOPL are very rare, move the switching code to the slow
>> path for lower impact on normal tasks.
> I think that Andrew Cooper added a vmassist that we could opt in to
> that makes Xen PV IOPL switching work more or less just like native.
> We could maybe opt in to that and avoid needing this stuff at all on
> newer hypervisors.
Indeed.
HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_architectural_iopl);
(if recognised) does two things.
1) virtual IOPL is picked up from EFLAGS in the iret frame, exactly like
native.
2) The guest kernel is assumed to have virtual CPL0 for the purpose of
privilege calculations.
Xen never runs with the real IOPL different to 0, or a PV guests could
disable interrupts with popf. As a result, all IO port access does trap
to Xen for auditing. What part 2) does is avoid having the awkward
double-step of Linux needing to set IOPL to 1 for kernel level IO access
to avoid faulting.
The assist should be available in Xen 4.7 and later (or wherever vendors
have backported it to).
~Andrew
Powered by blists - more mailing lists