On Sun, Aug 18, 2013 at 05:28:28PM +0200, Paolo Bonzini wrote:
Il 12/08/2013 21:56, Marcelo Tosatti ha scritto:
Commit 8c3ba334f8588e1d5099f8602cf01897720e0eca, KVM: x86: Raise the
hard VCPU count limit, upstream introduced the notion of a recommended
vcpu max limit.
Switch the order
1) Use recommended vcpu limit instead of max vcpu limit
2) Do not allow max_cpus max_vcpus
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
maxcpus, which specifies the maximum number of hotpluggable CPUs,
should not exceed KVM's vcpu limit.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: qemu/kvm-all.c
===
--- qemu.orig/kvm-all.c
+++ qemu/kvm-all.c
@@ -1391,6
Commit 8c3ba334f8588e1d5099f8602cf01897720e0eca, KVM: x86: Raise the
hard VCPU count limit, upstream introduced the notion of a recommended
vcpu max limit.
Switch the order so the recommended vcpu max limit is used instead of
the actual max vcpu limit.
Signed-off-by: Marcelo Tosatti mtosa
On Wed, Aug 07, 2013 at 12:06:49PM +0800, Xiao Guangrong wrote:
On 08/07/2013 09:48 AM, Marcelo Tosatti wrote:
On Tue, Jul 30, 2013 at 09:02:02PM +0800, Xiao Guangrong wrote:
Make sure we can see the writable spte before the dirt bitmap is visible
We do
== DOMAIN_MAX_PFN(domain-gaw)) {
free_pgtable_page(domain-pgd);
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Tue, Jul 30, 2013 at 09:02:02PM +0800, Xiao Guangrong wrote:
Make sure we can see the writable spte before the dirt bitmap is visible
We do this is for kvm_vm_ioctl_get_dirty_log() write-protects the spte based
on the dirty bitmap, we should ensure the writable spte can be found in rmap
On Tue, Jul 30, 2013 at 09:02:01PM +0800, Xiao Guangrong wrote:
Currently, kvm zaps the large spte if write-protected is needed, the later
read can fault on that spte. Actually, we can make the large spte readonly
instead of making them un-present, the page fault caused by read access can
be
On Fri, Aug 02, 2013 at 11:42:19PM +0800, Xiao Guangrong wrote:
On Aug 2, 2013, at 10:55 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jul 30, 2013 at 09:02:01PM +0800, Xiao Guangrong wrote:
Currently, kvm zaps the large spte if write-protected is needed, the later
read can
On Sat, Jul 27, 2013 at 07:47:49AM +, Zhanghaoyu (A) wrote:
hi all,
I met similar problem to these, while performing live migration or
save-restore test on the kvm platform (qemu:1.4.0, host:suse11sp2,
guest:suse11sp2), running tele-communication software suite in guest,
Peter,
Because x2apic support is emulated in software.
On Mon, Jul 22, 2013 at 08:36:05PM +0800, Peter Huang(Peng) wrote:
I traced the qemu process, and find out that host cpuid doesn't support
x2apic,
but VM interception seems enabled x2apic.
with function=1(bit 21 indicates x2apic)
On Sat, Jul 06, 2013 at 10:41:12AM +0300, Gleb Natapov wrote:
On Fri, Jul 05, 2013 at 04:16:55PM -0300, Marcelo Tosatti wrote:
MMIO/PIO emulation should be interrupted if the system is restarted.
Otherwise in progress IO emulation continues at the instruction pointer,
even after vcpus
MMIO/PIO emulation should be interrupted if the system is restarted.
Otherwise in progress IO emulation continues at the instruction pointer,
even after vcpus' IP has been modified by KVM_SET_REGS.
Use IP change as an indicator to reset MMIO/PIO emulation state.
Signed-off-by: Marcelo Tosatti
On Wed, Jul 03, 2013 at 12:44:01PM -0400, Don Zickus wrote:
On Fri, Jun 28, 2013 at 05:37:39PM -0300, Marcelo Tosatti wrote:
On Fri, Jun 28, 2013 at 10:12:15AM -0400, Don Zickus wrote:
On Thu, Jun 27, 2013 at 11:57:23PM -0300, Marcelo Tosatti wrote:
One possibility for a softlockup
On Wed, Jul 03, 2013 at 12:44:01PM -0400, Don Zickus wrote:
And why overcommitment is not a valid reason to generate a softlockup in
the first place ?
For the guest I don't believe it is. It isn't the guest's fault it
couldn't run processes. A warning should be scheduled on the host that
On Fri, Jun 28, 2013 at 10:12:15AM -0400, Don Zickus wrote:
On Thu, Jun 27, 2013 at 11:57:23PM -0300, Marcelo Tosatti wrote:
One possibility for a softlockup report in a Linux VM, is that the host
system is overcommitted to the point where the watchdog task is unable
to make progress
by the default),
and report this increment in the softlockup message.
Overcommitment is then indicated by a large stolen time increment,
accounting for more than, or for a significant percentage of the
softlockup threshold.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/kernel
On Sat, Jun 15, 2013 at 10:01:45PM +0400, Eugene Batalov wrote:
Due to unintialized kvmclock read KVM guest is hanging on SMP boot stage.
If unintialized memory contains fatal garbage then hang reproduction is 100%.
Unintialized memory is allocated by memblock_alloc. So the garbage values
On Mon, Jun 17, 2013 at 07:59:15PM +0800, Xiao Guangrong wrote:
Sorry for the delay reply since i was on vacation.
On 06/15/2013 10:22 AM, Takuya Yoshikawa wrote:
On Thu, 13 Jun 2013 21:08:21 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
On Fri, Jun 07, 2013 at 04:51:22PM +0800
run time, that is,
time which OS has been in a runnable state (see CLOCK_BOOTTIME).
Change kvmclock driver so as to save clock value when vm transitions
from runnable to stopped state, and to restore clock value from stopped
to runnable transition.
Signed-off-by: Marcelo Tosatti mtosa
On Tue, Jun 18, 2013 at 11:02:27AM +0200, Paolo Bonzini wrote:
Hi Marcelo, sorry for the late review.
Il 08/06/2013 04:00, Marcelo Tosatti ha scritto:
kvmclock should not count while vm is paused, because:
1) if the vm is paused for long periods, timekeeping
math can overflow while
Serialize RDTSC so its executed inside kvmclock_read
section.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=922285
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/x86/kvmclock.c b/x86/kvmclock.c
index 0624da3..5b831c5 100644
--- a/x86/kvmclock.c
+++ b/x86/kvmclock.c
On Fri, Jun 07, 2013 at 04:51:22PM +0800, Xiao Guangrong wrote:
Changelog:
V3:
All of these changes are from Gleb's review:
1) rename RET_MMIO_PF_EMU to RET_MMIO_PF_EMULATE.
2) smartly adjust kvm generation number in kvm_current_mmio_generatio()
to avoid kvm_memslots-generation
://bugzilla.redhat.com/show_bug.cgi?id=969644
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 094b5d9..64a4b03 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1194,20 +1194,37 @@ void kvm_write_tsc(struct kvm_vcpu *vcpu
On Mon, Jun 10, 2013 at 06:31:11PM +0200, Igor Mammedov wrote:
===
Could be the following an acceptable fix?
===
Read of kvmclock should return proper value from hypervisor: system
timestamp + tsc delta.
Should find the offender site and have it register MSR_KVM_SYSTEM_TIME
before reading
(see CLOCK_BOOTTIME).
Change kvmclock driver so as to save clock value when vm transitions
from runnable to stopped state, and to restore clock value from stopped
to runnable transition.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c
On Fri, May 31, 2013 at 08:36:19AM +0800, Xiao Guangrong wrote:
Hi Gleb, Paolo, Marcelo,
I have putted the potential controversial patches to the latter that are
patch 8 ~ 10, patch 11 depends on patch 9. Other patches are fully reviewed,
I think its are ready for being merged. If not luck
On Wed, May 29, 2013 at 11:03:19AM +0800, Xiao Guangrong wrote:
the pages since other vcpus may be doing locklessly shadow
page walking
Ah, yes, i agree with you.
We can introduce a list, say kvm-arch.obsolte_pages, to link all of the
zapped-page, the page-shrink will free the page
On Tue, May 28, 2013 at 10:51:38PM +0800, Xiao Guangrong wrote:
On 05/28/2013 08:13 AM, Marcelo Tosatti wrote:
On Thu, May 23, 2013 at 03:55:58AM +0800, Xiao Guangrong wrote:
It is only used to zap the obsolete page. Since the obsolete page
will not be used, we need not spend time to find
On Tue, May 28, 2013 at 11:02:09PM +0800, Xiao Guangrong wrote:
On 05/28/2013 08:18 AM, Marcelo Tosatti wrote:
On Mon, May 27, 2013 at 10:20:12AM +0800, Xiao Guangrong wrote:
On 05/25/2013 04:34 AM, Marcelo Tosatti wrote:
On Thu, May 23, 2013 at 03:55:53AM +0800, Xiao Guangrong wrote:
Zap
On Wed, May 29, 2013 at 09:09:09PM +0800, Xiao Guangrong wrote:
On 05/29/2013 07:11 PM, Marcelo Tosatti wrote:
On Tue, May 28, 2013 at 11:02:09PM +0800, Xiao Guangrong wrote:
On 05/28/2013 08:18 AM, Marcelo Tosatti wrote:
On Mon, May 27, 2013 at 10:20:12AM +0800, Xiao Guangrong wrote
On Wed, May 29, 2013 at 09:09:09PM +0800, Xiao Guangrong wrote:
This information is I replied Gleb in his mail where he raced a question that
why collapse tlb flush is needed:
==
It seems no.
Since we have reloaded mmu before zapping the obsolete pages, the mmu-lock
is easily
On Thu, May 23, 2013 at 03:55:59AM +0800, Xiao Guangrong wrote:
kvm_zap_obsolete_pages uses lock-break technique to zap pages,
it will flush tlb every time when it does lock-break
We can reload mmu on all vcpus after updating the generation
number so that the obsolete pages are not used on
On Thu, May 23, 2013 at 03:55:58AM +0800, Xiao Guangrong wrote:
It is only used to zap the obsolete page. Since the obsolete page
will not be used, we need not spend time to find its unsync children
out. Also, we delete the page from shadow page cache so that the page
is completely isolated
On Mon, May 27, 2013 at 10:20:12AM +0800, Xiao Guangrong wrote:
On 05/25/2013 04:34 AM, Marcelo Tosatti wrote:
On Thu, May 23, 2013 at 03:55:53AM +0800, Xiao Guangrong wrote:
Zap at lease 10 pages before releasing mmu-lock to reduce the overload
caused by requiring lock
After the patch
On Sun, May 26, 2013 at 11:26:49AM +0300, Gleb Natapov wrote:
On Fri, May 24, 2013 at 05:23:07PM -0300, Marcelo Tosatti wrote:
Hi Xiao,
On Thu, May 23, 2013 at 03:55:52AM +0800, Xiao Guangrong wrote:
The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap
On Fri, May 24, 2013 at 06:11:16AM -0400, Vadim Rozenfeld wrote:
Is there a better option?
If setting TscSequence to zero makes Windows fall back to the MSR this is a
better option.
+1
This is why MS has two different mechanisms:
iTSC as a primary, reference counters as a fall-back.
Hi Xiao,
On Thu, May 23, 2013 at 03:55:52AM +0800, Xiao Guangrong wrote:
The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow pages one by one, also it need to zap all guest
page's rmap and all shadow page's parent spte list. Particularly, things
On Thu, May 23, 2013 at 03:55:53AM +0800, Xiao Guangrong wrote:
Zap at lease 10 pages before releasing mmu-lock to reduce the overload
caused by requiring lock
After the patch, kvm_zap_obsolete_pages can forward progress anyway,
so update the comments
[ It improves kernel building 0.6% ~
On Thu, May 23, 2013 at 12:13:16PM +0300, Gleb Natapov wrote:
Reference TSC during Save and Restore and Migration
To address migration scenarios to physical platforms that do not support
iTSC, the TscSequence field is used. In the event that a guest partition
is migrated from an
On Thu, May 23, 2013 at 08:21:29AM -0400, Vadim Rozenfeld wrote:
@@ -1848,6 +1847,11 @@ static int set_msr_hyperv_pw(struct kvm_vcpu
*vcpu, u32 msr, u64 data)
HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT);
if (kvm_is_error_hva(addr))
On Thu, May 23, 2013 at 12:12:29PM +0300, Gleb Natapov wrote:
To address migration scenarios to physical platforms that do not support
iTSC, the TscSequence field is used. In the event that a guest partition
is migrated from an iTSC capable host to a non-iTSC capable host, the
hypervisor
On Wed, May 22, 2013 at 06:38:47AM +0300, Gleb Natapov wrote:
On Wed, May 22, 2013 at 12:32:57AM -0300, Marcelo Tosatti wrote:
On Wed, May 22, 2013 at 06:28:47AM +0300, Gleb Natapov wrote
+ case HV_X64_MSR_TIME_REF_COUNT:
r = true;
break
On Wed, May 22, 2013 at 09:34:13AM +0300, Gleb Natapov wrote:
On Tue, May 21, 2013 at 10:33:30PM -0300, Marcelo Tosatti wrote:
On Tue, May 21, 2013 at 11:39:03AM +0300, Gleb Natapov wrote:
Any pages with stale information will be zapped by kvm_mmu_zap_all().
When that happens, page
On Wed, May 22, 2013 at 03:22:55AM -0400, Vadim Rozenfeld wrote:
- Original Message -
From: Marcelo Tosatti mtosa...@redhat.com
To: Vadim Rozenfeld vroze...@redhat.com
Cc: kvm@vger.kernel.org, g...@redhat.com, p...@dlh.net
Sent: Wednesday, May 22, 2013 10:50:46 AM
Subject: Re
On Sun, May 19, 2013 at 05:06:37PM +1000, Vadim Rozenfeld wrote:
The following patch allows to activate a partition reference
time enlightenment that is based on the host platform's support
for an Invariant Time Stamp Counter (iTSC).
NOTE: This code will survive migration due to lack of VM
On Sun, May 19, 2013 at 05:06:36PM +1000, Vadim Rozenfeld wrote:
Signed-off: Peter Lieven p...@dlh.net
Signed-off: Gleb Natapov g...@redhat.com
Signed-off: Vadim Rozenfeld vroze...@redhat.com
v1 - v2
1. mark TSC page dirty as suggested by
Eric Northup digitale...@google.com and Gleb
On Tue, May 21, 2013 at 11:36:57AM +0800, Xiao Guangrong wrote:
On 05/21/2013 04:40 AM, Marcelo Tosatti wrote:
On Mon, May 20, 2013 at 11:15:45PM +0300, Gleb Natapov wrote:
On Mon, May 20, 2013 at 04:46:24PM -0300, Marcelo Tosatti wrote:
On Fri, May 17, 2013 at 05:12:58AM +0800, Xiao
On Tue, May 21, 2013 at 11:39:03AM +0300, Gleb Natapov wrote:
Any pages with stale information will be zapped by kvm_mmu_zap_all().
When that happens, page faults will take place which will automatically
use the new generation number.
So still not clear why is this necessary.
This
On Wed, May 22, 2013 at 06:28:47AM +0300, Gleb Natapov wrote
+ case HV_X64_MSR_TIME_REF_COUNT:
r = true;
break;
}
@@ -1827,6 +1829,29 @@ static int set_msr_hyperv_pw(struct kvm_vcpu
*vcpu, u32 msr, u64 data)
if (__copy_to_user((void __user
On Fri, May 17, 2013 at 05:12:58AM +0800, Xiao Guangrong wrote:
The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow pages one by one, also it need to zap all guest
page's rmap and all shadow page's parent spte list. Particularly, things
become worse
On Mon, May 20, 2013 at 11:15:45PM +0300, Gleb Natapov wrote:
On Mon, May 20, 2013 at 04:46:24PM -0300, Marcelo Tosatti wrote:
On Fri, May 17, 2013 at 05:12:58AM +0800, Xiao Guangrong wrote:
The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow
On Wed, May 15, 2013 at 07:02:24PM +0200, Paolo Bonzini wrote:
As announced last week by Marcelo Tosatti, I will be co-maintaining
KVM together with Gleb.
Cc: Marcelo Tosatti mtosa...@redhat.com
Cc: Gleb Natapov g...@redhat.com
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini pbonz
On Wed, May 15, 2013 at 08:41:54PM +0300, Gleb Natapov wrote:
On Tue, May 14, 2013 at 10:12:57AM -0300, Marcelo Tosatti wrote:
On Tue, May 14, 2013 at 12:05:13PM +0300, Gleb Natapov wrote:
On Thu, May 09, 2013 at 08:21:41PM -0300, Marcelo Tosatti wrote:
kvmclock updates which
On Tue, May 14, 2013 at 12:05:13PM +0300, Gleb Natapov wrote:
On Thu, May 09, 2013 at 08:21:41PM -0300, Marcelo Tosatti wrote:
kvmclock updates which are isolated to a given vcpu, such as vcpu-cpu
migration, should not allow system_timestamp from the rest of the vcpus
to remain static
On Thu, May 02, 2013 at 10:14:32PM -0300, Marcelo Tosatti wrote:
On Sun, Apr 28, 2013 at 02:00:41PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Since the arrival of posted interrupt support we can no longer guarantee
that coalesced IRQs are always reported to the IRQ
)
+{
+
+ atomic_notifier_chain_unregister(panic_notifier_list,
+ pvpanic_panic_nb);
+ return 0;
+}
+
+module_acpi_driver(pvpanic_driver);
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
update for all vcpus. The worst
case for a remote vcpu to update its kvmclock is then bounded by maximum
nohz sleep latency.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 94f35d2..a37cadc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm
On Tue, May 07, 2013 at 01:00:51PM +0300, Gleb Natapov wrote:
On Tue, May 07, 2013 at 05:41:35PM +0800, Xiao Guangrong wrote:
On 05/07/2013 04:58 PM, Gleb Natapov wrote:
On Tue, May 07, 2013 at 01:45:52AM +0800, Xiao Guangrong wrote:
On 05/07/2013 01:24 AM, Gleb Natapov wrote:
On Mon,
On Tue, May 07, 2013 at 11:39:59AM +0800, Xiao Guangrong wrote:
Step 1) Fix kvm_mmu_zap_all's behaviour: introduce lockbreak via
spin_needbreak. Use generation numbers so that in case kvm_mmu_zap_all
releases mmu_lock and reacquires it again, only shadow pages
from the generation with
On Tue, May 07, 2013 at 05:56:08PM +0300, Gleb Natapov wrote:
Yes, I am missing what Marcelo means there too. We cannot free memslot
until we unmap its rmap one way or the other.
I do not understand what are you optimizing for, given the four possible
cases we discussed at
On Mon, May 06, 2013 at 11:39:35AM +0800, Hu Tao wrote:
On Fri, May 03, 2013 at 06:59:18PM -0300, Marcelo Tosatti wrote:
On Fri, May 03, 2013 at 10:47:10AM +0800, Hu Tao wrote:
pvpanic device is a qemu simulated device through which guest panic
event is sent to host.
Signed-off
On Mon, May 06, 2013 at 11:39:11AM +0800, Xiao Guangrong wrote:
On 05/04/2013 08:52 AM, Marcelo Tosatti wrote:
On Sat, May 04, 2013 at 12:51:06AM +0800, Xiao Guangrong wrote:
On 05/03/2013 11:53 PM, Marcelo Tosatti wrote:
On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote
It is necessary for each vcpus system_timestamp memory copy to be
updated from one sample of the nanosecond kernel clock.
If this is not the case, and NTP changes frequency adjustment, different
vcpus will make use of different time bases.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Necessary since memory region accessor assumes read and write
methods are registered. Otherwise reading I/O port 0x7e segfaults.
https://bugzilla.redhat.com/show_bug.cgi?id=954306
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/hw/i386/kvmvapic.c b/hw/i386/kvmvapic.c
index
On Sat, May 04, 2013 at 12:00:29PM +0200, Paolo Bonzini wrote:
Il 04/05/2013 03:25, Marcelo Tosatti ha scritto:
Remove myself as KVM co-maintainer: Paolo Bonzini is taking the job.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
ENOPATCH? :)
Or I can just remove your entry when
On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote:
On 05/03/2013 09:05 AM, Marcelo Tosatti wrote:
+
+/*
+ * Fast invalid all shadow pages belong to @slot.
+ *
+ * @slot != NULL means the invalidation is caused the memslot specified
+ * by @slot is being deleted
On Fri, May 03, 2013 at 10:47:10AM +0800, Hu Tao wrote:
pvpanic device is a qemu simulated device through which guest panic
event is sent to host.
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
drivers/platform/x86/Kconfig | 7 +++
drivers/platform/x86/Makefile | 2 +
On Sat, May 04, 2013 at 12:51:06AM +0800, Xiao Guangrong wrote:
On 05/03/2013 11:53 PM, Marcelo Tosatti wrote:
On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote:
On 05/03/2013 09:05 AM, Marcelo Tosatti wrote:
+
+/*
+ * Fast invalid all shadow pages belong to @slot
On Fri, May 03, 2013 at 09:52:01PM -0300, Marcelo Tosatti wrote:
On Sat, May 04, 2013 at 12:51:06AM +0800, Xiao Guangrong wrote:
On 05/03/2013 11:53 PM, Marcelo Tosatti wrote:
On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote:
On 05/03/2013 09:05 AM, Marcelo Tosatti wrote
Remove myself as KVM co-maintainer: Paolo Bonzini is taking the job.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Wed, May 01, 2013 at 07:27:23PM -0500, Scott Wood wrote:
On 05/01/2013 07:15:53 PM, Marcelo Tosatti wrote:
On Fri, Apr 26, 2013 at 07:53:38PM -0500, Scott Wood wrote:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 1020119..506c87d 100644
--- a/arch/powerpc/kvm
On Thu, Apr 25, 2013 at 11:43:22PM -0700, Jun Nakajima wrote:
This is the first patch in a series which adds nested EPT support to KVM's
nested VMX. Nested EPT means emulating EPT for an L1 guest so that L1 can use
EPT when running a nested guest L2. When L1 uses EPT, it allows the L2 guest
to
On Thu, May 02, 2013 at 03:32:45PM +0200, Alexander Graf wrote:
Hi Marcelo / Gleb,
This is my current patch queue for ppc. Please pull and apply to next, so it
makes its way into 3.10. Sorry for the late request.
There is still one RCU patch outstanding that needs a respin, so expect
On Sat, Apr 27, 2013 at 11:13:20AM +0800, Xiao Guangrong wrote:
The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow pages one by one, also it need to zap all guest
page's rmap and all shadow page's parent spte list. Particularly, things
become worse
On Sun, Apr 28, 2013 at 02:00:41PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
Since the arrival of posted interrupt support we can no longer guarantee
that coalesced IRQs are always reported to the IRQ source. Moreover,
accumulated APIC timer events could cause a busy
On Sun, Apr 28, 2013 at 10:50:52AM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
The VMX implementation of enable_irq_window raised
KVM_REQ_IMMEDIATE_EXIT after we checked it in vcpu_enter_guest. This
caused infinite loops on vmentry. Fix it by letting enable_irq_window
On Mon, Apr 29, 2013 at 05:38:27PM +0200, Paolo Bonzini wrote:
Il 29/04/2013 16:46, Jan Kiszka ha scritto:
With VMX, enable_irq_window can now return -EBUSY, in which case an
immediate exit shall be requested before entering the guest. Account for
this also in enable_nmi_window which uses
On Thu, May 02, 2013 at 11:22:52AM -0700, David Daney wrote:
Hi,
I am working on the MIPS KVM port, and am trying to figure out under
which circumstances do I need to srcu_read_lock()/srcu_read_unlock()
the kvm-srcu.
For x86: kvm-srcu protects memory slot information (kvm-memslots) and
On Tue, Apr 30, 2013 at 12:06:27PM -0400, Robert P. J. Day wrote:
poking around in the KVM code and ran across this in kvm_main.c:
... snip ...
out_dir:
debugfs_remove_recursive(kvm_debugfs_dir);
out:
return r;
}
static void kvm_exit_debug(void)
{
struct
On Wed, May 01, 2013 at 07:27:23PM -0500, Scott Wood wrote:
On 05/01/2013 07:15:53 PM, Marcelo Tosatti wrote:
On Fri, Apr 26, 2013 at 07:53:38PM -0500, Scott Wood wrote:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 1020119..506c87d 100644
--- a/arch/powerpc/kvm
On Thu, May 02, 2013 at 03:32:45PM +0200, Alexander Graf wrote:
Hi Marcelo / Gleb,
This is my current patch queue for ppc. Please pull and apply to next, so it
makes its way into 3.10. Sorry for the late request.
There is still one RCU patch outstanding that needs a respin, so expect
On Thu, Apr 25, 2013 at 11:13:40PM +0200, Alexander Graf wrote:
On 25.04.2013, at 21:03, Scott Wood wrote:
On 04/25/2013 09:49:23 AM, Alexander Graf wrote:
On 25.04.2013, at 13:30, Alexander Graf wrote:
On 19.04.2013, at 20:51, Scott Wood wrote:
On 04/19/2013 09:06:27 AM,
On Fri, Apr 26, 2013 at 11:51:40AM +0200, Borislav Petkov wrote:
On Fri, Apr 26, 2013 at 08:42:50AM +0200, Ingo Molnar wrote:
... take all review comments
Here it is:
--
From 56880e448600ca1504df8c68c59f31153f7b5b0f Mon Sep 17 00:00:00 2001
From: Borislav Petkov b...@suse.de
Date:
On Fri, Apr 26, 2013 at 07:53:38PM -0500, Scott Wood wrote:
KVM core expects arch code to acquire the srcu lock when calling
gfn_to_memslot and similar functions.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/44x_tlb.c |5 +
arch/powerpc/kvm/booke.c|
On Thu, Apr 25, 2013 at 11:13:40PM +0200, Alexander Graf wrote:
On 25.04.2013, at 21:03, Scott Wood wrote:
On 04/25/2013 09:49:23 AM, Alexander Graf wrote:
On 25.04.2013, at 13:30, Alexander Graf wrote:
On 19.04.2013, at 20:51, Scott Wood wrote:
On 04/19/2013 09:06:27 AM,
On Fri, Apr 26, 2013 at 07:53:38PM -0500, Scott Wood wrote:
KVM core expects arch code to acquire the srcu lock when calling
gfn_to_memslot and similar functions.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/44x_tlb.c |5 +
arch/powerpc/kvm/booke.c|
On Mon, Apr 29, 2013 at 07:52:41PM -0700, Christoffer Dall wrote:
On Mon, Apr 29, 2013 at 7:11 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Sun, Apr 28, 2013 at 10:29:07PM -0700, Christoffer Dall wrote:
Hi Marcelo and Gleb,
These are the changes for KVM/ARM for 3.10.
The patches
On Wed, Apr 24, 2013 at 01:50:40PM +0300, Gleb Natapov wrote:
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/x86/realmode.c b/x86/realmode.c
Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
On Sun, Apr 28, 2013 at 10:29:07PM -0700, Christoffer Dall wrote:
Hi Marcelo and Gleb,
These are the changes for KVM/ARM for 3.10.
The patches depend on the cleanup branch, which you've already merged.
Main thing is the reworking of Hyp idmaps, which is now handled by KVM
instead of
On Mon, Apr 29, 2013 at 09:59:30AM -0700, Randy Dunlap wrote:
On 04/29/13 09:54, Alex Williamson wrote:
Fix build with CONFIG_PCI unset by linking KVM_CAP_IOMMU to
device assignment config option. It has no purpose otherwise.
Signed-off-by: Alex Williamson alex.william...@redhat.com
On Tue, Apr 23, 2013 at 08:52:16AM +0300, Gleb Natapov wrote:
On Mon, Apr 22, 2013 at 04:58:01PM +, Joji Mekkattuparamban (joji) wrote:
Greetings,
I have a SMP guest application, running on the 2.6.27 Linux kernel. The
application, originally written for bare metal, makes extensive
On Mon, Apr 22, 2013 at 10:45:53PM +0900, Takuya Yoshikawa wrote:
On Mon, 22 Apr 2013 15:39:38 +0300
Gleb Natapov g...@redhat.com wrote:
Do not want kvm_set_memory (cases: DELETE/MOVE/CREATES) to be
suspectible to:
vcpu 1 | kvm_set_memory
create
On Sun, Apr 21, 2013 at 04:03:46PM +0300, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
This patchset is based on my previous two patchset:
[PATCH 0/2] KVM: x86: avoid potential soft lockup and unneeded mmu reload
(https://lkml.org/lkml/2013/4/1/2)
On Sun, Apr 21, 2013 at 12:27:51PM -0300, Marcelo Tosatti wrote:
On Sun, Apr 21, 2013 at 04:03:46PM +0300, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
This patchset is based on my previous two patchset:
[PATCH 0/2] KVM: x86: avoid potential soft
On Sun, Apr 21, 2013 at 10:09:29PM +0800, Xiao Guangrong wrote:
On 04/21/2013 09:03 PM, Gleb Natapov wrote:
On Tue, Apr 16, 2013 at 02:32:38PM +0800, Xiao Guangrong wrote:
This patchset is based on my previous two patchset:
[PATCH 0/2] KVM: x86: avoid potential soft lockup and unneeded mmu
On Thu, Apr 18, 2013 at 12:03:45PM +0800, Xiao Guangrong wrote:
On 04/18/2013 08:08 AM, Marcelo Tosatti wrote:
On Tue, Apr 16, 2013 at 02:32:53PM +0800, Xiao Guangrong wrote:
Use kvm_mmu_invalid_all_pages in kvm_arch_flush_shadow_all and
rename kvm_zap_all to kvm_free_all which is used
On Thu, Apr 18, 2013 at 10:03:06AM -0300, Marcelo Tosatti wrote:
On Thu, Apr 18, 2013 at 12:00:16PM +0800, Xiao Guangrong wrote:
What is the justification for this?
We want the rmap of being deleted memslot is removed-only that is
needed for unmapping rmap out of mmu-lock
On Thu, Apr 18, 2013 at 11:46:29AM +0200, Borislav Petkov wrote:
On Wed, Apr 17, 2013 at 08:25:07PM -0300, Marcelo Tosatti wrote:
On Tue, Apr 16, 2013 at 06:18:52PM +0200, Borislav Petkov wrote:
On Sun, Apr 14, 2013 at 01:03:20PM +0200, Borislav Petkov wrote:
On Sun, Apr 14, 2013 at 12
On Thu, Apr 18, 2013 at 12:00:16PM +0800, Xiao Guangrong wrote:
What is the justification for this?
We want the rmap of being deleted memslot is removed-only that is
needed for unmapping rmap out of mmu-lock.
==
1) do not corrupt the rmap
2) keep pte-list-descs available
3)
501 - 600 of 4400 matches
Mail list logo
