From: Avi Kivity [EMAIL PROTECTED]
Conflicts:
qemu/configure
qemu/console.c
qemu/hw/e1000.c
qemu/hw/eepro100.c
qemu/hw/ne2000.c
qemu/hw/pc.c
qemu/hw/rtl8139.c
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
--
To unsubscribe from this list:
From: H. Peter Anvin [EMAIL PROTECTED]
this allows extboot to place its int13 chain in the code segment.
Signed-off-by: H. Peter Anvin [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index 26e3540..3a8269b 100644
--- a/qemu/hw/pc.c
+++
From: Avi Kivity [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/kernel/external-module-compat.h b/kernel/external-module-compat.h
index dfd90cf..49751fc 100644
--- a/kernel/external-module-compat.h
+++ b/kernel/external-module-compat.h
@@ -746,3 +746,14 @@ static
From: Ingo Molnar [EMAIL PROTECTED]
x86 -tip testing found this build bug:
arch/x86/kvm/built-in.o:(.text.fixup+0x1): relocation truncated to fit:
R_X86_64_32 against `.text'
arch/x86/kvm/built-in.o:(.text.fixup+0xb): relocation truncated to fit:
R_X86_64_32 against `.text'
From: Avi Kivity [EMAIL PROTECTED]
An invalid page may still contain sptes, as the current vcpu may not have
had the chance to unload its root after the page was marked invalid.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index
From: Avi Kivity [EMAIL PROTECTED]
We now detect event injection using the interrupt and exception queues,
not the IDT-Vectoring info field.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 67b02c0..c4510fe 100644
--- a/arch/x86/kvm/vmx.c
Avi Kivity wrote:
Alexander Graf wrote:
+pr_unimpl(vcpu, %s: MSR_IA32_DEBUGCTLMSR 0x%llx, nop\n,
+__func__, data);
We can avoid the printout if data == 0, since we support that case
fully.
I was thinking a lot about that. Even though we support data == 0,
usually
Alexander Graf wrote:
Corrected patch follows...
---
Netware writes to DEBUGCTL and reads from the DEBUGCTL and LAST*IP
MSRs without further checks and is really confused to receive a #GP
during that. To make it happy we should just make them stubs, which is
exactly what SVM already does.
H. Peter Anvin wrote:
extboot's use of interrupt vectors $0x2b and $0x2c is unsafe, as these
interrupt vectors fall in the OS-use range (0x20-0x3f). Furthermore,
it's unnecessary: we can keep a local pointer instead of hooking
another interrupt as long as we can write to our own segment.
Make
Marcelo Tosatti wrote:
On Sat, Jul 12, 2008 at 01:28:13PM -0600, David S. Ahern wrote:
All time drift issues we were aware of are fixed in kvm-70. Can you
please provide more details on how you see the time drifting with
RHEL3/4 guests? It slowly but continually drifts or there are large
From: Kay, Allen M [EMAIL PROTECTED]
This patch extends the VT-d driver to support KVM
[Ben: fixed memory pinning]
Signed-off-by: Kay, Allen M [EMAIL PROTECTED]
Signed-off-by: Weidong Han [EMAIL PROTECTED]
Signed-off-by: Ben-Ami Yassour [EMAIL PROTECTED]
---
drivers/pci/dmar.c
Following are the device assignment patches with the fixes of the
comments that were sent for the previous version.
Here is the list of changes that were made with respect to the previous
version:
1. Replace the interrupt ack hook patches with the notifiers list patch
by Avi.
2. Remove code from
From: Kay, Allen M [EMAIL PROTECTED]
This patch includes the functions to support VT-d for passthrough
devices.
[Ben: fixed memory pinning, cleanup]
Signed-off-by: Kay, Allen M [EMAIL PROTECTED]
Signed-off-by: Weidong Han [EMAIL PROTECTED]
Signed-off-by: Ben-Ami Yassour [EMAIL PROTECTED]
---
Based on a patch from: Amit Shah [EMAIL PROTECTED]
This patch adds support for handling PCI devices that are assigned to
the guest.
The device to be assigned to the guest is registered in the host kernel
and interrupt delivery is handled. If a device is already assigned, or
the device driver for
Followed is the userspace patch for device assignment
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Based on a patch from: Amit Shah [EMAIL PROTECTED]
We can assign a device from the host machine to a guest. The
original code comes from Neocleus.
A new command-line option, -pcidevice is added.
For example, to invoke it for an Ethernet device sitting at
PCI bus:dev.fn 04:08.0 with host IRQ 18,
Sheng,
Thanks for the comments, I sent an updated version of the patches.
Please see reply below.
Thanks,
Ben
On Thu, 2008-07-17 at 10:00 +0800, Yang, Sheng wrote:
Some comments below. :)
On Wednesday 16 July 2008 23:56:50 Ben-Ami Yassour wrote:
+ __func__);
+
On Thu, 2008-07-17 at 15:52 +0800, Han, Weidong wrote:
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
Bugs item #2024740, was opened at 2008-07-22 10:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2024740group_id=180599
Please note that this message will contain a full copy of
Sorry for the late reply I was on vacation last week.
On Tue, Jul 15, 2008 at 08:00:57PM -0400, Arn wrote:
Hi,
The recent 2.6.26 release didn't say anything about mmu-notifiers. My
impression was that it will be going to be included
in that release. Where can I download and try it out, what
On Sun, Jul 20, 2008 at 09:43:53AM +0530, Sukanto Ghosh wrote:
Hi all,
I was going through the slides Integrating KVM with the linux memory
management on MMU notifiers.
can anyone tell me ... if spte is invisible to linux vm, then why does
page-_mapcount increments when a spte mapping is
Mathieu Desnoyers wrote:
* 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
KVM intends to use paravirt code to calibrate khz. Xen
current code will do just fine. So as a first step, factor out
code to pvclock.c.
Signed-off-by: Glauber Costa [EMAIL PROTECTED]
---
arch/x86/kernel/pvclock.c | 12
arch/x86/xen/time.c | 11 ++-
We're currently facing timing problems in guests that do
calibration under heavy load, and then the load vanishes.
This means we'll have a much lower lpj than we actually should,
and delays end up taking less time than they should, which is a
nasty bug.
Solution is to pass on the lpj value from
On Sat, 2008-07-12 at 17:42 +0200, Alexander Graf wrote:
Hi Beth,
On Jul 10, 2008, at 5:48 AM, Beth Kon wrote:
This patch, based on an earlier patch by Alexander Graf, adds HPET
emulation to qemu. I am sending out a separate patch to kvm with the
required bios changes.
This work is
Mathieu Desnoyers wrote:
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),
Jan Kiszka wrote:
That's true - as long as you don't have to add/remove/modify
tracepoints. I had to do this job in the past (not for KVM). Having 1
spot in 1 file (based on generic probes) would be handier in that case
than 5 spots in 3 files. But if the KVM tracepoints are considered
stable in
On Tue, 22 Jul 2008, Simon Holm Thøgersen wrote:
tir, 22 07 2008 kl. 18:44 +0200, skrev Julia Lawall:
From: Julia Lawall [EMAIL PROTECTED]
There is a call to local_irq_restore in the normal exit case, so it would
seem that there should be one on an error return as well.
The
Avi Kivity [EMAIL PROTECTED] writes:
[...]
kvm tracepoints are heavily tied into the implementation; and making
them harder to write means we will have less information. In fact, I
am contemplating moving in another direction (when looking at the
pgprintk()s scattered around
Frank Ch. Eigler wrote:
Avi Kivity [EMAIL PROTECTED] writes:
[...]
kvm tracepoints are heavily tied into the implementation; and making
them harder to write means we will have less information. In fact, I
am contemplating moving in another direction (when looking at the
pgprintk()s
From: Julia Lawall [EMAIL PROTECTED]
There is a call to local_irq_restore in the normal exit case, so it would
seem that there should be one on an error return as well.
The semantic patch that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@@
expression l;
This option was meant to be temporary until TCG was fixed on PowerPC hosts. It
has been so let's get rid of it. The only issue this would introduce is that
GCC 4 could no longer be used to build KVM for PowerPC. Hollis has switched to
GCC 3.x for other reasons though so this is not a big deal.
tir, 22 07 2008 kl. 18:44 +0200, skrev Julia Lawall:
From: Julia Lawall [EMAIL PROTECTED]
There is a call to local_irq_restore in the normal exit case, so it would
seem that there should be one on an error return as well.
The semantic patch that makes this change is as follows:
The last time I posted the KVM patch series to qemu-devel, the -tdf patch met
with
some opposition. Since today we implement timer catch-up in the in-kernel PIT
and
the in-kernel PIT is used by default, it doesn't seem all that valuable to have
timer catch-up in userspace too.
Removing it will
This option no longer exists.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/vl.c b/qemu/vl.c
index d9b7db2..82c9831 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -8090,7 +8090,6 @@ enum {
QEMU_OPTION_startdate,
QEMU_OPTION_tb_size,
QEMU_OPTION_icount,
-
On Tue, Jul 22, 2008 at 09:38:18PM +0200, Julia Lawall wrote:
There is a call to local_irq_restore in the normal exit case, so it would
seem that there should be one on an error return as well.
Patch looks good to me:
Reviewed-by: Matthew Wilcox [EMAIL PROTECTED]
--
Intel are signing my
Avi Kivity [EMAIL PROTECTED] writes:
[...]
Have you considered using trace_mark() directly - eliminating the
KVM_TRACEN() middlemen?
[...]
Using trace_mark() directly -- looking at it, seems to fit the
requirements exactly. Should have looked at it earlier. Is there a
way to get a list
I've been running a series of tests on RHEL3, RHEL4, and RHEL5. The
short of it is that all of them keep time quite well with 1 vcpu. In the
case of RHEL3 and RHEL4 time is stable for *both* the uniprocessor and
smp kernels, again with only 1 vcpu (there's no up/smp distinction in
the kernels for
Bugs item #2017966, was opened at 2008-07-14 09:30
Message generated for change (Comment added) made by mtosatti
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_id=180599
Please note that this message will contain a full copy of the comment
On Tue, 2008-07-22 at 14:38 -0500, Anthony Liguori wrote:
This option was meant to be temporary until TCG was fixed on PowerPC hosts.
It
has been so let's get rid of it. The only issue this would introduce is that
GCC 4 could no longer be used to build KVM for PowerPC. Hollis has switched
Marcelo Tosatti wrote:
On Tue, Jul 22, 2008 at 10:22:00AM +0200, Jan Kiszka wrote:
The in-kernel PIT rearms relative to host clock, so the frequency is
more reliable (next_expiration = prev_expiration + count).
The same happens under plain QEMU:
static void
Anthony Liguori wrote:
The last time I posted the KVM patch series to qemu-devel, the -tdf patch met
with
some opposition. Since today we implement timer catch-up in the in-kernel PIT
and
the in-kernel PIT is used by default, it doesn't seem all that valuable to have
timer catch-up in
* Avi Kivity ([EMAIL PROTECTED]) wrote:
Frank Ch. Eigler wrote:
Avi Kivity [EMAIL PROTECTED] writes:
[...]
kvm tracepoints are heavily tied into the implementation; and making
them harder to write means we will have less information. In fact, I
am contemplating moving in another
Dor Laor wrote:
Anthony Liguori wrote:
The last time I posted the KVM patch series to qemu-devel, the -tdf
patch met with
some opposition. Since today we implement timer catch-up in the
in-kernel PIT and
the in-kernel PIT is used by default, it doesn't seem all that
valuable to have
timer
Julia Lawall wrote:
From: Julia Lawall [EMAIL PROTECTED]
There is a call to local_irq_restore in the normal exit case, so it
would
seem that there should be one on an error return as well.
The semantic patch that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
Anthony Liguori wrote:
Dor Laor wrote:
Anthony Liguori wrote:
The last time I posted the KVM patch series to qemu-devel, the -tdf
patch met with
some opposition. Since today we implement timer catch-up in the
in-kernel PIT and
the in-kernel PIT is used by default, it doesn't seem all
46 matches
Mail list logo
