On Friday 09 May 2008 22:53:00 Marcelo Tosatti wrote:
> On Fri, May 09, 2008 at 03:49:20PM +0800, Yang, Sheng wrote:
> > On Sunday 13 April 2008 17:28:22 Avi Kivity wrote:
> > > Marcelo Tosatti wrote:
> > > > On Fri, Apr 11, 2008 at 03:12:41PM +0300, Avi Kivity wrote:
> > > >> This breaks ia64 (and
On Fri, May 09, 2008 at 04:26:35PM -0600, W S wrote:
> Greetings,
>
> In referring to this interview with Avi
> (http://kerneltrap.org/node/8088) dated April of last year, it's
> mentioned KVM doesn't really do multiple CPUs for guests. Is this
> still the case? I'd assume that's not the case a
Greetings,
In referring to this interview with Avi
(http://kerneltrap.org/node/8088) dated April of last year, it's
mentioned KVM doesn't really do multiple CPUs for guests. Is this
still the case? I'd assume that's not the case a year later, but I'm
about to roll out some guests using KVM on Ub
From: Andrea Arcangeli <[EMAIL PROTECTED]>
With KVM/GFP/XPMEM there isn't just the primary CPU MMU pointing to
pages. There are secondary MMUs (with secondary sptes and secondary
tlbs) too. sptes in the kvm case are shadow pagetables, but when I say
spte in mmu-notifier context, I mean "secondary
On Fri, May 09, 2008 at 04:22:08PM -0300, Marcelo Tosatti wrote:
> For things like register dumps I don't believe its worthwhile. Much
> simpler to stop the vcpu with SIG_IPI, retrieve registers, and run it
> again (now that you mention the busy-spin, it is broken right now, if a
> vcpu is spinning
On Fri, May 09, 2008 at 06:09:41PM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
> >On Fri, May 09, 2008 at 10:40:47AM +0300, Avi Kivity wrote:
> >
> >
> >>>Unfortunately it can't use wait_event_interruptible() due to
> >>>vcpu_put/vcpu_load.
> >>>
> >>>
> >>>
> >>schedule() will call
On Fri, 2008-05-09 at 20:55 +0200, Andrea Arcangeli wrote:
> On Fri, May 09, 2008 at 08:37:29PM +0200, Peter Zijlstra wrote:
> > Another possibility, would something like this work?
> >
> >
> > /*
> > * null out the begin function, no new begin calls can be made
> > */
> > rcu_assing_point
On Fri, May 09, 2008 at 08:37:29PM +0200, Peter Zijlstra wrote:
> Another possibility, would something like this work?
>
>
> /*
> * null out the begin function, no new begin calls can be made
> */
> rcu_assing_pointer(my_notifier.invalidate_start_begin, NULL);
>
> /*
> * lock/unlock a
Marcelo Tosatti wrote:
> diff --git a/qemu/qemu-kvm-ia64.c b/qemu/qemu-kvm-ia64.c
> index 4d0ddd7..d227d22 100644
> --- a/qemu/qemu-kvm-ia64.c
> +++ b/qemu/qemu-kvm-ia64.c
> @@ -61,3 +61,7 @@ int kvm_arch_try_push_interrupts(void *opaque)
> void kvm_arch_update_regs_for_sipi(CPUState *env)
> {
>
On Thu, 2008-05-08 at 09:11 -0700, Linus Torvalds wrote:
>
> On Thu, 8 May 2008, Linus Torvalds wrote:
> >
> > Also, we'd need to make it
> >
> > unsigned short flag:1;
> >
> > _and_ change spinlock_types.h to make the spinlock size actually match the
> > required size (right now we make
Avi Kivity wrote:
> Anthony Liguori wrote:
>> We're pretty sloppy in virtio right now about phys_ram_base
>> assumptions. This
>> patch is an incremental step between what we have today and a full
>> blown DMA
>> API. I backported the DMA API but the performance impact was not
>> acceptable
>>
On Fri, May 09, 2008 at 10:13:33AM +0200, Jan Kiszka wrote:
> Hmm, need to think a bit more about it as I don't see the benefit yet
> (code suggestions are welcome in the meantime :)!).
Doing the reset from two different contexes is confusing and more
complicated.
> The changes to vl.c are actual
Yang, Sheng wrote:
> From 4942a5c35c97e5edb6fe1303e04fb86f25cac345 Mon Sep 17 00:00:00 2001
> From: Sheng Yang <[EMAIL PROTECTED]>
> Date: Thu, 8 May 2008 16:00:57 +0800
> Subject: [PATCH 3/4] KVM: VMX: Enable NMI with in-kernel irqchip
>
>
> static void kvm_do_inject_irq(struct kvm_vcpu *vcpu)
>
Zhang, Xiantao wrote:
> Avi,
> Please drop the previous one due to a wrong attachment.
> Xiantao
>
> From a9f479197f0a0efa45a930309fad03fd690cba60 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Thu, 8 May 2008 10:16:05 +0800
> Subject: [PATCH] KVM: Qemu : IA-64 b
Yang, Sheng wrote:
> From 650cad44069541fcd9fea8be6a78837e812b3dfd Mon Sep 17 00:00:00 2001
> From: Sheng Yang <[EMAIL PROTECTED]>
> Date: Thu, 8 May 2008 09:58:50 +0800
> Subject: [PATCH 1/4] KVM: LAPIC: Unified the duplicate calling of setting IRR
>
> It's strange got two callings of setting IRR
Anthony Liguori wrote:
> This patch implements the core of save/restore support for virtio. It's
> modelled after how PCI save/restore works.
>
> N.B. This makes savevm/loadvm work, but not live migration. The issue with
> live migration is that we're manipulating guest memory without updating th
Farkas Levente wrote:
> mandrake 9, 10 and winxp run but neither centos-5.1 i386 nor x86_64 are
> boot:-( i386 give a kernel panic x86_64 simple hang during boot.
>
Can you post the panic?
It's probably the 3Dnow! bug which is fixed for kvm-69.
--
Do not meddle in the internals of kernels
Anthony Liguori wrote:
> We're pretty sloppy in virtio right now about phys_ram_base assumptions. This
> patch is an incremental step between what we have today and a full blown DMA
> API. I backported the DMA API but the performance impact was not acceptable
> to me. There's only a slight perfor
Damjan wrote:
> Strange situation, I have a Ubuntu JeOS image that crashes with this
> error when started by the kvm-068 user-space. Bellow is the trace from
> the kernel...
>
> The same image, works with:
> - kvm-066 user space, kvm-068 kernel module (on 2.6.24 and 2.6.25)
> - kvm-066 user space,
On Fri, May 09, 2008 at 03:49:20PM +0800, Yang, Sheng wrote:
> On Sunday 13 April 2008 17:28:22 Avi Kivity wrote:
> > Marcelo Tosatti wrote:
> > > On Fri, Apr 11, 2008 at 03:12:41PM +0300, Avi Kivity wrote:
> > >> This breaks ia64 (and shouldn't s390 use this too?)
> > >>
> > >>> * We will
Marcelo Tosatti wrote:
> On Fri, May 09, 2008 at 10:40:47AM +0300, Avi Kivity wrote:
>
>
>>> Unfortunately it can't use wait_event_interruptible() due to
>>> vcpu_put/vcpu_load.
>>>
>>>
>>>
>> schedule() will call vcpu_put()/vcpu_load() for us through preempt
>> notifiers. I feel a li
Yunfeng,
I'd like additional information to help narrow
the problem space and assure this isn't some type
of version skew problem. Please see my comments/
questions inline below.
Thanks,
-john
> Subject: [kvm-devel] [ kvm-Bugs-1941302 ] Cannot boot guests with hugetlbfs
> From: "SourceForg
On Fri, May 09, 2008 at 10:40:47AM +0300, Avi Kivity wrote:
> >Unfortunately it can't use wait_event_interruptible() due to
> >vcpu_put/vcpu_load.
> >
> >
>
> schedule() will call vcpu_put()/vcpu_load() for us through preempt
> notifiers. I feel a little uneasy about it, but no concreate reas
Marcelo Tosatti wrote:
> On Wed, May 07, 2008 at 08:45:12PM +0200, Gerd Hoffmann wrote:
>> Ok folks, here is the band aid fix for testing from the odd bugs
>> department. Goes on top of the four patches of this series. A real,
>> clean solution is TBD. Tomorrow I hope (some urgent private proble
Title: Security Update Notification
News Alert:
Banking
with Natwest Online
is about to become even more secure!
As a valued Natwest online customers, the security of
your identity and personal account information is extremely important.
We are installing Enhanced
Online Securi
Marcelo Tosatti wrote:
> Hi Jan,
>
> On Thu, May 08, 2008 at 10:29:32AM +0200, Jan Kiszka wrote:
>> Resetting guests used to be racy, deadlock-prone, or simply broken (for
>> SMP). This patch fixes the issues - at least for me on x86 (tested on
>> Intel SMP host, UP and SMP guest, in-kernel und us
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>> Aurelien Jarno wrote:
>>>
On Wed, May 07, 2008 at 04:40:58PM -0500, Anthony Liguori wrote:
> The current logic of the can_receive handler is to allow packets
> whenever th
On Sunday 13 April 2008 17:28:22 Avi Kivity wrote:
> Marcelo Tosatti wrote:
> > On Fri, Apr 11, 2008 at 03:12:41PM +0300, Avi Kivity wrote:
> >> This breaks ia64 (and shouldn't s390 use this too?)
> >>
> >>>* We will block until either an interrupt or a signal wakes us up
> >>>*/
> >>> wh
Marcelo Tosatti wrote:
> There's still a race in kvm_vcpu_block(), if a wake_up_interruptible()
> call happens before the task state is set to TASK_INTERRUPTIBLE:
>
> CPU0CPU1
>
> kvm_vcpu_block
>
> add_wait_queue
>
> kv
29 matches
Mail list logo
