On 04/24/2012 03:29 PM, Gleb Natapov wrote:
On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
From: Srivatsa Vaddagiri
KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt state.
The presence of these hypercalls is indicated to guest via
KVM_FEATURE_PV_UNHALT
On 27.04.2012, at 07:48, Paul Mackerras wrote:
> On Thu, Apr 26, 2012 at 12:19:03PM +0200, Alexander Graf wrote:
>
>> So switch the code over to call into the Linux C handlers from C code,
>> speeding up everything along the way.
>
> I have to say this patch makes me pretty uneasy. There are a
On 27.04.2012, at 13:23, Alexander Graf wrote:
>
> On 27.04.2012, at 07:48, Paul Mackerras wrote:
>
>> On Thu, Apr 26, 2012 at 12:19:03PM +0200, Alexander Graf wrote:
>>
>>> So switch the code over to call into the Linux C handlers from C code,
>>> speeding up everything along the way.
>>
>>
The single byte opcode 0x80 should get a byte immediate.
The previous emulation is broken for opcode 0x80.
---
arch/x86/kvm/emulate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 8375622..dd53e53 100644
--- a/arch/x
On Fri, Apr 27, 2012 at 01:53:09PM +0800, Xiao Guangrong wrote:
> On 04/27/2012 07:45 AM, Marcelo Tosatti wrote:
>
>
> >> +static bool
> >> +fast_pf_fix_spte(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp,
> >> +u64 *sptep, u64 spte)
> >> +{
> >> + gfn_t gfn;
> >> +
> >> + spin_lock
On Thu, Apr 26, 2012 at 04:50:35PM +0200, Sasha Levin wrote:
> Hi all.
>
> I got a "INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected" warning
> while running LTP inside a KVM guest using the recent -next kernel.
>
> It seems that it was initially originated from rcu_torture_rea(), but I
>
On Mon, Apr 23, 2012 at 10:42:25AM +0200, Jan Kiszka wrote:
> On 2012-03-09 23:17, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > There is no need for an explicit kvm_arch_reset_vcpu on arch cpu init
> > anymore, kvm_init_vcpu does it already. Call the remaining
> > kvm_update_ioport_access direc
On Fri, Apr 27, 2012 at 04:15:35PM +0530, Raghavendra K T wrote:
> On 04/24/2012 03:29 PM, Gleb Natapov wrote:
> >On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
> >>From: Srivatsa Vaddagiri
> >>
> >>KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt
> >>stat
Remote flushing api's does a busy wait which is fine in bare-metal
scenario. But with-in the guest, the vcpus might have been pre-empted
or blocked. In this scenario, the initator vcpu would end up
busy-waiting for a long amount of time.
This was discovered in our gang scheduling test and other wa
Hypervisor code to indicate guest running/pre-empteded status through
msr.
Suggested-by: Peter Zijlstra
Signed-off-by: Nikunj A. Dadhania
---
arch/x86/include/asm/kvm_host.h |7 ++
arch/x86/kvm/cpuid.c|1 +
arch/x86/kvm/x86.c | 44 +
The patch adds guest code for msr between guest and hypervisor. The
msr will export the vcpu running/pre-empted information to the guest
from host. This will enable guest to intelligently send ipi to running
vcpus and set flag for pre-empted vcpus. This will prevent waiting for
vcpus that are not r
flush_tlb_others_ipi depends on lot of statics in tlb.c. Replicated
the flush_tlb_others_ipi as kvm_flush_tlb_others to further adapt to
paravirtualization.
Use the vcpu state information inside the kvm_flush_tlb_others to
avoid sending ipi to pre-empted vcpus.
* Do not send ipi's to offline vcp
Get kvm_kick_cpu out of CONFIG_PARAVIRT_SPINLOCK define
Signed-off-by: Nikunj A. Dadhania
---
arch/x86/kernel/kvm.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 66db54e..5943285 100644
--- a/arch/x86
In place of looping continuously introduce a halt if we do not succeed
after some time.
For vcpus that were running an IPI is sent. In case, it went to sleep
between this, we will be doing flush_on_enter(harmless). But as a
flush IPI was already sent, that will be processed in ipi handler,
this m
On 04/27/2012 06:23 AM, Alexander Graf wrote:
>
> On 27.04.2012, at 07:48, Paul Mackerras wrote:
>
>> Have you measured a performance improvement with this patch? If so
>> how big was it?
>
> Yeah, I tried things on 970 in an mfsprg/mtsprg busy loop. I measured 3
> different variants:
>
> C i
On 27.04.2012, at 18:37, Scott Wood wrote:
> On 04/27/2012 06:23 AM, Alexander Graf wrote:
>>
>> On 27.04.2012, at 07:48, Paul Mackerras wrote:
>>
>>> Have you measured a performance improvement with this patch? If so
>>> how big was it?
>>
>> Yeah, I tried things on 970 in an mfsprg/mtsprg
hypervisor - ubuntu natty 2.6.38-13-server #57-Ubuntu SMP Mon Mar 5
19:52:44 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
a VM, also ubuntu based, was hanging on vm initiated reboot, without
any useful error messages.
virsh destroyed the domain, killed -9 the remaining process and can
not start up the
On Fri, Apr 27, 2012 at 5:23 PM, Paul E. McKenney
wrote:
>
> On Thu, Apr 26, 2012 at 04:50:35PM +0200, Sasha Levin wrote:
> > Hi all.
> >
> > I got a "INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected"
> > warning
> > while running LTP inside a KVM guest using the recent -next kernel.
> >
>
On Fri, Apr 27, 2012 at 08:05:15PM +0200, Sasha Levin wrote:
> On Fri, Apr 27, 2012 at 5:23 PM, Paul E. McKenney
> wrote:
> >
> > On Thu, Apr 26, 2012 at 04:50:35PM +0200, Sasha Levin wrote:
> > > Hi all.
> > >
> > > I got a "INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected"
> > > warning
On Fri, Apr 27, 2012 at 02:07:57PM +0800, Xiao Guangrong wrote:
> On 04/27/2012 06:00 AM, Marcelo Tosatti wrote:
>
>
> >> static void walk_shadow_page_lockless_end(struct kvm_vcpu *vcpu)
> >> {
> >> - /* Decrease the counter after walking shadow page table finished */
> >> - smp_mb__before_at
On Fri, 2012-04-27 at 13:23 +0200, Alexander Graf wrote:
> On 27.04.2012, at 07:48, Paul Mackerras wrote:
>
> > On Thu, Apr 26, 2012 at 12:19:03PM +0200, Alexander Graf wrote:
> >
> >> So switch the code over to call into the Linux C handlers from C code,
> >> speeding up everything along the way
On Tue, Apr 24, 2012 at 04:40:14PM +0200, Jan Kiszka wrote:
> Some cosmetics for the API docs and the documentations for the PIT
> IOCTLs are the foundation. On top comes the previously posted patch for
> a separate PIT interrupt injection kthread, just augmented by some
> documentation.
>
> This
On Thu, Apr 26, 2012 at 09:10:30AM +0200, Jan Kiszka wrote:
> Removes any fragment from the original qemu-kvm PIT and some prototypes
> and declarations left over from previous cleanups. It also folds the
> function in qemu-kvm-x86.c into target-i386/kvm.c and removes the
> former.
>
> Signed-off-
On 04/27/2012 10:52 PM, Marcelo Tosatti wrote:
>> Actually, in this patch, all the spte update is under mmu-lock, and we
>> lockless-ly read spte , but the spte will be verified again after holding
>> mmu-lock.
>
> Yes but the objective you are aiming for is to read and write sptes
> without mmu
24 matches
Mail list logo
