Re: [kvm-devel] [PATCH] Moving unalias_gfn to x86.c
On Thu, 2007-11-22 at 11:25 +0800, Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Thu, 22 Nov 2007 11:20:33 +0800 Subject: [PATCH] KVM Portability: moving unalias_gfn to arch. Non-x86 archs don't need this mechanism. Move it to arch, and keep its interface in common. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] --- this is good, we probably want to change gfn_to_memslot() to have #ifdef kvm_x86 to call the unalias memory and gfn_to_hva on x86 still must to call unalias_gfn() so it will probably need a ifdef as well. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-53
On Wed, 2007-11-21 at 20:16 -0500, Haydn Solomon wrote: Sorry to be late on reporting on kvm-53 release but I have had host hang and BSOD when running windows xp sp2 32-bit guest. I have had to revert to release 51 as I also have problems with release 52 (boot failure). My host does have flexpriority and details are as follows: you still get bad_page state count 0 messages? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Moving unalias_gfn to x86.c
Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Thu, 22 Nov 2007 11:20:33 +0800 Subject: [PATCH] KVM Portability: moving unalias_gfn to arch. Non-x86 archs don't need this mechanism. Move it to arch, and keep its interface in common. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] Acked-by: Carsten Otte [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Moving unalias_gfn to x86.c
Izik Eidus wrote: On Thu, 2007-11-22 at 11:25 +0800, Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Thu, 22 Nov 2007 11:20:33 +0800 Subject: [PATCH] KVM Portability: moving unalias_gfn to arch. Non-x86 archs don't need this mechanism. Move it to arch, and keep its interface in common. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] --- this is good, we probably want to change gfn_to_memslot() to have #ifdef kvm_x86 to call the unalias memory and gfn_to_hva on x86 still must to call unalias_gfn() so it will probably need a ifdef as well. Don't know #ifdef way is acceptable. If yes, sure to do that. Contrarily, other archs can define it , and just returen original gfn instead:) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Moving unalias_gfn to x86.c
On Thu, 2007-11-22 at 17:09 +0800, Zhang, Xiantao wrote: Izik Eidus wrote: On Thu, 2007-11-22 at 11:25 +0800, Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Thu, 22 Nov 2007 11:20:33 +0800 Subject: [PATCH] KVM Portability: moving unalias_gfn to arch. Non-x86 archs don't need this mechanism. Move it to arch, and keep its interface in common. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] --- this is good, we probably want to change gfn_to_memslot() to have #ifdef kvm_x86 to call the unalias memory and gfn_to_hva on x86 still must to call unalias_gfn() so it will probably need a ifdef as well. Don't know #ifdef way is acceptable. If yes, sure to do that. Contrarily, other archs can define it , and just returen original gfn instead:) ok so call to kvm_arch_gfn_to_memslot() or something like that can be done the same with kvm_arch_gva_to_hva() this both will call to kvm_gva_to_hva() that will share most of the code ... - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-53
Farkas Levente wrote: Alexey Eremenko wrote: OK, I have found that Mandrake Linux 9.0 works on Intel/x86-64 on KVM-51. Does this help you for now ? I will try to look further. try with kvm-53! it do not even start to boot for me (actually i don't remember for the kvm-51 result but it may be worked with kvm-51). That bug is fixed for kvm-54. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]KVM: VMX: Remove the secondary execute control depends on irqchip
Sheng Yang wrote: From 140114fbd60afaf08fde429d05c280d88205051b Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Wed, 21 Nov 2007 14:33:25 +0800 Subject: [PATCH] KVM: VMX: Remove the secondary execute control depends on irqchip The state of SECONDARY_VM_EXEC_CONTROL shouldn't depend on in-kernel IRQ chip, this patch fix this. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
Hello,
CMPS and SCAS instructions accept repeat prefixes F3 and F2. So in
order to emulate those prefixed instructions we need to be able to know
if prefixes are REP/REPE/REPZ or REPNE/REPNZ. Currently kvm doesn't make
this distinction. This patch introduces this distinction.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c |4 +++-
drivers/kvm/x86_emulate.h |4
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index bebdcee..f8e7200 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -824,8 +824,10 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
c-lock_prefix = 1;
break;
case 0xf2: /* REPNE/REPNZ */
+ c-rep_prefix = REPNE_REPNZ;
+ break;
case 0xf3: /* REP/REPE/REPZ */
- c-rep_prefix = 1;
+ c-rep_prefix = REP_REPE_REPZ;
break;
default:
goto done_prefixes;
diff --git a/drivers/kvm/x86_emulate.h b/drivers/kvm/x86_emulate.h
index 31aa3e1..5ce4c0c 100644
--- a/drivers/kvm/x86_emulate.h
+++ b/drivers/kvm/x86_emulate.h
@@ -161,6 +161,10 @@ struct x86_emulate_ctxt {
struct decode_cache decode;
};
+/* Repeat String Operation Prefix */
+#define REP_REPE_REPZ 1
+#define REPNE_REPNZ2
+
/* Execution mode, passed to the emulator. */
#define X86EMUL_MODE_REAL 0/* Real mode. */
#define X86EMUL_MODE_PROT16 2/* 16-bit protected mode. */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Moving unalias_gfn to x86.c
Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Thu, 22 Nov 2007 11:20:33 +0800 Subject: [PATCH] KVM Portability: moving unalias_gfn to arch. Non-x86 archs don't need this mechanism. Move it to arch, and keep its interface in common. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
Guillaume Thouvenin wrote: Hello, CMPS and SCAS instructions accept repeat prefixes F3 and F2. So in order to emulate those prefixed instructions we need to be able to know if prefixes are REP/REPE/REPZ or REPNE/REPNZ. Currently kvm doesn't make this distinction. This patch introduces this distinction. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: add definition for kvm_qemu_check_extension to qemu-kvm.h
Carlo Marcelo Arenas Belon wrote: The following patch complement c79baa60813812e8d0e34d998d609e8 to avoid the implicit declaration of kvm_qemu_check_extension as shown by : kvm-53/qemu/vl.c: In function `main': kvm-53/qemu/vl.c:8675: warning implicit declaration of function `kvm_qemu_check_extension' kvm-53/qemu/hw/pc.c:727: warning: implicit declaration of function `kvm_qemu_check_extension' Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] VM networking stops working
Lynn Kerby schrieb: On Nov 21, 2007, at 12:52 PM, Mike wrote: Hello, I have a problem with my virtual machines. I am using kvm53 on an AMD Athlon(tm) 64 X2 Dual Core Processor 5000+. As distribution I use Ubuntu server 7.10. As kernel I use Linux 2.6.22-14-server #1 SMP Sun Oct 14 22:09:15 GMT 2007 x86_64 GNU/Linux. I have 3 different vms running. At the beginning they all work without a problem. Then, after one moment to another one or more stop working. I did a ping test to all the machines, the vm with the failure stops pinging. The result from external ping: Destination host unreachable. The same result from a ping onto the main server. Here are my configuration files: cat /etc/qemu-ifup #!/bin/sh /sbin/ifconfig $1 0.0.0.0 promisc up /usr/sbin/brctl addif br0 $1 sleep 2 cat /etc/network/interfaces auto lo iface lo inet loopback auto br0 iface br0 inet static address 195.24.77.169 netmask 255.255.255.0 gateway 195.24.77.1 bridge_ports eth0 bridge_stp off bridge_maxwait 5 I use scripts for starting the vms: kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net nic,vlan=0,macaddr=00:16:3e:00:00:01 -net tap -nographic -daemonize kvm -hda postfix.img -m 512 -boot c -net nic,vlan=0,macaddr=00:16:3e:00:00:12 -net tap -nographic -daemonize kvm -hda openvpn.img -m 256 -boot c -net nic,vlan=0,macaddr=00:16:3e:00:00:03 -net tap -nographic -daemonize The tapN devices are being created at the startup of the vms. When I run dmesg I have this: [ 112.390943] br0: port 2(tap1) entering learning state [ 112.391919] br0: port 3(tap0) entering learning state [ 112.397605] br0: port 4(tap2) entering learning state [ 122.674313] tap0: no IPv6 routers present [ 122.729185] tap1: no IPv6 routers present [ 122.843901] tap2: no IPv6 routers present [ 123.336081] kvm: emulating exchange as write [ 127.367940] br0: topology change detected, propagating [ 127.367949] br0: port 4(tap2) entering forwarding state [ 127.362971] br0: topology change detected, propagating [ 127.362977] br0: port 2(tap1) entering forwarding state [ 127.362978] br0: topology change detected, propagating [ 127.362980] br0: port 3(tap0) entering forwarding state No indication of a problem, nowhere in the log files. I don't know if the vms are freezing, or the network forwarding stops working. I also activated net.ipv4.conf.default.forwarding=1 I googled days for that problem, but without a result. I hope that maybe you have a solution for this problem. That would be great, because I prefer using kvm instead of other virtualization systems. Thank you very much in advance, Greetings from Luxembourg. Have a nice day, Mike I had similar problems for my first week or so of trying to use KVM for my virtualization needs. My problem was solved by adding a model=rtl8139 to the first -net option on the kvm/qemu command. The default ne2k emulation seems to be broken. Another possibility is problems with macaddr. In my testing I found that several of my machines were getting the same macaddr by default so now I specify them explicitly for each VM (or generate a dummy one based on the time for testing). An example from one of my KVMMs (hopefully line wrapping won't interfere): /usr/local/bin/qemu-system-x86_64 -name DOM9-BSD62 -hda /vm_img/bsd_in1/dom9-disk1.qcow \ -hdb /vm_img/bsd_in1/dom9-disk2.raw -m 512 -boot c -smp 2 -usb -usbdevice tablet -vnc :9 \ -serial telnet::4109,server,nowait -monitor telnet::4209,server,nowait \ -net nic,vlan=0,macaddr=52:54:09:12:34:56,model=rtl8139 \ -net tap,vlan=0,ifname=tap1,script=/etc/kvm/kvm-ifup Lynn Kerby It's working now. I added model=rtl8139 to the start command of all vms. Now, the network connection works without problems. I did a test the whole night long. Thank you for your help. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Compile problem with GIT repo on Scientific Linux
Cam Macdonell wrote: Hi, I'm trying to install KVM using the git repos on Scientific Linux. The error occurs when I run make. The kvm-53 tarball works fine, but something is getting misconfigured when I run make -C kernel sync. This error doesn't occur on Fedora Core. I installed kernel-headers using yum in the standard way Has anyone experienced this problem with other RHEL clones like CentOS? I just pushed a fix for this. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
* Guillaume Thouvenin wrote:
Hello,
CMPS and SCAS instructions accept repeat prefixes F3 and F2. So in
order to emulate those prefixed instructions we need to be able to know
if prefixes are REP/REPE/REPZ or REPNE/REPNZ. Currently kvm doesn't make
this distinction. This patch introduces this distinction.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c |4 +++-
drivers/kvm/x86_emulate.h |4
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index bebdcee..f8e7200 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -824,8 +824,10 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops) c-lock_prefix = 1;
break;
case 0xf2: /* REPNE/REPNZ */
+ c-rep_prefix = REPNE_REPNZ;
+ break;
case 0xf3: /* REP/REPE/REPZ */
- c-rep_prefix = 1;
+ c-rep_prefix = REP_REPE_REPZ;
break;
default:
goto done_prefixes;
diff --git a/drivers/kvm/x86_emulate.h b/drivers/kvm/x86_emulate.h
index 31aa3e1..5ce4c0c 100644
--- a/drivers/kvm/x86_emulate.h
+++ b/drivers/kvm/x86_emulate.h
@@ -161,6 +161,10 @@ struct x86_emulate_ctxt {
struct decode_cache decode;
};
+/* Repeat String Operation Prefix */
+#define REP_REPE_REPZ 1
+#define REPNE_REPNZ2
Can you just rename this to REP and REPNE?
Does this fix the problems you saw with openbsd?
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
On Thu, 22 Nov 2007 17:27:55 +0530 Amit Shah [EMAIL PROTECTED] wrote: Can you just rename this to REP and REPNE? Yes I can. I send the new patch. Does this fix the problems you saw with openbsd? No not yet. It will help to make the difference between REPE prefix and REPNE prefix because both can be added to the CMPS and SCAS instruction. To be able to boot OpenBSD41 properly we need to emulate CMPS. I replaced CMPS by a NOP instruction and it allows me to boot openbsd but it's not really an acceptable solution, it was just to see if that the emulation of CMPS instruction was the problem. Guillaume - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
CMPS and SCAS instructions accept repeat prefixes REPE and REPNE. So in
order to emulate those prefixed instructions we need to be able to know
if prefixes are REP/REPE/REPZ or REPNE/REPNZ. Currently kvm doesn't
make this distinction. This patch introduces this distinction.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c |4 +++-
drivers/kvm/x86_emulate.h |4
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index bebdcee..3eae1b1 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -824,8 +824,10 @@ x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
c-lock_prefix = 1;
break;
case 0xf2: /* REPNE/REPNZ */
+ c-rep_prefix = REPNE;
+ break;
case 0xf3: /* REP/REPE/REPZ */
- c-rep_prefix = 1;
+ c-rep_prefix = REP;
break;
default:
goto done_prefixes;
diff --git a/drivers/kvm/x86_emulate.h b/drivers/kvm/x86_emulate.h
index 31aa3e1..2252989 100644
--- a/drivers/kvm/x86_emulate.h
+++ b/drivers/kvm/x86_emulate.h
@@ -161,6 +161,10 @@ struct x86_emulate_ctxt {
struct decode_cache decode;
};
+/* Repeat String Operation Prefix */
+#define REP1
+#define REPNE 2
+
/* Execution mode, passed to the emulator. */
#define X86EMUL_MODE_REAL 0/* Real mode. */
#define X86EMUL_MODE_PROT16 2/* 16-bit protected mode. */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
* Guillaume Thouvenin wrote: On Thu, 22 Nov 2007 17:27:55 +0530 Amit Shah [EMAIL PROTECTED] wrote: Can you just rename this to REP and REPNE? Yes I can. I send the new patch. Does this fix the problems you saw with openbsd? No not yet. It will help to make the difference between REPE prefix and REPNE prefix because both can be added to the CMPS and SCAS instruction. To be able to boot OpenBSD41 properly we need to emulate CMPS. I replaced CMPS by a NOP instruction and it allows me to boot openbsd but it's not really an acceptable solution, it was just to see if that the emulation of CMPS instruction was the problem. OK, that sounds great! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Expose host cpuid to guest
On Thu, Nov 22, 2007 at 10:12:04AM +1030, Mike Lampard wrote: On Wed, 21 Nov 2007 09:36:31 pm Dan Kenigsberg wrote: These patches expose host CPU features (that are known to work under KVM) to guests. It makes a couple of benchmarks run faster, and generally gives kvm's user better info on its host. The kernel-space patch adds KVM_GET_SUPPORTED_CPUID ioctl to obtain the table of cpuid functions supported by the host. The user-space patch allows fine-tuning this table from the command-line. I had to define struct kvm_cpuid2, KVM_SET_CPUID2 etc., because cpuid functions are a little more complex than just function-value pairs. Dan. With current kvm-git (commit 51727a110220681f6f43b005d069e28c58f5d151) (userspace is current to commit 6a385c9539f9746d7ff51ef34c064c3eba86448b) and the userspace portion of this patch I cannot boot a 64 bit guest (Mandriva 2008 x64) on my AMD x2 without -cpu host. The guest kernel says Your CPU does not support long mode. Use a 32bit distribution.. Works fine without the userspace portion of the patch. Thanks for your report. I'm probably not exposing one(?) of AMD's x86_64 required cpuid features. However, I fail to reproduce this on Dual-Core AMD Opteron(tm) Processor 2210 running 2.6.18-8.1.15.el5. What is your host? Dan. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Expose host cpuid to guest
On Thu, 22 Nov 2007 11:31:18 pm Dan Kenigsberg wrote: On Thu, Nov 22, 2007 at 10:12:04AM +1030, Mike Lampard wrote: On Wed, 21 Nov 2007 09:36:31 pm Dan Kenigsberg wrote: These patches expose host CPU features (that are known to work under KVM) to guests. It makes a couple of benchmarks run faster, and generally gives kvm's user better info on its host. The kernel-space patch adds KVM_GET_SUPPORTED_CPUID ioctl to obtain the table of cpuid functions supported by the host. The user-space patch allows fine-tuning this table from the command-line. I had to define struct kvm_cpuid2, KVM_SET_CPUID2 etc., because cpuid functions are a little more complex than just function-value pairs. Dan. With current kvm-git (commit 51727a110220681f6f43b005d069e28c58f5d151) (userspace is current to commit 6a385c9539f9746d7ff51ef34c064c3eba86448b) and the userspace portion of this patch I cannot boot a 64 bit guest (Mandriva 2008 x64) on my AMD x2 without -cpu host. The guest kernel says Your CPU does not support long mode. Use a 32bit distribution.. Works fine without the userspace portion of the patch. Thanks for your report. I'm probably not exposing one(?) of AMD's x86_64 required cpuid features. However, I fail to reproduce this on Dual-Core AMD Opteron(tm) Processor 2210 running 2.6.18-8.1.15.el5. What is your host? 64bit 2.6.23.8 on an AMD Athlon X2 4400. cpuid flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse If you need further info, just yell. I didnt want to clutter up the mailinglist with the full output of cpuid, but will if it helps you. Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make distinction between repeat prefixes F3 and F2
Guillaume Thouvenin wrote: On Thu, 22 Nov 2007 17:27:55 +0530 Amit Shah [EMAIL PROTECTED] wrote: Can you just rename this to REP and REPNE? Yes I can. I send the new patch. Too late, merged it already. Does this fix the problems you saw with openbsd? No not yet. It will help to make the difference between REPE prefix and REPNE prefix because both can be added to the CMPS and SCAS instruction. To be able to boot OpenBSD41 properly we need to emulate CMPS. I replaced CMPS by a NOP instruction and it allows me to boot openbsd but it's not really an acceptable solution, it was just to see if that the emulation of CMPS instruction was the problem. What is cmps accessing? VGA memory? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Expose host cpuid to guest
Mike Lampard wrote: With current kvm-git (commit 51727a110220681f6f43b005d069e28c58f5d151) (userspace is current to commit 6a385c9539f9746d7ff51ef34c064c3eba86448b) and the userspace portion of this patch I cannot boot a 64 bit guest (Mandriva 2008 x64) on my AMD x2 without -cpu host. The guest kernel says Your CPU does not support long mode. Use a 32bit distribution.. Works fine without the userspace portion of the patch. With -cpu host, the 64bit kernel starts to boot then panics almost immediately: Code: 0f 30 e9 ed fc ff ff b8 66 00 00 00 f0 0f ab 45 08 e9 e2 fa RIP [8020ff99 identify_cpu+0x609/0x700 RSP 8057df58 Kernel panic - not syncing: Attempted to kill the idle task! In the host log I see: cpu0 unhandled wrmsr: 0xc0010015, which might not have anything to do with this patch of course :) A listing/disassembly of the function will help show where the problem is. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Expose host cpuid to guest
On Thu, Nov 22, 2007 at 11:50:14PM +1030, Mike Lampard wrote: On Thu, 22 Nov 2007 11:31:18 pm Dan Kenigsberg wrote: On Thu, Nov 22, 2007 at 10:12:04AM +1030, Mike Lampard wrote: On Wed, 21 Nov 2007 09:36:31 pm Dan Kenigsberg wrote: These patches expose host CPU features (that are known to work under KVM) to guests. It makes a couple of benchmarks run faster, and generally gives kvm's user better info on its host. The kernel-space patch adds KVM_GET_SUPPORTED_CPUID ioctl to obtain the table of cpuid functions supported by the host. The user-space patch allows fine-tuning this table from the command-line. I had to define struct kvm_cpuid2, KVM_SET_CPUID2 etc., because cpuid functions are a little more complex than just function-value pairs. Dan. With current kvm-git (commit 51727a110220681f6f43b005d069e28c58f5d151) (userspace is current to commit 6a385c9539f9746d7ff51ef34c064c3eba86448b) and the userspace portion of this patch I cannot boot a 64 bit guest (Mandriva 2008 x64) on my AMD x2 without -cpu host. The guest kernel says Your CPU does not support long mode. Use a 32bit distribution.. Works fine without the userspace portion of the patch. Thanks for your report. I'm probably not exposing one(?) of AMD's x86_64 required cpuid features. However, I fail to reproduce this on Dual-Core AMD Opteron(tm) Processor 2210 running 2.6.18-8.1.15.el5. What is your host? 64bit 2.6.23.8 on an AMD Athlon X2 4400. cpuid flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse If you need further info, just yell. I didnt want to clutter up the mailinglist with the full output of cpuid, but will if it helps you. Since I'm currently out of ideas, would you try it with -no-kvm? Since current Qemu cvs has a -cpu userspace patch, it might be worthwhile to test that, too. Dan. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Expose host cpuid to guest
On Fri, 23 Nov 2007 12:00:00 am Avi Kivity wrote: Mike Lampard wrote: With current kvm-git (commit 51727a110220681f6f43b005d069e28c58f5d151) (userspace is current to commit 6a385c9539f9746d7ff51ef34c064c3eba86448b) and the userspace portion of this patch I cannot boot a 64 bit guest (Mandriva 2008 x64) on my AMD x2 without -cpu host. The guest kernel says Your CPU does not support long mode. Use a 32bit distribution.. Works fine without the userspace portion of the patch. erm.. sorry, seems the patch mis-applied @ my end, I just re-applied the userspace patch and the above problem is no longer, 1 down, 1 to go: With -cpu host, the 64bit kernel starts to boot then panics almost immediately: Code: 0f 30 e9 ed fc ff ff b8 66 00 00 00 f0 0f ab 45 08 e9 e2 fa RIP [8020ff99 identify_cpu+0x609/0x700 RSP 8057df58 Kernel panic - not syncing: Attempted to kill the idle task! In the host log I see: cpu0 unhandled wrmsr: 0xc0010015, which might not have anything to do with this patch of course :) A listing/disassembly of the function will help show where the problem is. yes, of course.. I'll post it as soon as I can. Thanks for the help Mike - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Compile problem with GIT repo on Scientific Linux
Thanks for reporting the problem. You do not need to make -C kernel sync with kvm-tarballs. For more information look at http://kvm.qumranet.com/kvmwiki/HOWTO -- Unpacking and configuring kvm components Uri. -Original Message- From: [EMAIL PROTECTED] on behalf of Cam Macdonell Sent: Thu 22/11/2007 00:49 To: kvm-devel Subject: [kvm-devel] Compile problem with GIT repo on Scientific Linux Hi, snipped The kvm-53 tarball works fine, but something is getting misconfigured when I run make -C kernel sync. Thanks, Cam snipped - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: fix formatting mismatch in qemu_ram_alloc
Carlo Marcelo Arenas Belon wrote: The following patch complement 50096dbe4c8523d9855b0e2ee6f058a75e7942a3 to avoid a compilation warning because of a formatting mismatch after making size long to allow for allocations bigger than 4GB and as can be seen by : kvm-53/qemu/exec.c: In function `qemu_ram_alloc': kvm-53/qemu/exec.c:2098: warning: unsigned int format, long unsigned int arg (arg 3) Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/patch 1/2: remove desc.h include in kvm_main.c
This patch removes the include of asm/desc.h in kvm_main.c, which is only available for x86 and not needed anymore. Signed-off-by: Carsten Otte [EMAIL PROTECTED] --- kvm_main.c |1 - 1 file changed, 1 deletion(-) Index: kvm/drivers/kvm/kvm_main.c === --- kvm.orig/drivers/kvm/kvm_main.c 2007-11-22 15:15:54.0 +0100 +++ kvm/drivers/kvm/kvm_main.c 2007-11-22 15:22:51.0 +0100 @@ -45,7 +45,6 @@ #include asm/processor.h #include asm/io.h #include asm/uaccess.h -#include asm/desc.h #include asm/pgtable.h MODULE_AUTHOR(Qumranet); - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/patch 2/2: remove irq.h include in kvm_main.c
This patch removes the include of irq.h in kvm_main.c, s390 does not
have irqs. For that, kvm_cpu_has_interrupt becomes an architecutre
specific function which can check for external or I/O interrupts on s390
and for irqs on x86 and others. In order to clarify wording, the
function defined by irq.h has been renamed to kvm_cpu_has_irq.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
irq.c |4 ++--
irq.h |2 +-
kvm_main.c |3 +--
svm.c |2 +-
vmx.c |2 +-
x86.c |4
x86.h |2 ++
7 files changed, 12 insertions(+), 7 deletions(-)
Index: kvm/drivers/kvm/irq.c
===
--- kvm.orig/drivers/kvm/irq.c 2007-11-22 15:24:42.0 +0100
+++ kvm/drivers/kvm/irq.c 2007-11-22 15:40:40.0 +0100
@@ -29,7 +29,7 @@
* check if there is pending interrupt without
* intack.
*/
-int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
+int kvm_cpu_has_irq(struct kvm_vcpu *v)
{
struct kvm_pic *s;
@@ -42,7 +42,7 @@
}
return 1;
}
-EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
+EXPORT_SYMBOL_GPL(kvm_cpu_has_irq);
/*
* Read pending interrupt vector and intack.
Index: kvm/drivers/kvm/irq.h
===
--- kvm.orig/drivers/kvm/irq.h 2007-11-22 15:24:42.0 +0100
+++ kvm/drivers/kvm/irq.h 2007-11-22 15:37:43.0 +0100
@@ -58,7 +58,7 @@
void kvm_pic_set_irq(void *opaque, int irq, int level);
int kvm_pic_read_irq(struct kvm_pic *s);
int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
-int kvm_cpu_has_interrupt(struct kvm_vcpu *v);
+int kvm_cpu_has_irq(struct kvm_vcpu *v);
void kvm_pic_update_irq(struct kvm_pic *s);
#define IOAPIC_NUM_PINS KVM_IOAPIC_NUM_PINS
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-11-22 15:44:49.0 +0100
@@ -17,7 +17,6 @@
#include kvm.h
#include x86.h
-#include irq.h
#include linux/kvm.h
#include linux/module.h
@@ -656,7 +655,7 @@
/*
* We will block until either an interrupt or a signal wakes us up
*/
- while (!kvm_cpu_has_interrupt(vcpu)
+ while (!kvm_arch_cpu_has_interrupt(vcpu)
!signal_pending(current)
vcpu-mp_state != VCPU_MP_STATE_RUNNABLE
vcpu-mp_state != VCPU_MP_STATE_SIPI_RECEIVED) {
Index: kvm/drivers/kvm/svm.c
===
--- kvm.orig/drivers/kvm/svm.c 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/svm.c 2007-11-22 15:38:52.0 +0100
@@ -1338,7 +1338,7 @@
if (vmcb-control.int_ctl V_IRQ_MASK)
return;
- if (!kvm_cpu_has_interrupt(vcpu))
+ if (!kvm_cpu_has_irq(vcpu))
return;
if (!(vmcb-save.rflags X86_EFLAGS_IF) ||
Index: kvm/drivers/kvm/vmx.c
===
--- kvm.orig/drivers/kvm/vmx.c 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/vmx.c 2007-11-22 15:39:44.0 +0100
@@ -2244,7 +2244,7 @@
update_tpr_threshold(vcpu);
- has_ext_irq = kvm_cpu_has_interrupt(vcpu);
+ has_ext_irq = kvm_cpu_has_irq(vcpu);
intr_info_field = vmcs_read32(VM_ENTRY_INTR_INFO_FIELD);
idtv_info_field = vmcs_read32(IDT_VECTORING_INFO_FIELD);
if (intr_info_field INTR_INFO_VALID_MASK) {
Index: kvm/drivers/kvm/x86.c
===
--- kvm.orig/drivers/kvm/x86.c 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/x86.c 2007-11-22 15:37:46.0 +0100
@@ -2917,6 +2917,10 @@
return kvm;
}
+int kvm_arch_cpu_has_interrupt(struct kvm_vcpu *v) {
+ return kvm_cpu_has_irq(v);
+}
+
static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
{
vcpu_load(vcpu);
Index: kvm/drivers/kvm/x86.h
===
--- kvm.orig/drivers/kvm/x86.h 2007-11-22 15:24:43.0 +0100
+++ kvm/drivers/kvm/x86.h 2007-11-22 15:37:47.0 +0100
@@ -315,6 +315,8 @@
int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code);
+int kvm_arch_cpu_has_interrupt(struct kvm_vcpu *v);
+
static inline void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
{
if (unlikely(vcpu-kvm-n_free_mmu_pages KVM_MIN_FREE_MMU_PAGES))
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 1/2: remove desc.h include in kvm_main.c
Carsten Otte wrote: This patch removes the include of asm/desc.h in kvm_main.c, which is only available for x86 and not needed anymore. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 2/2: remove irq.h include in kvm_main.c
Carsten Otte wrote: This patch removes the include of irq.h in kvm_main.c, s390 does not have irqs. For that, kvm_cpu_has_interrupt becomes an architecutre specific function which can check for external or I/O interrupts on s390 and for irqs on x86 and others. In order to clarify wording, the function defined by irq.h has been renamed to kvm_cpu_has_irq. I generally understand irq to mean the interrupt request line, and interrupt to mean a vectored interrupt (post interrupt controller). In those terms the naming in correct. However I'm not at all certain this naming convention is generally accepted. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 2/2: remove irq.h include in kvm_main.c
On Thu, 22 Nov 2007 18:37:13 +0200, Avi Kivity [EMAIL PROTECTED] wrote: Carsten Otte wrote: This patch removes the include of irq.h in kvm_main.c, s390 does not have irqs. For that, kvm_cpu_has_interrupt becomes an architecutre specific function which can check for external or I/O interrupts on s390 and for irqs on x86 and others. In order to clarify wording, the function defined by irq.h has been renamed to kvm_cpu_has_irq. I generally understand irq to mean the interrupt request line, and interrupt to mean a vectored interrupt (post interrupt controller). In those terms the naming in correct. However I'm not at all certain this naming convention is generally accepted. Well, at least IO-Interrupts on s390 don't really fit this model from my point of view. (In fact, we can even get IO-Interrupts that are not associated with any (channel) device at all). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 2/2: remove irq.h include in kvm_main.c
Cornelia Huck wrote: Carsten Otte wrote: This patch removes the include of irq.h in kvm_main.c, s390 does not have irqs. For that, kvm_cpu_has_interrupt becomes an architecutre specific function which can check for external or I/O interrupts on s390 and for irqs on x86 and others. In order to clarify wording, the function defined by irq.h has been renamed to kvm_cpu_has_irq. I generally understand irq to mean the interrupt request line, and interrupt to mean a vectored interrupt (post interrupt controller). In those terms the naming in correct. However I'm not at all certain this naming convention is generally accepted. Well, at least IO-Interrupts on s390 don't really fit this model from my point of view. (In fact, we can even get IO-Interrupts that are not associated with any (channel) device at all). Oh, I agree about the removal, just wondering about the name change. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 2/2: remove irq.h include in kvm_main.c
Avi Kivity wrote: I generally understand irq to mean the interrupt request line, and interrupt to mean a vectored interrupt (post interrupt controller). In those terms the naming in correct. However I'm not at all certain this naming convention is generally accepted. I think on s390 we'll have kvm_s390_vcpu_has_extint() kvm_s390_vcpu_has_ioint() and maybe kvm_s390_vcpu_has_machine_check() and kvm_arch_vcpu_has_interrupt() will check if any of above is pending. It would be great if the function names would clearly identify that one is the general portable cpu needs to run an interrupt handler of whatever sort and the other one is we have a vectored interrupt to deliver on x86 as well. If you'd like to keep the wording as is, I'll send a patch that just adds the kvm_arch_cpu_has_interrupt wrapper. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 2/2: remove irq.h include in kvm_main.c
Avi Kivity wrote: Cornelia Huck wrote: Carsten Otte wrote: This patch removes the include of irq.h in kvm_main.c, s390 does not have irqs. For that, kvm_cpu_has_interrupt becomes an architecutre specific function which can check for external or I/O interrupts on s390 and for irqs on x86 and others. In order to clarify wording, the function defined by irq.h has been renamed to kvm_cpu_has_irq. I generally understand irq to mean the interrupt request line, and interrupt to mean a vectored interrupt (post interrupt controller). In those terms the naming in correct. However I'm not at all certain this naming convention is generally accepted. Well, at least IO-Interrupts on s390 don't really fit this model from my point of view. (In fact, we can even get IO-Interrupts that are not associated with any (channel) device at all). Oh, I agree about the removal, just wondering about the name change. Sorry, I misunderstood what you were saying. Anyway I'm not at all sure that the way I understand the names irq and interrupt is correct. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 2/2: remove irq.h include in kvm_main.c
Carsten Otte wrote: Avi Kivity wrote: I generally understand irq to mean the interrupt request line, and interrupt to mean a vectored interrupt (post interrupt controller). In those terms the naming in correct. However I'm not at all certain this naming convention is generally accepted. I think on s390 we'll have kvm_s390_vcpu_has_extint() kvm_s390_vcpu_has_ioint() and maybe kvm_s390_vcpu_has_machine_check() and kvm_arch_vcpu_has_interrupt() will check if any of above is pending. It would be great if the function names would clearly identify that one is the general portable cpu needs to run an interrupt handler of whatever sort and the other one is we have a vectored interrupt to deliver on x86 as well. If you'd like to keep the wording as is, I'll send a patch that just adds the kvm_arch_cpu_has_interrupt wrapper. What I'd like is to find out what the generally accepted terminology is, and conform to that. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 2/2: remove irq.h include in kvm_main.c
On Thu, 22 Nov 2007 17:42:30 +0100, Cornelia Huck [EMAIL PROTECTED] wrote: Argh, please ignore. Was deep in something else and became confused. Sorry about the noise. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Compile problem with GIT repo on Scientific Linux
Uri Lublin wrote: Thanks for reporting the problem. Thanks for the quick patch :) You do not need to make -C kernel sync with kvm-tarballs. Yes, sorry, my language was unclear in that sentence. I wasn't running sync on the tarball, just on the git repo. Thanks, Cam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 1/2: remove desc.h include in kvm_main.c
Carsten Otte wrote: This patch removes the include of asm/desc.h in kvm_main.c, which is only available for x86 and not needed anymore. Signed-off-by: Carsten Otte [EMAIL PROTECTED] --- kvm_main.c |1 - 1 file changed, 1 deletion(-) Index: kvm/drivers/kvm/kvm_main.c === --- kvm.orig/drivers/kvm/kvm_main.c 2007-11-22 15:15:54.0 +0100 +++ kvm/drivers/kvm/kvm_main.c 2007-11-22 15:22:51.0 +0100 @@ -45,7 +45,6 @@ #include asm/processor.h #include asm/io.h #include asm/uaccess.h -#include asm/desc.h #include asm/pgtable.h MODULE_AUTHOR(Qumranet); Acked-by Zhang Xiantao [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Change arch_clean target of config-x86-common.mak file to remove .*.d and *.o files in x86/lib directory.
From 3671928c13f974a9e1f551a9829b49511499d1a5 Mon Sep 17 00:00:00 2001 From: Neo Jia [EMAIL PROTECTED] Date: Thu, 22 Nov 2007 23:03:17 -0800 Subject: [PATCH] Change arch_clean target of config-x86-common.mak file to remove .*.d and *.o files in x86/lib directory. Signed-off-by: Neo Jia [EMAIL PROTECTED] --- user/config-x86-common.mak |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/user/config-x86-common.mak b/user/config-x86-common.mak index 6d5c795..94058e4 100644 --- a/user/config-x86-common.mak +++ b/user/config-x86-common.mak @@ -38,4 +38,4 @@ $(TEST_DIR)/libcflat.a: $(TEST_DIR)/lib/exit.o arch_clean: $(RM) $(TEST_DIR)/bootstrap $(TEST_DIR)/*.o $(TEST_DIR)/*.flat \ - $(TEST_DIR)/.*.d + $(TEST_DIR)/.*.d $(TEST_DIR)/lib/.*.d $(TEST_DIR)/lib/*.o -- 1.5.3.6 -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From 3671928c13f974a9e1f551a9829b49511499d1a5 Mon Sep 17 00:00:00 2001 From: Neo Jia [EMAIL PROTECTED] Date: Thu, 22 Nov 2007 23:03:17 -0800 Subject: [PATCH] Change arch_clean target of config-x86-common.mak file to remove .*.d and *.o files in x86/lib directory. Signed-off-by: Neo Jia [EMAIL PROTECTED] --- user/config-x86-common.mak |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/user/config-x86-common.mak b/user/config-x86-common.mak index 6d5c795..94058e4 100644 --- a/user/config-x86-common.mak +++ b/user/config-x86-common.mak @@ -38,4 +38,4 @@ $(TEST_DIR)/libcflat.a: $(TEST_DIR)/lib/exit.o arch_clean: $(RM) $(TEST_DIR)/bootstrap $(TEST_DIR)/*.o $(TEST_DIR)/*.flat \ - $(TEST_DIR)/.*.d + $(TEST_DIR)/.*.d $(TEST_DIR)/lib/.*.d $(TEST_DIR)/lib/*.o -- 1.5.3.6 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
