* I/O port access handling for PVH
@ 2013-10-21 14:10 Jan Beulich
2013-11-28 11:01 ` [PATCH] " Tim Deegan
0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2013-10-21 14:10 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] Re: I/O port access handling for PVH
2013-10-21 14:10 I/O port access handling for PVH Jan Beulich
@ 2013-11-28 11:01 ` Tim Deegan
2013-11-28 11:37 ` George Dunlap
0 siblings, 1 reply; 6+ messages in thread
From: Tim Deegan @ 2013-11-28 11:01 UTC (permalink / raw)
To: Jan Beulich
Cc: George Dunlap, xen-devel, Boris Ostrovsky, Suravee Suthikulpanit
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 |
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] Re: I/O port access handling for PVH
2013-11-28 11:01 ` [PATCH] " Tim Deegan
@ 2013-11-28 11:37 ` George Dunlap
2013-11-28 11:44 ` Tim Deegan
0 siblings, 1 reply; 6+ messages in thread
From: George Dunlap @ 2013-11-28 11:37 UTC (permalink / raw)
To: Tim Deegan, Jan Beulich; +Cc: xen-devel, Boris Ostrovsky, Suravee Suthikulpanit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Re: I/O port access handling for PVH
2013-11-28 11:37 ` George Dunlap
@ 2013-11-28 11:44 ` Tim Deegan
2013-11-29 9:19 ` Jan Beulich
0 siblings, 1 reply; 6+ messages in thread
From: Tim Deegan @ 2013-11-28 11:44 UTC (permalink / raw)
To: George Dunlap
Cc: xen-devel, Boris Ostrovsky, Suravee Suthikulpanit, Jan Beulich
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Re: I/O port access handling for PVH
2013-11-28 11:44 ` Tim Deegan
@ 2013-11-29 9:19 ` Jan Beulich
2013-12-02 11:31 ` George Dunlap
0 siblings, 1 reply; 6+ messages in thread
From: Jan Beulich @ 2013-11-29 9:19 UTC (permalink / raw)
To: George Dunlap, Tim Deegan
Cc: xen-devel, Boris Ostrovsky, Suravee Suthikulpanit
>>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Re: I/O port access handling for PVH
2013-11-29 9:19 ` Jan Beulich
@ 2013-12-02 11:31 ` George Dunlap
0 siblings, 0 replies; 6+ messages in thread
From: George Dunlap @ 2013-12-02 11:31 UTC (permalink / raw)
To: Jan Beulich, Tim Deegan; +Cc: xen-devel, Boris Ostrovsky, Suravee Suthikulpanit
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-12-02 11:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-21 14:10 I/O port access handling for PVH Jan Beulich
2013-11-28 11:01 ` [PATCH] " Tim Deegan
2013-11-28 11:37 ` George Dunlap
2013-11-28 11:44 ` Tim Deegan
2013-11-29 9:19 ` Jan Beulich
2013-12-02 11:31 ` George Dunlap
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).