2008/3/5, Avi Kivity <[EMAIL PROTECTED]>:
> Andi Kleen wrote:
> > Avi Kivity <[EMAIL PROTECTED]> writes:
> >
> >> Most likely movs emulation is broken for long counts. Please post a
> >> disassembly of copy_user_generic_string to make sure we're looking at
> >> the same code.
> >>
> >
> >
Hi All,
This is today's KVM test result against kvm.git
168676c978243d14263f900ba35e3534659a68df and kvm-userspace.git
efada398f0aaeeaa521379c67be43d597367fce0.
Three issues have fixed:
1. blue screen when booting 64bits windows guests
https://sourceforge.net/tracker/index.php?func=detail&aid=
* Yang, Sheng <[EMAIL PROTECTED]> wrote:
> +#if 1
> +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
> +#else
> +#define pit_debug(fmt, arg...)
> +#endif
this should use pr_debug() instead i guess.
> +#ifndef CONFIG_X86_64
> +#define mod_64(x, y) ((x) - (y) * div64_64(x, y))
> +#
Davide Libenzi wrote:
>> I think that may be a bit cleaner than Al's approach, but it still
>> leaves the same trap that create_vcpu_fd() falls into. The current
>> code is:
>>
>> static int create_vcpu_fd(struct kvm_vcpu *vcpu)
>> {
>> int fd, r;
>> struct inode *inode;
>> struct f
On Wed, Mar 05, 2008 at 07:09:55AM +0200, Avi Kivity wrote:
> Isn't that out of the question for .25?
I keep hearing this mantra. What is so compelling about the .25
release? When seems to be more important than what. While I understand
product release cycles, etc. and can certainly agree with
Robin Holt wrote:
> On Wed, Mar 05, 2008 at 07:09:55AM +0200, Avi Kivity wrote:
>
>> Isn't that out of the question for .25?
>>
>
> I keep hearing this mantra. What is so compelling about the .25
> release? When seems to be more important than what. While I understand
> product release c
On Tue, 2008-03-04 at 18:50 -0600, Anthony Liguori wrote:
> Dor Laor wrote:
> > On Tue, 2008-03-04 at 09:52 -0600, Anthony Liguori wrote:
> >
> >> Yang, Sheng wrote:
> >>
> >>> Hi
> >>>
> >>> Here is the last in-kernel PIT patch for KVM. The mainly change from last
> >>> version is the su
On Tuesday 04 March 2008 17:00:25 Avi Kivity wrote:
> Yunfeng Zhao wrote:
> > Hi, all,
> >
> > This is today's KVM test result against kvm.git
> > daf4de30ec718b16798aba07e9f25fd9e6ba9e53 and kvm-userspace.git
> > 724f8a940ec0e78e607c051e6e82ca2f5055b1e1.
> > In today's testing , save/restore cras
On Wed, 2008-03-05 at 03:47 -0600, Robin Holt wrote:
> On Wed, Mar 05, 2008 at 07:09:55AM +0200, Avi Kivity wrote:
> > Isn't that out of the question for .25?
>
> I keep hearing this mantra. What is so compelling about the .25
> release? When seems to be more important than what. While I under
Thanks for comments!
On Wednesday 05 March 2008 17:15:29 Ingo Molnar wrote:
> * Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > +#if 1
> > +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
> > +#else
> > +#define pit_debug(fmt, arg...)
> > +#endif
>
> this should use pr_debug() instead i
Yang, Sheng wrote:
> Thanks for comments!
>
> On Wednesday 05 March 2008 17:15:29 Ingo Molnar wrote:
>
>> * Yang, Sheng <[EMAIL PROTECTED]> wrote:
>>
>>> +#if 1
>>> +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
>>> +#else
>>> +#define pit_debug(fmt, arg...)
>>> +#endif
>>>
* Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > * Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > > +#if 1
> > > +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
> > > +#else
> > > +#define pit_debug(fmt, arg...)
> > > +#endif
> >
> > this should use pr_debug() instead i guess.
>
> Um...
Anthony Liguori wrote:
> Glauber Costa wrote:
>> Anthony Liguori wrote:
>>
>> No, it can't. Because at the time qemu starts, no vcpu -> thread id
>> relationship exists at all. And we don't know when it will.
>
> Sure we do. The vcpu -> thread id relationship is valid after
> kvm_init_ap() is c
Avi Kivity wrote:
> Glauber Costa wrote:
>> Hi guys,
>>
>> Here's a first series of patch aiming at vcpu pinning support in qemu.
>> Ideally, as vcpu as just normal threads, the usual userspace tools can
>> be used
>> to set cpu affinities mask.
>>
>> However, It makes it very difficult to _start_
Avi Kivity wrote:
> Affinity control is probably useful mostly for numa configurations,
> where you want to restrict virtual cpus to run on the cores closest to
> memory. However it may well be that the scheduler is already good
> enough to do this on its own.
In that case, you need to use num
Dor Laor wrote:
> On Tue, 2008-03-04 at 18:50 -0600, Anthony Liguori wrote:
>
>> Dor Laor wrote:
>>
>> I thought there was some discussion about whether -tdf was every useful
>> in practice?
>>
>
> It works.
> Just try to play a movie in windows standard HAL with and w/o -tdf
> --no-i
Try adding the noapic option to your guest kernel. I re-ran that test on kvm-62
and my VM was able to run under load for more than 3-1/2 days (the network never
locked up; I stopped the test to try other variations).
One side effect of the noapic option is that irq balancing is disabled -- all
int
Hi,
> If you are using virtio drivers in the guest (which I presume you are
> given the reference to /dev/vda), try using the following -drive syntax:
>
> -drive file=/dev/mapper/ioband1,if=virtio,boot=on,cache=off
>
> This will force the use of O_DIRECT. By default, QEMU does not open
> with
Handle the case where the balloon target is larger than total ram size.
BUG: unable to handle kernel paging request at 00100100
IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: virtio/virtio_balloon.c
==
Ryo Tsuruta wrote:
Hi,
If you are using virtio drivers in the guest (which I presume you are
given the reference to /dev/vda), try using the following -drive syntax:
-drive file=/dev/mapper/ioband1,if=virtio,boot=on,cache=off
This will force the use of O_DIRECT. By default, QEMU does not
Marcelo Tosatti wrote:
> Handle the case where the balloon target is larger than total ram size.
>
> BUG: unable to handle kernel paging request at 00100100
> IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
>
> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
>
> Index: virtio/virtio_ballo
david ahern wrote:
> Try adding the noapic option to your guest kernel. I re-ran that test on
> kvm-62
> and my VM was able to run under load for more than 3-1/2 days (the network
> never
> locked up; I stopped the test to try other variations).
>
> One side effect of the noapic option is that ir
Anthony Liguori wrote:
> Playing a movie is a bit subjective. I presume you're talking about the
> standard HAL as presumably the ACPI HAL is using the pm timer?
>
ACPI HAL uses the apic timer, IIRC; perhaps the pm timer as well.
> So the two cases I'm hearing where timer accuracy should imp
Very Nice. Must be KVM-63.
> - merge qemu-cvs
>- new curses display option
How to activate that one?
--
-Alexey Eremenko "Technologov"
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) V
Marcelo Tosatti wrote:
> On Wed, Mar 05, 2008 at 06:59:10PM +0200, Avi Kivity wrote:
>
>> Marcelo Tosatti wrote:
>>
>>> Handle the case where the balloon target is larger than total ram size.
>>>
>>> BUG: unable to handle kernel paging request at 00100100
>>> IP: [] :virtio_balloon:
Avi Kivity wrote:
> Add cpus on the fly to your virtual machines with the new cpu hotplug
> feature.
>
er, kvm-63, that is.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.
On Wed, Mar 05, 2008 at 06:59:10PM +0200, Avi Kivity wrote:
> Marcelo Tosatti wrote:
> >Handle the case where the balloon target is larger than total ram size.
> >
> >BUG: unable to handle kernel paging request at 00100100
> >IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
> >
> >Signed-off-
Add cpus on the fly to your virtual machines with the new cpu hotplug
feature.
Changes from kvm-62:
- portability: make room for the ia64 register stack (Xiantao Zhang)
- fix leak when setting the pv clock to an invalid address (Marcelo Tosatti)
- detect vcpu triple faults (Joerg Roedel)
- fix ra
I did not have any better luck with the e1000 or pcnet nics when running kvm-61.
I'll try again with kvm-63 and get back to you.
david
Avi Kivity wrote:
> david ahern wrote:
>> Try adding the noapic option to your guest kernel. I re-ran that test
>> on kvm-62
>> and my VM was able to run under l
Avi Kivity wrote:
> Marcelo Tosatti wrote:
>
>> Handle the case where the balloon target is larger than total ram size.
>>
>> BUG: unable to handle kernel paging request at 00100100
>> IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
>>
>> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Hi,
With this series, I'm introducing the ability to turn off the kvmclock.
It is done by writting any thing to the first three bits of the address
passed as a parameter to the msr.
For that to work properly, we should make absolutely sure the guest is aligned.
If we really care about compatibili
If the calling cpu rewrites the system clock msr for any reason,
release the page we allocated in the last time
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.
Align the kvm_vcpu_time array to the size of a cacheline.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/kvmclock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index b8da3bf..d82406a 100644
Use the lower 3 lower bits of the system time msr to turn off the clock.
This means that all clock registration has to be aligned in a 4-byte boundary
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
clean this leftover in kvmclock.c
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/kvmclock.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index d82406a..8ff12b6 100644
--- a/arch/x86/kernel/
Marcelo Tosatti wrote:
> On Wed, Mar 05, 2008 at 06:59:10PM +0200, Avi Kivity wrote:
>
>> Marcelo Tosatti wrote:
>>
>>> Handle the case where the balloon target is larger than total ram size.
>>>
>>> BUG: unable to handle kernel paging request at 00100100
>>> IP: [] :virtio_balloon:
On Wed, 5 Mar 2008, Nick Piggin wrote:
> Um, it's bound to the *Linux page tables*, yes. And I have no idea why
> you would use the paravirt ops for this.
paravirt ops allows interception of page table operations?
-
This SF
Alexey Eremenko wrote:
> Very Nice. Must be KVM-63.
>
>
>> - merge qemu-cvs
>>- new curses display option
>>
>
> How to activate that one?
>
>
qemu -curses
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
> >I guess the description was not clear, you understood the opposite.
> >
> >The problem is when the target for total guest pages (not balloon target
> >size) is set to be larger than the amount of total pages the guest has
> >booted with. What happens then is that the driver tries to release pag
Marcelo Tosatti wrote:
>>> I guess the description was not clear, you understood the opposite.
>>>
>>> The problem is when the target for total guest pages (not balloon target
>>> size) is set to be larger than the amount of total pages the guest has
>>> booted with. What happens then is that the d
Hey,
This patch series expose the actual thread id of each cpu via the qemu
monitor. It is done through "info cpus", which I though would be the
most natural command to do it. (If you disagree, please voice it)
Goal is to allow tools like libvirt to easily grab it and feed taskset
for thinks like
This patch introduces a "thread_id" variable to CPUState.
It's duty will be to hold the process, or more generally, thread
id of the current executing cpu
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/cpu-defs.h |1 +
qemu/exec.c |5 +
2 files changed, 6 insertions(+),
This patch exposes the thread id associated with each
cpu through the already well known info cpus interface.
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/monitor.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/qemu/monitor.c b/qemu/monitor.c
index 0874671.
At kvm ap creation, update CPUState with the actual thread id.
For us, they are actually different
Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
---
qemu/qemu-kvm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 051946e..
Oops!
Forgot the -n option in git.
Anyway, the series is small and straightforward, so I'm not reposting
it. If there is any doubt about the ordering, please tell me.
On Wed, Mar 5, 2008 at 5:01 PM, Glauber Costa <[EMAIL PROTECTED]> wrote:
> Hey,
>
> This patch series expose the actual thread i
On Thursday 06 March 2008 03:28:32 Marcelo Tosatti wrote:
> Handle the case where the balloon target is larger than total ram size.
>
> BUG: unable to handle kernel paging request at 00100100
> IP: [] :virtio_balloon:leak__balloon+0x2e/0xbe
>
> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECT
On Wed, 2008-03-05 at 19:30 +0200, Avi Kivity wrote:
> Anthony Liguori wrote:
> > Playing a movie is a bit subjective. I presume you're talking about the
> > standard HAL as presumably the ACPI HAL is using the pm timer?
> >
>
> ACPI HAL uses the apic timer, IIRC; perhaps the pm timer as wel
Dor Laor wrote:
> On Wed, 2008-03-05 at 19:30 +0200, Avi Kivity wrote:
>
>>
>> Playing a movie is better than any benchmark; it reflects actual user
>> experience in a real and important use case. Benchmarks are substitutes
>> for real use cases, not the goal of the optimization.
>>
>>
>
On Wed, 2008-03-05 at 22:06 +1100, Rusty Russell wrote:
> On Tuesday 04 March 2008 03:05:16 octane indice wrote:
> > Hello
> >
> > I have some difficulty to use network inside lguest.
> > I use a slackware 12 for guest and host with a 2.6.24 kernel.
> >
> > I boot lguest like that:
> > # tunctl
>
Dor Laor wrote:
> Seems to work reliably with kvm, should do the same trick for lguest.
> You can download it from
> git://kvm.qumranet.com/home/dor/src/kvm-guest-drivers-linux
>
> Anthony, you can update your mercurial repository with our changes.
>
Hrm, I thought we were standardizing on
htt
On Wed, 2008-03-05 at 17:05 -0600, Anthony Liguori wrote:
> Dor Laor wrote:
> > On Wed, 2008-03-05 at 19:30 +0200, Avi Kivity wrote:
> >
> >>
> >> Playing a movie is better than any benchmark; it reflects actual user
> >> experience in a real and important use case. Benchmarks are substitutes
On Wed, 2008-03-05 at 17:10 -0600, Anthony Liguori wrote:
> Dor Laor wrote:
> > Seems to work reliably with kvm, should do the same trick for lguest.
> > You can download it from
> > git://kvm.qumranet.com/home/dor/src/kvm-guest-drivers-linux
> >
> > Anthony, you can update your mercurial reposito
Hello,
Is it possible to share a memory (a page perhaps) between the host and
guest? More precisely, could a host and guest share a memory-mapped
file? If one were crazy enough to want to do this, where should they
look first?
Thanks,
Cam
---
This patch implements a simple callback for device drivers that establish
their own references to pages (KVM, GRU, XPmem, RDMA/Infiniband, DMA engines
etc). These references are unknown to the VM (therefore external).
With these callbacks it is possible for the device driver to release external
re
Cam Macdonell wrote:
> Hello,
>
> Is it possible to share a memory (a page perhaps) between the host and
> guest?
Yes, the host always has access to all of the guests memory. All of the
virtio drivers depend on this fact. With KVM, the userspace (in this
case, QEMU), just tells the kernel abo
On Wed, Mar 05, 2008 at 10:48:24AM -0800, Christoph Lameter wrote:
> On Wed, 5 Mar 2008, Nick Piggin wrote:
>
> > Um, it's bound to the *Linux page tables*, yes. And I have no idea why
> > you would use the paravirt ops for this.
>
> paravirt ops allows interception of page table operations?
May
Fixes :
qemu/hw/pc.c: In function `pc_init1':
qemu/hw/pc.c:1029: warning: passing arg 1 of `qemu_system_hot_add_init'
discards qualifiers from pointer target type
Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c |4 ++--
qemu/sysemu.h |2 +-
2 files
Hi Avi,
After reading the patch, I think the hypercall batching mechanism is as follows:
1 defer the MMU-related operations and buffer them in
kvm_para_state->mmu_queue[]
2 during the flush period, kvm_mmu_op() is called to flush operations
in kvm_para_state->mmu_queue[]
3 kvm_mmu_op() generate a
Christoph Lameter wrote:
>
> /*
> + * Notifier for devices establishing their own references to Linux
> + * kernel pages in addition to the regular mapping via page
> + * table and rmap. The notifier allows the device to drop the mapping
> + * when the VM removes references to pages.
> + */
> +e
Glauber Costa wrote:
> If the calling cpu rewrites the system clock msr for any reason,
> release the page we allocated in the last time
>
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
Glauber Costa wrote:
> Align the kvm_vcpu_time array to the size of a cacheline.
>
> Signed-off-by: Glauber Costa <[EMAIL PROTECTED]>
> ---
> arch/x86/kernel/kvmclock.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmcl
Glauber Costa wrote:
> Use the lower 3 lower bits of the system time msr to turn off the clock.
> This means that all clock registration has to be aligned in a 4-byte boundary
>
>
3 bits -> 8 bytes.
How about just using just bit 0 as an enable bit (not a disable bit).
That means the default
Glauber Costa wrote:
> clean this leftover in kvmclock.c
>
>
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by: Microsoft
Defy al
Glauber Costa wrote:
> Hey,
>
> This patch series expose the actual thread id of each cpu via the qemu
> monitor. It is done through "info cpus", which I though would be the
> most natural command to do it. (If you disagree, please voice it)
>
> Goal is to allow tools like libvirt to easily grab it
Anthony Liguori wrote:
>>
>> Set the target in QEMU to be larger than guest ram size. The config
>> space variable will be set negatively, so guest attempts to release
>> pages from the balloon.
>>
>>
>>
>
> Is an __le32 signed? If so, we should just use an unsigned type.
>
>
That woul
Zhao Forrest wrote:
> Hi Avi,
>
> After reading the patch, I think the hypercall batching mechanism is as
> follows:
> 1 defer the MMU-related operations and buffer them in
> kvm_para_state->mmu_queue[]
> 2 during the flush period, kvm_mmu_op() is called to flush operations
> in kvm_para_state->mm
66 matches
Mail list logo
