Re: [kvm-devel] Where are vmentry failure caugth?
On Thu, 10 Jan 2008 17:32:35 +0200 Avi Kivity <[EMAIL PROTECTED]> wrote: > I think 33 is the error code, which means we got a general protection > fault while accessing segment 0x33. > > What guest code is running when this happens? The dump sometimes > includes the current code. When it happened I started an openSUSE-10.3 installation. Here is the complete dump: [guill]$ ./qemu-system-x86_64 -hda ~/disk_images/openSUSE-10.3.qcow2 -cdrom ~/iso_images/openSUSE-10.3-GM-x86_64-mini.iso -boot d -m 1024 exception 13 (33) rax 0671 rbx 0080 rcx rdx 13ca rsi 00055e1c rdi 00055e1d rsp fffa0080 rbp 200b r8 r9 r10 r11 r12 r13 r14 r15 rip b071 rflags 00033096 cs 4004 (00040040/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 4004 (00040040/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 00ff (0ff0/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss ff11 (000ff110/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 3002 (00030020/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (fffbd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 40920/47 idt 0/ cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 17 06 29 4b 01 18 eb 18 a8 25 aa 19 28 4c 01 28 4d 01 01 17 --> 0f 17 0f 01 17 0f 17 12 01 17 2c 25 4b 19 21 00 02 17 1a 94 0a 76 67 61 3d 30 78 25 78 20 Aborted In the console I got: [86955.117391] handle_exception: unexpected, vectoring info 0x8306 intr info 0x8b0d [86955.193194] pending exception: not handled yet [86955.219948] pending exception: not handled yet -- Guillaume Thouvenin - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC: MMIO endianness flag
Hi all,
That's a good start to consider BE.
Yes, IA64 support BE and LE.
I have below comments.
What does is_bigendian mean?
Host is runing with BE or guest is running with BE.
Who will set is_bigendian?
For supporing BE,
We need to consider host BE and guest BE.
For IA64, most OS is running with LE, and
Application can run with BE or LE,
For example, Qemu can run with BE or LE.
IMHO, we need two flags,
host_is_bigendian indicates Qemu is running with BE
Guest_is_bigendian indecates the guest application who is accessing MMIO
Is running with LE.
- Anthony
Hollis Blanchard wrote:
> On Thu, 2008-01-10 at 17:28 +0200, Avi Kivity wrote:
>> I'll apply that patch (with a #ifdef CONFIG_PPC so other archs don't
>> use it by mistake).
>
> I don't think that's the right ifdef. For example, I believe IA64 can
> run in BE mode and so will have the same issue, and there are
> certainly
> other architectures (less relevant to the current code) that
> definitely
> are in the same situation.
>
> We need to plumb this through to the libkvm users anyways. Take a look
> at the patch below and tell me if you think it's not the right
> approach.
> x86 simply won't consider 'is_bigendian'. I spent a lot of time on
> this,
> and it's by far the cleanest solution I could come up with.
>
>
>
> diff --git a/libkvm/config-i386.mak b/libkvm/config-i386.mak
> --- a/libkvm/config-i386.mak
> +++ b/libkvm/config-i386.mak
> @@ -2,5 +2,6 @@ LIBDIR := /lib
> LIBDIR := /lib
> CFLAGS += -m32
> CFLAGS += -D__i386__
> +CFLAGS += -DARCH_MMIO_ENDIAN_LITTLE
>
> libkvm-$(ARCH)-objs := libkvm-x86.o
> diff --git a/libkvm/config-ia64.mak b/libkvm/config-ia64.mak
> --- a/libkvm/config-ia64.mak
> +++ b/libkvm/config-ia64.mak
> @@ -1,5 +1,6 @@
>
> LIBDIR := /lib
> CFLAGS += -D__ia64__
> +CFLAGS += -DARCH_MMIO_ENDIAN_LITTLE -DARCH_MMIO_ENDIAN_BIG
>
> libkvm-$(ARCH)-objs := libkvm-ia64.o
> diff --git a/libkvm/config-powerpc.mak b/libkvm/config-powerpc.mak
> --- a/libkvm/config-powerpc.mak
> +++ b/libkvm/config-powerpc.mak
> @@ -2,5 +2,6 @@ LIBDIR := /lib
> LIBDIR := /lib
> CFLAGS += -m32
> CFLAGS += -D__powerpc__
> +CFLAGS += -DARCH_MMIO_ENDIAN_BIG -DARCH_MMIO_ENDIAN_LITTLE
>
> libkvm-$(ARCH)-objs := libkvm-powerpc.o
> diff --git a/libkvm/config-x86_64.mak b/libkvm/config-x86_64.mak
> --- a/libkvm/config-x86_64.mak
> +++ b/libkvm/config-x86_64.mak
> @@ -2,5 +2,6 @@ LIBDIR := /lib64
> LIBDIR := /lib64
> CFLAGS += -m64
> CFLAGS += -D__x86_64__
> +CFLAGS += -DARCH_MMIO_ENDIAN_LITTLE
>
> libkvm-$(ARCH)-objs := libkvm-x86.o
> diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
> --- a/libkvm/libkvm.c
> +++ b/libkvm/libkvm.c
> @@ -774,21 +774,56 @@ int kvm_set_sregs(kvm_context_t kvm, int
> return ioctl(kvm->vcpu_fd[vcpu], KVM_SET_SREGS, sregs);
> }
>
> +#ifdef ARCH_MMIO_ENDIAN_BIG
> +static int handle_mmio_bigendian(kvm_context_t kvm, struct kvm_run
> *kvm_run) +{
> + if (kvm_run->mmio.is_write)
> + return kvm->callbacks->mmio_write_be(kvm->opaque,
> +
kvm_run->mmio.phys_addr,
> + kvm_run->mmio.data,
> + kvm_run->mmio.len);
> + else
> + return kvm->callbacks->mmio_read_be(kvm->opaque,
> +
kvm_run->mmio.phys_addr,
> + kvm_run->mmio.data,
> + kvm_run->mmio.len);
> +}
> +#endif
> +
> +#ifdef ARCH_MMIO_ENDIAN_LITTLE
> +static int handle_mmio_littleendian(kvm_context_t kvm, struct
> kvm_run *kvm_run) +{
> + if (kvm_run->mmio.is_write)
> + return kvm->callbacks->mmio_write_le(kvm->opaque,
> +
kvm_run->mmio.phys_addr,
> + kvm_run->mmio.data,
> + kvm_run->mmio.len);
> + else
> + return kvm->callbacks->mmio_read_le(kvm->opaque,
> +
kvm_run->mmio.phys_addr,
> + kvm_run->mmio.data,
> + kvm_run->mmio.len);
> +}
> +#endif
> +
> static int handle_mmio(kvm_context_t kvm, struct kvm_run *kvm_run)
> {
> unsigned long addr = kvm_run->mmio.phys_addr;
> - void *data = kvm_run->mmio.data;
>
> /* hack: Red Hat 7.1 generates these weird accesses. */
> if ((addr > 0xa-4 && addr <= 0xa) && kvm_run->mmio.len
== 3)
> return 0;
>
> - if (kvm_run->mmio.is_write)
> - return kvm->callbacks->mmio_write(kvm->opaque, addr,
data,
> - kvm_run->mmio.len);
> +#if defined(ARCH_MMIO_ENDIAN_BIG) && defined(ARCH_MMIO_ENDIAN_LITTLE)
> + if (kvm_run->mmio.is_bigendian)
> + return handle_mmio_bigendian(kvm, kvm_run);
> else
> - return kvm->callbacks->mmio_read(kvm->opaque, addr,
data,
> - kvm_run->mmio.len);
> + return handle_mmio_littleendi
Re: [kvm-devel] Strange networking behavior
Peter Osuchowski wrote: > talithaA ~ # ping 10.0.1.1 > PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data. > 64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=850 ms > 64 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=389 ms > 64 bytes from 10.0.1.1: icmp_seq=3 ttl=64 time=0.353 ms > 64 bytes from 10.0.1.1: icmp_seq=4 ttl=64 time=0.366 ms > 64 bytes from 10.0.1.1: icmp_seq=5 ttl=64 time=0.361 ms ... > The two networks above (10.0.0.0/8 and 172.16.1.0/24) are on seperate Qemu > VLANs. The hardware is a Dual Quad-Core Opteron 2210 server and I'm using the > default (NE2000) virtual NICs. The host machines have no networking problems. The NE2000 code appears to be very broken. Use rtl8139 instead and you should get better results. -jim - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Setting hardware breakpoints in guest OS
Can hardware breakpoints be set (and trapped, and handled) inside a guest OS (specifially Windows XP2)? I noticed the other day that software (malicious code, in fact) packed with the EXE compressor PELock won't run under QEMU+KVM. I guessed that this was because h/w breakpoints aren't being trapped. (The PELock incarnation used in this case relies on SEH and H/W breaks -- verifying that they take place correctly -- in its decryption code in order to try to make it harder to extract the original content from packed files.) A quick try with OllyDbg suggested that I wasn't able to provoke hardware traps in my own code, either. Olly allows me to specify a H/W breakpoint but I never seem to get control back at the desired address. INT 1 and INT 3 debugging work just fine (i.e. tracing and software breakpoints). Is this "one of those things" to do with virtualisation? QEMU+kqemu handles PELock files just fine. Apologies if this is an already-answered question. I couldn't find an answer on my own. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Strange networking behavior
Hello, I've noticed this strange networking behavior while running kvm-59 modules and qemu on a custom-compiled 2.6.24-rc5 kernel on x86_64 (2 x Opteron 2210). When I ping a VM from the host it's running on, I get the following result: talithaA ~ # ping 10.0.1.1 PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data. 64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=850 ms 64 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=389 ms 64 bytes from 10.0.1.1: icmp_seq=3 ttl=64 time=0.353 ms 64 bytes from 10.0.1.1: icmp_seq=4 ttl=64 time=0.366 ms 64 bytes from 10.0.1.1: icmp_seq=5 ttl=64 time=0.361 ms 64 bytes from 10.0.1.1: icmp_seq=6 ttl=64 time=739 ms 64 bytes from 10.0.1.1: icmp_seq=7 ttl=64 time=740 ms 64 bytes from 10.0.1.1: icmp_seq=8 ttl=64 time=741 ms 64 bytes from 10.0.1.1: icmp_seq=9 ttl=64 time=1742 ms 64 bytes from 10.0.1.1: icmp_seq=10 ttl=64 time=731 ms 64 bytes from 10.0.1.1: icmp_seq=11 ttl=64 time=0.373 ms 64 bytes from 10.0.1.1: icmp_seq=12 ttl=64 time=0.380 ms 64 bytes from 10.0.1.1: icmp_seq=13 ttl=64 time=0.383 ms --- 10.0.1.1 ping statistics --- 14 packets transmitted, 13 received, 7% packet loss, time 13005ms rtt min/avg/max/mdev = 0.353/456.630/1742.288/509.780 ms, pipe 2 On the other hand, when I ping something on the network from the VM, I get: talithaA-v00 ~ # ping 172.16.1.1 PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data. 64 bytes from 172.16.1.1: icmp_seq=1 ttl=64 time=1011 ms 64 bytes from 172.16.1.1: icmp_seq=2 ttl=64 time=2.81 ms 64 bytes from 172.16.1.1: icmp_seq=3 ttl=64 time=1000 ms 64 bytes from 172.16.1.1: icmp_seq=4 ttl=64 time=1.37 ms 64 bytes from 172.16.1.1: icmp_seq=5 ttl=64 time=1000 ms 64 bytes from 172.16.1.1: icmp_seq=6 ttl=64 time=1.37 ms 64 bytes from 172.16.1.1: icmp_seq=7 ttl=64 time=1000 ms 64 bytes from 172.16.1.1: icmp_seq=8 ttl=64 time=1.37 ms --- 172.16.1.1 ping statistics --- 9 packets transmitted, 8 received, 11% packet loss, time 8007ms rtt min/avg/max/mdev = 1.375/502.390/1011.591/500.668 ms, pipe 2 The two networks above (10.0.0.0/8 and 172.16.1.0/24) are on seperate Qemu VLANs. The hardware is a Dual Quad-Core Opteron 2210 server and I'm using the default (NE2000) virtual NICs. The host machines have no networking problems. If anyone could offer any advice, I would be most grateful. Thanks, Peter -- Peter Osuchowski Hosting Operations Engineer Turtol, LLC. [EMAIL PROTECTED] http://www.turtol.com - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] e1000 emulation code
On 11/01/2008, Dor Laor <[EMAIL PROTECTED]> wrote: > andrzej zaborowski wrote: > > Would it be possible to pick only the useful stuff from the header and > > put it into the same file, rather than maintaining a copy of a linux > > header (which is 3.5 bigger than the actual emulation in kLoC)? Qemu > > has avoided that until now. > > > > > I can but then how can you compile qemu for OS's which do not have > Linux/ or linux headers? I don't mean using the Linux header. I mean having all the necessary definitions in e1000.c or a different file but not with 3000 lines of unused definitions. Regards - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] e1000 emulation code
andrzej zaborowski wrote: > Hi, > > On 09/01/2008, Dor Laor <[EMAIL PROTECTED]> wrote: > >> It which supports TCP/UDP and IP transmit checksum, as well as TSO. >> It has been tested with Linux (2.6.18|22|23|24)++ and Windows XP (using >> the driver supplied at the intel download site). >> Windows Vista recognizes it but there is no traffic. >> >> Checksum calculation is currently naïve and unoptimized (the host >> kernel does it better). But when working in conjuction to tso >> the performance is drastically better. >> >> Some figures: Linux rx 350Mbps, tx 150bps, Windows rx 700mbps, tx 100 mbps. >> > > That will be great to have in qemu. > > >> The e1000_hw.h is copied from Linux kernel. >> > > Would it be possible to pick only the useful stuff from the header and > put it into the same file, rather than maintaining a copy of a linux > header (which is 3.5 bigger than the actual emulation in kLoC)? Qemu > has avoided that until now. > > I can but then how can you compile qemu for OS's which do not have Linux/ or linux headers? >> qemu/hw/e1000.c | 1000 +++ >> qemu/hw/e1000_hw.h | 3411 >> ++ >> > > Regards. > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1868937 ] eepro100.c:1570: nic_receive: Assertion `0' failed.
Bugs item #1868937, was opened at 2008-01-11 00:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1868937&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: qemu
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Philipp Morger (swissphoenix)
Assigned to: Nobody/Anonymous (nobody)
Summary: eepro100.c:1570: nic_receive: Assertion `0' failed.
Initial Comment:
Hi there
:: System
Using kvm-58 on linux 2.6.22 (ubuntu gutsy) guest is openbsd-4.1
:: StartUp Command
Executing with parameters: -pidfile /var/run/kvm/raven.pid -no-acpi -k de-ch
-boot c -m 64 -hda /srv/kvm/vmx/4I/raven/wd0-openbsd-4_1-MkI.img -serial
telnet:localhost:10057,server,nowait -net
nic,vlan=1,model=i82559er,macaddr=00:16:3E:22:24:94 -net
tap,vlan=1,ifname=tap97 -net
nic,vlan=2,model=i82559er,macaddr=00:16:3E:46:81:09 -net
tap,vlan=2,ifname=tap98 -net
nic,vlan=3,model=i82559er,macaddr=00:16:3E:93:40:42 -net
tap,vlan=3,ifname=tap99 -net
nic,vlan=4,model=i82559er,macaddr=00:16:3E:49:97:04 -net
tap,vlan=4,ifname=tap100 -net
nic,vlan=5,model=i82559er,macaddr=00:16:3E:30:35:89 -net
tap,vlan=5,ifname=tap101 -net
nic,vlan=6,model=i82559er,macaddr=00:16:3E:12:02:75 -net
tap,vlan=6,ifname=tap102 -net
nic,vlan=7,model=i82559er,macaddr=00:16:3E:03:40:50 -net
tap,vlan=7,ifname=tap103 -net
nic,vlan=8,model=i82559er,macaddr=00:16:3E:93:90:45 -net
tap,vlan=8,ifname=tap104 -net
nic,vlan=9,model=i82559er,macaddr=00:16:3E:08:47:60 -net
tap,vlan=9,ifname=tap105
qemu: /usr/src/kvm-58/qemu/hw/eepro100.c:1570: nic_receive: Assertion `0'
failed.
/srv/kvm/scripts/kvm_start_wrapper.sh: line 59: 9116 Aborted
sudo -u kvm nice qemu ${COMMAND}
CRITICAL: We had a software error! RC: 134
:: Code
eepro100.c:1570
if (rfd_command & 0x8000) {
/* EL bit is set, so this was the last frame. */
assert(0);
}
:: Figuring what happens...
I managed to figure what's an assertion is, so I guess the "assert(0)" always
fails, and thus qemu is intended to fail here, so assumption is that
rfd_command should never enter the state or the code is incomplete or some
other error, would be nice to know :)
regards
Philipp
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1868937&group_id=180599
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC: MMIO endianness flag
On Thu, 2008-01-10 at 17:28 +0200, Avi Kivity wrote:
> I'll apply that patch (with a #ifdef CONFIG_PPC so other archs don't
> use it by mistake).
I don't think that's the right ifdef. For example, I believe IA64 can
run in BE mode and so will have the same issue, and there are certainly
other architectures (less relevant to the current code) that definitely
are in the same situation.
We need to plumb this through to the libkvm users anyways. Take a look
at the patch below and tell me if you think it's not the right approach.
x86 simply won't consider 'is_bigendian'. I spent a lot of time on this,
and it's by far the cleanest solution I could come up with.
diff --git a/libkvm/config-i386.mak b/libkvm/config-i386.mak
--- a/libkvm/config-i386.mak
+++ b/libkvm/config-i386.mak
@@ -2,5 +2,6 @@ LIBDIR := /lib
LIBDIR := /lib
CFLAGS += -m32
CFLAGS += -D__i386__
+CFLAGS += -DARCH_MMIO_ENDIAN_LITTLE
libkvm-$(ARCH)-objs := libkvm-x86.o
diff --git a/libkvm/config-ia64.mak b/libkvm/config-ia64.mak
--- a/libkvm/config-ia64.mak
+++ b/libkvm/config-ia64.mak
@@ -1,5 +1,6 @@
LIBDIR := /lib
CFLAGS += -D__ia64__
+CFLAGS += -DARCH_MMIO_ENDIAN_LITTLE -DARCH_MMIO_ENDIAN_BIG
libkvm-$(ARCH)-objs := libkvm-ia64.o
diff --git a/libkvm/config-powerpc.mak b/libkvm/config-powerpc.mak
--- a/libkvm/config-powerpc.mak
+++ b/libkvm/config-powerpc.mak
@@ -2,5 +2,6 @@ LIBDIR := /lib
LIBDIR := /lib
CFLAGS += -m32
CFLAGS += -D__powerpc__
+CFLAGS += -DARCH_MMIO_ENDIAN_BIG -DARCH_MMIO_ENDIAN_LITTLE
libkvm-$(ARCH)-objs := libkvm-powerpc.o
diff --git a/libkvm/config-x86_64.mak b/libkvm/config-x86_64.mak
--- a/libkvm/config-x86_64.mak
+++ b/libkvm/config-x86_64.mak
@@ -2,5 +2,6 @@ LIBDIR := /lib64
LIBDIR := /lib64
CFLAGS += -m64
CFLAGS += -D__x86_64__
+CFLAGS += -DARCH_MMIO_ENDIAN_LITTLE
libkvm-$(ARCH)-objs := libkvm-x86.o
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -774,21 +774,56 @@ int kvm_set_sregs(kvm_context_t kvm, int
return ioctl(kvm->vcpu_fd[vcpu], KVM_SET_SREGS, sregs);
}
+#ifdef ARCH_MMIO_ENDIAN_BIG
+static int handle_mmio_bigendian(kvm_context_t kvm, struct kvm_run *kvm_run)
+{
+ if (kvm_run->mmio.is_write)
+ return kvm->callbacks->mmio_write_be(kvm->opaque,
+kvm_run->mmio.phys_addr,
+kvm_run->mmio.data,
+kvm_run->mmio.len);
+ else
+ return kvm->callbacks->mmio_read_be(kvm->opaque,
+ kvm_run->mmio.phys_addr,
+ kvm_run->mmio.data,
+ kvm_run->mmio.len);
+}
+#endif
+
+#ifdef ARCH_MMIO_ENDIAN_LITTLE
+static int handle_mmio_littleendian(kvm_context_t kvm, struct kvm_run *kvm_run)
+{
+ if (kvm_run->mmio.is_write)
+ return kvm->callbacks->mmio_write_le(kvm->opaque,
+kvm_run->mmio.phys_addr,
+kvm_run->mmio.data,
+kvm_run->mmio.len);
+ else
+ return kvm->callbacks->mmio_read_le(kvm->opaque,
+ kvm_run->mmio.phys_addr,
+ kvm_run->mmio.data,
+ kvm_run->mmio.len);
+}
+#endif
+
static int handle_mmio(kvm_context_t kvm, struct kvm_run *kvm_run)
{
unsigned long addr = kvm_run->mmio.phys_addr;
- void *data = kvm_run->mmio.data;
/* hack: Red Hat 7.1 generates these weird accesses. */
if ((addr > 0xa-4 && addr <= 0xa) && kvm_run->mmio.len == 3)
return 0;
- if (kvm_run->mmio.is_write)
- return kvm->callbacks->mmio_write(kvm->opaque, addr, data,
- kvm_run->mmio.len);
+#if defined(ARCH_MMIO_ENDIAN_BIG) && defined(ARCH_MMIO_ENDIAN_LITTLE)
+ if (kvm_run->mmio.is_bigendian)
+ return handle_mmio_bigendian(kvm, kvm_run);
else
- return kvm->callbacks->mmio_read(kvm->opaque, addr, data,
- kvm_run->mmio.len);
+ return handle_mmio_littleendian(kvm, kvm_run);
+#elif ARCH_MMIO_ENDIAN_LITTLE
+ return handle_mmio_littleendian(kvm, kvm_run);
+#elif ARCH_MMIO_ENDIAN_BIG
+ return handle_mmio_bigendian(kvm, kvm_run);
+#endif
}
int handle_io_window(kvm_context_t kvm)
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -46,11 +46,11 @@ struct kvm_callbacks {
/// For 32bit IO writes from the guest (Usually when executing 'outl')
int (*outl)(void *opaque, uint16_t addr, uint32_t data);
/// generic memory reads to unmapped memory (For
[kvm-devel] Medical Doctor Listing in the US
Here is the package deal we're running for this week
Currently Practicing Medical Doctors in America
788,614 in total * 17,576 emails
34 primary and secondary specialties
Sort by over a dozen different fields
American Pharmaceutical Company Contact List
47,000 personal emails and names of decision makers
Contact List of US Hospitals
23,000 Admins in more than 7,000 hospitals {a $399 value]
Extensive List of Dentists in the United States
More than half a million listings [worth $499 alone!]
Chiropractors in the USA
Over than 100k chiropractors practicing in the United States
Reduced to only:
$397 for everything
Email us at: [EMAIL PROTECTED]
valid thru Jan 11
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] mmu notifiers
On Thu, 10 Jan 2008, Avi Kivity wrote: > So this is yet another instance of hardware that has a tlb that needs to be > kept in sync with the page tables, yes? Correct. > Excellent, the more users the patch has, the easier it will be to justify it. We'd like to make sure though that we can sleep when the hooks have been called. We may have to sent a message to kick remote ptes out when local pte changes happen. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] mmu notifiers
On Thu, 10 Jan 2008, Avi Kivity wrote: > Actually sharing memory is possible even without this patch; one simply > mmap()s a file into the address space of both guests. Or are you referring to > something else? A file from where? If a file is read by two guests then they will have distinct page structs. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: [PATCH] e1000 emulation code
On Thu, Jan 10, 2008 at 03:36:19PM +, Paul Brook wrote: > > the next step would be to emulate LSI SCSI chips, eh? > > Qemu already does. Quite a different one from vmware, though :) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] e1000 emulation code
Hi, On 09/01/2008, Dor Laor <[EMAIL PROTECTED]> wrote: > It which supports TCP/UDP and IP transmit checksum, as well as TSO. > It has been tested with Linux (2.6.18|22|23|24)++ and Windows XP (using > the driver supplied at the intel download site). > Windows Vista recognizes it but there is no traffic. > > Checksum calculation is currently naïve and unoptimized (the host > kernel does it better). But when working in conjuction to tso > the performance is drastically better. > > Some figures: Linux rx 350Mbps, tx 150bps, Windows rx 700mbps, tx 100 mbps. That will be great to have in qemu. > > The e1000_hw.h is copied from Linux kernel. Would it be possible to pick only the useful stuff from the header and put it into the same file, rather than maintaining a copy of a linux header (which is 3.5 bigger than the actual emulation in kLoC)? Qemu has avoided that until now. > qemu/hw/e1000.c | 1000 +++ > qemu/hw/e1000_hw.h | 3411 ++ Regards. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] portability: configure top level dependencies per architecture
This includes the comments from Avi to "[PATCH] portability: add top level config-$arch files v2". Putting the arch dependencies into if's saves us 4 config-$arch files which are not essential to fix the current issue. Since this is copy&paste from Avis response to v2 I added him to the From list changes to v2: - remove config-$arch files - put arch dep in if's checking the arch to add more dependencies to a target directly in the top level Makefile --- Subject: [PATCH] portability: configure top level dependencies per architecture From: Christian Ehrhardt <[EMAIL PROTECTED]> From: Avi Kivity [EMAIL PROTECTED] This allows per arch configuration for the top level Makefile of kvm-userspace e.g. allowing to disable extboot for non x86 or disabling kvmctl build until ported to an architecture. Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> Makefile | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -7,14 +7,20 @@ rpmrelease = devel .PHONY: kernel user libkvm qemu bios vgabios extboot clean -all: $(if $(WANT_MODULE), kernel) user libkvm qemu +all: libkvm qemu +ifneq '$(filter $(ARCH), x86_64 i386 ia64)' '' +all: $(if $(WANT_MODULE), kernel) user +endif kcmd = $(if $(WANT_MODULE),,@\#) qemu kernel user libkvm: $(MAKE) -C $@ -qemu: libkvm extboot +qemu: libkvm +ifneq '$(filter $(ARCH), i386 x86_64)' '' +qemu: extboot +endif user: libkvm bios: - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM and Vista question
Hello All, I was trying to get Vista 64-bit to boot off QEMU and was pointed to this list from the QEMU developers list. From the guest compatibility page I could gather that KVM with Intel host is able to boot a Vista 64-bit guest, however the stand-alone version of QEMU does not (yet) support booting Vista. Could someone please provide more insight as to how this is achieved. My understanding is that there are problems in: 1. ACPI code in QEMU BIOS 2. Deficiencies in device model I believe that these issues are addressed in the QEMU tree being maintained with KVM. Is there anything additional which KVM does to get Vista to work? Thanks for the help. Regards, Anup - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio_net and SMP guests
Am Donnerstag, 10. Januar 2008 schrieb Christian Borntraeger:
> Am Donnerstag, 10. Januar 2008 schrieb Christian Borntraeger:
> > Am Dienstag, 18. Dezember 2007 schrieb Rusty Russell:
> > > To me this points to doing interrupt suppression a different way. If
we
> > > have a ->disable_cb() virtio function, and call it before we call
> > > netif_rx_schedule, does that fix it?
> >
> > The fix looks good and I agree with it.
> >
> > There is one problem that I try to find for some days, but the following
> > BUG_ON triggers:
> >
> > static void vring_disable_cb(struct virtqueue *_vq)
> > {
> > struct vring_virtqueue *vq = to_vvq(_vq);
> >
> > START_USE(vq);
> > > BUG_ON(vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT);
> > vq->vring.avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
> > END_USE(vq);
> > }
>
> Ok, I found it:
>
> static int virtnet_open(struct net_device *dev)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> try_fill_recv(vi);
> /* If we didn't even get one input buffer, we're useless. */
> if (vi->num == 0)
> return -ENOMEM;
> ---> int for new packet
> static void skb_recv_done(struct
> virtqueue *rvq)
> {
> struct virtnet_info *vi =
> rvq->vdev->priv;
> /* Suppress further interrupts.
> */
> rvq->vq_ops->disable_cb(rvq);
> netif_rx_schedule(vi->dev,
> &vi->napi);
> }
> - poll is not yet possible, no softirq
> - return from interrupt
> napi_enable(&vi->napi);
> vi->rvq->vq_ops->disable_cb(vi->rvq);
> ---> BUG: its already disabled
Btw. this problem also happens on single processor guests.
What about the following patch:
---
drivers/net/virtio_net.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: kvm/drivers/net/virtio_net.c
===
--- kvm.orig/drivers/net/virtio_net.c
+++ kvm/drivers/net/virtio_net.c
@@ -179,9 +179,12 @@ static void try_fill_recv(struct virtnet
static void skb_recv_done(struct virtqueue *rvq)
{
struct virtnet_info *vi = rvq->vdev->priv;
- /* Suppress further interrupts. */
- rvq->vq_ops->disable_cb(rvq);
- netif_rx_schedule(vi->dev, &vi->napi);
+ /* Schedule NAPI, Suppress further interrupts if successful. */
+
+ if (netif_rx_schedule_prep(vi->dev, &vi->napi)) {
+ rvq->vq_ops->disable_cb(rvq);
+ __netif_rx_schedule(vi->dev, &vi->napi);
+ }
}
static int virtnet_poll(struct napi_struct *napi, int budget)
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio_net and SMP guests
Am Donnerstag, 10. Januar 2008 schrieb Christian Borntraeger:
> Am Dienstag, 18. Dezember 2007 schrieb Rusty Russell:
> > To me this points to doing interrupt suppression a different way. If we
> > have a ->disable_cb() virtio function, and call it before we call
> > netif_rx_schedule, does that fix it?
>
> The fix looks good and I agree with it.
>
> There is one problem that I try to find for some days, but the following
> BUG_ON triggers:
>
> static void vring_disable_cb(struct virtqueue *_vq)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
>
> START_USE(vq);
> > BUG_ON(vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT);
> vq->vring.avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
> END_USE(vq);
> }
Ok, I found it:
static int virtnet_open(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
try_fill_recv(vi);
/* If we didn't even get one input buffer, we're useless. */
if (vi->num == 0)
return -ENOMEM;
---> int for new packet
static void skb_recv_done(struct
virtqueue *rvq)
{
struct virtnet_info *vi =
rvq->vdev->priv;
/* Suppress further interrupts.
*/
rvq->vq_ops->disable_cb(rvq);
netif_rx_schedule(vi->dev,
&vi->napi);
}
- poll is not yet possible, no softirq
- return from interrupt
napi_enable(&vi->napi);
vi->rvq->vq_ops->disable_cb(vi->rvq);
---> BUG: its already disabled
Christian
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] RFC: MMIO endianness flag
On Jan 10, 2008, at 10:23 AM, Hollis Blanchard wrote: > On Thu, 2008-01-10 at 08:56 +0200, Avi Kivity wrote: >> >> IIRC endianness is a per-page attribute on ppc, no? Otherwise you'd >> have a global attribute instead of per-access. > > The MMU in some PowerPC can have per-page endianness, but not all. > On a > processor that supports this attribute, I expect that when an MMIO > trap > occurs we'll need to inspect the guest MMU state in order to set the > is_bigendian flag correctly. Hey.. don't forget MSR[LE]. -JX > > The real issue I'm looking at right now is byte-reversed loads and > stores. For example, "lwzx" (Load Word and Zero Indexed) does a > big-endian 4-byte load, while "lwbrx" (Load Word Byte-Reverse Indexed) > does a little-endian 4-byte load. These instructions exist on all > PowerPC, and they can be issued at any time and do not depend on MMU > mappings. > > -- > Hollis Blanchard > IBM Linux Technology Center > > > -- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/ > marketplace > ___ > kvm-ppc-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: [PATCH] e1000 emulation code
> the next step would be to emulate LSI SCSI chips, eh? Qemu already does. Paul - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Where are vmentry failure caugth?
Guillaume Thouvenin wrote: > On Thu, 10 Jan 2008 11:19:58 +0100 > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: > > >> I tried but it didn't catch any vmentry failures (and I know that >> there is at least one during the test). >> > > I think that there is a vmentry failure because qemu-system-x86_64 > crashes with following error: > "exception 13 (33)" > > I interpreted this as a vmentry failure because 33 is the exit reason > for a vmentry failure. The problem is that I don't find how to catch it > in kvm. I thought that something like: > I think 33 is the error code, which means we got a general protection fault while accessing segment 0x33. What guest code is running when this happens? The dump sometimes includes the current code. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC: MMIO endianness flag
Hollis Blanchard wrote: > On Thu, 2008-01-10 at 08:56 +0200, Avi Kivity wrote: > >> IIRC endianness is a per-page attribute on ppc, no? Otherwise you'd >> have a global attribute instead of per-access. >> > > The MMU in some PowerPC can have per-page endianness, but not all. On a > processor that supports this attribute, I expect that when an MMIO trap > occurs we'll need to inspect the guest MMU state in order to set the > is_bigendian flag correctly. > > The real issue I'm looking at right now is byte-reversed loads and > stores. For example, "lwzx" (Load Word and Zero Indexed) does a > big-endian 4-byte load, while "lwbrx" (Load Word Byte-Reverse Indexed) > does a little-endian 4-byte load. These instructions exist on all > PowerPC, and they can be issued at any time and do not depend on MMU > mappings. > Okay, so it's at instruction granularity _and_ page granularity. I'll apply that patch (with a #ifdef CONFIG_PPC so other archs don't use it by mistake). -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC: MMIO endianness flag
On Thu, 2008-01-10 at 08:56 +0200, Avi Kivity wrote: > > IIRC endianness is a per-page attribute on ppc, no? Otherwise you'd > have a global attribute instead of per-access. The MMU in some PowerPC can have per-page endianness, but not all. On a processor that supports this attribute, I expect that when an MMIO trap occurs we'll need to inspect the guest MMU state in order to set the is_bigendian flag correctly. The real issue I'm looking at right now is byte-reversed loads and stores. For example, "lwzx" (Load Word and Zero Indexed) does a big-endian 4-byte load, while "lwbrx" (Load Word Byte-Reverse Indexed) does a little-endian 4-byte load. These instructions exist on all PowerPC, and they can be issued at any time and do not depend on MMU mappings. -- Hollis Blanchard IBM Linux Technology Center - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] mmu notifiers
On Thu, Jan 10, 2008 at 03:27:24PM +0200, Avi Kivity wrote: > Robin Holt wrote: >> >>> The patch does enable some nifty things; one example you may be familiar >>> with is using page migration to move a guest from one numa node to >>> another. >>> >> >> xpmem allows one MPI rank to "export" his address space, a different >> MPI rank to "import" that address space, and they share the same pages. >> This allows sharing of things like stack and heap space. XPMEM also >> provides a mechanism to share that PFN information across partition >> boundaries so the pages become available on a different host. This, >> of course, is dependent upon hardware that supports direct access to >> the memory by the processor. >> >> > > So this is yet another instance of hardware that has a tlb that needs to be > kept in sync with the page tables, yes? Yep, the external TLBs happen to be cpus in a different OS instance, but you get the idea. > Excellent, the more users the patch has, the easier it will be to justify > it. I think we have another hardware device driver that will use it first. It is sort of a hardware coprocessor that is available from user space to do operations against a processes address space. That driver will probably be first out the door. Looking at the mmu_notifiers patch, there are locks held which will preclude the use of invalidate_page for xpmem. In that circumstance, the clearing operation will need to be messaged to the other OS instance and that will certainly involving putting the current task to sleep. We will work on that detail later. First, we will focus on getting the other driver submitted to the community. Thanks, Robin - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Where are vmentry failure caugth?
On Thu, 10 Jan 2008 11:19:58 +0100
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> I tried but it didn't catch any vmentry failures (and I know that
> there is at least one during the test).
I think that there is a vmentry failure because qemu-system-x86_64
crashes with following error:
"exception 13 (33)"
I interpreted this as a vmentry failure because 33 is the exit reason
for a vmentry failure. The problem is that I don't find how to catch it
in kvm. I thought that something like:
static int
kvm_handle_exit(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
u32 exit_reason = vmcs_read32(VM_EXIT_REASON);
struct vcpu_vmx *vmx = to_vmx(vcpu);
u32 vectoring_info = vmx->idt_vectoring_info;
if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
// I should get it here no?
...
}
but exit_reason is never equal to VMX_EXIT_REASONS_FAILED_VMENTRY. Does
it mean that what I interpret as a vmentry failure due to invalid guest
state is in fact due to something else.
Any hints to catch the vmentry failure due to invalid guest state in
kvm?
Thanks,
Guillaume
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] mmu notifiers
Robin Holt wrote: > >> The patch does enable some nifty things; one example you may be familiar >> with is using page migration to move a guest from one numa node to another. >> > > xpmem allows one MPI rank to "export" his address space, a different > MPI rank to "import" that address space, and they share the same pages. > This allows sharing of things like stack and heap space. XPMEM also > provides a mechanism to share that PFN information across partition > boundaries so the pages become available on a different host. This, > of course, is dependent upon hardware that supports direct access to > the memory by the processor. > > So this is yet another instance of hardware that has a tlb that needs to be kept in sync with the page tables, yes? Excellent, the more users the patch has, the easier it will be to justify it. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] mmu notifiers
On Thu, Jan 10, 2008 at 01:44:18PM +0200, Avi Kivity wrote: > Christoph Lameter wrote: >> On Wed, 9 Jan 2008, Andrea Arcangeli wrote: >> >> >>> This patch is a first basic implementation of the mmu notifiers. More >>> methods can be added in the future. >>> >>> In short when the linux VM decides to free a page, it will unmap it >>> from the linux pagetables. However when a page is mapped not just by >>> the regular linux ptes, but also from the shadow pagetables, it's >>> currently unfreeable by the linux VM. >>> >> >> Such a patch would also address issues that SGI has with exporting >> mappings via XPMEM. Plus a variety of other uses. Go ahead and lets do >> more in this area. >> >> Are the KVM folks interested in exporting memory from one guest to >> another? That may also become possible with some of the work that we have >> in progress and that also requires a patch like this. >> >> > > Actually sharing memory is possible even without this patch; one simply > mmap()s a file into the address space of both guests. Or are you referring > to something else? He is referring to the xpmem work SGI has pushed in the past. It was rejected precisely because this type functionality did not exist. We were trying to determine the cleanest yet smallest acceptable implementation when this suddenly sprang up. I would expect Dean Nelson or myself to repost the xpmem patch set again based upon this patche. > The patch does enable some nifty things; one example you may be familiar > with is using page migration to move a guest from one numa node to another. xpmem allows one MPI rank to "export" his address space, a different MPI rank to "import" that address space, and they share the same pages. This allows sharing of things like stack and heap space. XPMEM also provides a mechanism to share that PFN information across partition boundaries so the pages become available on a different host. This, of course, is dependent upon hardware that supports direct access to the memory by the processor. Thanks, Robin - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] kvm balloon guest driver (v2)
On Thu, 2008-01-10 at 21:27 +0900, Akio Takebe wrote:
> Hi, Marcelo
>
> >> >+static int kvm_balloon_inflate(struct virtballoon *v, int32_t npages)
> >> >+{
> >> >+ LIST_HEAD(tmp_list);
> >> >+ struct page *page, *tmp;
> >> >+ struct balloon_buf *buf;
> >> >+ u32 *pfn;
> >> >+ int allocated = 0;
> >> >+ int i, r = -ENOMEM;
> >> >+
> >> >+ buf = alloc_balloon_buf(v->vdev, GFP_KERNEL);
> >> When does balloon driver free the buf?
> >
> >Hi Akio,
> >
> >The buffers are passed from the virtio handling routine to the balloon_thread
> >through the balloon_work list, and then freed here:
> >
> >+ spin_lock_irq(&v->queue_lock);
> >+ while (!list_empty(&v->balloon_work)) {
> >+ struct balloon_work *work;
> >+ struct balloon_buf *buf;
> >+
> >+ work = list_entry(v->balloon_work.next,
> >+struct balloon_work, list);
> >+ list_del(&work->list);
> >+ spin_unlock_irq(&v->queue_lock);
> >+ buf = work->buf;
> >+ kfree(work);
> >+
> >+ switch(buf->hdr.cmd) {
> >+ case CMD_BALLOON_DEFLATE:
> >+ deflate_done(v, buf);
> >+ break;
> >+ case CMD_BALLOON_INFLATE:
> >+ inflate_done(v, buf);
> >+ break;
> >+ default:
> >+ printk("%s: unknown cmd 0x%x\n", __func__,
> >+ buf->hdr.cmd);
> >+ }
> >+ kfree(buf);
> Thank you for your exlanation.
> Does balloon free the buf when kvm_balloon_xflate() retrun -ENOMEM?
It return -ENOMEM only when kvm_balloon_inflate fails.
We just need to handle this case a little better - there is no leak but
the xflate function or the balloon thread need to check the value
and update the host that it failed to reach the requested balloon size.
> Akio Takebe
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] kvm/qemu: Fix ia64 build broken.
On Sat, Jan 05, 2008 at 07:53:03PM -0600, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > there has to be something wrong with your build system as from the log it > seems you are using "-I /include " which most likely doesn't exist right, that was the problem. for the record, i needed ./configure --kerneldir=`pwd`/kernel, rather than /usr/src/linux and now it works fine. thanks for your help, - VMiklos pgpQvSL3KtHdQ.pgp Description: PGP signature - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio_net and SMP guests
Am Dienstag, 18. Dezember 2007 schrieb Rusty Russell:
> To me this points to doing interrupt suppression a different way. If we
> have a ->disable_cb() virtio function, and call it before we call
> netif_rx_schedule, does that fix it?
The fix looks good and I agree with it.
There is one problem that I try to find for some days, but the following
BUG_ON triggers:
static void vring_disable_cb(struct virtqueue *_vq)
{
struct vring_virtqueue *vq = to_vvq(_vq);
START_USE(vq);
> BUG_ON(vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT);
vq->vring.avail->flags |= VRING_AVAIL_F_NO_INTERRUPT;
END_USE(vq);
}
The funny thing is, that this bit is correct during probe but changes later
before open. It seems that there is still something fishy on s390 and
virtio.
I looked several times at the virtio_ring code and it really seems to be ok.
Any ideas?
Christian
the oops that I cannot explain -
kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:232!
illegal operation: 0001 [#1]
Modules linked in:
CPU:0Not tainted
Process ip (pid: 1583, task: 0eee7038, ksp: 0ec4beb8)
Krnl PSW : 070430018000 0045dcd4 (vring_disable_cb+0x30/0x34)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
Krnl GPRS: 03ff0002 0001 10001800
0045dca4
0f054800 00595a80
00897768 03ff1002 0f09c920
0ec4bbf8
0f09c900 00596b20 0045c9c6
0ec4bbf8
Krnl Code: 0045dcc8: e3b0b074 lg %r11,112(%r11)
0045dcce: 07fe bcr 15,%r14
0045dcd0: a7f40001 brc 15,45dcd2
>0045dcd4: a7f4fff6 brc 15,45dcc0
0045dcd8: eb7ff0500024 stmg%r7,%r15,80(%r15)
0045dcde: a7f13e00 tmll%r15,15872
0045dce2: b90400ef lgr %r14,%r15
0045dce6: a7840001 brc 8,45dce8
Call Trace:
([<0045c95e>] virtnet_open+0x32/0x114)
[<0048cbac>] dev_open+0xb0/0xe8
[<0048b6a2>] dev_change_flags+0x156/0x1cc
[<004ead02>] devinet_ioctl+0x5ae/0x728
[<004eb564>] inet_ioctl+0xa4/0xf0
[<004798dc>] sock_ioctl+0x90/0x2e4
[<001b8bd2>] do_ioctl+0x4a/0xd4
[<001b8cda>] vfs_ioctl+0x7e/0x3c8
[<001b90b6>] sys_ioctl+0x92/0xa4
[<00112e7c>] sysc_noemu+0x10/0x16
[<0212c7e6>] 0x212c7e6
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] kvm balloon guest driver (v2)
Hi, Marcelo
>> >+static int kvm_balloon_inflate(struct virtballoon *v, int32_t npages)
>> >+{
>> >+ LIST_HEAD(tmp_list);
>> >+ struct page *page, *tmp;
>> >+ struct balloon_buf *buf;
>> >+ u32 *pfn;
>> >+ int allocated = 0;
>> >+ int i, r = -ENOMEM;
>> >+
>> >+ buf = alloc_balloon_buf(v->vdev, GFP_KERNEL);
>> When does balloon driver free the buf?
>
>Hi Akio,
>
>The buffers are passed from the virtio handling routine to the balloon_thread
>through the balloon_work list, and then freed here:
>
>+ spin_lock_irq(&v->queue_lock);
>+ while (!list_empty(&v->balloon_work)) {
>+ struct balloon_work *work;
>+ struct balloon_buf *buf;
>+
>+ work = list_entry(v->balloon_work.next,
>+struct balloon_work, list);
>+ list_del(&work->list);
>+ spin_unlock_irq(&v->queue_lock);
>+ buf = work->buf;
>+ kfree(work);
>+
>+ switch(buf->hdr.cmd) {
>+ case CMD_BALLOON_DEFLATE:
>+ deflate_done(v, buf);
>+ break;
>+ case CMD_BALLOON_INFLATE:
>+ inflate_done(v, buf);
>+ break;
>+ default:
>+ printk("%s: unknown cmd 0x%x\n", __func__,
>+ buf->hdr.cmd);
>+ }
>+ kfree(buf);
Thank you for your exlanation.
Does balloon free the buf when kvm_balloon_xflate() retrun -ENOMEM?
Best Regards,
Akio Takebe
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] kvm balloon guest driver (v2)
On Thu, Jan 10, 2008 at 04:11:51PM +0900, Akio Takebe wrote:
> Hi, Marcelo
>
> >+struct balloon_buf *alloc_balloon_buf(struct virtio_device *vdev, gfp_t
> >flags)
> >+{
> >+struct balloon_buf *buf;
> >+
> >+buf = kzalloc(sizeof(struct balloon_buf), flags);
> >+if (!buf)
> >+dev_printk(KERN_ERR, &vdev->dev, "%s: alloc fail\n", __func__);
> >+
> >+return buf;
> >+}
> >+
> [snip..]
> >+static int kvm_balloon_inflate(struct virtballoon *v, int32_t npages)
> >+{
> >+LIST_HEAD(tmp_list);
> >+struct page *page, *tmp;
> >+struct balloon_buf *buf;
> >+u32 *pfn;
> >+int allocated = 0;
> >+int i, r = -ENOMEM;
> >+
> >+buf = alloc_balloon_buf(v->vdev, GFP_KERNEL);
> When does balloon driver free the buf?
Hi Akio,
The buffers are passed from the virtio handling routine to the balloon_thread
through the balloon_work list, and then freed here:
+ spin_lock_irq(&v->queue_lock);
+ while (!list_empty(&v->balloon_work)) {
+ struct balloon_work *work;
+ struct balloon_buf *buf;
+
+ work = list_entry(v->balloon_work.next,
+struct balloon_work, list);
+ list_del(&work->list);
+ spin_unlock_irq(&v->queue_lock);
+ buf = work->buf;
+ kfree(work);
+
+ switch(buf->hdr.cmd) {
+ case CMD_BALLOON_DEFLATE:
+ deflate_done(v, buf);
+ break;
+ case CMD_BALLOON_INFLATE:
+ inflate_done(v, buf);
+ break;
+ default:
+ printk("%s: unknown cmd 0x%x\n", __func__,
+ buf->hdr.cmd);
+ }
+ kfree(buf);
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] e1000 emulation code
On Wed, 2008-01-09 at 23:08 -0500, Javier Guerra Giraldez wrote: > On Wednesday 09 January 2008, Dor Laor wrote: > > Some figures: Linux rx 350Mbps, tx 150bps, Windows rx 700mbps, tx 100 mbps. > > very nice! > > in a related note, the VMWare tools package, which is supposed to 'enhance > performance' by installing 'specially tuned' drivers into a guest, doesn't > include net or HD drivers for linux! i was surprised, but it simply said Vmware has a nice trick to online change an emulated amd nic into a pv mode nic. > that using e1000 emulation on 64bit linux was optimised enough. since i saw > good performance (no hard benchmarks, but definitely not bad); i thought that > they do some paravirtualizification at runtime as part of their software > recompiling (because they're much older than HVM-capable processors). > > now it seems that there are higher-level hardware that can be emulated far > more efficiently than the original set of QEMU hardware. This is just a newer device with some coalescing abilities and tso, pv driver can always be better since they are not bound to any specification. btw: I wonder when qemu will get virtio drivers. > > the next step would be to emulate LSI SCSI chips, eh? > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] mmu notifiers
Christoph Lameter wrote: > On Wed, 9 Jan 2008, Andrea Arcangeli wrote: > > >> This patch is a first basic implementation of the mmu notifiers. More >> methods can be added in the future. >> >> In short when the linux VM decides to free a page, it will unmap it >> from the linux pagetables. However when a page is mapped not just by >> the regular linux ptes, but also from the shadow pagetables, it's >> currently unfreeable by the linux VM. >> > > Such a patch would also address issues that SGI has with exporting > mappings via XPMEM. Plus a variety of other uses. Go ahead and lets do > more in this area. > > Are the KVM folks interested in exporting memory from one guest to > another? That may also become possible with some of the work that we have > in progress and that also requires a patch like this. > > Actually sharing memory is possible even without this patch; one simply mmap()s a file into the address space of both guests. Or are you referring to something else? The patch does enable some nifty things; one example you may be familiar with is using page migration to move a guest from one numa node to another. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Pass through SSSE3 capability
Dan Kenigsberg wrote: > On Wed, Jan 09, 2008 at 07:46:04PM +0100, Alexander Graf wrote: > >> Darwin requires SSSE3 in 64-bit mode, so KVM needs to reveal the >> appropriate CPUID flag. I could not find a proper define in the kernel >> headers, so I just added the specific bit number. >> > > >> Index: kernel/x86.c >> === >> --- kernel.orig/x86.c >> +++ kernel/x86.c >> @@ -898,7 +903,7 @@ static void do_cpuid_ent(struct kvm_cpui >> bit(X86_FEATURE_3DNOWEXT) | >> bit(X86_FEATURE_3DNOW); >> const u32 kvm_supported_word3_x86_features = >> -bit(X86_FEATURE_XMM3) | bit(X86_FEATURE_CX16); >> +bit(X86_FEATURE_XMM3) | bit(X86_FEATURE_CX16) | bit(9) /* SSSE3 >> */; >> const u32 kvm_supported_word6_x86_features = >> bit(X86_FEATURE_LAHF_LM) | bit(X86_FEATURE_CMP_LEGACY); >> >> >> > > I bet that one day this will be added to asm-x86/cpufeature_32.h, so maybe > adding the following would be nicer. > I agree. Do I need to send a new patch including this as the patch is really small? > diff --git a/kernel/external-module-compat.h b/kernel/external-module-compat.h > index 67b9cc4..0e2bc4c 100644 > --- a/kernel/external-module-compat.h > +++ b/kernel/external-module-compat.h > @@ -566,6 +566,9 @@ static inline void blahblah(void) > #ifndef X86_FEATURE_NX > #define X86_FEATURE_NX (1*32+20) > #endif > +#ifndef X86_FEATURE_SSSE3 > +#define X86_FEATURE_SSSE3 (4*32+9) > +#endif > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Where are vmentry failure caugth?
Hello,
When a vmentry failure occurs, where is it caught? I see that
VMX_EXIT_REASONS_FAILED_VMENTRY is defined but I don't see where it is
used. Shouldn't there be something in handle_excetion() like:
static int handle_exception(struct kvm_vcpu *vcpu, struct kvm_run
*kvm_run) {
struct vcpu_vmx *vmx = to_vmx(vcpu);
u32 intr_info, error_code, exit_reason;
unsigned long cr2, rip;
u32 vect_info;
enum emulation_result er;
vect_info = vmx->idt_vectoring_info;
intr_info = vmcs_read32(VM_EXIT_INTR_INFO);
exit_reason = vmcs_readl(VM_EXIT_REASON);
if (unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY))
/* check why and do something */
...
}
I tried but it didn't catch any vmentry failures (and I know that
there is at least one during the test).
The idea is to find failure due to invalid guest state (like with old
gfxboot bug) and emulate the code until the guest recovers a valid
state.
Regards,
Guillaume
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] portability: add top level config-$arch files v2
Christian Ehrhardt wrote: > This includes the comments from Jerone. Moving the targets back into the > Makefile e.g. easen things for people looking at the Makefile for the first > time and looking for targets. So here v2 of the patch. > changes to v1: > - defining per arch targets via variables in config-$arch > - removed that user is not build for ppc assuming Hollis patches >are accepted sometime soon > > --- > > Subject: [PATCH] portability: add top level config-$arch files v2 > From: Christian Ehrhardt <[EMAIL PROTECTED]> > > This allows per arch configuration for the top level Makefile of > kvm-userspace e.g. allowing to disable extboot for non x86 or disabling > kvmctl build until ported to an architecture. > I'm aware that we now have already 8 config-$arch files in kvm-userspace > and this patch adds 4 more so maybe we need some kind of consolidation in > the future - comments and approaches to that are very welcome. > > Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> > > Makefile |5 +++-- > b/config-i386.mak|2 ++ > b/config-ia64.mak|2 ++ > b/config-powerpc.mak |3 +++ > b/config-x86_64.mak |2 ++ > 5 files changed, 12 insertions(+), 2 deletions(-) > > diff -r d21fce8a6cd9 Makefile > --- a/MakefileWed Jan 09 10:49:03 2008 +0100 > +++ b/MakefileWed Jan 09 12:33:26 2008 +0100 > @@ -1,5 +1,6 @@ > > include config.mak > +include config-$(ARCH).mak > > DESTDIR= > > @@ -7,14 +8,14 @@ rpmrelease = devel > > .PHONY: kernel user libkvm qemu bios vgabios extboot clean > > -all: $(if $(WANT_MODULE), kernel) user libkvm qemu > +all: $(ARCH_ALL_DEP) > Only kernel and user may vary; we always need libkvm and qemu. This might also be simplified to: all: libkvm qemu ifneq '$(filter $(ARCH), x86_64 i386 ia64)' '' all: $(if $(WANT_MODULE), kernel) user endif > > kcmd = $(if $(WANT_MODULE),,@\#) > > qemu kernel user libkvm: > $(MAKE) -C $@ > > -qemu: libkvm extboot > +qemu: $(ARCH_QEMU_DEP) > Similarly, qemu always requires libkvm, so: qemu: libkvm ifneq '$(filter $(ARCH), i386 x86_64)' '' qemu: extboot endif -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] compile error
Hollis Blanchard wrote: > On Wed, 2008-01-09 at 10:39 +0200, Avi Kivity wrote: > >> Zhao, Yunfeng wrote: >> >>> Today's tip fails to compile with following error messages: >>> >>> >> [...] >> >> Fixed now. Hollis, I had to revert your asm symlink patch to fix this, >> so we need to find an alternative solution to that problem. >> > > qemu ends up including from /usr. > > libkvm, on the other hand, ends up including from the target > kernel tree. > > Since the two components are meaning completely different things when > referring to the "asm" directory, we should use different include paths. > The best long-term solution would probably be to remove "-I > $(KERNELDIR)/include" from libkvm, and instead build against a copy of > the KVM headers (maybe copied over with that "make sync" target?). > > Avi, I think you're responsible for all the build directory munging we > do currently; what do you think about that? > I agree. The traditional way is to build against installed headers; but we don't want to do that at this stage. So your suggestion is the closest thing. But we should make the sync target implicit so users don't have that additional step. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] architecture-specific data in struct kvm_run ?
Zhang, Xiantao wrote: > Hollis Blanchard wrote: > >> There are a bunch of x86-specific fields in struct kvm_run: >> /* in */ >> __u8 request_interrupt_window; >> __u8 padding1[7]; >> >> /* out */ >> __u8 if_flag; >> __u8 padding2[2]; >> >> /* in (pre_kvm_run), out (post_kvm_run) */ >> __u64 cr8; >> __u64 apic_base; >> >> Since this structure is shared with all architectures, can we find a >> more appropriate place to keep this data? Or should we feel free to >> add arch-specific data here? >> > Hollis, > > Maybe #ifdef is enough if we other archs doesn't need to add new more. > For IA64, we don't require new fields. > > I agree, ifdefs are best here. Maybe wrap them in a structure. -- error compiling committee.c: too many arguments to function - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] architecture-specific data in struct kvm_run ?
Hollis Blanchard wrote: > There are a bunch of x86-specific fields in struct kvm_run: > /* in */ > __u8 request_interrupt_window; > __u8 padding1[7]; > > /* out */ > __u8 if_flag; > __u8 padding2[2]; > > /* in (pre_kvm_run), out (post_kvm_run) */ > __u64 cr8; > __u64 apic_base; > > Since this structure is shared with all architectures, can we find a > more appropriate place to keep this data? Or should we feel free to add > arch-specific data here? Afaics, we'll need an arch extension to kvm_run. On s390, we'll need different extensions then x86 has defined here. And we don't need any of above fields. Carsten - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
