Juan:
It's especailly important for ft to be a standalone thread, as it
may cause monitor to be blocked by network problems. what's your
schedule, maybe I can help some.
Yoshi:
in the following code:
+
+s->file = qemu_fopen_ops(s, ft_trans_put_buffer, ft_trans_get_buffer,
+
sendkey is a very good command for human using it in their monitor,
but it is not a good idea to port it to qmp, because qmp is a machine
protocol. So we introduce keydown and keyup command for qmp, they
simulate the events that keyboard send to the system.
Example, simulates ctrl+alt+f1:
{ "execu
Yoshi:
I meet one problem if I killed a ft source VM, the dest ft VM will
return errors as the following:
qemu-system-x86_64: fill buffer failed, Resource temporarily unavailable
qemu-system-x86_64: recv header failed
the problem is that the dest VM can not continue to run, as it is
inte
On Tue, Mar 8, 2011 at 11:19 AM, Avi Kivity wrote:
> You might try logging the connection with wireshark (start on the, perhaps
> later also in the guest) to see what's the cause. If you run it on both
> guest and host, you can see if packets are lost or corrupted.
I tried something else first:
On 03/09/2011 01:55 AM, Steven Rostedt wrote:
Hi Avi,
This patch set got lost in the shuffle, and I'm not looking to include
it.
Anything I need to do?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body
On Wed, Mar 9, 2011 at 7:37 AM, Jan Kiszka wrote:
> On 2011-03-08 23:53, Peter Lieven wrote:
>> Hi,
>>
>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>> have seen similar crash already in 0.13.0, but had no time to debug.
>> my guess is that this segfault is relate
ya su wrote:
Yoshi:
I meet one problem if I killed a ft source VM, the dest ft VM will
return errors as the following:
qemu-system-x86_64: fill buffer failed, Resource temporarily unavailable
qemu-system-x86_64: recv header failed
the problem is that the dest VM can not continue to r
On 2011-03-09 09:50, Corentin Chary wrote:
> On Wed, Mar 9, 2011 at 7:37 AM, Jan Kiszka wrote:
>> On 2011-03-08 23:53, Peter Lieven wrote:
>>> Hi,
>>>
>>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>>> have seen similar crash already in 0.13.0, but had no time to
In order to maximize code reuse among different virtualization
technologies, refactor the KVM test code in a way that will allow
new implementations of virtualization testing, such as xen testing.
What was done
• Create autotest_lib.client.virt and move the libraries in there,
with some renaming a
In order to allow the shared infrastructure to select
the correct vm class to instantiate a VM, introduce
the parameter vm_type, which for kvm based VMs is,
not surprisingly, 'kvm'.
Signed-off-by: Lucas Meneghel Rodrigues
---
client/tests/kvm/tests_base.cfg.sample |1 +
1 files changed, 1 in
As we have several subtests that can be shared among different
virtualization tests (kvm, xen), manipulate kvm.py to try loading
subtests from the common area (planned to be client/virt/tests) first,
then falling back to the specific test area (client/tests/kvm/tests).
Signed-off-by: Lucas Meneghe
Am 09.03.2011 08:39, schrieb Michael Tokarev:
09.03.2011 10:26, Stefan Weil wrote:
Am 08.03.2011 23:53, schrieb Peter Lieven:
Hi,
during testing of qemu-kvm-0.14.0 i can reproduce the following
segfault. i have seen similar crash already in 0.13.0, but had no time
to debug.
my guess is that th
Am 08.03.2011 16:50, schrieb Chris Wright:
> QAPI merge plans
> - should be 100% back compat
> - qmp moved over
> - hmp moved over
> - 1st pass, core infrastructure (includes test framework)
> - 2nd pass, command conversion
> - 3rd pass, more controversial bits
> - adds dependencies: glib and pytho
On Wed, Mar 09, 2011 at 08:05:54AM +0100, Francis Moreau wrote:
> Hi,
>
> On Sun, Mar 6, 2011 at 4:08 PM, Avi Kivity wrote:
> > On 03/06/2011 05:02 PM, Avi Kivity wrote:
> >>
> >> (for #TS we need additional logic... will this arch never end?)
> >>
> >
> > Actually these instructions don't genera
On 03/09/2011 11:25 AM, Gleb Natapov wrote:
On Wed, Mar 09, 2011 at 08:05:54AM +0100, Francis Moreau wrote:
> Hi,
>
> On Sun, Mar 6, 2011 at 4:08 PM, Avi Kivity wrote:
> > On 03/06/2011 05:02 PM, Avi Kivity wrote:
> >>
> >> (for #TS we need additional logic... will this arch never end?)
>
On Wed, Mar 9, 2011 at 10:26 AM, Avi Kivity wrote:
> On 03/09/2011 11:25 AM, Gleb Natapov wrote:
>>
>> On Wed, Mar 09, 2011 at 08:05:54AM +0100, Francis Moreau wrote:
>> > Hi,
>> >
>> > On Sun, Mar 6, 2011 at 4:08 PM, Avi Kivity wrote:
>> > > On 03/06/2011 05:02 PM, Avi Kivity wrote:
>> > >>
On 03/09/2011 11:28 AM, Francis Moreau wrote:
> Probably not. The problematic case is not very mainstream.
>
> We'll merge it into 2.6.39 and backport into 2.6.38.1.
maybe 2.6.35.x too ?
It will eventually trickle down to all maintained stable series.
--
error compiling committee.c: too m
On Wed, Mar 9, 2011 at 10:25 AM, Gleb Natapov wrote:
> On Wed, Mar 09, 2011 at 08:05:54AM +0100, Francis Moreau wrote:
>> Hi,
>>
>> On Sun, Mar 6, 2011 at 4:08 PM, Avi Kivity wrote:
>> > On 03/06/2011 05:02 PM, Avi Kivity wrote:
>> >>
>> >> (for #TS we need additional logic... will this arch neve
On Wed, Mar 09, 2011 at 10:30:56AM +0100, Francis Moreau wrote:
> On Wed, Mar 9, 2011 at 10:25 AM, Gleb Natapov wrote:
> > On Wed, Mar 09, 2011 at 08:05:54AM +0100, Francis Moreau wrote:
> >> Hi,
> >>
> >> On Sun, Mar 6, 2011 at 4:08 PM, Avi Kivity wrote:
> >> > On 03/06/2011 05:02 PM, Avi Kivity
On 03/08/2011 10:07 PM, Raghavendra D Prabhu wrote:
Hi,
I am seeing a few early panics inside the guest while testing
2.6.38-rc{7,8} with
qemu-kvm 0.14. I have attached the earlyprintk log of the guest. The
guest is 2.6.38-rc6 with debug and paravirt enabled. I am also
attaching the config use
Hi folks,
would it make sense to make elevator=noop the default
for virtio block devices? Or would you recommend to
set this on the kvm server instead?
Any helpful comment would be highly appreciated
Harri
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a messa
Re-reading:
>> So we are calling a IOHandlerRecord::fd_write handler that is NULL.
>> Looking at qemu_set_fd_handler2, this may happen if that function is
>> called for an existing io-handler entry with non-NULL write handler,
>> passing a NULL write and a non-NULL read handler. And all this witho
On 03/07/2011 02:55 PM, Gleb Natapov wrote:
Current implementation truncates upper 32bit of TR base address during IO
permission bitmap check. The patch fixes this.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line
On 2011-03-09 10:54, Corentin Chary wrote:
> Re-reading:
>
>>> So we are calling a IOHandlerRecord::fd_write handler that is NULL.
>>> Looking at qemu_set_fd_handler2, this may happen if that function is
>>> called for an existing io-handler entry with non-NULL write handler,
>>> passing a NULL wr
On 03/07/2011 02:55 PM, Gleb Natapov wrote:
Currently if io port + len crosses 8bit boundary in io permission bitmap the
check may allow IO that otherwise should not be allowed. The patch fixes that.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubsc
Am 09.03.2011 um 08:26 schrieb Stefan Weil:
> Am 08.03.2011 23:53, schrieb Peter Lieven:
>> Hi,
>>
>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>> have seen similar crash already in 0.13.0, but had no time to debug.
>> my guess is that this segfault is related
On 03/09/2011 11:42 AM, Harald Dunkel wrote:
Hi folks,
would it make sense to make elevator=noop the default
for virtio block devices? Or would you recommend to
set this on the kvm server instead?
I think leaving the defaults is best. The elevator on the guest serves
to schedule I/O among p
On 2011-03-09 10:58, Jan Kiszka wrote:
> On 2011-03-09 10:54, Corentin Chary wrote:
>> Re-reading:
>>
So we are calling a IOHandlerRecord::fd_write handler that is NULL.
Looking at qemu_set_fd_handler2, this may happen if that function is
called for an existing io-handler entry with
Am 09.03.2011 um 08:37 schrieb Jan Kiszka:
> On 2011-03-08 23:53, Peter Lieven wrote:
>> Hi,
>>
>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>> have seen similar crash already in 0.13.0, but had no time to debug.
>> my guess is that this segfault is related to
On 03/09/2011 11:32 AM, Gleb Natapov wrote:
On Wed, Mar 09, 2011 at 10:30:56AM +0100, Francis Moreau wrote:
> On Wed, Mar 9, 2011 at 10:25 AM, Gleb Natapov wrote:
> > On Wed, Mar 09, 2011 at 08:05:54AM +0100, Francis Moreau wrote:
> >> Hi,
> >>
> >> On Sun, Mar 6, 2011 at 4:08 PM, Avi Ki
> Probably the best way is to make vnc stop fiddling with
> qemu_set_fd_handler2, specifically in threaded mode.
> Why does it need to set/reset the write handler all the time?
I didn't write the original code, but it's probably to avoid calling a
write handler when there is no data to write. That
On Wed, Mar 9, 2011 at 11:03 AM, Avi Kivity wrote:
> On 03/09/2011 11:32 AM, Gleb Natapov wrote:
>>
>> On Wed, Mar 09, 2011 at 10:30:56AM +0100, Francis Moreau wrote:
>> > On Wed, Mar 9, 2011 at 10:25 AM, Gleb Natapov wrote:
>> > > On Wed, Mar 09, 2011 at 08:05:54AM +0100, Francis Moreau wrote
On 2011-03-09 11:06, Corentin Chary wrote:
>> Probably the best way is to make vnc stop fiddling with
>> qemu_set_fd_handler2, specifically in threaded mode.
>> Why does it need to set/reset the write handler all the time?
>
> I didn't write the original code, but it's probably to avoid calling a
>> Cheap stuff is done by the main thread (cursor, etc...). The thread
>> only do framebuffer updates.
>
> And both are synchronized with a vnc-private lock only?
Yes
> The problem with this model is the non-threaded qemu execution model.
> Even if we acquire the global mutex to protect handler u
Am 09.03.2011 um 08:37 schrieb Jan Kiszka:
> On 2011-03-08 23:53, Peter Lieven wrote:
>> Hi,
>>
>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>> have seen similar crash already in 0.13.0, but had no time to debug.
>> my guess is that this segfault is related to
On 2011-03-09 11:14, Corentin Chary wrote:
>>> Cheap stuff is done by the main thread (cursor, etc...). The thread
>>> only do framebuffer updates.
>>
>> And both are synchronized with a vnc-private lock only?
>
> Yes
>
>> The problem with this model is the non-threaded qemu execution model.
>> E
On 2011-03-09 11:16, Peter Lieven wrote:
>
> Am 09.03.2011 um 08:37 schrieb Jan Kiszka:
>
>> On 2011-03-08 23:53, Peter Lieven wrote:
>>> Hi,
>>>
>>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i
>>> have seen similar crash already in 0.13.0, but had no time to debu
Am 09.03.2011 um 11:20 schrieb Jan Kiszka:
> On 2011-03-09 11:16, Peter Lieven wrote:
>>
>> Am 09.03.2011 um 08:37 schrieb Jan Kiszka:
>>
>>> On 2011-03-08 23:53, Peter Lieven wrote:
Hi,
during testing of qemu-kvm-0.14.0 i can reproduce the following segfault.
i have seen
Am 09.03.2011 um 11:41 schrieb Corentin Chary:
> The threaded VNC servers messed up with QEMU fd handlers without
> any kind of locking, and that can cause some nasty race conditions.
>
> The IO-Thread provides appropriate locking primitives to avoid that.
> This patch makes CONFIG_VNC_THREAD de
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
The IO-Thread provides appropriate locking primitives to avoid that.
This patch makes CONFIG_VNC_THREAD depends on CONFIG_IO_THREAD,
and add lock and unlock calls ar
>> The threaded VNC servers messed up with QEMU fd handlers without
>> any kind of locking, and that can cause some nasty race conditions.
>>
>> The IO-Thread provides appropriate locking primitives to avoid that.
>> This patch makes CONFIG_VNC_THREAD depends on CONFIG_IO_THREAD,
>> and add lock an
On Wed, Mar 9, 2011 at 10:57 AM, Corentin Chary
wrote:
>>> The threaded VNC servers messed up with QEMU fd handlers without
>>> any kind of locking, and that can cause some nasty race conditions.
>>>
>>> The IO-Thread provides appropriate locking primitives to avoid that.
>>> This patch makes CONF
On Wed, Mar 9, 2011 at 10:01 AM, Avi Kivity wrote:
> On 03/09/2011 11:42 AM, Harald Dunkel wrote:
>>
>> Hi folks,
>>
>> would it make sense to make elevator=noop the default
>> for virtio block devices? Or would you recommend to
>> set this on the kvm server instead?
>>
>
> I think leaving the def
On 03/09/2011 08:37 AM, Jan Kiszka wrote:
It's probably worth validating that the iothread lock is
always held when qemu_set_fd_handler2 is invoked to confirm this race
theory, adding something like
assert(pthread_mutex_trylock(&qemu_mutex) != 0);
(that's for qemu-kvm only)
Alternatively, ioha
On 2011-03-09 12:05, Stefan Hajnoczi wrote:
> On Wed, Mar 9, 2011 at 10:57 AM, Corentin Chary
> wrote:
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
The IO-Thread provides appropriate locking
Am 09.03.2011 um 12:25 schrieb Jan Kiszka:
> On 2011-03-09 12:05, Stefan Hajnoczi wrote:
>> On Wed, Mar 9, 2011 at 10:57 AM, Corentin Chary
>> wrote:
> The threaded VNC servers messed up with QEMU fd handlers without
> any kind of locking, and that can cause some nasty race conditions.
>
On 2011-03-09 12:32, Peter Lieven wrote:
>
> Am 09.03.2011 um 12:25 schrieb Jan Kiszka:
>
>> On 2011-03-09 12:05, Stefan Hajnoczi wrote:
>>> On Wed, Mar 9, 2011 at 10:57 AM, Corentin Chary
>>> wrote:
>> The threaded VNC servers messed up with QEMU fd handlers without
>> any kind of locki
On 2011-03-09 11:41, Corentin Chary wrote:
> The threaded VNC servers messed up with QEMU fd handlers without
> any kind of locking, and that can cause some nasty race conditions.
>
> The IO-Thread provides appropriate locking primitives to avoid that.
> This patch makes CONFIG_VNC_THREAD depends
On 2011-03-09 12:20, Paolo Bonzini wrote:
> On 03/09/2011 08:37 AM, Jan Kiszka wrote:
>> It's probably worth validating that the iothread lock is
>> always held when qemu_set_fd_handler2 is invoked to confirm this race
>> theory, adding something like
>>
>> assert(pthread_mutex_trylock(&qemu_mutex)
On Wed, 2011-03-09 at 06:21 -0300, Lucas Meneghel Rodrigues wrote:
> In order to maximize code reuse among different virtualization
> technologies, refactor the KVM test code in a way that will allow
> new implementations of virtualization testing, such as xen testing.
>
> What was done
> • Create
Hello.
Dominik Klein (Cc'd) reported on irc that current
FreeBSD release hangs at boot in qemu-kvm. It is
trivially verifiable by d/loading the bootonly
FreeBSD 8.2 CD image from ftp.freebsd.org and
running
kvm -cdrom FreeBSD-8.2-RELEASE-amd64-bootonly.iso.
The guest unpacks kernel, draws a m
Le 08/03/2011 12:13, Michael S. Tsirkin a écrit :
On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-Philippe Menil wrote:
Yes, it's a 2.6.37.2 kernel.
OK, here's a debugging patch.
Please run with slab debugging as previously until you see
'eventfd bug detected!' in dmesg or until there is a crash
On 03/09/2011 02:06 PM, Michael Tokarev wrote:
Hello.
Dominik Klein (Cc'd) reported on irc that current
FreeBSD release hangs at boot in qemu-kvm. It is
trivially verifiable by d/loading the bootonly
FreeBSD 8.2 CD image from ftp.freebsd.org and
running
kvm -cdrom FreeBSD-8.2-RELEASE-amd64-
Am 09.03.2011 um 12:42 schrieb Jan Kiszka:
> On 2011-03-09 11:41, Corentin Chary wrote:
>> The threaded VNC servers messed up with QEMU fd handlers without
>> any kind of locking, and that can cause some nasty race conditions.
>>
>> The IO-Thread provides appropriate locking primitives to avoid
On Wed, 2011-03-09 at 10:50 +0200, Avi Kivity wrote:
> On 03/09/2011 01:55 AM, Steven Rostedt wrote:
> > Hi Avi,
> >
> > This patch set got lost in the shuffle, and I'm not looking to include
Nasty typo: s/not/now/
> > it.
>
> Anything I need to do?
>
Yeah, give me your Acked-by ;)
-- Steve
09.03.2011 15:50, Avi Kivity wrote:
> On 03/09/2011 02:06 PM, Michael Tokarev wrote:
>> Hello.
>>
>> Dominik Klein (Cc'd) reported on irc that current
>> FreeBSD release hangs at boot in qemu-kvm. It is
>> trivially verifiable by d/loading the bootonly
>> FreeBSD 8.2 CD image from ftp.freebsd.org
On Wed, Mar 09, 2011 at 01:28:43PM +0100, Jean-Philippe Menil wrote:
> Le 08/03/2011 12:13, Michael S. Tsirkin a écrit :
> >On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-Philippe Menil wrote:
> >>Yes, it's a 2.6.37.2 kernel.
> >OK, here's a debugging patch.
> >Please run with slab debugging as pre
On 03/09/2011 02:54 PM, Steven Rostedt wrote:
On Wed, 2011-03-09 at 10:50 +0200, Avi Kivity wrote:
> On 03/09/2011 01:55 AM, Steven Rostedt wrote:
> > Hi Avi,
> >
> > This patch set got lost in the shuffle, and I'm not looking to include
Nasty typo: s/not/now/
Makes sense now.
> > i
On 03/09/2011 02:59 PM, Michael Tokarev wrote:
> Please post the output of
>
>info register
And this is where the most fun begins. Right after `info registers'
it "unhangs" and continues as if nothing happened, ...
Probably one of the KVM_REQ_EVENT changes. Please try kvm.git and
rep
On 03/09/2011 02:24 AM, Lai Jiangshan wrote:
sendkey is a very good command for human using it in their monitor,
but it is not a good idea to port it to qmp, because qmp is a machine
protocol. So we introduce keydown and keyup command for qmp, they
simulate the events that keyboard send to the sy
Le 09/03/2011 14:00, Michael S. Tsirkin a écrit :
On Wed, Mar 09, 2011 at 01:28:43PM +0100, Jean-Philippe Menil wrote:
Le 08/03/2011 12:13, Michael S. Tsirkin a écrit :
On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-Philippe Menil wrote:
Yes, it's a 2.6.37.2 kernel.
OK, here's a debugging pat
On 03/09/2011 03:25 AM, Kevin Wolf wrote:
Am 08.03.2011 16:50, schrieb Chris Wright:
QAPI merge plans
- should be 100% back compat
- qmp moved over
- hmp moved over
- 1st pass, core infrastructure (includes test framework)
- 2nd pass, command conversion
- 3rd pass, more controversial bits
- adds
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
The IO-Thread provides appropriate locking primitives to avoid that.
This patch makes CONFIG_VNC_THREAD depends on CONFIG_IO_THREAD,
and add lock and unlock calls ar
On Wed, Mar 9, 2011 at 1:21 PM, Corentin Chary wrote:
> The threaded VNC servers messed up with QEMU fd handlers without
> any kind of locking, and that can cause some nasty race conditions.
>
> The IO-Thread provides appropriate locking primitives to avoid that.
> This patch makes CONFIG_VNC_THRE
On 03/09/2011 02:21 PM, Corentin Chary wrote:
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
The IO-Thread provides appropriate locking primitives to avoid that.
This patch makes CONFIG_VNC_THREAD depends on CO
On Wed, Mar 9, 2011 at 1:51 PM, Paolo Bonzini wrote:
> On 03/09/2011 02:21 PM, Corentin Chary wrote:
>>
>> The threaded VNC servers messed up with QEMU fd handlers without
>> any kind of locking, and that can cause some nasty race conditions.
>>
>> The IO-Thread provides appropriate locking primit
On Wed, Mar 09, 2011 at 02:12:58PM +0100, Jean-Philippe Menil wrote:
> Le 09/03/2011 14:00, Michael S. Tsirkin a écrit :
> >On Wed, Mar 09, 2011 at 01:28:43PM +0100, Jean-Philippe Menil wrote:
> >>Le 08/03/2011 12:13, Michael S. Tsirkin a écrit :
> >>>On Fri, Mar 04, 2011 at 10:39:05AM +0100, Jean-
On Wed, Mar 09, 2011 at 03:03:49PM +0200, Avi Kivity wrote:
> On 03/09/2011 02:59 PM, Michael Tokarev wrote:
> >> Please post the output of
> >>
> >>info register
> >
> >And this is where the most fun begins. Right after `info registers'
> >it "unhangs" and continues as if nothing happened, .
09.03.2011 17:24, Gleb Natapov пишет:
> On Wed, Mar 09, 2011 at 03:03:49PM +0200, Avi Kivity wrote:
>> On 03/09/2011 02:59 PM, Michael Tokarev wrote:
Please post the output of
info register
>>>
>>> And this is where the most fun begins. Right after `info registers'
>>> it "unhan
Stefan Hajnoczi wrote on 03/09/2011 05:12:07 AM:
>
> On Wed, Mar 9, 2011 at 10:01 AM, Avi Kivity wrote:
> > On 03/09/2011 11:42 AM, Harald Dunkel wrote:
> >>
> >> Hi folks,
> >>
> >> would it make sense to make elevator=noop the default
> >> for virtio block devices? Or would you recommend to
>
> Please try kvm.git and
> report, it's likely fixed.
With kvm.git kernel it works.
Here's what I did:
git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git
cd kvm
cp /boot/config-$(uname -r) .config
# set LOCALVERSION to -kvm.git.20110309
make modules bzImage
make modules
On 03/09/2011 04:53 PM, Dominik Klein wrote:
> Please try kvm.git and
> report, it's likely fixed.
With kvm.git kernel it works.
Here's what I did:
git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git
cd kvm
cp /boot/config-$(uname -r) .config
# set LOCALVERSION to -kvm.g
Hi David,
looks really impressive.
It works and the performance is really good!
But some things are not working and cause my Windows guest to stop booting
or getting slowed down:
-device usb-tablet
-device usb-mouse
do not really work. (I have connected a PS/2 mouse to have no interference
with t
On Tue, 2011-03-08 at 20:21 -0600, Andrew Theurer wrote:
> Tom L has started using Rusty's patches and found some interesting
> results, sent yesterday:
> http://marc.info/?l=kvm&m=129953710930124&w=2
Thanks. Very good experimental. I have been struggling with guest/vhost
optimization work for a w
On Wed, 2011-03-09 at 09:15 +0200, Michael S. Tsirkin wrote:
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 82dba5a..ebe3337 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -514,11 +514,11 @@ static unsigned int free_old_xmit_skbs(struct
> v
it.kernel.org/pub/scm/virt/kvm/kvm.git
>> cd kvm
>> cp /boot/config-$(uname -r) .config
>> # set LOCALVERSION to -kvm.git.20110309
>> make modules bzImage
>> make modules_install install
>> # build initrd
>> reboot
>> /usr/bin/qemu-kvm -vnc 127.0.0.1:0
On Wednesday, March 09, 2011 01:15:58 am Michael S. Tsirkin wrote:
> On Mon, Mar 07, 2011 at 04:31:41PM -0600, Tom Lendacky wrote:
> > We've been doing some more experimenting with the small packet network
> > performance problem in KVM. I have a different setup than what Steve D.
> > was using so
On Wed, Mar 09, 2011 at 07:45:43AM -0800, Shirley Ma wrote:
> On Wed, 2011-03-09 at 09:15 +0200, Michael S. Tsirkin wrote:
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 82dba5a..ebe3337 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> >
On 03/09/11 08:40, erik.r...@rdsoftware.de wrote:
> Hi David,
>
> looks really impressive.
> It works and the performance is really good!
>
> But some things are not working and cause my Windows guest to stop booting
> or getting slowed down:
> -device usb-tablet
> -device usb-mouse
> do not re
On Wednesday, March 09, 2011 01:17:44 am Michael S. Tsirkin wrote:
> On Mon, Mar 07, 2011 at 04:31:41PM -0600, Tom Lendacky wrote:
> > I used the uperf tool to do this after verifying the results against
> > netperf. Uperf allows the specification of the number of connections as
> > a parameter in
On Wed, 2011-03-09 at 10:09 -0600, Tom Lendacky wrote:
> >
> > > This spread out the kick_notify but still resulted in alot of
> them. I
> > > decided to build on the delayed Tx buffer freeing and code up an
> > > "ethtool" like coalescing patch in order to delay the kick_notify
> until
> > > the
>> Here's what I did:
>>
>> git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git
>> cd kvm
>> cp /boot/config-$(uname -r) .config
>> # set LOCALVERSION to -kvm.git.20110309
>> make modules bzImage
>> make modules_install install
>> # build i
On Wed, 2011-03-09 at 18:10 +0200, Michael S. Tsirkin wrote:
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 82dba5a..4477b9a 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -514,11 +514,11 @@ static unsigned int free_old_xmit_skbs(struct
On 03/09/2011 06:24 PM, Avi Kivity wrote:
http://www.corpit.ru/mjt/tmp/kvm-fbsd-boot-trace.txt.gz
(Yes, this kernel works for me too).
>> # visually verify that it does not hang as it did before
So the trace is for a working kernel? That's not very interesting
(well maybe later to compare
09.03.2011 19:26, Avi Kivity wrote:
> Sorry, I misread. So kvm.git works, we just have to identify what patch
> fixed it.
>
> What's the last kernel that *didn't* work for you?
2.6.38-rc8 does not work - verified by Dominik.
But kvm.git works.
I know it warrants a very nice bisection :)
/mjt
On Wed, Mar 09, 2011 at 10:09:26AM -0600, Tom Lendacky wrote:
> On Wednesday, March 09, 2011 01:15:58 am Michael S. Tsirkin wrote:
> > On Mon, Mar 07, 2011 at 04:31:41PM -0600, Tom Lendacky wrote:
> > > We've been doing some more experimenting with the small packet network
> > > performance problem
On 03/09/2011 06:28 PM, Michael Tokarev wrote:
09.03.2011 19:26, Avi Kivity wrote:
> Sorry, I misread. So kvm.git works, we just have to identify what patch
> fixed it.
>
> What's the last kernel that *didn't* work for you?
2.6.38-rc8 does not work - verified by Dominik.
But kvm.git works.
On Wed, Mar 09, 2011 at 08:25:34AM -0800, Shirley Ma wrote:
> On Wed, 2011-03-09 at 18:10 +0200, Michael S. Tsirkin wrote:
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 82dba5a..4477b9a 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.
On 03/09/2011 06:32 PM, Avi Kivity wrote:
On 03/09/2011 06:28 PM, Michael Tokarev wrote:
09.03.2011 19:26, Avi Kivity wrote:
> Sorry, I misread. So kvm.git works, we just have to identify what
patch
> fixed it.
>
> What's the last kernel that *didn't* work for you?
2.6.38-rc8 does not wor
On Wed, 2011-03-09 at 18:32 +0200, Michael S. Tsirkin wrote:
> I think your issues are with TX overrun.
> Besides delaying IRQ on TX, I don't have many ideas.
>
> The one interesting thing is that you see better speed
> if you drop packets. netdev crowd says this should not happen,
> so could be a
On Wed, 2011-03-09 at 10:09 -0600, Tom Lendacky wrote:
> > > Vhost is receiving a lot of notifications for packets that are to
> be
> > > transmitted (over 60% of the packets generate a kick_notify).
This is guest TX send notification when vhost enables notification.
In TCP_STREAM test, vhost ex
09.03.2011 19:34, Avi Kivity wrote:
[]
>>> > Sorry, I misread. So kvm.git works, we just have to identify what patch
>>> > fixed it.
>>> 2.6.38-rc8 does not work - verified by Dominik.
>>> But kvm.git works.
>> There's some chance it's e5d135f80b98b0.
> If you apply it, also apply the followin
On Wed, Mar 09, 2011 at 08:51:33AM -0800, Shirley Ma wrote:
> On Wed, 2011-03-09 at 10:09 -0600, Tom Lendacky wrote:
> > > > Vhost is receiving a lot of notifications for packets that are to
> > be
> > > > transmitted (over 60% of the packets generate a kick_notify).
>
> This is guest TX send not
On Wed, 2011-03-09 at 19:16 +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 09, 2011 at 08:51:33AM -0800, Shirley Ma wrote:
> > On Wed, 2011-03-09 at 10:09 -0600, Tom Lendacky wrote:
> > > > > Vhost is receiving a lot of notifications for packets that are
> to
> > > be
> > > > > transmitted (over 60
> Can you try moving the kvm_make_request() inside the if conditional and
> see if it that also fixes it?
yes, changing to:
if (unlikely(vcpu->cpu != cpu) || check_tsc_unstable()) {
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
/* Make sure TSC doesn't go backwards */
s64
Here are the results again with the addition of the interrupt rate that
occurred on the guest virtio_net device:
Here is the KVM baseline (average of six runs):
Txn Rate: 87,070.34 Txn/Sec, Pkt Rate: 172,992 Pkts/Sec
Exits: 148,444.58 Exits/Sec
TxCPU: 2.40% RxCPU: 99.35%
Virtio1-input I
David Ahern wrote:
On 03/09/11 08:40, erik.r...@rdsoftware.de wrote:
But some things are not working and cause my Windows guest to stop booting
or getting slowed down:
-device usb-tablet
-device usb-mouse
do not really work. (I have connected a PS/2 mouse to have no interference
with the rest of
On 03/09/2011 02:30 PM, Nikola Ciprich wrote:
Can you try moving the kvm_make_request() inside the if conditional and
see if it that also fixes it?
yes, changing to:
if (unlikely(vcpu->cpu != cpu) || check_tsc_unstable()) {
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
/* M
Hi all,
is it possible to parameterize qemu in a way where the VNC port and the VGA
output is available in parallel?
My system screen remains dark if I run it with the -vnc :0 option and vnc
is unavailable when SDL/VGA is available.
Best regards,
Erik
--
To unsubscribe from this list: send
Since we have lots of performance discussions about virtio_net and vhost
communication. I think it's better to have a common understandings of
the code first, then we can seek the right directions to improve it. We
also need to collect more statistics data on both virtio and vhost.
Let's look at T
1 - 100 of 115 matches
Mail list logo
