On 02/02/2011 05:52 PM, Jan Kiszka wrote:
If there is no problem in the logic of this commit (and I do not see
one yet) then we somewhere miss kicking vcpu when interrupt, that should be
handled, arrives?
I'm not yet confident about the logic of the kernel patch: mov to cr8 is
On 02.02.2011, at 23:08, Scott Wood wrote:
On Wed, 2 Feb 2011 22:33:41 +0100
Alexander Graf ag...@suse.de wrote:
On 02.02.2011, at 21:33, Yoder Stuart-B08248 wrote:
Below is a proposal for a new API for PPC to allow KVM clients
to set MMU state in a vcpu.
BookE processors have one
Hello, I have server platform S5520UR, 2x Intel Xeon E5520 with Debian Squeeze.
In kvm guest with debian, I execute gbuk for firebird and he working
quickly on 1 cpu guest, than 4.
vmstat show that with 1 cpu guest 300/s interrupts, but in 4 cpu guest
interrupts over 12000/s
If run gbuk in host
On 02.02.2011, at 23:34, Yoder Stuart-B08248 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Wednesday, February 02, 2011 3:34 PM
To: Yoder Stuart-B08248
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; qemu-de...@nongnu.org
Subject: Re: RFC: New
On 2011-02-03 08:42, Gleb Natapov wrote:
On Wed, Feb 02, 2011 at 05:51:32PM +0100, Jan Kiszka wrote:
Just did so, and I can no longer reproduce the problem. Hmm...
If there is no problem in the logic of this commit (and I do not see
one yet) then we somewhere miss kicking vcpu when interrupt,
On 2011-02-03 09:18, Avi Kivity wrote:
On 02/02/2011 05:52 PM, Jan Kiszka wrote:
If there is no problem in the logic of this commit (and I do not see
one yet) then we somewhere miss kicking vcpu when interrupt, that should be
handled, arrives?
I'm not yet confident about the logic of the
On Sun, Jan 30, 2011 at 11:15:46AM +0800, Huang Ying wrote:
v2:
- Export __get_user_pages, because we need other get_user_pages variants too.
[PATCH -v2 1/3] mm, export __get_user_pages
[PATCH -v2 2/3] mm, Make __get_user_pages return -EHWPOISON for HWPOISON page
optionally
[PATCH -v2
On 02/03/2011 11:32 AM, Jan Kiszka wrote:
On 2011-02-03 09:18, Avi Kivity wrote:
On 02/02/2011 05:52 PM, Jan Kiszka wrote:
If there is no problem in the logic of this commit (and I do not see
one yet) then we somewhere miss kicking vcpu when interrupt, that should
be
handled,
On Thu, Feb 03, 2011 at 10:32:25AM +0100, Jan Kiszka wrote:
On 2011-02-03 09:18, Avi Kivity wrote:
On 02/02/2011 05:52 PM, Jan Kiszka wrote:
If there is no problem in the logic of this commit (and I do not see
one yet) then we somewhere miss kicking vcpu when interrupt, that should
On 2011-02-03 11:04, Marcelo Tosatti wrote:
On Thu, Feb 03, 2011 at 10:32:25AM +0100, Jan Kiszka wrote:
On 2011-02-03 09:18, Avi Kivity wrote:
On 02/02/2011 05:52 PM, Jan Kiszka wrote:
If there is no problem in the logic of this commit (and I do not see
one yet) then we somewhere miss
On 2011-02-03 11:01, Avi Kivity wrote:
On 02/03/2011 11:32 AM, Jan Kiszka wrote:
On 2011-02-03 09:18, Avi Kivity wrote:
On 02/02/2011 05:52 PM, Jan Kiszka wrote:
If there is no problem in the logic of this commit (and I do not see
one yet) then we somewhere miss kicking vcpu when
On Tue, Feb 01, 2011 at 06:34:50PM +0100, Jan Kiszka wrote:
On 2011-02-01 18:20, Anthony Liguori wrote:
On 02/01/2011 11:03 AM, Jan Kiszka wrote:
On 2011-02-01 17:53, Anthony Liguori wrote:
On 02/01/2011 10:36 AM, Jan Kiszka wrote:
On 2011-02-01 16:54, Chris Wright wrote:
On Tue, Feb 01, 2011 at 12:53:36PM -0500, Christoph Hellwig wrote:
On Tue, Feb 01, 2011 at 05:36:13PM +0100, Jan Kiszka wrote:
kvm_cpu_exec/kvm_run, and start wondering What needs to be done to
upstream so that qemu-kvm could use that implementation?. If they
differ, the reasons need to be
On 02/01/2011 06:53 PM, Christoph Hellwig wrote:
I'd really prefer to let you finish up all the major work that way
before starting massive revamping like the glib main loop.
Yes, the glib main loop is not going to go anywhere if it cannot be
applied to both qemu and qemu-kvm.
(And, I
On Sun, Jan 30, 2011, Avi Kivity wrote about Re: [PATCH 07/29] nVMX: Hold a
vmcs02 for each vmcs12:
..
+static int nested_create_current_vmcs(struct kvm_vcpu *vcpu)
+{
...
+if (vmx-nested.vmcs02_num= NESTED_MAX_VMCS)
+return -ENOMEM;
I asked to replace this by dropping the
On Tue, 2011-02-01 at 09:51 -0500, Rik van Riel wrote:
-static void yield_task_fair(struct rq *rq)
-{
- struct task_struct *curr = rq-curr;
- struct cfs_rq *cfs_rq = task_cfs_rq(curr);
- struct sched_entity *rightmost, *se = curr-se;
-
- /*
-* Are we the
On Tue, 2011-02-01 at 09:50 -0500, Rik van Riel wrote:
+bool __sched yield_to(struct task_struct *p, bool preempt)
+{
+ struct task_struct *curr = current;
+ struct rq *rq, *p_rq;
+ unsigned long flags;
+ bool yielded = 0;
+
+ local_irq_save(flags);
+
Hi,
I am observing severe backward time drift in a MS Windows Vista(tm)
guest running on a Fedora 14 KVM host. I can reproduce the problem
with the following steps:
1. Use 'vncviewer' to connect to the guest's desktop.
2. Click on the menu title bar of a window on the guest's desktop.
3. Move
code part 1
---
Introduces the '-hpet [device=none|present][,driftfix=none|slew]' option.
diff -up ./qemu-config.c.orig1 ./qemu-config.c
--- ./qemu-config.c.orig1 2011-01-21 23:34:47.0 +0100
+++ ./qemu-config.c 2011-02-01 19:38:26.665250920 +0100
@@ -255,6 +255,21
code part 2
---
Implements compensation of lost interrupts for HPET periodic timers.
diff -up ./hw/hpet.c.orig2 ./hw/hpet.c
--- ./hw/hpet.c.orig2 2011-01-21 23:34:47.0 +0100
+++ ./hw/hpet.c 2011-02-01 19:20:24.619247214 +0100
@@ -41,6 +41,13 @@
#define HPET_MSI_SUPPORT
On 02/03/2011 04:11 AM, Marcelo Tosatti wrote:
On Tue, Feb 01, 2011 at 06:34:50PM +0100, Jan Kiszka wrote:
On 2011-02-01 18:20, Anthony Liguori wrote:
On 02/01/2011 11:03 AM, Jan Kiszka wrote:
On 2011-02-01 17:53, Anthony Liguori wrote:
On 02/01/2011 10:36 AM,
On 2011-02-03 15:15, Gleb Natapov wrote:
On Thu, Feb 03, 2011 at 11:11:23AM +0100, Jan Kiszka wrote:
On 2011-02-03 11:04, Marcelo Tosatti wrote:
On Thu, Feb 03, 2011 at 10:32:25AM +0100, Jan Kiszka wrote:
On 2011-02-03 09:18, Avi Kivity wrote:
On 02/02/2011 05:52 PM, Jan Kiszka wrote:
If
On 01/27/2011 10:55 AM, Avi Kivity wrote:
... Using kvm-kmod allows you to run a newer kvm on an older kernel ...
ok thanks
Regarding this: I can't find the kmod version requirements for every KVM
version.
What happens if the kernel module version I'm running is too old for the
KVM I'm trying
On 02/03/2011 04:33 PM, Asdo wrote:
On 01/27/2011 10:55 AM, Avi Kivity wrote:
... Using kvm-kmod allows you to run a newer kvm on an older kernel ...
ok thanks
Regarding this: I can't find the kmod version requirements for every KVM
version.
I don't think there is an exhaustive list.
On 02/03/2011 06:36 AM, Paolo Bonzini wrote:
On 02/01/2011 06:53 PM, Christoph Hellwig wrote:
I'd really prefer to let you finish up all the major work that way
before starting massive revamping like the glib main loop.
Yes, the glib main loop is not going to go anywhere if it cannot be
Add the missing EOI broadcast from local APIC to the IOAPICs on
completion of level-triggered IRQs. This ensures that a still asserted
IRQ source properly re-triggers an APIC IRQ.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/apic.c |9 ++---
hw/ioapic.c | 43
Fix a few style issues and convert magic numbers into prober symbolic
constants, also fixing the wrong but unused IOAPIC_DM_SIPI value.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/ioapic.c | 177 +++---
1 files changed, 107
This is a guest modifiable state that must be saved/restored properly.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/ioapic.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/hw/ioapic.c b/hw/ioapic.c
index 443c579..c7019f5 100644
--- a/hw/ioapic.c
This series fixes the re-injection of level-triggered IRQs that are
still raised on APIC EOI, adds a must-have field to the vmstate of the
IOAPIC, and also aligns that vmstate with qemu-kvm.
I would recommend the whole series for 0.14, but at least patch 1 should
be applied.
Jan Kiszka (4):
The registers of real IOAPICs can be relocated during runtime (via
chipset registers). We don't support this yet, but qemu-kvm carries the
current base address in its version 2 vmstate.
To align both implementations for migratability, add the proper
infrastructure to accept initial as well as
Hello list
I know qemu-kvm versions from sourceforge are the stable kvm releases.
So I went there hoping to find a version maintainance policy like that
of the linux kernel, that is, the last number in the release version is
the patch level.
Usually in linux I go hunting for the last kernel
The interrupt injection logic looks something like
if an nmi is pending, and nmi injection allowed
inject nmi
if an nmi is pending
request exit on nmi window
the problem is that nmi is pending can be set asynchronously by
the PIT; if it happens to fire between the two if statements,
When we enable an NMI window, we ask for an IRET intercept, since
the IRET re-enables NMIs. However, the IRET intercept happens before
the instruction executes, while the NMI window architecturally opens
afterwards.
To compensate for this mismatch, we only open the NMI window in the
following
There are a couple of fairly severe problems with NMI on AMD, both triggered
with nmi_watchdog=1 in the guest and kvm ftrace in the host. One of the bug
leads to guest userspace crashes via spurious setting of EFLAGS.TF, while the
other leads to guest kernel hangs looping on the NMI handler's
On 02/03/2011 05:02 PM, Avi Kivity wrote:
When we enable an NMI window, we ask for an IRET intercept, since
the IRET re-enables NMIs. However, the IRET intercept happens before
the instruction executes, while the NMI window architecturally opens
afterwards.
To compensate for this mismatch, we
On 2011-02-03 16:02, Avi Kivity wrote:
The interrupt injection logic looks something like
if an nmi is pending, and nmi injection allowed
inject nmi
if an nmi is pending
request exit on nmi window
the problem is that nmi is pending can be set asynchronously by
the PIT; if it
On 2011-02-03 16:07, Avi Kivity wrote:
On 02/03/2011 05:02 PM, Avi Kivity wrote:
When we enable an NMI window, we ask for an IRET intercept, since
the IRET re-enables NMIs. However, the IRET intercept happens before
the instruction executes, while the NMI window architecturally opens
On 2011-02-03 14:43, Ulrich Obergfell wrote:
Hi,
I am observing severe backward time drift in a MS Windows Vista(tm)
guest running on a Fedora 14 KVM host. I can reproduce the problem
with the following steps:
1. Use 'vncviewer' to connect to the guest's desktop.
2. Click on the menu
On 02/03/2011 05:21 PM, Jan Kiszka wrote:
So what would be a better fix? We could unconditionally single step on
iret_interception() which would fix the problem at the cost of making
NMIs less efficient (three exits instead of two). We could emulate the
IRET (doubling kvm's code and
On 2011-02-03 16:30, Avi Kivity wrote:
On 02/03/2011 05:21 PM, Jan Kiszka wrote:
So what would be a better fix? We could unconditionally single step on
iret_interception() which would fix the problem at the cost of making
NMIs less efficient (three exits instead of two). We could emulate
On Thu, 2011-02-03 at 08:13 +0200, Michael S. Tsirkin wrote:
Initial TCP_STREAM performance results I got for guest to local
host
4.2Gb/s for 1K message size, (vs. 2.5Gb/s)
6.2Gb/s for 2K message size, and (vs. 3.8Gb/s)
9.8Gb/s for 4K message size. (vs.5.xGb/s)
What is the average
On 02/03/2011 05:55 PM, Jan Kiszka wrote:
What's an interrupt window without IRET interception?
I don't the details, but I thought you could get something like an
interrupt-window-open interception by (fake-)injecting an IRQ and
intercepting on VIRQ acceptance. That will not work if
On Wed, Feb 02, 2011 at 07:16:20AM -0500, Glauber Costa wrote:
If the machine is stopped, we should not record two different tsc values
upon a save operation. The same problem happens with kvmclock.
But kvmclock is taking a different diretion, being now seen as a separate
device. Since this
On 12/06/2010 12:53 PM, Roedel, Joerg wrote:
Joerg, if this looks right to you, please integrate it into your emulator
intercept patchset.
Will do. It will probably take until January before I am done with this.
There is some other stuff to do first.
Any progress? I'd like to do some
On 2011-02-03 16:58, Avi Kivity wrote:
On 02/03/2011 05:55 PM, Jan Kiszka wrote:
What's an interrupt window without IRET interception?
I don't the details, but I thought you could get something like an
interrupt-window-open interception by (fake-)injecting an IRQ and
intercepting on VIRQ
On Thu, Feb 03, 2011 at 11:07:57AM -0500, Avi Kivity wrote:
On 12/06/2010 12:53 PM, Roedel, Joerg wrote:
Joerg, if this looks right to you, please integrate it into your emulator
intercept patchset.
Will do. It will probably take until January before I am done with this.
There is
On Thu, Feb 03, 2011 at 07:58:00AM -0800, Shirley Ma wrote:
On Thu, 2011-02-03 at 08:13 +0200, Michael S. Tsirkin wrote:
Initial TCP_STREAM performance results I got for guest to local
host
4.2Gb/s for 1K message size, (vs. 2.5Gb/s)
6.2Gb/s for 2K message size, and (vs. 3.8Gb/s)
On 02/03/2011 06:14 PM, Jan Kiszka wrote:
On 2011-02-03 16:58, Avi Kivity wrote:
On 02/03/2011 05:55 PM, Jan Kiszka wrote:
What's an interrupt window without IRET interception?
I don't the details, but I thought you could get something like an
interrupt-window-open interception by
On 2011-02-03 17:20, Avi Kivity wrote:
On 02/03/2011 06:14 PM, Jan Kiszka wrote:
On 2011-02-03 16:58, Avi Kivity wrote:
On 02/03/2011 05:55 PM, Jan Kiszka wrote:
What's an interrupt window without IRET interception?
I don't the details, but I thought you could get something like an
On 02/03/2011 06:18 PM, Roedel, Joerg wrote:
On Thu, Feb 03, 2011 at 11:07:57AM -0500, Avi Kivity wrote:
On 12/06/2010 12:53 PM, Roedel, Joerg wrote:
Joerg, if this looks right to you, please integrate it into your
emulator
intercept patchset.
Will do. It will probably
On Thu, Feb 3, 2011 at 2:55 PM, Jan Kiszka jan.kis...@siemens.com wrote:
The registers of real IOAPICs can be relocated during runtime (via
chipset registers). We don't support this yet, but qemu-kvm carries the
current base address in its version 2 vmstate.
To align both implementations for
On Thu, 2011-02-03 at 18:20 +0200, Michael S. Tsirkin wrote:
Just a thought: does it help to make tx queue len of the
virtio device smaller?
Yes, that what I did before, reducing txqueuelen will cause qdisc dropp
the packet early, But it's hard to control by using tx queuelen for
performance
On Thu, Feb 3, 2011 at 5:18 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:03, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 2:55 PM, Jan Kiszka jan.kis...@siemens.com wrote:
The registers of real IOAPICs can be relocated during runtime (via
chipset registers). We don't support this
On Tue, Feb 01, 2011 at 01:27:15PM +0100, Jan Kiszka wrote:
This warning was once used for debugging QEMU user space. Though
uncommon, it is actually possible to send an INIT request to a running
VCPU. So better drop this warning before someone misuses it to flood
kernel logs this way.
On 2011-02-03 18:36, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:18 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:03, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 2:55 PM, Jan Kiszka jan.kis...@siemens.com wrote:
The registers of real IOAPICs can be relocated during runtime (via
On Thu, Feb 3, 2011 at 5:43 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:36, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:18 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:03, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 2:55 PM, Jan Kiszka jan.kis...@siemens.com
On 2011-02-03 18:54, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:43 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:36, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:18 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:03, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 2:55
This is a guest modifiable state that must be saved/restored properly.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/ioapic.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/hw/ioapic.c b/hw/ioapic.c
index 443c579..edf99cc 100644
---
Second round, addressing review comments and fixing (still unused) code:
- pass IOAPIC default address as property
- properly update MMIO mapping after vmload
- switch post_load callback for all fix-ups
Jan Kiszka (4):
ioapic: Implement EOI handling for level-triggered IRQs
ioapic:
Fix a few style issues and convert magic numbers into prober symbolic
constants, also fixing the wrong but unused IOAPIC_DM_SIPI value.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/ioapic.c | 177 +++---
1 files changed, 107
Add the missing EOI broadcast from local APIC to the IOAPICs on
completion of level-triggered IRQs. This ensures that a still asserted
IRQ source properly re-triggers an APIC IRQ.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/apic.c |9 ++---
hw/ioapic.c | 43
The registers of real IOAPICs can be relocated during runtime (via
chipset registers). We don't support this yet, but qemu-kvm carries the
current base address in its version 2 vmstate.
To align both implementations for migratability, add the proper
infrastructure to accept initial as well as
On Thu, Feb 3, 2011 at 6:01 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:54, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:43 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:36, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:18 PM, Jan Kiszka jan.kis...@siemens.com
On 2011-02-03 20:01, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 6:01 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:54, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:43 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:36, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:18
On Thu, Feb 3, 2011 at 7:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 20:01, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 6:01 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:54, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:43 PM, Jan Kiszka jan.kis...@siemens.com
If the machine is stopped, we should not record two different tsc values
upon a save operation. The same problem happens with kvmclock.
But kvmclock is taking a different diretion, being now seen as a separate
device. Since this is unlikely to happen with the tsc, I am taking the
approach here of
On 2011-02-03 20:11, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 7:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 20:01, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 6:01 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 18:54, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 5:43
On Thu, Feb 3, 2011 at 7:25 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 20:11, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 7:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 20:01, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 6:01 PM, Jan Kiszka jan.kis...@siemens.com
On 2011-02-03 20:30, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 7:25 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 20:11, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 7:06 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-02-03 20:01, Blue Swirl wrote:
On Thu, Feb 3, 2011 at 6:01
On 02/03/2011 08:55 AM, Jan Kiszka wrote:
Add the missing EOI broadcast from local APIC to the IOAPICs on
completion of level-triggered IRQs. This ensures that a still asserted
IRQ source properly re-triggers an APIC IRQ.
Signed-off-by: Jan Kiszkajan.kis...@siemens.com
---
hw/apic.c |9
On 02/03/2011 09:28 AM, Jan Kiszka wrote:
On 2011-02-03 14:43, Ulrich Obergfell wrote:
Hi,
I am observing severe backward time drift in a MS Windows Vista(tm)
guest running on a Fedora 14 KVM host. I can reproduce the problem
with the following steps:
1. Use 'vncviewer' to connect to the
On 2011-02-03 21:07, Anthony Liguori wrote:
On 02/03/2011 09:28 AM, Jan Kiszka wrote:
On 2011-02-03 14:43, Ulrich Obergfell wrote:
Hi,
I am observing severe backward time drift in a MS Windows Vista(tm)
guest running on a Fedora 14 KVM host. I can reproduce the problem
with the
From: Jan Kiszka jan.kis...@siemens.com
Add the missing EOI broadcast from local APIC to the IOAPICs on
completion of level-triggered IRQs. This ensures that a still asserted
IRQ source properly re-triggers an APIC IRQ.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/apic.c |9
From: Jan Kiszka jan.kis...@siemens.com
This is a guest modifiable state that must be saved/restored properly.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/ioapic.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/hw/ioapic.c b/hw/ioapic.c
index
From: Jan Kiszka jan.kis...@siemens.com
Fix a few style issues and convert magic numbers into prober symbolic
constants, also fixing the wrong but unused IOAPIC_DM_SIPI value.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/ioapic.c | 177
Third round, primarily dropping IOAPIC relocation support:
- replace IOAPIC relocation with a qemu-kvm compat patch
- fix ioapic_eoi_broadcast name
Note that, even if we do not include the base address explicitly in the
IOAPIC state, we will still need to read it out for KVM in-kernel
support
From: Jan Kiszka jan.kis...@siemens.com
qemu-kvm carries the IOAPIC base address in its v2 vmstate. We only
support the default base address so far, and saving even that in the
device state was rejected.
Add a padding field to be able to read qemu-kvm's old state, but
increase our version to 3,
Hi,
Here are the SeaBIOS parts that initialize the AMD IOMMU.
I was told an ack from other QEMU/KVM developers would be nice, so please have
a look.
Thanks,
Eduard
Eduard - Gabriel Munteanu (3):
pci: add pci_find_capability() helper
AMD IOMMU support
Clarify address space
pci_find_capability() looks up a given capability and returns its
offset. This is needed by AMD IOMMU initialization code.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
src/pci.c | 15 +++
src/pci.h |1 +
2 files changed, 16 insertions(+), 0
This initializes the AMD IOMMU and creates ACPI tables for it.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
src/acpi.c | 84
src/config.h |3 ++
src/pci_ids.h |1 +
src/pci_regs.h |1 +
The Buildbot has detected a new failure of default_i386_debian_5_0 on qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_debian_5_0/builds/743
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_2
The Buildbot has detected a new failure of default_i386_out_of_tree on qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_out_of_tree/builds/680
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build: b1_qemu_kvm_2
On 02/03/2011 03:24 PM, Jan Kiszka wrote:
On 2011-02-03 21:07, Anthony Liguori wrote:
On 02/03/2011 09:28 AM, Jan Kiszka wrote:
On 2011-02-03 14:43, Ulrich Obergfell wrote:
Hi,
I am observing severe backward time drift in a MS Windows Vista(tm)
guest running on a Fedora 14
On Fri, Feb 04, 2011 at 01:24:14AM +0200, Eduard - Gabriel Munteanu wrote:
This initializes the AMD IOMMU and creates ACPI tables for it.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
src/acpi.c | 84
The Buildbot has detected a new failure of disable_kvm_i386_debian_5_0 on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_debian_5_0/builds/732
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
The Buildbot has detected a new failure of disable_kvm_i386_out_of_tree on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_out_of_tree/builds/680
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
The Buildbot has detected a new failure of next-ppc64 on kvm.
Full details are available at:
http://buildbot.b1-systems.de/kvm/builders/next-ppc64/builds/68
Buildbot URL: http://buildbot.b1-systems.de/kvm/
Buildslave for this Build: b1_kvm_1
Build Reason: The Nightly scheduler named
On 02.02.2011, at 23:34, Yoder Stuart-B08248 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Wednesday, February 02, 2011 3:34 PM
To: Yoder Stuart-B08248
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; qemu-de...@nongnu.org
Subject: Re: RFC: New
88 matches
Mail list logo
