It is available at:
http://wiki.qemu.org/Features/Livebackup
It is a work in progress, and I will continue to add control flow
diagrams, and other illustrative content over the next week or so.
Feedback is welcome.
Thanks,
Jagane
--
To unsubscribe from this list: send the line unsubscribe kvm
Hi!
We're currently having issues while trying to make the KVM in-kernel
lapic to work. There seems to be a KVM_SET_LAPIC ioctl() for this but
it's not documented in Documentation/kvm/api.txt. Are there other
ioctls we should know about? We're using KVM_CREATE_IRQCHIP obviously.
On 04/26/2011 04:19 PM, Jan Kiszka wrote:
I've still plans to consolidate MSI-X mask notifiers and KVM hooks, but
that can wait until we go upstream.
This version still makes classic MSI usable in irqchip mode, now not
only for PCI devices (AHCI, HDA) but also for the HPET (with msi=on).
On 04/27/2011 10:23 AM, Pekka Enberg wrote:
Hi!
We're currently having issues while trying to make the KVM in-kernel
lapic to work. There seems to be a KVM_SET_LAPIC ioctl() for this but
it's not documented in Documentation/kvm/api.txt. Are there other
ioctls we should know about? We're using
On 04/26/2011 06:55 PM, Paul E. McKenney wrote:
On Tue, Apr 26, 2011 at 03:38:24PM +0300, Gleb Natapov wrote:
Hello Paul,
I have a question about RCU + KVM. KVM does not hold any references to RCU
protected data when it switches CPU into a guest mode. In fact switching
to a guest mode
On 04/26/2011 07:13 PM, Michael Tokarev wrote:
This change fixes a long-standing immediate crash (memory corruption
and abort in glibc malloc code) in migration on 32bits.
snip
Applied, thanks. Very good catch indeed.
--
error compiling committee.c: too many arguments to function
--
To
On 04/26/2011 06:39 PM, Randy Dunlap wrote:
On Tue, 26 Apr 2011 20:26:05 +1000 Stephen Rothwell wrote:
Hi all,
The kernel.org mirroring is being very slow today.
on i386:
ERROR: __get_user_X [arch/x86/kvm/kvm.ko] undefined!
Thanks, this has already been noted; we'll fix this shortly.
On 04/23/2011 01:05 PM, Jan Kiszka wrote:
The promised cleanups.
Jan Kiszka (3):
qemu-kvm: pci-assign: Clean up free_assigned_device
qemu-kvm: pci-assign: Remove dead code from assigned_dev_iomem_map
qemu-kvm: pci-assign: Consolidate and fix slow mmio region mappings
Applied,
On Wed, Apr 27, 2011 at 10:37 AM, Avi Kivity a...@redhat.com wrote:
KVM_SET_GSI_ROUTING - manipulate the routes between irq lines and the IOAPIC
and PIC; also maintain virtual routes for message signalled interrupts (MSI)
Is this mandatory to set up manually for lapic to work or does KVM set
On Wed, Apr 27, 2011 at 10:47:04AM +0300, Avi Kivity wrote:
On 04/26/2011 06:55 PM, Paul E. McKenney wrote:
On Tue, Apr 26, 2011 at 03:38:24PM +0300, Gleb Natapov wrote:
Hello Paul,
I have a question about RCU + KVM. KVM does not hold any references to RCU
protected data when it
On 04/27/2011 10:53 AM, Pekka Enberg wrote:
On Wed, Apr 27, 2011 at 10:37 AM, Avi Kivitya...@redhat.com wrote:
KVM_SET_GSI_ROUTING - manipulate the routes between irq lines and the IOAPIC
and PIC; also maintain virtual routes for message signalled interrupts (MSI)
Is this mandatory to set
On Wed, Apr 27, 2011 at 11:20:29AM +0300, Avi Kivity wrote:
On 04/27/2011 10:53 AM, Pekka Enberg wrote:
On Wed, Apr 27, 2011 at 10:37 AM, Avi Kivitya...@redhat.com wrote:
KVM_SET_GSI_ROUTING - manipulate the routes between irq lines and the
IOAPIC
and PIC; also maintain virtual routes
On 04/25/2011 08:55 AM, brill...@viatech.com.cn wrote:
On 04/21/2011 01:06 PM, brill...@viatech.com.cn wrote:
So,the conclusion is:
Only VIA C7 CPUs have dependency on EFLAGS[30], but they do
not support VT-X technology, so kvm can not run on it and the issue
about EFLAGS[30]
On 04/27/2011 11:26 AM, Gleb Natapov wrote:
On Wed, Apr 27, 2011 at 11:20:29AM +0300, Avi Kivity wrote:
On 04/27/2011 10:53 AM, Pekka Enberg wrote:
On Wed, Apr 27, 2011 at 10:37 AM, Avi Kivitya...@redhat.com wrote:
KVM_SET_GSI_ROUTING - manipulate the routes between irq lines and the
On 04/24/2011 03:24 PM, Jan Kiszka wrote:
This would cause IRQs to be delivered even if the PIT is masked, no?
I checked the patch and our code again: NMI watchdog masking is managed
via arch.vapics_in_nmi_mode and by re-checking the per-APIC mask
situation in kvm_apic_local_deliver when
On 2011-04-27 09:27, Avi Kivity wrote:
On 04/26/2011 04:19 PM, Jan Kiszka wrote:
I've still plans to consolidate MSI-X mask notifiers and KVM hooks, but
that can wait until we go upstream.
This version still makes classic MSI usable in irqchip mode, now not
only for PCI devices (AHCI, HDA)
On 04/27/2011 12:00 PM, Jan Kiszka wrote:
On 2011-04-27 09:27, Avi Kivity wrote:
On 04/26/2011 04:19 PM, Jan Kiszka wrote:
I've still plans to consolidate MSI-X mask notifiers and KVM hooks, but
that can wait until we go upstream.
This version still makes classic MSI usable in irqchip
On 2011-04-27 11:04, Avi Kivity wrote:
On 04/27/2011 12:00 PM, Jan Kiszka wrote:
On 2011-04-27 09:27, Avi Kivity wrote:
On 04/26/2011 04:19 PM, Jan Kiszka wrote:
I've still plans to consolidate MSI-X mask notifiers and KVM hooks, but
that can wait until we go upstream.
This version
On 04/27/2011 12:06 PM, Jan Kiszka wrote:
We can simply drop all route entries that are used exclusively in qemu
(i.e. not bound to an irqfd) and let the cache rebuild itself.
When should they be dropped?
Whenever we need to allocate a new routing entry, but cannot because it
is full.
On 04/26/2011 04:19 PM, Jan Kiszka wrote:
I've still plans to consolidate MSI-X mask notifiers and KVM hooks, but
that can wait until we go upstream.
This version still makes classic MSI usable in irqchip mode, now not
only for PCI devices (AHCI, HDA) but also for the HPET (with msi=on).
On 2011-04-27 11:14, Avi Kivity wrote:
On 04/27/2011 12:06 PM, Jan Kiszka wrote:
We can simply drop all route entries that are used exclusively in qemu
(i.e. not bound to an irqfd) and let the cache rebuild itself.
When should they be dropped?
Whenever we need to allocate a new routing
On 2011-04-27 11:34, Avi Kivity wrote:
On 04/26/2011 04:19 PM, Jan Kiszka wrote:
I've still plans to consolidate MSI-X mask notifiers and KVM hooks, but
that can wait until we go upstream.
This version still makes classic MSI usable in irqchip mode, now not
only for PCI devices (AHCI, HDA)
On Sat, Apr 23, 2011 at 12:23:37PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Remove the premature return from msix_vector_use if the vector was
already in use, this could cause usage counter imbalances. In contrast,
the check for msix_entry_used on deletion was
On 2011-04-27 10:55, Avi Kivity wrote:
On 04/24/2011 03:24 PM, Jan Kiszka wrote:
This would cause IRQs to be delivered even if the PIT is masked, no?
I checked the patch and our code again: NMI watchdog masking is managed
via arch.vapics_in_nmi_mode and by re-checking the per-APIC mask
On 04/27/2011 02:21 PM, Jan Kiszka wrote:
On 2011-04-27 11:14, Avi Kivity wrote:
On 04/27/2011 12:06 PM, Jan Kiszka wrote:
We can simply drop all route entries that are used exclusively in qemu
(i.e. not bound to an irqfd) and let the cache rebuild itself.
When should they be
On 2011-04-26 18:13, Michael Tokarev wrote:
This change fixes a long-standing immediate crash (memory corruption
and abort in glibc malloc code) in migration on 32bits.
The bug is present since this commit:
commit 692d9aca97b865b0f7903565274a52606910f129
Author: Bruce Rogers
On 04/27/2011 02:39 PM, Jan Kiszka wrote:
Yeah, better use this version of patch 8.
Replaced, going through the mill again.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 04/27/2011 03:17 PM, Jan Kiszka wrote:
+ */
+size = ALIGN(((mem-memory_size) TARGET_PAGE_BITS),
/*HOST_LONG_BITS*/ 64) / 8;
-ELINETOOLONG
-ETABSALERT
Once fixed, it should also be queued in uq/master.
Right. I fixed it in my tree, no need to resubmit.
--
error
On Tue, Apr 26, 2011 at 08:55:28AM -0700, Paul E. McKenney wrote:
On Tue, Apr 26, 2011 at 03:38:24PM +0300, Gleb Natapov wrote:
Hello Paul,
I have a question about RCU + KVM. KVM does not hold any references to RCU
protected data when it switches CPU into a guest mode. In fact switching
On Sat, Apr 23, 2011 at 12:23:38PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Testing support and allocating a GSI for an MSI message is required both
for MSI and MSI-X. At this chance, drop the aging version warning.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Hi there,
is it possible to announce the kvm-guest (i.e. winxp) some arbitrary
vendor-id's in a way, that the win-client starts to install the driver
for this card?
I.e. the RTL8111/8168B PCI Express Gigabit Ethernet Card has the
vendor-id 10ec:8168 (taken from lspci -nn), so if i give this ID
On 2011-04-27 14:54, Michael S. Tsirkin wrote:
On Sat, Apr 23, 2011 at 12:23:38PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Testing support and allocating a GSI for an MSI message is required both
for MSI and MSI-X. At this chance, drop the aging version warning.
On 2011-04-27 14:12, Avi Kivity wrote:
On 04/27/2011 02:21 PM, Jan Kiszka wrote:
On 2011-04-27 11:14, Avi Kivity wrote:
On 04/27/2011 12:06 PM, Jan Kiszka wrote:
We can simply drop all route entries that are used exclusively in qemu
(i.e. not bound to an irqfd) and let the cache rebuild
On Sat, Apr 23, 2011 at 12:23:40PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This adds the required bits to map classic MSI vectors on KVM IRQ
routing entries and deliver them via the irqchip if enabled.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
On Sat, Apr 23, 2011 at 12:23:35PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This structure will be used for legacy MSI as well and will become part
of the KVM API.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
I'd like KVMMSIMessage better. struct
On Wed, Apr 27, 2011 at 03:29:15PM +0200, Jan Kiszka wrote:
On 2011-04-27 14:54, Michael S. Tsirkin wrote:
On Sat, Apr 23, 2011 at 12:23:38PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Testing support and allocating a GSI for an MSI message is required both
for MSI
On 04/27/2011 04:31 PM, Jan Kiszka wrote:
A hash table is indeed overcomplicated for this.
How about a replacement for stl_phys() for the MSI case:
- stl_phys(timer-fsb 32, timer-fsb 0x);
+ msi_stl_phys(timer-fsb 32, timer-fsb 0x,
On Wed, Apr 27, 2011 at 03:31:16PM +0200, Jan Kiszka wrote:
On 2011-04-27 14:12, Avi Kivity wrote:
On 04/27/2011 02:21 PM, Jan Kiszka wrote:
On 2011-04-27 11:14, Avi Kivity wrote:
On 04/27/2011 12:06 PM, Jan Kiszka wrote:
We can simply drop all route entries that are used exclusively
On 2011-04-27 15:39, Avi Kivity wrote:
On 04/27/2011 04:31 PM, Jan Kiszka wrote:
A hash table is indeed overcomplicated for this.
How about a replacement for stl_phys() for the MSI case:
- stl_phys(timer-fsb 32, timer-fsb 0x);
+ msi_stl_phys(timer-fsb
On 04/27/2011 04:54 PM, Jan Kiszka wrote:
I was planning for a MSI short-path anyway. Also for TCG, it's pointless
to go through lengthy stl_phys if we know it's supposed to be an MSI
message.
I don't think tcg will see much benefit; the decoding path through
hw/apic.c isn't
On Wed, Apr 27, 2011 at 03:54:36PM +0200, Jan Kiszka wrote:
On 2011-04-27 15:39, Avi Kivity wrote:
On 04/27/2011 04:31 PM, Jan Kiszka wrote:
A hash table is indeed overcomplicated for this.
How about a replacement for stl_phys() for the MSI case:
- stl_phys(timer-fsb
On 2011-04-27 15:34, Michael S. Tsirkin wrote:
On Sat, Apr 23, 2011 at 12:23:35PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This structure will be used for legacy MSI as well and will become part
of the KVM API.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
I'd
On 2011-04-27 16:02, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 03:54:36PM +0200, Jan Kiszka wrote:
On 2011-04-27 15:39, Avi Kivity wrote:
On 04/27/2011 04:31 PM, Jan Kiszka wrote:
A hash table is indeed overcomplicated for this.
How about a replacement for stl_phys() for the MSI
On Wed, Apr 27, 2011 at 05:01:09PM +0300, Avi Kivity wrote:
On 04/27/2011 04:54 PM, Jan Kiszka wrote:
I was planning for a MSI short-path anyway. Also for TCG, it's pointless
to go through lengthy stl_phys if we know it's supposed to be an MSI
message.
I don't think tcg will see
On Wed, Apr 27, 2011 at 04:10:04PM +0200, Jan Kiszka wrote:
Another issue is the reverse: regular memory address can be put
in the MSIX/MSI field and the result should be a regular memory
write.
Yes, that's a separate issue: Requests issued by the CPUs have to be
told apart from those
On Wed, Apr 27, 2011 at 01:39:05PM +0200, Jan Kiszka wrote:
On 2011-04-27 11:34, Avi Kivity wrote:
On 04/26/2011 04:19 PM, Jan Kiszka wrote:
I've still plans to consolidate MSI-X mask notifiers and KVM hooks, but
that can wait until we go upstream.
This version still makes classic MSI
On Apr 26, 2011, at 11:51 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-04-26 16:24, 大村 圭 wrote:
2011/4/25 Jan Kiszka jan.kis...@web.de:
On 2011-04-25 13:00, OHMURA Kei wrote:
From: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Record mmio write event to replay it upon failover.
On Apr 27, 2011, at 2:51 PM, Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
wrote:
What kind of mmio should be traced here, device or CPU originated? Or both?
Jan
To let Kemari replay outputs upon failover, tracing CPU originated
mmio (specifically write requests) should be
On 2011-04-27 16:14, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 04:10:04PM +0200, Jan Kiszka wrote:
Another issue is the reverse: regular memory address can be put
in the MSIX/MSI field and the result should be a regular memory
write.
Yes, that's a separate issue: Requests issued by
On 2011-04-27 16:16, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 01:39:05PM +0200, Jan Kiszka wrote:
On 2011-04-27 11:34, Avi Kivity wrote:
On 04/26/2011 04:19 PM, Jan Kiszka wrote:
I've still plans to consolidate MSI-X mask notifiers and KVM hooks, but
that can wait until we go
On 04/27/2011 05:04 PM, Jan Kiszka wrote:
I put kvm_msix_message in pci.h to avoid having every pci device pull in
kvm.h
is anything wrong with that? Maybe just rename it to make it generic
for msi and leave if where it is.
kvm.h shall provide kvm related types, not some unrelated
On 2011-04-27 16:29, Avi Kivity wrote:
On 04/27/2011 05:04 PM, Jan Kiszka wrote:
I put kvm_msix_message in pci.h to avoid having every pci device pull in
kvm.h
is anything wrong with that? Maybe just rename it to make it generic
for msi and leave if where it is.
kvm.h shall provide
On Wed, Apr 27, 2011 at 04:28:56PM +0200, Jan Kiszka wrote:
On 2011-04-27 16:16, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 01:39:05PM +0200, Jan Kiszka wrote:
On 2011-04-27 11:34, Avi Kivity wrote:
On 04/26/2011 04:19 PM, Jan Kiszka wrote:
I've still plans to consolidate MSI-X
On Wed, 27 Apr 2011 09:54:34 +0800
Lai Jiangshan la...@cn.fujitsu.com wrote:
On 04/26/2011 09:29 PM, Anthony Liguori wrote:
On 04/26/2011 08:26 AM, Luiz Capitulino wrote:
On Thu, 21 Apr 2011 11:23:54 +0800
Lai Jiangshanla...@cn.fujitsu.com wrote:
Hi, Anthony Liguori
Any
On Wed, Apr 27, 2011 at 04:04:44PM +0200, Jan Kiszka wrote:
On 2011-04-27 15:34, Michael S. Tsirkin wrote:
On Sat, Apr 23, 2011 at 12:23:35PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This structure will be used for legacy MSI as well and will become part
of the
On Wed, Apr 27, 2011 at 05:29:10PM +0300, Avi Kivity wrote:
On 04/27/2011 05:04 PM, Jan Kiszka wrote:
I put kvm_msix_message in pci.h to avoid having every pci device pull in
kvm.h
is anything wrong with that? Maybe just rename it to make it generic
for msi and leave if where it
On 2011-04-27 16:30, Michael S. Tsirkin wrote:
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -34,6 +34,7 @@
#include device-assignment.h
#include qemu-objects.h
#include range.h
+#include msi.h
//#define DEBUG_PCI
#ifdef DEBUG_PCI
@@ -342,6 +343,7 @@ static int get_pci_config_device(QEMUFile
On 04/27/2011 05:30 PM, Jan Kiszka wrote:
On 2011-04-27 16:29, Avi Kivity wrote:
On 04/27/2011 05:04 PM, Jan Kiszka wrote:
I put kvm_msix_message in pci.h to avoid having every pci device pull in
kvm.h
is anything wrong with that? Maybe just rename it to make it generic
for msi and
On 2011-04-27 15:31, Michael S. Tsirkin wrote:
On Sat, Apr 23, 2011 at 12:23:40PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This adds the required bits to map classic MSI vectors on KVM IRQ
routing entries and deliver them via the irqchip if enabled.
Signed-off-by:
On 2011-04-27 16:40, Avi Kivity wrote:
On 04/27/2011 05:30 PM, Jan Kiszka wrote:
On 2011-04-27 16:29, Avi Kivity wrote:
On 04/27/2011 05:04 PM, Jan Kiszka wrote:
I put kvm_msix_message in pci.h to avoid having every pci device pull
in kvm.h
is anything wrong with that? Maybe just
On 2011-04-27 16:19, Yoshiaki Tamura wrote:
Hi Jan,
Indeed Kemari is for KVM, so moving to kvm-all.c seems to be reasonable.
However, I would like to have this feature general rather than locking up
only in KVM.
Could you describe the difference between KVM and TCG in processing mmio,
On Wed, Apr 27, 2011 at 04:39:53PM +0200, Jan Kiszka wrote:
On 2011-04-27 16:30, Michael S. Tsirkin wrote:
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -34,6 +34,7 @@
#include device-assignment.h
#include qemu-objects.h
#include range.h
+#include msi.h
//#define DEBUG_PCI
#ifdef
On 2011-04-27 17:09, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 04:39:53PM +0200, Jan Kiszka wrote:
On 2011-04-27 16:30, Michael S. Tsirkin wrote:
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -34,6 +34,7 @@
#include device-assignment.h
#include qemu-objects.h
#include range.h
+#include
On Wed, Apr 27, 2011 at 05:21:43PM +0200, Jan Kiszka wrote:
On 2011-04-27 17:09, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 04:39:53PM +0200, Jan Kiszka wrote:
On 2011-04-27 16:30, Michael S. Tsirkin wrote:
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -34,6 +34,7 @@
#include
On 2011-04-27 18:02, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 05:21:43PM +0200, Jan Kiszka wrote:
On 2011-04-27 17:09, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 04:39:53PM +0200, Jan Kiszka wrote:
On 2011-04-27 16:30, Michael S. Tsirkin wrote:
--- a/hw/pci.c
+++ b/hw/pci.c
On Wed, Apr 27, 2011 at 06:20:52PM +0200, Jan Kiszka wrote:
On 2011-04-27 18:02, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 05:21:43PM +0200, Jan Kiszka wrote:
On 2011-04-27 17:09, Michael S. Tsirkin wrote:
On Wed, Apr 27, 2011 at 04:39:53PM +0200, Jan Kiszka wrote:
On 2011-04-27
On Tue, 2011-04-19 at 13:06 +0200, Jan Kiszka wrote:
kvmclock is represented by two feature bits. Therefore, lookup_feature
needs to continue its search even after the first match. Enhance it
accordingly and switch to a bool return type at this chance.
Signed-off-by: Jan Kiszka
Ok guys, we did it:
http://autotest.kernel.org/changeset/5328
http://autotest.kernel.org/changeset/5329
http://autotest.kernel.org/changeset/5330
http://autotest.kernel.org/changeset/5331
http://autotest.kernel.org/changeset/5332
http://autotest.kernel.org/changeset/5333
On 04/26/11 02:19, Avi Kivity wrote:
On 04/25/2011 08:49 PM, David Ahern wrote:
There are several copies.
qemu's virtio-net implementation incurs a copy on tx and on rx when
calling the kernel; in addition there is also an internal copy:
/* copy in packet. ugh */
Sorry for being late to send.
Making a PAE guest took longer than I expected.
The test was done before unlikely annotation was added.
But I did compile-test after adding unlikely on x86_32.
Thanks,
Takuya
Test conditions:
On x86_32: PAE/non-PAE Linux guest
On x86_64: Usual 64 guest
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Fix regression introduced by
commit e30d2a170506830d5eef5e9d7990c5aedf1b0a51
KVM: MMU: Optimize guest page table walk
On x86_32, get_user() does not support 64-bit values and we fail to
build KVM at the point of 64-bit paging.
This patch
On Wed, Apr 27, 2011 at 10:47:04AM +0300, Avi Kivity wrote:
On 04/26/2011 06:55 PM, Paul E. McKenney wrote:
On Tue, Apr 26, 2011 at 03:38:24PM +0300, Gleb Natapov wrote:
Hello Paul,
I have a question about RCU + KVM. KVM does not hold any references to RCU
protected data when it
On Wed, Apr 27, 2011 at 03:41:41PM +0300, Gleb Natapov wrote:
On Tue, Apr 26, 2011 at 08:55:28AM -0700, Paul E. McKenney wrote:
On Tue, Apr 26, 2011 at 03:38:24PM +0300, Gleb Natapov wrote:
Hello Paul,
I have a question about RCU + KVM. KVM does not hold any references to RCU
When KVM is running on VIA CPU with host cpu's model, the feautures of VIA CPU
will be passed into kvm guest by calling the CPUID instruction for Centaur.
Signed-off-by: BrillyWubrill...@viatech.com.cn
Signed-off-by: KaryJinkary...@viatech.com.cn
---
target-i386/cpu.h |3 +++
Avi Kivity a...@redhat.com writes:
On 04/24/2011 03:24 PM, Jan Kiszka wrote:
This would cause IRQs to be delivered even if the PIT is masked, no?
I checked the patch and our code again: NMI watchdog masking is managed
via arch.vapics_in_nmi_mode and by re-checking the per-APIC mask
Jason Wang writes:
Inspired by Krishna's patch (http://www.spinics.net/lists/kvm/msg52098.html)
and
Michael's suggestions. The following series adds the multiqueue support for
qemu and enable it for virtio-net (both userspace and vhost).
The aim for this series is to simplified the
Adds new QERR_UNSUPPORTED, converts nmi to inject-nmi and
make it supports qmp.
Lai Jiangshan (2):
qemu,qmp: QError: New QERR_UNSUPPORTED
qmp,inject-nmi: convert do_inject_nmi() to QObject
hmp-commands.hx | 21 +++--
monitor.c | 20 +---
qerror.c
New QERR_UNSUPPORTED for unsupported commands or requests.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 4855604..f905887 100644
--- a/qerror.c
+++
Make we can inject NMI via qemu-monitor-protocol.
We use inject-nmi for the command name, the meaning is clearer.
The behavior is cheanged to injecting NMI to all CPU which
simulates the Real hardware NMI button.
The command inject-nmi is only supported for x86 guest
currently, it will returns
79 matches
Mail list logo
