Alexander Graf wrote:
Please make sure cpu hotplug/hotunplug (and this suspend/resume)
still work.
Make sure as in test?
I use this:
#!/usr/bin/python
import commands, time, random
processors = int(commands.getoutput('getconf _NPROCESSORS_CONF'))
def fname(cpu):
return '/sys/devices/
Felix Leimbach wrote:
Avi Kivity wrote:
Does idle=poll help things? It can cause tsc breakage similar to
cpufreq.
On the host, right? Can't test that as I cannot reboot the server.
Is tsc breakage still s.th. to watch out after I've upgraded to the
Shanghai quadcores?
No, should be gone.
W
Tomasz Chmielewski wrote:
Felix Leimbach schrieb:
OK, another bug found.
Set your MTU to 100.
On two hosts, do:
HOST1_MTU1500# dd if=/dev/zero | ssh mana...@host2 dd of=/dev/null
HOST2_MTU100# dd if=/dev/zero | ssh mana...@host1 dd of=/dev/null
HOST2 with MTU 100 will crash after 10-15 minu
Andi Kleen wrote:
KVM flushes tlbs on remote cpus for two purposes: to protect guest pages
that it needs to collect information about, and to prevent stale tlb entries
from pointing to pages that no longer belong to the guest.
I assume you have numbers with some benchmark how much that
im
Avi,
Avi Kivity wrote:
packet counters are will within 32-bit limits. byte counters not so
interesting.
This night my test overflowed the *packet* counters twice without any
slowness or loss of connectivity.
Snippet from my log file of the sending VM (linux 2.6.27):
Wed Mar 18 05:14:18 CET
I'm having trouble compiling C++ code that #includes .
There was a patch several months back and a request for an update to
that patch, though the latest kernels still do not seem to work
correctly. Is this something that is on anyone's radar?
http://www.mail-archive.com/kvm@vger.kernel.org/msg06
On Tue, 17 Mar 2009 17:12:48 -0700 Alexander Duyck
wrote:
> Thanks for all the comments. I tried to incorporate most of them into
> the igbvf driver and also ended up porting some over to our other
> drivers, specifically igb since the igbvf driver copies much of the code.
>
> I have added m
Avi Kivity writes:
> KVM flushes tlbs on remote cpus for two purposes: to protect guest pages
> that it needs to collect information about, and to prevent stale tlb entries
> from pointing to pages that no longer belong to the guest.
I assume you have numbers with some benchmark how much that
i
Jan Kiszka writes:
>
> At least you could try to apply your findings in an analogous way to the
> 16-bit case. Note in the change log that there is no test case yet and
> let us wait for someone else to come around and stress it (which
> probably means that we had no user for that use case so far
Thanks for all the comments. I tried to incorporate most of them into
the igbvf driver and also ended up porting some over to our other
drivers, specifically igb since the igbvf driver copies much of the code.
I have added my comments inline below.
Thanks,
Alex
Andrew Morton wrote:
On Tue,
I accidentally tried to run a 64-bit guest on a 32-bit host. Even
though this isn't supported, it shouldn't crash my kernel. :-)
CPU: Intel Core 2 Quad
KVM: kernel kvm-84-640-g967f619, userspace kvm-84-304-g2ced1d8. Also
occurs with vanilla kvm-84.
Host kernel: Vanilla 2.6.28
Host arch: i38
Tomasz Chmielewski schrieb:
Tomasz Chmielewski schrieb:
Sorry, both machines run Debian Lenny and 2.6.26 kernel.
The only difference is that machine which crashes (with MTU=100) or
locks up (with MTU=1500) runs a "2.6.26-1-686" kernel and the one
which doesn't lock up runs "2.6.26-1-486" kern
Tomasz Chmielewski schrieb:
Sorry, both machines run Debian Lenny and 2.6.26 kernel.
The only difference is that machine which crashes (with MTU=100) or
locks up (with MTU=1500) runs a "2.6.26-1-686" kernel and the one which
doesn't lock up runs "2.6.26-1-486" kernel (both are Debian's kernels
On 17.03.2009, at 13:04, Avi Kivity wrote:
Alexander Graf wrote:
X86 CPUs need to have some magic happening to enable the
virtualization
extensions on them. This magic can result in unpleasant results for
users, like blocking other VMMs from working (vmx) or using invalid
TLB
entries (sv
On Tue, Mar 17, 2009 at 10:55:48AM -0300, Marcelo Tosatti wrote:
> I think that enforcing the correct type on deassign is alright.
>
> Avi, I'm good with this patchset, we can force the correct type on
> deassign ioctl as a separate kernel patch.
Err, meant v6 patchset.
--
To unsubscribe from th
Tomasz Chmielewski schrieb:
See this screenshot:
http://www1.wpkg.org/lockup.png
Guest that locks up is running Debian Lenny with 2.6.26 kernel.
Guest that does not lock up runs Mandriva 2009.0 with 2.6.27.x kernel.
(data being transferred both side to/from each of these hosts).
Sorry, both
On Mon, Mar 16, 2009 at 01:07:50PM +0200, Avi Kivity wrote:
> KVM flushes tlbs on remote cpus for two purposes: to protect guest pages
> that it needs to collect information about, and to prevent stale tlb entries
> from pointing to pages that no longer belong to the guest.
>
> We can defer the la
Felix Leimbach schrieb:
OK, another bug found.
Set your MTU to 100.
On two hosts, do:
HOST1_MTU1500# dd if=/dev/zero | ssh mana...@host2 dd of=/dev/null
HOST2_MTU100# dd if=/dev/zero | ssh mana...@host1 dd of=/dev/null
HOST2 with MTU 100 will crash after 10-15 minutes (with packet count
sti
Tomasz Chmielewski wrote:
Tomasz Chmielewski schrieb:
Avi Kivity schrieb:
packet counters are will within 32-bit limits. byte counters not so
interesting.
Ah OK.
I did only byte overflow.
Packet overflow will take much longer. It's one of these very rare
cases where setting very small MTU
Avi Kivity wrote:
Felix Leimbach wrote:
eth0 Link encap:Ethernet HWaddr 52:54:00:74:01:01
inet addr:10.75.13.1 Bcast:10.75.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3542104 errors:0 dropped:0 overruns:0 frame:0
Tomasz Chmielewski schrieb:
Avi Kivity schrieb:
Felix Leimbach wrote:
Tomasz Chmielewski wrote:
Avi Kivity schrieb:
Might it be that some counter overflowed? What are the packet
counts on long running guests?
Here is the current ifconfig output of a machine which suffered the
problem befo
Avi Kivity wrote:
Does idle=poll help things? It can cause tsc breakage similar to
cpufreq.
On the host, right? Can't test that as I cannot reboot the server.
Is tsc breakage still s.th. to watch out after I've upgraded to the
Shanghai quadcores?
--
To unsubscribe from this list: send the lin
Hi,
I am writing to this list as I believe to have found a KVM bug and
hope that my information might be helpful to you (additionally, I
of course hope to receive a patch or some such to fix my problem).
First of all, here is what I am trying to achieve:
I have a 4-port CologneChip ISDN card (co
Avi Kivity schrieb:
Felix Leimbach wrote:
Tomasz Chmielewski wrote:
Avi Kivity schrieb:
Might it be that some counter overflowed? What are the packet
counts on long running guests?
Here is the current ifconfig output of a machine which suffered the
problem before:
eth0 Link encap:Et
Felix Leimbach schrieb:
BTW, what CPU do you have?
One dual core Opteron 2212
Note: I will upgrade to two Shanghai Quad-Cores in 2 weeks and test with
those as well.
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD O
Felix Leimbach schrieb:
I have not tried rebooting; always stopped and restarted the qemu
instance. Will try on the next occasion.
Before I wrote that I tested on kvm-83 and 84 but it turns out the
kvm-84 part was wrong: Since the upgrade 4 days ago I have not yet had a
hang.
I noticed that
Felix Leimbach wrote:
I noticed that you Tomasz are also running kvm-83. Maybe kvm-84 fixed
the issue already?
kvm-84 fixes a serious problem with kvmclock on AMDs, but does not fix
the problem with c1e, so it may not have fixed the problem completely.
--
error compiling committee.c: too man
Tomasz Chmielewski wrote:
Felix Leimbach schrieb:
I see similar behavior: After a week one of my guests' network
totally stops to respond. Only guests using virtio networking get
hit. Both windows and linux guests are affected.
Also, does guest reboot help for you (for me, it doesn't)?
Or,
Felix Leimbach wrote:
Tomasz Chmielewski wrote:
Avi Kivity schrieb:
Might it be that some counter overflowed? What are the packet
counts on long running guests?
I don't think so.
I just made both counters (TX, RX) of ifconfig for virtio interfaces
overflow several times and everything is st
Felix Leimbach wrote:
BTW, what CPU do you have?
One dual core Opteron 2212
Does idle=poll help things? It can cause tsc breakage similar to cpufreq.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body
Tomasz Chmielewski wrote:
Avi Kivity schrieb:
Might it be that some counter overflowed? What are the packet counts
on long running guests?
I don't think so.
I just made both counters (TX, RX) of ifconfig for virtio interfaces
overflow several times and everything is still as fast as it shoul
Tomasz Chmielewski wrote:
Felix Leimbach schrieb:
Out of 3 e1000 guests none has ever been hit.
Observed with kvm-83 and kvm-84 with the host running in-kernel KVM
code (linux 2.6.25.7)
Could you add a (unused) e1000 interface to your virtio guests?
As this issue happens rarely for me, maybe
Felix Leimbach schrieb:
Yes, all affected had virtio. Probably because I didn't have many
guests with e1000 interface.
After a guest gets slow, I stop it and add another interface, e1000.
If it gets slow again, I'll check if e1000 interface is slow as well.
Will keep you updated.
I see simi
Avi Kivity schrieb:
Felix Leimbach wrote:
I see similar behavior: After a week one of my guests' network totally
stops to respond. Only guests using virtio networking get hit. Both
windows and linux guests are affected.
My guests in production use e1000 and have never been hit.
While that can
On Tue, Mar 17, 2009 at 06:27:47PM +0300, Alexander Beregalov wrote:
> Hi
>
> randconfig build on ia64 fails like this
>
> CC [M] arch/ia64/kvm/../../../virt/kvm/irq_comm.o
> arch/ia64/kvm/../../../virt/kvm/irq_comm.c: In function
> 'kvm_irq_delivery_to_apic':
> arch/ia64/kvm/../../../virt/kvm
Felix Leimbach wrote:
I see similar behavior: After a week one of my guests' network totally
stops to respond. Only guests using virtio networking get hit. Both
windows and linux guests are affected.
My guests in production use e1000 and have never been hit.
While that can be a coincidence it s
Felix Leimbach schrieb:
If it gets slow again, I'll check if e1000 interface is slow as well.
Will keep you updated.
I see similar behavior: After a week one of my guests' network totally
stops to respond. Only guests using virtio networking get hit. Both
windows and linux guests are affected
Hi
randconfig build on ia64 fails like this
CC [M] arch/ia64/kvm/../../../virt/kvm/irq_comm.o
arch/ia64/kvm/../../../virt/kvm/irq_comm.c: In function
'kvm_irq_delivery_to_apic':
arch/ia64/kvm/../../../virt/kvm/irq_comm.c:53: error: 'APIC_DM_LOWEST'
undeclared (first use in this function)
Intr
Tomasz Chmielewski wrote:
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
After a week or so, network in one guest got slow with kvm-84 and no
cpufreq.
This is virtio, right? What about e1000?
(I realize it takes a week to reproduce, but maybe you have some more
experience)
Yes, all affecte
On Tue, Mar 17, 2009 at 11:40:31AM +0200, Avi Kivity wrote:
> Maybe we want different ioctl pairs for guest and host?
Don't think it is necessary.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:/
On Tue, Mar 17, 2009 at 11:43:10AM +0800, Sheng Yang wrote:
> On Tuesday 17 March 2009 02:12:11 Marcelo Tosatti wrote:
> > On Mon, Mar 16, 2009 at 11:10:47AM +0200, Avi Kivity wrote:
> > > Sheng Yang wrote:
> > >> Patch 1 and 2 are new ones, all the others had been sent before.
> > >>
> > >> This (
Alexander Graf wrote:
X86 CPUs need to have some magic happening to enable the virtualization
extensions on them. This magic can result in unpleasant results for
users, like blocking other VMMs from working (vmx) or using invalid TLB
entries (svm).
Currently KVM activates virtualization when the
Sheng Yang wrote:
It's IOR by mistake, so fix it before release.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
It's IOR by mistake, so fix it before release.
Signed-off-by: Sheng Yang
---
include/linux/kvm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f8abdbf..ee755e2 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@
Avi Kivity schrieb:
Tomasz Chmielewski wrote:
After a week or so, network in one guest got slow with kvm-84 and no
cpufreq.
This is virtio, right? What about e1000?
(I realize it takes a week to reproduce, but maybe you have some more
experience)
Yes, all affected had virtio. Probably
It's IOR by mistake, so fix it before release.
Signed-off-by: Sheng Yang
---
include/linux/kvm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f8abdbf..ee755e2 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@
Tomasz Chmielewski wrote:
After a week or so, network in one guest got slow with kvm-84 and no
cpufreq.
This is virtio, right? What about e1000?
(I realize it takes a week to reproduce, but maybe you have some more
experience)
--
error compiling committee.c: too many arguments to func
Tomasz Chmielewski schrieb:
Avi Kivity schrieb:
I'm guessing there's a problem with timers or timer interrupts.
What is the host cpu?
4 entries like this in /proc/cpuinfo:
processor : 3
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Cor
Avi Kivity wrote:
> Jan Kiszka wrote:
>> This is not a hack (it shouldn't have been merged upstream otherwise):
>> cpu_physical_memory_write_rom() takes system-wide physical addresses
>> while kvm_patch_opcode_byte() works with per-CPU linear addresses.
>>
>
> From exec.c:
>
>> /* virtual memo
Jan Kiszka wrote:
This is not a hack (it shouldn't have been merged upstream otherwise):
cpu_physical_memory_write_rom() takes system-wide physical addresses
while kvm_patch_opcode_byte() works with per-CPU linear addresses.
From exec.c:
/* virtual memory access for debug */
int cpu_memory
Avi Kivity wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> Align qemu-kvm-x86 with upstream kvm support /wrt software breakpoint
>>> support in ROM code.
>>>
>>
>> Hmm, this might not be needed as kvm-userspace is not protecting its
>> ROM. That's why I didn't pushed this so far. Howe
Marcelo Tosatti wrote:
Looks good to me, ready to be applied.
There is one pending detail in the ioctl interface. Its a minor issue,
but might become troublesome later (and can be fixed after the patchset
has been applied).
The unassign ioctl takes "struct kvm_assigned_irq" and parses its flags
Han, Weidong wrote:
Avi Kivity wrote:
Han, Weidong wrote:
kvm_deassign_pci_device is defined when KVM_CAP_DEVICE_DEASSIGNMENT
is defined. Following patch should fix the breakage.
Signoff please.
Sorry for missing it. Signed-off-by: Weidong Han
Thanks; applied.
Jan Kiszka wrote:
Jan Kiszka wrote:
Align qemu-kvm-x86 with upstream kvm support /wrt software breakpoint
support in ROM code.
Hmm, this might not be needed as kvm-userspace is not protecting its
ROM. That's why I didn't pushed this so far. However, aligning isn't
bad. But dropping thi
X86 CPUs need to have some magic happening to enable the virtualization
extensions on them. This magic can result in unpleasant results for
users, like blocking other VMMs from working (vmx) or using invalid TLB
entries (svm).
Currently KVM activates virtualization when the respective kernel modul
Jan Kiszka wrote:
[ Get, save, synchronize, put... hell. Reminds me: what's the schedule
for finally dropping libkvm? ]
Patches welcome.
I expect this will become much easier once qemu merges iothread and smp
support. Then we can feed qemu-kvm.c into kvm.c and then into upstream.
Fix
56 matches
Mail list logo
