>From: Darrick J. Wong [mailto:[EMAIL PROTECTED]
>Sent: 2008年7月18日 3:05
>
>If there are multiple VMs that are busy, the busy ones will fight among
>themselves for CPU time. I still see some priority boost, just not as
>much.
some micro-level analysis is useful here.
>
>I wonder how stable the v
Bugs item #1877875, was opened at 2008-01-23 01:32
Message generated for change (Settings changed) made by mtosatti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1877875&group_id=180599
Please note that this message will contain a full copy of the comme
Bugs item #2012799, was opened at 2008-07-07 16:29
Message generated for change (Settings changed) made by mtosatti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2012799&group_id=180599
Please note that this message will contain a full copy of the comme
Bugs item #1999184, was opened at 2008-06-20 18:31
Message generated for change (Settings changed) made by mtosatti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1999184&group_id=180599
Please note that this message will contain a full copy of the comme
> > > + kmalloc(GFP_KERNEL, sizeof(struct
> > kvm_pv_mmu_op_buffer));
> > Surely this produces a warning? kmalloc takes (size, flags) -- you have
> > them reversed here.
> Heh. It actually doesn't.
Yeah, I guess you need sparse to catch the gfp_t mismatch.
> > kfree(NU
Add an 'info kvm' command to the monitor to be used to determine if KVM is
active. It's very similar to the existing 'info kqemu' command.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/monitor.c b/qemu/monitor.c
index 46d5998..20dcca6 100644
--- a/qemu/monitor.c
+++ b/qemu
Decorating the application name is not the best way to let users figure out
if KVM is enabled or not. It's impossible for management applications to
figure out, inconsistent with other accelerators like kqemu, and clutters the
title bar.
We may experience a little user pain in the short term sinc
Removes hypercall device, old balloon device, and vmchannel stuff from QEMU.
The
stuff never was used publicly and is being/has been replaced by virtio.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 8ba8f9a..a7468c1 100644
---
Most likely from a bad merge.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/vl.c b/qemu/vl.c
index e76396f..a30873e 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -8180,7 +8180,6 @@ const QEMUOption qemu_options[] = {
#endif
{ "localtime", 0, QEMU_OPTION_localtime },
This function no longer exists.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/net.h b/qemu/net.h
index 9dc8b7c..933ed3c 100644
--- a/qemu/net.h
+++ b/qemu/net.h
@@ -41,9 +41,6 @@ void qemu_handler_true(void *opaque);
void do_info_network(void);
-/* virtio hack for zero
Again, most likely a bad merge.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/block-vmdk.c b/qemu/block-vmdk.c
index 67dd2f1..843bf86 100644
--- a/qemu/block-vmdk.c
+++ b/qemu/block-vmdk.c
@@ -93,6 +93,7 @@ typedef struct ActiveBDRVState{
static ActiveBDRVState activeBDR
This is unnecessary sign-extension will do the Right Thing. Paul Brook also
objects strongly to it because it's unnecessary.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/cpu-all.h b/qemu/cpu-all.h
index 6ded4e6..a4c05b0 100644
--- a/qemu/cpu-all.h
+++ b/qemu/cpu-all.h
@@
On Wed, Jul 16, 2008 at 01:56:51PM +0800, Tian, Kevin wrote:
>
> How many VMs did you run in this test?
100 idle
> All the VMs are idle except
> the one where your benchmark runs?
Yes.
> How about the actual effect when several VMs are doing some stuff?
If there are multiple VMs that are busy
Hi guys,
I've recently gotten KVM to work on my Slamd64 12.1 machine running
kernel 2.6.26. Once I got everything up and running I tried installing
Windows Server 2008. The installation went fine and I can get
everything up and running and it seems to be working fine. Only
problem is that I canno
Ben-Ami Yassour wrote:
On Thu, 2008-07-17 at 11:31 +0300, Avi Kivity wrote:
Ben-Ami Yassour wrote:
+
+/* FIXME: Implement the OR logic needed to make shared interrupts
on + * this line behave properly + */
Isn't this a showstopper? There is no easy wa
Ben-Ami Yassour wrote:
On Thu, 2008-07-17 at 12:50 +0300, Avi Kivity wrote:
Ben-Ami Yassour wrote:
On Wed, 2008-07-16 at 18:04 +0300, Avi Kivity wrote:
If a level triggered interrupt remains active after the eoi, the ioapic
has to inject it. This is used to support shared in
On Thu, 2008-07-17 at 11:31 +0300, Avi Kivity wrote:
> Ben-Ami Yassour wrote:
> > +
> > +/* FIXME: Implement the OR logic needed to make shared interrupts
> > on + * this line behave properly + */
> >
> >
> >
> Isn't this a showstopper? There is no ea
On Thu, 2008-07-17 at 12:50 +0300, Avi Kivity wrote:
> Ben-Ami Yassour wrote:
> > On Wed, 2008-07-16 at 18:04 +0300, Avi Kivity wrote:
> >
>
> If a level triggered interrupt remains active after the eoi, the ioapic
> has to inject it. This is used to support shared interrupts, or when
> the
* Jan Kiszka ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> > Port/cleanup of KVM-trace to tracepoints.
> >
> > Tracepoints allow dormat instrumentation, like the kernel markers, but also
> > allows to describe the trace points in global headers so they can be easily
> > managed. They als
Avi Kivity wrote:
Ben-Ami Yassour wrote:
I did, and have something very similar queued.
The notification list might help simplify the assigned device code.
Are you planning to merge the patch you have queued, or should I use the
one that I sent you?
I'll dig mine up tomorro
On Thu, 2008-07-17 at 08:40 -0700, Roland Dreier wrote:
> > + struct kvm_pv_mmu_op_buffer *buffer =
> > + kmalloc(GFP_KERNEL, sizeof(struct kvm_pv_mmu_op_buffer));
>
> Surely this produces a warning? kmalloc takes (size, flags) -- you have
> them reversed here.
Heh. It actually doe
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
> Hi Mathieu,
>
Hi Anthony,
> It's difficult to review your patches because they aren't inlined.
>
> At any rate, this patches are unusable with SVM. They try to execute VT
> instructions unconditionally. For instance, you changed:
>>
>> -KVMTRA
Ben-Ami Yassour wrote:
I did, and have something very similar queued.
The notification list might help simplify the assigned device code.
Are you planning to merge the patch you have queued, or should I use the
one that I sent you?
I'll dig mine up tomorrow and post it, so
On Thu, 2008-07-10 at 16:57 +0300, Avi Kivity wrote:
> Ben-Ami Yassour wrote:
> > On Mon, 2008-07-07 at 13:08 +0300, Avi Kivity wrote:
> >
> >> Amit Shah wrote:
> >>
> >>> This will be useful for acking irqs of assigned devices
> >>>
> >>>
> >>>
> >> And also for improving time dr
Hi Mathieu,
It's difficult to review your patches because they aren't inlined.
At any rate, this patches are unusable with SVM. They try to execute VT
instructions unconditionally. For instance, you changed:
-KVMTRACE_1D(INTR, vcpu, vmcs_read32(VM_EXIT_INTR_INFO), handler);
+trace_k
Mathieu Desnoyers wrote:
> Port/cleanup of KVM-trace to tracepoints.
>
> Tracepoints allow dormat instrumentation, like the kernel markers, but also
> allows to describe the trace points in global headers so they can be easily
> managed. They also do not use format strings.
>
> Anything that woul
Port/cleanup of KVM-trace to tracepoints.
Tracepoints allow dormat instrumentation, like the kernel markers, but also
allows to describe the trace points in global headers so they can be easily
managed. They also do not use format strings.
Anything that would involve an action (dereference a poin
The VMCS Encodings will be needed by the kvm-trace probes. Put them in
system-side headers instead of local header.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: 'Peter Zijlstra' <[EMAIL PROTECTED]>
CC: 'Feng(Eric) Liu' <[EMAIL PROTECTED]>
CC: Avi Kivity <[EMAIL PROTECTED]>
CC: kvm@vger
The VMCS read will be needed by the kvm-trace probes. Put them in
static inline functions in system-side headers instead of in the C file.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: 'Peter Zijlstra' <[EMAIL PROTECTED]>
CC: 'Feng(Eric) Liu' <[EMAIL PROTECTED]>
CC: Avi Kivity <[EMAIL
Needed by kvm_tracer probes, which are outside of arch/x86/kvm.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: 'Peter Zijlstra' <[EMAIL PROTECTED]>
CC: 'Feng(Eric) Liu' <[EMAIL PROTECTED]>
CC: Avi Kivity <[EMAIL PROTECTED]>
CC: kvm@vger.kernel.org
---
arch/x86/kvm/kvm_cache_regs.h|
Hi,
Here is a port of KVM-trace, currently using macros on top of the Linux Markers,
to tracepoints. Note that I cleaned up the instrumentation too, so stuff like
KVMTRACE_3D(CR_WRITE, vcpu, (u32)cr,
(u32)kvm_register_read(vcpu, reg),
(u32)((u64)kvm_register_read(vcpu, reg) >> 32),
handler)
> +struct kvm_pv_mmu_op_buffer *buffer =
> +kmalloc(GFP_KERNEL, sizeof(struct kvm_pv_mmu_op_buffer));
Surely this produces a warning? kmalloc takes (size, flags) -- you have
them reversed here.
> +lapic = kzalloc(GFP_KERNEL, sizeof(*lapic));
> +lapic =
KVM uses a lot of kernel stack on x86, especially with gcc 3.x. It
likes to overflow it and make my poor machine go boom. This patch takes
the worst stack users and makes them use kmalloc(). It also saves ~30
bytes in kvm_arch_vm_ioctl() by using a union.
I haven't tested this at all yet. Just
From: Carsten Otte <[EMAIL PROTECTED]>
From: Christian Borntraeger <[EMAIL PROTECTED]>
This is an update patch for libkvm to build and work on s390.
It should address Avis and Christians comments.
Tested on s390. Compile tested on i386.
Avi please consider to apply.
Signed-off-by: Christian Bornt
Dave Hansen wrote:
On Wed, 2008-07-16 at 23:08 -0700, Roland Dreier wrote:
> Yes, things like kvm_lapic_state are way too big to be on the
stack.
I had a quick look at the code, and my worry about dynamic allocation
would be that handling allocation failure seems like it might get
tricky.
On Wed, 2008-07-16 at 23:08 -0700, Roland Dreier wrote:
> > Yes, things like kvm_lapic_state are way too big to be on the
> stack.
>
> I had a quick look at the code, and my worry about dynamic allocation
> would be that handling allocation failure seems like it might get
> tricky. Eg for handli
On 07/17, Mark McLoughlin wrote:
>
> On Wed, 2008-07-16 at 20:21 +0400, Oleg Nesterov wrote:
> > On 07/16, Mark McLoughlin wrote:
> > >
> > > When a timer fires, posix_timer_event() zeroes out its
> > > pre-allocated siginfo structure, initialises it and then
> > > queues up the signal with send_si
Marcelo Tosatti wrote:
On Thu, Jul 17, 2008 at 01:03:57PM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
As the comment in the diff mentions, VMX does not accept any bit in
the range 11:0 of ES,CS,FS,GS,SS segment registers limit field to be
zero with the granulity bit set to one.
S
On Thu, Jul 17, 2008 at 01:03:57PM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
>> As the comment in the diff mentions, VMX does not accept any bit in
>> the range 11:0 of ES,CS,FS,GS,SS segment registers limit field to be
>> zero with the granulity bit set to one.
>>
>> So clear granularity
Hi Oleg,
On Wed, 2008-07-16 at 20:21 +0400, Oleg Nesterov wrote:
> On 07/16, Mark McLoughlin wrote:
> >
> > When a timer fires, posix_timer_event() zeroes out its
> > pre-allocated siginfo structure, initialises it and then
> > queues up the signal with send_sigqueue().
> >
> > However, we may hav
Christian Borntraeger wrote:
This is an update patch for libkvm to build and work on s390
[...]
Index: kvm-userspace/libkvm/libkvm-s390.c
===
--- /dev/null
+++ kvm-userspace/libkvm/libkvm-s390.c
@@ -0,0 +1,137 @@
+/*
+ * This file
Marcelo Tosatti wrote:
As the comment in the diff mentions, VMX does not accept any bit in
the range 11:0 of ES,CS,FS,GS,SS segment registers limit field to
be zero with the granulity bit set to one.
So clear granularity and adjust the limit accordingly.
Signed-off-by: Marcelo Tosatti <[EMA
Marcelo Tosatti wrote:
The following patchset fixes task switch problems seen on installation
of SMP Windows (2000, 2003 and supposedly XP).
Windows 2003 reboots fine, but crashes during initialization (separate
problem though, also happens with UP installation or with new qemu-kvm
instance). XP
Ben-Ami Yassour wrote:
On Wed, 2008-07-16 at 18:04 +0300, Avi Kivity wrote:
Ben-Ami Yassour wrote:
+/* Stores information for identifying host PCI devices assigned to the
+ * guest: this is used in the host kernel and in the userspace.
+ */
+struct kvm_pci_pt_info {
+ unsigned cha
On Wed, 2008-07-16 at 18:04 +0300, Avi Kivity wrote:
> Ben-Ami Yassour wrote:
> > +/* Stores information for identifying host PCI devices assigned to the
> > + * guest: this is used in the host kernel and in the userspace.
> > + */
> > +struct kvm_pci_pt_info {
> > + unsigned char busnr;
> > +
Ben-Ami Yassour wrote:
+
+/* FIXME: Implement the OR logic needed to make shared interrupts
on + * this line behave properly + */
Isn't this a showstopper? There is no easy way for a user to avoid
sharing, especially as we have only three pci irqs at present.
What d
On Thu, 2008-07-17 at 09:02 +0300, Avi Kivity wrote:
> Han, Weidong wrote:
> > Avi Kivity wrote:
> >
> >>> +static void kvm_pci_pt_work_fn(struct work_struct *work) +{
> >>> + struct kvm_pci_pt_dev_list *match;
> >>> + struct kvm_pci_pt_work *int_work;
> >>> + int source;
> >>> + unsigned long f
Ben-Ami Yassour wrote:
> From: Or Sagi <[EMAIL PROTECTED]>
>
> From: Nir Peleg <[EMAIL PROTECTED]>
> From: Amit Shah <[EMAIL PROTECTED]>
> From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
>
> We can assign a device from the host machine to a guest. The
> original code comes from Neocleus.
>
>
Bugs item #2001452, was opened at 2008-06-24 07:27
Message generated for change (Comment added) made by gerdwachs
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2001452&group_id=180599
Please note that this message will contain a full copy of the comment
49 matches
Mail list logo