Rusty Russell wrote:
> On Tue, 2007-07-10 at 08:53 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> No; this is a "I'm doing something magic and need to know before someone
>>> else takes the CPU". Almost by definition, you cannot have two of them
>>> at the same time. Let someon
On Tue, 2007-07-10 at 10:19 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > Exactly, if we have two at the same time, they need to know about each
> > other. Providing infrastructure which lets them avoid thinking about it
> > is the wrong direction.
> >
>
> With a kvm-specific hook, they
Hi, all
This is today's ABAT testing result against kvm-kernel
344d2fba147c955053ced20b39f6a36d493bfab8 and userspace
5d1b2cc7e4467dc383ffd69eace00bd306d4a7b3
Status Summary:
##What's working:
Can boot most ia32/ia32e UP Linux guests with either acpi enabled or
acpi disabled.
Can boot ia32 UP UP
Anthony Liguori wrote:
> This looks like a typo. I think the intention of the if is to normalize
> i[3456]86 to i386 since that's the target name for QEMU.
>
> Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
>
> diff --git a/configure b/configure
> index d9292fe..e4d1ec6 100755
> --- a/configur
Rusty Russell wrote:
> On Tue, 2007-07-10 at 10:19 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> Exactly, if we have two at the same time, they need to know about each
>>> other. Providing infrastructure which lets them avoid thinking about it
>>> is the wrong direction.
>>>
On 7/10/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Satyam Sharma wrote:
> >
> >
> > On 7/9/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >> [...]
> >> on_each_cpu() was imho always a mistake. It would have been better
> >> to just fix smp_call_function() directly
> >
> > I'm not sure what you mean b
Jindrich Makovicka wrote:
> On Thu, 14 Jun 2007 17:46:14 +0200
> Magicboiz <[EMAIL PROTECTED]> wrote:
>
>
>> with VNC option, we had better luck: we got an Oops!!:
>>
>> Jun 14 17:37:35 linux kernel: [ 575.212000] BUG: unable to handle
>> kernel NULL pointer dereference at virtual address 0
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
Won't that increase task_struct (16 bytes on 64-bit) unnecessarily?
The function pointers are common to all virtual machines.
>>> well, this function pointer could then be reused by other virtual
>>> mach
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> How do you feel about some variant of this going into 2.6.23-rc1? I
> initially thought of this as a 2.6.24 thing, but as it now looks
> solid, maybe we can hurry things along.
yeah, fine by me. You were working on a more generic patch, right? I
thin
Satyam Sharma wrote:
> On 7/10/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>> Satyam Sharma wrote:
>> >
>> >
>> > On 7/9/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>> >> [...]
>> >> on_each_cpu() was imho always a mistake. It would have been better
>> >> to just fix smp_call_function() directly
>> >
>
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
just a trivial cosmetic fix, taking advantage of the static inlines
defined in include/linux/highmem.h.
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index c1ac106..6425084 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -
Robert P. J. Day wrote:
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> just a trivial cosmetic fix, taking advantage of the static inlines
> defined in include/linux/highmem.h.
>
> diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
> index c1ac106..6425084 100644
> --- a/driver
On Tue, 10 Jul 2007, Avi Kivity wrote:
> Robert P. J. Day wrote:
> > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
> >
> > ---
> >
> > just a trivial cosmetic fix, taking advantage of the static inlines
> > defined in include/linux/highmem.h.
> >
> > diff --git a/drivers/kvm/vmx.c b/driver
[EMAIL PROTECTED] wrote:
> Avi Kivity wrote:
>> Dong, Eddie wrote:
>>> Avi:
>>> To make lapic code into mainline earlier, I am thinking what
>>> should the user space code look like. If we wait till lapic branch
>>> has all same functionality as mainline have today i.e. live
>>> migration, all
Dong, Eddie wrote:
> [EMAIL PROTECTED] wrote:
>
>> Avi Kivity wrote:
>>
>>> Dong, Eddie wrote:
>>>
Avi:
To make lapic code into mainline earlier, I am thinking what
should the user space code look like. If we wait till lapic branch
has all same functionality a
> If we release a kernel with pic but not lapic, and userspace that
> defaults to user-pic+lapic, then that kernel will not work
> with a newer
> userspace that defaults to in-kernel pic+lapic.
>
> We need to switch in one go. I don't mind checking in patches to the
> lapic2 branch, and continua
Dong, Eddie wrote:
>> If we release a kernel with pic but not lapic, and userspace that
>> defaults to user-pic+lapic, then that kernel will not work
>> with a newer
>> userspace that defaults to in-kernel pic+lapic.
>>
>> We need to switch in one go. I don't mind checking in patches to the
>> lap
> I don't think live migration is particularly difficult. You
> need a APIs
> to read and write the PIC+LAPIC states, and you write the
> state into the
This is partily true party not. Like what did in Xen, a live migration
in kernel side need to consider not only device state, but also cpu
stat
On Tue, 2007-07-10 at 22:08 +0800, Dong, Eddie wrote:
> > I don't think live migration is particularly difficult. You
> > need a APIs
> > to read and write the PIC+LAPIC states, and you write the
> > state into the
>
> This is partily true party not.
I agree with Avi here. The system is alread
Save US $ 1529.1 THANKS TO THIS SITE I CAN DOWNLOAD PHOTOSHOP CS3 ONLY $89 $269
http://dvacvetakr.com
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control o
Bugs item #1751350, was opened at 2007-07-10 19:52
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=1751350&group_id=180599
Please note that this message will contain a full copy
On 7/10/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Satyam Sharma wrote:
> > On 7/10/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> >> Satyam Sharma wrote:
> >> >
> >> >
> >> > On 7/9/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >> >> [...]
> >> >> on_each_cpu() was imho always a mistake. It would have
> I had already solved these types of issues neatly in the lapic branch,
> so perhaps you can model a solution from that (at least in
> spirit). For
> instance, the irq.deferred source has the IDT_Vectoring state,
> irq.pending has the vcpu interrupt state (NMI, EXTINT, etc),
> kvm->isa_int has t
On Wed, 2007-07-11 at 09:34 +0800, Dong, Eddie wrote:
> No, what you mean is only for external irq. IDT_Vectoring can happen for
> any exception injection.
Well, yes, but that really is just an attribute the irq.deferred
"source" needs to maintain, right? I had been thinking of adding
something
Avi Kivity wrote:
>
>> The
>> congruent case which comes to mind is lazy FPU handling.
>>
>
> That one has preempt_ops in hardware: cr0.ts and #NM.
However, that doesn't handle in-kernel use of the fpu.
kernel_fpu_begin()/kernel_fpu_end() could easily be modified to take
advantage of a gener
25 matches
Mail list logo
