From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] Re: I/O port access handling for PVH Date: Thu, 28 Nov 2013 11:37:30 +0000 Message-ID: <52972AFA.3010506@eu.citrix.com> References: <526551DE02000078000FC6FD@nat28.tlf.novell.com> <20131128110108.GD36239@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vlzuc-00042R-IW for xen-devel@lists.xenproject.org; Thu, 28 Nov 2013 11:37:38 +0000 In-Reply-To: <20131128110108.GD36239@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan , Jan Beulich Cc: xen-devel , Boris Ostrovsky , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.org On 11/28/2013 11:01 AM, Tim Deegan wrote: > At 15:10 +0100 on 21 Oct (1382364606), Jan Beulich wrote: >> In particular it would then hopefully be safe to do all that without >> the on-stack emulation stub, as this ought to be necessary only >> for Dom0, which ought to always have direct access to such >> "special" I/O ports. With one apparent caveat: SVM sets >> GENERAL1_INTERCEPT_SMI (for a reason that escapes my right >> now), and hence control doesn't transfer directly to SMM when >> an SMI occurs (and consequently registers aren't expected). But >> I would hope that this intercept isn't really needed, and hence >> could be dropped at least for PVH guests. > (I realise I'm rather late replying to this - I put it aside and then > only found it again today) > > On machines where the BIOS has locked down SMM mode, this > intercept is in fact ignored by the hardware, and that works fine. > So we can drop it for all VMs if it's convenient: > > commit a842864f3901078e2a5f4d1cca2f01a72c8d7d13 > Author: Tim Deegan > Date: Thu Nov 28 10:58:42 2013 +0000 > > x86/svm: don't intercept SMI. > > The SMI intercept is ignored anyway when the BIOS has set the SMMLOCK > bit in HWCR (see APM v3.21, volume 2, 15.13.3) and it's convenient for > PVH IO processing to have the SMI handled directly with the guest's > GPR state (for BIOSes that use SMI as a sort of function call interface). > > Signed-off-by: Tim Deegan I take it you're not targeting this for 4.4? -George