[PATCH 1/1] configure: passthrough for audio-{drv,card} and logic cleanup
This is a revised and tested patch that correctly passes arguments
containing spaces to qemu/configure.
Avoids reformatting for the options that are send verbatim to qemu's
configure and add a passthrough for qemu options that use a space
separated list of options like the list for audio drivers enabled
or the list for audio devices emulated.
--- configure.orig 2008-07-27 11:08:56.0 +0100
+++ configure 2008-07-31 07:59:53.0 +0100
@@ -8,8 +8,10 @@
want_module=1
qemu_cflags=
qemu_ldflags=
-qemu_opts=
+declare -a qemu_opts
cross_prefix=
+audio_drv_list=
+audio_card_list=
arch=`uname -m`
target_exec=
@@ -30,15 +32,16 @@
EOF
cd qemu
-./configure --help | egrep "enable-|disable-" \
+./configure --help | egrep "enable-|disable-|audio-|Available" \
| grep -v user | grep -v system | grep -v kqemu | grep -v kvm \
| sed -e "s/^ //g" \
- | sed -e"s/ enable/enable/g" | sed -e "s/ disable/disable/g"
+| sed -e "s/ enable/enable/g" | sed -e "s/ disable/disable/g" \
+| sed -e "s/ set/set/g" | sed -e "s/ Available/Available/g"
exit 1
}
-
while [[ "$1" = -* ]]; do
-opt="$1"; shift
+optorig="$1"; shift
+opt="$optorig"
arg=
if [[ "$opt" = *=* ]]; then
arg="${opt#*=}"
@@ -69,13 +72,15 @@
--help)
usage
;;
+--audio-*)
+[EMAIL PROTECTED]"${opt}=${arg}"
+;;
*)
- qemu_opts="$qemu_opts $opt"
+[EMAIL PROTECTED]"${optorig}"
;;
esac
done
-
#set kenel directory
libkvm_kerneldir=$(readlink -f kernel)
@@ -114,7 +119,7 @@
--kernel-path="$libkvm_kerneldir" \
--prefix="$prefix" \
${cross_prefix:+"--cross-prefix=$cross_prefix"} \
-${cross_prefix:+"--cpu=$arch"} $qemu_opts
+${cross_prefix:+"--cpu=$arch"} "[EMAIL PROTECTED]"
) || usage
--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-userspace: fix memslot assignment
Am Dienstag, 29. Juli 2008 schrieb Avi Kivity:
> They all start with 0 AFAIK (kvm also starts with 0, it just wants it to
> be a special slot).
Now my brain hurts
Ok, so I read this as: ppc, ia64 and s390 can start with slot 0 and it is not a
special slot.
On x86 slot 0 is special, if
* KVM_CAP_SET_TSS_ADDR is not available
or
* The ioctl VM_CAP_SET_TSS_ADDR returns <=0
Since my opteron box died recently I cannot test that on x86 at the moment.
What do you think about the following patch
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
libkvm/libkvm.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
Index: kvm-userspace/libkvm/libkvm.c
===
--- kvm-userspace.orig/libkvm/libkvm.c
+++ kvm-userspace/libkvm/libkvm.c
@@ -75,25 +75,21 @@ void init_slots(void)
int get_free_slot(kvm_context_t kvm)
{
- int i;
- int tss_ext;
-
-#if defined(KVM_CAP_SET_TSS_ADDR) && !defined(__s390__)
- tss_ext = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
-#else
- tss_ext = 0;
-#endif
+ int i = 0;
/*
-* on older kernels where the set tss ioctl is not supprted we must save
-* slot 0 to hold the extended memory, as the vmx will use the last 3
-* pages of this slot.
+* on older x86 kernels where the set tss ioctl is not supported we
+* must save slot 0 to hold the extended memory, as the vmx will
+* use the last 3 pages of this slot.
*/
- if (tss_ext > 0)
- i = 0;
- else
- i = 1;
-
+#if defined(__x86_64__) || defined(__i386__)
+#if defined(KVM_CAP_SET_TSS_ADDR)
+ if (ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR) > 0)
+ i++;
+#else
+ i++;
+#endif
+#endif
for (; i < KVM_MAX_NUM_MEM_REGIONS; ++i)
if (!slots[i].len)
return i;
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Offline for a week
I will go offline starting tonight, for about a week. If all goes well, I will have no Internet connectivity. I'll be back on August 10. Stephen/Andrew, if kvm.git gives you trouble, please drop it temporarily from linux-next. Andrea, I see Linus hasn't pulled the kvm-mmu notifiers glue. If that's still the case in a few days, please resolve any issues and send it yourself. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] [RESEND] KVM MMU notifiers support for 2.6.27-rc1
Linus, please pull from repo & branch at: git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git kvm-updates-2.6.27 to receive the mmu notifiers support for kvm. This allows the full range of Linux virtual memory management, such as swapping and page migration, to apply to kvm virtual machines. Andrea Arcangeli (3): KVM: Allow reading aliases with mmu_lock KVM: Allow browsing memslots with mmu_lock KVM: Synchronize guest physical memory map to host virtual memory map Avi Kivity (1): KVM: Advertise synchronized mmu support to userspace arch/x86/kvm/mmu.c | 100 arch/x86/kvm/paging_tmpl.h | 12 arch/x86/kvm/x86.c | 24 +-- include/asm-x86/kvm_host.h |6 ++ include/linux/kvm.h|1 + include/linux/kvm_host.h | 24 +++ virt/kvm/kvm_main.c| 155 ++- 7 files changed, 311 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] KVM: Add irq ack notifier list
Amit Shah wrote: 'opaque' fields can be later made to point to other structures without changing the structure itself. This is an advantage. Will the kvm_pic struct be needed to change in the future? Very unlikely. So we can rename it to struct kvm *, however, that gives us no real benefit as against opaque (just readability). Yes, the readability... I think people would be very curious about why void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi) got a irq_request_opaque as a parameter. It's more like a hack, which is not my meaning... Anyway, it's trivial one and just a coding style. :) However, this idiom is used in quite a few places in the kernel already so it shouldn't come as a big surprise to someone reading the code. Void pointers are useful where there are multiple clients for a service which needs a callback. When there is just one client (and not because no one has written another, but because logically there is only one client), specifying it explicity is better. An alternative to void pointers (which I prefer) is to embed the structure that holds the callback within the structure that needs to be passed to the callback, and use container_of(). This saves the space to store the void pointer, and is also cleaner, IMO. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] configure: passthrough for audio-{drv,card} and logic cleanup
On Thu, Jul 31, 2008 at 04:34:03AM +0100, TJ wrote:
> This patch fails to achieve the intended aim since the values assigned
> to audio-*-list are hard-reset in several places in qemu/configure, both
> for initial variable 'declaration' and when setting sane defaults in the
> absence of command-line over-rides.
Not really sure which patch you are referring to as there is none on this
email, but the one I sent originally in this thread with this subject and
that I got back from the list and that is in the mail archive seem to work
correctly as shown below :
kvm-72 $ ./configure | grep Audio
Audio drivers oss
kvm-72 $ ./configure --audio-drv-list="alsa" | grep Audio
Audio drivers alsa
kvm-72 $ ./configure --audio-drv-list="sdl oss alsa" | grep Audio
Audio drivers sdl oss alsa
in case your copy got somehow mangled I am sending it again attached so it
will be easier to apply by doing something like :
$ tar -xzf kvm-72.tar.gz
$ cd kvm-72
$ patch -p1 < kvm-72-configure-audio-list.patch
Carlo
>From 0e457bd68805df64b120a70c44fd62860b759f3c Mon Sep 17 00:00:00 2001
From: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
Date: Tue, 15 Jul 2008 22:52:42 -0700
Subject: [PATCH 2/2] configure: passthrough for audio-{drv,card}-list and logic
cleanup
Avoids reformatting for the options that are send verbatim to qemu's
configure and add a passthrough for qemu options that use a space
separated list of options like the list for audio drivers enabled
or the list for audio devices emulated.
Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
---
configure | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 2558e0e..fc05767 100755
--- a/configure
+++ b/configure
@@ -10,6 +10,8 @@ qemu_cflags=
qemu_ldflags=
qemu_opts=
cross_prefix=
+audio_drv_list=
+audio_card_list=
arch=`uname -m`
target_exec=
@@ -39,7 +41,8 @@ EOF
}
while [[ "$1" = -* ]]; do
-opt="$1"; shift
+optorig="$1"; shift
+opt="$optorig"
arg=
if [[ "$opt" = *=* ]]; then
arg="${opt#*=}"
@@ -67,16 +70,21 @@ while [[ "$1" = -* ]]; do
--cross-prefix)
cross_prefix="$arg"
;;
+ --audio-drv-list)
+ audio_drv_list="$arg"
+ ;;
+ --audio-card-list)
+ audio_card_list="$arg"
+ ;;
--help)
usage
;;
*)
- qemu_opts="$qemu_opts $opt"
+ qemu_opts="$qemu_opts $optorig"
;;
esac
done
-
#set kenel directory
libkvm_kerneldir=$(readlink -f kernel)
@@ -114,11 +122,12 @@ fi
--extra-ldflags="-L $PWD/../libkvm $qemu_ldflags" \
--kernel-path="$libkvm_kerneldir" \
--prefix="$prefix" \
+${audio_drv_list:+"--audio-drv-list=$audio_drv_list"} \
+${audio_card_list:+"--audio-card-list=$audio_card_list"} \
${cross_prefix:+"--cross-prefix=$cross_prefix"} \
${cross_prefix:+"--cpu=$arch"} $qemu_opts
) || usage
-
cat < config.mak
ARCH=$arch
PREFIX=$prefix
--
1.5.4.5
Re: [PATCH] kvm: bios: Put AP boot up code to 0x1000
On Thursday 31 July 2008 14:41:04 Avi Kivity wrote: > Yang, Sheng wrote: > > On Thursday 31 July 2008 10:43:20 Yang, Sheng wrote: > >> From ba05b3c821400127074f65ee4d172fabbe3524cd Mon Sep 17 > >> 00:00:00 2001 From: Sheng Yang <[EMAIL PROTECTED]> > >> Date: Thu, 31 Jul 2008 10:39:24 +0800 > >> Subject: [PATCH] kvm: bios: Put AP boot up code to 0x1000 > >> > >> Rather than 0x1, which can be overrided by userspace program > >> like grub. > > How about 0xex000? And avoid copying the bios to low memory? > > Gleb tried it and it worked. We'd have to change qemu to mark the > memory as RAM, not ROM, but that's what real hardware does as well > (shadowing the ROM into RAM). I tried 0xea000, and it's fine. But avoid copying is better. But I don't understand the RAM/ROM issue in qemu here... And do you mean you have patch on hand now? :) -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Yang, Sheng wrote: On Thursday 31 July 2008 14:41:04 Avi Kivity wrote: Yang, Sheng wrote: On Thursday 31 July 2008 10:43:20 Yang, Sheng wrote: From ba05b3c821400127074f65ee4d172fabbe3524cd Mon Sep 17 00:00:00 2001 From: Sheng Yang <[EMAIL PROTECTED]> Date: Thu, 31 Jul 2008 10:39:24 +0800 Subject: [PATCH] kvm: bios: Put AP boot up code to 0x1000 Rather than 0x1, which can be overrided by userspace program like grub. How about 0xex000? And avoid copying the bios to low memory? Gleb tried it and it worked. We'd have to change qemu to mark the memory as RAM, not ROM, but that's what real hardware does as well (shadowing the ROM into RAM). I tried 0xea000, and it's fine. But avoid copying is better. But I don't understand the RAM/ROM issue in qemu here... IIRC the rombios32.c writes to the memory it is in, so it expects RAM, not ROM. kvm doesn't support ROM, so it would work. Qemu doesn't, so it would fail. And do you mean you have patch on hand now? :) No, but maybe Gleb does. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] configure: passthrough for audio-{drv,card} and logic cleanup
Carlo Marcelo Arenas Belon wrote:
Not really sure which patch you are referring to as there is none on this
email, but the one I sent originally in this thread with this subject and
that I got back from the list and that is in the mail archive seem to work
correctly as shown below :
kvm-72 $ ./configure | grep Audio
Audio drivers oss
kvm-72 $ ./configure --audio-drv-list="alsa" | grep Audio
Audio drivers alsa
kvm-72 $ ./configure --audio-drv-list="sdl oss alsa" | grep Audio
Audio drivers sdl oss alsa
in case your copy got somehow mangled I am sending it again attached so it
will be easier to apply by doing something like :
$ tar -xzf kvm-72.tar.gz
$ cd kvm-72
$ patch -p1 < kvm-72-configure-audio-list.patch
diff --git a/configure b/configure
index 2558e0e..fc05767 100755
--- a/configure
+++ b/configure
@@ -10,6 +10,8 @@ qemu_cflags=
qemu_ldflags=
qemu_opts=
cross_prefix=
+audio_drv_list=
+audio_card_list=
arch=`uname -m`
target_exec=
@@ -39,7 +41,8 @@ EOF
}
while [[ "$1" = -* ]]; do
-opt="$1"; shift
+optorig="$1"; shift
+opt="$optorig"
arg=
if [[ "$opt" = *=* ]]; then
arg="${opt#*=}"
@@ -67,16 +70,21 @@ while [[ "$1" = -* ]]; do
--cross-prefix)
cross_prefix="$arg"
;;
+ --audio-drv-list)
+ audio_drv_list="$arg"
+ ;;
+ --audio-card-list)
+ audio_card_list="$arg"
+ ;;
--help)
usage
;;
*)
- qemu_opts="$qemu_opts $opt"
+ qemu_opts="$qemu_opts $optorig"
;;
esac
done
-
#set kenel directory
libkvm_kerneldir=$(readlink -f kernel)
@@ -114,11 +122,12 @@ fi
--extra-ldflags="-L $PWD/../libkvm $qemu_ldflags" \
--kernel-path="$libkvm_kerneldir" \
--prefix="$prefix" \
+${audio_drv_list:+"--audio-drv-list=$audio_drv_list"} \
+${audio_card_list:+"--audio-card-list=$audio_card_list"} \
${cross_prefix:+"--cross-prefix=$cross_prefix"} \
${cross_prefix:+"--cpu=$arch"} $qemu_opts
) || usage
Too fragile. It would be best to quote the argument properly so
qemu/configure sees the right thing.
I tried playing with printf %q, but only got more annoyed with bash that
I usually am. Patches to rewrite ./configure in python are welcome.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RESEND] x86_emulator: Emulate cld and std instruction
Mohammed Gamal wrote: This patch adds 'cld' and 'std' instructions to the emulator I presume for big real mode? Which guest wants it? @@ -1755,6 +1755,14 @@ special_insn: ctxt->eflags |= X86_EFLAGS_IF; c->dst.type = OP_NONE; /* Disable writeback. */ break; + case 0xfc: /* cld */ + ctxt->eflags &= ~EFLG_DF; + c->dst.type = OP_NONE; /* Disable writeback. */ + break; + case 0xfd: /* std */ + ctxt->eflags |= EFLG_DF; + c->dst.type = OP_NONE; /* Disable writeback. */ + break; You need to add non-zero entries in opcode_table[] for this to work. Also, why disable writeback? If there is not DstSomething in opcode_table[], c->dst.type will be OP_NONE anyway. I would like to see test cases for emulator changes. See users/test/x86/emulator.c. Of course, right now it is impossible to cause cld and std to execute in the emulator. But with the proposed invalid_guest_state() change, it should be easy to to cause this state and force emulation. So how about adding optional invalid_guest_state() support (controlled by a module parameter), then start adding instructions and test cases, then removing the module parameter when everything works? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: ia64 allmodconfig
Andrew Morton wrote: arch/ia64/kvm/../../../virt/kvm/ioapic.c:42:17: irq.h: No such file or directory arch/ia64/kvm/../../../virt/kvm/ioapic.c: In function `__kvm_ioapic_update_eoi': arch/ia64/kvm/../../../virt/kvm/ioapic.c:296: error: implicit declaration of function `kvm_notify_acked_irq' arch/ia64/kvm/../../../virt/kvm/ioapic.c: In function `ioapic_mmio_write': arch/ia64/kvm/../../../virt/kvm/ioapic.c:389: error: too few arguments to functi Xiantao/Anthony? I'd write a patch but have no ia64 machine to test it on. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Save 64-bit of the IA-32e capable sysenter MSRs
Alexander Graf wrote: Hi, When transitioning from KVM to the qemu userspace, we try to get and push a whole bunch of MSR values, including the SYSENTER ones. While this is basically a good idea, qemu doesn't know anything about SYSENTER on x86_64, which is an additional feature only available on Intel CPUs and thus defines SYSENTER_EIP and SYSENTER_ESP as 32-bit values. Because we're saving/restoring the SYSENTER values on transitions to userspace and the values in env->cpu only hold 32 bits, they get truncated to 32-bit. The easiest way around this is to widen the fields to 64 bits. This should not disturb the current functionality, but allows us to run 32-bit code on x86_64 using VMX. As this is KVM specific for now, I'll only CC the qemu mailinglist, but wouldn't encourage qemu to take the patch for now, as it's not necessary when emulating an AMD CPU. Applied, thanks. I imagine save/restore support needs updating as well? That should go into qemuy btw since maintaining the save/restore format across forks isn't possible. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RESEND] x86_emulator: Emulate cld and std instruction
On Thu, Jul 31, 2008 at 12:57 PM, Avi Kivity <[EMAIL PROTECTED]> wrote: > Mohammed Gamal wrote: >> >> This patch adds 'cld' and 'std' instructions to the emulator >> >> > > I presume for big real mode? Which guest wants it? Actually I was experimenting with checking guest state and emulating on mode switches. When I was doing so, it used to happen with all guests, so I guess it maybe something related to the BIOS not a specific guest. BTW, the other way we can do is still handle vmentry failures. I discovered that the problem that caused occasional exits with Guillaume's patches is very likely to be that not enough checks on the guest state. The only check was if CS RPL equals SS RPL, so what happens is that when a vmexit and then a vmentry occurs CS and SS RPL maybe equal, but other checks might cause a vmentry failure. I've written a function to check that guest state is VMX valid - although not all checks are implemented yet, and I no more get the occasional vmexits. > >> @@ -1755,6 +1755,14 @@ special_insn: >>ctxt->eflags |= X86_EFLAGS_IF; >>c->dst.type = OP_NONE; /* Disable writeback. */ >>break; >> + case 0xfc: /* cld */ >> + ctxt->eflags &= ~EFLG_DF; >> + c->dst.type = OP_NONE; /* Disable writeback. */ >> + break; >> + case 0xfd: /* std */ >> + ctxt->eflags |= EFLG_DF; >> + c->dst.type = OP_NONE; /* Disable writeback. */ >> + break; >> > > You need to add non-zero entries in opcode_table[] for this to work. Also, > why disable writeback? If there is not DstSomething in opcode_table[], > c->dst.type will be OP_NONE anyway. > Oh! completely forgot about that, sorry! > I would like to see test cases for emulator changes. See > users/test/x86/emulator.c. Of course, right now it is impossible to cause > cld and std to execute in the emulator. But with the proposed > invalid_guest_state() change, it should be easy to to cause this state and > force emulation. > > So how about adding optional invalid_guest_state() support (controlled by a > module parameter), then start adding instructions and test cases, then > removing the module parameter when everything works? > Sounds good -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RESEND] x86_emulator: Emulate cld and std instruction
Mohammed Gamal wrote: On Thu, Jul 31, 2008 at 12:57 PM, Avi Kivity <[EMAIL PROTECTED]> wrote: Mohammed Gamal wrote: This patch adds 'cld' and 'std' instructions to the emulator I presume for big real mode? Which guest wants it? Actually I was experimenting with checking guest state and emulating on mode switches. When I was doing so, it used to happen with all guests, so I guess it maybe something related to the BIOS not a specific guest. There is indeed a cld in rombios.c (after rombios32_05), but it appears to be after all segments have been initialized. BTW, the other way we can do is still handle vmentry failures. I discovered that the problem that caused occasional exits with Guillaume's patches is very likely to be that not enough checks on the guest state. The only check was if CS RPL equals SS RPL, so what happens is that when a vmexit and then a vmentry occurs CS and SS RPL maybe equal, but other checks might cause a vmentry failure. I've written a function to check that guest state is VMX valid - although not all checks are implemented yet, and I no more get the occasional vmexits. I'm still worried about undoing the interrupt injection setup. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATH] kvm-72 - fix compilation on 2.6.26 (anon_inode_getfd flag)
Nikola Ciprich wrote: Hi, sure. hope it's OK Applied, thanks. Please signoff in the future. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-userspace: fix memslot assignment
Christian Borntraeger wrote: Am Dienstag, 29. Juli 2008 schrieb Avi Kivity: They all start with 0 AFAIK (kvm also starts with 0, it just wants it to be a special slot). Now my brain hurts Ok, so I read this as: ppc, ia64 and s390 can start with slot 0 and it is not a special slot. On x86 slot 0 is special, if * KVM_CAP_SET_TSS_ADDR is not available or * The ioctl VM_CAP_SET_TSS_ADDR returns <=0 I think this is right. Izik can you confirm? +#if defined(__x86_64__) || defined(__i386__) +#if defined(KVM_CAP_SET_TSS_ADDR) + if (ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR) > 0) Should be <= here? + i++; +#else + i++; +#endif +#endif Suggest a helper, kvm_supports_set_tss_addr(), to reduce further braindamage. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Offline for a week
On Thu, Jul 31, 2008 at 11:39:03AM +0300, Avi Kivity wrote: > Andrea, I see Linus hasn't pulled the kvm-mmu notifiers glue. If that's > still the case in a few days, please resolve any issues and send it > yourself. Ok. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-userspace: fix memslot assignment
Avi Kivity wrote: Christian Borntraeger wrote: Am Dienstag, 29. Juli 2008 schrieb Avi Kivity: They all start with 0 AFAIK (kvm also starts with 0, it just wants it to be a special slot). Now my brain hurts Ok, so I read this as: ppc, ia64 and s390 can start with slot 0 and it is not a special slot. On x86 slot 0 is special, if * KVM_CAP_SET_TSS_ADDR is not available or * The ioctl VM_CAP_SET_TSS_ADDR returns <=0 I think this is right. Izik can you confirm? yea kernels that dont have KVM_CAP_SET_TSS_ADDR should be treated like that. +#if defined(__x86_64__) || defined(__i386__) +#if defined(KVM_CAP_SET_TSS_ADDR) +if (ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR) > 0) Should be <= here? +i++; +#else +i++; +#endif +#endif Suggest a helper, kvm_supports_set_tss_addr(), to reduce further braindamage. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-userspace: fix memslot assignment
Am Donnerstag, 31. Juli 2008 schrieb Avi Kivity:
> > +#if defined(__x86_64__) || defined(__i386__)
> > +#if defined(KVM_CAP_SET_TSS_ADDR)
> > + if (ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR) > 0)
> >
>
> Should be <= here?
yes. But with the wrapper you suggest below its again >.
>
> > + i++;
> > +#else
> > + i++;
> > +#endif
> > +#endif
> >
>
> Suggest a helper, kvm_supports_set_tss_addr(), to reduce further
> braindamage.
Something like that? But then I get the following warning on non-x86:
libkvm.c:77: warning: 'kvm_supports_set_tss_addr' defined but not used
Should I mask the wrapper with config x86 as well?
---
libkvm.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
Index: libkvm/libkvm.c
===
--- libkvm.orig/libkvm.c
+++ libkvm/libkvm.c
@@ -73,27 +73,29 @@ void init_slots(void)
slots[i].len = 0;
}
+static int kvm_supports_set_tss_addr(kvm_context_t kvm)
+{
+#if defined(KVM_CAP_SET_TSS_ADDR)
+ if (ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR) > 0)
+ return 1;
+#endif
+ return 0;
+}
+
int get_free_slot(kvm_context_t kvm)
{
int i;
- int tss_ext;
-
-#if defined(KVM_CAP_SET_TSS_ADDR) && !defined(__s390__)
- tss_ext = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
-#else
- tss_ext = 0;
-#endif
/*
-* on older kernels where the set tss ioctl is not supprted we must save
-* slot 0 to hold the extended memory, as the vmx will use the last 3
-* pages of this slot.
+* on older x86 kernels where the set tss ioctl is not supported we
+* must save slot 0 to hold the extended memory, as the vmx will
+* use the last 3 pages of this slot.
*/
- if (tss_ext > 0)
- i = 0;
- else
- i = 1;
-
+#if defined(__x86_64__) || defined(__i386__)
+ i = !kvm_supports_set_tss_addr(kvm);
+#else
+ i = 0;
+#endif
for (; i < KVM_MAX_NUM_MEM_REGIONS; ++i)
if (!slots[i].len)
return i;
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-userspace: fix memslot assignment
Christian Borntraeger wrote: Something like that? But then I get the following warning on non-x86: libkvm.c:77: warning: 'kvm_supports_set_tss_addr' defined but not used Should I mask the wrapper with config x86 as well? If we rename the helper, kvm_wants_special_memslot_0() (reversing the meaning), we can have non-x86 return 0, x86 with KVM_CAP_SET_TSS_ADDR return 0, and otherwise return 1. No ifdefs outside the helper this way. --- libkvm.c | 32 +--- 1 file changed, 17 insertions(+), 15 deletions(-) (missing signoff) -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Balloon device in qemu?
Marcelo, the balloon was last seen drifting over your territory. Care to brush it up and send it over? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RESEND] x86_emulator: Emulate cld and std instruction
Here is an update patch.
This adds 'cld' and 'std' instructions. The group table entries are
added.
Signed-off-by: Mohammed Gamal <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86_emulate.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index 07a277c..4c7ca7f 100644
--- a/arch/x86/kvm/x86_emulate.c
+++ b/arch/x86/kvm/x86_emulate.c
@@ -182,7 +182,7 @@ static u16 opcode_table[256] = {
ImplicitOps, ImplicitOps, Group | Group3_Byte, Group | Group3,
/* 0xF8 - 0xFF */
ImplicitOps, 0, ImplicitOps, ImplicitOps,
- 0, 0, Group | Group4, Group | Group5,
+ ImplicitOps, ImplicitOps, Group | Group4, Group | Group5,
};
static u16 twobyte_table[256] = {
@@ -1757,6 +1757,14 @@ special_insn:
ctxt->eflags |= X86_EFLAGS_IF;
c->dst.type = OP_NONE; /* Disable writeback. */
break;
+ case 0xfc: /* cld */
+ ctxt->eflags &= ~EFLG_DF;
+ c->dst.type = OP_NONE; /* Disable writeback. */
+ break;
+ case 0xfd: /* std */
+ ctxt->eflags |= EFLG_DF;
+ c->dst.type = OP_NONE; /* Disable writeback. */
+ break;
case 0xfe ... 0xff: /* Grp4/Grp5 */
rc = emulate_grp45(ctxt, ops);
if (rc != 0)
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] x86 emulator: Add opcodes 0xb9-0xbf (mov r,imm)
The emulator only supported opcode 0xb8 for mov r,imm. However 0xb9-0xbf
are also mov r,imm. This patch adds support for these instructions.
Signed-off-by: Mohammed Gamal <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86_emulate.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index 005f1db..4c7ca7f 100644
--- a/arch/x86/kvm/x86_emulate.c
+++ b/arch/x86/kvm/x86_emulate.c
@@ -156,7 +156,9 @@ static u16 opcode_table[256] = {
ByteOp | ImplicitOps | String, ImplicitOps | String,
/* 0xB0 - 0xBF */
0, 0, 0, 0, 0, 0, 0, 0,
- DstReg | SrcImm | Mov, 0, 0, 0, 0, 0, 0, 0,
+ DstReg | SrcImm | Mov, DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
+ DstReg | SrcImm | Mov, DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
+ DstReg | SrcImm | Mov, DstReg | SrcImm | Mov,
/* 0xC0 - 0xC7 */
ByteOp | DstMem | SrcImm | ModRM, DstMem | SrcImmByte | ModRM,
0, ImplicitOps | Stack, 0, 0,
@@ -1660,7 +1662,7 @@ special_insn:
case 0xae ... 0xaf: /* scas */
DPRINTF("Urk! I don't handle SCAS.\n");
goto cannot_emulate;
- case 0xb8: /* mov r, imm */
+ case 0xb8 ... 0xbf: /* mov r, imm */
goto mov;
case 0xc0 ... 0xc1:
emulate_grp2(ctxt);
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM compile fails on s390x
I guess I am doing something very dumb, but when I try to compile kvm-72 on z900 architecture (actually Hercules) I immediately get a compile error: zgentoo kvm-72 # ./configure --disable-gfx-check --disable-sdl Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /usr/tmp/kvm-72/qemu C compilergcc Host C compiler gcc ARCH_CFLAGS -march=z900 make make install install host CPU s390 host big endian yes target list i386-softmmu x86_64-softmmu arm-softmmu cris-softmmu m68k-softmmu mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu ppc-softmmu ppcemb-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu i386-linux-user x86_64-linux-user alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user m68k-linux-user mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user ppc64abi32-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc64-linux-user sparc32plus-linux-user gprof enabled no profiler no static build no -Werror enabled no SDL support no curses supportyes mingw32 support no Audio drivers oss Extra audio cards Mixer emulation no VNC TLS support no kqemu support no kvm support no CPU emulation yes brlapi supportno Documentation yes NPTL support yes vde support no zgentoo kvm-72 # make make -C libkvm make[1]: Entering directory `/var/tmp/kvm-72/libkvm' gcc -MMD -MF ./.libkvm.d -g -fomit-frame-pointer -Wall -fno-stack-protector -I /var/tmp/kvm-72/kernel/include -c -o libkvm.o libkvm.c libkvm.c: In function 'kvm_run': libkvm.c:1003: warning: label 'more' defined but not used gcc -MMD -MF ./.libkvm-s390.d -g -fomit-frame-pointer -Wall -fno-stack-protector -I /var/tmp/kvm-72/kernel/include -c -o libkvm-s390.o libkvm-s390.c libkvm-s390.c: In function 'kvm_show_regs': libkvm-s390.c:63: error: 'struct kvm_regs' has no member named 'gprs' libkvm-s390.c:64: error: 'struct kvm_regs' has no member named 'gprs' libkvm-s390.c:65: error: 'struct kvm_regs' has no member named 'gprs' Obviously some s390-specific equates are missing but I can't find any options to enable them and the arch seems correctly detected. The kernel is 2.6.26. TIA -Robin -- -- Robin Atwood. "Ship me somewheres east of Suez, where the best is like the worst, Where there ain't no Ten Commandments an' a man can raise a thirst" from "Mandalay" by Rudyard Kipling -- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]: Add a "migrate_incoming" monitor option
We've been trying to plumb libvirt to do KVM migration. One of the stumbling
blocks we are running into, however, is that libvirt expects to be able to use
the Qemu monitor both before and after migration has taken place, on both the
source and destination nodes. After migration has taken place is no problem; we
return to the main qemu select() loop, and we can run monitor commands.
However, before migration, on the destination side, when we start qemu with a
command-line like:
qemu-kvm -M pc -S blah blah -incoming tcp://0:
we can't run any monitor commands since the migration code is synchronously
waiting for an incoming tcp connection. To get around this, the following patch
adds a new monitor command called "migrate_incoming"; it takes all of the same
parameters as the command-line option, but just starts it later. To make sure
it is safe, you actually have to start with "-incoming monitor"; if you run it
without that, it will just spit an error at you. So with this in place, libvirt
can do the equivalent of:
qemu-kvm -M pc -S blah blah -incoming monitor
(qemu) info cpus
...other commands
(qemu) migrate_incoming tcp://0:
...wait for migration to start, and then complete
(qemu) info block
...etc.
Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
diff --git a/qemu/monitor.c b/qemu/monitor.c
index 20dcca6..c11b82c 100644
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -504,6 +504,25 @@ static void do_cont(void)
vm_start();
}
+static void do_migrate_incoming(const char *incom)
+{
+extern int incoming_monitor;
+
+if (!incoming_monitor) {
+term_printf("FAIL: Can only use the migrate-incoming command with -incoming monitor\n");
+}
+else {
+int rc;
+
+rc = migrate_incoming(incom);
+ if (rc != 0) {
+fprintf(stderr, "Migration failed rc=%d\n", rc);
+exit(rc);
+ }
+vm_start();
+}
+}
+
#ifdef CONFIG_GDBSTUB
static void do_gdbserver(const char *port)
{
@@ -1486,6 +1505,7 @@ static term_cmd_t term_cmds[] = {
"", "cancel the current VM migration" },
{ "migrate_set_speed", "s", do_migrate_set_speed,
"value", "set maximum speed (in bytes) for migrations" },
+{ "migrate_incoming", "s", do_migrate_incoming, "incom", "incoming string" },
{ "cpu_set", "is", do_cpu_set_nr, "cpu [online|offline]", "change cpu state" },
#if defined(TARGET_I386) || defined(TARGET_X86_64)
{ "drive_add", "iss", drive_hot_add, "pcibus pcidevfn [file=file][,if=type][,bus=n]\n"
diff --git a/qemu/vl.c b/qemu/vl.c
index e1762ee..9b5f113 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -229,6 +229,7 @@ int cursor_hide = 1;
int graphic_rotate = 0;
int daemonize = 0;
const char *incoming;
+int incoming_monitor = 0;
const char *option_rom[MAX_OPTION_ROMS];
int nb_option_roms;
int semihosting_enabled = 0;
@@ -9673,11 +9675,16 @@ int main(int argc, char **argv)
if (incoming) {
int rc;
-rc = migrate_incoming(incoming);
-if (rc != 0) {
-fprintf(stderr, "Migration failed rc=%d\n", rc);
-exit(rc);
- }
+if (strncmp(incoming, "monitor", 7) == 0) {
+incoming_monitor = 1;
+}
+else {
+rc = migrate_incoming(incoming);
+if (rc != 0) {
+fprintf(stderr, "Migration failed rc=%d\n", rc);
+exit(rc);
+}
+}
}
{
Re: [PATCH] kvm-userspace: fix memslot assignment
Am Donnerstag, 31. Juli 2008 schrieb Avi Kivity:
> If we rename the helper, kvm_wants_special_memslot_0() (reversing the
> meaning), we can have non-x86 return 0, x86 with KVM_CAP_SET_TSS_ADDR
> return 0, and otherwise return 1. No ifdefs outside the helper this way.
Having two ifdefs is not going to be very pretty, but here is the latest
version:
ppc, ia64 and s390 can start with slot 0 and it is not a special slot.
On x86 slot 0 is special, if
* KVM_CAP_SET_TSS_ADDR is not available
or
* The ioctl VM_CAP_SET_TSS_ADDR returns <=0
Lets introduce a helper that checks if we need a special memslot.
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
libkvm.c | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
Index: libkvm/libkvm.c
===
--- libkvm.orig/libkvm.c
+++ libkvm/libkvm.c
@@ -73,26 +73,29 @@ void init_slots(void)
slots[i].len = 0;
}
-int get_free_slot(kvm_context_t kvm)
+static int kvm_wants_special_memslot_0(kvm_context_t kvm)
{
- int i;
- int tss_ext;
-
-#if defined(KVM_CAP_SET_TSS_ADDR) && !defined(__s390__)
- tss_ext = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
+#if !defined(__x86_64__) && !defined(__i386__)
+ return 0;
#else
- tss_ext = 0;
-#endif
-
/*
-* on older kernels where the set tss ioctl is not supprted we must save
-* slot 0 to hold the extended memory, as the vmx will use the last 3
-* pages of this slot.
+* on older x86 kernels where the set tss ioctl is not supported we
+* must save slot 0 to hold the extended memory, as the vmx will
+* use the last 3 pages of this slot.
*/
- if (tss_ext > 0)
- i = 0;
- else
- i = 1;
+#if defined(KVM_CAP_SET_TSS_ADDR)
+ if (ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR) > 0)
+ return 0;
+#endif
+ return 1;
+#endif
+}
+
+int get_free_slot(kvm_context_t kvm)
+{
+ int i;
+
+ i = kvm_wants_special_memslot_0(kvm);
for (; i < KVM_MAX_NUM_MEM_REGIONS; ++i)
if (!slots[i].len)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add a "migrate_incoming" monitor option
On Thu, Jul 31, 2008 at 04:50:51PM +0200, Chris Lalancette wrote:
> We've been trying to plumb libvirt to do KVM migration. One of the stumbling
> blocks we are running into, however, is that libvirt expects to be able to use
> the Qemu monitor both before and after migration has taken place, on both the
> source and destination nodes. After migration has taken place is no problem;
> we
> return to the main qemu select() loop, and we can run monitor commands.
> However, before migration, on the destination side, when we start qemu with a
> command-line like:
>
> qemu-kvm -M pc -S blah blah -incoming tcp://0:
>
> we can't run any monitor commands since the migration code is synchronously
> waiting for an incoming tcp connection. To get around this, the following
> patch
> adds a new monitor command called "migrate_incoming"; it takes all of the same
> parameters as the command-line option, but just starts it later. To make sure
> it is safe, you actually have to start with "-incoming monitor"; if you run it
> without that, it will just spit an error at you. So with this in place,
> libvirt
> can do the equivalent of:
>
> qemu-kvm -M pc -S blah blah -incoming monitor
> (qemu) info cpus
> ...other commands
> (qemu) migrate_incoming tcp://0:
> ...wait for migration to start, and then complete
> (qemu) info block
> ...etc.
>
> Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
> diff --git a/qemu/monitor.c b/qemu/monitor.c
> index 20dcca6..c11b82c 100644
> --- a/qemu/monitor.c
> +++ b/qemu/monitor.c
> @@ -504,6 +504,25 @@ static void do_cont(void)
> vm_start();
> }
>
> +static void do_migrate_incoming(const char *incom)
> +{
> +extern int incoming_monitor;
> +
> +if (!incoming_monitor) {
> +term_printf("FAIL: Can only use the migrate-incoming command with
> -incoming monitor\n");
> +}
> +else {
> +int rc;
> +
> +rc = migrate_incoming(incom);
You probably want to set 'incoming_monitor = 0' here, to protect against
someone accidentially running it multiple times.
> + if (rc != 0) {
> +fprintf(stderr, "Migration failed rc=%d\n", rc);
> +exit(rc);
> + }
And some whitespace issues here..
> +vm_start();
> +}
> +}
> +
> #ifdef CONFIG_GDBSTUB
> static void do_gdbserver(const char *port)
> {
> @@ -1486,6 +1505,7 @@ static term_cmd_t term_cmds[] = {
>"", "cancel the current VM migration" },
> { "migrate_set_speed", "s", do_migrate_set_speed,
>"value", "set maximum speed (in bytes) for migrations" },
> +{ "migrate_incoming", "s", do_migrate_incoming, "incom", "incoming
> string" },
> { "cpu_set", "is", do_cpu_set_nr, "cpu [online|offline]", "change cpu
> state" },
> #if defined(TARGET_I386) || defined(TARGET_X86_64)
> { "drive_add", "iss", drive_hot_add, "pcibus pcidevfn
> [file=file][,if=type][,bus=n]\n"
> diff --git a/qemu/vl.c b/qemu/vl.c
> index e1762ee..9b5f113 100644
> --- a/qemu/vl.c
> +++ b/qemu/vl.c
> @@ -229,6 +229,7 @@ int cursor_hide = 1;
> int graphic_rotate = 0;
> int daemonize = 0;
> const char *incoming;
> +int incoming_monitor = 0;
> const char *option_rom[MAX_OPTION_ROMS];
> int nb_option_roms;
> int semihosting_enabled = 0;
> @@ -9673,11 +9675,16 @@ int main(int argc, char **argv)
> if (incoming) {
> int rc;
>
> -rc = migrate_incoming(incoming);
> -if (rc != 0) {
> -fprintf(stderr, "Migration failed rc=%d\n", rc);
> -exit(rc);
> - }
> +if (strncmp(incoming, "monitor", 7) == 0) {
> +incoming_monitor = 1;
> +}
> +else {
> +rc = migrate_incoming(incoming);
> +if (rc != 0) {
> +fprintf(stderr, "Migration failed rc=%d\n", rc);
> +exit(rc);
> +}
> +}
Rather than putting the strncmp("monitor") into vl.c, I'd just leave
this part as is. Put the logic into the 'migrate_incoming()' method
so that it just sets the 'incoming_monitor' flag and then returns
immediately. That would allwo the 'incoming_Monitor' flag to be declared
static to the migrate.c file, instead of polluting vl.c
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM: fix i8259 reset irq acking
The irq ack during pic reset has three problems:
- Ignores slave/master PIC, using gsi 0-8 for both.
- Generates an ACK even if the APIC is in control.
- Depends upon IMR being clear, which is broken if the
irq was masked at the time it was generated.
The last one causes the BIOS to hang after the first reboot of Windows
installation, since PIT interrupts stop.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index de70499..2b42d48 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -195,14 +195,18 @@ int kvm_pic_read_irq(struct kvm *kvm)
void kvm_pic_reset(struct kvm_kpic_state *s)
{
- int irq;
+ int irq, irqbase;
struct kvm *kvm = s->pics_state->irq_request_opaque;
- for (irq = 0; irq < PIC_NUM_PINS; irq++) {
- if (!(s->imr & (1 << irq)) && (s->irr & (1 << irq) ||
- s->isr & (1 << irq)))
- kvm_notify_acked_irq(kvm, irq);
- }
+ if (s == &s->pics_state->pics[0])
+ irqbase = 0;
+ else
+ irqbase = 8;
+
+ if (!kvm_lapic_enabled(kvm->vcpus[0]))
+ for (irq = 0; irq < PIC_NUM_PINS/2; irq++)
+ if (s->irr & (1 << irq) || s->isr & (1 << irq))
+ kvm_notify_acked_irq(kvm, irq+irqbase);
s->last_irr = 0;
s->irr = 0;
s->imr = 0;
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add a "migrate_incoming" monitor option
Chris Lalancette wrote: We've been trying to plumb libvirt to do KVM migration. One of the stumbling blocks we are running into, however, is that libvirt expects to be able to use the Qemu monitor both before and after migration has taken place, on both the source and destination nodes. After migration has taken place is no problem; we return to the main qemu select() loop, and we can run monitor commands. However, before migration, on the destination side, when we start qemu with a command-line like: qemu-kvm -M pc -S blah blah -incoming tcp://0: we can't run any monitor commands since the migration code is synchronously waiting for an incoming tcp connection. To get around this, the following patch adds a new monitor command called "migrate_incoming"; it takes all of the same parameters as the command-line option, but just starts it later. To make sure it is safe, you actually have to start with "-incoming monitor"; if you run it without that, it will just spit an error at you. So with this in place, libvirt can do the equivalent of: qemu-kvm -M pc -S blah blah -incoming monitor I think adding a 'nowait' parameter to migration would make more sense than introducing a monitor command. So: qemu-kvm -M pc -S blah blah -incoming tcp://0:,nowait From an implementation perspective, it's just a matter of setting a callback for the accept fd I imagine. Regards, Anthony Liguori (qemu) info cpus ...other commands (qemu) migrate_incoming tcp://0: ...wait for migration to start, and then complete (qemu) info block ...etc. Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RESEND] x86_emulator: Emulate cld and std instruction
On Thu, Jul 31, 2008 at 01:25:40PM +0300, Mohammed Gamal wrote: > The only check was if CS RPL equals SS RPL, so what happens is that > when a vmexit and then a vmentry occurs CS and SS RPL maybe equal, but Yes same problem here, vmentry fails because CS is set to >16 bit value (I think) but the last two bits of CS and SS are the same. That surely is the wrong check to know if we've to invoke emulation on vmentry failure. > other checks might cause a vmentry failure. I've written a function to > check that guest state is VMX valid - although not all checks are > implemented yet, and I no more get the occasional vmexits. Can you send me your latest patch so I can test. I tried to force unconditional emulation on invalid guest state exception generated by vmentry failure but even emulation fails for me, and then your patch sets SS to sane value but that's meaningless here as it's CS that is set to >16bit value. I've yet to trace where emulation fails, but I suspect it's fetching instructions from the wrong place by not emulating the segment-caches set by protected mode, maybe not. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fresh install of Windows XP hangs early in boot?
On Tue, Jul 29, 2008 at 10:27:14PM -0700, Roland Dreier wrote: > > Known problem: > > http://www.nabble.com/LSI:-avoid-infinite-loops-p17116605.html > > I tried this hack (and actually made the magic insns number 500), and > doing an XP install I got > > lsi_scsi: error: Reselect with pending DMA > > do you have any feeling if this is because the script execution got > stopped too soon? Or is this likely a further issue? Perhaps the context that was stopped due to > 500 instructions was handling a DMA operation that didnt finish. Since the hack won't restart execution by itself, the driver executed a command (probably SIGP) to restart, leaving the DMA operation unfinished. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2001452 ] Restarted Windows 2003 Server guests have disk corruption
Bugs item #2001452, was opened at 2008-06-24 07:27 Message generated for change (Comment added) made by gerdwachs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2001452&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: gwachs (gerdwachs) Assigned to: Nobody/Anonymous (nobody) Summary: Restarted Windows 2003 Server guests have disk corruption Initial Comment: I have a number of Windows 2003 32Bit guests. I use them to perform installation and configuration tests of a large software product. During these tests, the guests are restarted. Randomly, the guests produce disk corruption messages after a restart. The following are two examples : --- Windows Registry Hive Recovered Registry hive (file): SOFTWARE was corrupted and it has been recovered. Some data might have been lost. --- The system cannot log on due to the following error: Unable to complete the requested operation because of either a catastrophic media failure or a data structure corruption on the disk. --- OS : Ubuntu 8.04 x86_64 Kernel : 2.6.24-18-server #1 SMP x86_64 GNU/Linux KVM: kvm-70 CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xt Start Command : sudo /usr/local/kvm/bin/qemu-system-x86_64 -hda asit51ascs.img \ -m 1024 -std-vga -boot c -k sv -usb -usbdevice tablet -snapshot -vnc :51 \ -net nic,vlan=0,macaddr=00:16:3e:00:51:00 -net tap,vlan=0,script=/etc/qemu-ifup-br0 \ -net nic,vlan=1,macaddr=00:16:3e:00:51:01 -net tap,vlan=1,script=/etc/qemu-ifup-br1 no-kvm : Cannot do due to the loss of performance. Tests execute time is 7 hours with kvm. -- >Comment By: gwachs (gerdwachs) Date: 2008-07-31 22:55 Message: Logged In: YES user_id=2122332 Originator: YES I always start with a newly created image file and install from a Windows 2003 Server ISO which is well tested in the physical machines and under vmware. To give a little more background, I install the following before installing the product under test (restarting when approprate) : Windows Updates, Acorbat, Office 2003, Winzip, Visual Basic 6, DirectX, SQL Server, Oracle Server. The products we test require a DVD for space. This may be a more heavy usage of Windows 2003 Server running in a kvm environment. -- Comment By: Jamie Lokier (jlokier) Date: 2008-07-31 07:19 Message: Logged In: YES user_id=1233069 Originator: NO Did you start with the Windows Server 2003 image which is available free from Microsoft, and convert it to qcow2 using 'qemu-img convert'? That conversion is known to be buggy. -- Comment By: gwachs (gerdwachs) Date: 2008-07-17 09:39 Message: Logged In: YES user_id=2122332 Originator: YES I use qcow2 The host disk format is xfs I do not have access to the computers until Aug 10th so I cannot test the raw format until them. -- Comment By: Avi Kivity (avik) Date: 2008-07-16 16:23 Message: Logged In: YES user_id=539971 Originator: NO What disk format are you using? Does switching to raw format help? -- Comment By: gwachs (gerdwachs) Date: 2008-07-10 07:10 Message: Logged In: YES user_id=2122332 Originator: YES Regarding using daily builds. >From Build 20080707, my existing guests would not start. Have rebuilt one guest using 20080708. Seems OK but need to be running more guests for longer time to be sure. I will not have access to the environment from July 12 to Aug 10 -- Comment By: gwachs (gerdwachs) Date: 2008-06-30 13:27 Message: Logged In: YES user_id=2122332 Originator: YES Sorry, I am not that advanced on the usage of git. If you would care to send instructions, I will try. I am currently using the latest snapshots. It appears to be working enough to for my requirements, but I have still been getting the odd corruption message. P.S. I believe that kvm is an absolute winning concept. -- Comment By: Brian Jackson (iggy_cav) Date: 2008-0
Re: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Yang, Sheng wrote: Rather than 0x1, which can be overrided by userspace program like grub. Could you please explain this problem? If i don't misunderstand this smp_ap_boot_code_start from rombios32start.S gets copied to AP_BOOT_CODE and then there is a broadcast INIT and SIPI. After the code is run it's not used anymore so there should be no need to care where it's located. - Sebastian -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: bios: Put AP boot up code to 0x1000
On Friday 01 August 2008 05:15:11 Sebastian Herbszt wrote: > Yang, Sheng wrote: > > Rather than 0x1, which can be overrided by userspace program > > like grub. > > Could you please explain this problem? > If i don't misunderstand this smp_ap_boot_code_start from > rombios32start.S gets copied to AP_BOOT_CODE and then there is a > broadcast INIT and SIPI. After the code is run it's not used > anymore so there should be no need to care where it's located. > > - Sebastian Hi Sebastian Please refer to my another patch comment. Basicly, AP is running HLT in 0x10038, but it can exit due to some reason, here QEmu want to raise it up . But after AP exit from HLT, it can't return to it because the code was overrided by grub and no HLT loop there. Then AP had gone away... -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/04]Create x86 directory to hold x86-specific files.
Avi Kivity wrote: > Zhang, Xiantao wrote: >> Avi Kivity wrote: >> >>> Zhang, Xiantao wrote: >>> From c8c8c5a6b3ff943cb645f9ac4ef169490f14cd08 Mon Sep 17 00:00:00 2001 From: Zhang Xiantao <[EMAIL PROTECTED]> Date: Fri, 25 Jul 2008 16:50:30 +0800 Subject: [PATCH] KVM: external module: Moving x86-speicif files to x86 directory. Create x86 directory to hold x86-specific files. Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]> >>> You forgot to attach a patch; and your mailer corrupts patches, so >>> I can't apply this. >>> >> >> Sorry. Attached! :) >> > > Applied all, but I had to revert the change to the install command in > the last patch. My install doesn't like the -C option. Please check > if further changes are necessary. Hi, Avi -t should be a new argument for installer, and doesn't exist in many older Linux systems, for example, my RHEL4.3 can't recognize it at all. How to make it work well in these systems ? Xiantao -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] KVM/userspace: Support for assigning PCI devices to guest
Ben-Ami Yassour wrote:
> +#define assigned_dev_ioport_write(suffix)
\
> +static void assigned_dev_ioport_write##suffix(void *opaque,
> \ + uint32_t addr,
\
> + uint32_t value)
\
> +{
\
> + assigned_dev_region_t *r_access =
\
> + (assigned_dev_region_t *)opaque;
\
> + uint32_t r_pio = (unsigned long)r_access->r_virtbase
\
> + + (addr - r_access->e_physbase);
\
> + if (r_access->debug & DEVICE_ASSIGNMENT_DEBUG_PIO) {
\
> + fprintf(logfile, "assigned_dev_ioport_write" #suffix
\
> + ": r_pio=%08x e_physbase=%08x"
\
> + " r_virtbase=%08lx value=%08x\n",
\
> + r_pio, (int)r_access->e_physbase,
\
> + (unsigned long)r_access->r_virtbase, value);
\
> + }
\
> + iopl(3);\
> + out##suffix(value, r_pio);
\
> +}
> +assigned_dev_ioport_write(b)
> +assigned_dev_ioport_write(w)
> +assigned_dev_ioport_write(l)
> +
> +#define assigned_dev_ioport_read(suffix)
\
> +static uint32_t assigned_dev_ioport_read##suffix(void *opaque,
> \ + uint32_t addr)
\
> +{
\
> + assigned_dev_region_t *r_access =
\
> +(assigned_dev_region_t *)opaque;
\
> + uint32_t r_pio = (addr - r_access->e_physbase)
\
> + + (unsigned long)r_access->r_virtbase;
\
> + uint32_t value = in##suffix(r_pio);
\
> + if (r_access->debug & DEVICE_ASSIGNMENT_DEBUG_PIO) {
\
> + fprintf(logfile, "assigned_dev_ioport_read"
\
> +#suffix ": r_pio=%08x "
> \ +"e_physbase=%08x r_virtbase=%08lx
> " \ + "value=%08x\n",
\
> + r_pio, (int)r_access->e_physbase,
\
> + (unsigned long)r_access->r_virtbase,
\
> +value);
\
> + }
\
> + return value;
\
> +}
> +
> +assigned_dev_ioport_read(b)
> +assigned_dev_ioport_read(w)
> +assigned_dev_ioport_read(l)
> +
Need to add iopl(3) in assigned_dev_ioport_read##suffix(). ioport read
may be before ioport write. When assign USB controller to guest, I found
it read ioport before write. If there is no iopl(3) in
assigned_dev_ioport_read##suffix(), it results in "segmentation fault".
BTW, code style in assigned_dev_ioport_read##suffix() is not correct,
pls update it.
Randy (Weidong)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2034672 ] guest: BUG: soft lockup - CPU#0 stuck for 41s!
Bugs item #2034672, was opened at 2008-08-01 08:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2034672&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rafal Wijata (ravpl) Assigned to: Nobody/Anonymous (nobody) Summary: guest: BUG: soft lockup - CPU#0 stuck for 41s! Initial Comment: host: kvm71, 64bit 2.6.25.11-60.fc8, 8Gram, 2*E5420(8cores), 3ware raid10 guest: 64bit 2.6.18-92.1.6.el5, 5Gram, 6cpus, hdd on raw file. I know this bug happens even in non-virtual machines(browsing internet shows that clearly), but inside kvm I'm getting excessive rate of this bug (under load, even few times a hour) An example can be found at end of this message. The record was something over 500 seconds !! Now, I suspect it has something to do with the network or net driver. There's almost always either swapper or network service in the backtrace. But I cannot confirm for surely. BUG: soft lockup - CPU#0 stuck for 41s! [events/0:20] CPU 0: Modules linked in: nfsd exportfs auth_rpcgss ipv6 xfrm_nalgo crypto_api autofs4 nfs lockd fscache nfs_acl sunrpc dm_mirror dm_multipath dm_mod video sbs backlight i2c_ec button battery asus_acpi acpi_memhotplug ac lp floppy loop ide_cd parport_pc i2c_piix4 serio_raw parport cdrom i2c_core e1000 pcspkr ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 20, comm: events/0 Not tainted 2.6.18-92.1.6.el5 #1 RIP: 0010:[] [] __do_softirq+0x53/0xd6 RSP: 0018:80418f60 EFLAGS: 0206 RAX: 0002 RBX: 803b6f80 RCX: 0380 RDX: 81015f9e7fd8 RSI: 0280 RDI: 81015f9d97a0 RBP: 80418ee0 R08: 0001 R09: 810080bf5000 R10: 0046 R11: 0246 R12: 8005dc8e R13: 0002 R14: 80077090 R15: 80418ee0 FS: () GS:8039f000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 00300c203080 CR3: 00015df0a000 CR4: 06e0 Call Trace: [] call_softirq+0x1c/0x28 [] do_softirq+0x2c/0x85 [] apic_timer_interrupt+0x66/0x6c [] _spin_unlock_irqrestore+0x8/0x9 [] :e1000:e1000_update_stats+0x5f6/0x5fd [] :e1000:e1000_watchdog_task+0x535/0x65a [] run_workqueue+0x94/0xe4 [] worker_thread+0x0/0x122 [] worker_thread+0xf0/0x122 [] default_wake_function+0x0/0xe [] kthread+0xfe/0x132 [] child_rip+0xa/0x11 [] kthread+0x0/0x132 [] child_rip+0x0/0x11 BUG: soft lockup - CPU#2 stuck for 17s! [swapper:0] CPU 2: Modules linked in: nfsd exportfs auth_rpcgss ipv6 xfrm_nalgo crypto_api autofs4 nfs lockd fscache nfs_acl sunrpc dm_mirror dm_multipath dm_mod video sbs backlight i2c_ec button battery asus_acpi acpi_memhotplug ac lp floppy loop ide_cd parport_pc i2c_piix4 serio_raw parport cdrom i2c_core e1000 pcspkr ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 0, comm: swapper Not tainted 2.6.18-92.1.6.el5 #1 RIP: 0010:[] [] default_idle+0x29/0x50 RSP: 0018:810104e63ef0 EFLAGS: 0246 RAX: RBX: 0002 RCX: RDX: RSI: 0001 RDI: 802e6658 RBP: 810104e1d270 R08: 810104e62000 R09: 003e R10: 810104f64038 R11: R12: 0c51b3f5 R13: 3434e623bb62 R14: 81015f9db7e0 R15: 810104e1d080 FS: () GS:810104e1cec0() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b3a3b647230 CR3: 00201000 CR4: 06e0 Call Trace: [] cpu_idle+0x95/0xb8 [] start_secondary+0x45a/0x469 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2034672&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
