lkml.org 
[lkml]   [2017]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 3/3] x86/xen: Move paravirt IOPL switching to slow the path
On Wed, Jun 14, 2017 at 2:02 PM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 14/06/17 18:40, Andy Lutomirski wrote:
>> On Wed, Jun 14, 2017 at 5:40 AM, Brian Gerst <brgerst@gmail.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

Ok. So do we keep the old code around to support older Xen
hypervisors or just require the newer Xen for guest userspace IOPL
support? Part of the reason I am making these changes is to sync the
32-bit and 64-bit code in __switch_to(), to ultimately merge them.

--
Brian Gerst

\
 
 \ /
  Last update: 2017-06-14 20:26    [W:0.058 / U:25.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site