From: Marcelo Tosatti [EMAIL PROTECTED]
There is no guarantee that the old TSS descriptor in the GDT contains
the proper base address. This is the case for Windows installation's
reboot-via-triplefault.
Use guest registers instead. Also translate the address properly.
Signed-off-by: Marcelo
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 flags;
+ int guest_irq;
+ int host_irq;
+
+
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 handling struct kvm_pv_mmu_op_buffer (which is 528 bytes
on the stack in
On Thu, 2008-07-17 at 08:52 +0300, Avi Kivity wrote:
Dave Hansen wrote:
Avi, how would you like this fixed? I'd be happy to prepare some
patches. Do you have a particular approach that you think we should
use? Just make the big objects dynamically allocated?
Yes, things like
A newer gcc (4.2) makes this a wee bit better, but probably still
worrisome.
[EMAIL PROTECTED]:~/src/kvm-userspace-virgin/kernel$ objdump -d *.ko | perl
/home/dave/kernels/linux-2.6.git-t61/scripts/checkstack.pl i386
0x7b33 kvm_arch_vm_ioctl [kvm]: 1164
0x72e8
Dave Hansen wrote:
switch (...) {
case x: {
struct medium a;
...
}
case y:
struct medium b;
...
}
};
These could be solved either by stack allocation, or by moving into
functions marked noinline. Whichever is easier.
Did you mean
That also reminds me. kvm somehow has an outdated copy of
anon_inodes.c. It needs to be updated for the r/o bind mount patches to
add a proper mnt_want/drop_write(). Otherwise, you'll run into warnings
about imbalanced mount writer counts. Something like this will do, but
it would be best to
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=detailatid=893831aid=2001452group_id=180599
Please note that this message will contain a full copy of the comment
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.
A new
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 flags;
+ int guest_irq;
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
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
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).
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 have previously
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
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 and adjust
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.
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.
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
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.
+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 =
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);
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| 32
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);
+
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 drift tracking.
Please make
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-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 doesn't.
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
* 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 also do not
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 way for a user to avoid
sharing,
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
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
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
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,
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
@@
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
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 },
{
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
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
+++
+ 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(NULL) is
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=detailatid=893831aid=1877875group_id=180599
Please note that this message will contain a full copy of the comment
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 virtual
44 matches
Mail list logo
