[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Re: I/O port access handling for PVH
At 11:37 +0000 on 28 Nov (1385635050), George Dunlap wrote: > 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 <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> > > I take it you're not targeting this for 4.4? Indeed not. Sorry, I should have said so. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |