Re: qcow2 corruption observed, fixed by reverting old change
I tested kvm-81 and kvm-83 as well (can't test kvm-80 or older because of the qcow2 performance regression caused by the default writethrough caching policy) but it randomly triggers an even worse bug: the moment I shut down a guest by typing quit in the monitor, it sometimes overwrite the first 4kB of the disk image with mostly NUL bytes (!) which completely destroys it. I am familiar with the qcow2 format and apparently this 4kB block seems to be an L2 table with most entries set to zero. I have had to restore at least 6 or 7 disk images from backup after occurences of that bug. My intuition tells me this may be the qcow2 code trying to allocate a cluster to write a new L2 table, but not noticing the allocation failed (represented by a 0 offset), and writing the L2 table at that 0 offset, overwriting the qcow2 header. Fortunately this bug is also fixed by running kvm-75 with block-qcow2.c reverted to its kvm-72 version. Basically qcow2 in kvm-73 or newer is completely unreliable. -marc I think the corruption is a completely unrelated bug. I would suspect it was introduced in one of Gleb's patches in December. Adding him to CC. I am not able to reproduce this. After more then hundred boot linux; generate disk io; quit loops all I've got is an image with 7 leaked blocks and couple of filesystem corruptions that were fixed by fsck. -- Gleb. -- 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: qcow2 corruption observed, fixed by reverting old change
On Sun, Feb 15, 2009 at 2:57 AM, Gleb Natapov g...@redhat.com wrote: I am not able to reproduce this. After more then hundred boot linux; generate disk io; quit loops all I've got is an image with 7 leaked blocks and couple of filesystem corruptions that were fixed by fsck. The type of activity occuring in the guest is most likely an important factor determining the probability of the bug occuring. So you should try running guest OSes I remember having been affected by it: Windows 2003 SP2 x64. And now that I think about it, I don't recall any other guest OS having been a victim of that bug... coincidence ? Other factors you might consider when trying to reproduce: the qcow2 images that ended up being corrupted had a backing file (a read-only qcow2 image); NPT was in use; the host filesystem was xfs; my command line was: $ qemu-system-x86_64 -name xxx -monitor stdio -vnc xxx:xxx -hda hda -net nic,macaddr=xx:xx:xx:xx:xx:xx,model=rtl8139 -net tap -boot c -cdrom -cpu qemu64 -m 1024 -usbdevice tablet -marc -- 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: qcow2 corruption observed, fixed by reverting old change
On Sun, Feb 15, 2009 at 3:46 AM, Marc Bevand m.bev...@gmail.com wrote: Other factors you might consider when trying to reproduce: [...] And the probability of that bug occuring seems less than 1% (I only witnessed 6 or 7 occurences out of about a thousand shutdown events). Also, contrary to what I said I am *not* sure whether the quit monitor command was used or not. Instead the guests may have been using ACPI to shut themselves down. -marc -- 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
Biweekly KVM Test report, kernel 48aa74... userspace a1efe3...
Hi All, This is our Weekly KVM Testing Report against lastest kvm.git 48aa74b80e1dbef32f756104a9f5a18f58429c25 and kvm-userspace.git a1efe3d681ccd3ae75870b9bd639ae8ee2625e7e. There is no new issue found in this two weeks. Five Old Issues: 1. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 2. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 3. OpenSuse10.2 can not be installed http://sourceforge.net/tracker/index.php?func=detailaid=2088475group_id=180599atid=893831 4. Fail to Save Restore Guest https://sourceforge.net/tracker/?func=detailatid=893831aid=2175042group_id=180599 5. hotplug inexistent device will kill guest https://sourceforge.net/tracker/index.php?func=detailaid=2432316group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G' Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 8 7 1 00 gtest 16 16 0 00 = control_panel 8 7 1 00 :KVM_256M_guest_PAE_gPAE 1 1 0 00 :KVM_linux_win_PAE_gPAE1 1 0 00 :KVM_two_winxp_PAE_gPAE1 1 0 00 :KVM_four_sguest_PAE_gPA 1 1 0 00 :KVM_1500M_guest_PAE_gPA 1 1 0 00 :KVM_LM_Continuity_PAE_g 1 1 0 00 :KVM_LM_SMP_PAE_gPAE 1 1 0 00 :KVM_SR_Continuity_PAE_g 1 0 1 00 gtest 16 16 0 00 :ltp_nightly_PAE_gPAE 1 1 0 00 :boot_up_acpi_PAE_gPAE 1 1 0 00 :boot_up_acpi_xp_PAE_gPA 1 1 0 00 :boot_up_vista_PAE_gPAE1 1 0 00 :reboot_xp_PAE_gPAE1 1 0 00 :boot_base_kernel_PAE_gP 1 1 0 00 :boot_up_acpi_win2k3_PAE 1 1 0 00 :boot_smp_acpi_win2k3_PA 1 1 0 00 :boot_smp_acpi_win2k_PAE 1 1 0 00 :boot_up_win2008_PAE_gPA 1 1 0 00 :boot_up_acpi_win2k_PAE_ 1 1 0 00 :boot_smp_acpi_xp_PAE_gP 1 1 0 00 :boot_up_noacpi_win2k_PA 1 1 0 00 :boot_smp_vista_PAE_gPAE 1 1 0 00 :boot_smp_win2008_PAE_gP 1 1 0 00 :kb_nightly_PAE_gPAE 1 1 0 00 = Total 24 23 1 00 Report Summary on IA32e Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 14 3 00 gtest 23 23 0 00 = control_panel 17 14 3 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 0 1 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 0 1 00 :KVM_LM_Continuity_64_g3 1 1 0 00 :KVM_1500M_guest_64_gPAE 1 1 0 00 :KVM_LM_Continuity_64_gP 1 1 0 00 :KVM_1500M_guest_64_g32e 1 1 0 00 :KVM_SR_Continuity_64_g3 1 0 1 00 :KVM_two_winxp_64_gPAE 1 1 0 00 :KVM_256M_guest_64_gPAE1 1 0 0
[ kvm-Bugs-2088475 ] OpenSuse10.2 can not be installed
Bugs item #2088475, was opened at 2008-09-02 11:37 Message generated for change (Comment added) made by technologov You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2088475group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: OpenSuse10.2 can not be installed Initial Comment: OpenSuse10.2 can not be installed on KVM. Installer will stop after loading ISOLinux. It is against latest kvm comit, kvm.git :5b9207ec01681337786c7898ffc0165ec4e7c2e4 userspace.git :5f2a9719f105e29fbde4529cf919a5351b05da9a. -- Comment By: Technologov (technologov) Date: 2009-02-15 15:21 Message: Closed as duplicate of: [ 1760424 ] Intel real mode emulation failures https://sourceforge.net/tracker/index.php?func=detailaid=1760424group_id=180599atid=893831 -- Comment By: Technologov (technologov) Date: 2008-12-02 16:06 Message: BTW: If you absolutely _must_ have openSUSE 10.2 there are workarounds that allow you to install it anyway. 1. Install 10.2 using Qemu, then disable bootloader -or- 2. Start VM, and press-n-hold shift during KVM's BIOS load. -- Comment By: Technologov (technologov) Date: 2008-12-02 15:58 Message: It crashed with old KVMs, but with newer it just stucks. Doesn't matters. And yes, openSUSE 11.0 tested to work. -- Comment By: Jiajun Xu (jiajun) Date: 2008-10-16 17:23 Message: From the bug description, opensuse11.0 should work? And we did not meet guest crash when installation, guest hangs when loading grub and no any error messages printed. -- Comment By: Technologov (technologov) Date: 2008-10-16 17:04 Message: Known issue: https://sourceforge.net/tracker/index.php?func=detailaid=1760424group_id=180599atid=893831 This bug is duplicate. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2088475group_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: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter
The callback you suggest for devices requesting an inbound filter will infinite-loop when there's two such devices on the same vlan bus, because each time the callback is called, that device will re-issue its filter request which triggers the callback on the other similar device. Back and forth. To avoid the infinite loop, the vlan code in the middle (if that's where you want it, and I agree) has to distinguish between no inbound filters requested by attached devices, and multiple incompatible inbound filters requested by attached devices. Of course. As I've said repeatedly, the only sane way to implement this is if you isolate individual devices from this kind of implementation detail. If you're API doesn't do that then it's wrong. Paul -- 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: Running KVM on a Laptop
Jorge Lucángeli Obes wrote: On Thu, Feb 12, 2009 at 11:56 PM, Ross McKay ro...@zeta.org.au wrote: dnjap wrote: I'm looking for a laptop on which I can run KVM. 1. Does anyone have a list of AMD-V or VT-x capable laptop CPU's? http://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors A handy reference link is http://www.intel.com/products/processor_number/index.htm I use this link a lot cross-referencing features of various processors. As for a laptop example, I just acquired a Dell Latitude E6500 with a Core 2 Duo T9550 @ 2.66GHz. The link for Core 2 Duo is: http://www.intel.com/products/processor_number/chart/core2duo.htm?iid=pn_ov+list_c2d which shows it has VT capability (which of course I confirmed before ordering this laptop). The header before each chart lists which processors have VT-x. Something similar must be available for the laptop version of Intel's Nehalem and for AMD. Is it not as simple as checking for the svm or vt flags? egrep '(vt|svm)' /proc/cpuinfo Take a bootable LiveCD into your local computer shop and check. 2. It seems Turion 64 X2 and some of Core 2 Duo processors can run KVM. Does anyone know which of these CPU's implement Nested Page Tables or Extended Page Tables? (Xen's compatibility list doesn't provide such details: http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors) You will probably have to verify that in the manufacturer's web site. I recall a discussion not long ago regarding the addition of NPT and EPT to /proc/cpuinfo. As I understand it you want a laptop with a Core i7 processor to get EPT. I am not as familiar with AMD's offerings. I did not see the Core i7 offered on Dell laptops as of late January. 3. If you're running KVM on your laptop, could you share the information? Does your laptop's BIOS support AMD-V or VT-x? FWIW, I have KVM running on my ASUS laptop, with the following CPU: AMD Athlon(tm) 64 X2 Dual-Core Processor TK-55 I have a Dell XPS 1210 with: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz As I mentioned above I have Dell Latitude E6500 with a Core 2 Duo T9550 @ 2.66GHz. So far (one whole week) I have not had any kvm related problems (the intel_drv xorg module is a different matter), and the performance has been nice. david Regards, Jorge -- 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 -- 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-2525768 ] kvm image corruption
Bugs item #2525768, was opened at 2009-01-21 16:03 Message generated for change (Comment added) made by danv You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2525768group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel van Vugt (danv) Assigned to: Nobody/Anonymous (nobody) Summary: kvm image corruption Initial Comment: Creating a new bug from my original problems detailed in bug 2490866, because that technically is a different problem. Reproduced with kvm-83 and kvm-82 vanilla. Host: Ubuntu 8.04 amd64, Intel Q6600 Guests: Windows 2003 Server, Windows 7 beta at least. After shutting down the guest cleanly, it's image file is (often but not always) corrupt and unbootable. A fact confirmed by the change in information reported by qemu-img info Example 1 (qcow2 image): $ qemu-img info windows7beta.qcow2 image: windows7beta.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 5.0G cluster_size: 4096 Snapshot list: ID TAG VM SIZE DATE VM CLOCK 1 Fresh_install 1.3M 2009-01-09 15:34:31 00:00:00.000 2 Activated_kvm-82 1.3M 2009-01-09 15:43:27 00:00:00.000 $ qemu -m 512 -usbdevice tablet -redir tcp:3389::3389 windows7beta.qcow2 (use and then shut down windows) $ qemu-img info windows7beta.qcow2 image: windows7beta.qcow2 file format: raw INVALID virtual size: 5.0G (5353566208 bytes) - INVALID disk size: 5.0G $ qemu -m 512 -usbdevice tablet -redir tcp:3389::3389 windows7beta.qcow2 -S (qemu) info snapshots Snapshot devices: ide0-hd0 bdrv_snapshot_list: error -95 (And the image won't boot) Example 2 (raw image converted from Example 1): $ qemu-img info windows7beta.raw image: windows7beta.raw file format: raw virtual size: 20G (21474836480 bytes) disk size: 4.7G (Install and test lots on the guest) $ qemu-img info windows7beta.raw image: windows7beta.raw file format: raw virtual size: 7.5G (8049315840 bytes) - INVALID disk size: 7.5G (And now the image won't boot) -- Comment By: Daniel van Vugt (danv) Date: 2009-02-16 11:16 Message: Confirmed the bug is still present in kvm-84. Just booting up my guest, opening the browser and then shutting down turns the qcow2 image into a corrupt unbootable raw image file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2525768group_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 1/3] KVM: Ioctls for init MSI-X entry
Introduce KVM_SET_MSIX_NR and KVM_SET_MSIX_ENTRY two ioctls.
This two ioctls are used by userspace to specific guest device MSI-X entry
number and correlate MSI-X entry with GSI during the initialization stage.
MSI-X should be well initialzed before enabling.
Don't support change MSI-X entry number for now.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
include/linux/kvm.h | 16 +++
include/linux/kvm_host.h |3 +
virt/kvm/kvm_main.c | 103 ++
3 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 2163b3d..a2dfbe0 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -475,6 +475,8 @@ struct kvm_irq_routing {
#define KVM_ASSIGN_IRQ _IOR(KVMIO, 0x70, \
struct kvm_assigned_irq)
#define KVM_REINJECT_CONTROL _IO(KVMIO, 0x71)
+#define KVM_SET_MSIX_NR _IOR(KVMIO, 0x72, struct kvm_assigned_msix_nr)
+#define KVM_SET_MSIX_ENTRY _IOR(KVMIO, 0x73, struct kvm_assigned_msix_entry)
/*
* ioctls for vcpu fds
@@ -595,4 +597,18 @@ struct kvm_assigned_irq {
#define KVM_DEV_IRQ_ASSIGN_MSI_ACTION KVM_DEV_IRQ_ASSIGN_ENABLE_MSI
#define KVM_DEV_IRQ_ASSIGN_ENABLE_MSI (1 0)
+struct kvm_assigned_msix_nr {
+ __u32 assigned_dev_id;
+ __u16 entry_nr;
+ __u16 padding;
+};
+
+#define KVM_MAX_MSIX_PER_DEV 512
+struct kvm_assigned_msix_entry {
+ __u32 assigned_dev_id;
+ __u32 gsi;
+ __u16 entry; /* The index of entry in the MSI-X table */
+ __u16 padding[3];
+};
+
#endif
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 7c7096d..ac4d63c 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -326,9 +326,12 @@ struct kvm_assigned_dev_kernel {
int assigned_dev_id;
int host_busnr;
int host_devfn;
+ int entries_nr;
int host_irq;
bool host_irq_disabled;
+ struct msix_entry *host_msix_entries;
int guest_irq;
+ struct msix_entry *guest_msix_entries;
#define KVM_ASSIGNED_DEV_GUEST_INTX(1 0)
#define KVM_ASSIGNED_DEV_GUEST_MSI (1 1)
#define KVM_ASSIGNED_DEV_HOST_INTX (1 8)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 266bdaf..08d5372 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1593,6 +1593,87 @@ static int kvm_vcpu_ioctl_set_sigmask(struct kvm_vcpu
*vcpu, sigset_t *sigset)
return 0;
}
+static int kvm_vm_ioctl_set_msix_nr(struct kvm *kvm,
+ struct kvm_assigned_msix_nr *entry_nr)
+{
+ int r = 0;
+ struct kvm_assigned_dev_kernel *adev;
+
+ mutex_lock(kvm-lock);
+
+ adev = kvm_find_assigned_dev(kvm-arch.assigned_dev_head,
+ entry_nr-assigned_dev_id);
+ if (!adev) {
+ r = -EINVAL;
+ goto msix_nr_out;
+ }
+
+ if (adev-entries_nr == 0) {
+ adev-entries_nr = entry_nr-entry_nr;
+ if (adev-entries_nr == 0 ||
+ adev-entries_nr = KVM_MAX_MSIX_PER_DEV)
+ goto msix_nr_out;
+
+ adev-host_msix_entries = kzalloc(sizeof(struct msix_entry) *
+ entry_nr-entry_nr,
+ GFP_KERNEL);
+ if (!adev-host_msix_entries) {
+ printk(KERN_ERR no memory for host msix entries!\n);
+ r = -ENOMEM;
+ goto msix_nr_out;
+ }
+ adev-guest_msix_entries = kzalloc(sizeof(struct msix_entry) *
+ entry_nr-entry_nr,
+ GFP_KERNEL);
+ if (!adev-guest_msix_entries) {
+ printk(KERN_ERR no memory for host msix entries!\n);
+ free(adev-host_msix_entries);
+ r = -ENOMEM;
+ goto msix_nr_out;
+ }
+ } else
+ printk(KERN_WARNING kvm: not allow recall set msix nr!\n);
+msix_nr_out:
+ mutex_unlock(kvm-lock);
+ return r;
+}
+
+static int kvm_vm_ioctl_set_msix_entry(struct kvm *kvm,
+ struct kvm_assigned_msix_entry *entry)
+{
+ int r = 0, i;
+ struct kvm_assigned_dev_kernel *adev;
+
+ mutex_lock(kvm-lock);
+
+ adev = kvm_find_assigned_dev(kvm-arch.assigned_dev_head,
+ entry-assigned_dev_id);
+
+ if (!adev) {
+ r = -EINVAL;
+ goto msix_entry_out;
+ }
+
+ for (i = 0; i adev-entries_nr; i++)
+ if (adev-guest_msix_entries[i].vector == 0 ||
+ adev-guest_msix_entries[i].entry == entry-entry) {
+ adev-guest_msix_entries[i].entry = entry-entry;
+
[PATCH 1/3] KVM: Ioctls for init MSI-X entry
(oops... fix a typo)
Introduce KVM_SET_MSIX_NR and KVM_SET_MSIX_ENTRY two ioctls.
This two ioctls are used by userspace to specific guest device MSI-X entry
number and correlate MSI-X entry with GSI during the initialization stage.
MSI-X should be well initialzed before enabling.
Don't support change MSI-X entry number for now.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
include/linux/kvm.h | 16 +++
include/linux/kvm_host.h |3 +
virt/kvm/kvm_main.c | 103 ++
3 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 2163b3d..a2dfbe0 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -475,6 +475,8 @@ struct kvm_irq_routing {
#define KVM_ASSIGN_IRQ _IOR(KVMIO, 0x70, \
struct kvm_assigned_irq)
#define KVM_REINJECT_CONTROL _IO(KVMIO, 0x71)
+#define KVM_SET_MSIX_NR _IOR(KVMIO, 0x72, struct kvm_assigned_msix_nr)
+#define KVM_SET_MSIX_ENTRY _IOR(KVMIO, 0x73, struct kvm_assigned_msix_entry)
/*
* ioctls for vcpu fds
@@ -595,4 +597,18 @@ struct kvm_assigned_irq {
#define KVM_DEV_IRQ_ASSIGN_MSI_ACTION KVM_DEV_IRQ_ASSIGN_ENABLE_MSI
#define KVM_DEV_IRQ_ASSIGN_ENABLE_MSI (1 0)
+struct kvm_assigned_msix_nr {
+ __u32 assigned_dev_id;
+ __u16 entry_nr;
+ __u16 padding;
+};
+
+#define KVM_MAX_MSIX_PER_DEV 512
+struct kvm_assigned_msix_entry {
+ __u32 assigned_dev_id;
+ __u32 gsi;
+ __u16 entry; /* The index of entry in the MSI-X table */
+ __u16 padding[3];
+};
+
#endif
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 7c7096d..ac4d63c 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -326,9 +326,12 @@ struct kvm_assigned_dev_kernel {
int assigned_dev_id;
int host_busnr;
int host_devfn;
+ int entries_nr;
int host_irq;
bool host_irq_disabled;
+ struct msix_entry *host_msix_entries;
int guest_irq;
+ struct msix_entry *guest_msix_entries;
#define KVM_ASSIGNED_DEV_GUEST_INTX(1 0)
#define KVM_ASSIGNED_DEV_GUEST_MSI (1 1)
#define KVM_ASSIGNED_DEV_HOST_INTX (1 8)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 266bdaf..bb4aa73 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1593,6 +1593,87 @@ static int kvm_vcpu_ioctl_set_sigmask(struct kvm_vcpu
*vcpu, sigset_t *sigset)
return 0;
}
+static int kvm_vm_ioctl_set_msix_nr(struct kvm *kvm,
+ struct kvm_assigned_msix_nr *entry_nr)
+{
+ int r = 0;
+ struct kvm_assigned_dev_kernel *adev;
+
+ mutex_lock(kvm-lock);
+
+ adev = kvm_find_assigned_dev(kvm-arch.assigned_dev_head,
+ entry_nr-assigned_dev_id);
+ if (!adev) {
+ r = -EINVAL;
+ goto msix_nr_out;
+ }
+
+ if (adev-entries_nr == 0) {
+ adev-entries_nr = entry_nr-entry_nr;
+ if (adev-entries_nr == 0 ||
+ adev-entries_nr = KVM_MAX_MSIX_PER_DEV)
+ goto msix_nr_out;
+
+ adev-host_msix_entries = kzalloc(sizeof(struct msix_entry) *
+ entry_nr-entry_nr,
+ GFP_KERNEL);
+ if (!adev-host_msix_entries) {
+ printk(KERN_ERR no memory for host msix entries!\n);
+ r = -ENOMEM;
+ goto msix_nr_out;
+ }
+ adev-guest_msix_entries = kzalloc(sizeof(struct msix_entry) *
+ entry_nr-entry_nr,
+ GFP_KERNEL);
+ if (!adev-guest_msix_entries) {
+ printk(KERN_ERR no memory for host msix entries!\n);
+ kfree(adev-host_msix_entries);
+ r = -ENOMEM;
+ goto msix_nr_out;
+ }
+ } else
+ printk(KERN_WARNING kvm: not allow recall set msix nr!\n);
+msix_nr_out:
+ mutex_unlock(kvm-lock);
+ return r;
+}
+
+static int kvm_vm_ioctl_set_msix_entry(struct kvm *kvm,
+ struct kvm_assigned_msix_entry *entry)
+{
+ int r = 0, i;
+ struct kvm_assigned_dev_kernel *adev;
+
+ mutex_lock(kvm-lock);
+
+ adev = kvm_find_assigned_dev(kvm-arch.assigned_dev_head,
+ entry-assigned_dev_id);
+
+ if (!adev) {
+ r = -EINVAL;
+ goto msix_entry_out;
+ }
+
+ for (i = 0; i adev-entries_nr; i++)
+ if (adev-guest_msix_entries[i].vector == 0 ||
+ adev-guest_msix_entries[i].entry == entry-entry) {
+ adev-guest_msix_entries[i].entry = entry-entry;
+
[PATCH 02/02] kvm: ia64: Fix the build errors due to lack of macros related to MSI.
From fb2e7473e44b6b0bcc8448d4f74a4f8d43e7fa4c Mon Sep 17 00:00:00 2001
From: Xiantao Zhang xiantao.zh...@intel.com
Date: Mon, 16 Feb 2009 15:24:05 +0800
Subject: [PATCH] kvm: ia64: Fix the build errors due to lack of macros related
to MSI.
Include the newly introduced msidef.h to solve the build issues.
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
---
arch/ia64/kvm/irq.h |2 ++
virt/kvm/irq_comm.c |2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kvm/irq.h b/arch/ia64/kvm/irq.h
index c6786e8..c0785a7 100644
--- a/arch/ia64/kvm/irq.h
+++ b/arch/ia64/kvm/irq.h
@@ -23,6 +23,8 @@
#ifndef __IRQ_H
#define __IRQ_H
+#include lapic.h
+
static inline int irqchip_in_kernel(struct kvm *kvm)
{
return 1;
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index 6bc7439..a6433bd 100644
--- a/virt/kvm/irq_comm.c
+++ b/virt/kvm/irq_comm.c
@@ -21,9 +21,7 @@
#include linux/kvm_host.h
-#ifdef CONFIG_X86
#include asm/msidef.h
-#endif
#include irq.h
--
1.6.0
0002-kvm-ia64-Fix-the-build-errors-due-to-lack-of-macro.patch
Description: 0002-kvm-ia64-Fix-the-build-errors-due-to-lack-of-macro.patch
[PATCH 01/02] ia64: Move the macro definitions related to MSI to one header file.
Hi, Tony For supporting kvm's MSI, we have to move some macros from ia64_msi.c out to avoide duplicate them. In addition, to keep them consistent with x86's , I also changed some macros' name. How do you think of the patch ? If you agree to the changes, could you add your Sign-off-by to the patch, and Avi may check-in it to kvm.git first to fix an emergent build issue for kvm/ia64. Thanks! Xiantao From 73f06500b94b8d386548d81e999ad019d205 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang xiantao.zh...@intel.com Date: Mon, 16 Feb 2009 15:14:48 +0800 Subject: [PATCH] ia64: Move the macro definitions related to MSI to one header file. For kvm's MSI support, it needs these macros defined in ia64_msi.c, and to avoid duplicate them, move them to one header file and share with kvm. Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com --- arch/ia64/include/asm/msidef.h | 42 ++ arch/ia64/kernel/msi_ia64.c| 55 ++- 2 files changed, 51 insertions(+), 46 deletions(-) create mode 100644 arch/ia64/include/asm/msidef.h diff --git a/arch/ia64/include/asm/msidef.h b/arch/ia64/include/asm/msidef.h new file mode 100644 index 000..b71b211 --- /dev/null +++ b/arch/ia64/include/asm/msidef.h @@ -0,0 +1,42 @@ +#ifndef _IA64_MSI_DEF_H +#define _IA64_MSI_DEF_H + +/* + * Shifts for APIC-based data + */ + +#define MSI_DATA_VECTOR_SHIFT 0 +#defineMSI_DATA_VECTOR(v) (((u8)v) MSI_DATA_VECTOR_SHIFT) +#define MSI_DATA_VECTOR_MASK 0xff00 + +#define MSI_DATA_DELIVERY_MODE_SHIFT 8 +#define MSI_DATA_DELIVERY_FIXED(0 MSI_DATA_DELIVERY_MODE_SHIFT) +#define MSI_DATA_DELIVERY_LOWPRI (1 MSI_DATA_DELIVERY_MODE_SHIFT) + +#define MSI_DATA_LEVEL_SHIFT 14 +#define MSI_DATA_LEVEL_DEASSERT(0 MSI_DATA_LEVEL_SHIFT) +#define MSI_DATA_LEVEL_ASSERT (1 MSI_DATA_LEVEL_SHIFT) + +#define MSI_DATA_TRIGGER_SHIFT 15 +#define MSI_DATA_TRIGGER_EDGE (0 MSI_DATA_TRIGGER_SHIFT) +#define MSI_DATA_TRIGGER_LEVEL (1 MSI_DATA_TRIGGER_SHIFT) + +/* + * Shift/mask fields for APIC-based bus address + */ + +#define MSI_ADDR_DEST_ID_SHIFT 4 +#define MSI_ADDR_HEADER0xfee0 + +#define MSI_ADDR_DEST_ID_MASK 0xffff +#define MSI_ADDR_DEST_ID_CPU(cpu) ((cpu) MSI_ADDR_DEST_ID_SHIFT) + +#define MSI_ADDR_DEST_MODE_SHIFT 2 +#define MSI_ADDR_DEST_MODE_PHYS(0 MSI_ADDR_DEST_MODE_SHIFT) +#defineMSI_ADDR_DEST_MODE_LOGIC(1 MSI_ADDR_DEST_MODE_SHIFT) + +#define MSI_ADDR_REDIRECTION_SHIFT 3 +#define MSI_ADDR_REDIRECTION_CPU (0 MSI_ADDR_REDIRECTION_SHIFT) +#define MSI_ADDR_REDIRECTION_LOWPRI(1 MSI_ADDR_REDIRECTION_SHIFT) + +#endif/* _IA64_MSI_DEF_H */ diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c index 8903393..368ee4e 100644 --- a/arch/ia64/kernel/msi_ia64.c +++ b/arch/ia64/kernel/msi_ia64.c @@ -7,44 +7,7 @@ #include linux/msi.h #include linux/dmar.h #include asm/smp.h - -/* - * Shifts for APIC-based data - */ - -#define MSI_DATA_VECTOR_SHIFT 0 -#defineMSI_DATA_VECTOR(v) (((u8)v) MSI_DATA_VECTOR_SHIFT) -#define MSI_DATA_VECTOR_MASK 0xff00 - -#define MSI_DATA_DELIVERY_SHIFT8 -#define MSI_DATA_DELIVERY_FIXED(0 MSI_DATA_DELIVERY_SHIFT) -#define MSI_DATA_DELIVERY_LOWPRI (1 MSI_DATA_DELIVERY_SHIFT) - -#define MSI_DATA_LEVEL_SHIFT 14 -#define MSI_DATA_LEVEL_DEASSERT(0 MSI_DATA_LEVEL_SHIFT) -#define MSI_DATA_LEVEL_ASSERT (1 MSI_DATA_LEVEL_SHIFT) - -#define MSI_DATA_TRIGGER_SHIFT 15 -#define MSI_DATA_TRIGGER_EDGE (0 MSI_DATA_TRIGGER_SHIFT) -#define MSI_DATA_TRIGGER_LEVEL (1 MSI_DATA_TRIGGER_SHIFT) - -/* - * Shift/mask fields for APIC-based bus address - */ - -#define MSI_TARGET_CPU_SHIFT 4 -#define MSI_ADDR_HEADER0xfee0 - -#define MSI_ADDR_DESTID_MASK 0xffff -#define MSI_ADDR_DESTID_CPU(cpu) ((cpu) MSI_TARGET_CPU_SHIFT) - -#define MSI_ADDR_DESTMODE_SHIFT2 -#define MSI_ADDR_DESTMODE_PHYS (0 MSI_ADDR_DESTMODE_SHIFT) -#defineMSI_ADDR_DESTMODE_LOGIC (1 MSI_ADDR_DESTMODE_SHIFT) - -#define MSI_ADDR_REDIRECTION_SHIFT 3 -#define MSI_ADDR_REDIRECTION_CPU (0 MSI_ADDR_REDIRECTION_SHIFT) -#define MSI_ADDR_REDIRECTION_LOWPRI(1 MSI_ADDR_REDIRECTION_SHIFT) +#include asm/msidef.h static struct irq_chip ia64_msi_chip; @@ -65,8 +28,8 @@ static void ia64_set_msi_irq_affinity(unsigned int irq, read_msi_msg(irq, msg); addr = msg.address_lo; - addr = MSI_ADDR_DESTID_MASK; - addr |= MSI_ADDR_DESTID_CPU(cpu_physical_id(cpu)); + addr = MSI_ADDR_DEST_ID_MASK; + addr |= MSI_ADDR_DEST_ID_CPU(cpu_physical_id(cpu)); msg.address_lo = addr; data = msg.data; @@ -98,9 +61,9
