On Tue, Sep 27, 2011 at 04:04:41PM -0600, Thomas Fjellstrom wrote:
On September 27, 2011, Avi Kivity wrote:
On 09/27/2011 03:29 AM, Thomas Fjellstrom wrote:
I just noticed something interesting, a virtual machine on one of my
servers seems to have 69 threads (including the main thread).
On Tue, Sep 27, 2011 at 08:10:21PM +0200, Reeted wrote:
I repost this, this time by also including the libvirt mailing list.
Info on my libvirt: it's the version in Ubuntu 11.04 Natty which is
0.8.8-1ubuntu6.5 . I didn't recompile this one, while Kernel and
qemu-kvm are vanilla and compiled
On September 28, 2011, Daniel P. Berrange wrote:
On Tue, Sep 27, 2011 at 04:04:41PM -0600, Thomas Fjellstrom wrote:
On September 27, 2011, Avi Kivity wrote:
On 09/27/2011 03:29 AM, Thomas Fjellstrom wrote:
I just noticed something interesting, a virtual machine on one of my
servers
On 28.09.2011, at 04:40, Alex Williamson wrote:
On Tue, 2011-09-27 at 16:28 -0500, Scott Wood wrote:
On 09/26/2011 07:45 PM, Alex Williamson wrote:
On Mon, 2011-09-26 at 18:59 -0500, Scott Wood wrote:
On 09/26/2011 01:34 PM, Alex Williamson wrote:
/* Reset the device */
#define
On 09/28/11 09:51, Daniel P. Berrange wrote:
On Tue, Sep 27, 2011 at 08:10:21PM +0200, Reeted wrote:
I repost this, this time by also including the libvirt mailing list.
Info on my libvirt: it's the version in Ubuntu 11.04 Natty which is
0.8.8-1ubuntu6.5 . I didn't recompile this one, while
On Wed, Sep 28, 2011 at 11:19:43AM +0200, Reeted wrote:
On 09/28/11 09:51, Daniel P. Berrange wrote:
This is my bash commandline:
/opt/qemu-kvm-0.14.1/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm
-m 2002 -smp 2,sockets=2,cores=1,threads=1 -name vmname1-1 -uuid
On 09/28/11 11:28, Daniel P. Berrange wrote:
On Wed, Sep 28, 2011 at 11:19:43AM +0200, Reeted wrote:
On 09/28/11 09:51, Daniel P. Berrange wrote:
This is my bash commandline:
/opt/qemu-kvm-0.14.1/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm
-m 2002 -smp 2,sockets=2,cores=1,threads=1 -name
On Wed, Sep 28, 2011 at 11:49:01AM +0200, Reeted wrote:
On 09/28/11 11:28, Daniel P. Berrange wrote:
On Wed, Sep 28, 2011 at 11:19:43AM +0200, Reeted wrote:
On 09/28/11 09:51, Daniel P. Berrange wrote:
This is my bash commandline:
/opt/qemu-kvm-0.14.1/bin/qemu-system-x86_64 -M pc-0.14
On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote:
On 09/28/11 11:53, Daniel P. Berrange wrote:
On Wed, Sep 28, 2011 at 11:49:01AM +0200, Reeted wrote:
YES!
It's the vhost. With vhost=on it takes about 12 seconds more time to boot.
...meaning? :-)
I've no idea. I was always under the
- Original Message -
This is a second iteration of the patch. The patch has been
significantly reworked to address (offline) comments by Gleb.
I think the infrastructure created is generic enough
to be generally useful beyond the specific bug
that I would like to fix. Specifically
On Tue, 2011-09-27 at 15:37 +0300, Michael S. Tsirkin wrote:
On Tue, Sep 27, 2011 at 02:20:29PM +0300, Sasha Levin wrote:
On Tue, 2011-09-27 at 10:00 +0300, Michael S. Tsirkin wrote:
skb = page_to_skb(vi, page, len);
...
Sorry I don't get it yet. Where
On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote:
On 09/28/11 11:53, Daniel P. Berrange wrote:
On Wed, Sep 28, 2011 at 11:49:01AM +0200, Reeted wrote:
YES!
It's the vhost. With vhost=on it takes about 12 seconds more time to boot.
...meaning? :-)
I've no idea. I was always under the
On 09/28/11 11:53, Daniel P. Berrange wrote:
On Wed, Sep 28, 2011 at 11:49:01AM +0200, Reeted wrote:
YES!
It's the vhost. With vhost=on it takes about 12 seconds more time to boot.
...meaning? :-)
I've no idea. I was always under the impression that 'vhost=on' was
the 'make it go much faster'
On Tuesday 27 September 2011, 12:44:02 Jeremy Fitzhardinge wrote:
On 09/27/2011 02:34 AM, Stephan Diestelhorst wrote:
On Wednesday 14 September 2011, 17:31:32 Jeremy Fitzhardinge wrote:
This series replaces the existing paravirtualized spinlock mechanism
with a paravirtualized ticketlock
Alex,
we have this diff in qemu-kvm:
diff --git a/exec.c b/exec.c
index c1e045d..f188549 100644
--- a/exec.c
+++ b/exec.c
@@ -3950,6 +3955,11 @@ void cpu_physical_memory_rw(target_phys_addr_t addr,
uint8_t *buf,
cpu_physical_memory_set_dirty_flags(
On 28.09.2011, at 16:23, Jan Kiszka wrote:
Alex,
we have this diff in qemu-kvm:
diff --git a/exec.c b/exec.c
index c1e045d..f188549 100644
--- a/exec.c
+++ b/exec.c
@@ -3950,6 +3955,11 @@ void cpu_physical_memory_rw(target_phys_addr_t addr,
uint8_t *buf,
This patch verifies that the length of a buffer stored in a linked list
of pages is small enough to fit into a skb.
If the size is larger than a max size of a skb, it means that we shouldn't
go ahead building skbs anyway since we won't be able to send the buffer as
the user requested.
Cc: Rusty
This patch prevents a NULL dereference when the user has passed a length
longer than an actual buffer to virtio-net.
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Michael S. Tsirkin m...@redhat.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Cc: kvm@vger.kernel.org
On 2011-09-28 16:26, Alexander Graf wrote:
On 28.09.2011, at 16:23, Jan Kiszka wrote:
Alex,
we have this diff in qemu-kvm:
diff --git a/exec.c b/exec.c
index c1e045d..f188549 100644
--- a/exec.c
+++ b/exec.c
@@ -3950,6 +3955,11 @@ void cpu_physical_memory_rw(target_phys_addr_t addr,
On 2011-09-28 16:45, Jan Kiszka wrote:
On 2011-09-28 16:26, Alexander Graf wrote:
On 28.09.2011, at 16:23, Jan Kiszka wrote:
Alex,
we have this diff in qemu-kvm:
diff --git a/exec.c b/exec.c
index c1e045d..f188549 100644
--- a/exec.c
+++ b/exec.c
@@ -3950,6 +3955,11 @@ void
No longer required as we use upstream posix-aio-compat now.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Makefile.objs |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index cb10816..afd6137 100644
--- a/Makefile.objs
+++
We no longer get here if KVM is enabled.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
exec.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index f188549..83ffa39 100644
--- a/exec.c
+++ b/exec.c
@@ -470,9 +470,6 @@ static uint8_t
On 09/28/11 14:56, Richard W.M. Jones wrote:
On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote:
Ok that seems to work: it removes the vhost part in the virsh launch
hence cutting down 12secs of boot time.
If nobody comes out with an explanation of why, I will open another
thread on the
This is already done in kvm_arch_init_vcpu based on the kernel-reported
supported features.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
I'm not 100% sure, so please double-check.
target-i386/cpuid.c | 22 --
1 files changed, 0 insertions(+), 22 deletions(-)
diff
Am 28.09.2011 um 16:49 schrieb Jan Kiszka jan.kis...@siemens.com:
On 2011-09-28 16:45, Jan Kiszka wrote:
On 2011-09-28 16:26, Alexander Graf wrote:
On 28.09.2011, at 16:23, Jan Kiszka wrote:
Alex,
we have this diff in qemu-kvm:
diff --git a/exec.c b/exec.c
index c1e045d..f188549
Hi all,
in order to reduce the diff between qemu-kvm.git and upstream, getting
rid of the kvm subdirectory would be nice. What bits there are actually
still in use today?
From the top of my head, I only remember running kvm_stat and
scripts/vmxcap from time to time. Obviously, there is
On Tue, Sep 27, 2011 at 9:44 AM, Jeremy Fitzhardinge jer...@goop.org wrote:
I guess it comes down to throwing myself on the efficiency of some kind
of fence instruction. I guess an lfence would be sufficient; is that
any more efficient than a full mfence? At least I can make it so that
its
On 28.09.11 at 17:38, Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, Sep 27, 2011 at 9:44 AM, Jeremy Fitzhardinge jer...@goop.org wrote:
I guess it comes down to throwing myself on the efficiency of some kind
of fence instruction. I guess an lfence would be sufficient; is that
On Wed, Sep 28, 2011 at 8:55 AM, Jan Beulich jbeul...@suse.com wrote:
just use lock xaddw there too.
I'm afraid that's not possible, as that might carry from the low 8 bits
into the upper 8 ones, which must be avoided.
Oh damn, you're right. So I guess the right way to do things is with
On 09/28/2011 09:10 AM, Linus Torvalds wrote:
On Wed, Sep 28, 2011 at 8:55 AM, Jan Beulich jbeul...@suse.com wrote:
just use lock xaddw there too.
I'm afraid that's not possible, as that might carry from the low 8 bits
into the upper 8 ones, which must be avoided.
Oh damn, you're right. So I
On 09/28/2011 06:58 AM, Stephan Diestelhorst wrote:
I have tested this and have not seen it fail on publicly released AMD
systems. But as I have tried to point out, this does not mean it is
safe to do in software, because future microarchtectures may have more
capable forwarding engines.
On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge jer...@goop.org wrote:
Could do something like:
if (ticket-head = 254)
prev = xadd(ticket-head_tail, 0xff02);
else
prev = xadd(ticket-head_tail, 0x0002);
to compensate for the overflow.
Oh
On 09/28/2011 09:45 AM, Jan Kiszka wrote:
On 2011-09-28 16:26, Alexander Graf wrote:
On 28.09.2011, at 16:23, Jan Kiszka wrote:
Alex,
we have this diff in qemu-kvm:
diff --git a/exec.c b/exec.c
index c1e045d..f188549 100644
--- a/exec.c
+++ b/exec.c
@@ -3950,6 +3955,11 @@ void
On 09/28/2011 10:22 AM, Linus Torvalds wrote:
On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge jer...@goop.org wrote:
Could do something like:
if (ticket-head = 254)
prev = xadd(ticket-head_tail, 0xff02);
else
prev = xadd(ticket-head_tail,
On 09/28/2011 10:24 AM, H. Peter Anvin wrote:
On 09/28/2011 10:22 AM, Linus Torvalds wrote:
On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge jer...@goop.org wrote:
Could do something like:
if (ticket-head = 254)
prev = xadd(ticket-head_tail, 0xff02);
else
On Wednesday 28 September 2011 19:50:08 Jeremy Fitzhardinge wrote:
On 09/28/2011 10:24 AM, H. Peter Anvin wrote:
On 09/28/2011 10:22 AM, Linus Torvalds wrote:
On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge jer...@goop.org
wrote:
Could do something like:
if (ticket-head =
On Wednesday 28 September 2011 18:44:25 Jeremy Fitzhardinge wrote:
On 09/28/2011 06:58 AM, Stephan Diestelhorst wrote:
I guess it comes down to throwing myself on the efficiency of some kind
of fence instruction. I guess an lfence would be sufficient; is that
any more efficient than a full
On 09/28/2011 11:08 AM, Stephan Diestelhorst wrote:
On Wednesday 28 September 2011 19:50:08 Jeremy Fitzhardinge wrote:
On 09/28/2011 10:24 AM, H. Peter Anvin wrote:
On 09/28/2011 10:22 AM, Linus Torvalds wrote:
On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge jer...@goop.org
wrote:
On Mon, 2011-09-19 at 17:19 +0930, Rusty Russell wrote:
On Mon, 19 Sep 2011 09:01:50 +0300, Michael S. Tsirkin m...@redhat.com
wrote:
On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
On Sat, 20 Aug 2011 23:00:44 +0300, Michael S. Tsirkin
m...@redhat.com wrote:
On Fri,
On Wed, Sep 28, 2011 at 11:08 AM, Stephan Diestelhorst
stephan.diestelho...@amd.com wrote:
I must have missed the part when this turned into the propose-the-
craziest-way-that-this-still-works.contest :)
So doing it just with the lock addb probably works fine, but I have
to say that I
On 09/28/2011 11:49 AM, Linus Torvalds wrote:
But I don't care all *that* deeply. I do agree that the xaddw trick is
pretty tricky. I just happen to think that it's actually *less* tricky
than read the upper bits separately and depend on subtle ordering
issues with another writer that happens
On Wed, 2011-09-28 at 16:26 +0200, Alexander Graf wrote:
This makes sure that when device emulation overwrites code that is
already present in the cache of a CPU, it gets flushed from the
icache. I'm fairly sure we want that :). But let's ask Ben and David
as well.
Hrm we don't need that.
On Wed, 2011-09-28 at 12:27 -0500, Scott Wood wrote:
Why would it need to be synchronous? Even if it's asynchronous emulated
DMA, we don't want it sitting around only in a data cache that
instruction fetches won't snoop.
Except that this is exactly what happens on real HW :-)
The guest will
On 09/28/2011 04:02 PM, Benjamin Herrenschmidt wrote:
On Wed, 2011-09-28 at 12:27 -0500, Scott Wood wrote:
Why would it need to be synchronous? Even if it's asynchronous emulated
DMA, we don't want it sitting around only in a data cache that
instruction fetches won't snoop.
Except that
On Wed, 2011-09-28 at 16:20 -0500, Scott Wood wrote:
Sure, if there might be stale stuff in the icache, the guest will need
to invalidate that. But when running on real hardware, an OS does not
need to flush it out of data cache after a DMA transaction[1]. So
technically we just want a
On 09/28/11 16:51, Reeted wrote:
On 09/28/11 14:56, Richard W.M. Jones wrote:
On Wed, Sep 28, 2011 at 12:19:09PM +0200, Reeted wrote:
Ok that seems to work: it removes the vhost part in the virsh launch
hence cutting down 12secs of boot time.
If nobody comes out with an explanation of why, I
On Tue, Sep 27, 2011 at 12:49:29PM +0300, Avi Kivity wrote:
On 09/27/2011 12:00 PM, Robin Lee Powell wrote:
On Tue, Sep 27, 2011 at 01:48:43AM -0700, Robin Lee Powell wrote:
On Tue, Sep 27, 2011 at 04:41:33PM +0800, Emmanuel Noobadmin wrote:
On 9/27/11, Robin Lee
On Wed, Sep 28, 2011 at 05:11:06PM -0700, Robin Lee Powell wrote:
On Tue, Sep 27, 2011 at 12:49:29PM +0300, Avi Kivity wrote:
On 09/27/2011 12:00 PM, Robin Lee Powell wrote:
On Tue, Sep 27, 2011 at 01:48:43AM -0700, Robin Lee Powell wrote:
On Tue, Sep 27, 2011 at 04:41:33PM +0800,
commit f9c29774d2174df6ffc20becec20928948198914
changed the PCIe Capability structure version check
from if 2 fail, to if ==1, size=x, if ==2, size=y,
else fail.
Turns out the 82599's VF has an errata where it's
PCIe Cap struct version is 0, which now fails device assignment
due to the else
* Donald Dutile (ddut...@redhat.com) wrote:
commit f9c29774d2174df6ffc20becec20928948198914
changed the PCIe Capability structure version check
from if 2 fail, to if ==1, size=x, if ==2, size=y,
else fail.
Turns out the 82599's VF has an errata where it's
PCIe Cap struct version is 0, which
* Reeted (ree...@shiftmail.org) wrote:
On 09/28/11 11:28, Daniel P. Berrange wrote:
On Wed, Sep 28, 2011 at 11:19:43AM +0200, Reeted wrote:
On 09/28/11 09:51, Daniel P. Berrange wrote:
You could have equivalently used
-netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0,vhost=on
* Ren, Yongjie (yongjie@intel.com) wrote:
I'm using kvm and qemu upstream on https://github.com/avikivity
The following command line was right for me about three weeks ago, but now I
meet some error.
# qemu-system-x86_64 -m 1024 -smp 2 -device pci-assign,host=0e:00.0 -hda
Chris,
Thanks very much for you kind help.
I can't find hw/device-assignment.c in the qemu.git tree.
Avi,
I clone qemu from git://github.com/avikivity/qemu.git
So device assignment is not available. But qemu-kvm.git has device-assignment
code before kernel.org is down.
Any update for this
* Ren, Yongjie (yongjie@intel.com) wrote:
Chris,
Thanks very much for you kind help.
I can't find hw/device-assignment.c in the qemu.git tree.
Avi,
I clone qemu from git://github.com/avikivity/qemu.git
So device assignment is not available. But qemu-kvm.git has device-assignment
code
On Wed, 2011-09-28 at 20:20 -0400, Donald Dutile wrote:
commit f9c29774d2174df6ffc20becec20928948198914
changed the PCIe Capability structure version check
from if 2 fail, to if ==1, size=x, if ==2, size=y,
else fail.
Turns out the 82599's VF has an errata where it's
PCIe Cap struct version
* Chris Wright (chr...@sous-sol.org) wrote:
* Ren, Yongjie (yongjie@intel.com) wrote:
Chris,
Thanks very much for you kind help.
I can't find hw/device-assignment.c in the qemu.git tree.
Avi,
I clone qemu from git://github.com/avikivity/qemu.git
So device assignment is not
-Original Message-
From: Chris Wright [mailto:chr...@sous-sol.org]
Sent: Thursday, September 29, 2011 12:33 PM
To: Ren, Yongjie
Cc: Chris Wright; Avi Kivity; KVM General
Subject: Re: how to assign a pci device to guest [with qemu.git upstream]?
* Chris Wright (chr...@sous-sol.org)
57 matches
Mail list logo
