[PATCH] kvm: testsuite: add regression test for MSR_KERNEL_GS_BASE
From: Avi Kivity a...@redhat.com kvm used to read host values from this msr. Signed-off-by: Avi Kivity a...@redhat.com diff --git a/user/config-x86-common.mak b/user/config-x86-common.mak index 315091a..e789fd4 100644 --- a/user/config-x86-common.mak +++ b/user/config-x86-common.mak @@ -21,7 +21,7 @@ FLATLIBS = test/lib/libcflat.a $(libgcc) tests-common = $(TEST_DIR)/bootstrap \ $(TEST_DIR)/vmexit.flat $(TEST_DIR)/tsc.flat \ $(TEST_DIR)/smptest.flat $(TEST_DIR)/port80.flat \ - $(TEST_DIR)/realmode.flat + $(TEST_DIR)/realmode.flat $(TEST_DIR)/msr.flat test_cases: $(tests-common) $(tests) @@ -59,6 +59,8 @@ $(TEST_DIR)/realmode.flat: $(TEST_DIR)/realmode.o $(TEST_DIR)/realmode.o: bits = 32 +$(TEST_DIR)/msr.flat: $(cstart.o) $(TEST_DIR)/msr.o + arch_clean: $(RM) $(TEST_DIR)/bootstrap $(TEST_DIR)/*.o $(TEST_DIR)/*.flat \ $(TEST_DIR)/.*.d $(TEST_DIR)/lib/.*.d $(TEST_DIR)/lib/*.o diff --git a/user/test/x86/msr.c b/user/test/x86/msr.c new file mode 100644 index 000..5010ad0 --- /dev/null +++ b/user/test/x86/msr.c @@ -0,0 +1,50 @@ +/* msr tests */ + +#include libcflat.h + +#define MSR_KERNEL_GS_BASE 0xc102 /* SwapGS GS shadow */ + +int nr_passed, nr_tests; + +static void report(const char *name, int passed) +{ + ++nr_tests; + if (passed) + ++nr_passed; + printf(%s: %s\n, name, passed ? PASS : FAIL); +} + +static void wrmsr(unsigned index, unsigned long long value) +{ + asm volatile (wrmsr : : c(index), A(value)); +} + +static unsigned long long rdmsr(unsigned index) +{ + unsigned long long value; + + asm volatile (rdmsr : =A(value) : c(index)); + + return value; +} + +static void test_kernel_gs_base(void) +{ +#ifdef __x86_64__ + unsigned long long v1 = 0x123456789abcdef, v2; + + wrmsr(MSR_KERNEL_GS_BASE, v1); + v2 = rdmsr(MSR_KERNEL_GS_BASE); + report(MSR_KERNEL_GS_BASE, v1 == v2); +#endif +} + +int main(int ac, char **av) +{ + test_kernel_gs_base(); + + printf(%d tests, %d failures\n, nr_tests, nr_tests - nr_passed); + + return nr_passed == nr_tests ? 0 : 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] Fix hardware accelerated video to video copy on Cirrus VGA (Brian Kress)
From: aliguori aliguori cirrus_do_copy() in hw/cirrus_vga.c seems to make some incorrect assumptions about video memory layout. It tries to convert addresses to coordinates assuming that one row of data is (width * depth) bytes long. The correct way seems to be to use the pitch fields in the CirrusVGAState structure instead. Without this patch, I get lots of screen corruption when I try to drag a window under X as it's passing the wrong coordinates to the display surface for the copy. With this patch I can drag a window with no screen corruption. Signed-off-by: Brian Kress kre...@moose.net Signed-off-by: Anthony Liguori aligu...@us.ibm.com diff --git a/qemu/hw/cirrus_vga.c b/qemu/hw/cirrus_vga.c index 242..866954d 100644 --- a/qemu/hw/cirrus_vga.c +++ b/qemu/hw/cirrus_vga.c @@ -731,10 +731,10 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h) s-get_resolution((VGAState *)s, width, height); /* extra x, y */ -sx = (src % (width * depth)) / depth; -sy = (src / (width * depth)); -dx = (dst % (width *depth)) / depth; -dy = (dst / (width * depth)); +sx = (src % ABS(s-cirrus_blt_srcpitch)) / depth; +sy = (src / ABS(s-cirrus_blt_srcpitch)); +dx = (dst % ABS(s-cirrus_blt_dstpitch)) / depth; +dy = (dst / ABS(s-cirrus_blt_dstpitch)); /* normalize width */ w /= depth; -- 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] Merge branch 'qemu-cvs'
From: Avi Kivity a...@redhat.com Conflicts: qemu/Makefile.target qemu/hw/acpi.c qemu/hw/device-hotplug.c qemu/hw/ide.c qemu/hw/lsi53c895a.c qemu/hw/pc.c qemu/hw/pc.h qemu/hw/pci.c qemu/hw/pci.h qemu/hw/virtio-blk.c qemu/hw/virtio-net.c qemu/monitor.c qemu/net.c qemu/net.h qemu/pc-bios/bios.bin qemu/sysemu.h 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]remove some redundant args for ipf
Hi This patch remove some redundant args in function pci_vga_init(),isa_vga_init(), rtc_init() in ipf.c Please review it yang From 2a7c4cdf02c992da36f25bfe62ab1e4b0d9e3e91 Mon Sep 17 00:00:00 2001 From: Yang Zhang Yang Zhang Date: Mon, 16 Feb 2009 01:17:52 -0600 Subject: [PATCH] kvm : qemu: remove some redundant args of ipf remove redundant args of pci_vga_init(),isa_vga_init(), rtc_init() in ia64. Signed-off-by: Yang Zhang Yang Zhang --- kernel/ia64/hack-module.awk |1 + qemu/hw/ipf.c | 10 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/ia64/hack-module.awk b/kernel/ia64/hack-module.awk index d0ef130..2e4e05f 100644 --- a/kernel/ia64/hack-module.awk +++ b/kernel/ia64/hack-module.awk @@ -20,6 +20,7 @@ BEGIN { split(INIT_WORK on_each_cpu smp_call_function \ } /#include linux\/compiler.h/ { $0 = } +/#include linux\/types.h/ { $0 = #include asm/types.h } { sub(/linux\/mm_types\.h/, linux/mm.h) } diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c index a761d52..eb9aaec 100644 --- a/qemu/hw/ipf.c +++ b/qemu/hw/ipf.c @@ -514,23 +514,23 @@ static void ipf_init1(ram_addr_t ram_size, int vga_ram_size, if (cirrus_vga_enabled) { if (pci_enabled) { -pci_cirrus_vga_init(pci_bus, ds, phys_ram_base + vga_ram_addr, +pci_cirrus_vga_init(pci_bus, phys_ram_base + vga_ram_addr, vga_ram_addr, vga_ram_size); } else { -isa_cirrus_vga_init(ds, phys_ram_base + vga_ram_addr, +isa_cirrus_vga_init(phys_ram_base + vga_ram_addr, vga_ram_addr, vga_ram_size); } } else { if (pci_enabled) { -pci_vga_init(pci_bus, ds, phys_ram_base + vga_ram_addr, +pci_vga_init(pci_bus, phys_ram_base + vga_ram_addr, vga_ram_addr, vga_ram_size, 0, 0); } else { -isa_vga_init(ds, phys_ram_base + vga_ram_addr, +isa_vga_init(phys_ram_base + vga_ram_addr, vga_ram_addr, vga_ram_size); } } -rtc_state = rtc_init(0x70, i8259[8]); +rtc_state = rtc_init(0x70, i8259[8], 2000); if (pci_enabled) { pic_set_alt_irq_func(isa_pic, NULL, NULL); -- 1.6.0.rc1 0001-kvm-qemu-remove-some-redundant-args.patch Description: 0001-kvm-qemu-remove-some-redundant-args.patch
[PATCH] kvm: userspace: Get all cpuid values from function 2
cpuid function 2 can have multiple values to describe cache behaviour. Loop till we have fetched all the values. Signed-off-by: Amit Shah amit.s...@redhat.com --- qemu/qemu-kvm-x86.c | 27 +-- 1 files changed, 25 insertions(+), 2 deletions(-) diff --git a/qemu/qemu-kvm-x86.c b/qemu/qemu-kvm-x86.c index 5264015..9a175a8 100644 --- a/qemu/qemu-kvm-x86.c +++ b/qemu/qemu-kvm-x86.c @@ -538,7 +538,27 @@ int kvm_arch_qemu_init_env(CPUState *cenv) limit = copy.regs[R_EAX]; for (i = 0; i = limit; ++i) { -if (i == 4 || i == 0xb || i == 0xd) { +switch (i) { +case 2: { +/* Keep reading function 2 till all the input is received */ +int times; + +do_cpuid_ent(cpuid_ent[cpuid_nent], i, 0, copy); +times = cpuid_ent[cpuid_nent].eax 0xff; + +cpuid_ent[cpuid_nent].flags |= KVM_CPUID_FLAG_STATEFUL_FUNC; +cpuid_ent[cpuid_nent].flags |= KVM_CPUID_FLAG_STATE_READ_NEXT; + +for (j = 1; j times; ++j) { +do_cpuid_ent(cpuid_ent[++cpuid_nent], i, 0, copy); +cpuid_ent[cpuid_nent].flags |= KVM_CPUID_FLAG_STATEFUL_FUNC; +} +cpuid_nent++; +break; +} +case 4: +case 0xb: +case 0xd: for (j = 0; ; ++j) { do_cpuid_ent(cpuid_ent[cpuid_nent], i, j, copy); @@ -554,8 +574,11 @@ int kvm_arch_qemu_init_env(CPUState *cenv) if (i == 0xd copy.regs[R_EAX] == 0) break; } -} else +break; + +default: do_cpuid_ent(cpuid_ent[cpuid_nent++], i, 0, copy); +} } copy.regs[R_EAX] = 0x8000; -- 1.6.0.6 -- 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] qcow2 corruption observed, fixed by reverting old change
Jamie Lokier schrieb: Kevin Wolf wrote: Besides reviewing the code over and over again, I think the only real chance is that you can get a non-productive copy of your image and add some debug code so that we can see at least which code path is causing problems. I have a copy of my image to reproduce the bug, so I can test patches including diagnostic patches. That's what I did to narrow it down. Being a company mail server, I can't send you the image of course. I perfectly understand that, it just makes debugging hard when you don't have a specific suspicion nor the problematic image. Do you need those diagnostic patches from me or will you try to put debug messages into the code yourself? I would just start putting in random printfs into alloc_cluster_offset() and the functions it calls to get some information about the failing write. I guess we'd need some iterations with my diagnostic patch and it wouldn't be any better than ad-hoc hacks done by yourself. By the way and completely off-topic: Have you already tried to use the VHD patches? I would really like to know if they fix your problems. Are those patches in kvm-83? I still have the image that was causing problems way back, and I'm converting it to raw now with kvm-83 to see if it now matches the raw image produced by VPC's own tool. Avi mentioned the patches in the kvm-84 announcement yesterday, so it seems they are not in kvm-83. Kevin -- 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
Ross McKay 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? 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. Yes, this would be the ultimate test. AMD Turion X2 and Turion X2 Ultra are based on K8 and thus support SVM. Some vendors decided to disable SVM in the BIOS. On some of those machines it _cannot_ be enabled (both in the BIOS setup and later from the OS side). So although this machines are Turion X2 based you cannot use KVM here, but /proc/cpuinfo shouldn't show this flag in this case. Please note that AMD-CPUs labeled Sempron do not support SVM at all. 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) Currently there are no Nested Page Tables capable notebook processors from AMD, but the Turion X2 Ultra successor will be PhenomII based and thus support NPT. Look at the AMD roadmaps for a processor called Caspian. NPT is a CPUID bit in the SVM feature CPUID leaf (8000_000A, EDX:0). Recent versions of x86info can also decode this bit (x86info -v, line starting with SVM: and containing np). There are no known BIOS restrictions regarding to NPT nor the BIOS needs to handle NPT in a special way. 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? We use hardware virtualization on a MSI MegaBook S271 (TurionX2). Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 277-4917 to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 -- 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
On Fri, 13 Feb 2009 12:56:56 +1100, Ross McKay wrote: NB: don't use recent sources (post v80) if you want to run compressed qcow2 images, as you'll only get corruption. I was told on this list that QEMU has resolved the problem but that the patch hasn't been ported across to the KVM branch yet. As such, get a laptop with a *big* hard drive if you plan to run the latest versions. -- If you're playing with kvm-git, you should be able to pull these fixes in via cherry picking 16f197e29c19a4366a1d2ba3dcd0b4b8b0f86ce6, then 86030aade7ae09f4cedfb13973e37ba30f3db073. /B -- 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: [ANNOUNCE] kvm-84 release
Avi Kivity wrote: A long list of changes due to an unusually late release. As is becoming usual, many of the changes come from upstream qemu; the kvm specific changes are mostly bugfixes, but also include infrastructure intended for message-signalled interrupts (MSI). kvm-84 is slower when rendering fonts on Windows than kvm-83; we are still investigating why. Changes from kvm-83: - merge qemu-svn - redirect slirp traffic to qemu-char device - slirp fixes - qcow2 fixes Does this fix the qcow2 corruption issue reported on the list last week on this list? (qcow2 corruption observed, fixed by reverting old change) [snip] -- Randy Smith http://www.vuser.org/ http://perlstalker.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: Porting KVM to Mac OS?
On Sun, Jan 25, 2009 at 10:00 AM, Anthony Liguori anth...@codemonkey.ws wrote: Alexander Graf wrote: Hi, On 25.01.2009, at 09:16, Neo Jia wrote: hi, I am thinking if it is possible to port KVM to Mac OS (leopard). Is there anybody doing this already? I've considered doing it, but haven't gotten around to it, due to lack of inspiration. The biggest problem IMHO is the sync. Rewriting a kvm module for Mac OS X should be fairly easy, but you'll miss all the good bugfixes from upstream. Using the upstream code with a wrapper on the other hand is probably a really big hassle, because osx doesn't really know about mmu notifiers and a lot of other Linux internal things. Most of the special Linux internal things are optional when using the external kernel modules (in order to support older host kernels). If you rely on that, there shouldn't be a huge amount of Linux-specific dependencies. Best thing to do would be to avoid touching the KVM source code as much as humanly possible, and try to write a compatibility layer on top of the external kernel modules. You could even use awk trickery like make sync does. That way you can get bugfixes almost for free. Thanks! I am reviewing the possible interface wrapper solution now. But I just notice that the current leopard is 32-bit. Will this be a problem to run KVM as it always assume qemu-x86-64 bit? Thanks, Neo Regards, Anthony Liguori So if you come up with a good idea for this problem, I'd be glad to help you out as much as time permits :-). Alex If it is possible, which KVM release should I use as a start? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! -- 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 -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! -- 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: Porting KVM to Mac OS?
On 16.02.2009, at 19:01, Neo Jia neo...@gmail.com wrote: On Sun, Jan 25, 2009 at 10:00 AM, Anthony Liguori anth...@codemonkey.ws wrote: Alexander Graf wrote: Hi, On 25.01.2009, at 09:16, Neo Jia wrote: hi, I am thinking if it is possible to port KVM to Mac OS (leopard). Is there anybody doing this already? I've considered doing it, but haven't gotten around to it, due to lack of inspiration. The biggest problem IMHO is the sync. Rewriting a kvm module for Mac OS X should be fairly easy, but you'll miss all the good bugfixes from upstream. Using the upstream code with a wrapper on the other hand is probably a really big hassle, because osx doesn't really know about mmu notifiers and a lot of other Linux internal things. Most of the special Linux internal things are optional when using the external kernel modules (in order to support older host kernels). If you rely on that, there shouldn't be a huge amount of Linux-specific dependencies. Best thing to do would be to avoid touching the KVM source code as much as humanly possible, and try to write a compatibility layer on top of the external kernel modules. You could even use awk trickery like make sync does. That way you can get bugfixes almost for free. Thanks! I am reviewing the possible interface wrapper solution now. But I just notice that the current leopard is 32-bit. Will this be a problem to run KVM as it always assume qemu-x86-64 bit? The Linux kernel module does work on 32 bit systems too. But please keep everything 64-bit aware, as the 10.6 kernel will be available in x86_64 flavors. Alex Thanks, Neo Regards, Anthony Liguori So if you come up with a good idea for this problem, I'd be glad to help you out as much as time permits :-). Alex If it is possible, which KVM release should I use as a start? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! -- 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 -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! -- 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 on Via Nano (Isaiah) CPUs?
Has anyone (esp. the KVM core developers) tried to determine whether KVM works on the new Via Nano CPUs? They claim to support the Intel-style VT-x instruction set extensions and show up in cpuinfo that way. But, according to some Google searching, folks who have tried to use KVM (or Hyper-V) have not been succesful. It's not clear if this is a CPU implementation problem and/or something that needs more work in KVM. Has anyone tried this / debugged this? Thanks, -Craig -- 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
How is the -smb switch supposed to work?
Hi all, I've successfully installed KVM (version 83 with 2.6.28 kernel) and windows as guest. I start it with kvm -net nic,macaddr=46:0e:b3:53:9f:3a \ -net user -localtime -smb /home/horn \ ~/kvm/windows.img and basically it works fine. I have network access in the guest, performance is fine and every application I need seems to work well. The only thing which doesn't work is accessing my $HOME on the host from the guest. My $HOME is /home/horn and reading the kvm man page it seems clear that with that I should be able to access the dir using \\smbserver\qemu. I added the line 10.0.2.4 smbserver in the lmhosts file, too. But the connection always fails. Samba is installed on the host (/usr/sbin/smbd exists), CIFS support is in the kernel. But ps -e doesn't show a smbd process when the guest is started. I also tried starting smbd before starting the guest, but still no luck. When on the guest I can ping 10.0.2.2 but not 10.0.2.4. Reading the kvm man page I see that this is the built-in TFTP server, but why is it activated? I didn't specify -tftp dir on the command line... Does anyone know what I'm doing wrong? Or does someone know how to debug what's the problem? Thanks a lot for any pointers! Bye, Tassilo -- 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
Bryon Roche wrote: If you're playing with kvm-git, you should be able to pull these fixes in via cherry picking 16f197e29c19a4366a1d2ba3dcd0b4b8b0f86ce6, then 86030aade7ae09f4cedfb13973e37ba30f3db073. Thanks, but I have other problems at present so I'm just accepting source tarballs to build from. v80 is working fine for me, so I'm sticking with it for now. -- Ross McKay, Toronto, NSW Australia There is more to life than simply increasing its speed. - Gandhi -- 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: Ioctls for init MSI-X entry
On Mon, Feb 16, 2009 at 01:49:29PM +0800, Sheng Yang wrote: (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_ACTIONKVM_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 || = 0 ? + adev-entries_nr = KVM_MAX_MSIX_PER_DEV) Otherwise looks OK, thanks. -- 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] use KVM_UPSTREAM for ppc.
On 2/13/09, Glauber Costa glom...@redhat.com wrote: ppc should compile with upstream qemu code, so, put these defines in ppc specific code that references kvm functions. We don put them in config.h in this case, since there are files (like vl.c) that includes both kvm.h and qemu-kvm.h, and would break compilation. Ack. This patch is required for Ubuntu packaging of kvm-84. Otherwise, the compilation is broken. Thanks for this. :-Dustin -- 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] include qemu-kvm.h at all cases.
On 2/12/09, Glauber Costa glom...@redhat.com wrote: We don't have any kind of kvm support for linux-user targets, but conditionalizing the inclusion of kvm header make linux-user compilation break. And we don't have a reason to prevent that, do we? Ack, again, same problem here. The lack of inclusion of this header breaks the build of kvm-84 for the Ubuntu package. :-Dustin -- 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] qcow2 corruption observed, fixed by reverting old change
Kevin Wolf wrote: By the way and completely off-topic: Have you already tried to use the VHD patches? I would really like to know if they fix your problems. Are those patches in kvm-83? I still have the image that was causing problems way back, and I'm converting it to raw now with kvm-83 to see if it now matches the raw image produced by VPC's own tool. Avi mentioned the patches in the kvm-84 announcement yesterday, so it seems they are not in kvm-83. Ok. I did the conversion from VHD to raw with kvm-83-img convert and it gave a different result to MSVPC - i.e. wrong. I'll try it again sometime with kvm-84. -- Jamie -- 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: Ioctls for init MSI-X entry
On Tuesday 17 February 2009 07:23:23 Marcelo Tosatti wrote: On Mon, Feb 16, 2009 at 01:49:29PM +0800, Sheng Yang wrote: (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 || = 0 ? Oh, yeah, that's right. :) I would change the type of adev-entries_nr to unsigned int. -- regards Yang, Sheng + adev-entries_nr = KVM_MAX_MSIX_PER_DEV) Otherwise looks OK, thanks. -- 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..b105ada 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; + unsigned 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; +
RE: [PATCH]remove some redundant args for ipf
Avi, Please help to check-in this patch, and it breaks ia64's build. Xiantao -Original Message- From: Zhang, Yang Sent: Monday, February 16, 2009 4:31 PM To: kvm-i...@vger.kernel.org Cc: kvm@vger.kernel.org; Avi Kivity; Zhang, Xiantao Subject: [PATCH]remove some redundant args for ipf Hi This patch remove some redundant args in function pci_vga_init(),isa_vga_init(), rtc_init() in ipf.c Please review it yang From 2a7c4cdf02c992da36f25bfe62ab1e4b0d9e3e91 Mon Sep 17 00:00:00 2001 From: Yang Zhang Yang Zhang Date: Mon, 16 Feb 2009 01:17:52 -0600 Subject: [PATCH] kvm : qemu: remove some redundant args of ipf remove redundant args of pci_vga_init(),isa_vga_init(), rtc_init() in ia64. Signed-off-by: Yang Zhang Yang Zhang --- kernel/ia64/hack-module.awk |1 + qemu/hw/ipf.c | 10 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/ia64/hack-module.awk b/kernel/ia64/hack-module.awk index d0ef130..2e4e05f 100644 --- a/kernel/ia64/hack-module.awk +++ b/kernel/ia64/hack-module.awk @@ -20,6 +20,7 @@ BEGIN { split(INIT_WORK on_each_cpu smp_call_function \ } /#include linux\/compiler.h/ { $0 = } +/#include linux\/types.h/ { $0 = #include asm/types.h } { sub(/linux\/mm_types\.h/, linux/mm.h) } diff --git a/qemu/hw/ipf.c b/qemu/hw/ipf.c index a761d52..eb9aaec 100644 --- a/qemu/hw/ipf.c +++ b/qemu/hw/ipf.c @@ -514,23 +514,23 @@ static void ipf_init1(ram_addr_t ram_size, int vga_ram_size, if (cirrus_vga_enabled) { if (pci_enabled) { -pci_cirrus_vga_init(pci_bus, ds, phys_ram_base + vga_ram_addr, +pci_cirrus_vga_init(pci_bus, phys_ram_base + vga_ram_addr, vga_ram_addr, vga_ram_size); } else { -isa_cirrus_vga_init(ds, phys_ram_base + vga_ram_addr, +isa_cirrus_vga_init(phys_ram_base + vga_ram_addr, vga_ram_addr, vga_ram_size); } } else { if (pci_enabled) { -pci_vga_init(pci_bus, ds, phys_ram_base + vga_ram_addr, +pci_vga_init(pci_bus, phys_ram_base + vga_ram_addr, vga_ram_addr, vga_ram_size, 0, 0); } else { -isa_vga_init(ds, phys_ram_base + vga_ram_addr, +isa_vga_init(phys_ram_base + vga_ram_addr, vga_ram_addr, vga_ram_size); } } -rtc_state = rtc_init(0x70, i8259[8]); +rtc_state = rtc_init(0x70, i8259[8], 2000); if (pci_enabled) { pic_set_alt_irq_func(isa_pic, NULL, NULL); -- 1.6.0.rc1 -- 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 v9 0/7] PCI: Linux kernel SR-IOV support
Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. SR-IOV specification can be found at: http://www.pcisig.com/members/downloads/specifications/iov/sr-iov1.0_11Sep07.pdf (it requires membership.) Devices that support SR-IOV are available from following vendors: http://download.intel.com/design/network/ProdBrf/320025.pdf http://www.myri.com/vlsi/Lanai_Z8ES_Datasheet.pdf http://www.neterion.com/products/pdfs/X3100ProductBrief.pdf Physical Function driver for Intel 82576 NIC (based on drivers/net/igb/) will come soon. Major changes from v8 to v9: 1, put a might_sleep() into SR-IOV API which sleeps (Andi Kleen) 2, block user config accesses before clearing VF Enable bit (Matthew Wilcox) Yu Zhao (7): PCI: initialize and release SR-IOV capability PCI: restore saved SR-IOV state PCI: reserve bus range for SR-IOV device PCI: add SR-IOV API for Physical Function driver PCI: handle SR-IOV Virtual Function Migration PCI: document SR-IOV sysfs entries PCI: manual for SR-IOV user and driver developer Documentation/ABI/testing/sysfs-bus-pci | 27 ++ Documentation/DocBook/kernel-api.tmpl |1 + Documentation/PCI/pci-iov-howto.txt | 99 + drivers/pci/Kconfig | 13 + drivers/pci/Makefile|3 + drivers/pci/iov.c | 707 +++ drivers/pci/pci.c |8 + drivers/pci/pci.h | 53 +++ drivers/pci/probe.c |7 + include/linux/pci.h | 28 ++ include/linux/pci_regs.h| 33 ++ 11 files changed, 979 insertions(+), 0 deletions(-) create mode 100644 Documentation/PCI/pci-iov-howto.txt create mode 100644 drivers/pci/iov.c -- 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 v9 2/7] PCI: restore saved SR-IOV state
Signed-off-by: Yu Zhao yu.z...@intel.com --- drivers/pci/iov.c | 25 + drivers/pci/pci.c |1 + drivers/pci/pci.h |4 3 files changed, 30 insertions(+), 0 deletions(-) diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index e6736d4..1cc879b 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -128,6 +128,21 @@ static void sriov_release(struct pci_dev *dev) dev-sriov = NULL; } +static void sriov_restore_state(struct pci_dev *dev) +{ + u16 ctrl; + struct pci_sriov *iov = dev-sriov; + + pci_read_config_word(dev, iov-pos + PCI_SRIOV_CTRL, ctrl); + if (ctrl PCI_SRIOV_CTRL_VFE) + return; + + pci_write_config_dword(dev, iov-pos + PCI_SRIOV_SYS_PGSIZE, iov-pgsz); + pci_write_config_word(dev, iov-pos + PCI_SRIOV_CTRL, iov-ctrl); + if (iov-ctrl PCI_SRIOV_CTRL_VFE) + msleep(100); +} + /** * pci_iov_init - initialize the IOV capability * @dev: the PCI device @@ -179,3 +194,13 @@ int pci_iov_resource_bar(struct pci_dev *dev, int resno, return dev-sriov-pos + PCI_SRIOV_BAR + 4 * (resno - PCI_SRIOV_RESOURCES); } + +/** + * pci_restore_iov_state - restore the state of the IOV capability + * @dev: the PCI device + */ +void pci_restore_iov_state(struct pci_dev *dev) +{ + if (dev-sriov) + sriov_restore_state(dev); +} diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index c4f14f3..f791dcf 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -773,6 +773,7 @@ pci_restore_state(struct pci_dev *dev) } pci_restore_pcix_state(dev); pci_restore_msi_state(dev); + pci_restore_iov_state(dev); return 0; } diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index d2dc6b7..9d76737 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -216,6 +216,7 @@ extern int pci_iov_init(struct pci_dev *dev); extern void pci_iov_release(struct pci_dev *dev); extern int pci_iov_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type *type); +extern void pci_restore_iov_state(struct pci_dev *dev); #else static inline int pci_iov_init(struct pci_dev *dev) { @@ -230,6 +231,9 @@ static inline int pci_iov_resource_bar(struct pci_dev *dev, int resno, { return 0; } +static inline void pci_restore_iov_state(struct pci_dev *dev) +{ +} #endif /* CONFIG_PCI_IOV */ #endif /* DRIVERS_PCI_H */ -- 1.5.6.4 -- 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 v9 1/7] PCI: initialize and release SR-IOV capability
Signed-off-by: Yu Zhao yu.z...@intel.com --- drivers/pci/Kconfig | 13 drivers/pci/Makefile |3 + drivers/pci/iov.c| 181 ++ drivers/pci/pci.c|7 ++ drivers/pci/pci.h| 37 ++ drivers/pci/probe.c |4 + include/linux/pci.h |8 ++ include/linux/pci_regs.h | 33 + 8 files changed, 286 insertions(+), 0 deletions(-) create mode 100644 drivers/pci/iov.c diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 2a4501d..e8ea3e8 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -59,3 +59,16 @@ config HT_IRQ This allows native hypertransport devices to use interrupts. If unsure say Y. + +config PCI_IOV + bool PCI IOV support + depends on PCI + select PCI_MSI + default n + help + PCI-SIG I/O Virtualization (IOV) Specifications support. + Single Root IOV: allows the Physical Function driver to enable + the hardware capability, so the Virtual Function is accessible + via the PCI Configuration Space using its own Bus, Device and + Function Numbers. Each Virtual Function also has the PCI Memory + Space to map the device specific register set. diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index 3d07ce2..ba99282 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -29,6 +29,9 @@ obj-$(CONFIG_DMAR) += dmar.o iova.o intel-iommu.o obj-$(CONFIG_INTR_REMAP) += dmar.o intr_remapping.o +# PCI IOV support +obj-$(CONFIG_PCI_IOV) += iov.o + # # Some architectures use the generic PCI setup functions # diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c new file mode 100644 index 000..e6736d4 --- /dev/null +++ b/drivers/pci/iov.c @@ -0,0 +1,181 @@ +/* + * drivers/pci/iov.c + * + * Copyright (C) 2009 Intel Corporation, Yu Zhao yu.z...@intel.com + * + * PCI Express I/O Virtualization (IOV) support. + * Single Root IOV 1.0 + */ + +#include linux/pci.h +#include linux/mutex.h +#include linux/string.h +#include linux/delay.h +#include pci.h + + +static int sriov_init(struct pci_dev *dev, int pos) +{ + int i; + int rc; + int nres; + u32 pgsz; + u16 ctrl, total, offset, stride; + struct pci_sriov *iov; + struct resource *res; + struct pci_dev *pdev; + + if (dev-pcie_type != PCI_EXP_TYPE_RC_END + dev-pcie_type != PCI_EXP_TYPE_ENDPOINT) + return -ENODEV; + + pci_read_config_word(dev, pos + PCI_SRIOV_CTRL, ctrl); + if (ctrl PCI_SRIOV_CTRL_VFE) { + pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, 0); + ssleep(1); + } + + pci_read_config_word(dev, pos + PCI_SRIOV_TOTAL_VF, total); + if (!total) + return 0; + + list_for_each_entry(pdev, dev-bus-devices, bus_list) + if (pdev-sriov) + break; + if (list_empty(dev-bus-devices) || !pdev-sriov) + pdev = NULL; + + ctrl = 0; + if (!pdev pci_ari_enabled(dev-bus)) + ctrl |= PCI_SRIOV_CTRL_ARI; + + pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, ctrl); + pci_write_config_word(dev, pos + PCI_SRIOV_NUM_VF, total); + pci_read_config_word(dev, pos + PCI_SRIOV_VF_OFFSET, offset); + pci_read_config_word(dev, pos + PCI_SRIOV_VF_STRIDE, stride); + if (!offset || (total 1 !stride)) + return -EIO; + + pci_read_config_dword(dev, pos + PCI_SRIOV_SUP_PGSIZE, pgsz); + i = PAGE_SHIFT 12 ? PAGE_SHIFT - 12 : 0; + pgsz = ~((1 i) - 1); + if (!pgsz) + return -EIO; + + pgsz = ~(pgsz - 1); + pci_write_config_dword(dev, pos + PCI_SRIOV_SYS_PGSIZE, pgsz); + + nres = 0; + for (i = 0; i PCI_SRIOV_NUM_BARS; i++) { + res = dev-resource + PCI_SRIOV_RESOURCES + i; + i += __pci_read_base(dev, pci_bar_unknown, res, +pos + PCI_SRIOV_BAR + i * 4); + if (!res-flags) + continue; + if (resource_size(res) (PAGE_SIZE - 1)) { + rc = -EIO; + goto failed; + } + res-end = res-start + resource_size(res) * total - 1; + nres++; + } + + iov = kzalloc(sizeof(*iov), GFP_KERNEL); + if (!iov) { + rc = -ENOMEM; + goto failed; + } + + iov-pos = pos; + iov-nres = nres; + iov-ctrl = ctrl; + iov-total = total; + iov-offset = offset; + iov-stride = stride; + iov-pgsz = pgsz; + iov-self = dev; + pci_read_config_dword(dev, pos + PCI_SRIOV_CAP, iov-cap); + pci_read_config_byte(dev, pos + PCI_SRIOV_FUNC_LINK, iov-link); + + if (pdev) + iov-pdev = pci_dev_get(pdev); + else { + iov-pdev = dev; +
[PATCH v9 3/7] PCI: reserve bus range for SR-IOV device
Signed-off-by: Yu Zhao yu.z...@intel.com --- drivers/pci/iov.c | 34 ++ drivers/pci/pci.h |5 + drivers/pci/probe.c |3 +++ 3 files changed, 42 insertions(+), 0 deletions(-) diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index 1cc879b..c89fcb1 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -14,6 +14,16 @@ #include pci.h +static inline void virtfn_bdf(struct pci_dev *dev, int id, u8 *busnr, u8 *devfn) +{ + u16 bdf; + + bdf = (dev-bus-number 8) + dev-devfn + + dev-sriov-offset + dev-sriov-stride * id; + *busnr = bdf 8; + *devfn = bdf 0xff; +} + static int sriov_init(struct pci_dev *dev, int pos) { int i; @@ -204,3 +214,27 @@ void pci_restore_iov_state(struct pci_dev *dev) if (dev-sriov) sriov_restore_state(dev); } + +/** + * pci_iov_bus_range - find bus range used by Virtual Function + * @bus: the PCI bus + * + * Returns max number of buses (exclude current one) used by Virtual + * Functions. + */ +int pci_iov_bus_range(struct pci_bus *bus) +{ + int max = 0; + u8 busnr, devfn; + struct pci_dev *dev; + + list_for_each_entry(dev, bus-devices, bus_list) { + if (!dev-sriov) + continue; + virtfn_bdf(dev, dev-sriov-total - 1, busnr, devfn); + if (busnr max) + max = busnr; + } + + return max ? max - bus-number : 0; +} diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 9d76737..fdfc476 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -217,6 +217,7 @@ extern void pci_iov_release(struct pci_dev *dev); extern int pci_iov_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type *type); extern void pci_restore_iov_state(struct pci_dev *dev); +extern int pci_iov_bus_range(struct pci_bus *bus); #else static inline int pci_iov_init(struct pci_dev *dev) { @@ -234,6 +235,10 @@ static inline int pci_iov_resource_bar(struct pci_dev *dev, int resno, static inline void pci_restore_iov_state(struct pci_dev *dev) { } +static inline int pci_iov_bus_range(struct pci_bus *bus) +{ + return 0; +} #endif /* CONFIG_PCI_IOV */ #endif /* DRIVERS_PCI_H */ diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 03b6f29..4c8abd0 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1078,6 +1078,9 @@ unsigned int __devinit pci_scan_child_bus(struct pci_bus *bus) for (devfn = 0; devfn 0x100; devfn += 8) pci_scan_slot(bus, devfn); + /* Reserve buses for SR-IOV capability. */ + max += pci_iov_bus_range(bus); + /* * After performing arch-dependent fixup of the bus, look behind * all PCI-to-PCI bridges on this bus. -- 1.5.6.4 -- 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 v9 5/7] PCI: handle SR-IOV Virtual Function Migration
Signed-off-by: Yu Zhao yu.z...@intel.com --- drivers/pci/iov.c | 119 +++ drivers/pci/pci.h |4 ++ include/linux/pci.h |6 +++ 3 files changed, 129 insertions(+), 0 deletions(-) diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index e4e2dac..127f643 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -206,6 +206,97 @@ static void sriov_release_dev(struct device *dev) iov-nr_virtfn = 0; } +static int sriov_migration(struct pci_dev *dev) +{ + u16 status; + struct pci_sriov *iov = dev-sriov; + + if (!iov-nr_virtfn) + return 0; + + if (!(iov-cap PCI_SRIOV_CAP_VFM)) + return 0; + + pci_read_config_word(iov-self, iov-pos + PCI_SRIOV_STATUS, status); + if (!(status PCI_SRIOV_STATUS_VFM)) + return 0; + + schedule_work(iov-mtask); + + return 1; +} + +static void sriov_migration_task(struct work_struct *work) +{ + int i; + u8 state; + u16 status; + struct pci_sriov *iov = container_of(work, struct pci_sriov, mtask); + + for (i = iov-initial; i iov-nr_virtfn; i++) { + state = readb(iov-mstate + i); + if (state == PCI_SRIOV_VFM_MI) { + writeb(PCI_SRIOV_VFM_AV, iov-mstate + i); + state = readb(iov-mstate + i); + if (state == PCI_SRIOV_VFM_AV) + virtfn_add(iov-self, i, 1); + } else if (state == PCI_SRIOV_VFM_MO) { + virtfn_remove(iov-self, i, 1); + writeb(PCI_SRIOV_VFM_UA, iov-mstate + i); + state = readb(iov-mstate + i); + if (state == PCI_SRIOV_VFM_AV) + virtfn_add(iov-self, i, 0); + } + } + + pci_read_config_word(iov-self, iov-pos + PCI_SRIOV_STATUS, status); + status = ~PCI_SRIOV_STATUS_VFM; + pci_write_config_word(iov-self, iov-pos + PCI_SRIOV_STATUS, status); +} + +static int sriov_enable_migration(struct pci_dev *dev, int nr_virtfn) +{ + int bir; + u32 table; + resource_size_t pa; + struct pci_sriov *iov = dev-sriov; + + if (nr_virtfn = iov-initial) + return 0; + + pci_read_config_dword(dev, iov-pos + PCI_SRIOV_VFM, table); + bir = PCI_SRIOV_VFM_BIR(table); + if (bir PCI_STD_RESOURCE_END) + return -EIO; + + table = PCI_SRIOV_VFM_OFFSET(table); + if (table + nr_virtfn pci_resource_len(dev, bir)) + return -EIO; + + pa = pci_resource_start(dev, bir) + table; + iov-mstate = ioremap(pa, nr_virtfn); + if (!iov-mstate) + return -ENOMEM; + + INIT_WORK(iov-mtask, sriov_migration_task); + + iov-ctrl |= PCI_SRIOV_CTRL_VFM | PCI_SRIOV_CTRL_INTR; + pci_write_config_word(dev, iov-pos + PCI_SRIOV_CTRL, iov-ctrl); + + return 0; +} + +static void sriov_disable_migration(struct pci_dev *dev) +{ + struct pci_sriov *iov = dev-sriov; + + iov-ctrl = ~(PCI_SRIOV_CTRL_VFM | PCI_SRIOV_CTRL_INTR); + pci_write_config_word(dev, iov-pos + PCI_SRIOV_CTRL, iov-ctrl); + + cancel_work_sync(iov-mtask); + iounmap(iov-mstate); +} + static int sriov_enable(struct pci_dev *dev, int nr_virtfn) { int rc; @@ -294,6 +385,12 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn) goto failed2; } + if (iov-cap PCI_SRIOV_CAP_VFM) { + rc = sriov_enable_migration(dev, nr_virtfn); + if (rc) + goto failed2; + } + kobject_uevent(dev-dev.kobj, KOBJ_CHANGE); iov-nr_virtfn = nr_virtfn; @@ -325,6 +422,9 @@ static void sriov_disable(struct pci_dev *dev) if (!iov-nr_virtfn) return; + if (iov-cap PCI_SRIOV_CAP_VFM) + sriov_disable_migration(dev); + for (i = 0; i iov-nr_virtfn; i++) virtfn_remove(dev, i, 0); @@ -586,3 +686,22 @@ void pci_disable_sriov(struct pci_dev *dev) sriov_disable(dev); } EXPORT_SYMBOL_GPL(pci_disable_sriov); + +/** + * pci_sriov_migration - notify SR-IOV core of Virtual Function Migration + * @dev: the PCI device + * + * Returns IRQ_HANDLED if the IRQ is handled, or IRQ_NONE if not. + * + * Physical Function driver is responsible to register IRQ handler using + * VF Migration Interrupt Message Number, and call this function when the + * interrupt is generated by the hardware. + */ +irqreturn_t pci_sriov_migration(struct pci_dev *dev) +{ + if (!dev-sriov) + return IRQ_NONE; + + return sriov_migration(dev) ? IRQ_HANDLED : IRQ_NONE; +} +EXPORT_SYMBOL_GPL(pci_sriov_migration); diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 328a611..51bebb2 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -1,6 +1,8 @@ #ifndef
[PATCH v9 4/7] PCI: add SR-IOV API for Physical Function driver
Signed-off-by: Yu Zhao yu.z...@intel.com --- drivers/pci/iov.c | 348 +++ drivers/pci/pci.h |3 + include/linux/pci.h | 14 ++ 3 files changed, 365 insertions(+), 0 deletions(-) diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c index c89fcb1..e4e2dac 100644 --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -13,6 +13,8 @@ #include linux/delay.h #include pci.h +#define VIRTFN_ID_LEN 8 + static inline void virtfn_bdf(struct pci_dev *dev, int id, u8 *busnr, u8 *devfn) { @@ -24,6 +26,319 @@ static inline void virtfn_bdf(struct pci_dev *dev, int id, u8 *busnr, u8 *devfn) *devfn = bdf 0xff; } +static struct pci_bus *virtfn_add_bus(struct pci_bus *bus, int busnr) +{ + int rc; + struct pci_bus *child; + + if (bus-number == busnr) + return bus; + + child = pci_find_bus(pci_domain_nr(bus), busnr); + if (child) + return child; + + child = pci_add_new_bus(bus, NULL, busnr); + if (!child) + return NULL; + + child-subordinate = busnr; + child-dev.parent = bus-bridge; + rc = pci_bus_add_child(child); + if (rc) { + pci_remove_bus(child); + return NULL; + } + + return child; +} + +static void virtfn_remove_bus(struct pci_bus *bus, int busnr) +{ + struct pci_bus *child; + + if (bus-number == busnr) + return; + + child = pci_find_bus(pci_domain_nr(bus), busnr); + BUG_ON(!child); + + if (list_empty(child-devices)) + pci_remove_bus(child); +} + +static int virtfn_add(struct pci_dev *dev, int id, int reset) +{ + int i; + int rc; + u64 size; + u8 busnr, devfn; + char buf[VIRTFN_ID_LEN]; + struct pci_dev *virtfn; + struct resource *res; + struct pci_sriov *iov = dev-sriov; + + virtfn = alloc_pci_dev(); + if (!virtfn) + return -ENOMEM; + + virtfn_bdf(dev, id, busnr, devfn); + mutex_lock(iov-pdev-sriov-lock); + virtfn-bus = virtfn_add_bus(dev-bus, busnr); + if (!virtfn-bus) { + kfree(virtfn); + mutex_unlock(iov-pdev-sriov-lock); + return -ENOMEM; + } + + virtfn-sysdata = dev-bus-sysdata; + virtfn-dev.parent = dev-dev.parent; + virtfn-dev.bus = dev-dev.bus; + virtfn-devfn = devfn; + virtfn-hdr_type = PCI_HEADER_TYPE_NORMAL; + virtfn-cfg_size = PCI_CFG_SPACE_EXP_SIZE; + virtfn-error_state = pci_channel_io_normal; + virtfn-current_state = PCI_UNKNOWN; + virtfn-is_pcie = 1; + virtfn-pcie_type = PCI_EXP_TYPE_ENDPOINT; + virtfn-dma_mask = 0x; + virtfn-vendor = dev-vendor; + virtfn-subsystem_vendor = dev-subsystem_vendor; + virtfn-class = dev-class; + pci_read_config_word(dev, iov-pos + PCI_SRIOV_VF_DID, virtfn-device); + pci_read_config_byte(virtfn, PCI_REVISION_ID, virtfn-revision); + pci_read_config_word(virtfn, PCI_SUBSYSTEM_ID, +virtfn-subsystem_device); + + dev_set_name(virtfn-dev, %04x:%02x:%02x.%d, +pci_domain_nr(virtfn-bus), busnr, +PCI_SLOT(devfn), PCI_FUNC(devfn)); + + for (i = 0; i PCI_SRIOV_NUM_BARS; i++) { + res = dev-resource + PCI_SRIOV_RESOURCES + i; + if (!res-parent) + continue; + virtfn-resource[i].name = pci_name(virtfn); + virtfn-resource[i].flags = res-flags; + size = resource_size(res); + do_div(size, iov-total); + virtfn-resource[i].start = res-start + size * id; + virtfn-resource[i].end = virtfn-resource[i].start + size - 1; + rc = request_resource(res, virtfn-resource[i]); + BUG_ON(rc); + } + + if (reset) + pci_execute_reset_function(virtfn); + + pci_device_add(virtfn, virtfn-bus); + mutex_unlock(iov-pdev-sriov-lock); + + virtfn-physfn = pci_dev_get(dev); + + rc = pci_bus_add_device(virtfn); + if (rc) + goto failed1; + sprintf(buf, %d, id); + rc = sysfs_create_link(iov-dev.kobj, virtfn-dev.kobj, buf); + if (rc) + goto failed1; + rc = sysfs_create_link(virtfn-dev.kobj, dev-dev.kobj, physfn); + if (rc) + goto failed2; + + kobject_uevent(virtfn-dev.kobj, KOBJ_CHANGE); + + return 0; + +failed2: + sysfs_remove_link(iov-dev.kobj, buf); +failed1: + pci_dev_put(dev); + mutex_lock(iov-pdev-sriov-lock); + pci_remove_bus_device(virtfn); + virtfn_remove_bus(dev-bus, busnr); + mutex_unlock(iov-pdev-sriov-lock); + + return rc; +} + +static void virtfn_remove(struct pci_dev *dev, int id, int reset) +{ + u8 busnr, devfn; + char buf[VIRTFN_ID_LEN]; + struct
[PATCH v9 6/7] PCI: document SR-IOV sysfs entries
Signed-off-by: Yu Zhao yu.z...@intel.com --- Documentation/ABI/testing/sysfs-bus-pci | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index ceddcff..84dc100 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -9,3 +9,30 @@ Description: that some devices may have malformatted data. If the underlying VPD has a writable section then the corresponding section of this file will be writable. + +What: /sys/bus/pci/devices/.../virtfn/N +Date: February 2009 +Contact: Yu Zhao yu.z...@intel.com +Description: + This symbol link appears when hardware supports SR-IOV + capability and Physical Function driver has enabled it. + The symbol link points to the PCI device sysfs entry of + Virtual Function whose index is N (0...MaxVFs-1). + +What: /sys/bus/pci/devices/.../virtfn/dep_link +Date: February 2009 +Contact: Yu Zhao yu.z...@intel.com +Description: + This symbol link appears when hardware supports SR-IOV + capability and Physical Function driver has enabled it, + and this device has vendor specific dependencies with + others. The symbol link points to the PCI device sysfs + entry of Physical Function this device depends on. + +What: /sys/bus/pci/devices/.../physfn +Date: February 2009 +Contact: Yu Zhao yu.z...@intel.com +Description: + This symbol link appears when a device is Virtual Function. + The symbol link points to the PCI device sysfs entry of + Physical Function this device associates with. -- 1.5.6.4 -- 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 v9 7/7] PCI: manual for SR-IOV user and driver developer
Signed-off-by: Yu Zhao yu.z...@intel.com --- Documentation/DocBook/kernel-api.tmpl |1 + Documentation/PCI/pci-iov-howto.txt | 99 + 2 files changed, 100 insertions(+), 0 deletions(-) create mode 100644 Documentation/PCI/pci-iov-howto.txt diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 5818ff7..506e611 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -251,6 +251,7 @@ X!Edrivers/pci/hotplug.c -- !Edrivers/pci/probe.c !Edrivers/pci/rom.c +!Edrivers/pci/iov.c /sect1 sect1titlePCI Hotplug Support Library/title !Edrivers/pci/hotplug/pci_hotplug_core.c diff --git a/Documentation/PCI/pci-iov-howto.txt b/Documentation/PCI/pci-iov-howto.txt new file mode 100644 index 000..fc73ef5 --- /dev/null +++ b/Documentation/PCI/pci-iov-howto.txt @@ -0,0 +1,99 @@ + PCI Express I/O Virtualization Howto + Copyright (C) 2009 Intel Corporation + Yu Zhao yu.z...@intel.com + + +1. Overview + +1.1 What is SR-IOV + +Single Root I/O Virtualization (SR-IOV) is a PCI Express Extended +capability which makes one physical device appear as multiple virtual +devices. The physical device is referred to as Physical Function (PF) +while the virtual devices are referred to as Virtual Functions (VF). +Allocation of the VF can be dynamically controlled by the PF via +registers encapsulated in the capability. By default, this feature is +not enabled and the PF behaves as traditional PCIe device. Once it's +turned on, each VF's PCI configuration space can be accessed by its own +Bus, Device and Function Number (Routing ID). And each VF also has PCI +Memory Space, which is used to map its register set. VF device driver +operates on the register set so it can be functional and appear as a +real existing PCI device. + +2. User Guide + +2.1 How can I enable SR-IOV capability + +The device driver (PF driver) will control the enabling and disabling +of the capability via API provided by SR-IOV core. If the hardware +has SR-IOV capability, loading its PF driver would enable it and all +VFs associated with the PF. + +2.2 How can I use the Virtual Functions + +The VF is treated as hot-plugged PCI devices in the kernel, so they +should be able to work in the same way as real PCI devices. The VF +requires device driver that is same as a normal PCI device's. + +3. Developer Guide + +3.1 SR-IOV API + +To enable SR-IOV capability: + int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn); + 'nr_virtfn' is number of VFs to be enabled. + +To disable SR-IOV capability: + void pci_disable_sriov(struct pci_dev *dev); + +To notify SR-IOV core of Virtual Function Migration: + irqreturn_t pci_sriov_migration(struct pci_dev *dev); + +3.2 Usage example + +Following piece of code illustrates the usage of the SR-IOV API. + +static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id) +{ + pci_enable_sriov(dev, NR_VIRTFN); + + ... + + return 0; +} + +static void __devexit dev_remove(struct pci_dev *dev) +{ + pci_disable_sriov(dev); + + ... +} + +static int dev_suspend(struct pci_dev *dev, pm_message_t state) +{ + ... + + return 0; +} + +static int dev_resume(struct pci_dev *dev) +{ + ... + + return 0; +} + +static void dev_shutdown(struct pci_dev *dev) +{ + ... +} + +static struct pci_driver dev_driver = { + .name = SR-IOV Physical Function driver, + .id_table = dev_id_table, + .probe =dev_probe, + .remove = __devexit_p(dev_remove), + .suspend = dev_suspend, + .resume = dev_resume, + .shutdown = dev_shutdown, +}; -- 1.5.6.4 -- 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] kvm: fix typo of || to in arch/x86/kvm/vmx.c
Fix the typo of || to . Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com --- arch/x86/kvm/vmx.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 6259d74..3f3cab2 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -1813,7 +1813,7 @@ static bool stack_segment_valid(struct kvm_vcpu *vcpu) vmx_get_segment(vcpu, ss, VCPU_SREG_SS); ss_rpl = ss.selector SELECTOR_RPL_MASK; - if ((ss.type != 3) || (ss.type != 7)) + if ((ss.type != 3) (ss.type != 7)) return false; if (!ss.s) return false; @@ -1856,7 +1856,7 @@ static bool tr_valid(struct kvm_vcpu *vcpu) if (tr.selector SELECTOR_TI_MASK) /* TI = 1 */ return false; - if ((tr.type != 3) || (tr.type != 11)) /* TODO: Check if guest is in IA32e mode */ + if ((tr.type != 3) (tr.type != 11)) /* TODO: Check if guest is in IA32e mode */ return false; if (!tr.present) return false; -- 1.5.3.8 -- 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
Bryon Roche wrote: If you're playing with kvm-git, you should be able to pull these fixes in via cherry picking 16f197e29c19a4366a1d2ba3dcd0b4b8b0f86ce6, then 86030aade7ae09f4cedfb13973e37ba30f3db073. In fact, I compiled and installed kvm-84 today, and it seems to have resolved the problem with qcow2 encrypted volumes corrupting. Thanks for the prod, am now happily running on kvm-84. -- Ross McKay, Toronto, NSW Australia Let the laddie play wi the knife - he'll learn - The Wee Book of Calvin -- 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