date:20100217

Re: [PATCH 2/2] KVM: SVM: Make stepping out of NMI handlers more robust

2010-02-17 Thread Gleb Natapov

On Wed, Feb 17, 2010 at 08:16:45PM +0100, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Tue, Feb 16, 2010 at 12:08:58PM +0200, Gleb Natapov wrote:
> > Besides this, proper #DB forwarding to the guest was missing.
>  During NMI injection? How to reproduce?
> >>> Inject, e.g., an NMI over code with TF set. A bit harder is placing a
> >>> guest HW breakpoint at the spot the NMI handler returns to.
> >>>
> >> Will try to reproduce.
> >>
> > How can I make gdb to run debugged process with TF set? Is this patch
> > fixes it:
> > 
> > 
> > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> > index 52f78dd..b85b200 100644
> > --- a/arch/x86/kvm/svm.c
> > +++ b/arch/x86/kvm/svm.c
> > @@ -109,6 +109,7 @@ struct vcpu_svm {
> > struct nested_state nested;
> >  
> > bool nmi_singlestep;
> > +   bool nmi_singlestep_tf;
> >  };
> >  
> >  /* enable NPT for AMD64 and X86 with PAE */
> > @@ -1221,9 +1222,14 @@ static int db_interception(struct vcpu_svm *svm)
> >  
> > if (svm->nmi_singlestep) {
> > svm->nmi_singlestep = false;
> > -   if (!(svm->vcpu.guest_debug & KVM_GUESTDBG_SINGLESTEP))
> > +   if (!(svm->vcpu.guest_debug & KVM_GUESTDBG_SINGLESTEP)) {
> > svm->vmcb->save.rflags &=
> > ~(X86_EFLAGS_TF | X86_EFLAGS_RF);
> > +   if (svm->nmi_singlestep_tf) {
> > +   svm->vmcb->save.rflags |= X86_EFLAGS_TF;
> > +   kvm_queue_exception(&svm->vcpu, DB_VECTOR);
> > +   }
> > +   }
> > update_db_intercept(&svm->vcpu);
> > }
> >  
> > @@ -2586,6 +2592,7 @@ static void enable_nmi_window(struct kvm_vcpu *vcpu)
> >possible problem (IRET or exception injection or interrupt
> >shadow) */
> > svm->nmi_singlestep = true;
> > +   svm->nmi_singlestep_tf = (svm->vmcb->save.rflags | X86_EFLAGS_TF);
> > svm->vmcb->save.rflags |= (X86_EFLAGS_TF | X86_EFLAGS_RF);
> > update_db_intercept(vcpu);
> >  }
> 
> That's closer. However, I've a version here that restores TF&RF only if
> you did not execute an IRET but stepped over the shadow (which is still
> not correct either, e.g. when stepping popf). I will break up my patch
> into parts that fix the issues separately so that we can decide what to
> merge.
> 
I am not sure what do you mean here. Why should we restore RF? It is
cleared after each instruction execution and popf is not special in this
regards and SDM explicitly says so.

--
Gleb.
--
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

Re: [PATCH 00/18] KVM: PPC: Virtualize Gekko guests

2010-02-17 Thread Avi Kivity


On 02/17/2010 08:07 PM, Alexander Graf wrote:

On 17.02.2010, at 17:34, Avi Kivity wrote:

   

On 02/17/2010 06:23 PM, Alexander Graf wrote:
 

On 17.02.2010, at 17:03, Avi Kivity wrote:


   

On 02/17/2010 04:56 PM, Alexander Graf wrote:

 

So I changed to code according to your input by making all FPU calls explicit, 
getting rid of all binary patching.

On the PowerStation again I'm running this code (simplified to the important 
instructions) using kvmctl:

 li  r2, 0x1234
 std r2, 0(r1)
 lfd f3, 0(r1)
 lfd f4, 0(r1)
do_mul:
 fmulf0, f3, f4
 b   do_mul


With the following kvm_stat output:

  dec   2236  53
  exits 60797802 1171403
  ext_intr   379   4
  halt_wakeup  0   0
  inst_emu  60795247 1171344
  ld60795132 1171348

So I'm getting 1171403 fmul operations per second. And that's even with 
non-optimized instruction fetching. Not bad.


   

It's a large number, but won't real hardware be three orders of magnitude 
faster?

 

Yes, it would. But we don't have to care. The only thing we need to worry about is 
being fast enough to emulate enough FPU instructions actually used in normal 
guests so the guest runs in full speed. And 1000k>   250k, so we can do that 
apparently, leaving some spare cycles for non-fpu instructions.

   

