[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH] Re: I/O port access handling for PVH

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 <tim@xxxxxxx>
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 <tim@xxxxxxx>

diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 21292bb..de6fed0 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -75,7 +75,7 @@ static int construct_vmcb(struct vcpu *v)
     vmcb->_general1_intercepts = 
+        GENERAL1_INTERCEPT_INIT        |

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.