[PATCH] kvm: testsuite: add regression test for MSR_KERNEL_GS_BASE

2009-02-16 Thread Avi Kivity
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)

2009-02-16 Thread Avi Kivity
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'

2009-02-16 Thread Avi Kivity
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

2009-02-16 Thread Zhang, Yang
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

2009-02-16 Thread Amit Shah
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

2009-02-16 Thread Kevin Wolf
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

2009-02-16 Thread Andre Przywara

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

2009-02-16 Thread Bryon Roche
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

2009-02-16 Thread Randy Smith
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?

2009-02-16 Thread Neo Jia
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?

2009-02-16 Thread Alexander Graf


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?

2009-02-16 Thread Craig Metz
  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?

2009-02-16 Thread Tassilo Horn
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

2009-02-16 Thread Ross McKay
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

2009-02-16 Thread Marcelo Tosatti
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.

2009-02-16 Thread Dustin Kirkland
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.

2009-02-16 Thread Dustin Kirkland
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

2009-02-16 Thread Jamie Lokier
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

2009-02-16 Thread Sheng Yang
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

2009-02-16 Thread Sheng Yang
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

2009-02-16 Thread Zhang, Xiantao
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

2009-02-16 Thread Yu Zhao
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

2009-02-16 Thread Yu Zhao
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

2009-02-16 Thread Yu Zhao
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

2009-02-16 Thread Yu Zhao
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

2009-02-16 Thread Yu Zhao
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

2009-02-16 Thread Yu Zhao
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

2009-02-16 Thread Yu Zhao
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

2009-02-16 Thread Yu Zhao
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

2009-02-16 Thread Wei Yongjun
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

2009-02-16 Thread Ross McKay
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