* Re: port 80 pass-through to HVM guests
2009-06-10 10:20 port 80 pass-through to HVM guests Jan Beulich
2009-06-10 13:08 ` Keir Fraser
@ 2009-06-24 9:21 ` Paolo Bonzini
1 sibling, 0 replies; 3+ messages in thread
From: Paolo Bonzini @ 2009-06-24 9:21 UTC (permalink / raw)
To: Jan Beulich, keir.fraser; +Cc: xen-devel
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]
Jan Beulich wrote:
> In a recent commit (99f85a28a78e96d28907fe036e1671a218fee597), KVM
> disabled the passthrough of this port due to known problems on certain HP
> laptops (see http://lkml.indiana.edu/hypermail/linux/kernel/0712.3/0872.html
> and http://lkml.indiana.edu/hypermail/linux/kernel/0801.0/2388.html). While
> I'd say that doing this globally just because of laptops may not be the right
> thing in Xen, it would seem that a DMI based approach like is being used in
> recent kernels (to replace the use of port 0x80 with 0xED) might still be
> desirable.
I don't think the passthrough matters much in Xen. The current xenbits
kernel uses unconditionally port 0x80, so on the buggy laptops the user
probably will not even succeed in booting dom0. (They could in
principle use another OS than Linux as dom0, of course).
So, the first step should be to backport from upstream the changes to
use port 0xED on those machines.
Also, on KVM there was (presumably) no performance loss from the removal
of the pass-through, because KVM is using pv_ops to avoid the outs to
port 0x80 in their guests. The same could be done for domU in Xen (domU
does not deal with buggy hardware).
With both these steps in place, the pass-through could be disabled with
no performance issues. Actually it would be enough to disable it on SVM
with a patch as simple as the attached one.
Paolo
[-- Attachment #2: xen-80-dos-prototype.patch --]
[-- Type: text/plain, Size: 1095 bytes --]
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -74,11 +74,10 @@
printk("HVM: %s enabled\n", fns->name);
/*
- * Allow direct access to the PC debug ports 0x80 and 0xed (they are
- * often used for I/O delays, but the vmexits simply slow things down).
+ * Allow direct access to the PC debug ports 0xed (it is often used
+ * for I/O delays, but the vmexits simply slow things down).
*/
memset(hvm_io_bitmap, ~0, sizeof(hvm_io_bitmap));
- __clear_bit(0x80, hvm_io_bitmap);
__clear_bit(0xed, hvm_io_bitmap);
hvm_funcs = *fns;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1451,6 +1451,12 @@
setup_vmcs_dump();
hvm_enable(&vmx_function_table);
+
+ /*
+ * Allow direct access to the PC debug ports 0x80, which is used for I/O
+ * delays. On some AMD chipsets it is problematic, but not on Intel.
+ */
+ __clear_bit(0x80, hvm_io_bitmap);
}
/*
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread