From: Christian Borntraeger borntrae...@de.ibm.com
Since KVM: Unify the delivery of IOAPIC and MSI interrupts
I get the following warnings:
CC [M] arch/s390/kvm/kvm-s390.o
In file included from arch/s390/kvm/kvm-s390.c:22:
include/linux/kvm_host.h:357: warning: 'struct kvm_ioapic' declared
From: Marcelo Tosatti mtosa...@redhat.com
Hide the internals of vcpu awakening / injection from the in-kernel
emulated timers. This makes future changes in this logic easier and
decreases the distance to more generic timer handling.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
From: Joerg Roedel joerg.roe...@amd.com
There is no reason to update the shadow pte here because the guest pte
is only changed to dirty state.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/paging_tmpl.h
From: Gleb Natapov g...@redhat.com
ioapic_deliver() and kvm_set_msi() have code duplication. Move
the code into ioapic_deliver_entry() function and call it from
both places.
Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git
From: Gleb Natapov g...@redhat.com
The new way does not require additional loop over vcpus to calculate
the one with lowest priority as one is chosen during delivery bitmap
construction.
Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git
From: Sheng Yang sh...@linux.intel.com
Gleb fixed bitmap ops usage in kvm_ioapic_get_delivery_bitmask.
Sheng merged two functions, as well as fixed several issues in
kvm_get_intr_delivery_bitmask
1. deliver_bitmask is a bitmap rather than a unsigned long intereger.
2. Lowest priority target
From: Gleb Natapov g...@redhat.com
Deliver interrupt during destination matching loop.
Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index fdd4c75..e1984cb 100644
---
From: Gleb Natapov g...@redhat.com
Use kvm_apic_match_dest() in kvm_get_intr_delivery_bitmask() instead
of duplicating the same code. Use kvm_get_intr_delivery_bitmask() in
apic_send_ipi() to figure out ipi destination instead of reimplementing
the logic.
Signed-off-by: Gleb Natapov
Anthony Liguori wrote:
Hi,
I'd like to announce the creation of a QEMU stable branch based on the
recent 0.10.0 release. You can access it via anonymous SVN via:
svn co svn://svn.savannah.nongnu.org/qemu/branches/stable_0_10_0
The stable branch will receive bug fixes from trunk until at
Glauber Costa wrote:
Matt T. Yourst noted that we're currently having a dumb
race for no reason in paravirtual wall clock. This is due
to the use of a static variable to hold the counting.
This can race with multiple guests reading wallclock
at the same time, since the static variable value
Joerg Roedel wrote:
We also need to do a remote tlb flush if the PSE bit changes. The
pte_pfn should also change if this bit changes but we can't rely on
that. So check this bit too to be on the save side.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
arch/x86/kvm/mmu.c |2 +-
1
Matthew Wilcox wrote:
On Tue, Feb 24, 2009 at 12:47:38PM +0200, Avi Kivity wrote:
Do those patches allow using a VF on the host (in other words, does the
kernel emulate config space accesses)?
SR-IOV hardware handles config space accesses to virtual functions. No
kernel changes
On Sun, Mar 08, 2009 at 04:30:16PM +0200, Avi Kivity wrote:
Matthew Wilcox wrote:
On Tue, Feb 24, 2009 at 12:47:38PM +0200, Avi Kivity wrote:
Do those patches allow using a VF on the host (in other words, does the
kernel emulate config space accesses)?
SR-IOV hardware handles config space
Avi Kivity wrote:
Anthony Liguori wrote:
Hi,
I'd like to announce the creation of a QEMU stable branch based on
the recent 0.10.0 release. You can access it via anonymous SVN via:
svn co svn://svn.savannah.nongnu.org/qemu/branches/stable_0_10_0
The stable branch will receive bug fixes
Avi Kivity wrote:
In this case, the branch ought to be called stable_0_10, no?
That's not a bad idea if everyone agrees that 0.10.1 is good stable
naming convention. I was hoping to have the first stable release about
2 weeks after the 0.10.0 release FWIW. There's already some good stuff
Hi
I'm running a kvm-84 host with 2.6.28.7. Guests are two lenny and one
Centos52 running a oracle db for test purpose.
The host is a C2D E8400 @ 3.00GHz, 4G. HostOS debian lenny x86_64.
I've lenny guests on on other hosts where I do not get this errors. I
assume it is the centos guest which
When I run the guest without the -vga option, everything is fine, the
resolutions isn't what I would like, but it works remarkably well.
If I add -vga std to the command I use to run the guest, then it
will crash when it attempts to start graphics. This will also happen
if I attempt to boot from
On Sun, Mar 08, 2009 at 09:01:09AM -0600, Matthew Wilcox wrote:
On Sun, Mar 08, 2009 at 04:30:16PM +0200, Avi Kivity wrote:
Matthew Wilcox wrote:
On Tue, Feb 24, 2009 at 12:47:38PM +0200, Avi Kivity wrote:
Do those patches allow using a VF on the host (in other words, does the
kernel
On Sunday 08 March 2009 22:30:16 Avi Kivity wrote:
Matthew Wilcox wrote:
On Tue, Feb 24, 2009 at 12:47:38PM +0200, Avi Kivity wrote:
Do those patches allow using a VF on the host (in other words, does the
kernel emulate config space accesses)?
SR-IOV hardware handles config space
On Monday 09 March 2009 11:42:05 Yang, Sheng wrote:
On Sunday 08 March 2009 22:30:16 Avi Kivity wrote:
Matthew Wilcox wrote:
On Tue, Feb 24, 2009 at 12:47:38PM +0200, Avi Kivity wrote:
Do those patches allow using a VF on the host (in other words, does
the kernel emulate config space
20 matches
Mail list logo
