On Saturday 05 January 2008 09:24:40 Anthony Liguori wrote:
> Hey Rusty et al,
>
> I've got automatic backports of the virtio modules[1] working back to
> 2.6.18. Everything seems okay except that for any kernel with the older
> NAPI api, performance is extremely bad. I get about 1gbit on TX with
Zhang, Xiantao wrote:
> Avi Kivity wrote:
>
>> Avi Kivity wrote:
>>
>>> Zhang, Xiantao wrote:
>>>
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Sat, 5 Jan 2008 20:20:14 +0800
Subject: [PATCH] kvm: qemu: Moving tpr-patch routine to
qemu-kvm-x86.c
Since t
Dong, Eddie wrote:
>> Wrong patch attached...
>>
>
> Sorry for the wrong attachment :(
>
Applied, thanks. I fixed the error case -- you can't 'continue', you
still need to zap the pte and flush the tlb.
--
error compiling committee.c: too many arguments to function
-
Antoine Martin wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> Trying to boot KVM on a Core2Duo system, kvm-59 + linux-2.6.23.12
> Booting with:
> qemu-system-x86_64 -hda /home/uml/BusyBox-1.5.0-amd64-root_fs -m 384
> - -nographic -cpu qemu64 -kernel /boot/vmlinuz-2.6.23.12 -
Yang, Sheng wrote:
>> I have a vague plan for improving decode; basically extend the decode
>> tables to add group decoding. We add a bit to opcode_table and
>> twobyte_table that is set for all instructions which need group
>> decoding. When the bit is set, the rest of the value in opcode_table
Carlo Marcelo Arenas Belon wrote:
> On Sun, Jan 06, 2008 at 04:39:08PM +0200, Avi Kivity wrote:
>
>> From: Marcelo Tosatti <[EMAIL PROTECTED]>
>>
>> Emulate cmpxchg8b atomically on i386. This is required to avoid a guest
>> pte walker from seeing a splitted write.
>>
>> [avi: make it compile]
>>
Hi, all,
This is today's KVM test result against kvm.git
5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git
e44dce6b8c8c8cf155223ba0e036bb4ace5071b1.
One issue has been fixed:
1. Crashme causes RHEL5 guest kernel panic
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1840
Carlo Marcelo Arenas Belon wrote:
> revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that
> redefined sector as an array of pointers to char, instead of a statically
> allocated buffer of chars, that was triggering the following warnings :
>
> block.c: In function `bdrv_commit':
Carlo Marcelo Arenas Belon wrote:
> The following patch series implement a configure passthrough for qemu so that
> all available configure options in qemu can be used through kvm.
>
> This includes all suggestions from the 3 first RFC and complements the patches
> that were needed from qemu's side
Zhao, Yunfeng wrote:
> Hi, all,
>
> This is today's KVM test result against kvm.git
> 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git
> e44dce6b8c8c8cf155223ba0e036bb4ace5071b1.
>
> 4. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host
> https://sourceforge.net/tracker/?fun
Farkas Levente wrote:
> Zhao, Yunfeng wrote:
>
>> Hi, all,
>>
>> This is today's KVM test result against kvm.git
>> 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git
>> e44dce6b8c8c8cf155223ba0e036bb4ace5071b1.
>>
>> 4. Cannot boot 32bit smp RHEL5.1 guest with nic on 64bit host
>>
On Mon, 2008-01-07 at 10:48 +0100, Farkas Levente wrote:
> Zhao, Yunfeng wrote:
> > Hi, all,
> >
> > This is today's KVM test result against kvm.git
> > 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git
> > e44dce6b8c8c8cf155223ba0e036bb4ace5071b1.
> >
> > 4. Cannot boot 32bit smp R
Anthony Liguori wrote:
> Dong, Eddie wrote:
>> Anthony:
>> Actually I am wondering if the binary used for VMMCALL could be
>> assumed will never be used by Intel processor or vice versa. BTW,
>> what is the nenefit to remove hypercall page, which provide more
>> clean approach IMO?
>>
>
>
Dong, Eddie wrote:
> Anthony Liguori wrote:
>
>> Dong, Eddie wrote:
>>
>>> Anthony:
>>> Actually I am wondering if the binary used for VMMCALL could be
>>> assumed will never be used by Intel processor or vice versa. BTW,
>>> what is the nenefit to remove hypercall page, which provide
On Monday 07 January 2008 17:51:36 Avi Kivity wrote:
> Farkas Levente wrote:
> > Zhao, Yunfeng wrote:
> >> Hi, all,
> >>
> >> This is today's KVM test result against kvm.git
> >> 5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git
> >> e44dce6b8c8c8cf155223ba0e036bb4ace5071b1.
> >>
> >>
Yang, Sheng wrote:
> On Monday 07 January 2008 17:51:36 Avi Kivity wrote:
>
>> Farkas Levente wrote:
>>
>>> Zhao, Yunfeng wrote:
>>>
Hi, all,
This is today's KVM test result against kvm.git
5ed49953ef3749de1198bc07cdf11339d8f74432 and kvm-userspace.git
e44dce
On Monday 07 January 2008 17:22:43 Avi Kivity wrote:
> Yang, Sheng wrote:
> >> I have a vague plan for improving decode; basically extend the decode
> >> tables to add group decoding. We add a bit to opcode_table and
> >> twobyte_table that is set for all instructions which need group
> >> decodin
Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit :
> Carlo Marcelo Arenas Belon wrote:
> > revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that
> > redefined sector as an array of pointers to char, instead of a statically
> > allocated buffer of chars, that was trigge
Yang, Sheng wrote:
> On Monday 07 January 2008 17:22:43 Avi Kivity wrote:
>
>> Yang, Sheng wrote:
>>
I have a vague plan for improving decode; basically extend the decode
tables to add group decoding. We add a bit to opcode_table and
twobyte_table that is set for all instruc
Laurent Vivier wrote:
> Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit :
>
>> Carlo Marcelo Arenas Belon wrote:
>>
>>> revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that
>>> redefined sector as an array of pointers to char, instead of a statically
>>> allo
On Monday 07 January 2008 18:43:52 Avi Kivity wrote:
> Yang, Sheng wrote:
> > On Monday 07 January 2008 17:22:43 Avi Kivity wrote:
> >> Yang, Sheng wrote:
> I have a vague plan for improving decode; basically extend the decode
> tables to add group decoding. We add a bit to opcode_table
On Sun, Jan 06, 2008 at 11:08:31AM +0200, Avi Kivity wrote:
> Since it is the OS that assigns SCI to irq10, we can't be sure it will
> always be there. So I think all PCI IRQs need such an override.
The patch below adds the override to IRQs 5,9,10 & 11. The code is
basically from Xen. Xen fixes t
(needs either --no-kvm-irqchip or the previous patch)
-- Guido
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 314df94..7a96ece 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1318,8 +1318,8 @@ void acpi_bios_init(void)
fadt->pm_tmr_len = 4;
fadt->plvl2_lat = cpu_to_le16
Le lundi 07 janvier 2008 à 12:47 +0200, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit :
> >
> >> Carlo Marcelo Arenas Belon wrote:
> >>
> >>> revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that
> >>> redefin
Guido Guenther wrote:
> (needs either --no-kvm-irqchip or the previous patch)
> -- Guido
>
>
Applied both, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Mic
The error is:
libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report':
/home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221:
undefined reference to `kvm_enable_vapic'
libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup':
/home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-o
The error is:
libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report':
/home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221:
undefined reference to `kvm_enable_vapic'
libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_opt_setup':
/home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-o
On Mon, 2008-01-07 at 14:14 +0100, Laurent Vivier wrote:
> The error is:
>
> libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report':
> /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221:
> undefined reference to `kvm_enable_vapic'
> libqemu.a(kvm-tpr-opt.o): In function `kvm_t
Le lundi 07 janvier 2008 à 15:26 +0200, Dor Laor a écrit :
> On Mon, 2008-01-07 at 14:14 +0100, Laurent Vivier wrote:
> > The error is:
> >
> > libqemu.a(kvm-tpr-opt.o): In function `kvm_tpr_access_report':
> > /home/vivierl/Projects/KVM/kvm-userspace/qemu/kvm-tpr-opt.c:221:
> > undefined referenc
Laurent Vivier wrote:
> but a pull doesn't resolve anything (the clone has the same effect).
>
> Is the correction has been pushed... ?
>
>
Should be...
Perhaps a ./configure is needed.
What's your HEAD? I have a5b3d2c9b4d4ca3e02f294d14c7df016e070bda7,
which compiles fine.
--
error compi
Le lundi 07 janvier 2008 à 15:57 +0200, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > but a pull doesn't resolve anything (the clone has the same effect).
> >
> > Is the correction has been pushed... ?
> >
> >
>
> Should be...
>
> Perhaps a ./configure is needed.
>
> What's your HEAD? I h
Avi Kivity wrote:
> Dong, Eddie wrote:
>> Anthony Liguori wrote:
>>
>>> Dong, Eddie wrote:
>>>
Anthony:
Actually I am wondering if the binary used for VMMCALL could be
assumed will never be used by Intel processor or vice versa. BTW,
what is the nenefit to remove hypercall
Le lundi 07 janvier 2008 à 12:47 +0200, Avi Kivity a écrit :
> Laurent Vivier wrote:
> > Le lundi 07 janvier 2008 à 11:27 +0200, Avi Kivity a écrit :
> >
> >> Carlo Marcelo Arenas Belon wrote:
> >>
> >>> revert a merge conflict from 075da586c92f09bd9a7401f1e80d72fde27c173 that
> >>> redefin
Le lundi 07 janvier 2008 à 10:34 -0500, Javier Guerra a écrit :
> On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> > What I'm wondering now is: is it really useful to have "cache=off" and
> > "snapshot=on" at the same time ?
>
> does "cache=off" means disk cache? if so, it might be useful to
On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> What I'm wondering now is: is it really useful to have "cache=off" and
> "snapshot=on" at the same time ?
does "cache=off" means disk cache? if so, it might be useful to test
clustering filesystems.
so far, the only way is to setup a network
On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> "cache=off" means files is opened with "O_DIRECT" and thus there is no
> cache in the kernel memory on the host side.
> IMO, "cache=off" and "snapshot=on" are incompatible because a snapshot
> can be seen like a cache.
>
> > so far, the only wa
Bugs item #1865988, was opened at 2008-01-07 18:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1865988&group_id=180599
Please note that this message will contain a full copy
Rusty Russell wrote:
> On Saturday 05 January 2008 09:24:40 Anthony Liguori wrote:
>
>> Hey Rusty et al,
>>
>> I've got automatic backports of the virtio modules[1] working back to
>> 2.6.18. Everything seems okay except that for any kernel with the older
>> NAPI api, performance is extremely b
Le lundi 07 janvier 2008 à 11:03 -0500, Javier Guerra a écrit :
> On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> > "cache=off" means files is opened with "O_DIRECT" and thus there is no
> > cache in the kernel memory on the host side.
> > IMO, "cache=off" and "snapshot=on" are incompatible
On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote:
> Le lundi 07 janvier 2008 à 11:03 -0500, Javier Guerra a écrit :
> > hopefully, it would now work with "-cache=off", don't you think?
>
> Well, I don't think the problem is at the host level but at the guest
> level, because both instances of qe
Well, in fact, I think you can't use snapshot with cluster filesystem:
as each qemu instance will write in its own snapshot and will not see
modifications made by other, and I don't think there is currently a way
to share snapshot between qemu instances.
Laurent
Le lundi 07 janvier 2008 à 11:42 -
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> Dong, Eddie wrote:
>>
>>> Anthony Liguori wrote:
>>>
>>>
Dong, Eddie wrote:
> Anthony:
> Actually I am wondering if the binary used for VMMCALL could be
> assumed will never be used by Intel processor o
USB redirection support in qemu is currently using synchronous ioctls,
which might block the guest for too long (>100usec). The current host
controller emulations allow only one pending transfer at a time, which
might slow down the guest as well.
If you are using simple bulk device (disk on key,
Laurent Vivier wrote:
> What I'm wondering now is: is it really useful to have "cache=off" and
> "snapshot=on" at the same time ?
>
No idea, but wouldn't want to rule it out.
> If not, the patch of Carlo is good, otherwise there is more
> modifications to do (in other parts of qemu).
>
If
Javier Guerra wrote:
> On 1/7/08, Laurent Vivier <[EMAIL PROTECTED]> wrote:
>
>> What I'm wondering now is: is it really useful to have "cache=off" and
>> "snapshot=on" at the same time ?
>>
>
> does "cache=off" means disk cache? if so, it might be useful to test
> clustering filesystems.
>
Javier Guerra wrote:
> to test a cluster filesystem, i need two (virtual) machines with some
> shared storage. i tried long ago something like this (with (k)qemu):
>
> - create a disk image, call it hda-1.img
> - boot and install linux on it, shutdown
> - copy to hda-2.img
> - boot it (with new MA
Avi noticed that when using the virtio_net driver, ping responses stop
coming in after 12 packets. ping will then throw an "sendmsg: no buffer
space available" error.
This occurs on all kernel versions (even 2.6.24).
Regards,
Anthony Liguori
--
Anthony Liguori wrote:
> Avi noticed that when using the virtio_net driver, ping responses stop
> coming in after 12 packets. ping will then throw an "sendmsg: no
> buffer space available" error.
>
> This occurs on all kernel versions (even 2.6.24).
>
Latencies are high at around 4ms when the p
Avi Kivity wrote:
> Antoine Martin wrote:
>>
>> Hi,
>>
>> Trying to boot KVM on a Core2Duo system, kvm-59 + linux-2.6.23.12
>> Booting with:
>> qemu-system-x86_64 -hda /home/uml/BusyBox-1.5.0-amd64-root_fs -m 384
>> - -nographic -cpu qemu64 -kernel /boot/vmlinuz-2.6.23.12 -append
>> "earlyprintk=se
Avi and I were talking this afternoon and he suggested that we should
remove the tx_timer from the virtio_net front-end and replace it with a
tx_timer in the backend.
Since the backend can suppress notifications, this is appealing since it
gives much more flexibility to the backend in determin
I always build my kernels with the O= option, since it allows me to
build multiple architectures from the same sources.
However, it looks like the kvm-userspace configure script can't handle
this. It says --kerneldir should be the kernel *build* directory, but
when I do that I get
libkvm.c
Create an "asm" symlink from libkvm into the kernel source directory.
This allows one to use kernel trees built with the O= option.
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
---
This is all I can come up with... it should work by accident for user/
and qemu/ directories too, since they
This patch adds support for VRING_USED_F_NOTIFY_ON_FULL. When this bit is
set, virtio ring notifications will be suppressed unless the virtio ring is
full.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 1302ac4..e
Doing tx mitigation in the host gets equivalent performance and offers greater
flexibility. It also simplifies the guest code.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4082099..797a3ed 100644
--- a/drivers/net/virti
Whoops should have replied to this one.
So this does not solve the issue. As it point it includes
/includes .. just you have to compile the kernel directory so
that "include/asm" symlink in the kernel directory is made.
This creates a symlink to the symlink and that symlnk which is already
in in
On Tuesday 08 January 2008 07:36:45 Anthony Liguori wrote:
> Avi and I were talking this afternoon and he suggested that we should
> remove the tx_timer from the virtio_net front-end and replace it with a
> tx_timer in the backend.
>
> Since the backend can suppress notifications, this is appealing
This patch adds support for TX mitigation in QEMU using the new NOTIFY_ON_FULL
virtio ring flag.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 3940743..5fd4114 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -14,6
With kvm-44, I thought my kernel was freezing during boot if I gave it
1G of RAM. But, it boots fine with 512M.
So, I instrumented the kernel, and found out that it is just taking a
long time to memset a 58MB area of memory for mem_map[]. It appears to
be taking a mmio_exit for every access of e
I'm having a hard time parsing this.
Basically this patch is duplicating what Kbuild does: it is creating the
appropriate asm symlink. The original problem was that kvm-userspace
didn't have an asm symlink, so the patch does fix it.
--
Hollis Blanchard
IBM Linux Technology Center
On Mon, 2008-0
On Mon, Jan 07, 2008 at 07:30:44PM +, Antoine Martin wrote:
> Avi Kivity wrote:
> > Antoine Martin wrote:
> >>
> >> Hi,
> >>
> >> Trying to boot KVM on a Core2Duo system, kvm-59 + linux-2.6.23.12
> >> Booting with:
> >> qemu-system-x86_64 -hda /home/uml/BusyBox-1.5.0-amd64-root_fs -m 384
> >> -
Dave Hansen wrote:
> With kvm-44, I thought my kernel was freezing during boot if I gave it
> 1G of RAM. But, it boots fine with 512M.
>
> So, I instrumented the kernel, and found out that it is just taking a
> long time to memset a 58MB area of memory for mem_map[]. It appears to
> be taking a m
On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote:
> Dave Hansen wrote:
> > With kvm-44, I thought my kernel was freezing during boot if I gave it
> > 1G of RAM. But, it boots fine with 512M.
> >
> > So, I instrumented the kernel, and found out that it is just taking a
> > long time to memset a
Sorry for the cryptic language ;-o
No your right. I wasn't thinking about that.
On Mon, 2008-01-07 at 16:07 -0600, Hollis Blanchard wrote:
> I'm having a hard time parsing this.
>
> Basically this patch is duplicating what Kbuild does: it is creating the
> appropriate asm symlink. The original
Dave Hansen wrote:
> On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote:
>
>> Dave Hansen wrote:
>>
>>> With kvm-44, I thought my kernel was freezing during boot if I gave it
>>> 1G of RAM. But, it boots fine with 512M.
>>>
>>> So, I instrumented the kernel, and found out that it is just
On Tue, 2008-01-08 at 00:46 +0200, Izik Eidus wrote:
> Dave Hansen wrote:
> > On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote:
> >
> >> Dave Hansen wrote:
> >>
> >>> With kvm-44, I thought my kernel was freezing during boot if I gave it
> >>> 1G of RAM. But, it boots fine with 512M.
>
oh your problem is you must first build your kernel that you are
pointing too. Or you can cheat and point "include/asm" where you need to
point it. That solves the issue. It's all that userspace including
kernel headers :-)
On Mon, 2008-01-07 at 15:12 -0600, Hollis Blanchard wrote:
> I always buil
Carlo Marcelo Arenas Belon wrote:
> On Mon, Jan 07, 2008 at 07:30:44PM +, Antoine Martin wrote:
>> Avi Kivity wrote:
>>> Antoine Martin wrote:
Hi,
Trying to boot KVM on a Core2Duo system, kvm-59 + linux-2.6.23.12
Booting with:
qemu-system-x86_64 -hda /home/uml/BusyBox-1
On 1/7/08, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Guido Guenther wrote:
> > (needs either --no-kvm-irqchip or the previous patch)
> > -- Guido
> >
> >
>
> Applied both, thanks.
>
Sorry for my ignorance, but what is the effect of this patch? So
I can shutdown guest VM cleanly, or smt else??
On Tuesday 08 January 2008 03:35:48 Dave Hansen wrote:
> With kvm-44, I thought my kernel was freezing during boot if I gave it
> 1G of RAM. But, it boots fine with 512M.
>
> So, I instrumented the kernel, and found out that it is just taking a
> long time to memset a 58MB area of memory for mem_m
Subject: [PATCH] portability: move kvm_fpu to asm-x86/kvm.h
From: Christian Ehrhardt <[EMAIL PROTECTED]>
This patch moves kvm_fpu asm-x86/kvm.h to allow every architecture to
define an own representation used for KVM_GET_FPU/KVM_SET_FPU.
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
Acked
Acked-by: Zhang Xiantao <[EMAIL PROTECTED]>
Christian Ehrhardt wrote:
> Subject: [PATCH] portability: move kvm_fpu to asm-x86/kvm.h
> From: Christian Ehrhardt <[EMAIL PROTECTED]>
>
> This patch moves kvm_fpu asm-x86/kvm.h to allow every architecture to
> define an own representation used for KVM_
Hi Arnon,
thanks a lot for the response,
On Mo, 07 Jan 2008, Arnon Gilboa wrote:
> USB redirection support in qemu is currently using synchronous ioctls,
> which might block the guest for too long (>100usec). The current host
> controller emulations allow only one pending transfer at a time, whi
72 matches
Mail list logo
