Re: [kvm-devel] [PATCH 2/2] make the injection of interrupts run at sleepable mode.
Glauber de Oliveira Costa wrote: > On 10/15/07, Izik Eidus <[EMAIL PROTECTED]> wrote: > > I just took a quick overview on it, but to start with, why does it use > a vmx specific naming ? > > beacuse the problem is in the emulator function that the vmx have to run inside unsleepable mode for real mode. svm have no such problem - 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
[kvm-devel] [PATCH] [RESEND] Add cross compile to top level configuration file
This new patch removes gcc 3.x checks, as well as adds environment
variables $CFLAGS & $LDFLAGS to include libs to qemu for cross compile.
I was going to add this in another patch. But they should probably go in
now. So an example for power is to include zlib so before running
configure you do:
export LDFLAGS="-L/home/public/zlib-ppc/lib"
export CFLAGS="-I/home/public/zlib-ppc/include"
Signed-on-by: Jerone Young <[EMAIL PROTECTED]>
diff -r ff2feafadcac configure
--- a/configure Fri Oct 12 07:35:25 2007 -0500
+++ b/configure Mon Oct 15 21:52:51 2007 -0500
@@ -3,32 +3,29 @@ prefix=/usr/local
prefix=/usr/local
kerneldir=/lib/modules/$(uname -r)/build
want_module=1
-qemu_cc=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
+cc=gcc
disable_gcc_check=
+cross_prefix=
+arch=`uname -m`
+target_exec=
usage() {
cat <<-EOF
Usage: $0 [options]
Options include:
-
+ --arch=ARCHarchitecture to compile for ($arch)
+ --cross-prefix=PREFIX prefix for cross compiler
--prefix=PREFIXwhere to install things ($prefix)
--with-patched-kernel don't use external module
--kerneldir=DIRkernel build directory ($kerneldir)
- --qemu-cc="$qemu_cc" compiler for qemu (needs gcc3.x) ($qemu_cc)
+ --qemu-cc=CC compiler for qemu (needs to be gcc 3.x)
+ Not valid if used with --cross-prefix
--disable-gcc-checkdon't insist on gcc-3.x
- - this will break running without kvm
+ CAUTION: using this option may break build
EOF
exit 1
}
-
-
-# prefer gcc if its version is 3.* ( over a compat-gcc )
-# do it before parsing command line arguments to enable the user
-#to specify a specific gcc he/she likes.
-if gcc -v 2>&1 | grep -q 'gcc *version *3\.[2-4]\.[0-9]'; then
- qemu_cc=gcc
-fi
while [[ "$1" = -* ]]; do
opt="$1"; shift
@@ -48,11 +45,17 @@ while [[ "$1" = -* ]]; do
want_module=
;;
--qemu-cc)
- qemu_cc="$arg"
+ cc="$arg"
;;
--disable-gcc-check)
disable_gcc_check=1
;;
+ --arch)
+ arch="$arg"
+ ;;
+ --cross-prefix)
+ cross_prefix="$arg"
+;;
--help)
usage
;;
@@ -62,39 +65,54 @@ while [[ "$1" = -* ]]; do
esac
done
-if [[ -z "$qemu_cc" ]]; then
-echo "$0: cannot locate gcc 3.x. please install it or specify with
--qemu-cc"
-exit 1
-fi
+#set kenel directory
libkvm_kerneldir="$kerneldir"
if (( want_module )); then
libkvm_kerneldir=$(readlink -f kernel)
fi
-target_cpu() {
-if [[ $(uname -m) = i?86 ]]; then
- echo x86_64
-else
- uname -m
-fi
-}
+#if arch is an x86 arch set to i386
+if [[ $arch = i?86 ]]; then
+ arch="i386"
+fi
-(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
-(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
---disable-kqemu --extra-cflags="-I $PWD/../user" \
---extra-ldflags="-L $PWD/../user" \
+#see if using a cross compiler or not
+qemu_opts=
+user_opts=
+if [[ -z $cross_prefix ]]; then
+qemu_opts+=" --cc=$cc"
+user_opts+=" --cc=$cc"
+else
+qemu_opts+=" --cross-prefix=$cross_prefix"
+user_opts+=" --cross-prefix=$cross_prefix"
+fi
+
+#set parameters compiling
+if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
+target_exec="x86_64-softmmu"
+qemu_opts+=" --enable-alsa"
+fi
+
+qemudir=`pwd`/qemu
+
+#configure user dir
+(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
+ $user_opts --arch="$arch")
+(cd qemu; ./configure --target-list=$target_exec \
+--disable-kqemu --extra-cflags="-I $PWD/../user $CFLAGS" \
+--extra-ldflags="-L $PWD/../user $LDFLAGS" \
--enable-kvm --kernel-path="$libkvm_kerneldir" \
---enable-alsa \
${disable_gcc_check:+"--disable-gcc-check"} \
---prefix="$prefix"
+--prefix="$prefix" \
+$qemu_opts --cpu=$arch
)
-
cat < config.mak
+ARCH=$arch
PREFIX=$prefix
KERNELDIR=$kerneldir
WANT_MODULE=$want_module
+CC=$cross_prefix$cc
EOF
-
On Mon, 2007-10-15 at 15:51 -0500, Anthony Liguori wrote:
> Jerone Young wrote:
> > On Mon, 2007-10-15 at 15:13 -0500, Anthony Liguori wrote:
> >
> >> Jerone Young wrote:
> >>
> >>> This patch is an improved version of patches sent last week to enable
> >>> the top level configuration file for cross compile. This currently
> >>> allows x86 & x86-64 to cross compile. But will soon be sending patches
> >>> for powerpc embedded once this is accepted. This patches to latest git
> >>> and is in git format ;-)
> >>>
> >>> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
> >>>
> >>>
> >>>
> >> Why are you on
Re: [kvm-devel] [PATCH] Add cross compile to top level configuration file
So it appears that trying to remove --cpu option will not work. Qemu
still wants to compile to the arch of the machine you are compiling on
without it. Even with cross compiler specified. So qemu still thinks the
host CPU is going to be i386, even though I specified an x86-64 cross
compilers. So Qemu will intern use -m32 cflag as well as not make the
correct assumptions during build.
So same goes for power. This option is how we cross compile qemu today
on our x86 machines to the run on the our embedded power boards.
So I'll leave the patch alone for now until Avi weighs in on it. But
everything that is currently there keeps functionality that was already
there.
On Mon, 2007-10-15 at 15:51 -0500, Anthony Liguori wrote:
> Jerone Young wrote:
> > On Mon, 2007-10-15 at 15:13 -0500, Anthony Liguori wrote:
> >
> >> Jerone Young wrote:
> >>
> >>> This patch is an improved version of patches sent last week to enable
> >>> the top level configuration file for cross compile. This currently
> >>> allows x86 & x86-64 to cross compile. But will soon be sending patches
> >>> for powerpc embedded once this is accepted. This patches to latest git
> >>> and is in git format ;-)
> >>>
> >>> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
> >>>
> >>>
> >>>
> >> Why are you only passing --enable-alsa only x86?
> >>
> >
> > Because for our powerpc stuff we actually want different options. ALSA
> > is not a dependency we want.
> >
>
> Well, you don't want the dependency, but does that mean noone will ever
> want the dependency on anything but x86?
>
> I'm curious why --enable-alsa is here in the first place. QEMU will use
> SDL audio by default. Perhaps Avi can shed light on why added in the
> first place?
>
> Regards,
>
> Anthony Liguori
>
>
> >>> +fi
> >>> +
> >>> +qemudir=`pwd`/qemu
> >>> +
> >>> +#configure user dir
> >>> +(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir"
> >>> \
> >>> + $user_opts --arch="$arch")
> >>> +(cd qemu; ./configure --target-list=$target_exec \
> >>> --disable-kqemu --extra-cflags="-I $PWD/../user" \
> >>> --extra-ldflags="-L $PWD/../user" \
> >>> --enable-kvm --kernel-path="$libkvm_kerneldir" \
> >>> ---enable-alsa \
> >>> ${disable_gcc_check:+"--disable-gcc-check"} \
> >>> ---prefix="$prefix"
> >>> +--prefix="$prefix" \
> >>> +$qemu_opts --cpu="$arch"
> >>>
> >>>
> >> I don't think this is right. You're using two different --cpu options
> >> for i386 and x86_64. There really shouldn't be a --cpu option at all
> >> for x86.
> >>
> >
> > So the --cpu option is actually a hidden option in qemu & is not on the
> > qemu help page .. who know why it isn't but the it's in the code.
> >
> > It makes since though that if you are going to specify cross-prefix=
> > then there is little reason to specify the cpu on the qemu line. As it
> > should detect everything from cross compiler.
> >
> > I'll test this out and send a new patch with the 2 changes.
> >
> >
> >> Regards,
> >>
> >> Anthony Liguori
> >>
> >>
> >>> )
> >>>
> >>>
> >>> -
> >>> cat < config.mak
> >>> +ARCH=$arch
> >>> PREFIX=$prefix
> >>> KERNELDIR=$kerneldir
> >>> WANT_MODULE=$want_module
> >>> +CC=$cross_prefix$cc
> >>> EOF
> >>> -
> >>>
> >>
> >>> -
> >>> 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
> >>>
> >> -
> >> 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
> >>
> >
> >
> >
>
>
> -
> 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.sourcefor
Re: [kvm-devel] [PATCH 2/2] make the injection of interrupts run at sleepable mode.
On 10/15/07, Izik Eidus <[EMAIL PROTECTED]> wrote: I just took a quick overview on it, but to start with, why does it use a vmx specific naming ? -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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] [RFC] Paravirt timer for KVM
On 10/15/07, Hollis Blanchard <[EMAIL PROTECTED]> wrote: > (This mail was sent off-list, so I'll do the same.) Oh, I'm sorry Hollis, after so many mails, I've hit the reply key instead of the reply to all one ;-) I'm moving it to the list again, where it belongs. > On Mon, 2007-10-15 at 14:29 -0300, Glauber de Oliveira Costa wrote: > > > > > > I must have missed earlier discussion on this topic, so I'm left > > > wondering... what's the point? What's wrong with PIT (et al) emulation? > > > > > Well, my reasons are: > > > > * Steal time (despite the fact I've not addressed in this patch. But > > c'mon guys, one thing at a time! ;-)) > > Yes, I agree this is important, but I'm not sure you need a new time > source to do that. And how would you do it ? Only the host knows how much time you spent not running. So you either have an alternate clocksource, or goes tell the device about it. Which yeah, may be more general, but it is quite cumbersome, IMHO. > > * Performance: Although I've not measured it (for hpet we'd have to > > have an implementation , in first place), I think that handling timer > > events in the host might be more efficient than userspace exits for > > pit emulation. > > Host emulation doesn't require guest paravirtualization. > > However, Avi makes a good point about the number of MMIO exits, and I've > replied on-list. Yes, this is what I meant. > > * This is not exactly one that hurts me directly, but I saw come > > complaints frome some people in kvm-devel saying that they needed to > > run ntp in all the guests, and I felt sad for them. ;-) Paravirt > > timers make this task easier, IMHO, although maybe something can be > > done in the emulation layer for it. > > It's not clear to me that PV time would by itself solve any NTP issues. host provides the guest with the idea of timing. if the time in the host changes, the guest will get this update for free. > To clarify, I'm not saying PV time is a bad idea. I'm just trying to > understand why it's a good idea... If you try to understand why it's a good idea, and I try to understand why it's a bad idea, we'll hopefully come to a good middle ground, and everybody wins ;-) -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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] [RFC] Paravirt timer for KVM
> The basic issue is that on many architectures, the hardware MMU does > *not* hold all mappings, and even if it does, performing MMU translation > in software can be prohibitively complicated and slow. As a worst-case > scenario, consider a software-controlled TLB which can hold a small > finite number of simultaneous mappings. On the embedded PowerPC 440 > cores I'm working on, that number is 64. There is no hardware table > walker. > > That means that if the hypervisor is passed a virtual address, it may > not be present in the MMU at all. Ordinarily the hardware would deliver > a TLB miss interrupt to the kernel, and the kernel would insert the > appropriate mapping (as calculated or found in software-only data > structures). However, consider the locking nightmare if the hypervisor > delivers an interrupt while "inside" a guest hypercall... that makes a lot of sense, thank you for the explanation. > Longs everywhere. :) And not just that, but you are cementing this > particular layout of timespec into the guest ABI. There is nothing to > prevent Linux from changing timespec in some future version... Yeah, have figured it out. I think I'll stick to two fields then, with u64 for seconds and nanoseconds. Or would it just be better to use a u64 nanoseconds field? A _lot_ of time should have passed before such counter overflows. So having two is possibly overkill. -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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] [RFC] Paravirt timer for KVM
On Mon, 2007-10-15 at 18:47 +0200, Avi Kivity wrote: > Hollis Blanchard wrote: > >> > >> I'd think there is no reason for virtual timer to be PIT like, which > >> is mostly due to historic reason. > >> > >> If we need to make it close to native timer device, HPET is much > >> better than PIT for virtual time to look like. > >> > > > > Fine, so why do we need PV time when we can emulate the HPET? > > > > A pv timebase can require zero exits while any emulated timebase will > require at least one. That's a good point, but does PIT/HPET emulation show up as a hot spot in any profiles? I think keeping the hypercall API as small as feasible is a desirable design goal. -- Hollis Blanchard IBM Linux Technology Center - 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] [RFC] Paravirt timer for KVM
On Mon, 2007-10-15 at 14:48 -0300, Glauber de Oliveira Costa wrote:
> On 10/12/07, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > > + if (kvm_hypercall1(KVM_HCALL_SET_SHARED_PAGE, shared_page))
> > > + return;
> >
> > Here you're passing a virtual address across the guest/host interface,
> > which is something we've previously agreed is bad.
> And that's the reason for the "nothing". It was just the easier way,
> and I'm not aware of any discussion in which it was agreed bad. I'll
> dig into the archives, but it would be a lot easier if you give me
> some pointers ;-)
Here's the original thread:
http://www.mail-archive.com/kvm-devel@lists.sourceforge.net/msg00755.html
The basic issue is that on many architectures, the hardware MMU does
*not* hold all mappings, and even if it does, performing MMU translation
in software can be prohibitively complicated and slow. As a worst-case
scenario, consider a software-controlled TLB which can hold a small
finite number of simultaneous mappings. On the embedded PowerPC 440
cores I'm working on, that number is 64. There is no hardware table
walker.
That means that if the hypervisor is passed a virtual address, it may
not be present in the MMU at all. Ordinarily the hardware would deliver
a TLB miss interrupt to the kernel, and the kernel would insert the
appropriate mapping (as calculated or found in software-only data
structures). However, consider the locking nightmare if the hypervisor
delivers an interrupt while "inside" a guest hypercall...
> for the overall picture, it does not really make a difference, so if
> this is all that a bad idea, I can change it, no big deal.
Great! This is very important for portability to non-x86 architectures,
and a long-standing problem on another open source hypervisor, which is
why I'm eager to avoid it from the beginning here.
> > > +struct kvm_hv_clock {
> > > + int stable_tsc; /* use raw tsc for clock_read */
> > > + unsigned long tsc_mult;
> > > + struct timespec now;
> > > + u64 last_tsc;
> > > + /* That's the wall clock, not the water closet */
> > > + struct timespec wc;
> > > +};
> >
> > This isn't even good for x86: you're using "long" in a binary interface!
> > You're also using timespec, and what sort of binary compatibility
> > guarantees would you like to make about that?
>
> Now seriously, the long is just my bad, but I'm not aware of any
> complications regarding the timespec. You are welcome to enlighten me.
> (Meanwhile, I'll go look at it)
typedef long__kernel_time_t;
typedef __kernel_time_t time_t;
struct timespec {
time_t tv_sec; /* seconds */
longtv_nsec;/* nanoseconds */
};
Longs everywhere. :) And not just that, but you are cementing this
particular layout of timespec into the guest ABI. There is nothing to
prevent Linux from changing timespec in some future version...
--
Hollis Blanchard
IBM Linux Technology Center
-
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 0/2] Swapping:fixing the problem with unsleepable place of kvm and gfn_to_page
Very nice! This series seems to have solved the problem for me. Izik Eidus wrote: > this patch remove all the ugly messages from the dmesg, > now i think my patch together with Anthony changes can be merged to kvm. Perhaps you can send out all of the patches together in a single patch bomb for one final review? Right now I'm using patches from a few different sets. I'll also run some tests on it. Also, did your updated 3/4 patch fix the Fedora rmap problem? Regards, Anthony Liguori > thanks to Anthony with his help in working on it. > - 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
[kvm-devel] [PATCH 2/2] make the injection of interrupts run at sleepable mode.
>From c5761ef6c1333062a7cd9d5b0003955bc7b7a93e Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Mon, 15 Oct 2007 23:16:42 +0200
Subject: [PATCH] this patch make the injection of interrupts run at sleepable mode.
Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h |3 +++
drivers/kvm/kvm_main.c | 20 ++--
drivers/kvm/svm.c |1 +
drivers/kvm/vmx.c |6 --
4 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 74b427f..0b12a98 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -68,6 +68,7 @@
* vcpu->requests bit members
*/
#define KVM_TLB_FLUSH 0
+#define VMX_INJECT_RMODE_IRQ 1
/*
* Address types:
@@ -319,6 +320,7 @@ struct kvm_vcpu {
int guest_mode;
unsigned long requests;
unsigned long irq_summary; /* bit vector: 1 per word in irq_pending */
+ int inject_rmode_irq;
DECLARE_BITMAP(irq_pending, KVM_NR_INTERRUPTS);
unsigned long regs[NR_VCPU_REGS]; /* for rsp: vcpu_load_rsp_rip() */
unsigned long rip; /* needs vcpu_load_rsp_rip() */
@@ -520,6 +522,7 @@ struct kvm_x86_ops {
void (*inject_pending_irq)(struct kvm_vcpu *vcpu);
void (*inject_pending_vectors)(struct kvm_vcpu *vcpu,
struct kvm_run *run);
+ void (*vmx_inject_rmode_irq)(struct kvm_vcpu *vcpu, int irq);
};
extern struct kvm_x86_ops *kvm_x86_ops;
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index f58d49b..0e2bbe5 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -2178,6 +2178,10 @@ again:
if (unlikely(r))
goto out;
+vmx_inject_rmode:
+ if (test_and_clear_bit(VMX_INJECT_RMODE_IRQ, &vcpu->requests))
+ kvm_x86_ops->vmx_inject_rmode_irq(vcpu, vcpu->inject_rmode_irq);
+
preempt_disable();
kvm_x86_ops->prepare_guest_switch(vcpu);
@@ -2194,10 +2198,22 @@ again:
goto out;
}
- if (irqchip_in_kernel(vcpu->kvm))
+ if (irqchip_in_kernel(vcpu->kvm)) {
kvm_x86_ops->inject_pending_irq(vcpu);
- else if (!vcpu->mmio_read_completed)
+ if (test_bit(VMX_INJECT_RMODE_IRQ, &vcpu->requests)) {
+ local_irq_enable();
+ preempt_enable();
+ goto vmx_inject_rmode;
+ }
+ }
+ else if (!vcpu->mmio_read_completed) {
kvm_x86_ops->inject_pending_vectors(vcpu, kvm_run);
+ if (test_bit(VMX_INJECT_RMODE_IRQ, &vcpu->requests)) {
+ local_irq_enable();
+ preempt_enable();
+ goto vmx_inject_rmode;
+ }
+ }
vcpu->guest_mode = 1;
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index f643379..77b19be 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1732,6 +1732,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.set_irq = svm_set_irq,
.inject_pending_irq = svm_intr_assist,
.inject_pending_vectors = do_interrupt_requests,
+ .vmx_inject_rmode_irq = NULL,
};
static int __init svm_init(void)
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 2d75599..f014971 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -1678,10 +1678,11 @@ static void inject_rmode_irq(struct kvm_vcpu *vcpu, int irq)
vmcs_writel(GUEST_RSP, (vmcs_readl(GUEST_RSP) & ~0x) | (sp - 6));
}
-static void vmx_inject_irq(struct kvm_vcpu *vcpu, int irq)
+void vmx_inject_irq(struct kvm_vcpu *vcpu, int irq)
{
if (vcpu->rmode.active) {
- inject_rmode_irq(vcpu, irq);
+ vcpu->inject_rmode_irq = irq;
+ set_bit(VMX_INJECT_RMODE_IRQ, &vcpu->requests);
return;
}
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
@@ -2539,6 +2540,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
.set_irq = vmx_inject_irq,
.inject_pending_irq = vmx_intr_assist,
.inject_pending_vectors = do_interrupt_requests,
+ .vmx_inject_rmode_irq = inject_rmode_irq,
};
static int __init vmx_init(void)
--
1.5.2.4
-
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
[kvm-devel] [PATCH 1/2] making update_dirty_bit get called without disabling preempt
>From d11f64d00e5fd5fdcd6c82bf819653f392e5ad2b Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Mon, 15 Oct 2007 19:24:52 +0200
Subject: [PATCH] making update_dirty_bit get called without disabling preempt
Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
---
drivers/kvm/paging_tmpl.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
index 600b1cc..bd850c4 100644
--- a/drivers/kvm/paging_tmpl.h
+++ b/drivers/kvm/paging_tmpl.h
@@ -156,6 +156,8 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
if (walker->level == PT_PAGE_TABLE_LEVEL) {
walker->gfn = (*ptep & PT_BASE_ADDR_MASK)
>> PAGE_SHIFT;
+ kunmap_atomic(walker->table, KM_USER0);
+ walker->table = NULL;
FNAME(update_dirty_bit)(vcpu, write_fault, ptep,
table_gfn);
break;
@@ -167,6 +169,8 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
walker->gfn = (*ptep & PT_DIR_BASE_ADDR_MASK)
>> PAGE_SHIFT;
walker->gfn += PT_INDEX(addr, PT_PAGE_TABLE_LEVEL);
+ kunmap_atomic(walker->table, KM_USER0);
+ walker->table = NULL;
FNAME(update_dirty_bit)(vcpu, write_fault, ptep,
table_gfn);
break;
--
1.5.2.4
-
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
[kvm-devel] [PATCH 0/2] Swapping:fixing the problem with unsleepable place of kvm and gfn_to_page
this patch remove all the ugly messages from the dmesg, now i think my patch together with Anthony changes can be merged to kvm. thanks to Anthony with his help in working on it. - 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] Add cross compile to top level configuration file
Jerone Young wrote:
> On Mon, 2007-10-15 at 15:13 -0500, Anthony Liguori wrote:
>
>> Jerone Young wrote:
>>
>>> This patch is an improved version of patches sent last week to enable
>>> the top level configuration file for cross compile. This currently
>>> allows x86 & x86-64 to cross compile. But will soon be sending patches
>>> for powerpc embedded once this is accepted. This patches to latest git
>>> and is in git format ;-)
>>>
>>> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
>>>
>>>
>>>
>> Why are you only passing --enable-alsa only x86?
>>
>
> Because for our powerpc stuff we actually want different options. ALSA
> is not a dependency we want.
>
Well, you don't want the dependency, but does that mean noone will ever
want the dependency on anything but x86?
I'm curious why --enable-alsa is here in the first place. QEMU will use
SDL audio by default. Perhaps Avi can shed light on why added in the
first place?
Regards,
Anthony Liguori
>>> +fi
>>> +
>>> +qemudir=`pwd`/qemu
>>> +
>>> +#configure user dir
>>> +(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
>>> + $user_opts --arch="$arch")
>>> +(cd qemu; ./configure --target-list=$target_exec \
>>> --disable-kqemu --extra-cflags="-I $PWD/../user" \
>>> --extra-ldflags="-L $PWD/../user" \
>>> --enable-kvm --kernel-path="$libkvm_kerneldir" \
>>> ---enable-alsa \
>>> ${disable_gcc_check:+"--disable-gcc-check"} \
>>> ---prefix="$prefix"
>>> +--prefix="$prefix" \
>>> +$qemu_opts --cpu="$arch"
>>>
>>>
>> I don't think this is right. You're using two different --cpu options
>> for i386 and x86_64. There really shouldn't be a --cpu option at all
>> for x86.
>>
>
> So the --cpu option is actually a hidden option in qemu & is not on the
> qemu help page .. who know why it isn't but the it's in the code.
>
> It makes since though that if you are going to specify cross-prefix=
> then there is little reason to specify the cpu on the qemu line. As it
> should detect everything from cross compiler.
>
> I'll test this out and send a new patch with the 2 changes.
>
>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>>> )
>>>
>>>
>>> -
>>> cat < config.mak
>>> +ARCH=$arch
>>> PREFIX=$prefix
>>> KERNELDIR=$kerneldir
>>> WANT_MODULE=$want_module
>>> +CC=$cross_prefix$cc
>>> EOF
>>> -
>>>
>>
>>> -
>>> 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
>>>
>> -
>> 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
>>
>
>
>
-
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] Add cross compile to top level configuration file
On Mon, 2007-10-15 at 15:13 -0500, Anthony Liguori wrote:
> Jerone Young wrote:
> > This patch is an improved version of patches sent last week to enable
> > the top level configuration file for cross compile. This currently
> > allows x86 & x86-64 to cross compile. But will soon be sending patches
> > for powerpc embedded once this is accepted. This patches to latest git
> > and is in git format ;-)
> >
> > Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
> >
> >
>
> > diff --git a/configure b/configure
> > --- a/configure
> > +++ b/configure
> > @@ -3,32 +3,30 @@ prefix=/usr/local
> > prefix=/usr/local
> > kerneldir=/lib/modules/$(uname -r)/build
> > want_module=1
> > -qemu_cc=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
> > +cc=gcc
> > +qemu_cc=
> > disable_gcc_check=
> > +cross_prefix=
> > +arch=`uname -m`
> > +target_exec=
> >
> > usage() {
> > cat <<-EOF
> > Usage: $0 [options]
> >
> > Options include:
> > -
> > + --arch=ARCHarchitecture to compile for ($arch)
> > + --cross-prefix=PREFIX prefix for cross compiler
> > --prefix=PREFIXwhere to install things ($prefix)
> > --with-patched-kernel don't use external module
> > --kerneldir=DIRkernel build directory ($kerneldir)
> > - --qemu-cc="$qemu_cc" compiler for qemu (needs gcc3.x) ($qemu_cc)
> > + --qemu-cc=CC compiler for qemu (needs to be gcc 3.x)
> > + Not valid if used with --cross-prefix
> > --disable-gcc-checkdon't insist on gcc-3.x
> > - - this will break running without kvm
> > + CAUTION: using this option may break build
> > EOF
> > exit 1
> > }
> > -
> > -
> > -# prefer gcc if its version is 3.* ( over a compat-gcc )
> > -# do it before parsing command line arguments to enable the user
> > -#to specify a specific gcc he/she likes.
> > -if gcc -v 2>&1 | grep -q 'gcc *version *3\.[2-4]\.[0-9]'; then
> > - qemu_cc=gcc
> > -fi
> >
> > while [[ "$1" = -* ]]; do
> > opt="$1"; shift
> > @@ -53,6 +51,12 @@ while [[ "$1" = -* ]]; do
> > --disable-gcc-check)
> > disable_gcc_check=1
> > ;;
> > + --arch)
> > + arch="$arg"
> > + ;;
> > + --cross-prefix)
> > + cross_prefix="$arg"
> > +;;
> > --help)
> > usage
> > ;;
> > @@ -62,39 +66,71 @@ while [[ "$1" = -* ]]; do
> > esac
> > done
> >
> > -if [[ -z "$qemu_cc" ]]; then
> > -echo "$0: cannot locate gcc 3.x. please install it or specify with
> > --qemu-cc"
> > -exit 1
> > +
> > +# if cc is not specified on the command line
> > +# look for gcc version 3.x
> > +if [[ -z "$qemu_cc" ]] && [[ -z "$cross_prefix" ]]; then
> > +#check for a gcc 3.x version on the system
> > +cc_check=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
> > +#prefer gcc if its version is 3.* ( over a compat-gcc )
> > +gcc_check=$(gcc -v 2>&1 | grep -q 'gcc *version *3\.[2-4]\.[0-9]')
> > +if [[ -n "$cc_check" ]] && [[ -z "$gcc_check" ]] ; then
> > +cc=$cc_check
> > +fi
> > fi
> >
> >
>
> The QEMU that's in git automatically finds the right GCC version so this
> whole check isn't necessary anymore.
This is true. Figured that this was still there for a particular reason.
If this is the case then this can be removed.
>
> Regards,
>
> Anthony Liguori
>
> > +#if qemu_cc is specfied on the command line, set cc=$qemu_cc
> > +if [[ -n "$qemu_cc" ]] && [[ -z "$cross_prefix" ]]; then
> > + cc=$qemu_cc
> > +fi
> > +
> > +#set kenel directory
> > libkvm_kerneldir="$kerneldir"
> > if (( want_module )); then
> > libkvm_kerneldir=$(readlink -f kernel)
> > fi
> >
> > -target_cpu() {
> > -if [[ $(uname -m) = i?86 ]]; then
> > - echo x86_64
> > -else
> > - uname -m
> > -fi
> > -}
> > +#if arch is an x86 arch set to i386
> > +if [[ $arch = i?86 ]]; then
> > + arch="i386"
> > +fi
> >
> > -(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
> > -(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
> > +#see if using a cross compiler or not
> > +qemu_opts=
> > +user_opts=
> > +if [[ -z $cross_prefix ]]; then
> > +qemu_opts+=" --cc=$cc"
> > +user_opts+=" --cc=$cc"
> > +else
> > +qemu_opts+=" --cross-prefix=$cross_prefix"
> > +user_opts+=" --cross-prefix=$cross_prefix"
> > +fi
> > +
> > +#set parameters compiling
> > +if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
> > +target_exec="x86_64-softmmu"
> > +qemu_opts+=" --enable-alsa"
> >
>
> Why are you only passing --enable-alsa only x86?
Because for our powerpc stuff we actually want different options. ALSA
is not a dependency we want.
>
> > +fi
> > +
> > +qemudir=`pwd`/qemu
> > +
> > +#configure user dir
> > +(cd user; ./conf
Re: [kvm-devel] [PATCH 0/4] Swapping
Anthony Liguori wrote: > Izik Eidus wrote: >>> >>> That's not quite what I was wondering. >>> >>> When you do an madvise() in userspace, the result is that when that >>> memory is accessed again, linux will demand-fault in a zero page and >>> COW it appropriately. If we do madvise() on the VA representing >>> guest physical memory, what I'm curious about is whether the guest >>> will actually see this change. If the guest happens to have the >>> page mapped before we do the madvise(), what triggers KVM to kick >>> any shadow page table entries out of it's cache? >>> >>> IIUC, today, after the madvise, the guest will have access to the >>> old page until that entry gets evicted and reloaded from the shadow >>> page table cache. >> ok i am no familier with madvise() so i might talk nonsense but, >> if the guest have the page mapped before the madvise(), this mean we >> have high refernce to it, this is our only protection and as far as i >> understand this should be enough > > Right, we will have a reference to the page. But we want to propagate > this change to the guest. So madvise() may be a bad example. > > What if you wanted to do shared memory for multiple guests. You start > out with an anonymous mmap(), and you now what to mmap() a file in > /dev/shm to be shared among multiple guests so you mmap(MAP_FIXED) to > phys_ram_base + guest_pa in each guest. > > So what if guest_pa was in the guest's shadow page cache? In order > for the guest to see the right hpa (the new shared memory), we have to > be able to evict guest_pa. We could do this with something like > mmu_unshadow(). > > What I don't understand, is how we can have something like > mmu_unshadow() called automatically when an mmap() is initiated from > userspace. We could just add an ioctl() to do it from userspace but I > think it would be nicer if it Just Worked. yea i agree with you, but i dont know either how to do it, we will probably have to look around to see how it can be done. avi any idea? > > Regards, > > Anthony Liguori > >> >> >> >> > - 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] Add cross compile to top level configuration file
Jerone Young wrote:
> This patch is an improved version of patches sent last week to enable
> the top level configuration file for cross compile. This currently
> allows x86 & x86-64 to cross compile. But will soon be sending patches
> for powerpc embedded once this is accepted. This patches to latest git
> and is in git format ;-)
>
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
>
>
> diff --git a/configure b/configure
> --- a/configure
> +++ b/configure
> @@ -3,32 +3,30 @@ prefix=/usr/local
> prefix=/usr/local
> kerneldir=/lib/modules/$(uname -r)/build
> want_module=1
> -qemu_cc=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
> +cc=gcc
> +qemu_cc=
> disable_gcc_check=
> +cross_prefix=
> +arch=`uname -m`
> +target_exec=
>
> usage() {
> cat <<-EOF
> Usage: $0 [options]
>
> Options include:
> -
> + --arch=ARCHarchitecture to compile for ($arch)
> + --cross-prefix=PREFIX prefix for cross compiler
> --prefix=PREFIXwhere to install things ($prefix)
> --with-patched-kernel don't use external module
> --kerneldir=DIRkernel build directory ($kerneldir)
> - --qemu-cc="$qemu_cc" compiler for qemu (needs gcc3.x) ($qemu_cc)
> + --qemu-cc=CC compiler for qemu (needs to be gcc 3.x)
> +Not valid if used with --cross-prefix
> --disable-gcc-checkdon't insist on gcc-3.x
> - - this will break running without kvm
> +CAUTION: using this option may break build
> EOF
> exit 1
> }
> -
> -
> -# prefer gcc if its version is 3.* ( over a compat-gcc )
> -# do it before parsing command line arguments to enable the user
> -#to specify a specific gcc he/she likes.
> -if gcc -v 2>&1 | grep -q 'gcc *version *3\.[2-4]\.[0-9]'; then
> - qemu_cc=gcc
> -fi
>
> while [[ "$1" = -* ]]; do
> opt="$1"; shift
> @@ -53,6 +51,12 @@ while [[ "$1" = -* ]]; do
> --disable-gcc-check)
> disable_gcc_check=1
> ;;
> + --arch)
> + arch="$arg"
> + ;;
> + --cross-prefix)
> + cross_prefix="$arg"
> +;;
> --help)
> usage
> ;;
> @@ -62,39 +66,71 @@ while [[ "$1" = -* ]]; do
> esac
> done
>
> -if [[ -z "$qemu_cc" ]]; then
> -echo "$0: cannot locate gcc 3.x. please install it or specify with
> --qemu-cc"
> -exit 1
> +
> +# if cc is not specified on the command line
> +# look for gcc version 3.x
> +if [[ -z "$qemu_cc" ]] && [[ -z "$cross_prefix" ]]; then
> +#check for a gcc 3.x version on the system
> +cc_check=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
> +#prefer gcc if its version is 3.* ( over a compat-gcc )
> +gcc_check=$(gcc -v 2>&1 | grep -q 'gcc *version *3\.[2-4]\.[0-9]')
> +if [[ -n "$cc_check" ]] && [[ -z "$gcc_check" ]] ; then
> +cc=$cc_check
> +fi
> fi
>
>
The QEMU that's in git automatically finds the right GCC version so this
whole check isn't necessary anymore.
Regards,
Anthony Liguori
> +#if qemu_cc is specfied on the command line, set cc=$qemu_cc
> +if [[ -n "$qemu_cc" ]] && [[ -z "$cross_prefix" ]]; then
> + cc=$qemu_cc
> +fi
> +
> +#set kenel directory
> libkvm_kerneldir="$kerneldir"
> if (( want_module )); then
> libkvm_kerneldir=$(readlink -f kernel)
> fi
>
> -target_cpu() {
> -if [[ $(uname -m) = i?86 ]]; then
> - echo x86_64
> -else
> - uname -m
> -fi
> -}
> +#if arch is an x86 arch set to i386
> +if [[ $arch = i?86 ]]; then
> + arch="i386"
> +fi
>
> -(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
> -(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
> +#see if using a cross compiler or not
> +qemu_opts=
> +user_opts=
> +if [[ -z $cross_prefix ]]; then
> +qemu_opts+=" --cc=$cc"
> +user_opts+=" --cc=$cc"
> +else
> +qemu_opts+=" --cross-prefix=$cross_prefix"
> +user_opts+=" --cross-prefix=$cross_prefix"
> +fi
> +
> +#set parameters compiling
> +if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
> +target_exec="x86_64-softmmu"
> +qemu_opts+=" --enable-alsa"
>
Why are you only passing --enable-alsa only x86?
> +fi
> +
> +qemudir=`pwd`/qemu
> +
> +#configure user dir
> +(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
> + $user_opts --arch="$arch")
> +(cd qemu; ./configure --target-list=$target_exec \
> --disable-kqemu --extra-cflags="-I $PWD/../user" \
> --extra-ldflags="-L $PWD/../user" \
> --enable-kvm --kernel-path="$libkvm_kerneldir" \
> ---enable-alsa \
> ${disable_gcc_check:+"--disable-gcc-check"} \
> ---prefix="$prefix"
> +--prefix="$prefix" \
> +$qemu_opts --cpu="$arch"
>
I don't think this is right. You're using two diffe
Re: [kvm-devel] [PATCH 3/4] Swapping
Izik Eidus wrote:
> Anthony Liguori wrote:
>> Anthony Liguori wrote:
>>> Izik Eidus wrote:
Anthony Liguori wrote:
>
> I think it's just a matter of calling do_mmap() with the
> appropriate parameters. It looks likes there's some drivers call
> do_mmap() directly.
>
yea, i think you right, this is excellent idea!, when we will merge
the swapping to kvm, we will add swapping support to older userspace.
>>>
>>> Here's a patch against your series. The memset in kvmctl ends up
>>> making the guest use all physical memory to start off with but I did
>>> confirm that once the system is under memory pressure, the guest's
>>> memory becomes swappable. Of course, it's quite painful :-)
>>>
>>> A nice thing though is that a lot of the code becomes a bit cleaner
>>> and we can eliminate the phys_mem array entirely.
>>
>>> /* Allocate if a slot is being created */
>>> -if (npages && !new.phys_mem) {
>>> -new.phys_mem = vmalloc(npages * sizeof(struct page *));
>>> -
>>> -if (!new.phys_mem)
>>> -goto out_unlock;
>>> -
>>> +if (npages) {
>>
>> This is wrong apparently. We needed to have new.phys_mem to indicate
>> whether the slot has been created yet or not. The new attached patch
>> uses new.rmap instead of new.phys_mem to accomplish the same goal.
>>
> this patch look good, and indeed make all the things simple.
> but why you didnt use new.phys_mem ?
>> I no longer see the BUG() that I was seeing.
>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>
>>
upsss
ignore me:)
i am idiot: :)
>
>
-
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 0/4] Swapping
Izik Eidus wrote: >> >> That's not quite what I was wondering. >> >> When you do an madvise() in userspace, the result is that when that >> memory is accessed again, linux will demand-fault in a zero page and >> COW it appropriately. If we do madvise() on the VA representing >> guest physical memory, what I'm curious about is whether the guest >> will actually see this change. If the guest happens to have the page >> mapped before we do the madvise(), what triggers KVM to kick any >> shadow page table entries out of it's cache? >> >> IIUC, today, after the madvise, the guest will have access to the old >> page until that entry gets evicted and reloaded from the shadow page >> table cache. > ok i am no familier with madvise() so i might talk nonsense but, > if the guest have the page mapped before the madvise(), this mean we > have high refernce to it, this is our only protection and as far as i > understand this should be enough Right, we will have a reference to the page. But we want to propagate this change to the guest. So madvise() may be a bad example. What if you wanted to do shared memory for multiple guests. You start out with an anonymous mmap(), and you now what to mmap() a file in /dev/shm to be shared among multiple guests so you mmap(MAP_FIXED) to phys_ram_base + guest_pa in each guest. So what if guest_pa was in the guest's shadow page cache? In order for the guest to see the right hpa (the new shared memory), we have to be able to evict guest_pa. We could do this with something like mmu_unshadow(). What I don't understand, is how we can have something like mmu_unshadow() called automatically when an mmap() is initiated from userspace. We could just add an ioctl() to do it from userspace but I think it would be nicer if it Just Worked. Regards, Anthony Liguori > > > > - 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 3/4] Swapping
Anthony Liguori wrote:
> Anthony Liguori wrote:
>> Izik Eidus wrote:
>>> Anthony Liguori wrote:
I think it's just a matter of calling do_mmap() with the
appropriate parameters. It looks likes there's some drivers call
do_mmap() directly.
>>> yea, i think you right, this is excellent idea!, when we will merge
>>> the swapping to kvm, we will add swapping support to older userspace.
>>
>> Here's a patch against your series. The memset in kvmctl ends up
>> making the guest use all physical memory to start off with but I did
>> confirm that once the system is under memory pressure, the guest's
>> memory becomes swappable. Of course, it's quite painful :-)
>>
>> A nice thing though is that a lot of the code becomes a bit cleaner
>> and we can eliminate the phys_mem array entirely.
>
>> /* Allocate if a slot is being created */
>> -if (npages && !new.phys_mem) {
>> -new.phys_mem = vmalloc(npages * sizeof(struct page *));
>> -
>> -if (!new.phys_mem)
>> -goto out_unlock;
>> -
>> +if (npages) {
>
> This is wrong apparently. We needed to have new.phys_mem to indicate
> whether the slot has been created yet or not. The new attached patch
> uses new.rmap instead of new.phys_mem to accomplish the same goal.
>
this patch look good, and indeed make all the things simple.
but why you didnt use new.phys_mem ?
> I no longer see the BUG() that I was seeing.
>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>
-
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 0/4] Swapping
Anthony Liguori wrote: > Izik Eidus wrote: >> Anthony Liguori wrote: >>> Izik Eidus wrote: Anthony Liguori wrote: > I've been playing around with these patches. If I do an > madvise(MADV_DONTNEED) in userspace, when I close the VM, I get > the following bug. My knowledge of the mm is limited but since > madvise(MADV_DONTNEED) effectively does a zap_page_range() I > wonder if we're lacking the necessary callback to also remove any > potential GPA covered by that range from shadow page cache. > > Regards, > > Anthony Liguori it probably beacuse the changes of the first patch, ( that make all present shadow pages rmapped ) Anthony can you please check what happn if you run latest kvm with the patch (of the rmap) and without the patch? >>> >>> It looks like it's my patch for doing an in kernel mmap() to support >>> older userspaces. I'll figure out what the problem is. >>> >>> But at any rate, would madvise() be able to evict the current >>> contents of something in the shadow page cache or will the guest not >>> pick up the new memory until the old gets evicted from the shadow >>> page cache? >> if i understand you right, then madvise() wont harm us, beacuse we >> protect all our shadow memory by removing the writable bit from it. >> therefor the guest cant change anything without we know it. > > That's not quite what I was wondering. > > When you do an madvise() in userspace, the result is that when that > memory is accessed again, linux will demand-fault in a zero page and > COW it appropriately. If we do madvise() on the VA representing guest > physical memory, what I'm curious about is whether the guest will > actually see this change. If the guest happens to have the page > mapped before we do the madvise(), what triggers KVM to kick any > shadow page table entries out of it's cache? > > IIUC, today, after the madvise, the guest will have access to the old > page until that entry gets evicted and reloaded from the shadow page > table cache. ok i am no familier with madvise() so i might talk nonsense but, if the guest have the page mapped before the madvise(), this mean we have high refernce to it, this is our only protection and as far as i understand this should be enough - 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
[kvm-devel] [PATCH] Add cross compile to top level configuration file
This patch is an improved version of patches sent last week to enable
the top level configuration file for cross compile. This currently
allows x86 & x86-64 to cross compile. But will soon be sending patches
for powerpc embedded once this is accepted. This patches to latest git
and is in git format ;-)
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -3,32 +3,30 @@ prefix=/usr/local
prefix=/usr/local
kerneldir=/lib/modules/$(uname -r)/build
want_module=1
-qemu_cc=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
+cc=gcc
+qemu_cc=
disable_gcc_check=
+cross_prefix=
+arch=`uname -m`
+target_exec=
usage() {
cat <<-EOF
Usage: $0 [options]
Options include:
-
+ --arch=ARCHarchitecture to compile for ($arch)
+ --cross-prefix=PREFIX prefix for cross compiler
--prefix=PREFIXwhere to install things ($prefix)
--with-patched-kernel don't use external module
--kerneldir=DIRkernel build directory ($kerneldir)
- --qemu-cc="$qemu_cc" compiler for qemu (needs gcc3.x) ($qemu_cc)
+ --qemu-cc=CC compiler for qemu (needs to be gcc 3.x)
+ Not valid if used with --cross-prefix
--disable-gcc-checkdon't insist on gcc-3.x
- - this will break running without kvm
+ CAUTION: using this option may break build
EOF
exit 1
}
-
-
-# prefer gcc if its version is 3.* ( over a compat-gcc )
-# do it before parsing command line arguments to enable the user
-#to specify a specific gcc he/she likes.
-if gcc -v 2>&1 | grep -q 'gcc *version *3\.[2-4]\.[0-9]'; then
- qemu_cc=gcc
-fi
while [[ "$1" = -* ]]; do
opt="$1"; shift
@@ -53,6 +51,12 @@ while [[ "$1" = -* ]]; do
--disable-gcc-check)
disable_gcc_check=1
;;
+ --arch)
+ arch="$arg"
+ ;;
+ --cross-prefix)
+ cross_prefix="$arg"
+;;
--help)
usage
;;
@@ -62,39 +66,71 @@ while [[ "$1" = -* ]]; do
esac
done
-if [[ -z "$qemu_cc" ]]; then
-echo "$0: cannot locate gcc 3.x. please install it or specify with --qemu-cc"
-exit 1
+
+# if cc is not specified on the command line
+# look for gcc version 3.x
+if [[ -z "$qemu_cc" ]] && [[ -z "$cross_prefix" ]]; then
+#check for a gcc 3.x version on the system
+cc_check=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
+#prefer gcc if its version is 3.* ( over a compat-gcc )
+gcc_check=$(gcc -v 2>&1 | grep -q 'gcc *version *3\.[2-4]\.[0-9]')
+if [[ -n "$cc_check" ]] && [[ -z "$gcc_check" ]] ; then
+cc=$cc_check
+fi
fi
+#if qemu_cc is specfied on the command line, set cc=$qemu_cc
+if [[ -n "$qemu_cc" ]] && [[ -z "$cross_prefix" ]]; then
+ cc=$qemu_cc
+fi
+
+#set kenel directory
libkvm_kerneldir="$kerneldir"
if (( want_module )); then
libkvm_kerneldir=$(readlink -f kernel)
fi
-target_cpu() {
-if [[ $(uname -m) = i?86 ]]; then
- echo x86_64
-else
- uname -m
-fi
-}
+#if arch is an x86 arch set to i386
+if [[ $arch = i?86 ]]; then
+ arch="i386"
+fi
-(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
-(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
+#see if using a cross compiler or not
+qemu_opts=
+user_opts=
+if [[ -z $cross_prefix ]]; then
+qemu_opts+=" --cc=$cc"
+user_opts+=" --cc=$cc"
+else
+qemu_opts+=" --cross-prefix=$cross_prefix"
+user_opts+=" --cross-prefix=$cross_prefix"
+fi
+
+#set parameters compiling
+if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
+target_exec="x86_64-softmmu"
+qemu_opts+=" --enable-alsa"
+fi
+
+qemudir=`pwd`/qemu
+
+#configure user dir
+(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
+ $user_opts --arch="$arch")
+(cd qemu; ./configure --target-list=$target_exec \
--disable-kqemu --extra-cflags="-I $PWD/../user" \
--extra-ldflags="-L $PWD/../user" \
--enable-kvm --kernel-path="$libkvm_kerneldir" \
---enable-alsa \
${disable_gcc_check:+"--disable-gcc-check"} \
---prefix="$prefix"
+--prefix="$prefix" \
+$qemu_opts --cpu="$arch"
)
-
cat < config.mak
+ARCH=$arch
PREFIX=$prefix
KERNELDIR=$kerneldir
WANT_MODULE=$want_module
+CC=$cross_prefix$cc
EOF
-
-
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 0/4] Swapping
Izik Eidus wrote: > Anthony Liguori wrote: >> Izik Eidus wrote: >>> Anthony Liguori wrote: I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache. Regards, Anthony Liguori >>> it probably beacuse the changes of the first patch, ( that make all >>> present shadow pages rmapped ) >>> Anthony can you please check what happn if you run latest kvm with >>> the patch (of the rmap) and without the patch? >> >> It looks like it's my patch for doing an in kernel mmap() to support >> older userspaces. I'll figure out what the problem is. >> >> But at any rate, would madvise() be able to evict the current >> contents of something in the shadow page cache or will the guest not >> pick up the new memory until the old gets evicted from the shadow >> page cache? > if i understand you right, then madvise() wont harm us, beacuse we > protect all our shadow memory by removing the writable bit from it. > therefor the guest cant change anything without we know it. That's not quite what I was wondering. When you do an madvise() in userspace, the result is that when that memory is accessed again, linux will demand-fault in a zero page and COW it appropriately. If we do madvise() on the VA representing guest physical memory, what I'm curious about is whether the guest will actually see this change. If the guest happens to have the page mapped before we do the madvise(), what triggers KVM to kick any shadow page table entries out of it's cache? IIUC, today, after the madvise, the guest will have access to the old page until that entry gets evicted and reloaded from the shadow page table cache. Regards, Anthony Liguori >> >> Regards, >> >> Anthony Liguori >> > > - 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 3/4] Swapping
Anthony Liguori wrote:
Izik Eidus wrote:
Anthony Liguori wrote:
I think it's just a matter of calling do_mmap() with the appropriate
parameters. It looks likes there's some drivers call do_mmap()
directly.
yea, i think you right, this is excellent idea!, when we will merge
the swapping to kvm, we will add swapping support to older userspace.
Here's a patch against your series. The memset in kvmctl ends up
making the guest use all physical memory to start off with but I did
confirm that once the system is under memory pressure, the guest's
memory becomes swappable. Of course, it's quite painful :-)
A nice thing though is that a lot of the code becomes a bit cleaner
and we can eliminate the phys_mem array entirely.
/* Allocate if a slot is being created */
-if (npages && !new.phys_mem) {
-new.phys_mem = vmalloc(npages * sizeof(struct page *));
-
-if (!new.phys_mem)
-goto out_unlock;
-
+if (npages) {
This is wrong apparently. We needed to have new.phys_mem to indicate
whether the slot has been created yet or not. The new attached patch
uses new.rmap instead of new.phys_mem to accomplish the same goal.
I no longer see the BUG() that I was seeing.
Regards,
Anthony Liguori
Subject: [PATCH] Allocate userspace memory for older userspace (v2)
From: Anthony Liguori <[EMAIL PROTECTED]>
Cc: Avi Kivity <[EMAIL PROTECTED]>
Cc: Izik Eidus <[EMAIL PROTECTED]>
Allocate a userspace buffer for older userspaces. Also eliminate phys_mem
buffer. The memset() in kvmctl really kills initial memory usage but swapping
does even with old userspaces.
Since v1, fixed a bug in slot creation.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 74b427f..c904ea3 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -405,10 +405,8 @@ struct kvm_memory_slot {
gfn_t base_gfn;
unsigned long npages;
unsigned long flags;
- struct page **phys_mem;
unsigned long *rmap;
unsigned long *dirty_bitmap;
- int user_alloc; /* user allocated memory */
unsigned long userspace_addr;
};
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index f58d49b..17d3c7d 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -319,36 +320,21 @@ static struct kvm *kvm_create_vm(void)
return kvm;
}
-static void kvm_free_kernel_physmem(struct kvm_memory_slot *free)
-{
- int i;
-
- for (i = 0; i < free->npages; ++i)
- if (free->phys_mem[i])
- __free_page(free->phys_mem[i]);
-}
-
/*
* Free any memory in @free but not in @dont.
*/
static void kvm_free_physmem_slot(struct kvm_memory_slot *free,
struct kvm_memory_slot *dont)
{
- if (!dont || free->phys_mem != dont->phys_mem)
- if (free->phys_mem) {
- if (!free->user_alloc)
-kvm_free_kernel_physmem(free);
- vfree(free->phys_mem);
- }
if (!dont || free->rmap != dont->rmap)
vfree(free->rmap);
if (!dont || free->dirty_bitmap != dont->dirty_bitmap)
vfree(free->dirty_bitmap);
- free->phys_mem = NULL;
free->npages = 0;
free->dirty_bitmap = NULL;
+ free->rmap = NULL;
}
static void kvm_free_physmem(struct kvm *kvm)
@@ -731,10 +717,6 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
goto out_unlock;
}
- /* Deallocate if slot is being removed */
- if (!npages)
- new.phys_mem = NULL;
-
/* Free page dirty bitmap if unneeded */
if (!(new.flags & KVM_MEM_LOG_DIRTY_PAGES))
new.dirty_bitmap = NULL;
@@ -742,29 +724,27 @@ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
r = -ENOMEM;
/* Allocate if a slot is being created */
- if (npages && !new.phys_mem) {
- new.phys_mem = vmalloc(npages * sizeof(struct page *));
-
- if (!new.phys_mem)
- goto out_unlock;
-
+ if (npages && !new.rmap) {
new.rmap = vmalloc(npages * sizeof(struct page *));
if (!new.rmap)
goto out_unlock;
- memset(new.phys_mem, 0, npages * sizeof(struct page *));
memset(new.rmap, 0, npages * sizeof(*new.rmap));
- if (user_alloc) {
- new.user_alloc = 1;
+
+ if (user_alloc)
new.userspace_addr = mem->userspace_addr;
- } else {
- for (i = 0; i < npages; ++i) {
-new.phys_mem[i] = alloc_page(GFP_HIGHUSER
- | __GFP_ZERO);
-if (!new.phys_mem[i])
- goto out_unlock;
- }
+ else {
+ down_write(¤t->mm->mmap_sem);
+ new.userspace_addr = do_mmap(NULL, 0,
+ npages * PAGE_SIZE,
+ PROT_READ | PROT_WRITE,
+ MAP_SHARED | MAP_ANONYMOUS,
+ 0);
+ up_write(¤t->mm->mmap_sem);
+
+ if (new.userspace_addr > -1024UL)
+goto out_unlock;
}
}
@@ -1029,6 +1009,8 @@ struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn)
struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
{
struct kvm_memory_slot *slot;
+ struct page *page[1];
+ int npages;
gfn = unalias_gfn(kvm, gfn);
slot = __gfn_to_memslot(kvm, gfn);
@@ -1036,24 +1018,
Re: [kvm-devel] [PATCH 0/4] Swapping
Anthony Liguori wrote: > Izik Eidus wrote: >> Anthony Liguori wrote: >>> I've been playing around with these patches. If I do an >>> madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the >>> following bug. My knowledge of the mm is limited but since >>> madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder >>> if we're lacking the necessary callback to also remove any potential >>> GPA covered by that range from shadow page cache. >>> >>> Regards, >>> >>> Anthony Liguori >> it probably beacuse the changes of the first patch, ( that make all >> present shadow pages rmapped ) >> Anthony can you please check what happn if you run latest kvm with >> the patch (of the rmap) and without the patch? > > It looks like it's my patch for doing an in kernel mmap() to support > older userspaces. I'll figure out what the problem is. > > But at any rate, would madvise() be able to evict the current contents > of something in the shadow page cache or will the guest not pick up > the new memory until the old gets evicted from the shadow page cache? if i understand you right, then madvise() wont harm us, beacuse we protect all our shadow memory by removing the writable bit from it. therefor the guest cant change anything without we know it. > > Regards, > > Anthony Liguori > - 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
[kvm-devel] KVM: Fix the invlpg instruction emulation on AMD64
The patch below removes the check for c->modrm_reg == 7 to detect the invlpg instruction, as it was the case before before commit aa38840d3d2e0a804e628077df8d8879b496d741. This fixes the boot of FreeBSD on an AMD64 CPU. It also moves the assignation of c->src.bytes after the test as it is not needed for the invlpg instruction. Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]> diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c index fa33fcd..01aa952 100644 --- a/drivers/kvm/x86_emulate.c +++ b/drivers/kvm/x86_emulate.c @@ -824,12 +824,10 @@ modrm_done: c->src.bytes = 4; goto srcmem_common; case SrcMem: - c->src.bytes = (c->d & ByteOp) ? 1 : - c->op_bytes; /* Don't fetch the address for invlpg: it could be unmapped. */ - if (c->twobyte && c->b == 0x01 - && c->modrm_reg == 7) + if (c->twobyte && c->b == 0x01) break; + c->src.bytes = (c->d & ByteOp) ? 1 : c->op_bytes; srcmem_common: c->src.type = OP_MEM; break; -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net - 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 0/4] Swapping
Izik Eidus wrote: > Anthony Liguori wrote: >> I've been playing around with these patches. If I do an >> madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the >> following bug. My knowledge of the mm is limited but since >> madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder >> if we're lacking the necessary callback to also remove any potential >> GPA covered by that range from shadow page cache. >> >> Regards, >> >> Anthony Liguori > it probably beacuse the changes of the first patch, ( that make all > present shadow pages rmapped ) > Anthony can you please check what happn if you run latest kvm with the > patch (of the rmap) and without the patch? It looks like it's my patch for doing an in kernel mmap() to support older userspaces. I'll figure out what the problem is. But at any rate, would madvise() be able to evict the current contents of something in the shadow page cache or will the guest not pick up the new memory until the old gets evicted from the shadow page cache? Regards, Anthony Liguori - 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 0/4] Swapping
Anthony Liguori wrote: > I've been playing around with these patches. If I do an > madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the > following bug. My knowledge of the mm is limited but since > madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if > we're lacking the necessary callback to also remove any potential GPA > covered by that range from shadow page cache. > > Regards, > > Anthony Liguori it probably beacuse the changes of the first patch, ( that make all present shadow pages rmapped ) Anthony can you please check what happn if you run latest kvm with the patch (of the rmap) and without the patch? - 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 0/4] Swapping
I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache. Regards, Anthony Liguori [ 860.724555] rmap_remove: 81004c48cf00 506d1025 0->BUG [ 860.724603] [ cut here ] [ 860.724606] kernel BUG at /home/anthony/git/fresh/kvm-userspace/kernel/mmu.c:433! [ 860.724608] invalid opcode: [1] SMP [ 860.724611] CPU 0 [ 860.724613] Modules linked in: kvm_intel kvm i915 drm af_packet rfcomm l2cap bluetooth nbd thinkpad_acpi ppdev acpi_cpufreq cpufreq_userspace cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_ondemand freq_table ac bay battery container video sbs button dock ipv6 bridge ipt_REJECT xt_state xt_tcpudp iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables x_tables deflate zlib_deflate twofish twofish_common camellia serpent blowfish des cbc aes xcbc sha256 sha1 crypto_null af_key sbp2 lp joydev arc4 ecb blkcipher snd_hda_intel snd_pcm_oss snd_mixer_oss iwl4965 snd_pcm iwlwifi_mac80211 pcmcia snd_seq_dummy sdhci snd_seq_oss cfg80211 parport_pc parport serio_raw psmouse mmc_core pcspkr yenta_socket rsrc_nonstatic pcmcia_core intel_agp snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq shpchp pci_hotplug snd_timer snd_seq_device snd soundcore snd_page_alloc evdev ext3 jbd mbcache sg sr_mod cdrom sd_mod usbhid hid ata_piix ata_generic libata scsi_mod ohci1394 ieee1394 ehci_hcd e1000 uhci_hcd usbcore dm_mirror dm_snapshot dm_mod thermal processor fan fuse apparmor commoncap [ 860.724688] Pid: 7372, comm: qemu-system-x86 Not tainted 2.6.22-14-generic #1 [ 860.724690] RIP: 0010:[] [] :kvm:rmap_remove+0xb3/0x190 [ 860.724704] RSP: 0018:81004f079d28 EFLAGS: 00010292 [ 860.724706] RAX: 0040 RBX: 81004ccc9580 RCX: 80534b68 [ 860.724709] RDX: 80534b68 RSI: 0086 RDI: 80534b60 [ 860.724711] RBP: 81004c48cf00 R08: R09: [ 860.724714] R10: 805ce880 R11: 8021e2c0 R12: 81004cda [ 860.724716] R13: 81004ccc9580 R14: 81004cda R15: 000ff000 [ 860.724719] FS: 2b55f14e6d30() GS:8056() knlGS: [ 860.724721] CS: 0010 DS: 002b ES: 002b CR0: 8005003b [ 860.724724] CR2: 2b55f0129680 CR3: 00201000 CR4: 26e0 [ 860.724726] Process qemu-system-x86 (pid: 7372, threadinfo 81004f078000, task 810056d974a0) [ 860.724728] Stack: 81004c48cf00 01e0 883851e4 [ 860.724734] 8100672cf650 81004c63a000 81004c63a000 81004cda [ 860.724739] 8100512056a8 810050c75100 81004dfb9a90 88385453 [ 860.724743] Call Trace: [ 860.724755] [] :kvm:kvm_mmu_zap_page+0x214/0x250 [ 860.724769] [] :kvm:free_mmu_pages+0x23/0x50 [ 860.724777] [] :kvm:kvm_mmu_destroy+0x1d/0x70 [ 860.724788] [] :kvm:kvm_vcpu_uninit+0x11/0x30 [ 860.724795] [] :kvm_intel:vmx_free_vcpu+0x5b/0x70 [ 860.724803] [] :kvm:kvm_destroy_vm+0xca/0x130 [ 860.724813] [] :kvm:kvm_vm_release+0x10/0x20 [ 860.724820] [] __fput+0xc1/0x1e0 [ 860.724834] [] :kvm:kvm_vcpu_release+0x1a/0x30 [ 860.724838] [] __fput+0xc1/0x1e0 [ 860.724848] [] filp_close+0x54/0x90 [ 860.724854] [] put_files_struct+0xed/0x120 [ 860.724864] [] do_exit+0x1a1/0x940 [ 860.724878] [] do_group_exit+0x2c/0x80 [ 860.724884] [] system_call+0x7e/0x83 [ 860.724899] [ 860.724900] [ 860.724901] Code: 0f 0b eb fe 48 89 c7 48 83 e7 fe 0f 84 a1 00 00 00 45 31 c0 [ 860.724911] RIP [] :kvm:rmap_remove+0xb3/0x190 [ 860.724919] RSP [ 860.724921] Fixing recursive fault but reboot is needed! Izik Eidus wrote: > this patchs allow the guest not shadowed memory to be swapped out. > > to make it the must effective you should run -kvm-shadow-memory 1 (witch > will make your machine slow) > with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb > on physical host! > > when not using -kvm-shadow-memory, i saw 4100mb machine getting to as > low as 168mb on the physical host (not as bad as i thought it would be, > and surely not as bad as it can be with 41mb of shadow pages :)) > > > it seems to be very stable, it didnt crushed to me once, and i was able > to run: > 2 3giga each windows xp + 5giga linux guest > > and > 2 4.1 giga each windows xp and 2 2giga each windows xp. > > few things to note: > ignore for now the ugly messages at dmesg, it is due to the fact that > gfn_to_page try to sleep while local intrreupts disabled ( we have to > split some emulator function so it wont do it) > > and i saw some issue with the new rmapp at fedora 7 live
Re: [kvm-devel] [RFC] Paravirt timer for KVM
On 10/15/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > If we want to make the clocksource useful for Windows we need to go > through the apic as that will allow the TPR to mask the interrupt when > Windows isn't ready to receive it. However I don't know whether it is > possible to integrate a paravirt clocksource into Windows. My politically-correct side told me to say that the solution that works also in Windows is the best one ;-) > For Linux, we might as well go further and provide a completely > paravirtualized irqchip instead of trying to integrate a paravirtualized > clocksource into a fullyvirtualized irqchip. > Yes, definitely. In your opinion, what's the size of the gap between the "we can", and the "we should" here? -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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] [RFC] Paravirt timer for KVM
On 10/15/07, Carsten Otte <[EMAIL PROTECTED]> wrote: > Gerd Hoffmann wrote: > > With VT you can attempt to make that invisible to the guest using the > > tsc offset field. Probably svm can do that too (didn't check docs > > though). kvm-lite can't (what is the status btw?). Xen "solves" that > > by not doing power management *evil grin*. > On s390, we've had an instruction for that ever since (store clock), > that works with an offset field with hardware support. Works great for us. I've heard s390 also have some special instructions to solve the halting problem. ;-) > If VT and SVM can do the same, I'd vote for using it if we can. I was in the opposite side of gerd: I knew svm did it, not sure about vt ;-) -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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] [RFC] Paravirt timer for KVM
On 10/15/07, Gerd Hoffmann <[EMAIL PROTECTED]> wrote: > > Host should know. Well, I hope. Dunno whenever one really can be sure > in all cases given all the different CPUs and tsc implementations. In the same way we can be sure about hardware for everything else: Well... not being _quite_ sure ;-) > With VT you can attempt to make that invisible to the guest using the > tsc offset field. Probably svm can do that too (didn't check docs > though). kvm-lite can't (what is the status btw?). Xen "solves" that > by not doing power management *evil grin*. Well, my previous understanding was that if the CPU marks the tsc as stable, it _won't_ stop even in C3, and it was done this way exactly to make sure there are a stable source for timing. But it does not really matter. We have two options: * Not considering tsc stable at all if sleeps, and then using the tsc just for adjustments. * Considering the tsc stable, but taking the time the cpu spend sleeping into account, and returning some sorf of "return tsc + total_time_spent_sleeping_in_so_deep_sleep_states_such_as_C3" . I specially liked the naming. > Nevertheless it is probably much easier to go with pv timers (or maybe > emulate hpet timers). At this time, I am for pv timers. (Why would I have written it in the first place??). But indeed, a discussion about the emulation alternative is healthy. -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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] [RFC] Paravirt timer for KVM
On 10/15/07, Avi Kivity <[EMAIL PROTECTED]> wrote: > Gerd Hoffmann wrote: > > > >> 2) the TSC would have to be used as a clocksource. You don't know the > >> frequency which is the first problem with using the TSC but some systems > >> have a TSC that changes frequencies. > >> > > > > Also note the tsc may stop ticking if the CPU goes sleep in C3, which > > IMHO makes the tsc almost useless as clocksource for guests ... > > > > But the host knows that, right? So it can update the guest's timebase? Yes, that's the whole point. -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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] qemu-system-x86_64 locks hard when used with kvm
Hi, On Monday 15 October 2007, you wrote: > Jan Frey wrote: > > So you can see AMD's "svm" is existent. > > Host's kernel is 2.6.23.1, config file is attached. > > KVM/Qemu sources I've tried include -37, -40, -45 and -46. > > > > When I run something like > > qemu-system-x86_64 -m 384 -no-kvm > > > > The virtual machine boots and everything works fine (except the > > slowliness ;-)). > > But when I try without the "-no-kvm" switch the whole host machine > > immediately freezes hard (no windows come up, no text on the console, > > mouse frozen, amazing though that machine still reacts to ping on > > network.. but anyway, even reset button at the PC doesn't help, I've > > got to switch off power..) > > > > The host distribution is FC6. > > > > Am I doing something substantially wrong? > > Can you set up netconsole or serial console on that machine and grab the > kernel output? Currently I don't have really much time.. could you point me to some guide or manual about what to do exactly? I'll try to do so in a few days.. Best regards, Jan -- Jan Frey linux [at] janfrey.de - 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] [RFC] Paravirt timer for KVM
On 10/15/07, Dong, Eddie <[EMAIL PROTECTED]> wrote: > > >>> 1) the PIT is periodic. a PV timer can offer a one shot > >timer which > >>> enables dynticks. > >>> > >> > >> Obviously people have figured out how to do dynticks on real x86 > >> hardware, so I don't accept this reason. :) > >> > > > >Using more advanced timers like the HPET. > > > > I'd think there is no reason for virtual timer to be PIT like, which > is mostly due to historic reason. > > If we need to make it close to native timer device, HPET is much > better than PIT for virtual time to look like. > Besides of course, the fact that you'd still have to keep the PIT timer around, for this same historical reason: It lives in an emulation layer that can't make too much assumptions about what's running on it, and it may well use the PIT exclusively. And we end up with two code bases to maintain. Obviously, as everything else, it's a trade-off. If the only benefit of an HPET like timer is its programability, then the paravirt timer solves this problem with less effort. If there are others, it might well be worth it. -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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] [RFC] Paravirt timer for KVM
On 10/12/07, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
>
> What makes you think this is page-aligned?
Nothing.
> > + if (kvm_hypercall1(KVM_HCALL_SET_SHARED_PAGE, shared_page))
> > + return;
>
> Here you're passing a virtual address across the guest/host interface,
> which is something we've previously agreed is bad.
And that's the reason for the "nothing". It was just the easier way,
and I'm not aware of any discussion in which it was agreed bad. I'll
dig into the archives, but it would be a lot easier if you give me
some pointers ;-)
for the overall picture, it does not really make a difference, so if
this is all that a bad idea, I can change it, no big deal.
> Are you intending this shared page to contain other data in the future,
> or is it just poorly named?
Well, this is still a work in progress, so the accurate answer should
be: Something in the middle, between "more data", and "poorly named".
I think more data can be in, but right now, everything I intend to
(maybe) put in is timer related, so a rename could go well anyway.
> > +struct kvm_hv_clock {
> > + int stable_tsc; /* use raw tsc for clock_read */
> > + unsigned long tsc_mult;
> > + struct timespec now;
> > + u64 last_tsc;
> > + /* That's the wall clock, not the water closet */
> > + struct timespec wc;
> > +};
>
> This isn't even good for x86: you're using "long" in a binary interface!
> You're also using timespec, and what sort of binary compatibility
> guarantees would you like to make about that?
>
Binary guarantees goes in version two ;-)
But c'mon, now that I'm starting to be able to make some merely
decents puns in english, I put one very well placed there, and you
come telling me about binary compatiblity?
Now seriously, the long is just my bad, but I'm not aware of any
complications regarding the timespec. You are welcome to enlighten me.
(Meanwhile, I'll go look at it)
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
-
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] [RFC] Paravirt timer for KVM
On 10/12/07, Hollis Blanchard <[EMAIL PROTECTED]> wrote: > > 2) the TSC would have to be used as a clocksource. You don't know the > > frequency which is the first problem with using the TSC but some systems > > have a TSC that changes frequencies. A PV time source gives you more > > stable clocksource (although as in glommer's patch, when the TSC can be > > used, it's better to use it). > > As I understand it, the TSC is based on CPU frequency, which changes > with power management. Architectural bug. No. The TSC _used_ to be tied to CPU frequency. Current architectural trends keep it constant, and provides other methods for cycle counting. So in newer machines, the tsc should be constant. > However, PV time still doesn't help here: > * The TSC is _user_ accessible, so PV time support in the guest > kernel doesn't solve the problem. I'm not sure about which (of them) problem you are talking about here. > * It looks like external agents can perform out-of-kernel > frequency scaling on x86 (at least I see options for it on IBM > blades). So there must already exist some mechanism for a kernel > to be informed that the TSC frequency has been changed. If the TSC frequency can be changed, I don't use tsc as a ultimate resort of timing at all, but rather, just for micro-adjustments. > > 3) a PV clock can support stolen time calculation which there really > > isn't a concept of with emulation. > > This is true, and I know other platforms support this functionality. I > think it's mostly useful for process time accounting. Is that actually > supported in this patch? > > -- > Hollis Blanchard > IBM Linux Technology Center > > -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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] [RFC] Paravirt timer for KVM
On 10/12/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > * Measure the time it takes for a hypercall, and subtract this time
> > for calculating the expiry time for the timer event.
> >
>
> I don't think there's much point in trying to do stuff like this. The
> guest can be preempted at any time, so there's an arbitrary amount of
> time between deciding to set a timeout, and the time the timeout
> actually happens.
Yes, we can't be precise. But my point here is just being _more_
accurate whenever possible. Yes, it might have been preempted, we
don't know how much time it spent out, but at least this time has
elapsed. It's a win in some scenarios, without too much overhead but
an initial measure and a summation.
Even with tsc adjustments to wallclock, and clock read, I'm using it
regardless of the host having accurate tsc. My main point behind it is
that it will, accurate or not, be _more_ accurate than the simple
version.
Of course, we can discuss if it will really make a difference.
> > + * If the platform provides a stable tsc, we just use it, and there is no
> > need
> > + * for the host to update anything.
>
>
> How would you deal with suspend/resume/migrate? Also, do you assume
> that stable_tsc also means synchronized tsc on an SMP host?
I have to think further on that.
But for all cases , I think that the host knows what happened, and can
adjust the timer accordingly. About sync tsc, this code shouldn't be
making this assumption, but right now... it is. I'll think further.
> So this returns a tsc here? >
[ .. snip .. ]
> ---> But returns ns here?
Yes. But if you look below, (unless I've really forgot to include in
the patch I fired out), I change the multiplier in case we're using a
tsc value. We multiply by one if using nanosecond timer, and by a host
provided multiplier if tsc timer.
>
> > + }
> > +
> > + do {
> > + last_tsc = hv_clock.last_tsc;
> > + rmb();
> > + now = &hv_clock.now;
> >
>
> Shouldn't this be taking a copy of now, rather than a pointer to it?
> Otherwise what's the point of this loop?
Yes, thanks.
> > + rmb();
> > + } while (hv_clock.last_tsc != last_tsc);
> >
>
> This won't be an atomic compare on 32-bit; it could get confused by
> seeing a half-updated tsc value.
You are right, it might be better using a version number like xen does, then.
humm... Rusty's approach of checking against seconds, and then using
nanoseconds only if it has not yet changed may work... but maybe not
as well, due to the tsc adjustments. Right now, I'm more inclined to
the first option.
> >
>
> Not worthwhile. It would be better to make the hypercall take an
> absolute time, and pass it now+delta. At least then if you get
> preempted past the timeout period you can return -ETIME, and the clock
> subsystem will know what to do.
Since the host and guest times are synchronized by assumption, it
might work. I'll give it a try.
> > +#ifdef CONFIG_KVM_CLOCK
> > + kvmclock_init();
> > +#endif
> >
>
> Why is this necessary? Can't you hook one of the existing pvops?
Well, as you all have seen, I've just arrived from weekend, just took
an overlook over all the answers, but I think anthony already answered
this one: Someone has to override the pvops.
However, I think I can do better on this, doing what I did for vsmp on
x86_64, by using ARCH_INIT to check for availability. To be honest, I
considered both approaches, but saw no clear benefit in any, against
the other, and did this way just because vmi is already there.
But yeah, it seems to have some special requirements for placement,
that we do not. If you feel more confortable with it, I can move it to
ARCH_INIT.
>
> J
>
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
-
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] [RFC] Paravirt timer for KVM
Glauber de Oliveira Costa wrote: >> >> It might be better to just rely on the in-kernel APIC to inject an >> interrupt for the clock (via kvm_pic_set_irq()). >> >> > > > After trying this option a little bit, it does not seemed worthwhile > to me. But it might well have been due to some misunderstanding from > my part, and I can take a look again. Basically, we can't do it in the > timer function because it is protected by a mutex. the hrtimer > function runs in interrupt context, so we'd have to flag and signal > anyway. > > "Interrupts for the clock" needs special irq lines anyway. (Well, VMI > masks it and does a whole lot of work to use the apic, but I prefer > the xen way, in which irq lines are triggered directly), so if I > remember the code correctly, we'd have to put some code on for those > lines anyway. > > I may be a little paranoid here, but as it does not seem we're going > to be able to use all code structure as is, at least this way we avoid > the apic code path in favour of a simpler one. But maybe it's really > not worth it > > I'd see an direct advantage for that if we are going to use the local > apic for the delivery, but then it complicates the kernel side, as it > already has an apic clockevents registered, with a interrupt handler > on its own. > > If we want to make the clocksource useful for Windows we need to go through the apic as that will allow the TPR to mask the interrupt when Windows isn't ready to receive it. However I don't know whether it is possible to integrate a paravirt clocksource into Windows. For Linux, we might as well go further and provide a completely paravirtualized irqchip instead of trying to integrate a paravirtualized clocksource into a fullyvirtualized irqchip. -- error compiling committee.c: too many arguments to function - 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] [RFC] Paravirt timer for KVM
> > +
> > +void __init kvmclock_init(void)
> > +{
> > +
> > + unsigned long shared_page = (unsigned long)&hv_clock;
> > + /*
> > + * If we can't use the paravirt clock, just go with
> > + * the usual timekeeping
> > + */
> > + if (!kvm_para_available() || no_kvmclock)
> > + return;
> >
>
> You should also check kvm_para_has_feature() and define a feature flag
> for the clock.
Ok.
> > +static int kvm_get_pvclock_interrupt(struct kvm_vcpu *v)
> > +{
> > + int ret = v->timer_vector;
> > + v->timer_vector = -1;
> > + return ret;
> > +}
> > /*
> > * Read pending interrupt vector and intack.
> > */
> > @@ -51,7 +59,9 @@ int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
> > struct kvm_pic *s;
> > int vector;
> >
> > - vector = kvm_get_apic_interrupt(v); /* APIC */
> > + vector = kvm_get_pvclock_interrupt(v);
> > + if (vector == -1)
> > + vector = kvm_get_apic_interrupt(v); /* APIC */
> >
>
> It might be better to just rely on the in-kernel APIC to inject an
> interrupt for the clock (via kvm_pic_set_irq()).
>
After trying this option a little bit, it does not seemed worthwhile
to me. But it might well have been due to some misunderstanding from
my part, and I can take a look again. Basically, we can't do it in the
timer function because it is protected by a mutex. the hrtimer
function runs in interrupt context, so we'd have to flag and signal
anyway.
"Interrupts for the clock" needs special irq lines anyway. (Well, VMI
masks it and does a whole lot of work to use the apic, but I prefer
the xen way, in which irq lines are triggered directly), so if I
remember the code correctly, we'd have to put some code on for those
lines anyway.
I may be a little paranoid here, but as it does not seem we're going
to be able to use all code structure as is, at least this way we avoid
the apic code path in favour of a simpler one. But maybe it's really
not worth it
I'd see an direct advantage for that if we are going to use the local
apic for the delivery, but then it complicates the kernel side, as it
already has an apic clockevents registered, with a interrupt handler
on its own.
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
-
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] [RFC] Paravirt timer for KVM
Hollis Blanchard wrote: >> >> I'd think there is no reason for virtual timer to be PIT like, which >> is mostly due to historic reason. >> >> If we need to make it close to native timer device, HPET is much >> better than PIT for virtual time to look like. >> > > Fine, so why do we need PV time when we can emulate the HPET? > A pv timebase can require zero exits while any emulated timebase will require at least one. -- error compiling committee.c: too many arguments to function - 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] [RFC] Paravirt timer for KVM
Carsten Otte wrote: > On s390, we've had an instruction... Yes, quite ;) J - 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] [RFC] Paravirt timer for KVM
On Mon, 2007-10-15 at 12:04 +0800, Dong, Eddie wrote: > >>> 1) the PIT is periodic. a PV timer can offer a one shot > >timer which > >>> enables dynticks. > >>> > >> > >> Obviously people have figured out how to do dynticks on real x86 > >> hardware, so I don't accept this reason. :) > >> > > > >Using more advanced timers like the HPET. > > > > I'd think there is no reason for virtual timer to be PIT like, which > is mostly due to historic reason. > > If we need to make it close to native timer device, HPET is much > better than PIT for virtual time to look like. Fine, so why do we need PV time when we can emulate the HPET? -- Hollis Blanchard IBM Linux Technology Center - 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
[kvm-devel] [PATCH] Enable ACPI interrupts.
Hi, It was some problem to ACPI interrupts delivering to the Windows guests. This patch fixes this problem and enables the ACPI interrupts. According to 82371AB spec. we need to reset the bit 0 of PIRQRCA register to enable interrupt routing. Note: This patch work fine with –no-kvm-irqchip option and I can see the interrupt according to the acpi timer expiration ( pm_tmr_timer() ) or other acpi events, but without –no-kvm-irqchip option it doesn't work. I'll try to find the reason and fix it. I'll appreciate all feedbacks and/or thoughts. Cheers, Igor Lvovsky acpi-irq.diff Description: acpi-irq.diff - 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] [ANNOUNCE] kvm-46 release
Avi Kivity wrote:
> Farkas Levente wrote:
>> Avi Kivity wrote:
>>
>>> Farkas Levente wrote:
>>>
>> we did a quick test against this version and it's turn out the smp
>> guests are still not working. even if we start only one linux guest
>> with
>> 4cpu on 4cpu host the guest kernel hangs at random stages of the kernel
>> loading process (if we run more smp guests then they hang earlier, but
>> different random stage), but it's never reach the end of the kernel so
>> hang somewhere inside the kernel. and the cpu usage of these process
>> goes up to until the qemu-kvm processes eat all cpus (ie. 100%). t
>>
>>
> What host cpu are you using? What guest kernel version? 32-bit or
> 64-bit?
>
> I have no problems running a 4-way Linux guest here.
>
>
- host:
- Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
- Intel S3000AHV
- 8GB RAM
- CentOS-5
- kernel-2.6.18-8.1.14.el5 x86_64 64bit
- guest-1:
- CentOS-5
- kernel-2.6.18-8.1.14.el5 i386 32bit
- guest-2:
- CentOS-5
- kernel-2.6.18-8.1.14.el5 x86_64 64bit
- guest-3:
- Mandrake-9
- kernel-2.4.19.16mdk-1-1mdk 32bit
- guest-4:
- Windows XP Professional 32bit
start the first guest-1 with 4cpu produce the above hang. (and of course
using kvm-46:-)
>>> Is it the only guest that hangs with -smp 4? Or all of them?
>>>
>> if i start this guest alone it's hang. if i start all guest-{1,2,3,4}
>> than all linux guest hangs expect windows which runs but see only one
>> cpu. ok now i try it for you:-) so:
>>
>> - host + guest-1 -> hang
>>
>> - host + guest-2 -> hang
>> in this case i've got a stack trace too on the host, and the host
>> working 2 more minutes (!?) so i see the top part of the stack
>> (shift-pageup) but when i try to take a picture the host crash and i can
>> only see the end:-( but next time i bale to catch it:
>> ---
>> BUG: soft lockup detected on CPU#0!
>>
>
> Yunfeng reports that this has been fixed, can you try the latest
> snapshot from http://people.qumranet.com/avi/snapshots/?
and the rpms in my repo, but i'd rather wait for kvm-47 since this's a
production server and i'd like to play with it only once a week:-)
--
Levente "Si vis pacem para bellum!"
-
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
[kvm-devel] failure booting knoppix via kvm
Hi, I've been trying booting a knoppix Live CD KNOPPIX_V5.1.1CD-2007-01-04-EN.iso without any success. This is my setup: - Fedora 7 with all the updates available up to today. - kernel vmlinuz-2.6.22.9-91.fc7PAE - kvm-45 and latest kvm-46 Boot fails because of a kernel panic Call back trace: - setup_local_APIC - verify_local_APIC - init - APIC_init_uniprocessor - smp_prepare_cpus - task_rq_lock - set_cpus_allowed - init - init - ret_from_fork - init - init - kernel_thread_helper I tried various combination for booting knoppix: normal, failsafe and several in between. I also tried a few combination of -no-kvm-irqchip -std-vga -no-acpi Everything works if I disable kvm with -no-kvm switch. Any hint? Thanks in advance Francesco - 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 0/4] Swapping
On Mon, 2007-10-15 at 11:13 +0200, Carsten Otte wrote: > Izik Eidus wrote: > > this patchs allow the guest not shadowed memory to be swapped out. > This patch has greatly improved since I've read the swapping code last > time. While not having time for a deep review, it looks very clean and > sane to me when scrolling over. thanks. - 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] [ANNOUNCE] kvm-46 release
Izik Eidus wrote:
> can you send me your kvmctl.c file so i will look at it?
> it is somewhat hard to me understand how you did the things that way
I'm trying to back a vm with memory coming from a file map, see patch
attached against kvm-46 (was also attached earlier in this thread).
I've made kvm_create() optionally skip the memory setup, so I can create
my own later on. That doesn't work though because creating the vcpu
fails then.
cheers,
Gerd
* make kvm_create() skip all memory setup in case phys_mem_bytes == 0
* add kvm_register_userspace_phys_mem() to register any userspace memory
as guest physical memory.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
user/kvmctl.c | 53 +
user/kvmctl.h |3 +++
2 files changed, 44 insertions(+), 12 deletions(-)
Index: kvm-46/user/kvmctl.c
===
--- kvm-46.orig/user/kvmctl.c
+++ kvm-46/user/kvmctl.c
@@ -443,20 +443,22 @@ int kvm_create(kvm_context_t kvm, unsign
}
kvm->vm_fd = fd;
- r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
- if (r > 0)
- r = kvm_alloc_userspace_memory(kvm, memory, vm_mem);
- else
- r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
- if (r < 0)
- return r;
+ if (phys_mem_bytes) {
+ r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
+ if (r > 0)
+ r = kvm_alloc_userspace_memory(kvm, memory, vm_mem);
+ else
+ r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
+ if (r < 0)
+ return r;
-zfd = open("/dev/zero", O_RDONLY);
-mmap(*vm_mem + 0xa8000, 0x8000, PROT_READ|PROT_WRITE,
- MAP_PRIVATE|MAP_FIXED, zfd, 0);
-close(zfd);
+ zfd = open("/dev/zero", O_RDONLY);
+ mmap(*vm_mem + 0xa8000, 0x8000, PROT_READ|PROT_WRITE,
+ MAP_PRIVATE|MAP_FIXED, zfd, 0);
+ close(zfd);
- kvm->physical_memory = *vm_mem;
+ kvm->physical_memory = *vm_mem;
+ }
kvm->irqchip_in_kernel = 0;
if (!kvm->no_irqchip_creation) {
@@ -558,6 +560,33 @@ void *kvm_create_phys_mem(kvm_context_t
log, writable);
}
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+ unsigned long phys_start, void *userspace_addr,
+ unsigned long len, int slot, int log)
+{
+ int r;
+ struct kvm_userspace_memory_region memory = {
+ .slot = slot,
+ .memory_size = len,
+ .guest_phys_addr = phys_start,
+ .userspace_addr = (intptr_t)userspace_addr,
+ .flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
+ };
+
+ if (!kvm->physical_memory)
+ kvm->physical_memory = userspace_addr - phys_start;
+
+ r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory);
+ if (r == -1) {
+ fprintf(stderr, "create_userspace_phys_mem: %s", strerror(errno));
+ return -1;
+ }
+
+ kvm_userspace_memory_region_save_params(kvm, &memory);
+
+ return 0;
+}
+
/* destroy/free a whole slot.
* phys_start, len and slot are the params passed to kvm_create_phys_mem()
*/
Index: kvm-46/user/kvmctl.h
===
--- kvm-46.orig/user/kvmctl.h
+++ kvm-46/user/kvmctl.h
@@ -404,6 +404,9 @@ void *kvm_create_phys_mem(kvm_context_t,
unsigned long len, int slot, int log, int writable);
void kvm_destroy_phys_mem(kvm_context_t, unsigned long phys_start,
unsigned long len, int slot);
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+ unsigned long phys_start, void *userspace_addr,
+ unsigned long len, int slot, int log);
int kvm_get_dirty_pages(kvm_context_t, int slot, void *buf);
-
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] [ANNOUNCE] kvm-46 release
On Mon, 2007-10-15 at 13:15 +0200, Gerd Hoffmann wrote: > Izik Eidus wrote: > > On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote: > >> Gerd Hoffmann wrote: > >> > >>> Something like this? (compiles, not tested yet). > >> Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory". > > > > try use slot bigger bigger than 5 and smaller than 8 > > It doesn't come that far, kvm_create(&foo, 0, NULL) fails, seems doing > vcpu_create() before memory setup doesn't work. > > cheers, > Gerd > > can you send me your kvmctl.c file so i will look at it? it is somewhat hard to me understand how you did the things that way - 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] [ANNOUNCE] kvm-46 release
Izik Eidus wrote: > On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote: >> Gerd Hoffmann wrote: >> >>> Something like this? (compiles, not tested yet). >> Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory". > > try use slot bigger bigger than 5 and smaller than 8 It doesn't come that far, kvm_create(&foo, 0, NULL) fails, seems doing vcpu_create() before memory setup doesn't work. cheers, Gerd - 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] [ANNOUNCE] kvm-46 release
On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote: > Gerd Hoffmann wrote: > > > Something like this? (compiles, not tested yet). > > Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory". try use slot bigger bigger than 5 and smaller than 8 > cheers, > Gerd > > - > 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 - 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] [RFC] Paravirt timer for KVM
Gerd Hoffmann wrote: > With VT you can attempt to make that invisible to the guest using the > tsc offset field. Probably svm can do that too (didn't check docs > though). kvm-lite can't (what is the status btw?). Xen "solves" that > by not doing power management *evil grin*. On s390, we've had an instruction for that ever since (store clock), that works with an offset field with hardware support. Works great for us. If VT and SVM can do the same, I'd vote for using it if we can. - 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] [ANNOUNCE] kvm-46 release
Gerd Hoffmann wrote: > Something like this? (compiles, not tested yet). Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory". cheers, Gerd - 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] [ANNOUNCE] kvm-46 release
Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> Avi Kivity wrote:
>>
>>> We've now switched to allocating guest memory in userspace rather than
>>> in the kernel.
>>>
>> Hmm, a quick glimpse over kvmctl.h doesn't show an obvious way how to
>> use that. If I want to back vm memory with a file mapping, how can I do
>> that?
>>
>
> kvmctl.h doesn't expose an API for that currently, though is should be
> fairly trivial to do so.
Something like this? (compiles, not tested yet).
cheers,
Gerd
* make kvm_create() skip all memory setup in case phys_mem_bytes == 0
* add kvm_register_userspace_phys_mem() to register any userspace memory
as guest physical memory.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
user/kvmctl.c | 53 +
user/kvmctl.h |3 +++
2 files changed, 44 insertions(+), 12 deletions(-)
Index: kvm-46/user/kvmctl.c
===
--- kvm-46.orig/user/kvmctl.c
+++ kvm-46/user/kvmctl.c
@@ -443,20 +443,22 @@ int kvm_create(kvm_context_t kvm, unsign
}
kvm->vm_fd = fd;
- r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
- if (r > 0)
- r = kvm_alloc_userspace_memory(kvm, memory, vm_mem);
- else
- r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
- if (r < 0)
- return r;
+ if (phys_mem_bytes) {
+ r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
+ if (r > 0)
+ r = kvm_alloc_userspace_memory(kvm, memory, vm_mem);
+ else
+ r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
+ if (r < 0)
+ return r;
-zfd = open("/dev/zero", O_RDONLY);
-mmap(*vm_mem + 0xa8000, 0x8000, PROT_READ|PROT_WRITE,
- MAP_PRIVATE|MAP_FIXED, zfd, 0);
-close(zfd);
+ zfd = open("/dev/zero", O_RDONLY);
+ mmap(*vm_mem + 0xa8000, 0x8000, PROT_READ|PROT_WRITE,
+ MAP_PRIVATE|MAP_FIXED, zfd, 0);
+ close(zfd);
- kvm->physical_memory = *vm_mem;
+ kvm->physical_memory = *vm_mem;
+ }
kvm->irqchip_in_kernel = 0;
if (!kvm->no_irqchip_creation) {
@@ -558,6 +560,33 @@ void *kvm_create_phys_mem(kvm_context_t
log, writable);
}
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+ unsigned long phys_start, void *userspace_addr,
+ unsigned long len, int slot, int log)
+{
+ int r;
+ struct kvm_userspace_memory_region memory = {
+ .slot = slot,
+ .memory_size = len,
+ .guest_phys_addr = phys_start,
+ .userspace_addr = (intptr_t)userspace_addr,
+ .flags = log ? KVM_MEM_LOG_DIRTY_PAGES : 0,
+ };
+
+ if (!kvm->physical_memory)
+ kvm->physical_memory = userspace_addr - phys_start;
+
+ r = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &memory);
+ if (r == -1) {
+ fprintf(stderr, "create_userspace_phys_mem: %s", strerror(errno));
+ return -1;
+ }
+
+ kvm_userspace_memory_region_save_params(kvm, &memory);
+
+ return 0;
+}
+
/* destroy/free a whole slot.
* phys_start, len and slot are the params passed to kvm_create_phys_mem()
*/
Index: kvm-46/user/kvmctl.h
===
--- kvm-46.orig/user/kvmctl.h
+++ kvm-46/user/kvmctl.h
@@ -404,6 +404,9 @@ void *kvm_create_phys_mem(kvm_context_t,
unsigned long len, int slot, int log, int writable);
void kvm_destroy_phys_mem(kvm_context_t, unsigned long phys_start,
unsigned long len, int slot);
+int kvm_register_userspace_phys_mem(kvm_context_t kvm,
+ unsigned long phys_start, void *userspace_addr,
+ unsigned long len, int slot, int log);
int kvm_get_dirty_pages(kvm_context_t, int slot, void *buf);
-
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] [RFC] Paravirt timer for KVM
2007/10/15, Gerd Hoffmann <[EMAIL PROTECTED]>: > Avi Kivity wrote: > > Gerd Hoffmann wrote: > >> > >>> 2) the TSC would have to be used as a clocksource. You don't know the > >>> frequency which is the first problem with using the TSC but some systems > >>> have a TSC that changes frequencies. > >>> > >> Also note the tsc may stop ticking if the CPU goes sleep in C3, which > >> IMHO makes the tsc almost useless as clocksource for guests ... > > > > But the host knows that, right? So it can update the guest's timebase? > > Host should know. Well, I hope. Dunno whenever one really can be sure > in all cases given all the different CPUs and tsc implementations. > > With VT you can attempt to make that invisible to the guest using the > tsc offset field. Probably svm can do that too (didn't check docs > though). kvm-lite can't (what is the status btw?). Xen "solves" that > by not doing power management *evil grin*. > > Nevertheless it is probably much easier to go with pv timers (or maybe > emulate hpet timers). > > cheers, > Gerd Hell I don't know what is the best technical way to solve this problem, but as a sysadmin, I'm really "annoyed" when the time starts to drift madly on the servers as soon as the host is loaded (talking about esx servers there but I guess this will probably apply to any existing x86 virtualisation solution). A simple, reliable solution to get a stable time source is not a must IMHO, it is a usability requirement. Cheers, Gildas - 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] [RFC] Paravirt timer for KVM
Avi Kivity wrote: > Gerd Hoffmann wrote: >> >>> 2) the TSC would have to be used as a clocksource. You don't know the >>> frequency which is the first problem with using the TSC but some systems >>> have a TSC that changes frequencies. >>> >> Also note the tsc may stop ticking if the CPU goes sleep in C3, which >> IMHO makes the tsc almost useless as clocksource for guests ... > > But the host knows that, right? So it can update the guest's timebase? Host should know. Well, I hope. Dunno whenever one really can be sure in all cases given all the different CPUs and tsc implementations. With VT you can attempt to make that invisible to the guest using the tsc offset field. Probably svm can do that too (didn't check docs though). kvm-lite can't (what is the status btw?). Xen "solves" that by not doing power management *evil grin*. Nevertheless it is probably much easier to go with pv timers (or maybe emulate hpet timers). cheers, Gerd - 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] KVM: x86 emulator: implement 'movnti mem, reg'
Avi Kivity wrote: > Yang, Sheng wrote: >> Yeah :) >> >> Linux guest 2.6.16 x86_64 crashed when trying to get IP, for this >> 'movnti' haven't been implement yet. >> >> > > So, it was using movnti for mmio into the nic registers? Yeah, it's a mmio operation. > > >> Avi Kivity wrote: >> >>> Yang, Sheng wrote: >>> > From 1b7892787f1b619a52e52275cf41248f1131d1b6 Mon Sep 17 00:00:00 > >> 2001 >> From: Sheng Yang <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 14:24:20 +0800 Subject: [PATCH] KVM: x86 emulator: implement 'movnti mem, reg' Implement emulation of instruction: movnti m32/m64, r32/r64 opcode: 0x0f 0xc3 >>> Applied, thanks. >>> >>> I vaguely remember something about a guest hitting this... which one >>> >> is it? >> >>> I'll push this for 2.6.24 if it's a real life issue. >>> >> >> Thanks >> Yang, Sheng >> >> - >> 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 Thanks Yang, Sheng - 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] KVM: x86 emulator: implement 'movnti mem, reg'
Yang, Sheng wrote: > Yeah :) > > Linux guest 2.6.16 x86_64 crashed when trying to get IP, for this > 'movnti' haven't been implement yet. > > So, it was using movnti for mmio into the nic registers? > Avi Kivity wrote: > >> Yang, Sheng wrote: >> From 1b7892787f1b619a52e52275cf41248f1131d1b6 Mon Sep 17 00:00:00 > 2001 > >>> From: Sheng Yang <[EMAIL PROTECTED]> >>> Date: Mon, 15 Oct 2007 14:24:20 +0800 >>> Subject: [PATCH] KVM: x86 emulator: implement 'movnti mem, reg' >>> >>> Implement emulation of instruction: >>> movnti m32/m64, r32/r64 >>> opcode: 0x0f 0xc3 >>> >>> >> Applied, thanks. >> >> I vaguely remember something about a guest hitting this... which one >> > is it? > >> I'll push this for 2.6.24 if it's a real life issue. >> > > Thanks > Yang, Sheng > > - > 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 > -- error compiling committee.c: too many arguments to function - 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] KVM: x86 emulator: implement 'movnti mem, reg'
Yeah :) Linux guest 2.6.16 x86_64 crashed when trying to get IP, for this 'movnti' haven't been implement yet. Avi Kivity wrote: > Yang, Sheng wrote: >>> From 1b7892787f1b619a52e52275cf41248f1131d1b6 Mon Sep 17 00:00:00 2001 >> From: Sheng Yang <[EMAIL PROTECTED]> >> Date: Mon, 15 Oct 2007 14:24:20 +0800 >> Subject: [PATCH] KVM: x86 emulator: implement 'movnti mem, reg' >> >> Implement emulation of instruction: >> movnti m32/m64, r32/r64 >> opcode: 0x0f 0xc3 >> > > Applied, thanks. > > I vaguely remember something about a guest hitting this... which one is it? > > I'll push this for 2.6.24 if it's a real life issue. Thanks Yang, Sheng - 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] KVM: x86 emulator: implement 'movnti mem, reg'
Yang, Sheng wrote: > >From 1b7892787f1b619a52e52275cf41248f1131d1b6 Mon Sep 17 00:00:00 2001 > From: Sheng Yang <[EMAIL PROTECTED]> > Date: Mon, 15 Oct 2007 14:24:20 +0800 > Subject: [PATCH] KVM: x86 emulator: implement 'movnti mem, reg' > > Implement emulation of instruction: > movnti m32/m64, r32/r64 > opcode: 0x0f 0xc3 > Applied, thanks. I vaguely remember something about a guest hitting this... which one is it? I'll push this for 2.6.24 if it's a real life issue. -- error compiling committee.c: too many arguments to function - 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] Add some \n in ioapic_debug()
Laurent Vivier wrote: > Add new-line at end of debug strings. > > Applied, thanks. I always assumed ioapic_debug() added the \n by itself... -- error compiling committee.c: too many arguments to function - 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] APIC_TMCCT register read bug
Kevin Pedretti wrote:
> Hi,
>
> While booting a non-Linux OS under kvm-46, I noticed that reading
> APIC_TMCCT before initializing APIC_TDCR to something other than its
> boot time value would lead to a host kernel divide by zero exception.
> It's due to apic->timer.divide_count being set to 0 at boot... it should
> be set to 2 since APIC_TDCR=0 means 'divide count by 2'. The last hunk
> of the attached patch results in apic->timer.divide_count being set to 2
> and eliminates the oops.
>
> The other changes to apic_get_tmcct() are intended to clean it up a bit,
> although completely untested other than to verify 0 is returned for a
> read of APIC_TMCCT at boot. 'apic' should not be used before the
> ASSERT() and using u32 for counter_passed makes it fairly easy to
> overflow.
>
Patch looks good, but I'm missing a signed-off-by: line.
Eddie, can you also take a look?
> --- kvm-46.orig/kernel/lapic.c2007-10-10 02:06:36.0 -0600
> +++ kvm-46.fix/kernel/lapic.c 2007-10-12 22:50:01.0 -0600
> @@ -487,12 +487,19 @@
>
> static u32 apic_get_tmcct(struct kvm_lapic *apic)
> {
> - u32 counter_passed;
> - ktime_t passed, now = apic->timer.dev.base->get_time();
> - u32 tmcct = apic_get_reg(apic, APIC_TMICT);
> + u64 counter_passed;
> + ktime_t passed, now;
> + u32 tmcct;
>
> ASSERT(apic != NULL);
>
> + now = apic->timer.dev.base->get_time();
> + tmcct = apic_get_reg(apic, APIC_TMICT);
> +
> + /* if initial count is 0, current count should also be 0 */
> + if (tmcct == 0)
> + return 0;
> +
> if (unlikely(ktime_to_ns(now) <=
> ktime_to_ns(apic->timer.last_update))) {
> /* Wrap around */
> @@ -507,15 +514,24 @@
>
> counter_passed = div64_64(ktime_to_ns(passed),
> (APIC_BUS_CYCLE_NS *
> apic->timer.divide_count));
> - tmcct -= counter_passed;
>
> - if (tmcct <= 0) {
> - if (unlikely(!apic_lvtt_period(apic)))
> + if (counter_passed > tmcct) {
> + if (unlikely(!apic_lvtt_period(apic))) {
> + /* one-shot timers stick at 0 until reset */
> tmcct = 0;
> - else
> - do {
> - tmcct += apic_get_reg(apic, APIC_TMICT);
> - } while (tmcct <= 0);
> + } else {
> + /*
> + * periodic timers reset to APIC_TMICT when they
> + * hit 0. The while loop simulates this happening N
> + * times. (counter_passed %= tmcct) would also work,
> + * but might be slower or not work on 32-bit??
> + */
> + while (counter_passed > tmcct)
> + counter_passed -= tmcct;
> + tmcct -= counter_passed;
> + }
> + } else {
> + tmcct -= counter_passed;
> }
>
> return tmcct;
> @@ -844,7 +860,7 @@
> apic_set_reg(apic, APIC_ISR + 0x10 * i, 0);
> apic_set_reg(apic, APIC_TMR + 0x10 * i, 0);
> }
> - apic->timer.divide_count = 0;
> + update_divide_count(apic);
> atomic_set(&apic->timer.pending, 0);
> if (vcpu->vcpu_id == 0)
> vcpu->apic_base |= MSR_IA32_APICBASE_BSP;
--
error compiling committee.c: too many arguments to function
-
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
[kvm-devel] [PATCH] KVM: x86 emulator: implement 'movnti mem, reg'
>From 1b7892787f1b619a52e52275cf41248f1131d1b6 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Mon, 15 Oct 2007 14:24:20 +0800
Subject: [PATCH] KVM: x86 emulator: implement 'movnti mem, reg'
Implement emulation of instruction:
movnti m32/m64, r32/r64
opcode: 0x0f 0xc3
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
drivers/kvm/x86_emulate.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index fa33fcd..e974ace 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -212,7 +212,8 @@ static u16 twobyte_table[256] = {
0, 0, ByteOp | DstReg | SrcMem | ModRM | Mov,
DstReg | SrcMem16 | ModRM | Mov,
/* 0xC0 - 0xCF */
- 0, 0, 0, 0, 0, 0, 0, ImplicitOps | ModRM, 0, 0, 0, 0, 0, 0, 0,
0,
+ 0, 0, 0, DstMem | SrcReg | ModRM | Mov, 0, 0, 0, ImplicitOps |
ModRM,
+ 0, 0, 0, 0, 0, 0, 0, 0,
/* 0xD0 - 0xDF */
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
/* 0xE0 - 0xEF */
@@ -1686,6 +1687,11 @@ twobyte_insn:
c->dst.val = (c->d & ByteOp) ? (s8) c->src.val :
(s16)
c->src.val;
break;
+ case 0xc3: /* movnti */
+ c->dst.bytes = c->op_bytes;
+ c->dst.val = (c->op_bytes == 4) ? (u32) c->src.val :
+ (u64)
c->src.val;
+ break;
}
goto writeback;
--
1.5.2
Thanks
Yang, Sheng
0001-KVM-x86-emulator-implement-movnti-mem-reg.patch
Description: 0001-KVM-x86-emulator-implement-movnti-mem-reg.patch
-
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] Windows XP PFN_LIST_CORRUPT error during install.
John Clemens wrote: > Not much detail here but I'll post all I can. > > KVM-46 (from tarball, using kvm-46 modules), ubuntu gutsy > 2.6.22-14-generic amd64, Turion X2 with SVM, 1GB total memory on > laptop. > > Was in the middle of an windows xp pro sp2 install using this command > line: > > sudo ~/kvm46/bin/qemu-system-x86_64 -m 368 -boot c -cdrom winxp.iso -hda > winxp-pro-work.qcow2 -vnc :1 -net user -net > nic,mac=00:11:22:33:44:55:66,model=rtl8139 -localtime > > While installing, I went to do other work, which involved starting > another VM running a linux boot CD with 256MB of ram. Was running both > side by side without problem, other than the fact my host X-windows was > sluggish due to the lack of total ram available (1G-368M-256M). When > finished with the other VM, I shut it down, and a few seconds later the > windows install which was almost complete in the first VM threw a > bluescreen with a 'PFN_LIST_CORRUPT' error. Note that this was in the > second stage of the install where windows had already rebooted into the > install environment on the hard disk and was 'registering components' or > something. > > Nothing in the kernel log on the host that I can see, anywhere else I > can look? > > Unrelated, but earlier I tried a windows install with '-clock dynticks' > and windows installation would eventually fail with an > IRQL__NOT_LESS_THAN_OR_EQUAL (or something like that.. I'm working from > memory). Removing the 'clock' option made it work fine. Not sure if > it's supposed to work yet or not, but it didn't for me. > > Unfortunately there's a problem with irq injection on amd that I haven't had time yet to track down. You can try using the Standard PC HAL as detailed in http://kvm.qumranet.com/kvmwiki/Windows_ACPI_Workaround (see the "If you're installing" comment). -- error compiling committee.c: too many arguments to function - 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][RFC]Split kvm_vcpu to support new archs.
Zhang, Xiantao wrote: > >>> - u64 ia32_misc_enable_msr; >>> >>> struct kvm_mmu mmu; >>> >>> >> mmu >> > > About mmu, i am not sure about this. IA64 only need kvm module to > allocate and free memory for guests. Most functions related to mmu are > useless for IA64. If we put them as common, Maybe we have to define some > blank functions. > > I meant the mmu is x86 specific. >>> >> pio is x86 specific >> > > Why see pio as x86 specific? as I know, most archs have port IO access . > > Which ones? ppc and s390 don't, and I think ia64 doesn't either? -- error compiling committee.c: too many arguments to function - 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 0/4] Swapping
Izik Eidus wrote: > this patchs allow the guest not shadowed memory to be swapped out. This patch has greatly improved since I've read the swapping code last time. While not having time for a deep review, it looks very clean and sane to me when scrolling over. - 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] qemu-system-x86_64 locks hard when used with kvm
Jan Frey wrote: > So you can see AMD's "svm" is existent. > Host's kernel is 2.6.23.1, config file is attached. > KVM/Qemu sources I've tried include -37, -40, -45 and -46. > > When I run something like > qemu-system-x86_64 -m 384 -no-kvm > > The virtual machine boots and everything works fine (except the > slowliness ;-)). > But when I try without the "-no-kvm" switch the whole host machine > immediately freezes hard (no windows come up, no text on the console, > mouse frozen, amazing though that machine still reacts to ping on > network.. but anyway, even reset button at the PC doesn't help, I've got > to switch off power..) > > The host distribution is FC6. > > Am I doing something substantially wrong? > > Can you set up netconsole or serial console on that machine and grab the kernel output? -- error compiling committee.c: too many arguments to function - 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] kernel device reset support
Dong, Eddie wrote: >> N+1, for me is that synchronous device emulation (like pio and mmio) >> happens in in the vcpu thread and asynchronous device emulation >> (handling signals in qemu, performing dma, and injecting interrupts) >> happens in the device thread. This minimizes context switching and >> heavyweight exits. >> >> > If this is true, then the N+1 thread won't be able to execute > qemu_system_reset > which is in VCPU contents, I don't understand. It can certainly access any qemu object (after taking qemu_mutex), and it can call any kvm vm ioctl. > nor can asyn I/O call back APIs. > Do you mean signal handlers? Sure, but we wait for socket I/O in select() and even dequeue signals synchronously. -- error compiling committee.c: too many arguments to function - 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] [RFC] Paravirt timer for KVM
Gerd Hoffmann wrote: > >> 2) the TSC would have to be used as a clocksource. You don't know the >> frequency which is the first problem with using the TSC but some systems >> have a TSC that changes frequencies. >> > > Also note the tsc may stop ticking if the CPU goes sleep in C3, which > IMHO makes the tsc almost useless as clocksource for guests ... > But the host knows that, right? So it can update the guest's timebase? -- error compiling committee.c: too many arguments to function - 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] PV network performance comparison
Zhao Forrest wrote: > > When running KVM(kvm.rtl) and xen-HVM(xen.um) on the same machine, I > feel that the guest OS on top of KVM is much faster responsive than > the one on top of xen-HVM. > But this test result showed that xen-HVM is more responsive than KVM. > Weird. I onced tried KVM-36 and xen-3.0.1 and got such impression. > KVM certainly has an edge in latency because there are fewer layers and schedulers involved. Regarding throughput, the numbers for kvm.rtl look lower than expected while xen.um's numbers are unrealistically high. The test needs to be done more carefully (using a recent kvm, too). -- error compiling committee.c: too many arguments to function - 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] PV network performance comparison
James Dykman wrote: > Dor, > > I ran some netperf tests with your PV > virtio drivers, along with some Xen PV cases > and a few others for comparison. I thought you > (and the list) might be interested in the numbers. > > I am going to start looking for bottlenecks, unless > you need help with the new hypercall updates. > I'll re-run when that is available. > > Jim > > TCP REQUEST/RESPONSE (Trans. Rate per sec) > size kvm.rtl kvm.pvxen.pvxen.umkvm.lo > 1 2191.47 9533.74 18052.37 13593.58 42400.73 > 642184.30 9518.13 17979.93 13557.98 42260.53 > 128 2177.52 9482.45 17940.08 13588.54 40983.90 > 256 2160.49 9465.97 17788.21 13492.42 41170.45 > 512 2130.99 9403.33 17655.11 13489.64 40765.26 > 1024 2074.85 9204.90 17293.06 13572.01 39437.78 > 2048 416.18 4750.41 12907.57 11571.07 37252.42 > 4096 265.22 3691.90 10990.67 9943.64 31905.03 > 8192 116.80 1892.25 8439.83 6604.64 24397.95 > 16384 92.06 1004.58 4535.86 3924.68 17460.30 > > A flood ping from guest to host gives almost 1 transmissions/sec with the rtl8139 with an FC6 x86_64 guest here. > TCP STREAM (Throughput 10^6bits/sec) > sizekvm.rtl kvm.pv xen.pv xen.um kvm.lo >204833.06 507.21 555.94 1442.38 5409.73 >409633.16 526.75 848.26 2359.42 6152.48 >819233.13 527.99 997.69 2418.87 7267.73 > 1638433.08 525.95 1107.64 2379.50 8434.29 > 3276833.13 525.38 1199.08 2375.81 8857.09 > 6553633.20 523.39 1255.33 2473.92 9248.35 > 13107233.11 520.87 1292.54 2605.49 8559.21 > xen.um is higher than xen.pv? I get 8.4 MB/s (67Mb/s) using netcat from guest to host. -- error compiling committee.c: too many arguments to function - 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] [RFC] Paravirt timer for KVM
Hi, > 2) the TSC would have to be used as a clocksource. You don't know the > frequency which is the first problem with using the TSC but some systems > have a TSC that changes frequencies. Also note the tsc may stop ticking if the CPU goes sleep in C3, which IMHO makes the tsc almost useless as clocksource for guests ... cheers, Gerd - 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] RFC/patch portability: split kvm_vm_ioctl
Carsten Otte wrote: > > > Avi Kivity wrote: >> We need to distinguish between x86 specific (only x86 has this) and s390 >> special (everyone has it except s390). In the latter case it should >> still be in common code to avoid duplication, with a guard to disable >> compilation on s390. >> >> KVM_SET_MEMORY_REGION is in theory applicable to non-s390 but I'd like >> to deprecate it, so there's no point in implementing it on non-x86. The >> rest are s390 special rather than x86 specific. >> >> As related previously, KVM_SET_USER_MEMORY_REGION should work for s390 >> (with an extra check for the guest phsyical start address). > I thought about that all through the weekend. To me, it looks like I > want to eliminate "s390 special" as far as possible. In given case, > I'll follow Anthonys suggestion and support > KVM_SET_USER_MEMORY_REGION. KVM_SET_MEMORY_REGION will also go common, > and in case While KVM_SET_MEMORY_REGION can be supported on other archs, there's no reason to do so. It will be supported on x86 for backward compatibility but newer ports need only support the newer APIs. > > As for the pic/apic part, I think it is x86 specific. Christian > Ehrhardt stated he believes ppc won't have that too. > Yes, it's x86 specific. -- error compiling committee.c: too many arguments to function - 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][RFC]Split kvm_vcpu to support new archs.
Avi Kivity wrote: > Zhang, Xiantao wrote: [in struct kvm_vcpu] >> int interrupt_window_open; > arch specific, though maybe it's close enough to generic I thought about this field for a while. What we really want, is that the common code can figure wheter or not it is a good idea to send an interrupt. All architectures (even including s390) could encode an interrupt number in a 64bit value. To me, it looks like a callback for this like int kvm_arch_interrupt_window_open(u64 interrupt); would be the right abstraction. No need to solve this whole thing with this patch though, that aims at splitting kvm_vcpu. so long, Carsten - 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] RFC/patch portability: split kvm_vm_ioctl
Carsten Otte wrote: > > Avi Kivity wrote: >> We need to distinguish between x86 specific (only x86 has this) and s390 >> special (everyone has it except s390). In the latter case it should >> still be in common code to avoid duplication, with a guard to disable >> compilation on s390. >> >> KVM_SET_MEMORY_REGION is in theory applicable to non-s390 but I'd like >> to deprecate it, so there's no point in implementing it on non-x86. The >> rest are s390 special rather than x86 specific. >> >> As related previously, KVM_SET_USER_MEMORY_REGION should work for s390 >> (with an extra check for the guest phsyical start address). > I thought about that all through the weekend. To me, it looks like I > want to eliminate "s390 special" as far as possible. In given case, > I'll follow Anthonys suggestion and support > KVM_SET_USER_MEMORY_REGION. KVM_SET_MEMORY_REGION will also go common, > and in case we're pushing the actual port before you deprecate that > call, we'll #ifdef CONFIG_ARCH_S390 around it. > > As for the pic/apic part, I think it is x86 specific. Christian > Ehrhardt stated he believes ppc won't have that too. At least not in that manner x86 has it atm (which would be enough for splitting it per arch), since I'm unsure in that topic I set Hollis on cc who should know it better with his larger power experience. > > Will create another patch on vm_ioctl that reflects this later today. > > so long, > Carsten > > - > 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 -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization +49 7031/16-3385 [EMAIL PROTECTED] [EMAIL PROTECTED] IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 - 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] RFC/patch portability: split kvm_vm_ioctl
Avi Kivity wrote: > We need to distinguish between x86 specific (only x86 has this) and s390 > special (everyone has it except s390). In the latter case it should > still be in common code to avoid duplication, with a guard to disable > compilation on s390. > > KVM_SET_MEMORY_REGION is in theory applicable to non-s390 but I'd like > to deprecate it, so there's no point in implementing it on non-x86. The > rest are s390 special rather than x86 specific. > > As related previously, KVM_SET_USER_MEMORY_REGION should work for s390 > (with an extra check for the guest phsyical start address). I thought about that all through the weekend. To me, it looks like I want to eliminate "s390 special" as far as possible. In given case, I'll follow Anthonys suggestion and support KVM_SET_USER_MEMORY_REGION. KVM_SET_MEMORY_REGION will also go common, and in case we're pushing the actual port before you deprecate that call, we'll #ifdef CONFIG_ARCH_S390 around it. As for the pic/apic part, I think it is x86 specific. Christian Ehrhardt stated he believes ppc won't have that too. Will create another patch on vm_ioctl that reflects this later today. so long, Carsten - 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] [RFC] Expose infrastructure for unpinning guest memory
Anthony Liguori wrote: > So does MADV_REMOVE remove the backing page but still allow for memory > to be faulted in? That is, after calling MADV_REMOVE, there's no > guarantee that the contents of a give VA range will remain the same (but > it won't SEGV the app if it accesses that memory)? > > If so, I think that would be the right way to treat it. That allows for > two types of hints for the guest to provide: 1) I won't access this > memory for a very long time (so it's a good candidate to swap out) and > 2) I won't access this memory and don't care about it's contents. You really want MADV_DONTNEED. It does what one would expect: tell the kernel you'd prefer to see it discarded but it remains mapped so that you can fault it in. My xip code got into conflice with subject kernel feature once, that's why I had to care what it does. - 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
[kvm-devel] sydneyss
WATCH KGLJ TRADE ON MONDAY OCTOBER 15, 2007 WE ARE 100% CONFIDENT THAT THIS ONE WILL BE THE RUNNER OF THE YEAR! Name: Kingslake Energy, Inc. Symbol: KGLJ Price: $1.51 5-D Target: $4 Rating: Agressive Buy ADD KGLJ TO YOUR RADAR ON MONDAY OCTOBER 15! RIDE THE WAVE LIKE A SURFER! END UP ON TOP! DON'T LET KGLJ PASS YOU BY! DISCLAIMER: This is not an offer to buy or sell any security. ASA Press discloses that they were paid ten thousand dollars for distribution of this report. This report contains forward-lqqking statements. Please do due diligence before investing in any company. Best of luck to you in the markets this morning! - 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
