Re: [kvm-devel] [PATCH 06/55] KVM: Per-architecture hypercall definitions
Hi!
> Currently kvm provides hypercalls only for x86* architectures. To
> provide hypercall infrastructure for other kvm architectures I split
> kvm_para.h into a generic header file and architecture specific
> definitions.
>
> Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
> ---
> include/asm-x86/kvm_para.h | 105
>
> include/linux/kvm_para.h | 105
> +---
> 2 files changed, 117 insertions(+), 93 deletions(-)
> create mode 100644 include/asm-x86/kvm_para.h
>
> diff --git a/include/asm-x86/kvm_para.h b/include/asm-x86/kvm_para.h
> new file mode 100644
> index 000..c6f3fd8
> --- /dev/null
> +++ b/include/asm-x86/kvm_para.h
> @@ -0,0 +1,105 @@
> +#ifndef __X86_KVM_PARA_H
> +#define __X86_KVM_PARA_H
> +
> +/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
> + * should be used to determine that a VM is running under KVM.
> + */
> +#define KVM_CPUID_SIGNATURE 0x4000
so it returns 'KVMKVMKVM' in %rax, too?
> +/* For KVM hypercalls, a three-byte sequence of either the vmrun or the
> vmmrun
> + * instruction. The hypervisor may replace it with something else but only
> the
> + * instructions are guaranteed to be supported.
> + *
> + * Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively.
> + * The hypercall number should be placed in rax and the return
rax? First, this file is shared with i386, AFAICT.
> + * placed in rax. No other registers will be clobbered unless explicited
> + * noted by the particular hypercall.
> + */
> +
> +static inline long kvm_hypercall0(unsigned int nr)
> +{
> + long ret;
> + asm volatile(KVM_HYPERCALL
> + : "=a"(ret)
> + : "a"(nr));
Second, if it is to be placed in rax, nr should be unsigned long?
> +static inline int kvm_para_available(void)
> +{
> + unsigned int eax, ebx, ecx, edx;
> + char signature[13];
> +
> + cpuid(KVM_CPUID_SIGNATURE, &eax, &ebx, &ecx, &edx);
> + memcpy(signature + 0, &ebx, 4);
> + memcpy(signature + 4, &ecx, 4);
> + memcpy(signature + 8, &edx, 4);
> + signature[12] = 0;
> +
ebx|ecx|ed
> + if (strcmp(signature, "KVMKVMKVM") == 0)
> + return 1;
Should the comment say
> +/* This CPUID returns the signature 'KVMKVMKVM\0\0\0' in ebx, ecx, and edx.
> It
> + * should be used to determine that a VM is running under KVM.
> + */
Plus, I'd use memcmp, and actually test for those zeros, too.
...which probably can be done later, as this is pure move...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Deferred interrupt handling.
Hi! I guess this will also allow UIO to work without _any_ kernel parts, with only slight performance penalty in 'almost-never-happens' deadlock case? (Greg, details are below, and better description is in the lkml thread). Pavel > > - Our dummy handler will always return IRQ_HANDLED in case any other > > previous > > irqaction did not return such. It will also issue the timer and mask > > the irq in this case. > > Ok > > > btw, if I'm not mistaken only after bad 99900/10 the irq is > > disabled. > > (and with GIT providing that they occurred in a short time period) > > > - If the timer pops before the guest acks the irq, the timer handler > > will > > ack the irq and unmask it. The timer's job is only to prevent > > deadlocks. > > Ok I see what you are doing. It's either inspired or insane and I am not > quite sure which of the two. I agree it should work although may cause > performance crunches now and then and will also need care getting the > locking right. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 10/13] KVM: Wire up hypercall handlers to a central arch-independent location
On Mon 2007-02-19 10:30:52, Avi Kivity wrote:
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
changelog?
> + switch (nr) {
> + default:
> + ;
> + }
Eh?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Stable kvm userspace interface
Hi! > >>Can we please avoid adding a ton of new ioctls? > >>ioctls inevitably require 64-bit compat code for > >>certain architectures, whereas sysfs/procfs does not. > > > >For performance reasons, an ascii string based > >interface is not > >desireable here, some of these calls should be > >optimized to > >the point of counting cycles. > > sysfs does not require ASCII... Yep, but at that point you have 32 vs. 64bit nightmare back... and stronger, because sysfs does not have compat handling. -- Thanks for all the (sleeping) penguins. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [announce] [patch] KVM paravirtualization for Linux
Hi! > i'm pleased to announce the first release of paravirtualized KVM (Linux > under Linux), which includes support for the hardware cr3-cache feature > of Intel-VMX CPUs. (which speeds up context switches and TLB flushes) > > the patch is against 2.6.20-rc3 + KVM trunk and can be found at: > >http://redhat.com/~mingo/kvm-paravirt-patches/ > > Some aspects of the code are still a bit ad-hoc and incomplete, but the > code is stable enough in my testing and i'd like to have some feedback. > > Firstly, here are some numbers: > > 2-task context-switch performance (in microseconds, lower is better): > > native: 1.11 > -- > Qemu:61.18 > KVM upstream:53.01 > KVM trunk:6.36 > KVM trunk+paravirt/cr3: 1.60 Does this make Xen obsolete? I mean... we have xen patches in suse kernels, should we keep updating them, or just drop them in favour of KVM? Pavel -- Thanks for all the (sleeping) penguins. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 12/14] KVM: x86 emulator
HI! > Add an x86 instruction emulator for kvm. > > We need an x86 emulator for the following reasons: > > - mmio instructions are intercepted as page faults, with no information about > the operation to be performed other than the virtual address > - real-mode is emulated using the old-fashined vm86 mode, with no special > intercepts for the privileged instructions, so we need to emulate mov cr, > lgdt, and lidt > - we plan to cache shadow page tables in the future, so that a guest context > switch will not throw away all the mappings we worked so hard to build. but > cachine page tables means write-protecting the guest page tables to keep > them in sync, so any writes to the guest page tables need to be emulated > > The emulator was lifted from the Xen hypervisor. > > Signed-off-by: Yaniv Kamay <[EMAIL PROTECTED]> > Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> > > Index: linux-2.6/drivers/kvm/x86_emulate.c > === > --- /dev/null > +++ linux-2.6/drivers/kvm/x86_emulate.c > @@ -0,0 +1,1370 @@ > +/** > + * x86_emulate.c > + * > + * Generic x86 (32-bit and 64-bit) instruction decoder and emulator. > + * > + * Copyright (c) 2005 Keir Fraser > + * > + * Linux coding style, mod r/m decoder, segment base fixes, real-mode > + * privieged instructions: > + * > + * Copyright (C) 2006 Qumranet > + * > + * Avi Kivity <[EMAIL PROTECTED]> > + * Yaniv Kamay <[EMAIL PROTECTED]> > + * > + * From: xen-unstable 10676:af9809f51f81a3c43f276f00c81a52ef558afda4 > + */ This needs GPL, I'd say. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
