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 by fix here, but if you're proposing
that we change smp_call_function()
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 0024
[...]
Jun 14 17:37:35 linux kernel: [
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 someone else try that if and when...
Why can't
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 can't stop
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
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/configure
+++
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.
With a
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 by fix here, but if
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 0024
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
machines as well, couldnt
* 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
think a
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
I'm not sure what you mean by
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/drivers/kvm/vmx.c
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/drivers/kvm/vmx.c
[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 guests etc, we
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 as mainline have today i.e.
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 continually
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
state.
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 already set up
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
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=detailatid=893831aid=1751350group_id=180599
Please note that this message will contain a full copy of
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 been better
to just fix
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 the PIC
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 generic
26 matches
Mail list logo
