| Message ID | 1245406553-22013-1-git-send-email-pbonzini@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 06/19/2009 01:15 PM, Paolo Bonzini wrote: > From: Paolo Bonzini<pbonzini@redhat.com> > > KVM's optimization of guest port 80 accesses was removed last May 11 > in commit 99f85a. However, this probably has speed penalties. I don't > have a machine to test but the equivalent VMX patch (fdef3ad) reported > a speedup of 3-5%, and on the Xen mailing list it was mentioned that on > Xen passing port 80 through had positive effects on startup speed. > > We can enable passthrough to the same port the host kernel uses instead. > Since we don't tell the guest to use 0xed, this won't help. If we can tell the guest, we can just tell it not to use any port at all, since this is a virtualized environment and there's no buggy hardware to please. We could speed it up by trapping and emulating the port write in the kernel instead of letting userspace handle it (should be faster than passthrough on newer hosts). I'd like to make is configurable from userspace though, the kernel has no business trapping random ports.
Avi Kivity wrote: > On 06/19/2009 01:15 PM, Paolo Bonzini wrote: >> From: Paolo Bonzini<pbonzini@redhat.com> >> >> KVM's optimization of guest port 80 accesses was removed last May 11 >> in commit 99f85a. However, this probably has speed penalties. I don't >> have a machine to test but the equivalent VMX patch (fdef3ad) reported >> a speedup of 3-5%, and on the Xen mailing list it was mentioned that on >> Xen passing port 80 through had positive effects on startup speed. >> >> We can enable passthrough to the same port the host kernel uses instead. > > Since we don't tell the guest to use 0xed, this won't help. Won't the guest do that automatically through DMI? I think we have four cases: 1) non-buggy chipset, host uses 0x80 and guest cannot crash the machine; this is okay. 2) buggy chipset, both host and guest use 0xed thanks to DMI detection; and (since 0x80 is not passthrough) the guest cannot crash the machine, so this is okay. 3) host is given explicit io_delay=0xed, but the guest isn't. However, 0x80 is not passthrough so the guest can use port 0x80 safely even on buggy hardware. 4) a buggy chipset is not detected, so io_delay=0x80 and 0x80 is made passthrough. In principle the guest could crash the machine; however the host will have written to 0x80 at startup, most likely causing a crash way before a guest is started. So this should not be a problem either. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 22, 2009 at 12:11:59PM +0200, Paolo Bonzini wrote: > Avi Kivity wrote: >> On 06/19/2009 01:15 PM, Paolo Bonzini wrote: >>> From: Paolo Bonzini<pbonzini@redhat.com> >>> >>> KVM's optimization of guest port 80 accesses was removed last May 11 >>> in commit 99f85a. However, this probably has speed penalties. I don't >>> have a machine to test but the equivalent VMX patch (fdef3ad) reported >>> a speedup of 3-5%, and on the Xen mailing list it was mentioned that on >>> Xen passing port 80 through had positive effects on startup speed. >>> >>> We can enable passthrough to the same port the host kernel uses instead. >> >> Since we don't tell the guest to use 0xed, this won't help. > > Won't the guest do that automatically through DMI? > DMI that guest sees is very different from DMI of the host. What table is used to tell which port to use for io delay? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/22/2009 01:11 PM, Paolo Bonzini wrote: > Avi Kivity wrote: >> On 06/19/2009 01:15 PM, Paolo Bonzini wrote: >>> From: Paolo Bonzini<pbonzini@redhat.com> >>> >>> KVM's optimization of guest port 80 accesses was removed last May 11 >>> in commit 99f85a. However, this probably has speed penalties. I don't >>> have a machine to test but the equivalent VMX patch (fdef3ad) reported >>> a speedup of 3-5%, and on the Xen mailing list it was mentioned that on >>> Xen passing port 80 through had positive effects on startup speed. >>> >>> We can enable passthrough to the same port the host kernel uses >>> instead. >> >> Since we don't tell the guest to use 0xed, this won't help. > > Won't the guest do that automatically through DMI? As Gleb said, the guest has a virtual DMI table. > > I think we have four cases: > > 1) non-buggy chipset, host uses 0x80 and guest cannot crash the > machine; this is okay. > > 2) buggy chipset, both host and guest use 0xed thanks to DMI > detection; and (since 0x80 is not passthrough) the guest cannot crash > the machine, so this is okay. > > 3) host is given explicit io_delay=0xed, but the guest isn't. > However, 0x80 is not passthrough so the guest can use port 0x80 safely > even on buggy hardware. > > 4) a buggy chipset is not detected, so io_delay=0x80 and 0x80 is made > passthrough. In principle the guest could crash the machine; however > the host will have written to 0x80 at startup, most likely causing a > crash way before a guest is started. So this should not be a problem > either. This is all true, but pass through is slower (at least on some chipsets) than in-kernel emulation, so I'd rather stay away from it.
Paolo, As said in private email you can change the port 80 passthrough to disabled only on those hosts that have broken port 80 (you can find the blacklist at arch/x86/kernel/io_delay.c).c On Fri, Jun 19, 2009 at 12:15:53PM +0200, Paolo Bonzini wrote: > From: Paolo Bonzini <pbonzini@redhat.com> > > KVM's optimization of guest port 80 accesses was removed last May 11 > in commit 99f85a. However, this probably has speed penalties. I don't > have a machine to test but the equivalent VMX patch (fdef3ad) reported > a speedup of 3-5%, and on the Xen mailing list it was mentioned that on > Xen passing port 80 through had positive effects on startup speed. > > We can enable passthrough to the same port the host kernel uses instead. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > arch/x86/kernel/io_delay.c | 1 + > arch/x86/kvm/svm.c | 5 +++++ > 2 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/kernel/io_delay.c b/arch/x86/kernel/io_delay.c > index a979b5b..a478cb2 100644 > --- a/arch/x86/kernel/io_delay.c > +++ b/arch/x86/kernel/io_delay.c > @@ -129,3 +129,4 @@ static int __init io_delay_param(char *s) > } > > early_param("io_delay", io_delay_param); > +EXPORT_SYMBOL_GPL(io_delay_type); > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > index 1f8510c..c49f4db 100644 > --- a/arch/x86/kvm/svm.c > +++ b/arch/x86/kvm/svm.c > @@ -26,6 +26,7 @@ > #include <linux/highmem.h> > #include <linux/sched.h> > > +#include <asm/io.h> > #include <asm/desc.h> > > #include <asm/virtext.h> > @@ -411,6 +412,10 @@ static __init int svm_hardware_setup(void) > > iopm_va = page_address(iopm_pages); > memset(iopm_va, 0xff, PAGE_SIZE * (1 << IOPM_ALLOC_ORDER)); > + if (io_delay_type == CONFIG_IO_DELAY_TYPE_0X80) > + clear_bit(0x80, iopm_va); > + else if (io_delay_type == CONFIG_IO_DELAY_TYPE_0XED) > + clear_bit(0xED, iopm_va); > iopm_base = page_to_pfn(iopm_pages) << PAGE_SHIFT; > > if (boot_cpu_has(X86_FEATURE_NX)) > -- > 1.6.0.3 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcelo Tosatti wrote: > Paolo, > > As said in private email you can change the port 80 passthrough to > disabled only on those hosts that have broken port 80 (you can find the > blacklist at arch/x86/kernel/io_delay.c).c Actually I read the code more and, since pv_ops is actually disabling outs to port 80 if the guest is sufficiently new, it may even make more sense for easier maintenance to remove the port 80 passthrough on Intel processors as well... Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 22, 2009 at 07:57:22PM +0200, Paolo Bonzini wrote: > Marcelo Tosatti wrote: >> Paolo, >> >> As said in private email you can change the port 80 passthrough to >> disabled only on those hosts that have broken port 80 (you can find the >> blacklist at arch/x86/kernel/io_delay.c).c > > Actually I read the code more and, since pv_ops is actually disabling > outs to port 80 if the guest is sufficiently new, it may even make more > sense for easier maintenance to remove the port 80 passthrough on Intel > processors as well... But what about Windows guests? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcelo Tosatti wrote: > On Mon, Jun 22, 2009 at 07:57:22PM +0200, Paolo Bonzini wrote: >> Marcelo Tosatti wrote: >>> Paolo, >>> >>> As said in private email you can change the port 80 passthrough to >>> disabled only on those hosts that have broken port 80 (you can find the >>> blacklist at arch/x86/kernel/io_delay.c).c >> Actually I read the code more and, since pv_ops is actually disabling >> outs to port 80 if the guest is sufficiently new, it may even make more >> sense for easier maintenance to remove the port 80 passthrough on Intel >> processors as well... > > But what about Windows guests? I don't think they are using port 80 to delay ISA access, are they? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/kernel/io_delay.c b/arch/x86/kernel/io_delay.c index a979b5b..a478cb2 100644 --- a/arch/x86/kernel/io_delay.c +++ b/arch/x86/kernel/io_delay.c @@ -129,3 +129,4 @@ static int __init io_delay_param(char *s) } early_param("io_delay", io_delay_param); +EXPORT_SYMBOL_GPL(io_delay_type); diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 1f8510c..c49f4db 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -26,6 +26,7 @@ #include <linux/highmem.h> #include <linux/sched.h> +#include <asm/io.h> #include <asm/desc.h> #include <asm/virtext.h> @@ -411,6 +412,10 @@ static __init int svm_hardware_setup(void) iopm_va = page_address(iopm_pages); memset(iopm_va, 0xff, PAGE_SIZE * (1 << IOPM_ALLOC_ORDER)); + if (io_delay_type == CONFIG_IO_DELAY_TYPE_0X80) + clear_bit(0x80, iopm_va); + else if (io_delay_type == CONFIG_IO_DELAY_TYPE_0XED) + clear_bit(0xED, iopm_va); iopm_base = page_to_pfn(iopm_pages) << PAGE_SHIFT; if (boot_cpu_has(X86_FEATURE_NX))