From: Mario Smarduch <mario.smarduch@huawei.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "<christoffer.dall@linaro.com>" <christoffer.dall@linaro.com>,
Antonios Motakis <a.motakis@virtualopensystems.com>,
Marc Zyngier <marc.zyngier@arm.com>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/2] armv7 initial device passthrough support
Date: Mon, 24 Jun 2013 10:08:08 +0200 [thread overview]
Message-ID: <51C7FE68.1050202@huawei.com> (raw)
In-Reply-To: <51BC8CAE.8090906@redhat.com>
On 6/15/2013 5:47 PM, Paolo Bonzini wrote:
> Il 13/06/2013 11:19, Mario Smarduch ha scritto:
>> Updated Device Passthrough Patch.
>> - optimized IRQ->CPU->vCPU binding, irq is installed once
>> - added dynamic IRQ affinity on schedule in
>> - added documentation and few other coding recommendations.
>>
>> Per earlier discussion VFIO is our target but we like
>> something earlier to work with to tackle performance
>> latency issue (some ARM related) for device passthrough
>> while we migrate towards VFIO.
>
> I don't think this is acceptable upstream, unfortunately. KVM device
> assignment is deprecated and we should not add more users.
That's fine we'll work our way towards dev-tree VFIO reusing what we can
working with the community.
At this point we're more concerned with numbers and best practices as
opposed to mechanism this part will be time consuming.
VFIO will be more background for us.
>
> What are the latency issues you have?
Our focus now is on IRQ latency and throughput. Right now it appears lowest latency
is 2x + exit/enter + IRQ injection overhead. We can't tolerate additional
IPIs or deferred IRQ injection approaches. We're looking for numbers closer
to what IBMs ELI managed. Also high res timers which ARM Virt. Ext supports
very well. Exitless interrupts which ARM handles very well too. There are
some future hw ARM interrupt enhancements coming up which may help a lot as well.
There are many other latency/perf. reqs for NFV related to RT,
essentially Guest must run near native. In the end it may turn out this
may need to be outside of main tree we'll see.
- Mario
>
> Paolo
>
>> - Mario
next prev parent reply other threads:[~2013-06-24 8:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 15:19 [PATCH 2/2] armv7 initial device passthrough support Mario Smarduch
2013-06-15 15:47 ` Paolo Bonzini
2013-06-24 8:08 ` Mario Smarduch [this message]
2013-06-24 20:01 ` Christoffer Dall
2013-06-24 22:27 ` Stuart Yoder
2013-06-25 6:58 ` Mario Smarduch
2013-06-25 6:53 ` Mario Smarduch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C7FE68.1050202@huawei.com \
--to=mario.smarduch@huawei.com \
--cc=a.motakis@virtualopensystems.com \
--cc=christoffer.dall@linaro.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=marc.zyngier@arm.com \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.