Re: [kvm-devel] kvm with usb slow
Hi Arnon, thanks a lot for the response, On Mo, 07 Jan 2008, Arnon Gilboa wrote: > USB redirection support in qemu is currently using synchronous ioctls, > which might block the guest for too long (>100usec). The current host > controller emulations allow only one pending transfer at a time, which > might slow down the guest as well. Ok, I understand. So anything which is a bit complicated usb device (like my GPS receiver) will have problems. > If you are using simple bulk device (disk on key, printer etc.), you can > try the patch of USB 2.0 EHCI emulation, recently submitted to > qemu-devel. It is at very preliminary stage, but still might be useful > for you. I will try (to find and use it). Thanks a lot and all the best Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- GLAZELEY (adj.) The state of a barrister's flat greasy hair after wearing a wig all day. --- Douglas Adams, The Meaning of Liff - 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: move kvm_fpu to asm-x86/kvm.h
Acked-by: Zhang Xiantao <[EMAIL PROTECTED]>
Christian Ehrhardt wrote:
> Subject: [PATCH] portability: move kvm_fpu to asm-x86/kvm.h
> From: Christian Ehrhardt <[EMAIL PROTECTED]>
>
> This patch moves kvm_fpu asm-x86/kvm.h to allow every architecture to
> define an own representation used for KVM_GET_FPU/KVM_SET_FPU.
>
> Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
> Acked-by: Carsten Otte <[EMAIL PROTECTED]>
>
> asm-x86/kvm.h | 15 +++
> linux/kvm.h | 17 -
> 2 files changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/include/asm-x86/kvm.h b/include/asm-x86/kvm.h
> index 17afa81..7a71120 100644
> --- a/include/asm-x86/kvm.h
> +++ b/include/asm-x86/kvm.h
> @@ -114,6 +114,21 @@ struct kvm_sregs {
> __u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
> };
>
> +/* for KVM_GET_FPU and KVM_SET_FPU */
> +struct kvm_fpu {
> + __u8 fpr[8][16];
> + __u16 fcw;
> + __u16 fsw;
> + __u8 ftwx; /* in fxsave format */
> + __u8 pad1;
> + __u16 last_opcode;
> + __u64 last_ip;
> + __u64 last_dp;
> + __u8 xmm[16][16];
> + __u32 mxcsr;
> + __u32 pad2;
> +};
> +
> struct kvm_msr_entry {
> __u32 index;
> __u32 reserved;
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index b27a381..4de4fd2 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -142,23 +142,6 @@ struct kvm_run {
> };
> };
>
> -
> -/* for KVM_GET_FPU and KVM_SET_FPU */
> -struct kvm_fpu {
> - __u8 fpr[8][16];
> - __u16 fcw;
> - __u16 fsw;
> - __u8 ftwx; /* in fxsave format */
> - __u8 pad1;
> - __u16 last_opcode;
> - __u64 last_ip;
> - __u64 last_dp;
> - __u8 xmm[16][16];
> - __u32 mxcsr;
> - __u32 pad2;
> -};
> -
> -
> /* for KVM_TRANSLATE */
> struct kvm_translation {
> /* in */
-
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: move kvm_fpu to asm-x86/kvm.h
Subject: [PATCH] portability: move kvm_fpu to asm-x86/kvm.h
From: Christian Ehrhardt <[EMAIL PROTECTED]>
This patch moves kvm_fpu asm-x86/kvm.h to allow every architecture to
define an own representation used for KVM_GET_FPU/KVM_SET_FPU.
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
asm-x86/kvm.h | 15 +++
linux/kvm.h | 17 -
2 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/include/asm-x86/kvm.h b/include/asm-x86/kvm.h
index 17afa81..7a71120 100644
--- a/include/asm-x86/kvm.h
+++ b/include/asm-x86/kvm.h
@@ -114,6 +114,21 @@ struct kvm_sregs {
__u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
};
+/* for KVM_GET_FPU and KVM_SET_FPU */
+struct kvm_fpu {
+ __u8 fpr[8][16];
+ __u16 fcw;
+ __u16 fsw;
+ __u8 ftwx; /* in fxsave format */
+ __u8 pad1;
+ __u16 last_opcode;
+ __u64 last_ip;
+ __u64 last_dp;
+ __u8 xmm[16][16];
+ __u32 mxcsr;
+ __u32 pad2;
+};
+
struct kvm_msr_entry {
__u32 index;
__u32 reserved;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index b27a381..4de4fd2 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -142,23 +142,6 @@ struct kvm_run {
};
};
-
-/* for KVM_GET_FPU and KVM_SET_FPU */
-struct kvm_fpu {
- __u8 fpr[8][16];
- __u16 fcw;
- __u16 fsw;
- __u8 ftwx; /* in fxsave format */
- __u8 pad1;
- __u16 last_opcode;
- __u64 last_ip;
- __u64 last_dp;
- __u8 xmm[16][16];
- __u32 mxcsr;
- __u32 pad2;
-};
-
-
/* for KVM_TRANSLATE */
struct kvm_translation {
/* in */
-
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] Slow Kernel Boot
On Tuesday 08 January 2008 03:35:48 Dave Hansen wrote: > With kvm-44, I thought my kernel was freezing during boot if I gave it > 1G of RAM. But, it boots fine with 512M. > > So, I instrumented the kernel, and found out that it is just taking a > long time to memset a 58MB area of memory for mem_map[]. It appears to > be taking a mmio_exit for every access of every byte of memory. The end > result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. > > I just tried kvm from git, and the kernel doesn't even get that far. I > see this in debugfs > > insn_emulation:1393985 > > even before I get a single kernel message. And it keeps going up, fast. > I can get the kernel to boot just fine if I give it less than 896MB of > RAM. > > kvm-44 boots long enough for me to see a really funky e820 table: > > BIOS-provided physical RAM map: > BIOS-e820: - 0009fc00 (usable) > BIOS-e820: 0009fc00 - 000a (reserved) > BIOS-e820: 000e8000 - 0010 (reserved) > BIOS-e820: 0010 - fffbd000 (usable) > BIOS-e820: fffbd000 - (reserved) > > Note that this is with '-m 1G'!! It looks to me like one of those And there lies the problem. qemu doesn't understand suffixes like 'G'. If you pass -m 1024, you'll boot just fine. This is really annoying of qemu (it should either accept that input properly or bail out); a patch is welcome! > sections is basically from 0x10 up to ~4G and *usable*. That > doesn't look right. > > Eventually, the kvm-git one just pukes: > > exception 13 (33) > rax 0002 rbx 2000 rcx rdx > rsi 002a1358 rdi 00099100 rsp > 673a rbp 673a r8 r9 > r10 r11 r12 > r13 r14 r15 > rip fb24 rflags 00033086 > cs 9020 (00090200/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 9000 (0009/ 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 8f5c/27 > idt 0/3ff > cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> f0 01 > f0 03 0e 00 00 00 70 01 70 03 0f 00 00 00 e8 01 e0 03 0c 00 00 00 68 01 60 > 03 0b 00 Aborted > > Any idea how to debug this? > > -- Dave - 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] add acpi powerbutton support
On 1/7/08, Avi Kivity <[EMAIL PROTECTED]> wrote: > Guido Guenther wrote: > > (needs either --no-kvm-irqchip or the previous patch) > > -- Guido > > > > > > Applied both, thanks. > Sorry for my ignorance, but what is the effect of this patch? So I can shutdown guest VM cleanly, or smt else?? Thanks, Jun - 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] boot stops after console handover?
Carlo Marcelo Arenas Belon wrote: > On Mon, Jan 07, 2008 at 07:30:44PM +, Antoine Martin wrote: >> Avi Kivity wrote: >>> Antoine Martin wrote: Hi, Trying to boot KVM on a Core2Duo system, kvm-59 + linux-2.6.23.12 Booting with: qemu-system-x86_64 -hda /home/uml/BusyBox-1.5.0-amd64-root_fs -m 384 - -nographic -cpu qemu64 -kernel /boot/vmlinuz-2.6.23.12 -append "earlyprintk=serial,ttyS0,115200" >>> Does regular boot (without -kernel) work? >>> >> Nope, it's just spinning at 100% cpu, tried stock 2.6.23.12 and >> 2.6.24-rc6, lots of clock_gettime(CLOCK_MONOTONIC,... > > this is a big guess as I have no way to test it or know the internals well > enough to come with an authoritative answer, but I remember having a similar > problem once which was fixed by using the kernel option "nolapic" I assume this is for the host? (no effect on the guest) unfortunately that box won't boot with nolapic, the sata controllers timeout. (although I haven't tried turning apic off in the bios) >> Do I need to enable/disable some RTC / HPET options? > > there used to be a bug about it before which was closed by the reported > even though I was able to reproduce it after all (haven't looked since) and it > was related to the use of CONFIG_HPET_EMULATE_RTC=y in the guest kernel. I've disabled that, and everything else I could trim. Still no luck :( > sorry for not giving you any hard evidence, but I am just going from memory > here and though I would mention it just in case it could help. Thanks, much appreciated. gdb gives me this, dunno if this helps: #0 0x2b231784d777 in ioctl () from /lib/libc.so.6 #1 0x600ef2df in kvm_run (kvm=0x62541010, vcpu=0) at libkvm.c:901 #2 0x6008bdb6 in kvm_cpu_exec (env=) at /usr/src/kvm-59/qemu/qemu-kvm.c:143 #3 0x6008bf80 in kvm_main_loop_cpu (env=0x62546100) at /usr/src/kvm-59/qemu/qemu-kvm.c:341 #4 0x600108f7 in main (argc=8, argv=0x7fff9422e758) at /usr/src/kvm-59/qemu/vl.c:7771 Which is this: r = ioctl(fd, KVM_RUN, 0); where int fd = kvm->vcpu_fd[vcpu]; Antoine - 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] Slow Kernel Boot
On Tue, 2008-01-08 at 00:46 +0200, Izik Eidus wrote: > Dave Hansen wrote: > > On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote: > > > >> Dave Hansen wrote: > >> > >>> With kvm-44, I thought my kernel was freezing during boot if I gave it > >>> 1G of RAM. But, it boots fine with 512M. > >>> > >>> So, I instrumented the kernel, and found out that it is just taking a > >>> long time to memset a 58MB area of memory for mem_map[]. It appears to > >>> be taking a mmio_exit for every access of every byte of memory. The end > >>> result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. > >>> > >>> I just tried kvm from git, and the kernel doesn't even get that far. I > >>> see this in debugfs > >>> > >>> insn_emulation:1393985 > >>> > >>> even before I get a single kernel message. And it keeps going up, fast. > >>> I can get the kernel to boot just fine if I give it less than 896MB of > >>> RAM. > >>> > >>> kvm-44 boots long enough for me to see a really funky e820 table: > >>> > >>> BIOS-provided physical RAM map: > >>> BIOS-e820: - 0009fc00 (usable) > >>> BIOS-e820: 0009fc00 - 000a (reserved) > >>> BIOS-e820: 000e8000 - 0010 (reserved) > >>> BIOS-e820: 0010 - fffbd000 (usable) > >>> BIOS-e820: fffbd000 - (reserved) > >>> > >>> Note that this is with '-m 1G'!! It looks to me like one of those > >>> sections is basically from 0x10 up to ~4G and *usable*. That > >>> doesn't look right. > >>> > >>> > >> yea it really dont look right, it look like it for some reason map the > >> whole memory up untill the bios to the kernel as memory > >> it even map it on the pci hole so... > >> hrmmm, very weird, > >> > >> what is your host info (32/64 amd/intel kernel...)? > >> > > > > 64-bit intel host, kernel 2.6.24-rc5 > > > > Running kvm's current git userspace with modules from the same version. > > > > > >> and what is the > >> guest info (kernel 32/64...) ? > >> > > > > 32-bit 2.6.23-rc6-mm1 > > > > > >> and what happen if you run it with -no-kvm ? > >> > > > > Both current -git and kvm-44 seem to lock up at early kernel boot before > > even early printk is available. But, GRUB comes up in both cases. > > > > -no-kvm doesn't seem to change things at all. > > > > -- Dave > > > > > when you see the grub how much memory is it saying you have? GNU GRUB version 0.97 (639K lower / 4193279K upper memory) > how can i get the image that you are using? The disk images? I made them myself and I've been using them for quite a while. Probably a year or more. > (i dont know if it will be too much to ask, but if you run it with pure > qemu (from qemu.org) is it working?) Ahhh. I'm using the ubuntu one, and it does the same thing. I guess that means I found a qemu bug. > for some reason the e820 return a really false values for your guest... > i would have suggest to check if you have the latest kvm bios(not in > your physical computer bios) but it cannot be the problem as that you > dont run it with more than 3.something giga... Yeah, I just updated the BIOSes. They're right out of KVM's git repo. -- Dave - 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] Slow Kernel Boot
Dave Hansen wrote: > On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote: > >> Dave Hansen wrote: >> >>> With kvm-44, I thought my kernel was freezing during boot if I gave it >>> 1G of RAM. But, it boots fine with 512M. >>> >>> So, I instrumented the kernel, and found out that it is just taking a >>> long time to memset a 58MB area of memory for mem_map[]. It appears to >>> be taking a mmio_exit for every access of every byte of memory. The end >>> result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. >>> >>> I just tried kvm from git, and the kernel doesn't even get that far. I >>> see this in debugfs >>> >>> insn_emulation:1393985 >>> >>> even before I get a single kernel message. And it keeps going up, fast. >>> I can get the kernel to boot just fine if I give it less than 896MB of >>> RAM. >>> >>> kvm-44 boots long enough for me to see a really funky e820 table: >>> >>> BIOS-provided physical RAM map: >>> BIOS-e820: - 0009fc00 (usable) >>> BIOS-e820: 0009fc00 - 000a (reserved) >>> BIOS-e820: 000e8000 - 0010 (reserved) >>> BIOS-e820: 0010 - fffbd000 (usable) >>> BIOS-e820: fffbd000 - (reserved) >>> >>> Note that this is with '-m 1G'!! It looks to me like one of those >>> sections is basically from 0x10 up to ~4G and *usable*. That >>> doesn't look right. >>> >>> >> yea it really dont look right, it look like it for some reason map the >> whole memory up untill the bios to the kernel as memory >> it even map it on the pci hole so... >> hrmmm, very weird, >> >> what is your host info (32/64 amd/intel kernel...)? >> > > 64-bit intel host, kernel 2.6.24-rc5 > > Running kvm's current git userspace with modules from the same version. > > >> and what is the >> guest info (kernel 32/64...) ? >> > > 32-bit 2.6.23-rc6-mm1 > > >> and what happen if you run it with -no-kvm ? >> > > Both current -git and kvm-44 seem to lock up at early kernel boot before > even early printk is available. But, GRUB comes up in both cases. > > -no-kvm doesn't seem to change things at all. > > -- Dave > > when you see the grub how much memory is it saying you have? how can i get the image that you are using? (i dont know if it will be too much to ask, but if you run it with pure qemu (from qemu.org) is it working?) for some reason the e820 return a really false values for your guest... i would have suggest to check if you have the latest kvm bios(not in your physical computer bios) but it cannot be the problem as that you dont run it with more than 3.something giga... i am going to sleep now, i will look at this tomorrow (this is strange) thanks for reporting - 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] building kvm-userspace with separate kernel object directory?
Sorry for the cryptic language ;-o No your right. I wasn't thinking about that. On Mon, 2008-01-07 at 16:07 -0600, Hollis Blanchard wrote: > I'm having a hard time parsing this. > > Basically this patch is duplicating what Kbuild does: it is creating the > appropriate asm symlink. The original problem was that kvm-userspace > didn't have an asm symlink, so the patch does fix it. > - 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] Slow Kernel Boot
On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote: > Dave Hansen wrote: > > With kvm-44, I thought my kernel was freezing during boot if I gave it > > 1G of RAM. But, it boots fine with 512M. > > > > So, I instrumented the kernel, and found out that it is just taking a > > long time to memset a 58MB area of memory for mem_map[]. It appears to > > be taking a mmio_exit for every access of every byte of memory. The end > > result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. > > > > I just tried kvm from git, and the kernel doesn't even get that far. I > > see this in debugfs > > > > insn_emulation:1393985 > > > > even before I get a single kernel message. And it keeps going up, fast. > > I can get the kernel to boot just fine if I give it less than 896MB of > > RAM. > > > > kvm-44 boots long enough for me to see a really funky e820 table: > > > > BIOS-provided physical RAM map: > > BIOS-e820: - 0009fc00 (usable) > > BIOS-e820: 0009fc00 - 000a (reserved) > > BIOS-e820: 000e8000 - 0010 (reserved) > > BIOS-e820: 0010 - fffbd000 (usable) > > BIOS-e820: fffbd000 - (reserved) > > > > Note that this is with '-m 1G'!! It looks to me like one of those > > sections is basically from 0x10 up to ~4G and *usable*. That > > doesn't look right. > > > yea it really dont look right, it look like it for some reason map the > whole memory up untill the bios to the kernel as memory > it even map it on the pci hole so... > hrmmm, very weird, > > what is your host info (32/64 amd/intel kernel...)? 64-bit intel host, kernel 2.6.24-rc5 Running kvm's current git userspace with modules from the same version. > and what is the > guest info (kernel 32/64...) ? 32-bit 2.6.23-rc6-mm1 > and what happen if you run it with -no-kvm ? Both current -git and kvm-44 seem to lock up at early kernel boot before even early printk is available. But, GRUB comes up in both cases. -no-kvm doesn't seem to change things at all. -- Dave - 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] building kvm-userspace with separate kernel object directory?
oh your problem is you must first build your kernel that you are pointing too. Or you can cheat and point "include/asm" where you need to point it. That solves the issue. It's all that userspace including kernel headers :-) On Mon, 2008-01-07 at 15:12 -0600, Hollis Blanchard wrote: > I always build my kernels with the O= option, since it allows me to > build multiple architectures from the same sources. > > However, it looks like the kvm-userspace configure script can't handle > this. It says --kerneldir should be the kernel *build* directory, but > when I do that I get > libkvm.c:21:23: warning: linux/kvm.h: No such file or directory > because the build directory does not contain an include/linux symlink. > > When I specify the kernel *source* directory for --kerneldir, I get > /home/hollisb/source/kvmppc.hg/include/linux/kvm.h:12:21: warning: > asm/kvm.h: No such file or directory > because the source directory doesn't contain an include/asm symlink. > > How can this work? > - 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] boot stops after console handover?
On Mon, Jan 07, 2008 at 07:30:44PM +, Antoine Martin wrote: > Avi Kivity wrote: > > Antoine Martin wrote: > >> > >> Hi, > >> > >> Trying to boot KVM on a Core2Duo system, kvm-59 + linux-2.6.23.12 > >> Booting with: > >> qemu-system-x86_64 -hda /home/uml/BusyBox-1.5.0-amd64-root_fs -m 384 > >> - -nographic -cpu qemu64 -kernel /boot/vmlinuz-2.6.23.12 -append > >> "earlyprintk=serial,ttyS0,115200" > >> > >> > > > > Does regular boot (without -kernel) work? > > > Nope, it's just spinning at 100% cpu, tried stock 2.6.23.12 and > 2.6.24-rc6, lots of clock_gettime(CLOCK_MONOTONIC,... this is a big guess as I have no way to test it or know the internals well enough to come with an authoritative answer, but I remember having a similar problem once which was fixed by using the kernel option "nolapic" > Do I need to enable/disable some RTC / HPET options? there used to be a bug about it before which was closed by the reported even though I was able to reproduce it after all (haven't looked since) and it was related to the use of CONFIG_HPET_EMULATE_RTC=y in the guest kernel. sorry for not giving you any hard evidence, but I am just going from memory here and though I would mention it just in case it could help. Carlo - 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] Slow Kernel Boot
Dave Hansen wrote: > With kvm-44, I thought my kernel was freezing during boot if I gave it > 1G of RAM. But, it boots fine with 512M. > > So, I instrumented the kernel, and found out that it is just taking a > long time to memset a 58MB area of memory for mem_map[]. It appears to > be taking a mmio_exit for every access of every byte of memory. The end > result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. > > I just tried kvm from git, and the kernel doesn't even get that far. I > see this in debugfs > > insn_emulation:1393985 > > even before I get a single kernel message. And it keeps going up, fast. > I can get the kernel to boot just fine if I give it less than 896MB of > RAM. > > kvm-44 boots long enough for me to see a really funky e820 table: > > BIOS-provided physical RAM map: > BIOS-e820: - 0009fc00 (usable) > BIOS-e820: 0009fc00 - 000a (reserved) > BIOS-e820: 000e8000 - 0010 (reserved) > BIOS-e820: 0010 - fffbd000 (usable) > BIOS-e820: fffbd000 - (reserved) > > Note that this is with '-m 1G'!! It looks to me like one of those > sections is basically from 0x10 up to ~4G and *usable*. That > doesn't look right. > yea it really dont look right, it look like it for some reason map the whole memory up untill the bios to the kernel as memory it even map it on the pci hole so... hrmmm, very weird, what is your host info (32/64 amd/intel kernel...)? and what is the guest info (kernel 32/64...) ? and what happen if you run it with -no-kvm ? and are you using new kvm-userspace as well? or just new kvm kernel modules (or is is the oppiste?) - 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] building kvm-userspace with separate kernel object directory?
I'm having a hard time parsing this.
Basically this patch is duplicating what Kbuild does: it is creating the
appropriate asm symlink. The original problem was that kvm-userspace
didn't have an asm symlink, so the patch does fix it.
--
Hollis Blanchard
IBM Linux Technology Center
On Mon, 2008-01-07 at 15:50 -0600, Jerone Young wrote:
> Whoops should have replied to this one.
>
> So this does not solve the issue. As it point it includes
> /includes .. just you have to compile the kernel directory so
> that "include/asm" symlink in the kernel directory is made.
I have already done this. The asm symlink is located at
linux/objpowerpcsequoia/include/asm .
> This creates a symlink to the symlink and that symlnk which is already
> in include path -I $(KERNELDIR)/include
It does not create a symlink to a symlink: the link is asm ->
linux/include/asm-foo .
> What would probably be better is to add a check to see if
> /include/asm is created. If it's not give the user an error
> to compile there kernel source.
The issue is not that I have not compiled the kernel tree. I HAVE
compiled it, but I used the O= option when doing so.
> On Mon, 2008-01-07 at 15:29 -0600, Hollis Blanchard wrote:
> > Create an "asm" symlink from libkvm into the kernel source directory.
> > This allows one to use kernel trees built with the O= option.
> >
> > Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
> >
> > ---
> > This is all I can come up with... it should work by accident for user/
> > and qemu/ directories too, since they use "-I ../libkvm".
> >
> > diff --git a/configure b/configure
> > --- a/configure
> > +++ b/configure
> > @@ -130,6 +130,8 @@ fi
> >--arch="$arch" \
> >${cross_prefix:+"--cross-prefix=$cross_prefix"})
> >
> > +(cd libkvm; ln -sf "$kerneldir/include/asm-$arch" asm)
> > +
> > #configure qemu
> > (cd qemu; ./configure --target-list=$target_exec \
> > --disable-kqemu \
> > diff --git a/libkvm/Makefile b/libkvm/Makefile
> > --- a/libkvm/Makefile
> > +++ b/libkvm/Makefile
> > @@ -10,7 +10,7 @@ CFLAGS += $(autodepend-flags) -g -fomit-
> > CFLAGS += $(autodepend-flags) -g -fomit-frame-pointer -Wall
> > CFLAGS += $(call cc-option, -fno-stack-protector, "")
> > CFLAGS += $(call cc-option, -fno-stack-protector-all, "")
> > -CFLAGS += -I $(KERNELDIR)/include
> > +CFLAGS += -I $(KERNELDIR)/include -I .
> >
> > LDFLAGS += $(CFLAGS)
> >
> > @@ -35,4 +35,4 @@ install:
> > -include .*.d
> >
> > clean:
> > - $(RM) *.o *.a .*.d
> > + $(RM) *.o *.a .*.d asm
> >
-
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] Slow Kernel Boot
With kvm-44, I thought my kernel was freezing during boot if I gave it 1G of RAM. But, it boots fine with 512M. So, I instrumented the kernel, and found out that it is just taking a long time to memset a 58MB area of memory for mem_map[]. It appears to be taking a mmio_exit for every access of every byte of memory. The end result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. I just tried kvm from git, and the kernel doesn't even get that far. I see this in debugfs insn_emulation:1393985 even before I get a single kernel message. And it keeps going up, fast. I can get the kernel to boot just fine if I give it less than 896MB of RAM. kvm-44 boots long enough for me to see a really funky e820 table: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - fffbd000 (usable) BIOS-e820: fffbd000 - (reserved) Note that this is with '-m 1G'!! It looks to me like one of those sections is basically from 0x10 up to ~4G and *usable*. That doesn't look right. Eventually, the kvm-git one just pukes: exception 13 (33) rax 0002 rbx 2000 rcx rdx rsi 002a1358 rdi 00099100 rsp 673a rbp 673a r8 r9 r10 r11 r12 r13 r14 r15 rip fb24 rflags 00033086 cs 9020 (00090200/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs 9000 (0009/ 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 8f5c/27 idt 0/3ff cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> f0 01 f0 03 0e 00 00 00 70 01 70 03 0f 00 00 00 e8 01 e0 03 0c 00 00 00 68 01 60 03 0b 00 Aborted Any idea how to debug this? -- Dave - 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] Remove tx_timer from virtio_net
On Tuesday 08 January 2008 07:36:45 Anthony Liguori wrote: > Avi and I were talking this afternoon and he suggested that we should > remove the tx_timer from the virtio_net front-end and replace it with a > tx_timer in the backend. > > Since the backend can suppress notifications, this is appealing since it > gives much more flexibility to the backend in determining how to do tx > batching. I've done a quick implementation and performance is pretty good. > > We may need an ABI change, however. When the backend disables > notifications, there is absolutely no way for the frontend to notify > anymore. In the case where the queue fills up, it cannot flush since > the backend has disabled notifications. To work around this, I had to > least notifications enabled and check for the case where the queue fills > up manually. > > I think a possible solution to this would be to differentiate between a > soft and hard notify. We would introduce a VRING_USED_F_NOTIFY_ON_FULL > and a VRING_AVAIL_F_NOTIFY_ON_FULL. > > The NO_NOTIFY variants would indicate that the other end never sends a > notify, whereas NOTIFY_ON_FULL would indicate that the other end never > sends a notify unless the queue fills up. Hi Anthony, I really like this (in proportion to my discomfort with the hrtimers hack, in fact). The good news is that I don't think we need a significant ABI change: I think we should have the vring_get_buf() failure path kick the other end unconditionally. This makes sense: the NO_INTERRUPT flag is really a "you don't need to interrupt me" hint; you're allowed to interrupt even if it's set. So it should be at worst harmless. It should work in the inter-guest case, for example. Rather than apply this, I will just drop the hrtimer patches, and do a separate "kick on queue full" patch. Thanks! Rusty. - 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] building kvm-userspace with separate kernel object directory?
Whoops should have replied to this one.
So this does not solve the issue. As it point it includes
/includes .. just you have to compile the kernel directory so
that "include/asm" symlink in the kernel directory is made.
This creates a symlink to the symlink and that symlnk which is already
in include path -I $(KERNELDIR)/include
What would probably be better is to add a check to see if
/include/asm is created. If it's not give the user an error
to compile there kernel source.
On Mon, 2008-01-07 at 15:29 -0600, Hollis Blanchard wrote:
> Create an "asm" symlink from libkvm into the kernel source directory.
> This allows one to use kernel trees built with the O= option.
>
> Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
>
> ---
> This is all I can come up with... it should work by accident for user/
> and qemu/ directories too, since they use "-I ../libkvm".
>
> diff --git a/configure b/configure
> --- a/configure
> +++ b/configure
> @@ -130,6 +130,8 @@ fi
>--arch="$arch" \
>${cross_prefix:+"--cross-prefix=$cross_prefix"})
>
> +(cd libkvm; ln -sf "$kerneldir/include/asm-$arch" asm)
> +
> #configure qemu
> (cd qemu; ./configure --target-list=$target_exec \
> --disable-kqemu \
> diff --git a/libkvm/Makefile b/libkvm/Makefile
> --- a/libkvm/Makefile
> +++ b/libkvm/Makefile
> @@ -10,7 +10,7 @@ CFLAGS += $(autodepend-flags) -g -fomit-
> CFLAGS += $(autodepend-flags) -g -fomit-frame-pointer -Wall
> CFLAGS += $(call cc-option, -fno-stack-protector, "")
> CFLAGS += $(call cc-option, -fno-stack-protector-all, "")
> -CFLAGS += -I $(KERNELDIR)/include
> +CFLAGS += -I $(KERNELDIR)/include -I .
>
> LDFLAGS += $(CFLAGS)
>
> @@ -35,4 +35,4 @@ install:
> -include .*.d
>
> clean:
> - $(RM) *.o *.a .*.d
> + $(RM) *.o *.a .*.d asm
>
-
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 3/3][QEMU] Support TX mitigation in QEMU's virtio_net device
This patch adds support for TX mitigation in QEMU using the new NOTIFY_ON_FULL
virtio ring flag.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 3940743..5fd4114 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -14,6 +14,7 @@
#include "virtio.h"
#include "net.h"
#include "pc.h"
+#include "qemu-timer.h"
/* from Linux's virtio_net.h */
@@ -28,6 +29,10 @@
#define VIRTIO_NET_F_TSO6 4
#define VIRTIO_NET_F_MAC 5
+#define USE_TX_TIMER
+
+#define TX_TIMER_INTERVAL (1000 / 500)
+
/* The config defining mac address (6 bytes) */
struct virtio_net_config
{
@@ -63,6 +68,8 @@ typedef struct VirtIONet
int tap_fd;
struct VirtIONet *next;
int do_notify;
+QEMUTimer *tx_timer;
+int tx_timer_active;
} VirtIONet;
static VirtIONet *VirtIONetHead = NULL;
@@ -222,10 +229,10 @@ again:
}
/* TX */
-static void virtio_net_handle_tx(VirtIODevice *vdev, VirtQueue *vq)
+static void virtio_net_flush_tx(VirtIONet *n, VirtQueue *vq)
{
-VirtIONet *n = to_virtio_net(vdev);
VirtQueueElement elem;
+int count = 0;
if (!(n->vdev.status & VIRTIO_CONFIG_S_DRIVER_OK))
return;
@@ -241,11 +248,39 @@ static void virtio_net_handle_tx(VirtIODevice *vdev,
VirtQueue *vq)
len += elem.out_sg[i].iov_len;
}
+ count++;
+
virtqueue_push(vq, &elem, sizeof(struct virtio_net_hdr) + len);
virtio_notify(&n->vdev, vq);
}
}
+static void virtio_net_handle_tx(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIONet *n = to_virtio_net(vdev);
+
+if (n->tx_timer_active &&
+ (vq->vring.avail->idx - vq->last_avail_idx) == 64) {
+ vq->vring.used->flags &= ~VRING_USED_F_NOTIFY_ON_FULL;
+ qemu_del_timer(n->tx_timer);
+ n->tx_timer_active = 0;
+ virtio_net_flush_tx(n, vq);
+} else {
+ qemu_mod_timer(n->tx_timer, qemu_get_clock(vm_clock) +
TX_TIMER_INTERVAL);
+ n->tx_timer_active = 1;
+ vq->vring.used->flags |= VRING_USED_F_NOTIFY_ON_FULL;
+}
+}
+
+static void virtio_net_tx_timer(void *opaque)
+{
+VirtIONet *n = opaque;
+
+n->tx_vq->vring.used->flags &= ~VRING_USED_F_NOTIFY_ON_FULL;
+n->tx_timer_active = 0;
+virtio_net_flush_tx(n, n->tx_vq);
+}
+
void *virtio_net_init(PCIBus *bus, NICInfo *nd, int devfn)
{
VirtIONet *n;
@@ -270,5 +305,8 @@ void *virtio_net_init(PCIBus *bus, NICInfo *nd, int devfn)
VirtIONetHead = n;
}
+n->tx_timer = qemu_new_timer(vm_clock, virtio_net_tx_timer, n);
+n->tx_timer_active = 0;
+
return &n->vdev;
}
diff --git a/qemu/hw/virtio.h b/qemu/hw/virtio.h
index dee97ba..21b96a3 100644
--- a/qemu/hw/virtio.h
+++ b/qemu/hw/virtio.h
@@ -39,6 +39,7 @@
/* This means don't notify other side when buffer added. */
#define VRING_USED_F_NO_NOTIFY 1
+#define VRING_USED_F_NOTIFY_ON_FULL 2
/* This means don't interrupt guest when buffer consumed. */
#define VRING_AVAIL_F_NO_INTERRUPT 1
-
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 1/3] Remove the TX timer from virtio_net
Doing tx mitigation in the host gets equivalent performance and offers greater
flexibility. It also simplifies the guest code.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4082099..797a3ed 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
static int napi_weight = 128;
module_param(napi_weight, int, 0444);
@@ -40,15 +39,9 @@ struct virtnet_info
struct net_device *dev;
struct napi_struct napi;
- /* TX coalescing. */
- struct hrtimer tx_timer;
-
/* Number of input buffers, and max we've ever had. */
unsigned int num, max;
- /* Number of queued output buffers, and max we've ever had. */
- unsigned int out_num, out_max;
-
/* Receive & send queues. */
struct sk_buff_head recv;
struct sk_buff_head send;
@@ -238,20 +231,6 @@ again:
return received;
}
-static enum hrtimer_restart kick_xmit(struct hrtimer *t)
-{
- struct virtnet_info *vi = container_of(t,struct virtnet_info,tx_timer);
-
- BUG_ON(!in_softirq());
- BUG_ON(in_irq());
- netif_tx_lock(vi->dev);
- vi->svq->vq_ops->kick(vi->svq);
- vi->out_num = 0;
- netif_tx_unlock(vi->dev);
-
- return HRTIMER_NORESTART;
-}
-
static int start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -305,13 +284,8 @@ again:
goto again;
pr_debug("%s: virtio not prepared to send\n", dev->name);
- if (vi->out_max != vi->out_num)
- printk("%s: out_max changed from %u to %u\n",
- dev->name, vi->out_max, vi->out_num);
- vi->out_max = vi->out_num;
- vi->out_num = 0;
+
/* Kick off send immediately. */
- hrtimer_cancel(&vi->tx_timer);
vi->svq->vq_ops->kick(vi->svq);
netif_stop_queue(dev);
@@ -327,13 +301,8 @@ again:
return NETDEV_TX_BUSY;
}
- if (++vi->out_num == vi->out_max) {
- hrtimer_cancel(&vi->tx_timer);
- vi->svq->vq_ops->kick(vi->svq);
- vi->out_num = 0;
- } else if (!hrtimer_is_queued(&vi->tx_timer))
- hrtimer_start(&vi->tx_timer, ktime_set(0,50),
- HRTIMER_MODE_REL);
+ vi->svq->vq_ops->kick(vi->svq);
+
return 0;
}
@@ -425,10 +394,6 @@ static int virtnet_probe(struct virtio_device *vdev)
netif_napi_add(dev, &vi->napi, virtnet_poll, napi_weight);
vi->dev = dev;
vi->vdev = vdev;
- memset(&vi->tx_timer, 0, sizeof(vi->tx_timer));
- hrtimer_init(&vi->tx_timer, CLOCK_REALTIME, HRTIMER_MODE_REL);
- vi->tx_timer.function = kick_xmit;
- vi->out_max = -1U;
/* We expect two virtqueues, receive then send. */
vi->rvq = vdev->config->find_vq(vdev, 0, skb_recv_done);
-
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 2/3] Add support for VRING_USED_F_NOTIFY_ON_FULL
This patch adds support for VRING_USED_F_NOTIFY_ON_FULL. When this bit is set, virtio ring notifications will be suppressed unless the virtio ring is full. Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 1302ac4..ee7936f 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -146,7 +146,9 @@ static void vring_kick(struct virtqueue *_vq) /* Need to update avail index before checking if we should notify */ mb(); - if (!(vq->vring.used->flags & VRING_USED_F_NO_NOTIFY)) + if (!(vq->vring.used->flags & VRING_USED_F_NO_NOTIFY) && + (!(vq->vring.used->flags & VRING_USED_F_NOTIFY_ON_FULL) || +(vq->num_free == 0))) /* Prod other side to tell it about changes. */ vq->notify(&vq->vq); diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h index ea3be89..ae6092e 100644 --- a/include/linux/virtio_ring.h +++ b/include/linux/virtio_ring.h @@ -17,8 +17,13 @@ /* This means don't notify other side when buffer added. */ #define VRING_USED_F_NO_NOTIFY 1 +/* Don't notify the other side unless the buffer is full */ +#define VRING_USED_F_NOTIFY_ON_FULL 2 + /* This means don't interrupt guest when buffer consumed. */ #define VRING_AVAIL_F_NO_INTERRUPT 1 +/* Don't notify the other side unless the buffer is full */ +#define VRING_AVAIL_F_NOTIFY_ON_FULL 2 /* Virtio ring descriptors: 16 bytes. These can chain together via "next". */ struct vring_desc - 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] building kvm-userspace with separate kernel object directory?
Create an "asm" symlink from libkvm into the kernel source directory.
This allows one to use kernel trees built with the O= option.
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
---
This is all I can come up with... it should work by accident for user/
and qemu/ directories too, since they use "-I ../libkvm".
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -130,6 +130,8 @@ fi
--arch="$arch" \
${cross_prefix:+"--cross-prefix=$cross_prefix"})
+(cd libkvm; ln -sf "$kerneldir/include/asm-$arch" asm)
+
#configure qemu
(cd qemu; ./configure --target-list=$target_exec \
--disable-kqemu \
diff --git a/libkvm/Makefile b/libkvm/Makefile
--- a/libkvm/Makefile
+++ b/libkvm/Makefile
@@ -10,7 +10,7 @@ CFLAGS += $(autodepend-flags) -g -fomit-
CFLAGS += $(autodepend-flags) -g -fomit-frame-pointer -Wall
CFLAGS += $(call cc-option, -fno-stack-protector, "")
CFLAGS += $(call cc-option, -fno-stack-protector-all, "")
-CFLAGS += -I $(KERNELDIR)/include
+CFLAGS += -I $(KERNELDIR)/include -I .
LDFLAGS += $(CFLAGS)
@@ -35,4 +35,4 @@ install:
-include .*.d
clean:
- $(RM) *.o *.a .*.d
+ $(RM) *.o *.a .*.d asm
--
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
[kvm-devel] building kvm-userspace with separate kernel object directory?
I always build my kernels with the O= option, since it allows me to build multiple architectures from the same sources. However, it looks like the kvm-userspace configure script can't handle this. It says --kerneldir should be the kernel *build* directory, but when I do that I get libkvm.c:21:23: warning: linux/kvm.h: No such file or directory because the build directory does not contain an include/linux symlink. When I specify the kernel *source* directory for --kerneldir, I get /home/hollisb/source/kvmppc.hg/include/linux/kvm.h:12:21: warning: asm/kvm.h: No such file or directory because the source directory doesn't contain an include/asm symlink. How can this work? -- 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
[kvm-devel] [RFC] Remove tx_timer from virtio_net
Avi and I were talking this afternoon and he suggested that we should
remove the tx_timer from the virtio_net front-end and replace it with a
tx_timer in the backend.
Since the backend can suppress notifications, this is appealing since it
gives much more flexibility to the backend in determining how to do tx
batching. I've done a quick implementation and performance is pretty good.
We may need an ABI change, however. When the backend disables
notifications, there is absolutely no way for the frontend to notify
anymore. In the case where the queue fills up, it cannot flush since
the backend has disabled notifications. To work around this, I had to
least notifications enabled and check for the case where the queue fills
up manually.
I think a possible solution to this would be to differentiate between a
soft and hard notify. We would introduce a VRING_USED_F_NOTIFY_ON_FULL
and a VRING_AVAIL_F_NOTIFY_ON_FULL.
The NO_NOTIFY variants would indicate that the other end never sends a
notify, whereas NOTIFY_ON_FULL would indicate that the other end never
sends a notify unless the queue fills up.
Regards,
Anthony Liguori
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 3940743..1006dee 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -14,6 +14,7 @@
#include "virtio.h"
#include "net.h"
#include "pc.h"
+#include "qemu-timer.h"
/* from Linux's virtio_net.h */
@@ -28,6 +29,10 @@
#define VIRTIO_NET_F_TSO6 4
#define VIRTIO_NET_F_MAC 5
+#define USE_TX_TIMER
+
+#define TX_TIMER_INTERVAL (1000 / 500)
+
/* The config defining mac address (6 bytes) */
struct virtio_net_config
{
@@ -63,6 +68,8 @@ typedef struct VirtIONet
int tap_fd;
struct VirtIONet *next;
int do_notify;
+QEMUTimer *tx_timer;
+int tx_timer_active;
} VirtIONet;
static VirtIONet *VirtIONetHead = NULL;
@@ -222,10 +229,10 @@ again:
}
/* TX */
-static void virtio_net_handle_tx(VirtIODevice *vdev, VirtQueue *vq)
+static void virtio_net_flush_tx(VirtIONet *n, VirtQueue *vq)
{
-VirtIONet *n = to_virtio_net(vdev);
VirtQueueElement elem;
+int count = 0;
if (!(n->vdev.status & VIRTIO_CONFIG_S_DRIVER_OK))
return;
@@ -241,11 +248,36 @@ static void virtio_net_handle_tx(VirtIODevice *vdev, VirtQueue *vq)
len += elem.out_sg[i].iov_len;
}
+ count++;
+
virtqueue_push(vq, &elem, sizeof(struct virtio_net_hdr) + len);
virtio_notify(&n->vdev, vq);
}
}
+static void virtio_net_handle_tx(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIONet *n = to_virtio_net(vdev);
+
+if (n->tx_timer_active &&
+ (vq->vring.avail->idx - vq->last_avail_idx) == 64) {
+ qemu_del_timer(n->tx_timer);
+ n->tx_timer_active = 0;
+ virtio_net_flush_tx(n, vq);
+} else {
+ qemu_mod_timer(n->tx_timer, qemu_get_clock(vm_clock) + TX_TIMER_INTERVAL);
+ n->tx_timer_active = 1;
+}
+}
+
+static void virtio_net_tx_timer(void *opaque)
+{
+VirtIONet *n = opaque;
+
+n->tx_timer_active = 0;
+virtio_net_flush_tx(n, n->tx_vq);
+}
+
void *virtio_net_init(PCIBus *bus, NICInfo *nd, int devfn)
{
VirtIONet *n;
@@ -270,5 +302,8 @@ void *virtio_net_init(PCIBus *bus, NICInfo *nd, int devfn)
VirtIONetHead = n;
}
+n->tx_timer = qemu_new_timer(vm_clock, virtio_net_tx_timer, n);
+n->tx_timer_active = 0;
+
return &n->vdev;
}
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4082099..797a3ed 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
static int napi_weight = 128;
module_param(napi_weight, int, 0444);
@@ -40,15 +39,9 @@ struct virtnet_info
struct net_device *dev;
struct napi_struct napi;
- /* TX coalescing. */
- struct hrtimer tx_timer;
-
/* Number of input buffers, and max we've ever had. */
unsigned int num, max;
- /* Number of queued output buffers, and max we've ever had. */
- unsigned int out_num, out_max;
-
/* Receive & send queues. */
struct sk_buff_head recv;
struct sk_buff_head send;
@@ -238,20 +231,6 @@ again:
return received;
}
-static enum hrtimer_restart kick_xmit(struct hrtimer *t)
-{
- struct virtnet_info *vi = container_of(t,struct virtnet_info,tx_timer);
-
- BUG_ON(!in_softirq());
- BUG_ON(in_irq());
- netif_tx_lock(vi->dev);
- vi->svq->vq_ops->kick(vi->svq);
- vi->out_num = 0;
- netif_tx_unlock(vi->dev);
-
- return HRTIMER_NORESTART;
-}
-
static int start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -305,13 +284,8 @@ again:
goto again;
pr_debug("%s: virtio not prepared to send\n", dev->name);
- if (vi->out_max != vi->out_num)
- printk("%s: out_max changed from %u to %u\n",
- dev->name, vi->out_max, vi->out_num);
- vi->out_max = vi->out_num;
- vi->out_num = 0;
+
/* Kick off send immediately. */
- hrtimer_cancel(&vi->tx_timer);
vi->svq->vq_ops->kick(vi->svq);
netif_stop_queue(dev);
@@ -32
Re: [kvm-devel] boot stops after console handover?
Avi Kivity wrote:
> Antoine Martin wrote:
>>
>> Hi,
>>
>> Trying to boot KVM on a Core2Duo system, kvm-59 + linux-2.6.23.12
>> Booting with:
>> qemu-system-x86_64 -hda /home/uml/BusyBox-1.5.0-amd64-root_fs -m 384
>> - -nographic -cpu qemu64 -kernel /boot/vmlinuz-2.6.23.12 -append
>> "earlyprintk=serial,ttyS0,115200"
>>
>>
>
> Does regular boot (without -kernel) work?
>
Nope, it's just spinning at 100% cpu, tried stock 2.6.23.12 and
2.6.24-rc6, lots of clock_gettime(CLOCK_MONOTONIC,...
Do I need to enable/disable some RTC / HPET options?
Cheers
Antoine
here is the start of the strace:
# execve("/usr/local/bin/qemu-system-x86_64", ["qemu-system-x86_64",
"-hda", "./BusyBox-1.5.0-amd64-root_fs", "-m", "384", "-nographic",
"-append", "earlyp
rintk=serial,115200"...], [/* 26 vars */]) = 0
brk(0) = 0x62541000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2ae8327b7000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2ae8327b8000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23976, ...}) = 0
mmap(NULL, 23976, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2ae8327b9000
close(3)= 0
open("/lib/libm.so.6", O_RDONLY)= 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0?\0\0\0\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=526472, ...}) = 0
mmap(NULL, 2621672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2ae8329b8000
mprotect(0x2ae832a38000, 2093056, PROT_NONE) = 0
mmap(0x2ae832c37000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7f000) = 0x2ae832c37000
close(3)= 0
open("/lib/libz.so.1", O_RDONLY)= 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\35\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=84272, ...}) = 0
mmap(NULL, 2179560, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2ae832c39000
mprotect(0x2ae832c4d000, 2093056, PROT_NONE) = 0
mmap(0x2ae832e4c000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13000) = 0x2ae832e4c000
close(3)= 0
open("/usr/lib/libSDL-1.2.so.0", O_RDONLY) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0pe\0\0\0\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=255360, ...}) = 0
mmap(NULL, 2361936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2ae832e4e000
mprotect(0x2ae832e8a000, 2097152, PROT_NONE) = 0
mmap(0x2ae83308a000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3c000) = 0x2ae83308a000
mmap(0x2ae83308c000, 10832, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ae83308c000
close(3)= 0
open("/lib/libpthread.so.0", O_RDONLY) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260W\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=131897, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2ae83308f000
mmap(NULL, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2ae83309
mprotect(0x2ae8330a5000, 2097152, PROT_NONE) = 0
mmap(0x2ae8332a5000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x2ae8332a5000
mmap(0x2ae8332a7000, 13168, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ae8332a7000
close(3)= 0
open("/lib/librt.so.1", O_RDONLY) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\"\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=35688, ...}) = 0
mmap(NULL, 2132968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2ae8332ab000
mprotect(0x2ae8332b3000, 2093056, PROT_NONE) = 0
mmap(0x2ae8334b2000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x2ae8334b2000
close(3)= 0
open("/lib/libutil.so.1", O_RDONLY) = 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\16\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=10488, ...}) = 0
mmap(NULL, 2105624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2ae8334b4000
mprotect(0x2ae8334b6000, 2093056, PROT_NONE) = 0
mmap(0x2ae8336b5000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x2ae8336b5000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\334\1\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1293456, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2ae8336b7000
mmap(NULL, 3399928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2ae8336b8000
mprotect(0x2ae8337ee000, 2093056, PROT_NONE) = 0
Re: [kvm-devel] virtio_net missing interrupts?
Anthony Liguori wrote: > Avi noticed that when using the virtio_net driver, ping responses stop > coming in after 12 packets. ping will then throw an "sendmsg: no > buffer space available" error. > > This occurs on all kernel versions (even 2.6.24). > Latencies are high at around 4ms when the packets do arrive. Further speculation yielded the following: a non hrtimer kernel will delay all packets by one jiffie due to the tx timer. For an unknown reason, an arp packet is lost, so further echo requests are queued up until the buffer is exhausted. -- 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
[kvm-devel] virtio_net missing interrupts?
Avi noticed that when using the virtio_net driver, ping responses stop coming in after 12 packets. ping will then throw an "sendmsg: no buffer space available" error. This occurs on all kernel versions (even 2.6.24). Regards, Anthony Liguori - 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] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Javier Guerra wrote: > to test a cluster filesystem, i need two (virtual) machines with some > shared storage. i tried long ago something like this (with (k)qemu): > > - create a disk image, call it hda-1.img > - boot and install linux on it, shutdown > - copy to hda-2.img > - boot it (with new MAC) and change IP, hostname, little things, shutdown > - boot both with the same bridge, check that network works between them > - create a new disk image, call id hdb-shr.img > - boot both VMs, sharing hdb-shr.img: > > qemu -hda=hda-1.img -hdb-shr.img > qemu -hda=hda-2.img -hdb-shr.img > > - try to setup a cluster filesystem on hdb > > it almost worked... but some writes didn't propagate to the other > until some extra writes to hdb; so i guessed that each qemu instance > had some caching on file I/O > > hopefully, it would now work with "-cache=off", don't you think? > > cache=off is not necessary. However you need raw format images (not qcow/vmdk/etc). -- 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] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Javier Guerra wrote: > On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote: > >> What I'm wondering now is: is it really useful to have "cache=off" and >> "snapshot=on" at the same time ? >> > > does "cache=off" means disk cache? if so, it might be useful to test > clustering filesystems. > > so far, the only way is to setup a network block device (iSCSI, AoE, > nbd). i'd like to simply specify the same backing file for two > instances' hdb parameter. > For that to work you need to use the raw format (and then, cache=off doesn't matter, as a clustering filesystem ought to have a coherent cache). -- 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] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Laurent Vivier wrote: > What I'm wondering now is: is it really useful to have "cache=off" and > "snapshot=on" at the same time ? > No idea, but wouldn't want to rule it out. > If not, the patch of Carlo is good, otherwise there is more > modifications to do (in other parts of qemu). > If other modifications are needed, perhaps do them in the I/O submission path (if unaligned and cache=off, force alignment). Since most of the data will be aligned by the guest, the overhead will only be incurred by the rare metadata accesses. -- 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] kvm with usb slow
USB redirection support in qemu is currently using synchronous ioctls, which might block the guest for too long (>100usec). The current host controller emulations allow only one pending transfer at a time, which might slow down the guest as well. If you are using simple bulk device (disk on key, printer etc.), you can try the patch of USB 2.0 EHCI emulation, recently submitted to qemu-devel. It is at very preliminary stage, but still might be useful for you. Arnon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Norbert Preining Sent: Sunday, January 06, 2008 6:42 PM To: kvm-devel@lists.sourceforge.net Subject: [kvm-devel] kvm with usb slow Hi all, (please Cc, thanks) I am running kernel 2.6.24-rc6 and kvm-56 (or was it 55) and as soon as I plug an usb device with usb enabled it is getting terrible slow. I have searched a bit and it seems to be related to async i/o not being implemented. Is this expected behaviour, and if yes, are there patches floating around for testing? Best wishes Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HASTINGS (pl.n.) Things said on the spur of the moment to explain to someone who comes into a room unexpectedly precisely what it is you are doing. --- Douglas Adams, The Meaning of Liff - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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: emulator: Only allow VMCALL/VMMCALL trapped by #UD
Dong, Eddie wrote: > Avi Kivity wrote: > >> Dong, Eddie wrote: >> >>> Anthony Liguori wrote: >>> >>> Dong, Eddie wrote: > Anthony: > Actually I am wondering if the binary used for VMMCALL could be > assumed will never be used by Intel processor or vice versa. BTW, > what is the nenefit to remove hypercall page, which provide more > clean approach IMO? > > > A hypercall page doesn't help the situation with respect to migration between an AMD and Intel system. >>> I guess I miss something. As if hypercall page is read only after >>> creation (by VMM), later memory migration won't overlap it. The page >>> could be a "Reserved" in e820 table. >>> >>> >> If migration happens while rip is in the hypercall page, and if the >> > > I didn't quit catch here. The source VM vCPU is in Qemu migration part, > The target VM VCPU is always waiting for migration data/command. > If you mean SMP case, all target VCPUs are in waiting for data/cmd, > and I assume source VCPUs are all in Qemu known state, not? > > > I'm talking about the guest rip. The guest is not aware of the migration. Suppose that on the last copy that the guest rip is (hypercall_page_virt + 3). This address might be in the middle of some instruction on the hypercall page on the target machine. You need to fix up rip and possibly modify registers so that when it resumes it works correctly. -- 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] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Well, in fact, I think you can't use snapshot with cluster filesystem: as each qemu instance will write in its own snapshot and will not see modifications made by other, and I don't think there is currently a way to share snapshot between qemu instances. Laurent Le lundi 07 janvier 2008 à 11:42 -0500, Javier Guerra a écrit : > On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote: > > Le lundi 07 janvier 2008 à 11:03 -0500, Javier Guerra a écrit : > > > hopefully, it would now work with "-cache=off", don't you think? > > > > Well, I don't think the problem is at the host level but at the guest > > level, because both instances of qemu share the host cache and thus > > first instance should see changes made by the second instance (and > > vice-versa). > > that's what a cluster filesystem is designed to cope with (and in fact > expects) > > > There are also some caches at qemu level to emulate DMA, for instance in > > hw/ide.c it is MAX_MULT_SECTORS (16) which is 8 kB buffer, perhaps your > > problem is here but "cache=off" doesn't remove this. > > Did you try to change MAX_MULT_SECTORS to 1 ? > > nope, don't know enough of qemu internals... > > but if those caches can be flushed from the guest, the filesystem > should do that when writing its metadata > > > What do you call a "cluster filesystem" ? > > GFS, OCFS2, etc. that is, filesystems that are designed to run on > more than one host with shared block storage. usually that means > FibreChannel or iSCSI, but on VMs, a common backing could work too (at > least in theory). > > Xen manages it, at least on paravirtualized guests; hadn't tried on > HVM guests. maybe the IDE-like emulation is too poor an interface to > handle it. > -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée - 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] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote: > Le lundi 07 janvier 2008 à 11:03 -0500, Javier Guerra a écrit : > > hopefully, it would now work with "-cache=off", don't you think? > > Well, I don't think the problem is at the host level but at the guest > level, because both instances of qemu share the host cache and thus > first instance should see changes made by the second instance (and > vice-versa). that's what a cluster filesystem is designed to cope with (and in fact expects) > There are also some caches at qemu level to emulate DMA, for instance in > hw/ide.c it is MAX_MULT_SECTORS (16) which is 8 kB buffer, perhaps your > problem is here but "cache=off" doesn't remove this. > Did you try to change MAX_MULT_SECTORS to 1 ? nope, don't know enough of qemu internals... but if those caches can be flushed from the guest, the filesystem should do that when writing its metadata > What do you call a "cluster filesystem" ? GFS, OCFS2, etc. that is, filesystems that are designed to run on more than one host with shared block storage. usually that means FibreChannel or iSCSI, but on VMs, a common backing could work too (at least in theory). Xen manages it, at least on paravirtualized guests; hadn't tried on HVM guests. maybe the IDE-like emulation is too poor an interface to handle it. -- Javier - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Le lundi 07 janvier 2008 à 11:03 -0500, Javier Guerra a écrit : > On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote: > > "cache=off" means files is opened with "O_DIRECT" and thus there is no > > cache in the kernel memory on the host side. > > IMO, "cache=off" and "snapshot=on" are incompatible because a snapshot > > can be seen like a cache. > > > > > so far, the only way is to setup a network block device (iSCSI, AoE, > > > nbd). i'd like to simply specify the same backing file for two > > > instances' hdb parameter. > > > > I'm sorry but I don't understand this part. > > to test a cluster filesystem, i need two (virtual) machines with some > shared storage. i tried long ago something like this (with (k)qemu): > > - create a disk image, call it hda-1.img > - boot and install linux on it, shutdown > - copy to hda-2.img > - boot it (with new MAC) and change IP, hostname, little things, shutdown > - boot both with the same bridge, check that network works between them > - create a new disk image, call id hdb-shr.img > - boot both VMs, sharing hdb-shr.img: > > qemu -hda=hda-1.img -hdb-shr.img > qemu -hda=hda-2.img -hdb-shr.img > > - try to setup a cluster filesystem on hdb > > it almost worked... but some writes didn't propagate to the other > until some extra writes to hdb; so i guessed that each qemu instance > had some caching on file I/O > > hopefully, it would now work with "-cache=off", don't you think? Well, I don't think the problem is at the host level but at the guest level, because both instances of qemu share the host cache and thus first instance should see changes made by the second instance (and vice-versa). There are also some caches at qemu level to emulate DMA, for instance in hw/ide.c it is MAX_MULT_SECTORS (16) which is 8 kB buffer, perhaps your problem is here but "cache=off" doesn't remove this. Did you try to change MAX_MULT_SECTORS to 1 ? What do you call a "cluster filesystem" ? > > > and snapshots help a lot to go back after blowing up the on-disk > > > structures > > > > But I think if you use a snapshot there is no reason to use "cache=off" > > in the above case, if both KVM instances share the snapshot without > cacheing it, the cluster should still work, and have some rollback > capability at the same time > > or is it too much wishful thinking? Unfortunately I guess... Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio_net backport performance
Rusty Russell wrote:
> On Saturday 05 January 2008 09:24:40 Anthony Liguori wrote:
>
>> Hey Rusty et al,
>>
>> I've got automatic backports of the virtio modules[1] working back to
>> 2.6.18. Everything seems okay except that for any kernel with the older
>> NAPI api, performance is extremely bad. I get about 1gbit on TX with
>> 2.6.24 but I get somewhere around 20mbit on 2.6.22.
>>
>
> OK, I tested this backport and immediately got oopses. Revealed some
> interesting races in net driver (again, it's that damn callback disable
> causing problems). New queue fixes these, but get awful performance:
> 'dd bs=1M count=1000 if=/dev/zero | nc 172.20.0.1 8889' takes almost 30
> seconds.
>
rx performance is pretty abysmal but tx performance seems respectable.
I'm getting strange results with netperf but my guess is that we're
getting around 800mbit tx but only 25mbit rx.
tx is right around what it should be but rx is about an order of
magnitude off.
> Found one bug in your code tho: if enable_cb returns false, it means the
> queue
> has *not* been enabled:
>
> --- hack-module.awk.~1~ 2008-01-06 10:49:16.0 +1100
> +++ hack-module.awk 2008-01-07 19:08:40.0 +1100
> @@ -49,7 +49,6 @@
> print " netif_rx_complete(vi->dev);";
> print "";
> print " if (!no_work && netif_rx_reschedule(vi->dev, received)) {";
> -print " vi->rvq->vq_ops->disable_cb(vi->rvq);";
> print " skb = NULL;";
> print " goto again;";
> print " }";
>
Thanks, I've applied this to the backport tree.
> Will continue looking for performance regression tomorrow (actually, better
> check my changes haven't introduced it in non-backports first!).
>
Excellent, thanks!
Regards,
Anthony Liguori
> Thanks!
> Rusty.
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1865988 ] KVM still may halt during restart in rare cases
Bugs item #1865988, was opened at 2008-01-07 18:11 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=1865988&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: KVM still may halt during restart in rare cases Initial Comment: Congratulations on much improved KVM restarts. Since KVM-57 it doesn't halts anymore during restarts under standard conditions; however, I have found a non-standard condition which makes KVM unable to restart. Host: F7/x64, Intel, KVM-59. Guest: Windows XP, ACPI. After running "WCPUID", Windows guest crashes (goes BSOD, while it should not), and after hard restart (Qemu monitor system_reset), KVM is unable to restart. NOTE: With "-no-kvm" it restarts fine. -Alexey Technologov, 07.01.2008. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1865988&group_id=180599 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote: > "cache=off" means files is opened with "O_DIRECT" and thus there is no > cache in the kernel memory on the host side. > IMO, "cache=off" and "snapshot=on" are incompatible because a snapshot > can be seen like a cache. > > > so far, the only way is to setup a network block device (iSCSI, AoE, > > nbd). i'd like to simply specify the same backing file for two > > instances' hdb parameter. > > I'm sorry but I don't understand this part. to test a cluster filesystem, i need two (virtual) machines with some shared storage. i tried long ago something like this (with (k)qemu): - create a disk image, call it hda-1.img - boot and install linux on it, shutdown - copy to hda-2.img - boot it (with new MAC) and change IP, hostname, little things, shutdown - boot both with the same bridge, check that network works between them - create a new disk image, call id hdb-shr.img - boot both VMs, sharing hdb-shr.img: qemu -hda=hda-1.img -hdb-shr.img qemu -hda=hda-2.img -hdb-shr.img - try to setup a cluster filesystem on hdb it almost worked... but some writes didn't propagate to the other until some extra writes to hdb; so i guessed that each qemu instance had some caching on file I/O hopefully, it would now work with "-cache=off", don't you think? > > and snapshots help a lot to go back after blowing up the on-disk structures > > But I think if you use a snapshot there is no reason to use "cache=off" in the above case, if both KVM instances share the snapshot without cacheing it, the cluster should still work, and have some rollback capability at the same time or is it too much wishful thinking? -- Javier - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Le lundi 07 janvier 2008 à 10:34 -0500, Javier Guerra a écrit : > On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote: > > What I'm wondering now is: is it really useful to have "cache=off" and > > "snapshot=on" at the same time ? > > does "cache=off" means disk cache? if so, it might be useful to test > clustering filesystems. "cache=off" means files is opened with "O_DIRECT" and thus there is no cache in the kernel memory on the host side. IMO, "cache=off" and "snapshot=on" are incompatible because a snapshot can be seen like a cache. > so far, the only way is to setup a network block device (iSCSI, AoE, > nbd). i'd like to simply specify the same backing file for two > instances' hdb parameter. I'm sorry but I don't understand this part. > and snapshots help a lot to go back after blowing up the on-disk structures But I think if you use a snapshot there is no reason to use "cache=off" Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote: > What I'm wondering now is: is it really useful to have "cache=off" and > "snapshot=on" at the same time ? does "cache=off" means disk cache? if so, it might be useful to test clustering filesystems. so far, the only way is to setup a network block device (iSCSI, AoE, nbd). i'd like to simply specify the same backing file for two instances' hdb parameter. and snapshots help a lot to go back after blowing up the on-disk structures -- Javier - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Le lundi 07 janvier 2008 à 12:47 +0200, Avi Kivity a écrit : > Laurent Vivier wrote: > > Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit : > > > >> Carlo Marcelo Arenas Belon wrote: > >> > >>> revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that > >>> redefined sector as an array of pointers to char, instead of a statically > >>> allocated buffer of chars, that was triggering the following warnings : > >>> > >>> block.c: In function `bdrv_commit': > >>> block.c:480: warning: passing arg 3 of `bdrv_read' from incompatible > >>> pointer type > >>> block.c:484: warning: passing arg 3 of `bdrv_write' from incompatible > >>> pointer type > >>> > >>> Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> > >>> > >>> > >> Doesn't the cache=off option warrant an allocation here to ensure > >> alignment (or perhaps a 1K stack buffer with runtime adjustment)? > >> > > > > You're right, a good patch should be something like this (it is not > > tested or even compiled) : > > > > Looks good, but patch is corrupted by mail client. What I'm wondering now is: is it really useful to have "cache=off" and "snapshot=on" at the same time ? If not, the patch of Carlo is good, otherwise there is more modifications to do (in other parts of qemu). Regards, Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD
Avi Kivity wrote: > Dong, Eddie wrote: >> Anthony Liguori wrote: >> >>> Dong, Eddie wrote: >>> Anthony: Actually I am wondering if the binary used for VMMCALL could be assumed will never be used by Intel processor or vice versa. BTW, what is the nenefit to remove hypercall page, which provide more clean approach IMO? >>> A hypercall page doesn't help the situation with respect to >>> migration between an AMD and Intel system. >>> >> >> I guess I miss something. As if hypercall page is read only after >> creation (by VMM), later memory migration won't overlap it. The page >> could be a "Reserved" in e820 table. >> > > If migration happens while rip is in the hypercall page, and if the I didn't quit catch here. The source VM vCPU is in Qemu migration part, The target VM VCPU is always waiting for migration data/command. If you mean SMP case, all target VCPUs are in waiting for data/cmd, and I assume source VCPUs are all in Qemu known state, not? > hypercall page is different in the target host, you may need to apply > fixups. The fixups (and the hypercall page itself) may be different > according to the guest mode (32-bit or 64-bit). thx, eddie - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-userspace fails to compile
Le lundi 07 janvier 2008 à 15:57 +0200, Avi Kivity a écrit : > Laurent Vivier wrote: > > but a pull doesn't resolve anything (the clone has the same effect). > > > > Is the correction has been pushed... ? > > > > > > Should be... > > Perhaps a ./configure is needed. > > What's your HEAD? I have a5b3d2c9b4d4ca3e02f294d14c7df016e070bda7, > which compiles fine. OK, I found where is the problem: my KERNELDIR is not the good one. Thank you for the answers. Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-userspace fails to compile
Laurent Vivier wrote: > but a pull doesn't resolve anything (the clone has the same effect). > > Is the correction has been pushed... ? > > Should be... Perhaps a ./configure is needed. What's your HEAD? I have a5b3d2c9b4d4ca3e02f294d14c7df016e070bda7, which compiles fine. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-userspace fails to compile
Le lundi 07 janvier 2008 à 15:26 +0200, Dor Laor a écrit : > On Mon, 2008-01-07 at 14:14 +0100, Laurent Vivier wrote: > > The error is: > > > > libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report': > > /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221: > > undefined reference to `kvm_enable_vapic' > > libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup': > > /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:287: > > undefined reference to `kvm_enable_tpr_access_reporting' > > collect2: ld returned 1 exit status > > make[2]: *** [qemu-system-x86_64] Error 1 > > make[2]: Leaving directory > > `/home/vivierl/Projects/KVM/kvm-userspace/qemu/x86_64-softmmu' > > make[1]: *** [subdir-x86_64-softmmu] Error 2 > > make[1]: Leaving directory > > `/home/vivierl/Projects/KVM/kvm-userspace/qemu' > > make: *** [qemu] Error 2 > > > > Any idea ? > > > > Please do another pull, it was temporary broken yesterday. > Dor Thank you for the answer Dor, but a pull doesn't resolve anything (the clone has the same effect). Is the correction has been pushed... ? Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-userspace fails to compile
On Mon, 2008-01-07 at 14:14 +0100, Laurent Vivier wrote: > The error is: > > libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report': > /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221: > undefined reference to `kvm_enable_vapic' > libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup': > /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:287: > undefined reference to `kvm_enable_tpr_access_reporting' > collect2: ld returned 1 exit status > make[2]: *** [qemu-system-x86_64] Error 1 > make[2]: Leaving directory > `/home/vivierl/Projects/KVM/kvm-userspace/qemu/x86_64-softmmu' > make[1]: *** [subdir-x86_64-softmmu] Error 2 > make[1]: Leaving directory > `/home/vivierl/Projects/KVM/kvm-userspace/qemu' > make: *** [qemu] Error 2 > > Any idea ? > Please do another pull, it was temporary broken yesterday. Dor > Laurent > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm-userspace fails to compile
The error is: libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report': /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221: undefined reference to `kvm_enable_vapic' libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup': /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:287: undefined reference to `kvm_enable_tpr_access_reporting' collect2: ld returned 1 exit status make[2]: *** [qemu-system-x86_64] Error 1 make[2]: Leaving directory `/home/vivierl/Projects/KVM/kvm-userspace/qemu/x86_64-softmmu' make[1]: *** [subdir-x86_64-softmmu] Error 2 make[1]: Leaving directory `/home/vivierl/Projects/KVM/kvm-userspace/qemu' make: *** [qemu] Error 2 Any idea ? Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm-userspace fails to compile
The error is: libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report': /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221: undefined reference to `kvm_enable_vapic' libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup': /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:287: undefined reference to `kvm_enable_tpr_access_reporting' collect2: ld returned 1 exit status make[2]: *** [qemu-system-x86_64] Error 1 make[2]: Leaving directory `/home/vivierl/Projects/KVM/kvm-userspace/qemu/x86_64-softmmu' make[1]: *** [subdir-x86_64-softmmu] Error 2 make[1]: Leaving directory `/home/vivierl/Projects/KVM/kvm-userspace/qemu' make: *** [qemu] Error 2 Any idea ? Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] add acpi powerbutton support
Guido Guenther wrote: > (needs either --no-kvm-irqchip or the previous patch) > -- Guido > > Applied both, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Le lundi 07 janvier 2008 à 12:47 +0200, Avi Kivity a écrit : > Laurent Vivier wrote: > > Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit : > > > >> Carlo Marcelo Arenas Belon wrote: > >> > >>> revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that > >>> redefined sector as an array of pointers to char, instead of a statically > >>> allocated buffer of chars, that was triggering the following warnings : > >>> > >>> block.c: In function `bdrv_commit': > >>> block.c:480: warning: passing arg 3 of `bdrv_read' from incompatible > >>> pointer type > >>> block.c:484: warning: passing arg 3 of `bdrv_write' from incompatible > >>> pointer type > >>> > >>> Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> > >>> > >>> > >> Doesn't the cache=off option warrant an allocation here to ensure > >> alignment (or perhaps a 1K stack buffer with runtime adjustment)? > >> > > > > You're right, a good patch should be something like this (it is not > > tested or even compiled) : > > > > Looks good, but patch is corrupted by mail client. OK, I'll resend it later (I'd like to compile it at least). Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry signature.asc Description: Ceci est une partie de message numériquement signée - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] add acpi powerbutton support
(needs either --no-kvm-irqchip or the previous patch)
-- Guido
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 314df94..7a96ece 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1318,8 +1318,8 @@ void acpi_bios_init(void)
fadt->pm_tmr_len = 4;
fadt->plvl2_lat = cpu_to_le16(0x0fff); // C2 state not supported
fadt->plvl3_lat = cpu_to_le16(0x0fff); // C3 state not supported
-/* WBINVD + PROC_C1 + PWR_BUTTON + SLP_BUTTON + FIX_RTC */
-fadt->flags = cpu_to_le32((1 << 0) | (1 << 2) | (1 << 4) | (1 << 5) | (1
<< 6));
+/* WBINVD + PROC_C1 + SLP_BUTTON + FIX_RTC */
+fadt->flags = cpu_to_le32((1 << 0) | (1 << 2) | (1 << 5) | (1 << 6));
acpi_build_table_header((struct acpi_table_header *)fadt, "FACP",
sizeof(*fadt));
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index a2efd9c..fa78b81 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -71,6 +71,8 @@ typedef struct PIIX4PMState {
#define SMBHSTDAT1 0x06
#define SMBBLKDAT 0x07
+PIIX4PMState *pm_state;
+
static uint32_t get_pmtmr(PIIX4PMState *s)
{
uint32_t d;
@@ -475,6 +477,7 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
smb_io_base)
s = (PIIX4PMState *)pci_register_device(bus,
"PM", sizeof(PIIX4PMState),
devfn, NULL, pm_write_config);
+pm_state = s;
pci_conf = s->dev.config;
pci_conf[0x00] = 0x86;
pci_conf[0x01] = 0x80;
@@ -516,3 +519,13 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
smb_io_base)
s->smbus = i2c_init_bus();
return s->smbus;
}
+
+#if defined(TARGET_I386)
+void qemu_system_powerdown(void)
+{
+if(pm_state->pmen & PWRBTN_EN) {
+pm_state->pmsts |= PWRBTN_EN;
+ pm_update_sci(pm_state);
+}
+}
+#endif
diff --git a/qemu/sysemu.h b/qemu/sysemu.h
index c8478ec..5fd7fc2 100644
--- a/qemu/sysemu.h
+++ b/qemu/sysemu.h
@@ -33,7 +33,7 @@ void qemu_system_powerdown_request(void);
int qemu_shutdown_requested(void);
int qemu_reset_requested(void);
int qemu_powerdown_requested(void);
-#if !defined(TARGET_SPARC)
+#if !defined(TARGET_SPARC) && !defined(TARGET_I386)
// Please implement a power failure function to signal the OS
#define qemu_system_powerdown() do{}while(0)
#else
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] acpi sci polarity
On Sun, Jan 06, 2008 at 11:08:31AM +0200, Avi Kivity wrote:
> Since it is the OS that assigns SCI to irq10, we can't be sure it will
> always be there. So I think all PCI IRQs need such an override.
The patch below adds the override to IRQs 5,9,10 & 11. The code is
basically from Xen. Xen fixes the SCI interrupt to 9, we should probably
do the same in the long term. However adding the proper MADT entries
should be fine anyway.
>
> Also, does this work if you remove the sci hack in piix3_set_irq()
>
> piix3_dev->config[0x60 + irq_num] &= ~0x80; // enable bit
Without that bit it doesn't work anymore.
>From 918338e3f37f91a14d230a9ccf3c3387a2b58617 Mon Sep 17 00:00:00 2001
From: Guido Guenther <[EMAIL PROTECTED]>
Date: Fri, 4 Jan 2008 19:26:33 +0100
Subject: [PATCH] add interrupt override entries for IRQs 5,9,10,11 to the MADT
so the OS knows that they're active high, level triggered. This allows
for proper ACPI event reporting such as the (emulated) power button and
should also fix the ACPI timer.
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 7a96ece..e5a9bd5 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -55,6 +55,9 @@ typedef unsigned long long uint64_t;
#define APIC_ID 0x020
#define APIC_LVT30x370
+/* IRQs 5,9,10,11 */
+#define PCI_ISA_IRQ_MASK0x0e20U
+
#define APIC_ENABLED 0x0100
#define AP_BOOT_ADDR 0x1
@@ -1181,6 +1184,14 @@ struct madt_io_apic
* lines start */
};
+struct madt_intsrcovr {
+ APIC_HEADER_DEF
+ uint8_t bus;
+ uint8_t source;
+ uint32_t gsi;
+ uint16_t flags;
+};
+
#include "acpi-dsdt.hex"
static inline uint16_t cpu_to_le16(uint16_t x)
@@ -1271,7 +1282,7 @@ void acpi_bios_init(void)
addr = (addr + 7) & ~7;
madt_addr = addr;
-madt_size = sizeof(*madt) +
+madt_size = sizeof(*madt) +
sizeof(struct madt_processor_apic) * smp_cpus +
sizeof(struct madt_io_apic);
madt = (void *)(addr);
@@ -1335,6 +1346,7 @@ void acpi_bios_init(void)
{
struct madt_processor_apic *apic;
struct madt_io_apic *io_apic;
+struct madt_intsrcovr *intsrcovr;
memset(madt, 0, madt_size);
madt->local_apic_address = cpu_to_le32(0xfee0);
@@ -1355,6 +1367,22 @@ void acpi_bios_init(void)
io_apic->address = cpu_to_le32(0xfec0);
io_apic->interrupt = cpu_to_le32(0);
+intsrcovr = (struct madt_intsrcovr*)(io_apic + 1);
+for ( i = 0; i < 16; i++ ) {
+if ( PCI_ISA_IRQ_MASK & (1U << i) ) {
+memset(intsrcovr, 0, sizeof(*intsrcovr));
+intsrcovr->type = APIC_XRUPT_OVERRIDE;
+intsrcovr->length = sizeof(*intsrcovr);
+intsrcovr->source = i;
+intsrcovr->gsi= i;
+intsrcovr->flags = 0xd; /* active high, level triggered */
+} else {
+/* No need for a INT source override structure. */
+continue;
+}
+intsrcovr++;
+madt_size += sizeof(struct madt_intsrcovr);
+}
acpi_build_table_header((struct acpi_table_header *)madt,
"APIC", madt_size);
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD
On Monday 07 January 2008 18:43:52 Avi Kivity wrote:
> Yang, Sheng wrote:
> > On Monday 07 January 2008 17:22:43 Avi Kivity wrote:
> >> Yang, Sheng wrote:
> I have a vague plan for improving decode; basically extend the decode
> tables to add group decoding. We add a bit to opcode_table and
> twobyte_table that is set for all instructions which need group
> decoding. When the bit is set, the rest of the value in opcode_table
> is interpreted as an index (together with modrm_reg) into a new
> group_table, so we can have different decoding for such instructions.
> >>>
> >>> I also have tried to propose a table for Grp opcode, but can't find a
> >>> easy way. Using the rest of the value in opcode_table is a good idea,
> >>> but I'm afraid the same value for different group exists, e.g.
> >>> 0x82(Grp1) and 0xc0 (Grp2) got the same value as: ByteOp | DstMem |
> >>> SrcImm | ModRM. If we add more factors to this, it would become unclear
> >>> and more tricky, the table also may become larger...
> >>>
> >>> Currently, if we want to using group_table, I think the straightforward
> >>> way is better: another big "switch"... The only exception is 1a, and we
> >>> may use 0 instead of it.
> >>
> >> Not sure what you mean. I thought of adding code like
> >>
> >>
> >> if (c->d & Group) {
> >> c->group = c->d & GroupMask;
> >
> > I meant the c->d & GroupMask is not sufficient to indicate different
> > group. For example, 0x82(Grp1) and 0xc0(Grp2) have same c->d & GroupMask
> > = ByteOp | DstMem | SrcImm | ModRM.
>
> I now see the source of confusion...
>
> >> // fetch modrm_reg
> >> c->d = group_table[c->group * 8 + modrm_reg];
> >
> > In this case, how can you deal with c->group = ByteOp | DstMem | SrcImm
> > | ModRM, and modrm_reg = 6. Is it a XOR or nothing?
>
> In this case, we would have
>
>opcode_table[0x82] == Group | Grp1 (c->group == Grp1 == 1)
>opcode_table[0xc0] == Group | Grp2 (c->group == Grp2 == 2)
>group_table[Grp1 * 8 + 6] == ByteOp | DstMem | SrcImm | ModRM
>group_table[Grp2 * 8 + 0] == ByteOp | DstMem | SrcImm | ModRM
>
> If Group is set in opcode_table, the rest of the value is the group
> number, with the reg part used to pick the final decode flags.
Faint...
Yeah, I think that's pretty good. Sorry for misunderstanding...
--
Thanks
Yang, Sheng
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Laurent Vivier wrote: > Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit : > >> Carlo Marcelo Arenas Belon wrote: >> >>> revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that >>> redefined sector as an array of pointers to char, instead of a statically >>> allocated buffer of chars, that was triggering the following warnings : >>> >>> block.c: In function `bdrv_commit': >>> block.c:480: warning: passing arg 3 of `bdrv_read' from incompatible >>> pointer type >>> block.c:484: warning: passing arg 3 of `bdrv_write' from incompatible >>> pointer type >>> >>> Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> >>> >>> >> Doesn't the cache=off option warrant an allocation here to ensure >> alignment (or perhaps a 1K stack buffer with runtime adjustment)? >> > > You're right, a good patch should be something like this (it is not > tested or even compiled) : > Looks good, but patch is corrupted by mail client. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD
Yang, Sheng wrote:
> On Monday 07 January 2008 17:22:43 Avi Kivity wrote:
>
>> Yang, Sheng wrote:
>>
I have a vague plan for improving decode; basically extend the decode
tables to add group decoding. We add a bit to opcode_table and
twobyte_table that is set for all instructions which need group
decoding. When the bit is set, the rest of the value in opcode_table is
interpreted as an index (together with modrm_reg) into a new
group_table, so we can have different decoding for such instructions.
>>> I also have tried to propose a table for Grp opcode, but can't find a
>>> easy way. Using the rest of the value in opcode_table is a good idea, but
>>> I'm afraid the same value for different group exists, e.g. 0x82(Grp1) and
>>> 0xc0 (Grp2) got the same value as: ByteOp | DstMem | SrcImm | ModRM. If
>>> we add more factors to this, it would become unclear and more tricky, the
>>> table also may become larger...
>>>
>>> Currently, if we want to using group_table, I think the straightforward
>>> way is better: another big "switch"... The only exception is 1a, and we
>>> may use 0 instead of it.
>>>
>> Not sure what you mean. I thought of adding code like
>>
>>
>> if (c->d & Group) {
>> c->group = c->d & GroupMask;
>>
>
> I meant the c->d & GroupMask is not sufficient to indicate different group.
> For example, 0x82(Grp1) and 0xc0(Grp2) have same c->d & GroupMask = ByteOp |
> DstMem | SrcImm | ModRM.
>
>
I now see the source of confusion...
>> // fetch modrm_reg
>> c->d = group_table[c->group * 8 + modrm_reg];
>>
>
> In this case, how can you deal with c->group = ByteOp | DstMem | SrcImm |
> ModRM, and modrm_reg = 6. Is it a XOR or nothing?
>
In this case, we would have
opcode_table[0x82] == Group | Grp1 (c->group == Grp1 == 1)
opcode_table[0xc0] == Group | Grp2 (c->group == Grp2 == 2)
group_table[Grp1 * 8 + 6] == ByteOp | DstMem | SrcImm | ModRM
group_table[Grp2 * 8 + 0] == ByteOp | DstMem | SrcImm | ModRM
If Group is set in opcode_table, the rest of the value is the group
number, with the reg part used to pick the final decode flags.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit :
> Carlo Marcelo Arenas Belon wrote:
> > revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that
> > redefined sector as an array of pointers to char, instead of a statically
> > allocated buffer of chars, that was triggering the following warnings :
> >
> > block.c: In function `bdrv_commit':
> > block.c:480: warning: passing arg 3 of `bdrv_read' from incompatible
> > pointer type
> > block.c:484: warning: passing arg 3 of `bdrv_write' from incompatible
> > pointer type
> >
> > Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
> >
>
> Doesn't the cache=off option warrant an allocation here to ensure
> alignment (or perhaps a 1K stack buffer with runtime adjustment)?
You're right, a good patch should be something like this (it is not
tested or even compiled) :
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
diff --git a/qemu/block.c b/qemu/block.c
index 519be24..c198659 100644
--- a/qemu/block.c
+++ b/qemu/block.c
@@ -460,7 +460,7 @@ int bdrv_commit(BlockDriverState *bs)
BlockDriver *drv = bs->drv;
int64_t i, total_sectors;
int n, j;
-unsigned char *sector[512];
+unsigned char *sector;
if (!drv)
return -ENOMEDIUM;
@@ -473,15 +473,21 @@ int bdrv_commit(BlockDriverState *bs)
return -ENOTSUP;
}
+sector = qemu_memalign(512,512);
+if (sector == NULL)
+return -ENOMEM;
+
total_sectors = bdrv_getlength(bs) >> SECTOR_BITS;
for (i = 0; i < total_sectors;) {
if (drv->bdrv_is_allocated(bs, i, 65536, &n)) {
for(j = 0; j < n; j++) {
if (bdrv_read(bs, i, sector, 1) != 0) {
+qemu_free(sector);
return -EIO;
}
if (bdrv_write(bs->backing_hd, i, sector, 1) != 0) {
+qemu_free(sector);
return -EIO;
}
i++;
@@ -491,6 +497,7 @@ int bdrv_commit(BlockDriverState *bs)
}
}
+qemu_free(sector);
if (drv->bdrv_make_empty)
return drv->bdrv_make_empty(bs);
--
- [EMAIL PROTECTED] --
"La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry
signature.asc
Description: Ceci est une partie de message numériquement signée
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD
On Monday 07 January 2008 17:22:43 Avi Kivity wrote:
> Yang, Sheng wrote:
> >> I have a vague plan for improving decode; basically extend the decode
> >> tables to add group decoding. We add a bit to opcode_table and
> >> twobyte_table that is set for all instructions which need group
> >> decoding. When the bit is set, the rest of the value in opcode_table is
> >> interpreted as an index (together with modrm_reg) into a new
> >> group_table, so we can have different decoding for such instructions.
> >
> > I also have tried to propose a table for Grp opcode, but can't find a
> > easy way. Using the rest of the value in opcode_table is a good idea, but
> > I'm afraid the same value for different group exists, e.g. 0x82(Grp1) and
> > 0xc0 (Grp2) got the same value as: ByteOp | DstMem | SrcImm | ModRM. If
> > we add more factors to this, it would become unclear and more tricky, the
> > table also may become larger...
> >
> > Currently, if we want to using group_table, I think the straightforward
> > way is better: another big "switch"... The only exception is 1a, and we
> > may use 0 instead of it.
>
> Not sure what you mean. I thought of adding code like
>
>
> if (c->d & Group) {
> c->group = c->d & GroupMask;
I meant the c->d & GroupMask is not sufficient to indicate different group.
For example, 0x82(Grp1) and 0xc0(Grp2) have same c->d & GroupMask = ByteOp |
DstMem | SrcImm | ModRM.
> // fetch modrm_reg
> c->d = group_table[c->group * 8 + modrm_reg];
In this case, how can you deal with c->group = ByteOp | DstMem | SrcImm |
ModRM, and modrm_reg = 6. Is it a XOR or nothing?
> }
>
> Instruction execution could continue to be in the regular switch, but
> the decode flags can be different for every instruction in the group.
--
Thanks
Yang, Sheng
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 5ed4995.., userspace e44dce6..
Yang, Sheng wrote: > On Monday 07 January 2008 17:51:36 Avi Kivity wrote: > >> Farkas Levente wrote: >> >>> Zhao, Yunfeng wrote: >>> Hi, all, This is today's KVM test result against kvm.git 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git e44dce6b8c8c8cf155223ba0e036bb4ace5071b1. 4. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&gro up_id=180599 >>> is there any progress with this? >>> >> It's a toughie. We know which guest kernel change caused the hang, but >> we are still some way off from understanding it and fixing it. >> > > I am beginning to look into this recently, but not many clues... Seems like > interrupt problem. The guest was executing "mov 0xd0b0, 0"(set EOI) all > the time after it hung. > > For reference, the trouble ends at commit 95492e4646e5de8b43d9a7908d6177fb737b61f0. Guest kernels before that commit will hang; guest kernels at the commit or later are fine. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 5ed4995.., userspace e44dce6..
On Monday 07 January 2008 17:51:36 Avi Kivity wrote: > Farkas Levente wrote: > > Zhao, Yunfeng wrote: > >> Hi, all, > >> > >> This is today's KVM test result against kvm.git > >> 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git > >> e44dce6b8c8c8cf155223ba0e036bb4ace5071b1. > >> > >> 4. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host > >> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&gro > >> up_id=180599 > > > > is there any progress with this? > > It's a toughie. We know which guest kernel change caused the hang, but > we are still some way off from understanding it and fixing it. I am beginning to look into this recently, but not many clues... Seems like interrupt problem. The guest was executing "mov 0xd0b0, 0"(set EOI) all the time after it hung. -- Thanks Yang, Sheng - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD
Dong, Eddie wrote: > Anthony Liguori wrote: > >> Dong, Eddie wrote: >> >>> Anthony: >>> Actually I am wondering if the binary used for VMMCALL could be >>> assumed will never be used by Intel processor or vice versa. BTW, >>> what is the nenefit to remove hypercall page, which provide more >>> clean approach IMO? >>> >>> >> A hypercall page doesn't help the situation with respect to migration >> between an AMD and Intel system. >> > > I guess I miss something. As if hypercall page is read only after > creation > (by VMM), later memory migration won't overlap it. The page could be > a "Reserved" in e820 table. > If migration happens while rip is in the hypercall page, and if the hypercall page is different in the target host, you may need to apply fixups. The fixups (and the hypercall page itself) may be different according to the guest mode (32-bit or 64-bit). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD
Anthony Liguori wrote: > Dong, Eddie wrote: >> Anthony: >> Actually I am wondering if the binary used for VMMCALL could be >> assumed will never be used by Intel processor or vice versa. BTW, >> what is the nenefit to remove hypercall page, which provide more >> clean approach IMO? >> > > A hypercall page doesn't help the situation with respect to migration > between an AMD and Intel system. I guess I miss something. As if hypercall page is read only after creation (by VMM), later memory migration won't overlap it. The page could be a "Reserved" in e820 table. thx, eddie - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 5ed4995.., userspace e44dce6..
On Mon, 2008-01-07 at 10:48 +0100, Farkas Levente wrote: > Zhao, Yunfeng wrote: > > Hi, all, > > > > This is today's KVM test result against kvm.git > > 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git > > e44dce6b8c8c8cf155223ba0e036bb4ace5071b1. > > > > 4. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host > > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&gro > > up_id=180599 > > is there any progress with this? > yes, there is slow progress, we debug this problem and found it probably releated to the tsc, but we still dont know why the tsc is going wrong - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 5ed4995.., userspace e44dce6..
Farkas Levente wrote: > Zhao, Yunfeng wrote: > >> Hi, all, >> >> This is today's KVM test result against kvm.git >> 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git >> e44dce6b8c8c8cf155223ba0e036bb4ace5071b1. >> >> 4. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host >> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&gro >> up_id=180599 >> > > is there any progress with this? > > It's a toughie. We know which guest kernel change caused the hang, but we are still some way off from understanding it and fixing it. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 5ed4995.., userspace e44dce6..
Zhao, Yunfeng wrote: > Hi, all, > > This is today's KVM test result against kvm.git > 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git > e44dce6b8c8c8cf155223ba0e036bb4ace5071b1. > > 4. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&gro > up_id=180599 is there any progress with this? -- Levente "Si vis pacem para bellum!" - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/5] configure passthrough for qemu
Carlo Marcelo Arenas Belon wrote: > The following patch series implement a configure passthrough for qemu so that > all available configure options in qemu can be used through kvm. > > This includes all suggestions from the 3 first RFC and complements the patches > that were needed from qemu's side and that were brought back through the last > imports. > > It reverts (in some cases partially) the patches needed to implement the > --enable-alsa, --disable-vnc-tls and --disable-gcc-check flags but reimports > them from qemu's configure usage and reimplements them through the generic > passthrough. > > Patch 1/5 : Revert "kvm: configure: qemu vnc-tls configure flag" > Patch 2/5 : Revert "kvm: configure: qemu alsa configure option" > Patch 3/5 : Revert "kvm: configure: support --disable-gcc-check" > Patch 4/5 : configure: use passthrough for all unknown options into qemu > Patch 5/5 : configure: use kvm's configure usage for unknown options > > Applied all, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: use statically allocate 512 byte buffer in the stack for sector in bdrv_commit
Carlo Marcelo Arenas Belon wrote: > revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that > redefined sector as an array of pointers to char, instead of a statically > allocated buffer of chars, that was triggering the following warnings : > > block.c: In function `bdrv_commit': > block.c:480: warning: passing arg 3 of `bdrv_read' from incompatible pointer > type > block.c:484: warning: passing arg 3 of `bdrv_write' from incompatible pointer > type > > Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> > Doesn't the cache=off option warrant an allocation here to ensure alignment (or perhaps a 1K stack buffer with runtime adjustment)? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM Test result, kernel 5ed4995.., userspace e44dce6..
Hi, all, This is today's KVM test result against kvm.git 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git e44dce6b8c8c8cf155223ba0e036bb4ace5071b1. One issue has been fixed: 1. Crashme causes RHEL5 guest kernel panic https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1840711&gro up_id=180599 Old Issues: 1. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1826080&gro up_id=180599 2. Cannot install 64bit vista guests. https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1836905&gro up_id=180599 4. Fails to save/restore 64bit guests https://sourceforge.net/tracker/index.php?func=detail&aid=1824525&group_ id=180599&atid=893831 4. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1812043&gro up_id=180599 5. With using qcow images xpsp2 with 2vpus may fail to boot https://sourceforge.net/tracker/index.php?func=detail&aid=1805017&group_ id=180599&atid=893831 Test environment Platformwoodcrest CPU 4 Memory size 8G' Details PAE: 1. boot guest with 256M memory PASS 2. boot two windows xp guestPASS 3. boot 4 same guest in parallel PASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabledPASS 7. boot Windows xp with ACPI enabled PASS 8. boot Windows 2000 without ACPI PASS 9. kernel build on SMP linux guest PASS 10. LTP on SMP linux guest PASS 11. boot base kernel linux PASS 12. save/restore 32-bit HVM guestsPASS 13. live migration 32-bit HVM guests PASS 14. boot SMP Windows xp with ACPI enabled FAIL 15. boot SMP Windows 2003 with ACPI enabled PASS 16. boot SMP Windows 2000 with ACPI enabled FAIL IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallelPASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 64-bit linux guests FAIL 13. save/restore 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP Windows 2000 with ACPI enabledFAIL 16. boot 32-bit SMP Windows xp with ACPI enabledFAIL 17. boot 32-bit Windows 2000 without ACPIPASS 18. boot 64-bit Windows xp with ACPI enabledPASS 19. boot 32-bit Windows xp without ACPIPASS 20. boot 64-bit vista PASS 21. kernel build in 32-bit linux guest OS PASS 22. kernel build in 64-bit linux guest OS PASS 23. LTP on SMP 32-bit linux guest OS PASS 24. LTP on SMP 64-bit linux guest OS PASS 25. boot 64-bit guests with ACPI enabled PASS 26. boot 32-bit x-server PASS 27. boot 64-bit SMP windows XP with ACPI enabled FAIL 28. boot 64-bit SMP windows 2003 with ACPI enabledFAIL 29. live migration 64bit linux guests FAIL 30. live migration 32bit linux guests PASS Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 7 5 2 00 Restart 2 2 0 00 gtest 14 12 2 00 = control_panel 7 5 2 00 :KVM_LM_PAE_gPAE 1 0 1 00 :KVM_four_sguest_PAE_gPA 1 1 0 00 :KVM_256M_guest_PAE_gPAE 1 1 0 00 :KVM_linux_win_PAE_gPAE1 1 0 00 :KVM_1500M_guest_PAE_gPA 1 1 0 00 :KVM_SR_PAE_gPAE 1 0 1 00 :KVM
Re: [kvm-devel] [PATCH 02/33] KVM: MMU: emulated cmpxchg8b should be atomic on i386
Carlo Marcelo Arenas Belon wrote: > On Sun, Jan 06, 2008 at 04:39:08PM +0200, Avi Kivity wrote: > >> From: Marcelo Tosatti <[EMAIL PROTECTED]> >> >> Emulate cmpxchg8b atomically on i386. This is required to avoid a guest >> pte walker from seeing a splitted write. >> >> [avi: make it compile] >> >> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> >> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> >> --- >> > > This one doesn't look like the one in the current tree, and avoids the reuse > of addr by moving the call to get the gpa up instead of renaming the variable > as propossed in : > > This is a cumulative patch that is the original patch plus all the fixes rolled in. I'd to avoid churn for style issues at this point, maybe we can address it later. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD
Yang, Sheng wrote:
>> I have a vague plan for improving decode; basically extend the decode
>> tables to add group decoding. We add a bit to opcode_table and
>> twobyte_table that is set for all instructions which need group
>> decoding. When the bit is set, the rest of the value in opcode_table is
>> interpreted as an index (together with modrm_reg) into a new
>> group_table, so we can have different decoding for such instructions.
>>
>
> I also have tried to propose a table for Grp opcode, but can't find a easy
> way. Using the rest of the value in opcode_table is a good idea, but I'm
> afraid the same value for different group exists, e.g. 0x82(Grp1) and 0xc0
> (Grp2) got the same value as: ByteOp | DstMem | SrcImm | ModRM. If we add
> more factors to this, it would become unclear and more tricky, the table also
> may become larger...
>
> Currently, if we want to using group_table, I think the straightforward way
> is
> better: another big "switch"... The only exception is 1a, and we may use 0
> instead of it.
>
Not sure what you mean. I thought of adding code like
if (c->d & Group) {
c->group = c->d & GroupMask;
// fetch modrm_reg
c->d = group_table[c->group * 8 + modrm_reg];
}
Instruction execution could continue to be in the regular switch, but
the decode flags can be different for every instruction in the group.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] boot stops after console handover?
Antoine Martin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > Trying to boot KVM on a Core2Duo system, kvm-59 + linux-2.6.23.12 > Booting with: > qemu-system-x86_64 -hda /home/uml/BusyBox-1.5.0-amd64-root_fs -m 384 > - -nographic -cpu qemu64 -kernel /boot/vmlinuz-2.6.23.12 -append > "earlyprintk=serial,ttyS0,115200" > > Does regular boot (without -kernel) work? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] remove redundant VM Exit for non-aligned guest pte write or part of pte write.
Dong, Eddie wrote: >> Wrong patch attached... >> > > Sorry for the wrong attachment :( > Applied, thanks. I fixed the error case -- you can't 'continue', you still need to zap the pte and flush the tlb. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Moving tpr-patch routine to x86 arch.
Zhang, Xiantao wrote: > Avi Kivity wrote: > >> Avi Kivity wrote: >> >>> Zhang, Xiantao wrote: >>> From: Zhang Xiantao <[EMAIL PROTECTED]> Date: Sat, 5 Jan 2008 20:20:14 +0800 Subject: [PATCH] kvm: qemu: Moving tpr-patch routine to qemu-kvm-x86.c Since tpr patching routine only needed in x86 side, moving it qemu-kvm-arch. >>> Applied, thanks. >>> >>> >> It broke x86 build, so I unapplied it. >> > > Please use the new one:) > > Thanks, applied. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] virtio_net backport performance
On Saturday 05 January 2008 09:24:40 Anthony Liguori wrote:
> Hey Rusty et al,
>
> I've got automatic backports of the virtio modules[1] working back to
> 2.6.18. Everything seems okay except that for any kernel with the older
> NAPI api, performance is extremely bad. I get about 1gbit on TX with
> 2.6.24 but I get somewhere around 20mbit on 2.6.22.
OK, I tested this backport and immediately got oopses. Revealed some
interesting races in net driver (again, it's that damn callback disable
causing problems). New queue fixes these, but get awful performance:
'dd bs=1M count=1000 if=/dev/zero | nc 172.20.0.1 8889' takes almost 30
seconds.
Found one bug in your code tho: if enable_cb returns false, it means the queue
has *not* been enabled:
--- hack-module.awk.~1~ 2008-01-06 10:49:16.0 +1100
+++ hack-module.awk 2008-01-07 19:08:40.0 +1100
@@ -49,7 +49,6 @@
print "netif_rx_complete(vi->dev);";
print "";
print "if (!no_work && netif_rx_reschedule(vi->dev, received)) {";
-print "vi->rvq->vq_ops->disable_cb(vi->rvq);";
print "skb = NULL;";
print "goto again;";
print "}";
Will continue looking for performance regression tomorrow (actually, better
check my changes haven't introduced it in non-backports first!).
Thanks!
Rusty.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
