[kvm-devel] [PATCH] No reason to disallow (phys_ram_alloc_offset + size) = phys_ram_size in qemu_ram_alloc
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 16:43:24 +0800
Subject: [PATCH] kvm: qemu: No reason to disallow (phys_ram_alloc_offset
+ size) = phys_ram_size
No reason to disallow (phys_ram_alloc_offset + size) = phys_ram_size.
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
qemu/exec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu/exec.c b/qemu/exec.c
index cf14fdd..8b6a2f6 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -2093,7 +2093,7 @@ uint32_t
cpu_get_physical_page_desc(target_phys_addr_t addr)
ram_addr_t qemu_ram_alloc(unsigned long size)
{
ram_addr_t addr;
-if ((phys_ram_alloc_offset + size) = phys_ram_size) {
+if ((phys_ram_alloc_offset + size) phys_ram_size) {
fprintf(stderr, Not enough memory (requested_size = %lu, max
memory = %d)\n,
size, phys_ram_size);
abort();
--
1.5.2
0001-kvm-qemu-No-reason-to-disallow-phys_ram_alloc_off.patch
Description: 0001-kvm-qemu-No-reason-to-disallow-phys_ram_alloc_off.patch
-
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/3] Make ioapic.c independent of x86 header files V2
Zhang, Xiantao wrote:
According to Avi's comments, Updated the patches.
[1/3] Create ioapic.h and lapic.h to hold their declarations.
[2/3] Moving ioapic{.h,.c} back to common directory.
[3/3] Moving out kvm_vcpu_kick from irq.c
Applied all, thanks.
--
error compiling committee.c: too many arguments to function
-
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] No reason to disallow (phys_ram_alloc_offset + size) = phys_ram_size in qemu_ram_alloc
Zhang, Xiantao wrote: From: Zhang Xiantao [EMAIL PROTECTED] Date: Mon, 17 Dec 2007 16:43:24 +0800 Subject: [PATCH] kvm: qemu: No reason to disallow (phys_ram_alloc_offset + size) = phys_ram_size No reason to disallow (phys_ram_alloc_offset + size) = phys_ram_size. Applied, thanks. -- error compiling committee.c: too many arguments to function - 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] [PATCH] Make ioapic structure in irqchip seen by ia64
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 20:27:27 +0800
Subject: [PATCH] kvm: make ioapic structure in irqchip seen by ia64
IA64 also needs to see ioapic structure in irqchip.
Signed-off-by: [EMAIL PROTECTED] [EMAIL PROTECTED]
---
include/linux/kvm.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f0bebd6..de9f28d 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -53,6 +53,8 @@ struct kvm_irqchip {
char dummy[512]; /* reserving space */
#ifdef CONFIG_X86
struct kvm_pic_state pic;
+#endif
+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
struct kvm_ioapic_state ioapic;
#endif
} chip;
--
1.5.2
-
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] Make ioapic structure in irqchip seen by ia64
Zhang, Xiantao wrote: From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Mon, 17 Dec 2007 20:27:27 +0800 Subject: [PATCH] kvm: make ioapic structure in irqchip seen by ia64 IA64 also needs to see ioapic structure in irqchip. Patch doesn't apply due to whitespace corruption. -- error compiling committee.c: too many arguments to function - 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] Make ioapic structure in irqchip seen by ia64
Attached.
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 20:27:27 +0800
Subject: [PATCH] kvm: make ioapic structure in irqchip seen by ia64
IA64 also needs to see ioapic structure in irqchip.
Signed-off-by: [EMAIL PROTECTED] [EMAIL PROTECTED]
---
include/linux/kvm.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f0bebd6..de9f28d 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -53,6 +53,8 @@ struct kvm_irqchip {
char dummy[512]; /* reserving space */
#ifdef CONFIG_X86
struct kvm_pic_state pic;
+#endif
+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
struct kvm_ioapic_state ioapic;
#endif
} chip;
--
1.5.2
0003-kvm-make-ioapic-structure-in-irqchip-seen-by-ia64.patch
Description: 0003-kvm-make-ioapic-structure-in-irqchip-seen-by-ia64.patch
-
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] Make ioapic structure in irqchip seen by ia64
Zhang, Xiantao wrote: Attached. From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Mon, 17 Dec 2007 20:27:27 +0800 Subject: [PATCH] kvm: make ioapic structure in irqchip seen by ia64 IA64 also needs to see ioapic structure in irqchip. Applied, thanks. -- error compiling committee.c: too many arguments to function - 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] questions
hi, in the function kvm_init_msr_list(), when will it be true that (j i) ? in x86.c the function kvm_arch_init() in x68.c, would it not make sense, to put the call to kvm_mmu_module_init() and kvm_init_msr_list after the 3 checks if kvm is already possible on this machine, or is that nonsense from me? flo - 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] Moving ioapic.h and ioapic.c back to common directory
Zhang, Xiantao wrote:
I don't think this is a issue. Since this makefile is located at
arch/{$arch}/kvm. So, you can choose to include it or not.
That is, you can define your own common objs.
Ah :-). Thanks for the explanation.
-
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] Enabling Virtualization on Toshiba Portege M400
I had problems getting kvm-intel to work on a Toshiba Portege M400, as the BIOS clearly stated virtualization was enabled, but KVM stated it was not. I got errors like: FATAL: Error inserting kvm_intel (/lib/modules/2.6.22.10/extra/kvm-intel.ko): Operation not supported kvm: disabled by bios Or the computer froze except for a blinking Caps Lock. The solution seems to be upgrading the BIOS to ver. 3.60: wget http://cdgenp01.csd.toshiba.com/content/support/downloads/pm400v36.exe unzip pm400v36.exe cdrecord pm400v36.iso Reboot Press 'F12' Select CDROM as boot media Wait until BIOS is flashed Turn off Remove battery Wait 40 sec Turn on Press 'ESC' Enable Virtualization Technology Boot Now the module loads. /Ole - 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.
On Fri, 14 Dec 2007, David P. Reed wrote:
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.
Attached is a patch that changes the outs to ins on port 0x80.
I did NOT let gcc decide what to do about modified registers.
Instead, the code saves/restores EAX itself so that all of the
times (whatever they are) are the same.
The code works and is running here. I also patched a very early
version (2.4.26) running on a 400 MHz i486 with an real ISA
bus (Adaptec AHA1453). It works too.
David, will you please try it on your machine. Maybe reading
from the port is less harmful than writing.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.--- linux-2.6.22.1/include/asm-i386/io.h.orig 2007-07-10 14:56:30.0
-0400
+++ linux-2.6.22.1/include/asm-i386/io.h2007-12-17 12:06:10.0
-0500
@@ -252,7 +252,10 @@
static inline void native_io_delay(void)
{
- asm volatile(outb %%al,$0x80 : : : memory);
+ asm volatile( pushl %%eax\n\t
+ inb $0x80, %%al\n\t
+ popl %%eax\n\t
+: : : memory);
}
#if defined(CONFIG_PARAVIRT)
-
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.
On 17-12-07 19:14, linux-os (Dick Johnson) wrote: Attached is a patch that changes the outs to ins on port 0x80. No, that isn't useful. Only a write is guaranteed to make ISA/LPC meaning the timing for a read varies wildly. See the in/out cycles results posted earlier. Was also reading the Intel PIIX(3) chiset datasheet today which specifically mentions that only writes flow through to ISA, reads do not. Rene. - 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] merge kvm_flush_remote_tlbs when modifing shadow pte
host side TLB flush can be merged together if multiple spte need to be write-protected. Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED] diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c index 92ac0d1..749db46 100644 --- a/drivers/kvm/mmu.c +++ b/drivers/kvm/mmu.c @@ -524,9 +524,9 @@ static void rmap_write_protect(struct kvm *kvm, u64 gfn) rmap_printk(rmap_write_protect: spte %p %llx\n, spte, *spte); if (is_writeble_pte(*spte)) set_shadow_pte(spte, *spte ~PT_WRITABLE_MASK); - kvm_flush_remote_tlbs(kvm); spte = rmap_next(kvm, rmapp, spte); } + kvm_flush_remote_tlbs(kvm); } #ifdef MMU_DEBUG tlb-clean1.patch Description: tlb-clean1.patch - 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: Cam Macdonell wrote: 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 git://kvm.qumranet.com/home/dor/src/kvm-nv use branch Hi Dor, I think you forgot a word after branch above. Also, I get the following error when I try clone the userspace repo. [EMAIL PROTECTED]:~/src/KVM$ git clone git://kvm.qumranet.com/home/dor/src/kvm-nv Initialized empty Git repository in /home/cam/src/KVM/kvm-nv/.git/ fatal: The remote end hung up unexpectedly fetch-pack from 'git://kvm.qumranet.com/home/dor/src/kvm-nv' failed. 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] merge kvm_flush_remote_tlbs when modifing shadow pte
Dong, Eddie wrote: host side TLB flush can be merged together if multiple spte need to be write-protected. Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED] diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c index 92ac0d1..749db46 100644 --- a/drivers/kvm/mmu.c +++ b/drivers/kvm/mmu.c @@ -524,9 +524,9 @@ static void rmap_write_protect(struct kvm *kvm, u64 gfn) rmap_printk(rmap_write_protect: spte %p %llx\n, spte, *spte); if (is_writeble_pte(*spte)) set_shadow_pte(spte, *spte ~PT_WRITABLE_MASK); - kvm_flush_remote_tlbs(kvm); spte = rmap_next(kvm, rmapp, spte); } + kvm_flush_remote_tlbs(kvm); } I think this can be improved; in case we don't touch the shadow pte at all, there is no need to flush the tlbs. Also, please pull from kvm.git; things have moved around (mmu.c is now in arch/x86/kvm/). -- 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] [virtio-net][PATCH] Don't arm tx hrtimer with a constant 500us each transmit
On Wednesday 12 December 2007 23:54:00 Dor Laor wrote:
commit 763769621d271d92204ed27552d75448587c1ac0
Author: Dor Laor [EMAIL PROTECTED]
Date: Wed Dec 12 14:52:00 2007 +0200
[virtio-net][PATCH] Don't arm tx hrtimer with a constant 50us each
transmit
The current start_xmit sets 500us hrtimer to kick the host.
The problem is that if another xmit happens before the timer was
fired then
the first xmit will have to wait additional 500us.
This patch does not re-arm the timer if there is existing one.
This will shorten the latency for tx.
Hi Dor!
Yes, I pondered this when I wrote the code. On the one hand, it's a
low-probability pathological corner case, on the other, your patch reduces
the number of timer reprograms in the normal case.
So I've applied it, thanks!
Rusty.
Signed-off-by: Dor Laor [EMAIL PROTECTED]
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7b051d5..8bb17d1
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -406,10 +405,10 @@ again:
virtio_debug(vdebug, %s: before calling kick %d\n,
__FUNCTION__, __LINE__);
vi-svq-vq_ops-kick(vi-svq);
vi-out_num = 0;
-} else {
-vi-stats.hrtimer_starts++;
-hrtimer_start(vi-tx_timer, ktime_set(0,50),
- HRTIMER_MODE_REL);
+} else if (!hrtimer_is_queued(vi-tx_timer)) {
+vi-stats.hrtimer_starts++;
+hrtimer_start(vi-tx_timer, ktime_set(0,50),
+ HRTIMER_MODE_REL);
}
return 0;
}
-
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] 电子传真
您好，我是北京四海恒泰 张力昨天您我有过电话沟通。现将我公司产品服务介绍给您。 我公司服务的特点：1，无需传真机可以随时随地收取发送传真。实现互联网与传统传真机互通。 2，可以同时给3000个号码发送 3，集成短信群发功能 资费：国内发送 长市合一 6秒钟 3分钱 国际资费 北美 香港 每分钟0.56 人民币 在线联系方式 [EMAIL PROTECTED]（Mark） QQ：78160372 （Mark） Mark Zhang MOBIE:+8613001979666 T E L:+861058690807-12 F A X:+861052214567-1051 Hi-fax传真系统为您驱动高效商务 A Professional Advance Your Business www.hi-fax.com - 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] merge kvm_flush_remote_tlbs when modifing shadow pte
Dong, Eddie wrote: host side TLB flush can be merged together if multiple spte need to be write-protected. Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED] diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c index 92ac0d1..749db46 100644 --- a/drivers/kvm/mmu.c +++ b/drivers/kvm/mmu.c @@ -524,9 +524,9 @@ static void rmap_write_protect(struct kvm *kvm, u64 gfn) rmap_printk(rmap_write_protect: spte %p %llx\n, spte, *spte); if (is_writeble_pte(*spte)) set_shadow_pte(spte, *spte ~PT_WRITABLE_MASK); -kvm_flush_remote_tlbs(kvm); spte = rmap_next(kvm, rmapp, spte); } +kvm_flush_remote_tlbs(kvm); } I think this can be improved; in case we don't touch the shadow pte at all, there is no need to flush the tlbs. Also, please pull from kvm.git; things have moved around (mmu.c is now in arch/x86/kvm/). Sure, rebased. thx,eddie tlb-clean1.patch2 Description: tlb-clean1.patch2 - 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
On Fri, 2007-12-14 at 10:07 +0100, Christian Ehrhardt wrote: 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? Yes! Hopefully much shorter than this email... :-P -- Hollis Blanchard IBM Linux Technology Center - 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] [kvm-ppc-devel] Current e500 kvm guest kernel booting log
Hollis Blanchard wrote: On Fri, 2007-12-14 at 14:15 +0800, Zhang Wei wrote: Hollis Blanchard wrote: On Thu, 2007-12-13 at 18:14 +0800, Zhang Wei wrote: From: Hollis Blanchard [mailto:[EMAIL PROTECTED] We haven't touched the hack code recently, since we've been refactoring the upstream tree. That's pretty much done though, and right now I'm just starting to integrate the old 440 support with the new upstream code. That's not in a good state right now, but I could clean it up and send it out if you're interested. Yes! I think hack codes are only for verifying the idea. Our target is for upstream code. I hope I could join you! Well, unfortunately at the moment I'm just fighting with asm-offsets.h . :( Since I'm basically already on vacation, I'm not sure I'll be able to get anything ready until January. Do you mind send out the asm-offsets.h? Maybe I can take it base on the hack code. Oh, the file is the same. The problem is how to have Kbuild automatically generate it. IA64 have the same issues , do you have good idea to handle it ? Now, I let kvm makefile to call a extenal script to solve it. :) Do you mean if you change the struct kvm_vcpu of the kvm.h file, but the asm-offsets.h file can not be re-generated by your current Makefile? If it is, you can modify Makefile as below: - $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c + $(obj)/kvm-offsets.s: $(src)/kvm-offsets.c FORCE Or is there any other problems about asm-offsets.h in Makefile? Yes, there is a larger problem: forget the dependencies; how do we generate asm-offsets.h in the first place? The Makefile hackery that I've posted before is not a good solution, and I'm looking for that good solution. I have a solution, but don't know this is the best one. According to the rules, all c or asm files should depend on FORCE, so in your own Makefile, you can set FORCE: asm-offsets.h , asm-offsets.h should be compiled before any Source files:) IA64 needs to generate its own asm-offsets too, and so does lguest. That's why I've been looking at the mkasm-values patches recently (google it)... - 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] (no subject)
-- Best Regards Yu Fei - 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 and SMP guests
On Friday 14 December 2007 23:12:05 Christian Borntraeger wrote:
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
Shouldn't this be BUG()ing in START_USE()? Or did you disable that because
of previous false positives?
virtnet_poll() should not be reentering, AFAICT. virtio relies on the caller
to ensure it never calls two virtio functions on the same queue
simultaneously, and virtio_net in turn relies on the core net code to enforce
this.
So, how did this happen?
Looks like we can have an interrupt on one CPU, which does:
if (vq-vq.callback !vq-vq.callback(vq-vq))
vq-vring.avail-flags |= VRING_AVAIL_F_NO_INTERRUPT;
The callback schedules the softirq to run, which usually runs on same CPU...
but if somehow it runs somewhere else, it could hit restart before the flag
is set. This means removing the BUG_ON() is bad, because we could restart,
and then set the NO_INTERRUPT flag from the handler, and stall.
Note that interrupt suppression is advisory, so we can be sloppy on the
setting side.
To me this points to doing interrupt suppression a different way. If we
have a -disable_cb() virtio function, and call it before we call
netif_rx_schedule, does that fix it?
How's this?
Rusty.
---
virtio: explicit enable_cb/disable_cb rather than callback return.
It seems that virtio_net wants to disable callbacks (interrupts) before
calling netif_rx_schedule(), so we can't use the return value to do so.
Rename restart to cb_enable and introduce cb_disable hook: callback
now returns void, rather than a boolean.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
diff -r 0eabf082c13a drivers/block/virtio_blk.c
--- a/drivers/block/virtio_blk.cTue Dec 18 13:51:13 2007 +1100
+++ b/drivers/block/virtio_blk.cTue Dec 18 15:49:18 2007 +1100
@@ -36,7 +36,7 @@ struct virtblk_req
struct virtio_blk_inhdr in_hdr;
};
-static bool blk_done(struct virtqueue *vq)
+static void blk_done(struct virtqueue *vq)
{
struct virtio_blk *vblk = vq-vdev-priv;
struct virtblk_req *vbr;
@@ -65,7 +65,6 @@ static bool blk_done(struct virtqueue *v
/* In case queue is stopped waiting for more buffers. */
blk_start_queue(vblk-disk-queue);
spin_unlock_irqrestore(vblk-lock, flags);
- return true;
}
static bool do_req(struct request_queue *q, struct virtio_blk *vblk,
diff -r 0eabf082c13a drivers/lguest/lguest_device.c
---
Re: [kvm-devel] [PATCH resent] virtio_net: Fix stalled inbound trafficon early packets
On Friday 14 December 2007 05:30:31 Christian Borntraeger wrote: Rusty, if you decide to apply my patch, there is one downside: The debugging code in virtio_ring sometimes triggers with a false positive: try_fill_recv calls vring_kick. Here we do a notify to the host. This might cause an immediate interrupt, triggering the poll routine before vring_kick can run END_USE. This is no real problem, as we dont touch the vq after notify. Hmm, how about we just do something like this? (needs previous enable_cb patch) Christian, facing 64 guest cpus unconvering all kind of races Heroic is the word which comes to mind... :) Cheers, Rusty. --- virtio: flush buffers on open Fix bug found by Christian Borntraeger: if the other side fills all the registered network buffers before we enable NAPI, we will never get an interrupt. The simplest fix is to process the input queue once on open. Signed-off-by: Rusty Russell [EMAIL PROTECTED] diff -r 1dd61213039c drivers/net/virtio_net.c --- a/drivers/net/virtio_net.c Tue Dec 18 17:34:18 2007 +1100 +++ b/drivers/net/virtio_net.c Tue Dec 18 17:47:39 2007 +1100 @@ -326,6 +326,13 @@ static int virtnet_open(struct net_devic return -ENOMEM; napi_enable(vi-napi); + + /* If all buffers were filled by other side before we napi_enabled, we +* won't get another interrupt, so process any outstanding packets +* now. virtnet_poll wants re-enable the queue, so we disable here. */ + vi-rvq-vq_ops-disable_cb(vi-rvq); + netif_rx_schedule(vi-dev, vi-napi); + return 0; } - 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 ar m tx hrtimer with a constant 500us each transmit
On Tuesday 18 December 2007 16:30:08 Avi Kivity wrote: Rusty Russell wrote: Yes, I pondered this when I wrote the code. On the one hand, it's a low-probability pathological corner case, on the other, your patch reduces the number of timer reprograms in the normal case. One thing that came up in our discussions is to let the host do the timer processing instead of the guest. When tx exit mitigation is enabled, the guest bumps the queue pointer, but carefully refrains from kicking the host. The host polls the tx pointer using a timer, kicking itself periodically; if polling yields no packets it disables tx exit mitigation. This saves the guest the bother of programming the timer, which presumably requires an exit if the timer is the closest one to expiration. [btw, this can be implemented in virtqueue rather than virtio-net, no?] Yes, the current patch is a hack (look at the hardcoded constant); wanted to see how much it helps, if any. More sophisticated timer management would be a definite win... funny, I have a patch here which helps that Rusty. - 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
