Re: [kvm-devel] [PATCH][UPDATE] kvm-userspace: sync icache for morearchitectures
Zhang, Xiantao wrote: Christian Ehrhardt wrote: [...] @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, phys_ram_dirty[addr1 TARGET_PAGE_BITS] |= (0xff ~CODE_DIRTY_FLAG); } -#ifdef __ia64__ -kvm_sync_icache((unsigned long)ptr, l); +#ifdef USE_KVM +flush_icache_range((unsigned long)ptr, ((unsigned long)ptr)+l); Are you sure ia64 implement this function for applications ? I didn't find it at my side, so I write it. What do you mean with implement it for applications ? Take a look at dyngen.h - it starts with the comment dyngen helpers and contains a lot of static functions to use them where you need. I don't see anything obvious that would prevent these functions from being built and the file has no own include statements which may change that. Therefor the include dyngen.h in the USE_KVM case should be enough to have this function available for cpu_physical_memory_rw in exec.c where we need it. [...] Xiantao --- Hollis Blanchard wrote: A comment to explain why the icache needs flushing only in the KVM case would be useful. Other than that I'm fine with it. Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] AFAIK Plain qemu does not directly execute guest code on the processor, so the icache is not an issue for it. Qemu itself has the flush_icache_range function only as helper for the dynamic code generation. But we may now write executable guest code with our intercepted mmio handling that is directly executed when switching back to the guest context, therefore we need that invalidation in the kvm case. For the case that I'm overlooking something in plain qemu, so that it might need it too I add [EMAIL PROTECTED] for comments from there, but currently I think to have it in #ifdef USE_KVM is the right way. P.S. Hollis did you mean you would like to see a comment in the code where that call takes place? -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization +49 7031/16-3385 [EMAIL PROTECTED] [EMAIL PROTECTED] IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM Test result, kernel 864b17c.., userspace 8778f7f..
Hi, This is today's KVM test result against kvm.git 864b17cab371ec5fc3b8560b640d8b8a867c5228 and kvm-userspace.git 8778f7f9c1c96cbe671815afb54cac5b47fa28eb. Save/restore IA32e guest passed today, but on PAE host it still fails with the error: prints:kvm_get_mem_map failed: Unknown error 4294967274 Issues: 1. PAE host hanged on some platforms while booting guests https://sourceforge.net/tracker/index.php?func=detailaid=1849200group_id=180599atid=893831 2. Crashme causes RHEL5 guest kernel panic The guest will kernel panic immediately after starting the test. https://sourceforge.net/tracker/?func=detailatid=893831aid=1840711group_id=180599 3. Timer of guest is inaccurate https://sourceforge.net/tracker/?func=detailatid=893831aid=1826080group_id=180599 4. Cannot install 64bit vista guests. https://sourceforge.net/tracker/?func=detailatid=893831aid=1836905group_id=180599 5. Fails to save/restore guests https://sourceforge.net/tracker/index.php?func=detailaid=1824525group_id=180599atid=893831 6. xp and win2k3 guest crashes https://sourceforge.net/tracker/?func=detailatid=893831aid=1819768group_id=180599 7. xpsp2 with 2vpus may fail to boot https://sourceforge.net/tracker/index.php?func=detailaid=1805017group_id=180599atid=893831 8. Cannot boot 32bit smp RHEL5.1 guest on 64bit host https://sourceforge.net/tracker/?func=detailatid=893831aid=1812043group_id=180599 Test environment Platform woodcrest CPU 4 Memory size 8G' Details PAE: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 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 enabled FAIL 7. boot Windows xp with ACPI enabled FAIL 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 guests FAIL 13. live migration 32-bit HVM guests FAIL 14. boot SMP Windows xp with ACPI enabled FAIL 15. boot SMP windows 2003 with ACPI enabled FAIL 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 parallel PASS 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 PASS 13. save/restore 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32bit SMP Windows 2000 with ACPI enabled FAIL 16. boot 32-bit SMP Windows xp with ACPI enabled FAIL 17. boot 32-bit Windows 2000 without ACPI PASS 18. boot 64-bit Windows xp with ACPI enabled PASS 19. boot 32-bit Windows xp without ACPI PASS 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 enabled FAIL Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 8
Re: [kvm-devel] [PATCH][10/22] kvm: Portability : Moving pio_data, pio, mmio_fault_cr2 to arch.
Carsten Otte wrote: Zhang, Xiantao wrote: diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c index 530c391..2d2ff55 100644 --- a/drivers/kvm/kvm_main.c +++ b/drivers/kvm/kvm_main.c @@ -670,7 +670,7 @@ static int kvm_vcpu_fault(struct vm_area_struct *vma, struct vm_fault *vmf) if (vmf-pgoff == 0) page = virt_to_page(vcpu-run); else if (vmf-pgoff == KVM_PIO_PAGE_OFFSET) -page = virt_to_page(vcpu-pio_data); +page = virt_to_page(vcpu-arch.pio_data); else return VM_FAULT_SIGBUS; get_page(page); Nothing that needs to be dealt with in this patch, just a thing that I ran into when reading this patch: The fact that we're accessing vcpu-arch here in kvm_main.c indicates that kvm_vcpu_fault() needs to go to arch. In fact, we'll be using the regular userspace fault path for guest pages on s390. kvm_vcpu_fault() isn't for mapping guest pages, but for mapping the kernel/userspace vcpu communication area. Moving that snippet to an arch hook should be enough. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - SF.Net email is sponsored by: 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][UPDATE] kvm-userspace: sync icache for morearchitectures
Christian Ehrhardt wrote: Zhang, Xiantao wrote: Christian Ehrhardt wrote: [...] @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf, phys_ram_dirty[addr1 TARGET_PAGE_BITS] |= (0xff ~CODE_DIRTY_FLAG); } -#ifdef __ia64__ - kvm_sync_icache((unsigned long)ptr, l); +#ifdef USE_KVM + flush_icache_range((unsigned long)ptr, ((unsigned long)ptr)+l); Are you sure ia64 implement this function for applications ? I didn't find it at my side, so I write it. What do you mean with implement it for applications ? Take a look at dyngen.h - it starts with the comment dyngen helpers and contains a lot of static functions to use them where you need. I don't see anything obvious that would prevent these functions from being built and the file has no own include statements which may change that. Therefor the include dyngen.h in the USE_KVM case should be enough to have this function available for cpu_physical_memory_rw in exec.c where we need it. Good! I didn't notice this definition. Originally, I think you mean it is a library functions. :) Hollis Blanchard wrote: A comment to explain why the icache needs flushing only in the KVM case would be useful. Other than that I'm fine with it. Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] AFAIK Plain qemu does not directly execute guest code on the processor, so the icache is not an issue for it. Qemu itself has the flush_icache_range function only as helper for the dynamic code generation. But we may now write executable guest code with our intercepted mmio handling that is directly executed when switching back to the guest context, therefore we need that invalidation in the kvm case. For the case that I'm overlooking something in plain qemu, so that it might need it too I add [EMAIL PROTECTED] for comments from there, but currently I think to have it in #ifdef USE_KVM is the right way. P.S. Hollis did you mean you would like to see a comment in the code where that call takes place? - SF.Net email is sponsored by: 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][10/22] kvm: Portability : Moving pio_data, pio, mmio_fault_cr2 to arch.
Zhang, Xiantao wrote: diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c index 530c391..2d2ff55 100644 --- a/drivers/kvm/kvm_main.c +++ b/drivers/kvm/kvm_main.c @@ -670,7 +670,7 @@ static int kvm_vcpu_fault(struct vm_area_struct *vma, struct vm_fault *vmf) if (vmf-pgoff == 0) page = virt_to_page(vcpu-run); else if (vmf-pgoff == KVM_PIO_PAGE_OFFSET) - page = virt_to_page(vcpu-pio_data); + page = virt_to_page(vcpu-arch.pio_data); else return VM_FAULT_SIGBUS; get_page(page); Nothing that needs to be dealt with in this patch, just a thing that I ran into when reading this patch: The fact that we're accessing vcpu-arch here in kvm_main.c indicates that kvm_vcpu_fault() needs to go to arch. In fact, we'll be using the regular userspace fault path for guest pages on s390. - SF.Net email is sponsored by: 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][0/22] Patches to use arch concept to hold arch-speicif fileds for kvm_vcpu and kvm strucuture.
Zhang, Xiantao wrote: As you know, we have to change to kvm_vcpu_arch concept since meet various issues about #includes. This patches enables it. I also prepared a series of patches to split kvm with similar idea. Now, kvm.h includes x86.h by default. X86.c needs includes kvm.h, and vmx.c and svm.c only needs to include x86.h One mmu.h is created to solve inter-dependent issues. With these two seires of pacthes, a clear arch-independent pictures described! :) Tested on x86_32 boot up, and x86_64 build. Very nice patch series :-). Acked-by: Carsten Otte [EMAIL PROTECTED] - SF.Net email is sponsored by: 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][10/22] kvm: Portability : Moving pio_data, pio, mmio_fault_cr2 to arch.
Avi Kivity wrote: kvm_vcpu_fault() isn't for mapping guest pages, but for mapping the kernel/userspace vcpu communication area. Moving that snippet to an arch hook should be enough. Oh thanks for clearing my confusion. Indeed, hm... but we won't have a PIO_PAGE at all. On the other hand, we might need a data page for in-kernel devices too. Let's leave it like it is for now. - SF.Net email is sponsored by: 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 and SMP guests
Rusty, Anthony, Dor, I need your brain power :-) On smp guests I have seen a problem with virtio (the version in curent Avi's git) which do not occur on single processor guests: kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:228! illegal operation: 0001 [#1] Modules linked in: ipv6 CPU:2Not tainted Process swapper (pid: 0, task: 0f83e038, ksp: 0f877d70) Krnl PSW : 070400018000 0045df2a (vring_restart+0x5a/0x70) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0 EA:3 Krnl GPRS: c0a80101 0eb35000 10005800 0045ded0 192f 0eb21000 0eb21000 000e 0eb21900 0eb21920 0f867cb8 07d9b058 0010 0045c06a 0f867cb8 Krnl Code: 0045df1e: e3b0b074 lg %r11,112(%r11) 0045df24: 07fe bcr 15,%r14 0045df26: a7f40001 brc 15,45df28 0045df2a: a7f4ffe1 brc 15,45deec 0045df2e: e3102034 lg %r1,48(%r2) 0045df34: a748 lhi %r4,0 0045df38: 96011001 oi 1(%r1),1 0045df3c: a7f4ffef brc 15,45df1a Call Trace: ([0045c016] virtnet_poll+0x96/0x42c) [0048cda2] net_rx_action+0xca/0x150 [00137f7a] __do_softirq+0x9e/0x130 [001105d6] do_softirq+0xae/0xb4 [00138182] irq_exit+0x96/0x9c [0010d710] do_extint+0xcc/0xf8 [001135d0] ext_no_vtime+0x16/0x1a [0010a57e] cpu_idle+0x216/0x238 I think there is a valid code path, triggering this bug: CPU1CPU2 --- --- - virtnet_poll found no more packets on queue - netif_rx_complete allow poll to be called - vq_ops-restart is called - vq Interrupts are enabled .new packets arrive vcpu is scheduled away . - interrupt is delivered . - poll is called . - poll work is done . - netif_rx_complete . - vq_ops-restart is called . - check if vq interrupts are . enable -- BUG The first idea was to remove this check? (See patch below). I am not sure if the proper fix also requires to change vring.avail-flags to be only changed by atomic bitops. Any ideas, comments? Signed-off-by: Christian Borntraeger [EMAIL PROTECTED] CC: Anthony Liguori [EMAIL PROTECTED] CC: Dor Laor [EMAIL PROTECTED] CC: Rusty Russell [EMAIL PROTECTED] --- drivers/virtio/virtio_ring.c |2 -- 1 file changed, 2 deletions(-) Index: kvm/drivers/virtio/virtio_ring.c === --- kvm.orig/drivers/virtio/virtio_ring.c +++ kvm/drivers/virtio/virtio_ring.c @@ -225,8 +225,6 @@ static bool vring_restart(struct virtque struct vring_virtqueue *vq = to_vvq(_vq); START_USE(vq); - BUG_ON(!(vq-vring.avail-flags VRING_AVAIL_F_NO_INTERRUPT)); - /* We optimistically turn back on interrupts, then check if there was * more to do. */ vq-vring.avail-flags = ~VRING_AVAIL_F_NO_INTERRUPT; - SF.Net email is sponsored by: 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] align gdbstub with QEMU
Jan Kiszka wrote:
We've noticed some problems with current gdbstub in kvm's qemu:
# qemu-system-x86_64 -hda myimage -S -s
# gdb
(gdb) tar re :1234
Remote debugging using :1234
Remote 'g' packet reply is too long:
[...]
This issue did not occur with QEMU from CVS. As I was aware of an
x86_64-related problem in QEMU's gdbstub, I merged its current state
into kvm - and things start to work again. Find the update patch below.
Any feedback on this? Any chance to see this patch (or some similar
version) in kvm-57?
Thanks,
Jan
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/gdbstub.c | 290
-
1 file changed, 143 insertions(+), 147 deletions(-)
Index: kvm-54/qemu/gdbstub.c
===
--- kvm-54.orig/qemu/gdbstub.c
+++ kvm-54/qemu/gdbstub.c
@@ -222,146 +222,60 @@ static int put_packet(GDBState *s, char
return 0;
}
-#if defined(TARGET_X86_64)
+#if defined(TARGET_I386)
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
-uint8_t *p = mem_buf;
int i, fpus;
+uint32_t *registers = (uint32_t *)mem_buf;
-#define PUTREG(x) do { \
- target_ulong reg = tswapl(x); \
- memcpy(p, reg, sizeof reg); \
- p += sizeof reg; \
-} while (0)
-#define PUTREG32(x) do { \
- uint32_t reg = tswap32(x); \
- memcpy(p, reg, sizeof reg); \
- p += sizeof reg; \
-} while (0)
-#define PUTREGF(x) do { \
- memcpy(p, (x), 10);\
- p += sizeof (x);\
-} while (0)
-
-PUTREG(env-regs[R_EAX]);
-PUTREG(env-regs[R_EBX]);
-PUTREG(env-regs[R_ECX]);
-PUTREG(env-regs[R_EDX]);
-PUTREG(env-regs[R_ESI]);
-PUTREG(env-regs[R_EDI]);
-PUTREG(env-regs[R_EBP]);
-PUTREG(env-regs[R_ESP]);
-PUTREG(env-regs[8]);
-PUTREG(env-regs[9]);
-PUTREG(env-regs[10]);
-PUTREG(env-regs[11]);
-PUTREG(env-regs[12]);
-PUTREG(env-regs[13]);
-PUTREG(env-regs[14]);
-PUTREG(env-regs[15]);
-
-PUTREG(env-eip);
-PUTREG32(env-eflags);
-PUTREG32(env-segs[R_CS].selector);
-PUTREG32(env-segs[R_SS].selector);
-PUTREG32(env-segs[R_DS].selector);
-PUTREG32(env-segs[R_ES].selector);
-PUTREG32(env-segs[R_FS].selector);
-PUTREG32(env-segs[R_GS].selector);
-/* XXX: convert floats */
-for(i = 0; i 8; i++) {
-PUTREGF(env-fpregs[i]);
-}
-PUTREG32(env-fpuc);
-fpus = (env-fpus ~0x3800) | (env-fpstt 0x7) 11;
-PUTREG32(fpus);
-PUTREG32(0); /* XXX: convert tags */
-PUTREG32(0); /* fiseg */
-PUTREG32(0); /* fioff */
-PUTREG32(0); /* foseg */
-PUTREG32(0); /* fooff */
-PUTREG32(0); /* fop */
-
-#undef PUTREG
-#undef PUTREG32
-#undef PUTREGF
-
-return p - mem_buf;
-}
+#ifdef TARGET_X86_64
+/* This corresponds with amd64_register_info[] in gdb/amd64-tdep.c */
+uint64_t *registers64 = (uint64_t *)mem_buf;
+
+if (env-hflags HF_CS64_MASK) {
+registers64[0] = tswap64(env-regs[R_EAX]);
+registers64[1] = tswap64(env-regs[R_EBX]);
+registers64[2] = tswap64(env-regs[R_ECX]);
+registers64[3] = tswap64(env-regs[R_EDX]);
+registers64[4] = tswap64(env-regs[R_ESI]);
+registers64[5] = tswap64(env-regs[R_EDI]);
+registers64[6] = tswap64(env-regs[R_EBP]);
+registers64[7] = tswap64(env-regs[R_ESP]);
+for(i = 8; i 16; i++) {
+registers64[i] = tswap64(env-regs[i]);
+}
+registers64[16] = tswap64(env-eip);
-static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int
size)
-{
-uint8_t *p = mem_buf;
-uint32_t junk;
-int i, fpus;
+registers = (uint32_t *)registers64[17];
+registers[0] = tswap32(env-eflags);
+registers[1] = tswap32(env-segs[R_CS].selector);
+registers[2] = tswap32(env-segs[R_SS].selector);
+registers[3] = tswap32(env-segs[R_DS].selector);
+registers[4] = tswap32(env-segs[R_ES].selector);
+registers[5] = tswap32(env-segs[R_FS].selector);
+registers[6] = tswap32(env-segs[R_GS].selector);
+/* XXX: convert floats */
+for(i = 0; i 8; i++) {
+memcpy(mem_buf + 16 * 8 + 7 * 4 + i * 10, env-fpregs[i], 10);
+}
+registers[27] = tswap32(env-fpuc); /* fctrl */
+fpus = (env-fpus ~0x3800) | (env-fpstt 0x7) 11;
+registers[28] = tswap32(fpus); /* fstat */
+registers[29] = 0; /* ftag */
+registers[30] = 0; /* fiseg */
+registers[31] = 0; /* fioff */
+registers[32] = 0; /* foseg */
+registers[33] = 0; /* fooff */
+registers[34] = 0; /* fop */
+for(i = 0; i 16; i++) {
+memcpy(mem_buf + 16 * 8 + 35 * 4 + i * 16,
Re: [kvm-devel] [PATCH] align gdbstub with QEMU
Avi Kivity wrote: Jan Kiszka wrote: Jan Kiszka wrote: We've noticed some problems with current gdbstub in kvm's qemu: # qemu-system-x86_64 -hda myimage -S -s # gdb (gdb) tar re :1234 Remote debugging using :1234 Remote 'g' packet reply is too long: [...] This issue did not occur with QEMU from CVS. As I was aware of an x86_64-related problem in QEMU's gdbstub, I merged its current state into kvm - and things start to work again. Find the update patch below. Any feedback on this? Any chance to see this patch (or some similar version) in kvm-57? Sorry for the non-response. I am hoping to get qemu-cvs merged for kvm-57, which will naturally include this. If that doesn't work out (i.e. we discover regressions), and if this is important for you, I will apply the patch. OK, great. BTW, are there plans to merge the kvm branch into qemu at some point and continue development unitedly with the qemu people? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - SF.Net email is sponsored by: 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][0/22] Patches to use arch concept to hold arch-speicif fileds for kvm_vcpu and kvm strucuture.
Avi Kivity wrote: Indeed, I'll rearrange the directory layout tomorrow and then we can finally see actual arch support instead of preparations! Yipieh :-). - SF.Net email is sponsored by: 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] align gdbstub with QEMU
Jan Kiszka wrote: BTW, are there plans to merge the kvm branch into qemu at some point and continue development unitedly with the qemu people? There is the intent, but no concrete plans. What is missing is someone to prepare a suitable patchset for qemu-devel; that's no small amount of work. I would also like to have libkvm in better shape for this; but if we include it in the patchset, that is not a hard requirement. -- Any sufficiently difficult bug is indistinguishable from a feature. - SF.Net email is sponsored by: 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] align gdbstub with QEMU
Jan Kiszka wrote: Jan Kiszka wrote: We've noticed some problems with current gdbstub in kvm's qemu: # qemu-system-x86_64 -hda myimage -S -s # gdb (gdb) tar re :1234 Remote debugging using :1234 Remote 'g' packet reply is too long: [...] This issue did not occur with QEMU from CVS. As I was aware of an x86_64-related problem in QEMU's gdbstub, I merged its current state into kvm - and things start to work again. Find the update patch below. Any feedback on this? Any chance to see this patch (or some similar version) in kvm-57? Sorry for the non-response. I am hoping to get qemu-cvs merged for kvm-57, which will naturally include this. If that doesn't work out (i.e. we discover regressions), and if this is important for you, I will apply the patch. -- Any sufficiently difficult bug is indistinguishable from a feature. - SF.Net email is sponsored by: 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][0/22] Patches to use arch concept to hold arch-speicif fileds for kvm_vcpu and kvm strucuture.
Zhang, Xiantao wrote: Hi, Avi As you know, we have to change to kvm_vcpu_arch concept since meet various issues about #includes. This patches enables it. I also prepared a series of patches to split kvm with similar idea. Now, kvm.h includes x86.h by default. X86.c needs includes kvm.h, and vmx.c and svm.c only needs to include x86.h One mmu.h is created to solve inter-dependent issues. Applied and pushed; thanks for the good patchset. With these two seires of pacthes, a clear arch-independent pictures described! :) Indeed, I'll rearrange the directory layout tomorrow and then we can finally see actual arch support instead of preparations! -- Any sufficiently difficult bug is indistinguishable from a feature. - SF.Net email is sponsored by: 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 vmx.c: add printk_ratelimit in vmx_intr_assist
* Avi Kivity [EMAIL PROTECTED] [2007-12-14 08:49]: Ryan Harper wrote: Add printk_ratelimit check in front of printk. This prevents spamming of the message during 32-bit ubuntu 6.06server install. Previously, it would hang during the partition formatting stage. Applied, but this is worrying. Do you know whether this is a regression? I'll try out older releases to see if we did regress. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] - SF.Net email is sponsored by: 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] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: Replace use of outb to unused diagnostic port 0x80 for time delay with udelay based time delay on x86_64 architecture machines. Fix for bugs 9511 and 6307 in bugzilla, plus bugs reported in bugzilla.redhat.com. Derived from suggestion (that didn't compile) by Pavel Machek, and tested, also based on measurements of typical timings of out's collated by Rene Herman from many in the community. This patch fixes a number of bugs known to cause problems on HP Pavilion dv9000z and dv6000z laptops - in the form of solid freezes when hwclock is used to show or set the time. Also, it potentially improves bus utilization on SMP machines, by using a waiting process that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds. kvm will forward a virtual machine's writes to port 0x80 to the real port. The reason is that the write is much faster than exiting and emulating it; the difference is measurable when compiling kernels. Now if the cause is simply writing to port 0x80, then we must stop doing that. But if the reason is the back-to-back writes, when we can keep it, since the other writes will be trapped by kvm and emulated. Do you which is the case? -- Any sufficiently difficult bug is indistinguishable from a feature. - SF.Net email is sponsored by: 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] [ANNOUNCE] kvm-56 release
On Thu, Dec 13, 2007 at 05:06:41PM +0200, Avi Kivity wrote: Alexey Eremenko wrote: Yes, You're right, KVM-56 doesn't compiles on 32-bit systems. (tested on openSUSE 10.3, 32-bit) It compiles on 32-bit systems. It doesn't compile on 32-bit non-pae systems. gentoo non-pae kernels build ok as explained in previous post when using : CONFIG_NOHIGHMEM=y CONFIG_X86_PAE not set enabling HIGHMEM64G and PAE also enables CONFIG_X86_CMPXCHG64=y Carlo - SF.Net email is sponsored by: 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] [ANNOUNCE] kvm-56 release
Theodore Tso wrote: BTW, there were changes between 2.6.24-rc3 and -rc5 such that there are merge conflicts when I tried to do a git pull from kvm/master unto Linus's git mainline. In general I merge regularly and resolve conflicts. Currently kvm.git is based on 2.6.24-rc5. -- Any sufficiently difficult bug is indistinguishable from a feature. - SF.Net email is sponsored by: 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 vmx.c: add printk_ratelimit in vmx_intr_assist
Ryan Harper wrote: Add printk_ratelimit check in front of printk. This prevents spamming of the message during 32-bit ubuntu 6.06server install. Previously, it would hang during the partition formatting stage. Applied, but this is worrying. Do you know whether this is a regression? -- Any sufficiently difficult bug is indistinguishable from a feature. - SF.Net email is sponsored by: 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] [ANNOUNCE] kvm-56 release
On Thu, Dec 13, 2007 at 06:59:06AM -0800, Alexey Eremenko wrote: Yes, You're right, KVM-56 doesn't compiles on 32-bit systems. (tested on openSUSE 10.3, 32-bit) it compiles ok in Gentoo 2007.0 building against the last stable gentoo kernels 2.6.22 and 2.6.23 for x86 : gentoo-sources-2.6.22-r9 gentoo-sources-2.6.23-r3 Carlo PS. 2.6.22 is missing a declaration for cmpxchg64 as reported by Pele. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [virtio-net][PATCH] Don't arm tx hrtimer with a constant 500us each transmit
Dor Laor wrote: Christian Borntraeger wrote: Am Mittwoch, 12. Dezember 2007 schrieb Dor Laor: Christian Borntraeger wrote: Am Mittwoch, 12. Dezember 2007 schrieb Dor Laor: --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -406,10 +405,10 @@ again: Hmm, while I agree in general with the patch, I fail to find the proper version of virtio_net where this patch applies. I tried kvm.git and linux-2.6.git from kernel.org. Can you give me a pointer to the repository where you work on virtio? Sorry for that, I added some debug prints of my one. Here it is: *git clone git*://kvm.*qumranet*.com/home/*dor*/src/linux-2.6-nv use branch 'virtio'. Hi Dor, Which userspace repo is usable with the above repo? Thanks, Cam - SF.Net email is sponsored by: 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 vmx.c: add printk_ratelimit in vmx_intr_assist
* Ryan Harper [EMAIL PROTECTED] [2007-12-14 09:36]: * Avi Kivity [EMAIL PROTECTED] [2007-12-14 08:49]: Ryan Harper wrote: Add printk_ratelimit check in front of printk. This prevents spamming of the message during 32-bit ubuntu 6.06server install. Previously, it would hang during the partition formatting stage. Applied, but this is worrying. Do you know whether this is a regression? I'll try out older releases to see if we did regress. Looks like kvm-47 introduced the hang during format, -46 finishes the format just fine and with no printk spamming. I'll start seeing if I can bisect down to a particular changeset. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] - SF.Net email is sponsored by: 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][0/22] Patches to use arch concept to hold arch-speicif fileds for kvm_vcpu and kvm strucuture.
Avi Kivity wrote: Zhang, Xiantao wrote: Hi, Avi As you know, we have to change to kvm_vcpu_arch concept since meet various issues about #includes. This patches enables it. I also prepared a series of patches to split kvm with similar idea. Now, kvm.h includes x86.h by default. X86.c needs includes kvm.h, and vmx.c and svm.c only needs to include x86.h One mmu.h is created to solve inter-dependent issues. Applied and pushed; thanks for the good patchset. With these two seires of pacthes, a clear arch-independent pictures described! :) Indeed, I'll rearrange the directory layout tomorrow and then we can finally see actual arch support instead of preparations! Thanks, that's great news to us :) - SF.Net email is sponsored by: 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 vmx.c: add printk_ratelimit in vmx_intr_assist
* Ryan Harper [EMAIL PROTECTED] [2007-12-14 16:14]: * Ryan Harper [EMAIL PROTECTED] [2007-12-14 09:36]: * Avi Kivity [EMAIL PROTECTED] [2007-12-14 08:49]: Ryan Harper wrote: Add printk_ratelimit check in front of printk. This prevents spamming of the message during 32-bit ubuntu 6.06server install. Previously, it would hang during the partition formatting stage. Applied, but this is worrying. Do you know whether this is a regression? I'll try out older releases to see if we did regress. Looks like kvm-47 introduced the hang during format, -46 finishes the format just fine and with no printk spamming. I'll start seeing if I can bisect down to a particular changeset. My git skills are poor and I can't for the life of my figure out how to get kvm and kvm-userspace checked out at kvm-46 and build them together. So, instead I tested the nightly tarballs between Oct 10 (kvm-46 release) and Oct 18 (kvm-47). kvm-snapshot-20071014.tar.gz is the last known good version. version:kvm-snapshot-20071014 srcversion: 5F6E5524AD0A76F65C4CF60 The flooding of: [2592349.069880] Fault when IDT_Vectoring starts with 1015 but 1015 can complete the formatting. 16 and 17 won't compile. 18 of course fails completely. So, something between 14 and 15 added the flooding, and something between 15 and 18 prevents formatting from progressing. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] - SF.Net email is sponsored by: 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] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
Avi Kivity wrote: kvm will forward a virtual machine's writes to port 0x80 to the real port. The reason is that the write is much faster than exiting and emulating it; the difference is measurable when compiling kernels. Now if the cause is simply writing to port 0x80, then we must stop doing that. But if the reason is the back-to-back writes, when we can keep it, since the other writes will be trapped by kvm and emulated. Do you which is the case? As for kvm, I don't have enough info to know anything about that. Is there a test you'd like me to try? I think you are also asking if the crash on these laptops is caused only by back-to-back writes. Actually, it doesn't seem to matter if they are back to back. I can cause the crash if the writes to 80 are very much spread out in time - it seems only to matter how many of them get executed - almost as if there is a buffer overflow. (And of course if you do back to back writes to other ports that are apparently fully unused, such as 0xED on my machine, no crash occurs). I believe (though no one seems to have confirming documentation from the chipset or motherboard vendor) that port 80 is actually functional for some unknown function on these machines. (They do respond to in instructions faster than a bus cycle abort does - more evidence). I searched the DSDT to see if there is any evidence of an ACPI use for this port, but found nothing. - SF.Net email is sponsored by: 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] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
David P. Reed wrote: I believe (though no one seems to have confirming documentation from the chipset or motherboard vendor) that port 80 is actually functional for some unknown function on these machines. (They do respond to in instructions faster than a bus cycle abort does - more evidence). This is normal. IN from port 0x80 is used by the DMA address map chip. As far as I understand, there are other laptops with the same chipset which don't have this problem, so it's likely either a motherboard or firmware issue. My guess is that they probably let debugging code out in the field (trap port 0x80 in SMM, and then try to output it on some debugging bus.) -hpa - SF.Net email is sponsored by: 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
