Paolo Bonzini wrote:
> Il 11/09/2014 19:03, Chris Webb ha scritto:
>> Paolo Bonzini wrote:
>>
>>> This is a hypercall that should have kicked VCPU 3 (see rcx).
>>>
>>> Can you please apply this patch and gather a trace of the host
>>> (u
Paolo Bonzini wrote:
> This is a hypercall that should have kicked VCPU 3 (see rcx).
>
> Can you please apply this patch and gather a trace of the host
> (using "trace-cmd -e kvm qemu-kvm ")?
Sure, no problem. I've built the trace-cmd tool against udis86 (I hope) and
have put the resulting trac
I've reported this bug before, which reliably crashes a guest kernel shortly
after boot, but have just reconfirmed that it is still present with Linux
3.16.2 guest and host kernels and Qemu 2.1.
Running a 3.16.2 x86-64 SMP guest kernel on qemu-2.1, with kvm enabled and
-cpu host on a 3.16.2 AMD Op
I see kernel 3.15 is now out, so I retested with 3.15 guest and host. I'm
still getting exactly the same guest kernel panic: a divide error in
kvm_unlock_kick with -cpu host, but not with -cpu qemu64:
divide error: [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 781 Comm: mkdir Not tainted 3
I realised my original bug report was for a guest kernel compiled without
frame pointers which might be unhelpful, so I enabled CONFIG_DEBUG_INFO and
CONFIG_FRAME_POINTER, but I don't think this has made the backtrace any more
detailed.
Is there anything more I can do to pinpoint what might be goi
Paolo Bonzini wrote:
> Il 29/05/2014 19:45, Chris Webb ha scritto:
>> Chris Webb wrote:
>>
>>> My CPU flags inside the crashing guest look like this:
>>>
>>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
>>>
Chris Webb wrote:
> My CPU flags inside the crashing guest look like this:
>
> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
> clflush
> mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb lm rep_good nopl
> extd_apicid pni pclmulqdq ssse3 fma
Running a 3.14.4 x86-64 SMP guest kernel on qemu-2.0, with kvm enabled and
-cpu host on a 3.14.4 AMD Opteron host, I'm seeing a reliable kernel panic from
the guest shortly after boot. I think is happening in kvm_unlock_kick() in the
paravirt_ops code:
divide error: [#1] PREEMPT SMP
Modules
Kevin Wolf writes:
> Good point... The only other thing that I can think of would be
> attaching gdb and setting a breakpoint in vm_stop() or something.
Perfect, that seems to identified what's going on very nicely:
(gdb) break vm_stop
Breakpoint 1 at 0x407d10: file /home/root/packages/qemu-kvm
Kevin Wolf writes:
> In qemu 1.0 we'll have an extended 'info status' that includes the stop
> reason, but 0.14 doesn't have this yet (was committed to git master only
> recently).
Right, okay. I might take a look at cherry-picking and back-porting that to
our version of qemu-kvm if it's not too
Kevin Wolf writes:
> Am 24.10.2011 12:00, schrieb Chris Webb:
> > I have qemu monitor access and can even strace the relevant qemu process if
> > necessary: is it possible to use this to diagnose what's caused this guest
> > to stop, e.g. the unsupported instruction if
I have a qemu-kvm guest (apparently a Ubuntu 11.04 x86-64 install) which has
stopped and refuses to continue:
(qemu) info status
VM status: paused
(qemu) cont
(qemu) info status
VM status: paused
The host is running linux 2.6.39.2 with qemu-kvm 0.14.1 on 24-core Opteron
6176 box, and ha
Hugh Dickins writes:
> KSM chooses to show the numbers pages_shared and pages_sharing as
> exclusive counts: pages_sharing indicates the saving being made. So it
> would be perfectly reasonable to add those two numbers together to get
> the "total" number of pages sharing, the number you expecte
We're running KSM on kernel 2.6.39.2 with hosts running a number qemu-kvm
virtual machines, and it has consistently been saving us a useful amount of
RAM.
To monitor the effective amount of memory saved, I've been looking at the
difference between /sys/kernel/mm/ksm/pages_sharing and pages_shared.
Avi Kivity writes:
> On 03/02/2010 11:34 AM, Jernej Simončič wrote:
> >On Tuesday, March 2, 2010, 9:21:18, Chris Webb wrote:
> >
> >>I remember about a year ago, someone asserting on the list that -usbdevice
> >>tablet was very CPU intensive even when not
Avi Kivity writes:
> On 03/22/2010 11:04 PM, Chris Webb wrote:
>
> >Unless I'm missing something, the risk to guest OSes in this configuration
> >should therefore be exactly the same as the risk from running on normal
> >commodity hardware with such drives and no
Chris Webb writes:
> Okay. What I was driving at in describing these systems as 'already broken'
> is that they will already lose data (in this sense) if they're run on bare
> metal with normal commodity SATA disks with their 32MB write caches on. That
> configuratio
Vivek Goyal writes:
> Are you using CFQ in the host? What is the host kernel version? I am not sure
> what is the problem here but you might want to play with IO controller and put
> these guests in individual cgroups and see if you get better throughput even
> with cache=writethrough.
Hi. We're
Avi Kivity writes:
> Chris, can you carry out an experiment? Write a program that
> pwrite()s a byte to a file at the same location repeatedly, with the
> file opened using O_SYNC. Measure the write rate, and run blktrace
> on the host to see what the disk (/dev/sda, not the volume) sees.
> Sho
Anthony Liguori writes:
> On 03/17/2010 10:14 AM, Chris Webb wrote:
> > (c) installations that are already broken and lose data with a physical
> > drive with a write-cache can lose much more in this case because the
> > write cache is much bigger?
>
>
Avi Kivity writes:
> On 03/15/2010 10:23 PM, Chris Webb wrote:
>
> >Wasteful duplication of page cache between guest and host notwithstanding,
> >turning on cache=writeback is a spectacular performance win for our guests.
>
> Is this with qcow2, raw file, or direct volu
Anthony Liguori writes:
> This really gets down to your definition of "safe" behaviour. As it
> stands, if you suffer a power outage, it may lead to guest
> corruption.
>
> While we are correct in advertising a write-cache, write-caches are
> volatile and should a drive lose power, it could lea
Avi Kivity writes:
> On 03/15/2010 10:07 AM, Balbir Singh wrote:
>
> >Yes, it is a virtio call away, but is the cost of paying twice in
> >terms of memory acceptable?
>
> Usually, it isn't, which is why I recommend cache=off.
Hi Avi. One observation about your recommendation for cache=none:
We
Chris Webb writes:
> During boot, the screen gets resized to height 1 and a mouse click at this
> point will cause a division by zero when calculating the absolute pointer
> position from the pixel (x, y). Return a click in the middle of the screen
> instead in this case.
I think t
During boot, the screen gets resized to height 1 and a mouse click at this
point will cause a division by zero when calculating the absolute pointer
position from the pixel (x, y). Return a click in the middle of the screen
instead in this case.
Signed-off-by: Chris Webb
---
vnc.c |6
Alexander Graf writes:
> On 05.03.2010, at 17:52, Chris Webb wrote:
>
> > Of course, if the screen width or height is 1, it doesn't really matter what
> > the value of the mouse position for the click is, so something as simple as
> >
> > diff --git a/vnc.
Anthony Liguori writes:
> On 03/01/2010 12:14 PM, Chris Webb wrote:
> >We've just seen another VNC related qemu-kvm crash, this time an arithmetic
> >exception at vnc.c:1424 in the newly release qemu-kvm 0.12.3.
> >
> > [...]
> > 1
Ingo Molnar writes:
> Yes, you are quite correct: udev has been argued to be a prime candidate for
> tools/. (and some other kernel utilities as well)
A small, static set of userspace like klibc (only 5M unpacked!) with enough
tools for rolling up in a standard initramfs would be especially nic
Dustin Kirkland writes:
> On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
> >
> > Defaulting usb to on and defaulting to a usb tablet is a reasonable
> > thing to do IMHO.
>
> \o/ Definitely a better user experience.
I remember about a year ago, someone asserting on the list that -
We've just seen another VNC related qemu-kvm crash, this time an arithmetic
exception at vnc.c:1424 in the newly release qemu-kvm 0.12.3.
[...]
1423 if (vs->absolute) {
1424 kbd_mouse_event(x * 0x7FFF / (ds_get_width(vs->ds) - 1),
1425 y * 0x7FFF / (ds_
Avi Kivity writes:
> On 02/21/2010 07:23 PM, Chris Webb wrote:
> >Some sort of race where a client disconnects and is removed from the client
> >list while the vnc_refresh() loop is iterating over it, maybe?
>
> Looks like c727a05459, and high time for 0.12.3. Anthony?
Ah
I've just had a segfault from one of the qemu-kvm virtual machines we run.
This is qemu-kvm 0.12.2 running with the in-kernel kvm modules on linux
2.6.32.7 on a dual quad-core Xeon E5420 machine, with ksm enabled.
The backtrace looks like
#0 vnc_update_client (vs=0x83f0, has_dirty=18) at vnc.c
Javier Guerra writes:
> i'd just want to add my '+1 votes' on both getting rid of JVM
> dependency and using block devices (usually LVM) instead of ext3/btrfs
If the chunks into which the virtual drives are split are quite small (say
the 64MB used by Hadoop), LVM may be a less appropriate choice
Chris Webb writes:
> MORITA Kazutaka writes:
>
> > We use JGroups (Java library) for reliable multicast communication in
> > our cluster manager daemon. We don't worry about the performance much
> > since the cluster manager daemon is not involved in the I/O p
MORITA Kazutaka writes:
> We use JGroups (Java library) for reliable multicast communication in
> our cluster manager daemon. We don't worry about the performance much
> since the cluster manager daemon is not involved in the I/O path. We
> might think about moving to corosync if it is more stabl
Chris Webb writes:
> With the following applied, VNC connections and disconnections still work
> correctly, so it doesn't horribly break anything, but I can't immediately
> confirm whether it will cure the rare segfaults as I haven't yet found a
> rapid way of reprodu
Avi Kivity writes:
> master branch has a patch that fixes a use-after-free when
> disconnecting. Unfortunately it doesn't port cleanly to stable-0.10.
I've collected quite a few more core dumps from segfaults of client virtual
machines now, all of which are VNC related and could quite plausib
Chris Webb writes:
> Avi Kivity writes:
>
> > csock looks corrupted, should be -1 or an fd. Was a vnc client connected?
> > Was the guest playing with the display resolution?
>
> Yes, I think in this case there was a vncviewer connected, and the guest had
> star
Avi Kivity writes:
> csock looks corrupted, should be -1 or an fd. Was a vnc client connected?
> Was the guest playing with the display resolution?
Yes, I think in this case there was a vncviewer connected, and the guest had
started booting up into windows, which changes the resolution a couple
Chris Webb writes:
> The segfault appears to be a null pointer dereference. ts->clock is NULL
> and line 1161 uses ts->clock->type:
>
> (gdb) p ts
> $4 = (QEMUTimer *) 0x30d1f30
> (gdb) p ts->clock
> $5 = (QEMUClock *) 0x0
Sorry, meant to paste this
Chris Webb writes:
> Avi Kivity writes:
>
> > I understand it's hard, but it's nearly impossible to work out the
> > problem from so little data, so please do make the effort to obtain
> > dumps.
>
> We're trying for this at the moment, b
Avi Kivity writes:
> I understand it's hard, but it's nearly impossible to work out the
> problem from so little data, so please do make the effort to obtain
> dumps.
We're trying for this at the moment, but since we can't change the rlimit
for the running qemu-kvm processes (?), we'll have t
I have a couple of clusters hosting qemu-kvm virtual machines. One of these
clusters consists of dual quad-core Xeon E5420s (vmx), the other consists of
dual quad-core Barcelona Opterons (svm), and both are running x86-64 Linux
2.6.30.4 with the kvm modules included with the upstream kernel compile
Michael Jinks writes:
> How do I make a guest use a specific tap? Quoting
> from my initial post, my -net options are:
>
> -net nic -net tap,name=tap11 -net nic -net tap,name=tap12
You want
-net nic,vlan=0 -net tap,vlan=0,ifname=tap11 -net nic,vlan=1 -net
tap,vlan=1,ifname=tap12
to get t
Fabian Deutsch <[EMAIL PROTECTED]> writes:
> Can you resend them as inline patches?
Sure, no problem: I've resent the original messages which had the patches
inline.
Best wishes,
Chris.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTE
Accept password as an argument to 'change vnc password' monitor command
This allows easier use of the change vnc password monitor command from
management scripts, without having to implement expect(1)-like behaviour.
Signed-off-by: Chris Webb <[EMAIL PROTECTED]>
---
moni
ectly.
Signed-off-by: Chris Webb <[EMAIL PROTECTED]>
---
monitor.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index 22360fc..a252838 100644
--- a/monitor.c
+++ b/monitor.c
@@ -433,8 +433,7 @@ static void do_change_vnc(const char *targ
esn't. The other site
where monitor_readline reads a password (in vl.c) passes the buffer length
correctly.
Signed-off-by: Chris Webb <[EMAIL PROTECTED]>
---
monitor.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index 22360fc..a252838 1
Accept password as an argument to 'change vnc password' monitor command
This allows easier use of the change vnc password monitor command from
management scripts, without having to implement expect(1)-like behaviour.
Signed-off-by: Chris Webb <[EMAIL PROTECTED]>
---
moni
ectly.
Signed-off-by: Chris Webb <[EMAIL PROTECTED]>
---
monitor.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index 22360fc..a252838 100644
--- a/monitor.c
+++ b/monitor.c
@@ -433,8 +433,7 @@ static void do_change_vnc(const char *targ
Thiemo Seufer <[EMAIL PROTECTED]> writes:
> Chris Webb wrote:
[...]
> > - monitor_readline("Password: ", 1, password, sizeof(password)-1);
> > + monitor_readline("Password: ", 1, password, sizeof(password));
> > password[sizeof(password)-1]
Accept password as an argument to 'change vnc password' monitor command
This allows easier use of the change vnc password monitor command from
management scripts, without having to implement expect(1)-like behaviour.
Signed-off-by: Chris Webb <[EMAIL PROTECTED]>
---
moni
ectly.
Signed-off-by: Chris Webb <[EMAIL PROTECTED]>
---
monitor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 22360fc..6ae5729 100644
--- a/monitor.c
+++ b/monitor.c
@@ -433,7 +433,7 @@ static void do_change_vnc(const char *target)
Jan Kiszka <[EMAIL PROTECTED]> writes:
> The reset issue might be fixed in kvm-userspace.git via commit
> 888cc6aa65369be5f648a27381aa98569755ac61
> (http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commitdiff_plain;h=888cc6aa65369be5f648a27381aa98569755ac61).
Thanks! I'll apply that patch t
We're running kvm-78 in production on Linux 2.6.27 x86_64 on dual quad-core
Opteron 'Barcelona' machines. Our kvm modules are built from the kvm-78
sources rather than the older version bundled with the kernel, and we're
using the NPT features of the processors.
For the most part, everything is pe
Javier Guerra Giraldez <[EMAIL PROTECTED]> writes:
> On Wednesday 11 June 2008, Chris Webb wrote:
> > Hi. I have a small 'qemu-send' utility for talking to a running qemu/kvm
> > process whose monitor console listens on a filesystem socket, which I think
> >
Freddie Cash <[EMAIL PROTECTED]> writes:
> For everyone's viewing (and critiquing, I guess) pleasure, I present
> my version of a kvmctl script.
Hi. I have a small 'qemu-send' utility for talking to a running qemu/kvm
process whose monitor console listens on a filesystem socket, which I think
mig
I'm experiencing a number of problems with kvm on a 32-bit x86 host when
migrating some SMP guests. The symptoms are identical on both kvm-68 and
kvm-69.
Two out of my three test guests are currently failing to migrate: a stock
FreeBSD 7.0 install and an out-of-the-box WinXP install. My other test
58 matches
Mail list logo
