Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752042AbdFOBe6 (ORCPT ); Wed, 14 Jun 2017 21:34:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:58620 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751920AbdFOBe5 (ORCPT ); Wed, 14 Jun 2017 21:34:57 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 481D0239BE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: References: <20170614124032.4159-1-brgerst@gmail.com> <20170614124032.4159-4-brgerst@gmail.com> <8f1ceb4d-72ba-db57-c468-5059c0227b6b@citrix.com> From: Andy Lutomirski Date: Wed, 14 Jun 2017 18:34:34 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/3] x86/xen: Move paravirt IOPL switching to slow the path To: Brian Gerst Cc: Andrew Cooper , Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , Ingo Molnar , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2063 Lines: 50 On Wed, Jun 14, 2017 at 11:25 AM, Brian Gerst wrote: > On Wed, Jun 14, 2017 at 2:02 PM, Andrew Cooper > wrote: >> On 14/06/17 18:40, Andy Lutomirski wrote: >>> On Wed, Jun 14, 2017 at 5:40 AM, Brian Gerst 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. I think we should keep the old code. One way to structure this that might be nicer than using paravirt ops would be to add a new bug X86_BUG_XEN_PV_IOPL that would only be set on old hypervisors that don't have the assist. Then the code could look like: if (static_cpu_has_bug(X86_XEN_PV_IOPL)) xen_set_iopl(whatever); and we wouldn't need the paravirt indirection at all.