George, since you asked on Friday, I though about the situation some more over the weekend. On PV, the requirement to trap all INs and OUTs is a result from us needing the enforce two levels of restrictions - Xen''s and the guest kernel''s. I.e. we can''t make use of the hardware''s access control mechanisms, as we can''t put two I/O bit maps in place, and we (obviously) can''t run the guest kernel at IOPL 0. On PVH, otoh, we do have two bitmaps, and hence we could at least allow those port accesses to go without interception that Xen doesn''t need to do any internal state keeping on (and of course also only for those the guest is allowed to access). That would make - for PVH - unnecessary a significant part of emulate_privileged_op(): In essence, all you''d need to wire up are guest_io_read() and guest_io_write(). 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. Jan
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@xen.org> 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@xen.org> 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_INTR | GENERAL1_INTERCEPT_NMI | - GENERAL1_INTERCEPT_SMI | GENERAL1_INTERCEPT_INIT | + GENERAL1_INTERCEPT_INIT | GENERAL1_INTERCEPT_CPUID | GENERAL1_INTERCEPT_INVD | GENERAL1_INTERCEPT_HLT | GENERAL1_INTERCEPT_INVLPG | GENERAL1_INTERCEPT_INVLPGA | GENERAL1_INTERCEPT_IOIO_PROT |
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@xen.org> > 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@xen.org>I take it you''re not targeting this for 4.4? -George
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@xen.org> > > 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@xen.org> > > I take it you''re not targeting this for 4.4?Indeed not. Sorry, I should have said so. Cheers, Tim.
>>> On 28.11.13 at 12:44, Tim Deegan <tim@xen.org> wrote: > 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@xen.org> >> > 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@xen.org> >> >> I take it you''re not targeting this for 4.4? > > Indeed not. Sorry, I should have said so.And even more so considering that PVH support on SVM is going to remain a todo item for after 4.4 anyway. Jan
On 11/29/2013 09:19 AM, Jan Beulich wrote:>>>> On 28.11.13 at 12:44, Tim Deegan <tim@xen.org> wrote: >> 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@xen.org> >>>> 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@xen.org> >>> I take it you''re not targeting this for 4.4? >> Indeed not. Sorry, I should have said so. > And even more so considering that PVH support on SVM is going > to remain a todo item for after 4.4 anyway.Yes, I had started to write this, but figured there was no point discussing the merits of accepting it if Tim wasn''t asking for it to be accepted. :-) -George
Seemingly Similar Threads
- [PATCH v5 0/6] Support calling functions on dedicated physical cpu
- [PATCH v5 0/6] Support calling functions on dedicated physical cpu
- [PATCH v4 0/6] Support calling functions on dedicated physical cpu
- [PATCH v4 0/6] Support calling functions on dedicated physical cpu
- [PATCH v2 0/6] Support calling functions on dedicated physical cpu