I'm sure 250k isn't representative of a floating point intensive program (but 
maybe there aren't fpu intensive applications on that cpu).
 

Now you made me check how fast the real hw is. I get about 65,000,000 fmul 
operations per second on it.

   


That's surprisingly low.


So we're 65x slower on a PowerStation. And that's for a tight FPU only loop. 
I'm still not convinced we're running into major problems.
   


Well, it's up to you.  I just hope we don't end up underperforming due 
to this.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
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

Re: [PATCH v2] KVM: VMX: Update instruction length on intercepted BP

2010-02-17 Thread Gleb Natapov

On Wed, Feb 17, 2010 at 08:17:28PM +0100, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Wed, Feb 17, 2010 at 12:23:39PM +0100, Jan Kiszka wrote:
> >> Gleb Natapov wrote:
> >>> On Wed, Feb 17, 2010 at 01:13:29PM +0200, Avi Kivity wrote:
>  On 02/17/2010 12:43 PM, Gleb Natapov wrote:
> >> And, again: This is an _existing_ user space ABI. We could only provide
> >> an alternative, but we have to maintain what is there at least for some
> >> longer grace period.
> >>
> > But it was always broken for SVM and was broken for VMX for a year and
> > nobody noticed, so may be instead of reintroducing old interface we 
> > should
> > do it right this time?
>  We need to fix the existing interface first, and then think long and
>  hard if we want yet another interface, since we're likely to screw
>  it up as well.
> 
>  The more interfaces we introduce, the harder maintenance becomes.
> 
> >>> We are in a sad state if we cannot improve interface. The current one
> >>> outsource part of CPU functionality into userspace. This should be a big
> >>> no-no.
> >> I still disagree on this. Moving the decision logic to user space
> >> prevented to re-implement a gdbstub in kernel space. I oversaw that
> >> re-injecting #BP over older SVM was broken, but it is now fixed for all
> >> vendors. So moving it back to kernel has actually no long-term reason.
> >>
> > There were patches to implement gdbstub in kernel space! And not so long
> > time ago :)
> 
> Yes, a good reason to implement yet another one. :)
> 
We can you unify them later :). But seriously I am not proposing
anything like gdbstub in kernel, just track inserted breakpoints in
kernel.

> > But I want to move only a tiny bit of logic into the kernel space.
> > And #BP reinjection brokenness is a different issue. It should be fixed
> > anyway no matter where decision about reinfection happens.
> > 
> > If maintainers think that we should not have improved interface and we
> > should support reinjection of #DB from userspace then this patch should
> > be applied. I don't have other objections to it. But I, at least, would
> > prefer the old interface for #DB reinjection (KVM_GUESTDBG_INJECT_DB)
> > and not the new one. The old one makes it explicit what we are doing,
> > the new one allows injection of any event and should be used only during
> > migration or CPU reset. It would be event good idea to fail setting
> > events if CPU is running.
> 
> Event injection is well supported by both vendors (except for those
> software-triggered events). Just because QEMU mostly uses it for reset
> and migration doesn't mean we have to restrict other users to only those
> cases as well.
Yes we have too! Qemu implements device model and the way devices
communicates with CPU is well defined and called interrupts, so we have
a way to inject interrupts (KVM_IRQ_LINE/KVM_INTERRUPT). Input is
validated and passed into VCPU in the right time, we do not inject
interrupts directly into VCPU using event injection. Exceptions, on the
other hand, is completely internal CPU thing. QEMU shouldn't be a part
of CPU emulation.

> 
> And as we have true event injection now, and as it naturally conflicts
Now we have a bug that should be fixed ASAP. We should allow setting of
some VCPU state only when VCPU is stopped and only for migration/reset
purposes.

> with the special KVM_SET_GUEST_DEBUG interface, I have a patch that
> consolidates this usage for QEMU: use the old interface of
> SET_GUEST_DEBUG for pre-2.6.33 kernels, switch to SET_VCPU_EVENTS on
> recent ones.
Don't do that please, this will encourage use of SET_VCPU_EVENTS for
something it shouldn't be used for.

--
Gleb.
--
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

Re: [Qemu-devel] Re: [PATCH v2] qemu-kvm: Speed up of the dirty-bitmap-traveling

2010-02-17 Thread OHMURA Kei

"We think"? I mean - yes, I think so too. But have you actually measured it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?

Thanks for pointing out.
I will post the data for x86 later.
However, I don't have a test environment to check the impact of bswap.
Would you please measure the run time between the following section if possible?

It'd make more sense to have a real stand alone test program, no?
I can try to write one today, but I have some really nasty important bugs to
fix first.

OK. I will prepare a test code with sample data. Since I found a ppc machine
around, I will run the code and post the results of
x86 and ppc.

By the way, the following data is a result of x86 measured in QEMU/KVM.
This data shows, how many times the function is called (#called), runtime of original function(orig.), runtime of this patch(patch), speedup ratio (ratio).

That does indeed look promising!

Thanks for doing this micro-benchmark. I just want to be 100% sure that it
doesn't affect performance for big endian badly.

I measured runtime of the test code with sample data. My test environment
and results are described below.

x86 Test Environment:
CPU: 4x Intel Xeon Quad Core 2.66GHz
Mem size: 6GB

ppc Test Environment:
CPU: 2x Dual Core PPC970MP
Mem size: 2GB

The sample data of dirty bitmap was produced by QEMU/KVM while the guest OS
was live migrating. To measure the runtime I copied cpu_get_real_ticks() of
QEMU to my test program.

Experimental results:
Test1: Guest OS read 3GB file, which is bigger than memory.
orig.(msec)patch(msec)ratio
x860.30.16.4
ppc7.92.73.0

Test2: Guest OS read/write 3GB file, which is bigger than memory.
orig.(msec)patch(msec)ratio
x8612.0 3.23.7
ppc251.1 1232.0

I also measured the runtime of bswap itself on ppc, and I found it was only
just 0.3% ~ 0.7 % of the runtime described above.

--
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

95 matches

Mail list logo