From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"mst@redhat.com" <mst@redhat.com>,
"gleb@redhat.com" <gleb@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd
Date: Wed, 11 Jul 2012 14:51:31 +0300 [thread overview]
Message-ID: <4FFD68C3.7000504@redhat.com> (raw)
In-Reply-To: <4FFD6221.1060304@siemens.com>
On 07/11/2012 02:23 PM, Jan Kiszka wrote:
>>
>> I'd appreciate a couple of examples for formality's sake.
>
> From the top of my head: NVIDIA FX3700 (granted, legacy by now), Atheros
> AR9287. For others, I need to check.
Thanks.
>>
>>> And then there is not easily replaceable legacy hardware like old
>>> telephony adapters or industrial I/O cards etc. that want this.
>>
>> I imagine legacy hardware will live with the speed of routing through
>> qemu, when running on modern platforms.
>
> Just because it's "legacy" doesn't mean it's "low performance" and "low
> interrupt rate".
I meant that it was used with lower throughput hardware, so the overhead
of routing through qemu will be masked by the improved host hardware.
But most of the improvement in hardware in recent years is the increase
in core/thread count.
> We still have classic KVM device assignment to provide fast-path INTx.
> But if we want to replace it midterm, I think it's necessary for VFIO to
> be able to provide such a path as well.
I would like VFIO to have no regressions vs. kvm device assignment,
except perhaps in uncommon corner cases. So I agree.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-07-11 11:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 19:21 [PATCH v3 0/2] kvm: level irqfd and new eoifd Alex Williamson
2012-07-03 19:21 ` [PATCH v3 1/2] kvm: Extend irqfd to support level interrupts Alex Williamson
2012-07-03 19:21 ` [PATCH v3 2/2] kvm: KVM_EOIFD, an eventfd for EOIs Alex Williamson
2012-07-04 14:00 ` Michael S. Tsirkin
2012-07-05 4:24 ` Alex Williamson
2012-07-05 15:53 ` Michael S. Tsirkin
2012-07-09 20:35 ` Alex Williamson
2012-07-13 13:36 ` Michael S. Tsirkin
2012-07-11 9:53 ` [PATCH v3 0/2] kvm: level irqfd and new eoifd Avi Kivity
2012-07-11 10:18 ` Jan Kiszka
2012-07-11 10:49 ` Avi Kivity
2012-07-11 11:23 ` Jan Kiszka
2012-07-11 11:51 ` Avi Kivity [this message]
2012-07-11 19:57 ` Alex Williamson
2012-07-12 9:35 ` Avi Kivity
2012-07-12 16:19 ` Alex Williamson
2012-07-12 17:38 ` Alex Williamson
2012-07-15 10:09 ` Avi Kivity
2012-07-16 14:08 ` Alex Williamson
2012-07-15 8:33 ` Avi Kivity
2012-07-16 14:03 ` Alex Williamson
2012-07-16 14:35 ` Avi Kivity
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=4FFD68C3.7000504@redhat.com \
--to=avi@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).