[PATCH] Merge branch 'qemu-cvs'
From: Avi Kivity a...@redhat.com Conflicts: qemu/Makefile.target qemu/hw/cirrus_vga.c qemu/hw/ide.c qemu/pc-bios/bios.bin qemu/vl.c Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: external module: compatibility for hrtimer_expires_remaining()
From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/kernel/external-module-compat-comm.h
b/kernel/external-module-compat-comm.h
index 5cb70b0..981dc96 100644
--- a/kernel/external-module-compat-comm.h
+++ b/kernel/external-module-compat-comm.h
@@ -613,6 +613,20 @@ static inline void kvm_hrtimer_start_expires(struct
hrtimer *timer, int mode)
#endif
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,27)
+
+static inline ktime_t kvm_hrtimer_expires_remaining(const struct hrtimer
*timer)
+{
+return ktime_sub(timer-expires, timer-base-get_time());
+}
+
+#else
+
+#define kvm_hrtimer_expires_remaining hrtimer_expires_remaining
+
+#endif
+
+
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,28)
static inline int pci_reset_function(struct pci_dev *dev)
diff --git a/kernel/ia64/hack-module.awk b/kernel/ia64/hack-module.awk
index a26d567..d0ef130 100644
--- a/kernel/ia64/hack-module.awk
+++ b/kernel/ia64/hack-module.awk
@@ -1,6 +1,7 @@
BEGIN { split(INIT_WORK on_each_cpu smp_call_function \
hrtimer_add_expires_ns hrtimer_get_expires \
hrtimer_get_expires_ns hrtimer_start_expires \
+ hrtimer_expires_remaining \
request_irq, compat_apis); }
/MODULE_AUTHOR/ {
diff --git a/kernel/x86/hack-module.awk b/kernel/x86/hack-module.awk
index 1840c47..cc50856 100644
--- a/kernel/x86/hack-module.awk
+++ b/kernel/x86/hack-module.awk
@@ -1,6 +1,7 @@
BEGIN { split(INIT_WORK tsc_khz desc_struct ldttss_desc64 desc_ptr \
hrtimer_add_expires_ns hrtimer_get_expires \
hrtimer_get_expires_ns hrtimer_start_expires \
+ hrtimer_expires_remaining \
on_each_cpu relay_open request_irq , compat_apis); }
/^int kvm_init\(/ { anon_inodes = 1 }
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: external module: Fix build for VT-d/AMD IOMMU
From: Sheng Yang sh...@linux.intel.com The vtd.c has renamed to iommu.c, and config option has changed to CONFIG_IOMMU_API. Notice now the host kernel before 2.6.29 can't work with VT-d due to API changed... At least this patch enabled building with host kernel before 2.6.29 with CONFIG_DMAR. Signed-off-by: Wei Huang wei.w.hu...@intel.com Signed-off-by: Sheng Yang sh...@linux.intel.com Signed-off-by: Avi Kivity a...@redhat.com diff --git a/kernel/ia64/Kbuild b/kernel/ia64/Kbuild index 130ec45..5bc6098 100644 --- a/kernel/ia64/Kbuild +++ b/kernel/ia64/Kbuild @@ -3,8 +3,8 @@ obj-m := kvm.o kvm-intel.o kvm-objs := kvm_main.o ioapic.o coalesced_mmio.o kvm-ia64.o kvm_fw.o \ irq_comm.o ../anon_inodes.o ../external-module-compat.o -ifeq ($(CONFIG_DMAR),y) -kvm-objs += vtd.o +ifeq ($(CONFIG_IOMMU_API),y) +kvm-objs += iommu.o endif EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127 diff --git a/kernel/x86/Kbuild b/kernel/x86/Kbuild index c4723b1..4ef1168 100644 --- a/kernel/x86/Kbuild +++ b/kernel/x86/Kbuild @@ -9,8 +9,8 @@ kvm-objs := kvm_main.o x86.o mmu.o x86_emulate.o ../anon_inodes.o irq.o i8259.o ifeq ($(EXT_CONFIG_KVM_TRACE),y) kvm-objs += kvm_trace.o endif -ifeq ($(CONFIG_DMAR),y) -kvm-objs += vtd.o +ifeq ($(CONFIG_IOMMU_API),y) +kvm-objs += iommu.o endif kvm-intel-objs := vmx.o vmx-debug.o ../external-module-compat.o kvm-amd-objs := svm.o ../external-module-compat.o -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2528121 ] Connecting a guest PC to a vlan cisco switch
Bugs item #2528121, was opened at 2009-01-22 10:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2528121group_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: Interface (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Diego Celso (dcelso) Assigned to: Nobody/Anonymous (nobody) Summary: Connecting a guest PC to a vlan cisco switch Initial Comment: In my case I have Debian in host and guest. The switch have two vlan networks. in total there are three nets (192.168.1.0,192.168.4.0,192.168.101.0) I am using a tap interface for share the real interface. The network configuration is hostPC *** auto br0 iface br0 inet static address 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255 network 192.168.1.0 gateway 192.168.1.1 bridge_ports eth0 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off *** guestPC *** auto eth0 iface eth0 inet static address 192.168.1.11 netmask 255.255.255.0 broadcast 192.168.1.255 network 192.168.1.0 gateway 192.168.1.1 auto eth0.4 iface eth0 inet static address 192.168.4.11 netmask 255.255.255.0 broadcast 192.4.1.255 network 192.168.4.0 gateway 192.168.4.1 auto eth0.101 iface eth0 inet static address 192.168.101.11 netmask 255.255.255.0 broadcast 192.168.101.255 network 192.168.101.0 gateway 192.168.101.1 The running kvm have the parametters -net nic -net tap,ifname=tap0 The result is that the guestPC can not connet to the two vlan networks. It only can do ping to the PC connected to the network 192.168.1.0. Trying the same configuration in VirtualBox it goes very well. I think that the method that kvm use for share the interface is not a completely real share. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2528121group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] kvm-s390: three kernel fixes
Hello Avi, here are small fixes for KVM on s390: 1. Fix printk on SIGP set arch 2. Fix problem state check for b2 intercepts 3. Fix SIGP set prefix ioctl I dont think any of the fixes is critical, but patch 1 allows a malicious guest to flood the host dmesg. Therefore, I want to push patch 1 for 2.6.29 and patches 2 + 3 for the next merge window. Christian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] kvm-s390: Fix problem state check for b2 intercepts
From: Christian Borntraeger borntrae...@de.ibm.com
The kernel handles some priviledged instruction exits. While I was
unable to trigger such an exit from guest userspace, the code should
check for supervisor state before emulating a priviledged instruction.
I also renamed kvm_s390_handle_priv to kvm_s390_handle_b2. After all
there are non priviledged b2 instructions like stck (store clock).
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/kvm/intercept.c |2 +-
arch/s390/kvm/kvm-s390.h |2 +-
arch/s390/kvm/priv.c | 18 +++---
3 files changed, 17 insertions(+), 5 deletions(-)
Index: kvm/arch/s390/kvm/intercept.c
===
--- kvm.orig/arch/s390/kvm/intercept.c
+++ kvm/arch/s390/kvm/intercept.c
@@ -103,7 +103,7 @@ static int handle_lctl(struct kvm_vcpu *
static intercept_handler_t instruction_handlers[256] = {
[0x83] = kvm_s390_handle_diag,
[0xae] = kvm_s390_handle_sigp,
- [0xb2] = kvm_s390_handle_priv,
+ [0xb2] = kvm_s390_handle_b2,
[0xb7] = handle_lctl,
[0xeb] = handle_lctlg,
};
Index: kvm/arch/s390/kvm/kvm-s390.h
===
--- kvm.orig/arch/s390/kvm/kvm-s390.h
+++ kvm/arch/s390/kvm/kvm-s390.h
@@ -50,7 +50,7 @@ int kvm_s390_inject_vcpu(struct kvm_vcpu
int kvm_s390_inject_program_int(struct kvm_vcpu *vcpu, u16 code);
/* implemented in priv.c */
-int kvm_s390_handle_priv(struct kvm_vcpu *vcpu);
+int kvm_s390_handle_b2(struct kvm_vcpu *vcpu);
/* implemented in sigp.c */
int kvm_s390_handle_sigp(struct kvm_vcpu *vcpu);
Index: kvm/arch/s390/kvm/priv.c
===
--- kvm.orig/arch/s390/kvm/priv.c
+++ kvm/arch/s390/kvm/priv.c
@@ -304,12 +304,24 @@ static intercept_handler_t priv_handlers
[0xb1] = handle_stfl,
};
-int kvm_s390_handle_priv(struct kvm_vcpu *vcpu)
+int kvm_s390_handle_b2(struct kvm_vcpu *vcpu)
{
intercept_handler_t handler;
+ /*
+* a lot of B2 instructions are priviledged. We first check for
+* the priviledges ones, that we can handle in the kernel. If the
+* kernel can handle this instruction, we check for the problem
+* state bit and (a) handle the instruction or (b) send a code 2
+* program check.
+* Anything else goes to userspace.*/
handler = priv_handlers[vcpu-arch.sie_block-ipa 0x00ff];
- if (handler)
- return handler(vcpu);
+ if (handler) {
+ if (vcpu-arch.sie_block-gpsw.mask PSW_MASK_PSTATE)
+ return kvm_s390_inject_program_int(vcpu,
+ PGM_PRIVILEGED_OPERATION);
+ else
+ return handler(vcpu);
+ }
return -ENOTSUPP;
}
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] kvm-s390: Fix SIGP set prefix ioctl
From: Christian Borntraeger borntrae...@de.ibm.com This patch fixes the SET PREFIX interrupt if triggered by userspace. Until now, it was not necessary, but life migration will need it. In addition, it helped me creating SMP support for my kvm_crashme tool (lets kvm execute random guest memory content). Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com --- arch/s390/kvm/interrupt.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) Index: kvm/arch/s390/kvm/interrupt.c === --- kvm.orig/arch/s390/kvm/interrupt.c +++ kvm/arch/s390/kvm/interrupt.c @@ -555,9 +555,14 @@ int kvm_s390_inject_vcpu(struct kvm_vcpu VCPU_EVENT(vcpu, 3, inject: program check %d (from user), s390int-parm); break; + case KVM_S390_SIGP_SET_PREFIX: + inti-prefix.address = s390int-parm; + inti-type = s390int-type; + VCPU_EVENT(vcpu, 3, inject: set prefix to %x (from user), + s390int-parm); + break; case KVM_S390_SIGP_STOP: case KVM_S390_RESTART: - case KVM_S390_SIGP_SET_PREFIX: case KVM_S390_INT_EMERGENCY: VCPU_EVENT(vcpu, 3, inject: type %x, s390int-type); inti-type = s390int-type; -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] kvm-s390: Fix printk on SIGP set arch
From: Christian Borntraeger borntrae...@de.ibm.com
KVM on s390 does not support the ESA/390 architecture. We refuse to
change the architecture mode and print a warning. While testing a
crashme for kvm, I spotted two problems with the printk:
o A malicious can flood host dmesg
o There was no newline at the end of the printk
This patch fixes both problems.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/kvm/sigp.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: kvm/arch/s390/kvm/sigp.c
===
--- kvm.orig/arch/s390/kvm/sigp.c
+++ kvm/arch/s390/kvm/sigp.c
@@ -153,8 +153,9 @@ static int __sigp_set_arch(struct kvm_vc
switch (parameter 0xff) {
case 0:
- printk(KERN_WARNING kvm: request to switch to ESA/390 mode
-not supported);
+ if (printk_ratelimit())
+ printk(KERN_WARNING kvm: request to switch to ESA/390
+mode not supported\n);
rc = 3; /* not operational */
break;
case 1:
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm-s390: Fix printk on SIGP set arch
On Thu, 22 Jan 2009 10:27:38 +0100 Christian Borntraeger borntrae...@de.ibm.com wrote: KVM on s390 does not support the ESA/390 architecture. We refuse to change the architecture mode and print a warning. While testing a crashme for kvm, I spotted two problems with the printk: o A malicious can flood host dmesg o There was no newline at the end of the printk This patch fixes both problems. [...] - printk(KERN_WARNING kvm: request to switch to ESA/390 mode - not supported); + if (printk_ratelimit()) + printk(KERN_WARNING kvm: request to switch to ESA/390 + mode not supported\n); Why don't you just remove the printk? IMHO it's rather pointless. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm-s390: Fix printk on SIGP set arch
Am Thu, 22 Jan 2009 12:17:07 +0100 schrieb heica...@linux.vnet.ibm.com: Why don't you just remove the printk? IMHO it's rather pointless. It is'nt: It infoms the user why his guest is going to crash even though it has performed an operation that is perfectly legal according to the spec. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm-s390: Fix printk on SIGP set arch
On (Thu) Jan 22 2009 [10:27:38], Christian Borntraeger wrote:
From: Christian Borntraeger borntrae...@de.ibm.com
KVM on s390 does not support the ESA/390 architecture. We refuse to
change the architecture mode and print a warning. While testing a
crashme for kvm, I spotted two problems with the printk:
o A malicious can flood host dmesg
o There was no newline at the end of the printk
This patch fixes both problems.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/kvm/sigp.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: kvm/arch/s390/kvm/sigp.c
===
--- kvm.orig/arch/s390/kvm/sigp.c
+++ kvm/arch/s390/kvm/sigp.c
@@ -153,8 +153,9 @@ static int __sigp_set_arch(struct kvm_vc
switch (parameter 0xff) {
case 0:
- printk(KERN_WARNING kvm: request to switch to ESA/390 mode
- not supported);
+ if (printk_ratelimit())
+ printk(KERN_WARNING kvm: request to switch to ESA/390
+ mode not supported\n);
Breaking printk lines isn't encouraged just to keep the column width at
80. It makes grepping the sources for the source of the message
difficult to find.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm-s390: Fix printk on SIGP set arch
On Thu, 22 Jan 2009 12:26:11 +0100 Carsten Otte co...@de.ibm.com wrote: Am Thu, 22 Jan 2009 12:17:07 +0100 schrieb heica...@linux.vnet.ibm.com: Why don't you just remove the printk? IMHO it's rather pointless. It is'nt: It infoms the user why his guest is going to crash even though it has performed an operation that is perfectly legal according to the spec. If you have hundreds of guests running, how do you get the connection from this message to a specific user process? Informing a user process that it did something that isn't allowed or supported is usually done by returning an appropriate return code. Also, if you have one evil process and hit the prink_limit the messages for all other processes will likely be lost anyway. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm-s390: Fix printk on SIGP set arch
Heiko Carstens wrote: On Thu, 22 Jan 2009 12:26:11 +0100 Carsten Otte co...@de.ibm.com wrote: Am Thu, 22 Jan 2009 12:17:07 +0100 schrieb heica...@linux.vnet.ibm.com: Why don't you just remove the printk? IMHO it's rather pointless. It is'nt: It infoms the user why his guest is going to crash even though it has performed an operation that is perfectly legal according to the spec. If you have hundreds of guests running, how do you get the connection from this message to a specific user process? Informing a user process that it did something that isn't allowed or supported is usually done by returning an appropriate return code. Right, either inject an exception to the guest (if appropriate for the arch), or return -ESOMETHING from ioctl(KVM_RUN). -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] kvm: Fix build for VT-d/AMD IOMMU
Sheng Yang wrote: The vtd.c has renamed to iommu.c, and config option has changed to CONFIG_IOMMU_API. Notice now the host kernel before 2.6.29 can't work with VT-d due to API changed... At least this patch enabled building with host kernel before 2.6.29 with CONFIG_DMAR. Applied, thanks. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm:virtio-net: Run TX from the I/O thread
Alex Williamson wrote: This is an attempt to improve the latency of virtio-net while not hurting throughput. I wanted to try moving packet TX into a different thread so we can quickly return to the guest after it kicks us to send packets out. I also switched the order of when the tx_timer comes into play, so we can get an inital burst of packets out, then wait for the timer to fire and notify us if there's more to do. Here's what it does for me (average of 5 runs each, testing to a remote system on a 1Gb network): netperf TCP_STREAM: 939.22Mb/s - 935.24Mb/s = 99.58% netperf TCP_RR: 2028.72/s - 3927.99/s = 193.62% tbench: 92.99MB/s - 99.97MB/s = 107.51% I'd be interested to hear if it helps or hurts anyone else. Thanks, My worry with this change is that increases cpu utilization even more than it increases bandwidth, so that our bits/cycle measure decreases. The descriptors (and perhaps data) are likely on the same cache as the vcpu, and moving the transmit to the iothread will cause them to move to the iothread's cache. My preferred approach to increasing both bandwidth and bits/cycle (the latter figure is more important IMO, unfortunately benchmarks don't measure it) is to aio-enable tap and raw sockets. The vcpu thread would only touch the packet descriptors (not data) and submit all packets in one io_submit() call. Unfortunately a huge amount of work is needed to pull this off. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] kvm-s390: Fix printk on SIGP set arch
Am Thu, 22 Jan 2009 13:58:57 +0200 schrieb Avi Kivity a...@redhat.com: Right, either inject an exception to the guest (if appropriate for the arch), or return -ESOMETHING from ioctl(KVM_RUN). Yea that's what we do. We let userland handle the intercept, and there we let the guest die gracefully with a message. so long, Carsten -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm:virtio-net: Run TX from the I/O thread
On Thu, 2009-01-22 at 14:12 +0200, Avi Kivity wrote: My worry with this change is that increases cpu utilization even more than it increases bandwidth, so that our bits/cycle measure decreases. Yep, agreed it's important to watch out for this. The descriptors (and perhaps data) are likely on the same cache as the vcpu, and moving the transmit to the iothread will cause them to move to the iothread's cache. We flush from the I/O thread right now. We only ever flush from the vcpu thread when the ring fills up, which rarely happens from what I've observed. Cheers, Mark. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix almost infinite loop in APIC
Marcelo Tosatti wrote: On Wed, Jan 21, 2009 at 01:11:23PM +0800, Sheng Yang wrote: Use ktime_to_ns() macro is better. The remaining parts are fine with me. But please do more test. :) Thanks for work! Alexander, can you please confirm this works for you, thanks. KVM: x86: fix LAPIC pending count calculation Simplify LAPIC TMCCT calculation by using hrtimer provided function to query remaining time until expiration. Fixes host hang with nested ESX. Applied, thanks. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3 v2] kvm-s390: Fix printk on SIGP set arch
Am Thursday 22 January 2009 12:58:57 schrieb Avi Kivity:
Right, either inject an exception to the guest (if appropriate for the
arch), or return -ESOMETHING from ioctl(KVM_RUN).
Ok. What about:
[PATCH] kvm-s390: fix printk on SIGP set arch
From: Christian Borntraeger borntrae...@de.ibm.com
Reported-by: Heiko Carstens heiko.carst...@de.ibm.com
KVM on s390 does not support the ESA/390 architecture. We refuse to
change the architecture mode and print a warning. This patch removes
the printk for several reasons:
o A malicious can flood host dmesg
o The old message had no newline
o there is no connection between the message and the failing guest
This patch simply removes the printk. We already set the condition
code to 3 - the guest knows that something went wrong.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
arch/s390/kvm/sigp.c |2 --
1 file changed, 2 deletions(-)
Index: kvm/arch/s390/kvm/sigp.c
===
--- kvm.orig/arch/s390/kvm/sigp.c
+++ kvm/arch/s390/kvm/sigp.c
@@ -153,8 +153,6 @@ static int __sigp_set_arch(struct kvm_vc
switch (parameter 0xff) {
case 0:
- printk(KERN_WARNING kvm: request to switch to ESA/390 mode
-not supported);
rc = 3; /* not operational */
break;
case 1:
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
kvm and cpu type
Hello Iam using kvm83 on CentOS5.2 my system has 2x dual Core intel CPU Intel(R) Xeon(R) CPU5110 @ 1.60GHz asdetected by Centos. If I start kvm-qemu with no CPU option everythign works and hte guest machine detects cpu as QEMU Virtual CPU version 0.9.1 iv I run qemu-kvm -cpu core2duo the guest hangs at boot time when it detects the CPU. I do not know how to fix it. I also do not know if using -cpu swtch can improve performances. thank you Rick -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm:virtio-net: Run TX from the I/O thread
Mark McLoughlin wrote: Hi Alex, On Wed, 2009-01-21 at 16:08 -0700, Alex Williamson wrote: This is an attempt to improve the latency of virtio-net while not hurting throughput. I wanted to try moving packet TX into a different thread so we can quickly return to the guest after it kicks us to send packets out. I also switched the order of when the tx_timer comes into play, so we can get an inital burst of packets out, then wait for the timer to fire and notify us if there's more to do. Here's what it does for me (average of 5 runs each, testing to a remote system on a 1Gb network): netperf TCP_STREAM: 939.22Mb/s - 935.24Mb/s = 99.58% netperf TCP_RR: 2028.72/s - 3927.99/s = 193.62% tbench: 92.99MB/s - 99.97MB/s = 107.51% I'd be interested to hear if it helps or hurts anyone else. Thanks, Avi and I went back and forth on this one in great detail before: http://www.mail-archive.com/kvm@vger.kernel.org/msg06431.html Avi's arguments make a lot of sense, but looking over those patches again now, I still think that applying them would be a better approach than what we have right now. I can go with that. Anthony, should I wait for a qemu iothread so it can go upstream directly? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm:virtio-net: Run TX from the I/O thread
(copying Anthony this time) Mark McLoughlin wrote: Hi Alex, On Wed, 2009-01-21 at 16:08 -0700, Alex Williamson wrote: This is an attempt to improve the latency of virtio-net while not hurting throughput. I wanted to try moving packet TX into a different thread so we can quickly return to the guest after it kicks us to send packets out. I also switched the order of when the tx_timer comes into play, so we can get an inital burst of packets out, then wait for the timer to fire and notify us if there's more to do. Here's what it does for me (average of 5 runs each, testing to a remote system on a 1Gb network): netperf TCP_STREAM: 939.22Mb/s - 935.24Mb/s = 99.58% netperf TCP_RR: 2028.72/s - 3927.99/s = 193.62% tbench: 92.99MB/s - 99.97MB/s = 107.51% I'd be interested to hear if it helps or hurts anyone else. Thanks, Avi and I went back and forth on this one in great detail before: http://www.mail-archive.com/kvm@vger.kernel.org/msg06431.html Avi's arguments make a lot of sense, but looking over those patches again now, I still think that applying them would be a better approach than what we have right now. I can go with that. Anthony, should I wait for a qemu iothread so it can go upstream directly? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2528121 ] Connecting a guest PC to a vlan cisco switch
Bugs item #2528121, was opened at 2009-01-22 11:02 Message generated for change (Comment added) made by thekozmo You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2528121group_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: Interface (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Diego Celso (dcelso) Assigned to: Nobody/Anonymous (nobody) Summary: Connecting a guest PC to a vlan cisco switch Initial Comment: In my case I have Debian in host and guest. The switch have two vlan networks. in total there are three nets (192.168.1.0,192.168.4.0,192.168.101.0) I am using a tap interface for share the real interface. The network configuration is hostPC *** auto br0 iface br0 inet static address 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255 network 192.168.1.0 gateway 192.168.1.1 bridge_ports eth0 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off *** guestPC *** auto eth0 iface eth0 inet static address 192.168.1.11 netmask 255.255.255.0 broadcast 192.168.1.255 network 192.168.1.0 gateway 192.168.1.1 auto eth0.4 iface eth0 inet static address 192.168.4.11 netmask 255.255.255.0 broadcast 192.4.1.255 network 192.168.4.0 gateway 192.168.4.1 auto eth0.101 iface eth0 inet static address 192.168.101.11 netmask 255.255.255.0 broadcast 192.168.101.255 network 192.168.101.0 gateway 192.168.101.1 The running kvm have the parametters -net nic -net tap,ifname=tap0 The result is that the guestPC can not connet to the two vlan networks. It only can do ping to the PC connected to the network 192.168.1.0. Trying the same configuration in VirtualBox it goes very well. I think that the method that kvm use for share the interface is not a completely real share. -- Comment By: Dor Laor (thekozmo) Date: 2009-01-22 16:20 Message: Where is your destination machine/interface? Note that if the guest nic is a vlan, the packet should come out tagged. A vlan interface needs to receive it on the host or on remote host. You can tcpdump the bridge to make sure the packets are tagged. Also make sure the mtu is 1518 (+4 for vlan tag) It was tested in the past without any issues. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2528121group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM
Jamie Kirkpatrick wrote: All This is my first post to the list but this seems to be the only place I can get this problem to be looked at by hopefully the correct people: I've bounced it around in #kvm on freenode and we've all agreed its a development issue / bug that needs looking at. Anyway, without further ado: my machine is a Core 2 Due Quad Core based box running Debian Lenny and a 2.6.27 kernel as the host OS. I am using KVM-82 right now and track all current releases of the KVM code. The issue I have run into seems to be very specific to the hardware setup I have and the fact that I'm running this version of Windows under virtualization. I have been trying for some time to get Git to work under this OS and for one reason or another I was trying the cygwin based install. Problems started appearing as soon as I install cygwin, and during the installation process even: various post-install config scripts crash and I get the usual windows JIT debugger window popping up etc. Upon further investigation I have tracked the problem down to a problem with Cygwin bash's builtin test implementation ( the [] syntax in shell scripting ). I can cause the crash by simply invoking this syntax from a command line. This problem has been noted before and has been posted about elsewhere: first on the cygwin list, and then after on the Xen list. Everyone seems to agree that based on more extensive testing from other people that this is being caused by something in the virtualzation stack. Two messages of note are: http://sourceware.org/ml/cygwin/2008-01/msg00582.html http://www.nabble.com/Xen-3.2.1---Win-2003-2008-Server-64-bit-guests:-cygwin-bash-builtin-%22test%22-crashes-td19001336.html I've spent a long time trying to track this down: I've tried various versions of KVM and have tried playing around with windows lots as well. No luck. I'm lost on this but it seems to me that this just should not happen and if there is a bug in the way Xen and KVM treat things then it needs fixing...hence the post. If someone wants to try and squash / identify this bug further I'm availible as a tester: I am a c++ developer by day but I don't know the KVM code or how you go about debugging it. If someone can prime me in that direction perhaps I could look at it as well. Anyway, anything I can do to help and I will. I tried to track this down. Apparently the guest clobbers gs during the exit routine. Since it happens in the guest, it's a little difficult to track down. It can be done using the guest debugger, in this way: - start bash in the debugger - stop the program - add a watchpoint to break when the value of gs:[0x30] changes - single-step the program until the watchpoint triggers However, my Windows debugging skills are pretty much nonexistent. Can you guide me through this? I'm using windbg. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM-82 failed to compile
Simon Gao wrote: Nikola Ciprich wrote: Hi, enable KVM support on kernel against which You're compiling.. n. That did it. So from 2.6.27 and on, we need to enable KVM module in kernel no matter we want to use a separate outside module or not. This is a little strange. While we could work around this, it actually buys you important functionality (full swapping) so I'd rather keep it this way. Distros will enable kvm, so most users won't notice this at all. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kvm-83
Hello everyone, I'm using kvm-83 on vanilla kernel 2.6.27.8 but I have some problems, since guest freezes at boot time (at very early stage since it does not print any message on the attached vnc) and /var/log/messages sports the following error message: kvm: 4982: cpu0 unhandled wrmsr: 0xc0010117 data 0 The virtual machine is started as follows: /usr/local/bin/qemu-system-x86_64 -M pc -m 1024 -boot c -hda /var/lib/libvirt/images/v10f.img -vnc :1 () the same guest boots ok when using standard Fedora 10 kernel kvm, i.e. 2.6.27.9-159.fc10 kvm-74 can I contribute to solve this issue? thanks in advance, GM More details regarding my hardware and software environment host: Fedora 10 guest: Fedora 10 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz stepping: 6 cpu MHz : 2101.000 cache size : 3072 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes 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 nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm ida bogomips: 3657.40 clflush size: 64 power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz stepping: 6 cpu MHz : 2101.000 cache size : 3072 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes 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 nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm ida bogomips: 4189.27 clflush size: 64 power management: -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm and cpu type
On (Thu) Jan 22 2009 [14:16:15], Riccardo Veraldi wrote: Hello Iam using kvm83 on CentOS5.2 my system has 2x dual Core intel CPU Intel(R) Xeon(R) CPU5110 @ 1.60GHz asdetected by Centos. If I start kvm-qemu with no CPU option everythign works and hte guest machine detects cpu as QEMU Virtual CPU version 0.9.1 iv I run qemu-kvm -cpu core2duo the guest hangs at boot time when it detects the CPU. I do not know how to fix it. This is a known problem and has been fixed for the upcoming kvm-84 release. I also do not know if using -cpu swtch can improve performances. It shouldn't matter much. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm:virtio-net: Run TX from the I/O thread
On Thu, 2009-01-22 at 12:48 +, Mark McLoughlin wrote: On Thu, 2009-01-22 at 14:12 +0200, Avi Kivity wrote: My worry with this change is that increases cpu utilization even more than it increases bandwidth, so that our bits/cycle measure decreases. Yep, agreed it's important to watch out for this. The descriptors (and perhaps data) are likely on the same cache as the vcpu, and moving the transmit to the iothread will cause them to move to the iothread's cache. We flush from the I/O thread right now. We only ever flush from the vcpu thread when the ring fills up, which rarely happens from what I've observed. Sorry to have come in late to the discussion, but it seems like maybe it needed another kick after a couple months anyway. As noted, we are mostly (almost exclusively?) doing TX from the timer anyway, so this change or Mark's previous patch series don't really change current cache effects. I am curious what happens to latency with Mark's series since that isn't really addressed by the charts, hopefully good things without the tx_timer. A thread per device or perhaps even a thread per RX/TX stream seems like a logical goal, but these current patches do provide a worthwhile incremental improvement. Perhaps we could affinitize the guest to do I/O on a specific vcpu via _PXM methods in ACPI so we can provide hints to the scheduler to keep a vcpu thread and it's associated I/O threads nearby. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm:virtio-net: Run TX from the I/O thread
Avi Kivity wrote: Mark McLoughlin wrote: Avi and I went back and forth on this one in great detail before: http://www.mail-archive.com/kvm@vger.kernel.org/msg06431.html Avi's arguments make a lot of sense, but looking over those patches again now, I still think that applying them would be a better approach than what we have right now. I can go with that. Anthony, should I wait for a qemu iothread so it can go upstream directly? Uh, go ahead and apply it now. The io thread should come soon but I don't think it's going to be easier to wait and merge this later than dealing with the conflict after you resync against QEMU post IO thread. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] External module compatibility for hrtimer_expires_remaining
Due to Marcelo's APIC fix we now depend on hrtimer_expires_remaining,
which is not available on my 2.6.27 kernel.
This patch adds a backwards compatibility layer for it.
Signed-off-by: Alexander Graf ag...@suse.de
---
kernel/external-module-compat-comm.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/kernel/external-module-compat-comm.h
b/kernel/external-module-compat-comm.h
index 981dc96..634f717 100644
--- a/kernel/external-module-compat-comm.h
+++ b/kernel/external-module-compat-comm.h
@@ -501,6 +501,17 @@ struct timespec kvm_ns_to_timespec(const s64 nsec);
#endif
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,28)
+
+#define hrtimer_expires_remaining kvm_hrtimer_expires_remaining
+
+static inline ktime_t kvm_hrtimer_expires_remaining(const struct hrtimer
*timer)
+{
+ return ktime_sub(timer-expires, timer-base-get_time());
+}
+
+#endif
+
/* work_struct lost the 'data' field in 2.6.20 */
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
--
1.6.0.2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM guest crashes
Alexander Graf wrote: Alexander Graf wrote: [...] Also after two days of permanent stress testing I also got the Intel machine w/ current git down: + sudo -u contain1 env -i /usr/local/bin/qemu-system-x86_64 -localtime -kernel virtio-kernel -initrd virtio-initrd -nographic -append 'quiet clocksource=acpi_pm cifsuser=contain1 cifspass=contain1 root=cifs://contain1:conta...@172.16.1.1/contain1 realroot=//172.16.1.1/users/contain1 ip=172.16.1.2:172.16.1.1::255.255.255.0::eth0:none console=ttyS0 dhcp=off builder=1' -net nic,model=virtio,macaddr=52:54:00:12:34:1 -net tap,ifname=tap1,script=/bin/true -m 2000 -nographic -smp 8 /dev/null qemu: loading initrd (0x1daf359 bytes) at 0x7b24 Stuck ?? No backtrace here though. That's all I got from the serial console. + sudo -u contain1 env -i /usr/local/bin/qemu-system-x86_64 -localtime -kernel virtio-kernel -initrd virtio-initrd -nographic -append 'quiet clocksource=acpi_pm cifsuser=contain1 cifspass=contain1 root=cifs://contain1:conta...@172.16.1.1/contain1 realroot=//172.16.1.1/users/contain1 ip=172.16.1.2:172.16.1.1::255.255.255.0::eth0:none console=ttyS0 dhcp=off builder=1' -net nic,model=virtio,macaddr=52:54:00:12:34:1 -net tap,ifname=tap1,script=/bin/true -m 2000 -nographic -smp 8 /dev/null qemu: loading initrd (0x1daf359 bytes) at 0x7b24 Stuck ?? (qemu) info cpus * CPU #0: pc=0x80221f1d thread_id=15211 CPU #1: pc=0x80221f1d thread_id=15212 CPU #2: pc=0x80221f1d thread_id=15213 CPU #3: pc=0x80221f1d thread_id=15214 CPU #4: pc=0x8049f7d0 thread_id=15215 CPU #5: pc=0x80221f1d thread_id=15216 CPU #6: pc=0x80221f1d thread_id=15217 CPU #7: pc=0x0009f02c thread_id=15218 (qemu) cpu 7 (qemu) info registers EAX=0c06 EBX=05b8 ECX= EDX= ESI= EDI= EBP= ESP= EIP=002c EFL=00033002 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES = f300 CS =9f00 0009f000 f300 SS = f300 DS = f300 FS = f300 GS = f300 LDT= 8200 TR = fffbd000 2088 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 FCW=037f FSW= [ST=0] FTW=00 MXCSR= FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= Is that guest really seriously in BIOS code? After booting Linux? (qemu) x /2i $pc-1 0x0009f02b: hlt 0x0009f02c: jmp0x9f02b Where is this? Looks like panic code to me. 0x0009f000: cli 0x0009f001: xor%ax,%ax 0x0009f003: mov%ax,%ds 0x0009f005: mov$0x510,%ebx 0x0009f00b: addr32 mov (%ebx),%ecx 0x0009f00f: test %ecx,%ecx 0x0009f012: je 0x9f026 0x0009f014: addr32 mov 0x4(%ebx),%eax 0x0009f019: addr32 mov 0x8(%ebx),%edx 0x0009f01e: wrmsr 0x0009f020: add$0xc,%ebx 0x0009f024: jmp0x9f00b 0x0009f026: lock incw 1856 0x0009f02b: hlt 0x0009f02c: jmp0x9f02b Looks a lot like this: smp_ap_boot_code_start: cli xor %ax, %ax mov %ax, %ds mov $SMP_MSR_ADDR, %ebx 11: mov 0(%ebx), %ecx test %ecx, %ecx jz 12f mov 4(%ebx), %eax mov 8(%ebx), %edx wrmsr add $12, %ebx jmp 11b 12: lock incw smp_cpus 1: hlt jmp 1b But that code shouldn't run after Linux booted, right? And without at least a Power Off message I'd expect Linux to still be up. The only thing the host's dmesg was saying is this: Ignoring delivery mode 3 (repeated often) Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] External module compatibility for hrtimer_expires_remaining
Alexander Graf wrote: Due to Marcelo's APIC fix we now depend on hrtimer_expires_remaining, which is not available on my 2.6.27 kernel. This patch adds a backwards compatibility layer for it. Signed-off-by: Alexander Graf ag...@suse.de I just saw that you did one yourself that doesn't work for me. Is the #define reversed? Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2528121 ] Connecting a guest PC to a vlan cisco switch
Bugs item #2528121, was opened at 2009-01-22 02:02 Message generated for change (Comment added) made by alex_williamson You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2528121group_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: Interface (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Diego Celso (dcelso) Assigned to: Nobody/Anonymous (nobody) Summary: Connecting a guest PC to a vlan cisco switch Initial Comment: In my case I have Debian in host and guest. The switch have two vlan networks. in total there are three nets (192.168.1.0,192.168.4.0,192.168.101.0) I am using a tap interface for share the real interface. The network configuration is hostPC *** auto br0 iface br0 inet static address 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255 network 192.168.1.0 gateway 192.168.1.1 bridge_ports eth0 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off *** guestPC *** auto eth0 iface eth0 inet static address 192.168.1.11 netmask 255.255.255.0 broadcast 192.168.1.255 network 192.168.1.0 gateway 192.168.1.1 auto eth0.4 iface eth0 inet static address 192.168.4.11 netmask 255.255.255.0 broadcast 192.4.1.255 network 192.168.4.0 gateway 192.168.4.1 auto eth0.101 iface eth0 inet static address 192.168.101.11 netmask 255.255.255.0 broadcast 192.168.101.255 network 192.168.101.0 gateway 192.168.101.1 The running kvm have the parametters -net nic -net tap,ifname=tap0 The result is that the guestPC can not connet to the two vlan networks. It only can do ping to the PC connected to the network 192.168.1.0. Trying the same configuration in VirtualBox it goes very well. I think that the method that kvm use for share the interface is not a completely real share. -- Comment By: Alex Williamson (alex_williamson) Date: 2009-01-22 16:41 Message: I've used VLANs recently with both the e1000 and virtio NICs, haven't tried with the default 8139 NIC. For e1000 you need kvm-80 or better. For virtio, turn the MTU in the guest down a little bit (1500 - 4 should do it) or you'll hit a packet truncation issue (patch on the mailing list). You also need to make sure the host NIC on the bridge is not filtering VLAN packets. This typically means it can't be part of a VLAN. -- Comment By: Dor Laor (thekozmo) Date: 2009-01-22 07:20 Message: Where is your destination machine/interface? Note that if the guest nic is a vlan, the packet should come out tagged. A vlan interface needs to receive it on the host or on remote host. You can tcpdump the bridge to make sure the packets are tagged. Also make sure the mtu is 1518 (+4 for vlan tag) It was tested in the past without any issues. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2528121group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Questions about relation between kernel version and KVM userspace version
Hi list I've been wondering about something for a while: How does the version of the kernel module and the version of the KVM userspace relate? Eg. if you run with a newer 2.6.27-2.6.28 kernel with the modules included, will you then benefit from using the modules from the latest KVM release together with the latest KVM userspace, or isn't it worth the effort? According to http://kvm.qumranet.com/kvmwiki/Downloads, it is required to use at least kernel 2.6.25 to run KVM userspace 76 or newer. Does this mean that no changes/bugfixes has been made to the KVM kernel module since 2.6.25? Or is it because all the major bugfixes are made in KVM userspace instead of the KVM kernel modules? And one last thing: When I compile the latest KVM modules from sourceforge, I'll be able to see the KVM module version in /var/log/messages when I load the module. But this isn't the case when I load the modules that comes with the kernel - how can I see check the KVM module version of the current kernel? modinfo etc. doesn't give out any information. Thank you in advance... Best Regards Kenni -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about relation between kernel version and KVM userspace version
On Friday 23 January 2009 07:47:23 Kenni Lund wrote: Hi list Hi Kenni I've been wondering about something for a while: How does the version of the kernel module and the version of the KVM userspace relate? Eg. if you run with a newer 2.6.27-2.6.28 kernel with the modules included, will you then benefit from using the modules from the latest KVM release together with the latest KVM userspace, or isn't it worth the effort? According to http://kvm.qumranet.com/kvmwiki/Downloads, it is required to use at least kernel 2.6.25 to run KVM userspace 76 or newer. Does this mean that no changes/bugfixes has been made to the KVM kernel module since 2.6.25? Or is it because all the major bugfixes are made in KVM userspace instead of the KVM kernel modules? Three factors here: Host Linux version you are using, KVM modules, KVM userspace. The released package you saw contained both KVM modules and KVM userspace. You would find latest KVM modules files in /kernel directory. That's the modules we meant to use. And please use latest KVM release. Even Linux upstream is new, the latest KVM is newer. If you know how Linux kernel accept patches, you would know the upstream only accept new features when merge window is opening(and the maintainers are more careful with Linux upstream, so maybe not all new features can be pushed to Linux upstream). So every sub system of Linux kernel would hold lots of patches during merge window closed period. That's why latest KVM is newer. And one last thing: When I compile the latest KVM modules from sourceforge, I'll be able to see the KVM module version in /var/log/messages when I load the module. But this isn't the case when I load the modules that comes with the kernel - how can I see check the KVM module version of the current kernel? modinfo etc. doesn't give out any information. Yeah, it have been replaced by KVM module in kvm-userspace, which is correct. I am afraid no version for Linux upstream would show. Versions are only tags applied on KVM upstream, no such things for kernel. And ensure you are using latest KVM release would make keep you sync with the community and happy. :) -- regards Yang, Sheng -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 2/2] Finish hpet implementation for KVM
- add hpet to BIOS
- add disable/enable of kernel pit when hpet enters/leaves legacy mode
Signed-off-by: Beth Kon e...@us.ibm.com
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index d67616d..9981a1f 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -233,6 +233,24 @@ DefinitionBlock (
,, , AddressRangeMemory, TypeStatic)
})
}
+Device(HPET) {
+Name(_HID, EISAID(PNP0103))
+Name(_UID, 0)
+Method (_STA, 0, NotSerialized) {
+Return(0x0F)
+}
+Name(_CRS, ResourceTemplate() {
+DWordMemory(
+ResourceConsumer, PosDecode, MinFixed, MaxFixed,
+NonCacheable, ReadWrite,
+0x,
+0xFED0,
+0xFED003FF,
+0x,
+0x0400 /* 1K memory: FED0 - FED003FF */
+)
+})
+}
}
Scope(\_SB.PCI0) {
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 84f15fb..17c3704 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1272,7 +1272,7 @@ struct rsdp_descriptor /* Root System Descriptor
Pointer */
struct rsdt_descriptor_rev1
{
ACPI_TABLE_HEADER_DEF /* ACPI common table
header */
- uint32_t table_offset_entry [2]; /* Array
of pointers to other */
+ uint32_t table_offset_entry [3]; /* Array
of pointers to other */
/* ACPI tables */
} __attribute__((__packed__));
@@ -1412,6 +1412,31 @@ struct madt_processor_apic
#endif
} __attribute__((__packed__));
+/*
+ * * ACPI 2.0 Generic Address Space definition.
+ * */
+struct acpi_20_generic_address {
+uint8_t address_space_id;
+uint8_t register_bit_width;
+uint8_t register_bit_offset;
+uint8_t reserved;
+uint64_t address;
+} __attribute__((__packed__));
+
+/*
+ * * HPET Description Table
+ * */
+struct acpi_20_hpet {
+ACPI_TABLE_HEADER_DEF /* ACPI common table
header */
+uint32_t timer_block_id;
+struct acpi_20_generic_address addr;
+uint8_thpet_number;
+uint16_t min_tick;
+uint8_tpage_protect;
+} __attribute__((__packed__));
+
+#define ACPI_HPET_ADDRESS 0xFED0UL
+
struct madt_io_apic
{
APIC_HEADER_DEF
@@ -1484,6 +1509,8 @@ void acpi_bios_init(void)
struct facs_descriptor_rev1 *facs;
struct multiple_apic_table *madt;
uint8_t *dsdt;
+struct acpi_20_hpet *hpet;
+uint32_t hpet_addr;
uint32_t base_addr, rsdt_addr, fadt_addr, addr, facs_addr, dsdt_addr;
uint32_t acpi_tables_size, madt_addr, madt_size;
int i;
@@ -1531,6 +1558,11 @@ void acpi_bios_init(void)
madt_size += sizeof(struct madt_intsrcovr);
addr += madt_size;
+addr = (addr + 7) ~7;
+hpet_addr = addr;
+hpet = (void *)(addr);
+addr += sizeof(*hpet);
+
acpi_tables_size = addr - base_addr;
BX_INFO(ACPI tables: RSDP addr=0x%08lx ACPI DATA addr=0x%08lx
size=0x%x\n,
@@ -1552,6 +1584,7 @@ void acpi_bios_init(void)
memset(rsdt, 0, sizeof(*rsdt));
rsdt-table_offset_entry[0] = cpu_to_le32(fadt_addr);
rsdt-table_offset_entry[1] = cpu_to_le32(madt_addr);
+rsdt-table_offset_entry[2] = cpu_to_le32(hpet_addr);
acpi_build_table_header((struct acpi_table_header *)rsdt,
RSDT, sizeof(*rsdt), 1);
@@ -1641,6 +1674,15 @@ void acpi_bios_init(void)
}
acpi_build_table_header((struct acpi_table_header *)madt,
APIC, madt_size, 1);
+/* HPET */
+memset(hpet, 0, sizeof(*hpet));
+/* Note timer_block_id value must be kept in sync with value
advertised by
+ * emulated hpet
+ */
+hpet-timer_block_id = cpu_to_le32(0x8086a201);
+hpet-addr.address = cpu_to_le32(ACPI_HPET_ADDRESS);
+acpi_build_table_header((struct acpi_table_header *)hpet,
+ HPET, sizeof(*hpet), 1);
}
}
diff --git a/qemu/hw/hpet.c b/qemu/hw/hpet.c
index 7df2d05..80b2edd 100644
--- a/qemu/hw/hpet.c
+++ b/qemu/hw/hpet.c
@@ -30,8 +30,9 @@
#include console.h
#include qemu-timer.h
#include hpet_emul.h
+#include qemu-kvm.h
-//#define HPET_DEBUG
+#define HPET_DEBUG
#ifdef HPET_DEBUG
#define dprintf printf
#else
@@ -48,6 +49,43 @@ uint32_t hpet_in_legacy_mode(void)
return 0;
}
+static void hpet_kpit_enable(void)
+{
+struct kvm_pit_state ps;
+kvm_get_pit(kvm_context, ps);
+kvm_set_pit(kvm_context, ps);
+}
+
+static void hpet_kpit_disable(void)
+{
+struct kvm_pit_state ps;
+kvm_get_pit(kvm_context, ps);
+ps.channels[0].mode = 0xff;
+kvm_set_pit(kvm_context, ps);
+}
+
+static void hpet_legacy_enable(void)
+{
+if
[RFC][PATCH 1/2] Make irq0-inti2 override in BIOS configurable from userspace
This series of patches (nearly) resolves the irq0-inti2 override issue, and
gets the hpet working on kvm with and
without the in-kernel irqchip (i.e., it disables userspace and in-kernel pit as
needed).
- irq0-inti2
The resolution was to always use the override unless the kernel cannot do irq
routing (i.e., compatibility with old
kernels). So qemu checks whether the kernel is capable of irq routing. If so,
qemu tells kvm to route irq0 to
inti2 via the irq routing interface, and tells bios to add the irq0-inti2
override to the MADT interrupt source
override table, and to the mp table (for the non-acpi case). The only
outstanding problem here is that when I set
acpi=off on the kernel boot line, the boot fails. Apparently linux does not
like the way I implemented the override
for the mp table in rombios32.c. Since I am pressed for time at the moment,
I'm putting this patch set out for comments
in hopes that someone else may immediately see the problem. Otherwise I'll
keep looking into it as time permits.
- hpet
The hpet works with and without in-kernel irqchip. And many thanks to Marcelo
for finding a bios corruption bug that
was the primary source of win2k864 problems. Now the hpet works on linux
(ubuntu 8.0.4), win2k832. On win2k864 it works
with the in-kernel irqchip but is broken (i.e.,black screen) when
-no-kvm-irqchip is specified. Though I found that
it is also broken when I remove these 2 patches, so it appears to have
nothing to do with hpet or irq routing. Needs
more looking into.
Signed-off-by: Beth Kon e...@us.ibm.com
---
bios/Makefile|2 +-
bios/rombios32.c | 40
qemu/hw/apic.c |5 ++---
qemu/hw/fw_cfg.c |1 +
qemu/hw/fw_cfg.h |1 +
qemu/qemu-kvm.c |5 -
qemu/sysemu.h|1 +
qemu/vl.c| 10 --
8 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/bios/Makefile b/bios/Makefile
index 2d1f40d..374d70e 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -48,7 +48,7 @@ LIBS = -lm
RANLIB = ranlib
BCC = bcc
-GCC = gcc $(CFLAGS)
+GCC = gcc $(CFLAGS) -fno-stack-protector
HOST_CC = gcc
AS86 = as86
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 9d2eaaa..84f15fb 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -443,6 +443,7 @@ uint32_t cpuid_ext_features;
unsigned long ram_size;
uint64_t ram_end;
uint8_t bios_uuid[16];
+uint8_t irq0_override;
#ifdef BX_USE_EBDA_TABLES
unsigned long ebda_cur_addr;
#endif
@@ -475,6 +476,7 @@ void wrmsr_smp(uint32_t index, uint64_t val)
#define QEMU_CFG_SIGNATURE 0x00
#define QEMU_CFG_ID 0x01
#define QEMU_CFG_UUID 0x02
+#define QEMU_CFG_IRQ0_OVERRIDE 0x07
int qemu_cfg_port;
@@ -516,6 +518,18 @@ void uuid_probe(void)
memset(bios_uuid, 0, 16);
}
+void irq0_override_probe(void)
+{
+#ifdef BX_QEMU
+if(qemu_cfg_port) {
+qemu_cfg_select(QEMU_CFG_IRQ0_OVERRIDE);
+qemu_cfg_read(irq0_override, 1);
+return;
+}
+#endif
+memset(irq0_override, 0, 1);
+}
+
void cpu_probe(void)
{
uint32_t eax, ebx, ecx, edx;
@@ -1149,6 +1163,8 @@ static void mptable_init(void)
/* irqs */
for(i = 0; i 16; i++) {
+if (irq0_override i == 2)
+continue;
putb(q, 3); /* entry type = I/O interrupt */
putb(q, 0); /* interrupt type = vectored interrupt */
putb(q, 0); /* flags: po=0, el=0 */
@@ -1156,7 +1172,10 @@ static void mptable_init(void)
putb(q, 0); /* source bus ID = ISA */
putb(q, i); /* source bus IRQ */
putb(q, ioapic_id); /* dest I/O APIC ID */
-putb(q, i); /* dest I/O APIC interrupt in */
+if (irq0_override i == 0)
+putb(q, 2); /* dest I/O APIC interrupt in */
+else
+putb(q, i); /* dest I/O APIC interrupt in */
}
/* patch length */
len = q - mp_config_table;
@@ -1505,6 +1524,11 @@ void acpi_bios_init(void)
sizeof(struct madt_processor_apic) * MAX_CPUS +
sizeof(struct madt_io_apic);
madt = (void *)(addr);
+for (i = 0; i 16; i++)
+if (PCI_ISA_IRQ_MASK (1U i))
+madt_size += sizeof(struct madt_intsrcovr);
+if (irq0_override)
+madt_size += sizeof(struct madt_intsrcovr);
addr += madt_size;
acpi_tables_size = addr - base_addr;
@@ -1594,8 +1618,15 @@ void acpi_bios_init(void)
io_apic-interrupt = cpu_to_le32(0);
intsrcovr = (struct madt_intsrcovr*)(io_apic + 1);
-for ( i = 0; i 16; i++ ) {
-if ( PCI_ISA_IRQ_MASK (1U i) ) {
+for (i = 0; i 16; i++) {
+if (irq0_override i == 0) {
+memset(intsrcovr, 0, sizeof(*intsrcovr));
+intsrcovr-type = APIC_XRUPT_OVERRIDE;
+intsrcovr-length = sizeof(*intsrcovr);
+intsrcovr-source = i;
+intsrcovr-gsi= 2;
+intsrcovr-flags = 0; //conforms
[PATCH 0/6] kvm/powerpc: Add emulation for MPC85xx in KVM mode
This patch set enable another KVM PowerPC platform E500. Like the 440 core, the MMU and a few other bits are not currently emulated in Qemu itself, so right now it's only functional in conjunction with KVM. The emulation of MPC85xx boards (which use E500 as its core) can be run on any MPC85xx hosts. The code has been tested on MPC8544DS and MPC8572DS. Patch 1: enable the MPIC for MPC85xx platform Patch 2: add emulation of freescale PCI controller for MPC85xx platform Patch 3: add IRQ support for E500 core Patch 4: extern one function for MPC85xx code use Patch 5: add MPC85xx board emulation Patch 6: flat device tree of MPC85xx -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] kvm/powerpc: Enable MPIC for MPC85xx platform
This patch add MPIC support for MPC85xx platform.
MPIC and OpenPIC have very similar design.
So a lot of code can be reused.
Since no other TCG and KVM platforms uses OpenPIC for now,
the modification makes the code only support MPIC.
Signed-off-by: Liu Yu yu@freescale.com
---
hw/openpic.c | 383 +++---
hw/openpic.h | 19 +++
hw/ppc_mac.h | 14 +--
3 files changed, 388 insertions(+), 28 deletions(-)
create mode 100644 hw/openpic.h
diff --git a/hw/openpic.c b/hw/openpic.c
index b8da4d7..2b4b9d3 100644
--- a/hw/openpic.c
+++ b/hw/openpic.c
@@ -35,6 +35,7 @@
#include hw.h
#include ppc_mac.h
#include pci.h
+#include openpic.h
//#define DEBUG_OPENPIC
@@ -45,7 +46,7 @@
#endif
#define ERROR(fmr, args...) do { printf(ERROR: fmr , ##args); } while (0)
-#define USE_MPCxxx /* Intel model is broken, for now */
+#define USE_MPC85xx /* Intel model and mac99 are broken, for now */
#if defined (USE_INTEL_GW80314)
/* Intel GW80314 I/O Companion chip */
@@ -84,15 +85,6 @@ enum {
#define OPENPIC_LITTLE_ENDIAN 1
#define OPENPIC_BIG_ENDIAN0
-#else
-#error Please select which OpenPic implementation is to be emulated
-#endif
-
-#if (OPENPIC_BIG_ENDIAN !TARGET_WORDS_BIGENDIAN) || \
-(OPENPIC_LITTLE_ENDIAN TARGET_WORDS_BIGENDIAN)
-#define OPENPIC_SWAP
-#endif
-
/* Interrupt definitions */
#define IRQ_FE (EXT_IRQ) /* Internal functional IRQ */
#define IRQ_ERR(EXT_IRQ + 1) /* Error IRQ */
@@ -105,6 +97,61 @@ enum {
#define IRQ_MBX0 (IRQ_DBL0 + MAX_DBL) /* First mailbox IRQ */
#endif
+#elif defined(USE_MPC85xx)
+
+#define MPIC_MAP_SIZE 0x4
+
+#define MAX_CPU 1
+#define MAX_EXT12
+#define MAX_INT64
+#define MAX_DBL 0
+#define MAX_MBX 0
+#define MAX_TMR 4
+#define MAX_MSG 4
+#define MAX_MSI 8
+#define MAX_IPI 4
+#define MAX_IRQ(MAX_EXT + MAX_INT + MAX_TMR + MAX_MSG + MAX_MSI + (MAX_IPI
* MAX_CPU))
+
+#define VECTOR_BITS 8
+#define VID 0x0 /* MPIC version ID */
+#define VENI0x /* Vendor ID */
+
+enum {
+IRQ_IPVP = 0,
+IRQ_IDE,
+};
+
+enum ide_bits {
+IDR_EP = 0,
+IDR_CI0 = 1,
+IDR_CI1 = 2,
+IDR_P1 = 30,
+IDR_P0 = 31,
+};
+
+#define OPENPIC_LITTLE_ENDIAN 0
+#define OPENPIC_BIG_ENDIAN1
+
+/* Interrupt definitions */
+#define EXT_IRQ0
+#define INT_IRQ(EXT_IRQ + MAX_EXT)
+#define TMR_IRQ(INT_IRQ + MAX_INT)
+#define MSG_IRQ(TMR_IRQ + MAX_TMR)
+#define MSI_IRQ(MSG_IRQ + MAX_MSG)
+#define IPI_IRQ(MSI_IRQ + MAX_MSI)
+
+#define IRQ_IPI0IPI_IRQ
+#define IRQ_TIM0TMR_IRQ
+
+#else
+#error Please select which OpenPic implementation is to be emulated
+#endif
+
+#if (OPENPIC_BIG_ENDIAN !TARGET_WORDS_BIGENDIAN) || \
+(OPENPIC_LITTLE_ENDIAN TARGET_WORDS_BIGENDIAN)
+#define OPENPIC_SWAP
+#endif
+
#define BF_WIDTH(_bits_) \
(((_bits_) + (sizeof(uint32_t) * 8) - 1) / (sizeof(uint32_t) * 8))
@@ -157,6 +204,7 @@ enum IPVP_bits {
#define IPVP_VECTOR(_ipvpr_) ((_ipvpr_) IPVP_VECTOR_MASK)
typedef struct IRQ_dst_t {
+uint32_t tfrr;
uint32_t pctp; /* CPU current task priority */
uint32_t pcsr; /* CPU sensitivity register */
IRQ_queue_t raised;
@@ -200,6 +248,8 @@ typedef struct openpic_t {
#endif
/* IRQ out is used when in bypass mode (not implemented) */
qemu_irq irq_out;
+void (*reset) (struct openpic_t *);
+void (*irq_raise) (struct openpic_t *, int, IRQ_src_t *);
} openpic_t;
static inline void IRQ_setbit (IRQ_queue_t *q, int n_IRQ)
@@ -286,7 +336,7 @@ static void IRQ_local_pipe (openpic_t *opp, int n_CPU, int
n_IRQ)
return;
}
DPRINTF(Raise OpenPIC INT output cpu %d irq %d\n, n_CPU, n_IRQ);
-qemu_irq_raise(dst-irqs[OPENPIC_OUTPUT_INT]);
+opp-irq_raise(opp, n_CPU, src);
}
/* update pic state because registers for n_IRQ have changed value */
@@ -551,8 +601,8 @@ static void openpic_gbl_write (void *opaque, uint32_t addr,
uint32_t val)
case 0x00: /* FREP */
break;
case 0x20: /* GLBC */
-if (val 0x8000)
-openpic_reset(opp);
+if (val 0x8000 opp-reset)
+opp-reset(opp);
opp-glbc = val ~0x8000;
break;
case 0x80: /* VENI */
@@ -818,7 +868,7 @@ static void openpic_cpu_write (void *opaque, uint32_t addr,
uint32_t val)
IPVP_PRIORITY(src-ipvp) dst-servicing.priority)) {
DPRINTF(Raise OpenPIC INT output cpu %d irq %d\n,
idx, n_IRQ);
-qemu_irq_raise(dst-irqs[OPENPIC_OUTPUT_INT]);
+opp-irq_raise(opp, idx, src);
}
break;
default:
@@ -1001,6 +1051,11 @@ static void openpic_map(PCIDevice *pci_dev, int
region_num,
#endif
}
+static void openpic_irq_raise(openpic_t *opp, int n_CPU, IRQ_src_t *src)
+{
+
[PATCH 3/6] kvm/powerpc: Add irq support for E500 core
Signed-off-by: Liu Yu yu@freescale.com
---
hw/ppc.c| 89 +++
hw/ppc.h|1 +
target-ppc/cpu.h| 10 +
target-ppc/translate_init.c |6 ++-
4 files changed, 104 insertions(+), 2 deletions(-)
diff --git a/hw/ppc.c b/hw/ppc.c
index 05e787f..7a44951 100644
--- a/hw/ppc.c
+++ b/hw/ppc.c
@@ -314,6 +314,95 @@ void ppc40x_irq_init (CPUState *env)
env, PPC40x_INPUT_NB);
}
+/* PowerPC E500 internal IRQ controller */
+static void ppce500_set_irq (void *opaque, int pin, int level)
+{
+CPUState *env = opaque;
+int cur_level;
+
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: env %p pin %d level %d\n, __func__,
+env, pin, level);
+}
+#endif
+cur_level = (env-irq_input_state pin) 1;
+/* Don't generate spurious events */
+if ((cur_level == 1 level == 0) || (cur_level == 0 level != 0)) {
+switch (pin) {
+case PPCE500_INPUT_MCK:
+if (level) {
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: reset the PowerPC system\n,
+__func__);
+}
+#endif
+ fprintf(stderr,PowerPC E500 reset core\n);
+ qemu_system_reset_request();
+}
+break;
+case PPCE500_INPUT_RESET_CORE:
+if (level) {
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: reset the PowerPC core\n, __func__);
+}
+#endif
+ ppc_set_irq(env, PPC_INTERRUPT_MCK, level);
+}
+break;
+case PPCE500_INPUT_CINT:
+/* Level sensitive - active high */
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: set the critical IRQ state to %d\n,
+__func__, level);
+}
+#endif
+ppc_set_irq(env, PPC_INTERRUPT_CEXT, level);
+break;
+case PPCE500_INPUT_INT:
+/* Level sensitive - active high */
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: set the core IRQ state to %d\n,
+__func__, level);
+}
+#endif
+ppc_set_irq(env, PPC_INTERRUPT_EXT, level);
+break;
+case PPCE500_INPUT_DEBUG:
+/* Level sensitive - active high */
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: set the debug pin state to %d\n,
+__func__, level);
+}
+#endif
+ppc_set_irq(env, PPC_INTERRUPT_DEBUG, level);
+break;
+default:
+/* Unknown pin - do nothing */
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: unknown IRQ pin %d\n, __func__, pin);
+}
+#endif
+return;
+}
+if (level)
+env-irq_input_state |= 1 pin;
+else
+env-irq_input_state = ~(1 pin);
+}
+}
+
+void ppce500_irq_init (CPUState *env)
+{
+env-irq_inputs = (void **)qemu_allocate_irqs(ppce500_set_irq,
+ env, PPCE500_INPUT_NB);
+}
/*/
/* PowerPC time base and decrementer emulation */
struct ppc_tb_t {
diff --git a/hw/ppc.h b/hw/ppc.h
index 75eb11a..2ec4680 100644
--- a/hw/ppc.h
+++ b/hw/ppc.h
@@ -31,6 +31,7 @@ extern CPUReadMemoryFunc *PPC_io_read[];
void PPC_debug_write (void *opaque, uint32_t addr, uint32_t val);
void ppc40x_irq_init (CPUState *env);
+void ppce500_irq_init (CPUState *env);
void ppc6xx_irq_init (CPUState *env);
void ppc970_irq_init (CPUState *env);
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index f7a12da..0eb794f 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1352,6 +1352,16 @@ enum {
};
enum {
+/* PowerPC E500 input pins */
+PPCE500_INPUT_RESET_CORE = 0,
+PPCE500_INPUT_MCK= 1,
+PPCE500_INPUT_CINT = 3,
+PPCE500_INPUT_INT= 4,
+PPCE500_INPUT_DEBUG = 6,
+PPCE500_INPUT_NB,
+};
+
+enum {
/* PowerPC 40x input pins */
PPC40x_INPUT_RESET_CORE = 0,
PPC40x_INPUT_RESET_CHIP = 1,
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 5008a3a..7953c69 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -4154,7 +4154,8 @@ static void init_proc_e300 (CPUPPCState *env)
POWERPC_FLAG_BUS_CLK)
#define check_pow_e500 check_pow_hid0
-__attribute__ (( unused ))
+extern void ppce500_irq_init (CPUState *env);
+
static void init_proc_e500 (CPUPPCState *env)
[PATCH 4/6] kvm/powerpc: extern one function for MPC85xx code use
Signed-off-by: Liu Yu yu@freescale.com
---
target-ppc/kvm_ppc.c |2 +-
target-ppc/kvm_ppc.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/target-ppc/kvm_ppc.c b/target-ppc/kvm_ppc.c
index f7ce52b..82c0f42 100644
--- a/target-ppc/kvm_ppc.c
+++ b/target-ppc/kvm_ppc.c
@@ -22,7 +22,7 @@ static QEMUTimer *kvmppc_timer;
static unsigned int kvmppc_timer_rate;
#ifdef HAVE_FDT
-static int kvmppc_read_host_property(const char *node_path, const char *prop,
+int kvmppc_read_host_property(const char *node_path, const char *prop,
void *val, size_t len)
{
char *path;
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index e536a88..3792ef7 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -11,5 +11,7 @@
void kvmppc_init(void);
void kvmppc_fdt_update(void *fdt);
+int kvmppc_read_host_property(const char *node_path, const char *prop,
+ void *val, size_t len);
#endif /* __KVM_PPC_H__ */
--
1.5.4
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] kvm/powerpc: Add MPC85xx board support
All MPC85xx boards use E500v1/v2 core.
This patch add emulation of a virtual MPC85xx board,
so that any MPC85xx host could run this emulation.
Only tested it on MPC8544DS and MPC8572DS hosts,
but it should work on other MPC85xx boards.
Signed-off-by: Liu Yu yu@freescale.com
---
Makefile.target |2 +-
hw/boards.h |1 +
hw/ppce500.h | 22 +++
hw/ppce500_mpc85xx.c | 346 ++
target-ppc/machine.c |1 +
5 files changed, 371 insertions(+), 1 deletions(-)
create mode 100644 hw/ppce500.h
create mode 100644 hw/ppce500_mpc85xx.c
diff --git a/Makefile.target b/Makefile.target
index 5cae257..3852f53 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -599,7 +599,7 @@ OBJS+= unin_pci.o ppc_chrp.o
OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc4xx_pci.o ppc405_uc.o ppc405_boards.o
OBJS+= ppc440.o ppc440_bamboo.o
# PowerPC E500 boards
-OBJS+= ppce500_pci.o
+OBJS+= ppce500_pci.o ppce500_mpc85xx.o
ifdef FDT_LIBS
OBJS+= device_tree.o
LIBS+= $(FDT_LIBS)
diff --git a/hw/boards.h b/hw/boards.h
index 0577f06..1939f78 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -40,6 +40,7 @@ extern QEMUMachine heathrow_machine;
extern QEMUMachine ref405ep_machine;
extern QEMUMachine taihu_machine;
extern QEMUMachine bamboo_machine;
+extern QEMUMachine mpc85xx_machine;
/* mips_r4k.c */
extern QEMUMachine mips_machine;
diff --git a/hw/ppce500.h b/hw/ppce500.h
new file mode 100644
index 000..24d49bb
--- /dev/null
+++ b/hw/ppce500.h
@@ -0,0 +1,22 @@
+/*
+ * QEMU PowerPC E500 emulation shared definitions
+ *
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Yu Liu, yu@freescale.com
+ *
+ * This file is derived from hw/ppc440.h
+ * the copyright for that material belongs to the original owners.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#if !defined(PPC_E500_H)
+#define PPC_E500_H
+
+PCIBus *ppce500_pci_init(qemu_irq *pic, target_phys_addr_t registers);
+
+#endif /* !defined(PPC_E500_H) */
diff --git a/hw/ppce500_mpc85xx.c b/hw/ppce500_mpc85xx.c
new file mode 100644
index 000..9dd619d
--- /dev/null
+++ b/hw/ppce500_mpc85xx.c
@@ -0,0 +1,346 @@
+/*
+ * Qemu PowerPC MPC85xx board emualtion
+ *
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Yu Liu, yu@freescale.com
+ *
+ * This file is derived from hw/ppc440_bamboo.c,
+ * the copyright for that material belongs to the original owners.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include dirent.h
+
+#include config.h
+#include qemu-common.h
+#include net.h
+#include hw.h
+#include pc.h
+#include pci.h
+#include virtio-blk.h
+#include boards.h
+#include sysemu.h
+#include kvm.h
+#include kvm_ppc.h
+#include device_tree.h
+#include openpic.h
+#include ppce500.h
+
+#define BINARY_DEVICE_TREE_FILE mpc85xx.dtb
+#define UIMAGE_LOAD_BASE 0
+#define DTB_LOAD_BASE0x60
+#define INITRD_LOAD_BASE 0x200
+
+#define RAM_SIZES_ALIGN (64UL 20)
+
+#define MPC85xx_CCSRBAR_BASE 0xE000
+#define MPC85xx_MPIC_REGS_BASE (MPC85xx_CCSRBAR_BASE + 0x4)
+#define MPC85xx_SERIAL0_REGS_BASE (MPC85xx_CCSRBAR_BASE + 0x4500)
+#define MPC85xx_SERIAL1_REGS_BASE (MPC85xx_CCSRBAR_BASE + 0x4600)
+#define MPC85xx_PCI_REGS_BASE (MPC85xx_CCSRBAR_BASE + 0x8000)
+#define MPC85xx_PCI_REGS_SIZE 0x1000
+#define MPC85xx_PCI_IO 0xE100
+#define MPC85xx_PCI_IOLEN 0x1
+
+struct board {
+const char *model;
+const char *compatible;
+};
+
+#define BOARD_DEF(_model, _compatible) \
+{\
+.model = _model, \
+.compatible = _compatible, \
+}
+
+/* Supported host boards */
+static const struct board mpc85xx_table[] = {
+BOARD_DEF(MPC8544DS,MPC8544DS), /* MPC8544DS */
+BOARD_DEF(fsl,MPC8572DS,fsl,MPC8572DS), /* MPC8572DS */
+BOARD_DEF(fsl,mpc8536ds,fsl,mpc8536ds), /* MPC8536DS */
+BOARD_DEF(MPC8548CDS, MPC8548CDS),/* MPC8548CDS */
+BOARD_DEF(MPC8555CDS, MPC8555CDS),/* MPC8555CDS */
+BOARD_DEF(MPC8541CDS, MPC8541CDS),/* MPC8541CDS */
+BOARD_DEF(MPC8540ADS, MPC8540ADS),/* MPC8540ADS */
+BOARD_DEF(MPC8560ADS, MPC8560ADS),/* MPC8560ADS */
+BOARD_DEF(MPC8568EMDS, MPC8568EMDS), /* MPC8568EMDS */
+};
+
+#define BOARDS_NUM (sizeof(mpc85xx_table)/sizeof(struct board))
+
+static int
Re: [PATCH 5/6] kvm/powerpc: Add MPC85xx board support
On Thu, 2009-01-22 at 18:14 +0800, Liu Yu wrote:
All MPC85xx boards use E500v1/v2 core.
This patch add emulation of a virtual MPC85xx board,
so that any MPC85xx host could run this emulation.
Only tested it on MPC8544DS and MPC8572DS hosts,
but it should work on other MPC85xx boards.
Signed-off-by: Liu Yu yu@freescale.com
...
+struct board {
+const char *model;
+const char *compatible;
+};
+
+#define BOARD_DEF(_model, _compatible) \
+{\
+.model = _model, \
+.compatible = _compatible, \
+}
+
+/* Supported host boards */
+static const struct board mpc85xx_table[] = {
+BOARD_DEF(MPC8544DS,MPC8544DS), /* MPC8544DS */
+BOARD_DEF(fsl,MPC8572DS,fsl,MPC8572DS), /* MPC8572DS */
+BOARD_DEF(fsl,mpc8536ds,fsl,mpc8536ds), /* MPC8536DS */
+BOARD_DEF(MPC8548CDS, MPC8548CDS),/* MPC8548CDS */
+BOARD_DEF(MPC8555CDS, MPC8555CDS),/* MPC8555CDS */
+BOARD_DEF(MPC8541CDS, MPC8541CDS),/* MPC8541CDS */
+BOARD_DEF(MPC8540ADS, MPC8540ADS),/* MPC8540ADS */
+BOARD_DEF(MPC8560ADS, MPC8560ADS),/* MPC8560ADS */
+BOARD_DEF(MPC8568EMDS, MPC8568EMDS), /* MPC8568EMDS */
+};
+
+#define BOARDS_NUM (sizeof(mpc85xx_table)/sizeof(struct board))
...
+static void *mpc85xx_load_device_tree(void *addr,
+ uint32_t ramsize,
+ target_phys_addr_t initrd_base,
+ target_phys_addr_t initrd_size,
+ const char *kernel_cmdline)
+{
...
+if (kvm_enabled()) {
+ FILE *fp;
+ char *model;
+ char const *compatible = NULL;
+ struct dirent *dirp;
+ DIR *dp;
+ int i;
+ char buf[128];
+
+ if ((fp = fopen(/proc/cpuinfo, r)) == NULL) {
+ printf(Can't open file /proc/cpuinfo\n);
+ goto out;
+ }
+ while (fgets(buf, 128, fp) != NULL) {
+ if (strncmp(buf, model, 5) == 0) {
+ model = buf + 9;
+ break;
+ }
+ }
+ fclose(fp);
+
+ for (i = 0; i BOARDS_NUM; i++) {
+ if (strncmp(model, mpc85xx_table[i].model,
+ strlen(mpc85xx_table[i].model)) == 0) {
+ compatible = mpc85xx_table[i].compatible;
+ }
+ }
+
+ if (compatible == NULL) {
+ printf(Unknow host board!\n);
+ goto out;
+ }
+
+ ret = qemu_devtree_setprop_string(fdt, /, compatible, compatible);
+ if (ret 0)
+ fprintf(stderr, couldn't set /compatible = %s\n, compatible);
+
+ if ((dp = opendir(/proc/device-tree/cpus/)) == NULL) {
+ printf(Can't open directory /proc/device-tree/cpus/\n);
+ goto out;
+ }
+
+ buf[0] = '\0';
+ while ((dirp = readdir(dp)) != NULL) {
+ if (strncmp(dirp-d_name, PowerPC, 7) == 0) {
+ sprintf(buf, /proc/device-tree/cpus/%s, dirp-d_name);
+ break;
+ }
+ }
+ closedir(dp);
+ if (buf[0] == '\0') {
+ printf(Unknow host!\n);
+ goto out;
+ }
+ path = buf + 17;
I don't think you should do this at all. As long as the core is known,
it doesn't matter what the host board is. You *always* emulate the
MPC8544DS board (that's what your device tree says). You should be able
to emulate a MPC8544DS on *any* e500v2 host board or chip.
For comparison, on 440 we have tested with Sequoia (440EPx) and Bamboo
(440EP) hosts, but qemu always emulates a Bamboo guest. The chips aren't
the same, but that's irrelevant because the core is (440 x5).
The rest of this patch looks good.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] kvm/powerpc: Add emulation for MPC85xx in KVM mode
On Thu, 2009-01-22 at 18:14 +0800, Liu Yu wrote: This patch set enable another KVM PowerPC platform E500. Like the 440 core, the MMU and a few other bits are not currently emulated in Qemu itself, so right now it's only functional in conjunction with KVM. The emulation of MPC85xx boards (which use E500 as its core) can be run on any MPC85xx hosts. The code has been tested on MPC8544DS and MPC8572DS. Patch 1: enable the MPIC for MPC85xx platform Patch 2: add emulation of freescale PCI controller for MPC85xx platform Patch 3: add IRQ support for E500 core Patch 4: extern one function for MPC85xx code use Patch 5: add MPC85xx board emulation Patch 6: flat device tree of MPC85xx Patches 1-4: Acked-by: Hollis Blanchard holl...@us.ibm.com I've posted some comments on patches 5 and 6. Aurelian, would you mind reviewing patches 1-3? -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] qemu/kvm: Add MPC85xx support
Oops. I just saw this mail.
I don't know why it's junked by my client...
OK. I will change it to MPC8544 and remove redundant node in fdt.
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Hollis Blanchard
Sent: Saturday, January 10, 2009 4:36 AM
To: Liu Yu-B13201
Cc: kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 4/5] qemu/kvm: Add MPC85xx support
On Fri, 2009-01-09 at 15:56 +0800, Liu Yu wrote:
As E500 exists in various boards such as MPC8544ds,
MPC8572ds, MPC8560ads, etc..
So I would like to implement a general virtual board
MPC85xx to simplify the case.
When 'cat /proc/cpuinfo' in guest, it will show:
processor : 0
cpu : e500v2
clock : 1499.985015MHz
revision: 3.0 (pvr 8021 0030)
bogomips: 285.69
timebase: 74999250
platform: MPC8572 DS Host platform
model : KVM MPC85xx
The current method is that change guest dts
/compatible=host model,
this seems somewhat dirty. It works for 8544, 8572 but not
sure for others.
I'll change it to search a table next time.
Signed-off-by: Liu Yu yu@freescale.com
---
Makefile.target |2 +
hw/boards.h |1 +
hw/ppc.c| 89 +++
hw/ppc.h|1 +
hw/ppce500_mpc85xx.c| 284
++
pc-bios/mpc85xx.dtb | Bin 0 - 12288 bytes
pc-bios/mpc85xx.dts | 361
+++
target-ppc/cpu.h| 12 ++
target-ppc/machine.c|1 +
target-ppc/translate_init.c |6 +-
10 files changed, 755 insertions(+), 2 deletions(-)
create mode 100644 hw/ppce500_mpc85xx.c
create mode 100644 pc-bios/mpc85xx.dtb
create mode 100644 pc-bios/mpc85xx.dts
diff --git a/Makefile.target b/Makefile.target
index b66b699..abf0d59 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -657,6 +657,8 @@ OBJS+= unin_pci.o ppc_chrp.o
# PowerPC 4xx boards
OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc4xx_pci.o
ppc405_uc.o ppc405_boards.o
OBJS+= ppc440.o ppc440_bamboo.o
+# PowerPC E500 boards
+OBJS+= ppce500.o ppce500_mpc85xx.o ppce500_pci.o mpic.o
ifdef FDT_LIBS
OBJS+= device_tree.o
LIBS+= $(FDT_LIBS)
diff --git a/hw/boards.h b/hw/boards.h
index bff1cf0..35bd5ae 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -39,6 +39,7 @@ extern QEMUMachine heathrow_machine;
extern QEMUMachine ref405ep_machine;
extern QEMUMachine taihu_machine;
extern QEMUMachine bamboo_machine;
+extern QEMUMachine mpc85xx_machine;
/* mips_r4k.c */
extern QEMUMachine mips_machine;
diff --git a/hw/ppc.c b/hw/ppc.c
index 60d6e86..fbce211 100644
--- a/hw/ppc.c
+++ b/hw/ppc.c
@@ -421,6 +421,95 @@ void ppc40x_irq_init (CPUState *env)
env,
PPC40x_INPUT_NB);
}
+/* PowerPC E500 internal IRQ controller */
+static void ppce500_set_irq (void *opaque, int pin, int level)
+{
+CPUState *env = opaque;
+int cur_level;
+
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: env %p pin %d level %d\n, __func__,
+env, pin, level);
+}
+#endif
+cur_level = (env-irq_input_state pin) 1;
+/* Don't generate spurious events */
+if ((cur_level == 1 level == 0) || (cur_level == 0
level != 0)) {
+switch (pin) {
+case PPCE500_INPUT_MCK:
+if (level) {
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: reset the
PowerPC system\n,
+__func__);
+}
+#endif
+ fprintf(stderr,PowerPC E500 reset core\n);
+ qemu_system_reset_request();
+}
+break;
+case PPCE500_INPUT_RESET_CORE:
+if (level) {
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: reset the
PowerPC core\n, __func__);
+}
+#endif
+ ppc_set_irq(env, PPC_INTERRUPT_MCK, level);
+}
+break;
+case PPCE500_INPUT_CINT:
+/* Level sensitive - active high */
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: set the critical IRQ
state to %d\n,
+__func__, level);
+}
+#endif
+ppc_set_irq(env, PPC_INTERRUPT_CEXT, level);
+break;
+case PPCE500_INPUT_INT:
+/* Level sensitive - active high */
+#if defined(PPC_DEBUG_IRQ)
+if (loglevel CPU_LOG_INT) {
+fprintf(logfile, %s: set the core IRQ
state to %d\n,
+
