Re: virtio_net hang
On Thu, Nov 13, 2008 at 04:24:52PM +0100, Emmanuel Lacour wrote: On Thu, Nov 13, 2008 at 03:12:33PM +, Mark McLoughlin wrote: The fact that re-loading the virtio_net driver fixes things up makes me suspect you've found a bug in the virtio_net driver, rather than e.g. a bug in the kvm-userspace side. To try and narrow down what's happening, when the interface has hung, try: - tcpdump on both eth0 in the guest and the tap device on the host (tap5 in your example) On eth0 I see echo requests, but _no_ echo replies On tap5 I see echo requests _and_ echo replies - look for anything unusual in the stats for both those interfaces, e.g. /proc/net/dev, netstat -s etc. Comparing with other guest without problems, the only difference is that this tap (and only this one) reports overruns: tap5 Link encap:Ethernet HWaddr 00:FF:AD:53:76:25 inet6 addr: fe80::2ff:adff:fe53:7625/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:717737621 errors:0 dropped:0 overruns:0 frame:0 TX packets:636626720 errors:0 dropped:0 overruns:317 carrier:0 collisions:0 txqueuelen:500 RX bytes:368973099756 (343.6 GiB) TX bytes:217917073227 (202.9 GiB) overruns seems to happen just when there is hang, it doesn't seems to increase when network is working properly. - strace the /usr/bin/kvm process Unfortunatly I was unable to do this because I can't reproduce the problem on a test VM and I can't leave this VM with a non working network for analysis because of production so I have a script which pings and restart module/interface when needed. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] KVM: support VT-d device hotplug
From bba614bf2acf22f765995fb2364de04cec039226 Mon Sep 17 00:00:00 2001
From: Weidong Han [EMAIL PROTECTED]
Date: Fri, 14 Nov 2008 16:53:10 +0800
Subject: [PATCH] support VT-d device hotplug
wrap kvm_assign_device() and kvm_deassign_device() to support assign/deassign a
device to a guest
Signed-off-by: Weidong Han [EMAIL PROTECTED]
---
include/linux/kvm.h |2 +
include/linux/kvm_host.h | 18 +++
virt/kvm/kvm_main.c | 45 -
virt/kvm/vtd.c | 55 ++
4 files changed, 119 insertions(+), 1 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 44fd7fa..558bc32 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -425,6 +425,8 @@ struct kvm_trace_rec {
struct kvm_assigned_pci_dev)
#define KVM_ASSIGN_IRQ _IOR(KVMIO, 0x70, \
struct kvm_assigned_irq)
+#define KVM_DEASSIGN_PCI_DEVICE _IOR(KVMIO, 0x71, \
+struct kvm_assigned_pci_dev)
/*
* ioctls for vcpu fds
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 3a0fb77..4830372 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -326,6 +326,10 @@ int kvm_iommu_map_pages(struct kvm *kvm, gfn_t base_gfn,
int kvm_iommu_map_guest(struct kvm *kvm,
struct kvm_assigned_dev_kernel *assigned_dev);
int kvm_iommu_unmap_guest(struct kvm *kvm);
+int kvm_assign_device(struct kvm *kvm,
+ struct kvm_assigned_dev_kernel *assigned_dev);
+int kvm_deassign_device(struct kvm *kvm,
+ struct kvm_assigned_dev_kernel *assigned_dev);
#else /* CONFIG_DMAR */
static inline int kvm_iommu_map_pages(struct kvm *kvm,
gfn_t base_gfn,
@@ -345,6 +349,20 @@ static inline int kvm_iommu_unmap_guest(struct kvm *kvm)
{
return 0;
}
+
+static inline int kvm_assign_device(struct kvm *kvm,
+ struct kvm_assigned_dev_kernel
+ *assigned_dev)
+{
+ return 0;
+}
+
+static inline int kvm_deassign_device(struct kvm *kvm,
+ struct kvm_assigned_dev_kernel
+ *assigned_dev)
+{
+ return 0;
+}
#endif /* CONFIG_DMAR */
static inline void kvm_guest_enter(void)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 4f43abe..689d615 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -293,7 +293,11 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
list_add(match-list, kvm-arch.assigned_dev_head);
if (assigned_dev-flags KVM_DEV_ASSIGN_ENABLE_IOMMU) {
- r = kvm_iommu_map_guest(kvm, match);
+ if (kvm-arch.intel_iommu_domain)
+ r = kvm_assign_device(kvm, match);
+ else
+ r = kvm_iommu_map_guest(kvm, match);
+
if (r)
goto out_list_del;
}
@@ -313,6 +317,34 @@ out_free:
mutex_unlock(kvm-lock);
return r;
}
+
+static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
+struct kvm_assigned_pci_dev
+ *assigned_dev)
+{
+ int r = 0;
+ struct kvm_assigned_dev_kernel *match;
+
+ mutex_lock(kvm-lock);
+
+ match = kvm_find_assigned_dev(kvm-arch.assigned_dev_head,
+ assigned_dev-assigned_dev_id);
+ if (!match) {
+ printk(KERN_INFO %s: device hasn't been assigned before,
+ so cannot be deassigned\n, __func__);
+ r = -EINVAL;
+ goto out;
+ }
+
+ if (assigned_dev-flags KVM_DEV_ASSIGN_ENABLE_IOMMU)
+ kvm_deassign_device(kvm, match);
+
+ kvm_free_assigned_device(kvm, match);
+
+out:
+ mutex_unlock(kvm-lock);
+ return r;
+}
#endif
static inline int valid_vcpu(int n)
@@ -1650,6 +1682,17 @@ static long kvm_vm_ioctl(struct file *filp,
goto out;
break;
}
+ case KVM_DEASSIGN_PCI_DEVICE: {
+ struct kvm_assigned_pci_dev assigned_dev;
+
+ r = -EFAULT;
+ if (copy_from_user(assigned_dev, argp, sizeof assigned_dev))
+ goto out;
+ r = kvm_vm_ioctl_deassign_device(kvm, assigned_dev);
+ if (r)
+ goto out;
+ break;
+ }
#endif
default:
r = kvm_arch_vm_ioctl(filp, ioctl, arg);
diff --git a/virt/kvm/vtd.c b/virt/kvm/vtd.c
index a770874..de55457 100644
--- a/virt/kvm/vtd.c
+++ b/virt/kvm/vtd.c
@@ -86,6 +86,61 @@ static int kvm_iommu_map_memslots(struct kvm *kvm)
return r;
}
+int kvm_assign_device(struct kvm *kvm,
+ struct
Support VT-d device hotplug
Currently, it doesn't handle cleanly for VT-d device hot add, because kvm_map_guest() will allocate a dmar_domain. It should add a device to the existed dmar_domain instead create a new one. For hot remove, it doesn't release the device from adev_head list, remove its ioperm data from ioperm_head list, and detach it from the dmar_domain. This patchset adds these supports both on kernel and userspace. Regards, Weidong-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] KVM/userspace: Add deassign ioctl
From 79fd6880a8e7caaecc98e559a673400d20fb14be Mon Sep 17 00:00:00 2001
From: Weidong Han [EMAIL PROTECTED]
Date: Fri, 14 Nov 2008 16:31:12 +0800
Subject: [PATCH] Deassign ioctl
Add this to support hot remove assigned device
Signed-off-by: Weidong Han [EMAIL PROTECTED]
---
libkvm/libkvm.c | 12
libkvm/libkvm.h | 12
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index e7dba8a..a42bcad 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -1125,6 +1125,18 @@ int kvm_assign_pci_device(kvm_context_t kvm,
return ret;
}
+int kvm_deassign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev)
+{
+ int ret;
+
+ ret = ioctl(kvm-vm_fd, KVM_DEASSIGN_PCI_DEVICE, assigned_dev);
+ if (ret 0)
+ return -errno;
+
+ return ret;
+}
+
int kvm_assign_irq(kvm_context_t kvm,
struct kvm_assigned_irq *assigned_irq)
{
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 53d67f2..e2da8da 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -701,6 +701,18 @@ int kvm_assign_pci_device(kvm_context_t kvm,
struct kvm_assigned_pci_dev *assigned_dev);
/*!
+ * \brief Notifies host kernel about a PCI device to be deassigned from a guest
+ *
+ * Used for hot remove PCI device, this function notifies the host
+ * kernel about the deassigning of the physical PCI device from a guest.
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param assigned_dev Parameters, like bus, devfn number, etc
+ */
+int kvm_deassign_pci_device(kvm_context_t kvm,
+ struct kvm_assigned_pci_dev *assigned_dev);
+
+/*!
* \brief Notifies host kernel about changes to IRQ for an assigned device
*
* Used for PCI device assignment, this function notifies the host
--
1.5.1
0002-Deassign-ioctl.patch
Description: 0002-Deassign-ioctl.patch
[PATCH 3/4] KVM/userspace: Add interface to remove ioperm data
From 9cf3b4c270c12f1ba966a033f3d207aed898a52a Mon Sep 17 00:00:00 2001
From: Weidong Han [EMAIL PROTECTED]
Date: Fri, 14 Nov 2008 16:35:16 +0800
Subject: [PATCH] Add interface to remove ioperm data
When hot remove assigned device, need to remove its ioperm data
Signed-off-by: Weidong Han [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 16 ++--
qemu/qemu-kvm.h |2 ++
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 4100bc8..06bcba0 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -1059,9 +1059,21 @@ int
qemu_kvm_unregister_coalesced_mmio(target_phys_addr_t addr,
#include sys/io.h
#ifdef USE_KVM_DEVICE_ASSIGNMENT
-void kvm_add_ioperm_data(struct ioperm_data *data)
+void kvm_add_ioperm_data(void *data)
{
-LIST_INSERT_HEAD(ioperm_head, data, entries);
+LIST_INSERT_HEAD(ioperm_head, (struct ioperm_data *)data, entries);
+}
+
+void kvm_remove_ioperm_data(unsigned long start_port, unsigned long num)
+{
+struct ioperm_data *data;
+
+LIST_FOREACH(data, ioperm_head, entries) {
+if (data-start_port == start_port
+data-num == num)
+LIST_REMOVE(data, entries);
+qemu_free(data);
+}
}
void kvm_ioperm(CPUState *env, void *data)
diff --git a/qemu/qemu-kvm.h b/qemu/qemu-kvm.h
index 56bc0e7..e5a8b06 100644
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -95,6 +95,8 @@ void qemu_kvm_system_reset_request(void);
#ifdef USE_KVM_DEVICE_ASSIGNMENT
void kvm_ioperm(CPUState *env, void *data);
+void kvm_add_ioperm_data(void *data);
+void kvm_remove_ioperm_data(unsigned long start_port, unsigned long num);
void kvm_arch_do_ioperm(void *_data);
#endif
--
1.5.1
0003-Add-interface-to-remove-ioperm-data.patch
Description: 0003-Add-interface-to-remove-ioperm-data.patch
[PATCH 4/4] KVM/userspace: support hot remove assigned device
From 63d8eeeff86e881ab212baed4af51801dbb90460 Mon Sep 17 00:00:00 2001
From: Weidong Han [EMAIL PROTECTED]
Date: Fri, 14 Nov 2008 16:45:44 +0800
Subject: [PATCH] support hot remove assigned device
When hot remove assigned device, deassign it from guest, delete it from
adev_head and remove its ioperm data.
need to assign irq in init_assigned_device(), because assigned_dev_update_irq()
may not be invoked when hot add a device. Additionally, remove the useless
parameter of assigned_dev_update_irq()
Signed-off-by: Weidong Han [EMAIL PROTECTED]
---
qemu/hw/device-assignment.c | 160 ---
qemu/hw/device-assignment.h |2 +
qemu/hw/device-hotplug.c| 17 +
qemu/hw/pci.c |4 +-
4 files changed, 156 insertions(+), 27 deletions(-)
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index 9aa7708..05db326 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -447,7 +447,7 @@ static uint32_t calc_assigned_dev_id(uint8_t bus, uint8_t
devfn)
/* The pci config space got updated. Check if irq numbers have changed
* for our devices
*/
-void assigned_dev_update_irq(PCIDevice *d)
+void assigned_dev_update_irq(void)
{
int irq, r;
AssignedDevice *assigned_dev;
@@ -459,7 +459,7 @@ void assigned_dev_update_irq(PCIDevice *d)
irq = piix_get_irq(irq);
#ifdef TARGET_IA64
- irq = ipf_map_irq(d, irq);
+ irq = ipf_map_irq(assigned_dev-dev, irq);
#endif
if (irq != assigned_dev-girq) {
@@ -485,12 +485,68 @@ void assigned_dev_update_irq(PCIDevice *d)
}
}
+static int assign_device(AssignedDevice *dev, int disable_iommu)
+{
+int r;
+struct kvm_assigned_pci_dev assigned_dev_data;
+
+memset(assigned_dev_data, 0, sizeof(assigned_dev_data));
+assigned_dev_data.assigned_dev_id =
+ calc_assigned_dev_id(dev-h_busnr, dev-h_devfn);
+assigned_dev_data.busnr = dev-h_busnr;
+assigned_dev_data.devfn = dev-h_devfn;
+
+#ifdef KVM_CAP_IOMMU
+/* We always enable the IOMMU if present
+ * (or when not disabled on the command line)
+ */
+r = kvm_check_extension(kvm_context, KVM_CAP_IOMMU);
+if (r !disable_iommu)
+ assigned_dev_data.flags |= KVM_DEV_ASSIGN_ENABLE_IOMMU;
+#endif
+
+r = kvm_assign_pci_device(kvm_context, assigned_dev_data);
+if (r 0)
+ fprintf(stderr, Could not notify kernel about
+assigned device (%x:%x.%x)\n,
+dev-h_busnr,
+PCI_SLOT(dev-h_devfn),
+PCI_FUNC(dev-h_devfn));
+
+return r;
+}
+
+static int assign_irq(AssignedDevice *dev)
+{
+int irq, r = 0;
+struct kvm_assigned_irq assigned_irq_data;
+
+irq = pci_map_irq(dev-dev, dev-intpin);
+irq = piix_get_irq(irq);
+
+#ifdef TARGET_IA64
+irq = ipf_map_irq(dev-dev, irq);
+#endif
+
+memset(assigned_irq_data, 0, sizeof(assigned_irq_data));
+assigned_irq_data.assigned_dev_id =
+calc_assigned_dev_id(dev-h_busnr, dev-h_devfn);
+assigned_irq_data.guest_irq = irq;
+assigned_irq_data.host_irq = dev-real_device.irq;
+r = kvm_assign_irq(kvm_context, assigned_irq_data);
+if (r 0)
+fprintf(stderr, Are you assigning a device
+that shares IRQ with some other device?\n);
+
+dev-girq = irq;
+return r;
+}
+
struct PCIDevice *init_assigned_device(AssignedDevInfo *adev, PCIBus *bus)
{
int r;
AssignedDevice *dev;
uint8_t e_device, e_intx;
-struct kvm_assigned_pci_dev assigned_dev_data;
DEBUG(Registering real physical device %s (bus=%x dev=%x func=%x)\n,
adev-name, adev-bus, adev-dev, adev-func);
@@ -526,32 +582,22 @@ struct PCIDevice *init_assigned_device(AssignedDevInfo
*adev, PCIBus *bus)
dev-h_busnr = adev-bus;
dev-h_devfn = PCI_DEVFN(adev-dev, adev-func);
-memset(assigned_dev_data, 0, sizeof(assigned_dev_data));
-assigned_dev_data.assigned_dev_id =
- calc_assigned_dev_id(dev-h_busnr, (uint32_t)dev-h_devfn);
-assigned_dev_data.busnr = dev-h_busnr;
-assigned_dev_data.devfn = dev-h_devfn;
-
-#ifdef KVM_CAP_IOMMU
-/* We always enable the IOMMU if present
- * (or when not disabled on the command line)
- */
-r = kvm_check_extension(kvm_context, KVM_CAP_IOMMU);
-if (r !adev-disable_iommu)
- assigned_dev_data.flags |= KVM_DEV_ASSIGN_ENABLE_IOMMU;
-#endif
-
-r = kvm_assign_pci_device(kvm_context, assigned_dev_data);
-if (r 0) {
- fprintf(stderr, Could not notify kernel about
-assigned device \%s\\n, adev-name);
- perror(register_real_device);
+/* assign device to guest */
+r = assign_device(dev, adev-disable_iommu);
+if (r 0)
goto out;
-}
+/* assign IRQ to device */
+r = assign_irq(dev);
+if (r 0)
+ goto out;
+
adev-assigned_dev = dev;
- out:
return dev-dev;
+
+out:
+/*FIXME: release resources */
+
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Jamie Lokier wrote: But does the fact KVM doesn't use TCG prevent KVM from running some x86 modes correctly? E.g. I gather 16-bit code is run by KVM using VM86 mode, which is not exactly correct. It would be nice to have KVM acceleration but also complete and correct emulation, by switching to TCG for those modes. There is work in progress to make 16-bit emulation fully accurate. Also, an earlier thread pointed out that loops doing a lot of MMIO are _slower_ with KVM than without - this manifested as very slow VGA output for some guests. Having KVM pass control to TCG for short runs of guest instructions which do MMIO, or other instructions which need to be emulated, would accelerate KVM in this respect. Since TCG is not smp-safe, this is very problematic for smp guests. You would have to stop virtualization on all vcpus and start tcg on all of them. Performance would plummet. There are ways of mitigating the high mmio cost with kvm. For framebuffers, one can allow kvm direct access. For other mmio, there's the 'coalesced mmio' support which allows mmio to be batched when this does not affect emulation accuracy and latency. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Avi Kivity wrote: Jamie Lokier wrote: But does the fact KVM doesn't use TCG prevent KVM from running some x86 modes correctly? E.g. I gather 16-bit code is run by KVM using VM86 mode, which is not exactly correct. It would be nice to have KVM acceleration but also complete and correct emulation, by switching to TCG for those modes. There is work in progress to make 16-bit emulation fully accurate. Ooh! I want my Windows 95 to run in KVM :-) I'm curious, how is this planned to work? I'm having trouble thinking of how to do it without software emulation at some stage. Also, an earlier thread pointed out that loops doing a lot of MMIO are _slower_ with KVM than without - this manifested as very slow VGA output for some guests. Having KVM pass control to TCG for short runs of guest instructions which do MMIO, or other instructions which need to be emulated, would accelerate KVM in this respect. (I think VMware does something like this, btw). Since TCG is not smp-safe, this is very problematic for smp guests. You would have to stop virtualization on all vcpus and start tcg on all of them. Performance would plummet. On the other hand, when running on a KVM-capable architecture combination, it is definitely possible to make TCG smp-safe because every guest atomic instruction has a corresponding host one. It's practically a 1:1 instruction mapping on x86, which doesn't have many atomic instructions. (Maybe harder on other archs). There are ways of mitigating the high mmio cost with kvm. For framebuffers, one can allow kvm direct access. For other mmio, there's the 'coalesced mmio' support which allows mmio to be batched when this does not affect emulation accuracy and latency. Don't you still have to trap for each MMIO in order to collect the batch, except for REP instructions? It's the traps which are expensive. Fortunately modern hardware tends to use DMA for data intensive things, and MMIO just to trigger DMA, and initialisation. -- Jamie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cross vendor migration ideas
* On Thursday 13 Nov 2008 19:08:14 Alexander Graf wrote: On 13.11.2008, at 05:35, Amit Shah wrote: * On Wednesday 12 Nov 2008 22:49:16 Alexander Graf wrote: On 12.11.2008, at 17:52, Amit Shah wrote: Hi Alex, * On Wednesday 12 Nov 2008 21:09:43 Alexander Graf wrote: Hi, I was thinking a bit about cross vendor migration recently and since we're doing open source development, I figured it might be a good idea to talk to everyone about this. So why are we having a problem? In normal operation we don't. If we're running a 32-bit kernel, we can use SYSENTER to jump from kernel-userspace. If we're on a 64-bit kernel with 64-bit userspace, every CPU supports SYSCALL. At least Linux is being smart on this and does use exactly these two capabilities in these two cases. But if we're running in compat mode (64-bit kernel with 32-bit userspace), things differ. Intel supports only SYSENTER here, while AMD only supports SYSCALL. Both can still use int80. Operating systems detect usage of SYSCALL or SYSENTER pretty early on (Linux does this on vdso). So when we boot up on an Intel machine, Linux assumes that using SYSENTER in compat mode is fine. Migrating that machine to an AMD machine breaks this assumption though, since SYSENTER can't be used in compat mode. On LInux, this detection is based on the CPU vendor string. If Linux finds a GenuineIntel, SYSENTER is used in compat mode, if it's AuthenticAMD, SYSCALL is used and if none of these two is found, int80 is used. I tried modifying the vendor string, removed the overwrite the vendor string with the native string hack and things look like they work just fine with Linux. Unfortunately right now I don't have a 64-bit Windows installation around to check if that approach works there too, but if it does and no known OS breaks due to the invalid vendor string, we can just create our own virtual CPU string, no? qemu has an option for that, -cpu qemu64 IIRC. As long as we expose practically correct cpuids and MSRs, this should be fine. I've not tested qemu64 with winxp x64 though. Also, last I knew, winxp x64 installation didn't succeed with --no-kvm. qemu by default exposes an AMD CPU type. I wasn't talking about CPUID features, but the vendor string. Qemu64 provides the AuthenticAMD string, so we don't run into any issues I'm presuming. Right -- the thing is, with the default AuthenticAMD string, winp x64 installation fails. That has to be because of some missing cpuids. That's one of the drawbacks of exposing a well-known CPU type. I was suggesting we should try out the -cpu qemu64 CPU type since it exposes a non- standard CPU to see if guests and most userspace programs work fine without any further tweaking -- see the 'cons' below for why this might be a problem. I still don't really understand what you're trying to say - qemu64 is the default in KVM right now. You mean winxp64 installation doesn't No, the default for KVM is the host CPU type. work as is and we should fix it? This has nothing to do with the migration problems, right? Solutions shouldn't involve adding known regressions. If our default cpu type changes to one that renders some of the OSes we support right now to become nonfunctional, such changes won't be accepted. Of course, we can improve the qemu64 cpu type to ensure the popular OS types work properly at the least. There are pros and cons to expose a custom vendor ID: pros: - We don't need to have all the cpuid features exposed which are expected of a physically available CPU in the market, for example, badly-coded applications might crash if we don't have SSSE3 on a Core2Duo. But badly-coded or not, not exposing what's actually available on every C2D out there is bad. cons: - To expose the correct set of feature bits for a known processor, we also need to check the family/model/stepping to support the exact same feature bits that were present in the CPU. - We might not get some optimizations that OSes might have based on CPU type, even if the host CPU qualifies for such optimizations - Standard programs like benchmarking tools, etc., might fail if they depend on the vendor string for their functionality For 32-bit guests, I think exposing a pentium4 or Athlon CPU type should be fine. For 64-bit guests, the newer the better. Well, we could create different CPU definitions: - migration safe (do what is safe for migration) There are multiple ways of approaching this: peg to a least-known good CPU type, all of whose instructions will work on processors from both the major vendors. However, you never know how the server pools change and you'd want to upgrade the CPU type once you know the CPUs that are installed in servers. This has to be dynamic and the management application has to take care of exposing a CPU that's
Re: [ANNOUNCE] kvm-79 release
Avi Kivity wrote: This is the first release to fully support pci device assignment. You can assign a pci device to qemu on the command line, or hot-plug it in via the monitor. Note that at this time, Linux 2.6.28 is required on the host. Upstream qemu recently gained kvm support. At this time a lot is missing in upstream (smp, performance) so this the upstream capabilities are not used yet. Over time we will switch to using qemu upstream for more functionality. hi, - guest fedora-9 latest kernel-2.6.26.6-79.fc9.i686 still not boot, - guest centos-5 x86_64's kernel-2.6.18-92.1.17.el5 still gives the same crash as kvm-78 (screenshot attached), - guest mandrake-10 still can't boot so imho still not the best release:-( -- Levente Si vis pacem para bellum! inline: devel-x86-64-kvm-79.png
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
2008/11/14 Anthony Liguori [EMAIL PROTECTED]: The issue is not disabling TCG at runtime. That's easy enough. The issue is that TCG doesn't exist (and probably won't ever exist) for certain architectures like ia64 and s390. Being forced to build with TCG support makes having QEMU + KVM not possible on these platforms even though they both support KVM. I mean either compile-time or run-time: assuming that each QEMUAccel implementation is a bunch of files + a struct with pointers in the common code, it should make turning on/off each emulator easy. Cheers -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Jamie Lokier wrote: Anthony Liguori wrote: Unlike kqemu, KVM does not use TCG at all when accelerating QEMU. Having TCG present is not a problem when using KVM on x86. x86 already has TCG host and target support and it's quite convenient to be able to disable/enable KVM and compare it to TCG when debugging. I agree with removing/isolating the dependency on TCG, and there are good reasons for it. But does the fact KVM doesn't use TCG prevent KVM from running some x86 modes correctly? E.g. I gather 16-bit code is run by KVM using VM86 mode, which is not exactly correct. It would be nice to have KVM acceleration but also complete and correct emulation, by switching to TCG for those modes. That's just a limitation of Intel VT. AMD SVM runs 16-bit code natively. We're slowly improving our in-kernel emulator so eventually we'll be able to emulate 16-bit mode in the kernel. Running 16-bit code in TCG is something that has been considered. Also, an earlier thread pointed out that loops doing a lot of MMIO are _slower_ with KVM than without - this manifested as very slow VGA output for some guests. Having KVM pass control to TCG for short runs of guest instructions which do MMIO, or other instructions which need to be emulated, would accelerate KVM in this respect. It falls apart for SMP guests. TCG does not preserve atomicity of memory instructions so you could never have an SMP VCPU running on bare metal while TCG is running. There is a rather large initial cost for building the TBs too so in practice, there are few areas that benefit from this sort of hand off. The VGA optimization actually addresses this problem in a much nicer way. KVM also supports MMIO batching which we'll eventually merge that covers the remaining cases pretty well. Regards, Anthony Liguori -- Jamie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH][RFC] Split non-TCG bits out of exec.c
Jamie Lokier wrote: Also, an earlier thread pointed out that loops doing a lot of MMIO are _slower_ with KVM than without - this manifested as very slow VGA output for some guests. Having KVM pass control to TCG for short runs of guest instructions which do MMIO, or other instructions which need to be emulated, would accelerate KVM in this respect. Note, the devil is in the details here. An MMIO exit to userspace typically costs around 6k cycles. On the other hand, a TB translation tends to average closer to 300k often times reaching much higher. This with was with dyngen so TCG may be more or less expensive. An in-kernel MMIO exit on the other hand will cost around 3k cycles. MMIO coalescing is pretty efficient because it effectively reduces the cost of a exit by half. To make up the cost of TCG translation for just one TB, you need to have a tight loop of at least 50 iterations. We can handle rep instructions with a single exit in KVM so this needs to be an actual MMIO loop, not a rep loop. If you also consider all the potential locking issues with SMP guests, I think it's pretty likely that there are few cases where dropping to TCG is going to be a net performance win. Regards, Anthony Liguori -- Jamie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hangs
I've have setup a couple virtual machines and they work great... for anywhere between 2-24 hours. But then, for no reason I can determine, they just go 100% busy and stop responding. My basic setup is: Ubuntu 8.10 server running on both host and guests. kvm version is the one from the Ubuntu distribution (kvm-72) Kernel is Ubuntu 8.10 kernel (2.6.27-7-server) The two VMs are both run like: kvm -daemonize \ -hda Imgs/ndev_root.img \ -m 1024 -cdrom ISOs/ubuntu-8.10-server-amd64.iso \ -vnc :1 -net nic,macaddr=DE:AD:BE:EF:04:04,model=e1000 \ -net tap,ifname=tap1,script=/home/chris/kvm/qemu-ifup.sh (With different disk imgs, vnc addresses and macaddrs) The disk images are raw format: qemu-img create -f raw 80G Imgs/ndev_root.img I've tried running with these options, and in different combos: -no-kvm-pit -no-kvm-irqchip -no-acpi They don't seem to help much. If anything, -no-kvm-irqchip seems to cause more troubles. I tried running with -no-kvm and it won't boot at all. I also built my own 2.6.27.4 kernel, from kernel.org, and built my own version of kvm-78, but saw the same behavior. Anyone have any advice how I can resolve these hangs? When the setup works, it's a beautiful setup and I love kvm. But with the 100% busy hangs I can't really continue with it. Thanks! Chris -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] remove unnecessary bool from qemu-kvm.c
Hi,
In support of Avi's preference for half line patches, I split out the
bool eliminating bits too.
Cheers,
Jes
Replace unnecessary use of _Bool type with int.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
---
qemu/qemu-kvm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: kvm-userspace.git/qemu/qemu-kvm.c
===
--- kvm-userspace.git.orig/qemu/qemu-kvm.c
+++ kvm-userspace.git/qemu/qemu-kvm.c
@@ -28,7 +28,6 @@
#include sys/syscall.h
#include sys/mman.h
-#define bool _Bool
#define false 0
#define true 1
@@ -53,7 +52,7 @@
struct qemu_kvm_work_item *next;
void (*func)(void *data);
void *data;
-bool done;
+int done;
};
struct vcpu_info {
Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
On Fri, Nov 14, 2008 at 03:56:19PM +0800, Zhao, Yu wrote: Hi Greg KH, I updated PF driver to use latest SR-IOV API in the patch set v6, and attached it. Please take a look and please let us know if you have any comments. Is this driver already upstream? If so, can you just send the diff that adds the SR-IOV changes to it? Otherwise it's a bit hard to just pick out those pieces, right? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
It's not upstream yet. However, if you grep through for CONFIG_PCI_IOV you'll see all the relevant code in those sections. - Greg (Rose that is) -Original Message- From: Greg KH [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2008 9:40 AM To: Zhao, Yu Cc: Rose, Gregory V; Dong, Eddie; kvm@vger.kernel.org; Barnes, Jesse; Ronciak, John; Nakajima, Jun; Yu, Wilfred; Li, Xin B; Li, Susie Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support On Fri, Nov 14, 2008 at 03:56:19PM +0800, Zhao, Yu wrote: Hi Greg KH, I updated PF driver to use latest SR-IOV API in the patch set v6, and attached it. Please take a look and please let us know if you have any comments. Is this driver already upstream? If so, can you just send the diff that adds the SR-IOV changes to it? Otherwise it's a bit hard to just pick out those pieces, right? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: virtio_net hang
On Fri, 2008-11-14 at 10:23 +0100, Emmanuel Lacour wrote: On Thu, Nov 13, 2008 at 04:24:52PM +0100, Emmanuel Lacour wrote: On Thu, Nov 13, 2008 at 03:12:33PM +, Mark McLoughlin wrote: The fact that re-loading the virtio_net driver fixes things up makes me suspect you've found a bug in the virtio_net driver, rather than e.g. a bug in the kvm-userspace side. To try and narrow down what's happening, when the interface has hung, try: - tcpdump on both eth0 in the guest and the tap device on the host (tap5 in your example) On eth0 I see echo requests, but _no_ echo replies On tap5 I see echo requests _and_ echo replies Okay, so the guest isn't receiving packets. - look for anything unusual in the stats for both those interfaces, e.g. /proc/net/dev, netstat -s etc. Comparing with other guest without problems, the only difference is that this tap (and only this one) reports overruns: tap5 Link encap:Ethernet HWaddr 00:FF:AD:53:76:25 inet6 addr: fe80::2ff:adff:fe53:7625/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:717737621 errors:0 dropped:0 overruns:0 frame:0 TX packets:636626720 errors:0 dropped:0 overruns:317 carrier:0 collisions:0 txqueuelen:500 RX bytes:368973099756 (343.6 GiB) TX bytes:217917073227 (202.9 GiB) overruns seems to happen just when there is hang, it doesn't seems to increase when network is working properly. Right, the tap device tx queue is full because kvm-userspace isn't reading packets from it. This could be because kvm-userspace has just stopped noticing that there's data available from the tapfd or because virtio_net in the guest has stopped noticing that packets are available in the ring. One thing you could easily check is whether: ip link set eth0 down ip link set eth0 up in the host is sufficient to fix it? If it is, then it points to a guest driver issue. Cheers, Mark. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
On Fri, Nov 14, 2008 at 09:48:15AM -0800, Rose, Gregory V wrote: It's not upstream yet. However, if you grep through for CONFIG_PCI_IOV you'll see all the relevant code in those sections. Wouldn't it make more sense for the IOV code to be reworked to not require #ifdefs in a driver? There seems to be a bit too much #ifdef code in this driver right now :( What is the status of submitting it upstream and getting netdev review of it? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-79 release
Farkas Levente wrote: Avi Kivity wrote: This is the first release to fully support pci device assignment. You can assign a pci device to qemu on the command line, or hot-plug it in via the monitor. Note that at this time, Linux 2.6.28 is required on the host. Upstream qemu recently gained kvm support. At this time a lot is missing in upstream (smp, performance) so this the upstream capabilities are not used yet. Over time we will switch to using qemu upstream for more functionality. hi, - guest fedora-9 latest kernel-2.6.26.6-79.fc9.i686 still not boot, - guest centos-5 x86_64's kernel-2.6.18-92.1.17.el5 still gives the same crash as kvm-78 (screenshot attached), Those two should be fine with this patch [1]. You are welcome to test it and be the first (mmmh...) to provide feedback on it. - guest mandrake-10 still can't boot Can't help here, your test boots fine on OpenSuse's 2.6.25.18-0.2 with kvm.git for me as well. so imho still not the best release:-( Bugs happen, and some corner cases may remain unfixed for a longer time as they happen to be hard to track down. Jan [1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/24409 signature.asc Description: OpenPGP digital signature
RE: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
We have been waiting for the kernel IOV work to be in place upstream completely before we submitted the drivers. Jeff Garzik won't take driver changes that have no user. So as the kernel work completes, we'll submit the driver(s). We have been talking about putting out the changes as RFC. If that make sense we can do that. Cheers, John --- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety., Benjamin Franklin 1755 -Original Message- From: Greg KH [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2008 10:39 AM To: Rose, Gregory V Cc: Zhao, Yu; Dong, Eddie; kvm@vger.kernel.org; Barnes, Jesse; Ronciak, John; Nakajima, Jun; Yu, Wilfred; Li, Xin B; Li, Susie Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support On Fri, Nov 14, 2008 at 09:48:15AM -0800, Rose, Gregory V wrote: It's not upstream yet. However, if you grep through for CONFIG_PCI_IOV you'll see all the relevant code in those sections. Wouldn't it make more sense for the IOV code to be reworked to not require #ifdefs in a driver? There seems to be a bit too much #ifdef code in this driver right now :( What is the status of submitting it upstream and getting netdev review of it? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-78 - kernel panic after using system_reset except when using -no-kvm-irqchip
Jan Kiszka wrote: Charles Duffy wrote: Jan Kiszka wrote: Charles Duffy wrote: irq 25, desc: 803afc80, depth: 1, count: 0, unhandled: 0 -handle_irq(): 800b54e3, handle_bad_irq+0x0/0x1f6 -chip(): 802ea700, 0x802ea700 -action(): IRQ_DISABLED set unexpected IRQ trap at vector 19 ..MP-BIOS bug: 8254 timer not connected to IO-APIC timer doesn't work through the IO-APIC - disabling NMI Watchdog! Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter Still too early for me, so I didn't get yet if you can trigger this guest panic reliably or only sporadically (like I can). In the former case I would be very interested in the how! Reproduced 100% of the time when using system_reset at the qemu monitor console coming from a non-panic'd state. (Thus, it happens only every other time doing a series of boots and system_reset monitor commands). Mmmh, /that/ sounds like some (re-)initialization issue of the virtualized hardware. OK, once that kernel boots again on latest kvm.git (currently broken due to a different issue), I will try to reproduce it. OK, I can reproduce now. It's an in-kernel irqchip, -no-kvm-irqchip doesn't suffer. Will see if I can find the reason. Jan signature.asc Description: OpenPGP digital signature
Re: KVM performance
See if boosting the priority of the VM (see man chrt), and locking it to a core (see man taskset) helps. You'll want to do that for the vcpu thread(s) (in the qmeu monitor, run 'info cpus' command). david Randy Broman wrote: I am using Intel Core2 Duo E6600, Kubuntu 8.04 with kernel 2.6.24-21-generic, kvm (as in QEMU PC emulator version 0.9.1 (kvm-62)) and a WinXP SP3 guest, with bridged networking. My start command is: sudo kvm -m 1024 -cdrom /dev/cdrom -boot c -net nic,macaddr=00:d0:13:b0:2d:32, model=rtl8139 -net tap -soundhw all -localtime /home/rbroman/windows.img All this is stable and generally works well, except that internet-based video and audio performance is poor (choppy, skips) in comparison with performance under WinXP running native on the same machine (it's a dual-boot). I would appreciate recommendations to improve video and audio performance, and have the following specific questions: -I've tried both the default Cirrus adapter and the -std-vga option. Which is better? I saw reference to another VMware-based adapter, but I can't figure out how to implement it - would that be better? -I notice we're up to kvm-79 vs my kvm-62. Should I move to the newer version? Do I have to custom-compile my kernel to do so, and if so what kernel version and what specific kernel options should I use? -Are there other tuning steps I could take? Please copy me directly as I'm not on this list. Thankyou -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
A: No. Q: Should I include quotations after my reply? On Fri, Nov 14, 2008 at 11:49:52AM -0700, Ronciak, John wrote: We have been waiting for the kernel IOV work to be in place upstream completely before we submitted the drivers. Jeff Garzik won't take driver changes that have no user. So as the kernel work completes, we'll submit the driver(s). We have been talking about putting out the changes as RFC. If that make sense we can do that. That would make sense, as I had to ask multiple times if a driver was actually using the IOV code that we could review to see if the api was sane for it. good luck, greg k-h -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest kvm.git versus Windows Vista?
walt wrote: ... So, does anyone have Vista working on recent kvm.git? Yes. I do, but only because I forgot to load the kvm-amd kernel module. I guess that means I'm really running Vista on plain qemu, and not on kvm at all. Is that correct? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest kvm.git versus Windows Vista?
walt wrote: walt wrote: ... So, does anyone have Vista working on recent kvm.git? Yes. I do, but only because I forgot to load the kvm-amd kernel module. I guess that means I'm really running Vista on plain qemu, and not on kvm at all. Is that correct? It appears to be. How slow is it? (Yes, I know it's Vista). I haven't been able to run a stable Vista (64 bit) since kvm-75. -John -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-79 release
Jan Kiszka wrote: Farkas Levente wrote: - guest fedora-9 latest kernel-2.6.26.6-79.fc9.i686 still not boot, - guest centos-5 x86_64's kernel-2.6.18-92.1.17.el5 still gives the same crash as kvm-78 (screenshot attached), Those two should be fine with this patch [1]. You are welcome to test it and be the first (mmmh...) to provide feedback on it. I've been able to reproduce the issue on CentOS 5 x86_64 guests quite reliably; after applying the patch to kvm-79 (with the necessary filename munging), this issue does indeed appear to be resolved. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cross vendor migration ideas
Amit, Alex, Please see my comments bellow. Avi, Please have a look at the patches, and let me know the parts you think can be done better. On Fri, 2008-11-14 at 06:07 -0700, Amit Shah wrote: * On Thursday 13 Nov 2008 19:08:14 Alexander Graf wrote: On 13.11.2008, at 05:35, Amit Shah wrote: * On Wednesday 12 Nov 2008 22:49:16 Alexander Graf wrote: On 12.11.2008, at 17:52, Amit Shah wrote: Hi Alex, * On Wednesday 12 Nov 2008 21:09:43 Alexander Graf wrote: Hi, I was thinking a bit about cross vendor migration recently and since we're doing open source development, I figured it might be a good idea to talk to everyone about this. So why are we having a problem? In normal operation we don't. If we're running a 32-bit kernel, we can use SYSENTER to jump from kernel-userspace. If we're on a 64-bit kernel with 64-bit userspace, every CPU supports SYSCALL. At least Linux is being smart on this and does use exactly these two capabilities in these two cases. But if we're running in compat mode (64-bit kernel with 32-bit userspace), things differ. Intel supports only SYSENTER here, while AMD only supports SYSCALL. Both can still use int80. Operating systems detect usage of SYSCALL or SYSENTER pretty early on (Linux does this on vdso). So when we boot up on an Intel machine, Linux assumes that using SYSENTER in compat mode is fine. Migrating that machine to an AMD machine breaks this assumption though, since SYSENTER can't be used in compat mode. On LInux, this detection is based on the CPU vendor string. If Linux finds a GenuineIntel, SYSENTER is used in compat mode, if it's AuthenticAMD, SYSCALL is used and if none of these two is found, int80 is used. I tried modifying the vendor string, removed the overwrite the vendor string with the native string hack and things look like they work just fine with Linux. Unfortunately right now I don't have a 64-bit Windows installation around to check if that approach works there too, but if it does and no known OS breaks due to the invalid vendor string, we can just create our own virtual CPU string, no? qemu has an option for that, -cpu qemu64 IIRC. As long as we expose practically correct cpuids and MSRs, this should be fine. I've not tested qemu64 with winxp x64 though. Also, last I knew, winxp x64 installation didn't succeed with --no-kvm. qemu by default exposes an AMD CPU type. I wasn't talking about CPUID features, but the vendor string. Qemu64 provides the AuthenticAMD string, so we don't run into any issues I'm presuming. Right -- the thing is, with the default AuthenticAMD string, winp x64 installation fails. That has to be because of some missing cpuids. That's one of the drawbacks of exposing a well-known CPU type. I was suggesting we should try out the -cpu qemu64 CPU type since it exposes a non- standard CPU to see if guests and most userspace programs work fine without any further tweaking -- see the 'cons' below for why this might be a problem. I still don't really understand what you're trying to say - qemu64 is the default in KVM right now. You mean winxp64 installation doesn't No, the default for KVM is the host CPU type. Amit, Aliex is correct. the default cpu for kvm is qemu64 not the host. I have sent the patches to add an options -cpu host. Some of the patches are gone in, But All the patches are not in yet. Also my patches does not make the host option as default. I have attached the remaining two patches. Alex, can you try these patches with -cpu host option and see if you can get the host vendor string in the guest for AMD box. I have already tested it on the latest Intel system. work as is and we should fix it? This has nothing to do with the migration problems, right? Solutions shouldn't involve adding known regressions. If our default cpu type changes to one that renders some of the OSes we support right now to become nonfunctional, such changes won't be accepted. Of course, we can improve the qemu64 cpu type to ensure the popular OS types work properly at the least. There are pros and cons to expose a custom vendor ID: pros: - We don't need to have all the cpuid features exposed which are expected of a physically available CPU in the market, for example, badly-coded applications might crash if we don't have SSSE3 on a Core2Duo. But badly-coded or not, not exposing what's actually available on every C2D out there is bad. cons: - To expose the correct set of feature bits for a known processor, we also need to check the family/model/stepping to support the exact same feature bits that were present in the CPU. - We might not get some optimizations that OSes might have based on CPU type, even if the host CPU qualifies for such optimizations -
[ kvm-Bugs-2287677 ] kvm79 compiling errors (with-patched-kernel)
Bugs item #2287677, was opened at 2008-11-15 01:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2287677group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Darkman (darkman82) Assigned to: Nobody/Anonymous (nobody) Summary: kvm79 compiling errors (with-patched-kernel) Initial Comment: config.mak : ARCH=i386 PROCESSOR=i386 PREFIX=/usr KERNELDIR=/usr/src/linux-2.6.27.6/ KERNELSOURCEDIR= LIBKVM_KERNELDIR=/root/kvm-79/kernel WANT_MODULE= CROSS_COMPILE= CC=gcc LD=ld OBJCOPY=objcopy AR=ar ERRORS: /root/kvm-79/qemu/qemu-kvm.c: In function 'ap_main_loop': /root/kvm-79/qemu/qemu-kvm.c:459: error: 'kvm_arch_do_ioperm' undeclared (first use in this function) /root/kvm-79/qemu/qemu-kvm.c:459: error: (Each undeclared identifier is reported only once /root/kvm-79/qemu/qemu-kvm.c:459: error: for each function it appears in.) /root/kvm-79/qemu/qemu-kvm.c: In function 'sigfd_handler': /root/kvm-79/qemu/qemu-kvm.c:544: warning: format '%ld' expects type 'long int', but argument 2 has type 'ssize_t' make[2]: *** [qemu-kvm.o] Error 1 make[2]: Leaving directory `/root/kvm-79/qemu/x86_64-softmmu' make[1]: *** [subdir-x86_64-softmmu] Error 2 make[1]: Leaving directory `/root/kvm-79/qemu' make: *** [qemu] Error 2 Same problem with 2.6.27.2 source. kvm78 works fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2287677group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0 of 2] Hello World test for libcflat
These patches add a Hello World test program for libcflat. It also includes a fix for guest load address code. They have been tested successfully on a host kernel built on 10/10/08. However, the test fails on a more recent kernel, built on 11/2/08. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1 of 2] [PATCH] kvm-userspace: ppc: Add hello world test for libcflat
# HG changeset patch
# User Deepa Srinivasan [EMAIL PROTECTED]
# Date 1226681616 21600
# Node ID 1a74ac23ff60cc2ab052072243dc4ff47faf5849
# Parent bdd5682d28d56e62c93a795465eb3625713a3885
[PATCH] kvm-userspace: ppc: Add hello world test for libcflat
From: Deepa Srinivasan [EMAIL PROTECTED]
Add a test program (hello world) to exercise printf() in libcflat.
Also, include -ffreestanding in the compiler options to avoid any checks for
built-in functions.
Signed-off-by: Deepa Srinivasan [EMAIL PROTECTED]
---
[diffstat]
b/user/test/powerpc/helloworld.c |8
user/config-powerpc.mak |4 +++-
2 files changed, 11 insertions(+), 1 deletion(-)
[diff]
diff -r bdd5682d28d5 -r 1a74ac23ff60 user/config-powerpc.mak
--- a/user/config-powerpc.mak Fri Nov 14 10:48:21 2008 -0600
+++ b/user/config-powerpc.mak Fri Nov 14 10:53:36 2008 -0600
@@ -1,5 +1,6 @@ CFLAGS += -I $(KERNELDIR)/include
CFLAGS += -I $(KERNELDIR)/include
CFLAGS += -Wa,-mregnames -I test/lib
+CFLAGS += -ffreestanding
cstart := test/powerpc/cstart.o
@@ -7,7 +8,6 @@ cflatobjs += \
test/lib/powerpc/io.o
$(libcflat): LDFLAGS += -nostdlib
-$(libcflat): CFLAGS += -ffreestanding
# these tests do not use libcflat
simpletests := \
@@ -17,7 +17,8 @@ simpletests := \
# theses tests use cstart.o, libcflat, and libgcc
tests := \
- test/powerpc/exit.bin
+ test/powerpc/exit.bin \
+ test/powerpc/helloworld.bin
include config-powerpc-$(PROCESSOR).mak
diff -r bdd5682d28d5 -r 1a74ac23ff60 user/test/powerpc/helloworld.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/user/test/powerpc/helloworld.cFri Nov 14 10:53:36 2008 -0600
@@ -0,0 +1,27 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation;
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * Authors: Deepa Srinivasan [EMAIL PROTECTED]
+ */
+
+#include libcflat.h
+
+int main()
+{
+ printf(Hello world\n);
+
+ return 1;
+}
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2 of 2] [PATCH] kvm-userspace: ppc: Fix for guest load address
# HG changeset patch
# User Deepa Srinivasan [EMAIL PROTECTED]
# Date 1226682073 21600
# Node ID c7f077a848cb4e80704450397f2f9bb300b9ee20
# Parent d175d293f2bff5bf882ef45286c973c094cfed1e
[PATCH] kvm-userspace: ppc: Fix for guest load address
From: Deepa Srinivasan [EMAIL PROTECTED]
Fix to ensure that guest test code is loaded at 1 MB.
Signed-off-by: Deepa Srinivasan [EMAIL PROTECTED]
---
[diffstat]
main-ppc.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
[diff]
diff -r d175d293f2bf -r c7f077a848cb user/main-ppc.c
--- a/user/main-ppc.c Fri Nov 14 10:54:11 2008 -0600
+++ b/user/main-ppc.c Fri Nov 14 11:01:13 2008 -0600
@@ -62,6 +62,9 @@ struct vcpu_info {
};
struct vcpu_info *vcpus;
+
+/* Load the guest binary at 1 MB since the flat.lds linker script sets the
base address to this value. */
+#define VM_TEST_LOAD_ADDRESS0x10
static int test_debug(void *opaque, int vcpu)
{
@@ -241,9 +244,13 @@ static void *do_create_vcpu(void *_n)
static void *do_create_vcpu(void *_n)
{
int n = (long)_n;
+ struct kvm_regs regs;
kvm_create_vcpu(kvm, n);
init_vcpu(n);
+ kvm_get_regs(kvm, n, regs);
+ regs.pc = VM_TEST_LOAD_ADDRESS;
+ kvm_set_regs(kvm, n, regs);
kvm_run(kvm, n);
sem_post(exited_sem);
return NULL;
@@ -364,8 +371,8 @@ int main(int argc, char **argv)
vm_mem = kvm_create_phys_mem(kvm, 0, memory_size, 0, 1);
- len = load_file(vm_mem, argv[optind], 1);
- sync_caches(vm_mem, len);
+ len = load_file(vm_mem + VM_TEST_LOAD_ADDRESS, argv[optind], 1);
+ sync_caches(vm_mem + VM_TEST_LOAD_ADDRESS, len);
io_table_register(mmio_table, 0xf000, 64, mmio_handler, NULL);
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qemu: Fix incorrect zlib check error
# HG changeset patch
# User Deepa Srinivasan [EMAIL PROTECTED]
# Date 1226685276 21600
# Node ID ae59be00a22c4769a1116943ca5e07cec9154de0
# Parent 1a74ac23ff60cc2ab052072243dc4ff47faf5849
qemu: Fix incorrect zlib check error
From: Deepa Srinivasan [EMAIL PROTECTED]
Include the CFLAGS and LDFLAGS variables in the check for zlib. When
cross-compiling
for PowerPC, the path for zlib headers and libraries are passed in the CFLAGS
and LDFLAGS respectively. While this patch fixes only the check for zlib,
this issue potentially affects other configure tests as well.
Signed-off-by: Deepa Srinivasan [EMAIL PROTECTED]
---
[diffstat]
configure |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[diff]
diff -r 1a74ac23ff60 -r ae59be00a22c qemu/configure
--- a/qemu/configureFri Nov 14 10:53:36 2008 -0600
+++ b/qemu/configureFri Nov 14 11:54:36 2008 -0600
@@ -798,7 +798,7 @@ cat $TMPC EOF
#include zlib.h
int main(void) { zlibVersion(); return 0; }
EOF
-if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC -lz 2 /dev/null ; then
+if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $CFLAGS $LDFLAGS $TMPC -lz 2
/dev/null ; then
:
else
echo
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1 of 2] [PATCH] kvm-userspace: ppc: Add hello world test for libcflat
On Fri, 2008-11-14 at 11:36 -0600, Deepa Srinivasan wrote: # HG changeset patch # User Deepa Srinivasan [EMAIL PROTECTED] # Date 1226681616 21600 # Node ID 1a74ac23ff60cc2ab052072243dc4ff47faf5849 # Parent bdd5682d28d56e62c93a795465eb3625713a3885 [PATCH] kvm-userspace: ppc: Add hello world test for libcflat From: Deepa Srinivasan [EMAIL PROTECTED] Add a test program (hello world) to exercise printf() in libcflat. Also, include -ffreestanding in the compiler options to avoid any checks for built-in functions. Signed-off-by: Deepa Srinivasan [EMAIL PROTECTED] Looks good Deepa, but as you described above, this really is two separate patches. Could you submit the -ffreestanding patch separately from the helloworld patch? -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
