From: Eric Auger <eric.auger@linaro.org>
To: Li Liu <john.liuli@huawei.com>, Peter Maydell <peter.maydell@linaro.org>
Cc: Joel Schopp <joel.schopp@amd.com>,
"eric.auger@st.com" <eric.auger@st.com>,
Yingshiuan Pan <yingshiuan.pan@gmail.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
remy.gauguey@cea.fr, Rusty Russell <rusty@rustcorp.com.au>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>,
QEMU Developers <qemu-devel@nongnu.org>,
peter.huangpeng@huawei.com,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] virtio-mmio: add irqfd support for vhost-net based on virtio-mmio
Date: Wed, 05 Nov 2014 09:43:47 +0100 [thread overview]
Message-ID: <5459E343.6030907@linaro.org> (raw)
In-Reply-To: <544E2B18.8010702@huawei.com>
On 10/27/2014 12:23 PM, Li Liu wrote:
>
>
> On 2014/10/27 17:37, Peter Maydell wrote:
>> On 25 October 2014 09:24, john.liuli <john.liuli@huawei.com> wrote:
>>> To get the interrupt reason to support such VIRTIO_NET_F_STATUS
>>> features I add a new register offset VIRTIO_MMIO_ISRMEM which
>>> will help to establish a shared memory region between qemu and
>>> virtio-mmio device. Then the interrupt reason can be accessed by
>>> guest driver through this region. At the same time, the virtio-mmio
>>> dirver check this region to see irqfd is supported or not during
>>> the irq handler registration, and different handler will be assigned.
>>
>> If you want to add a new register you should probably propose
>> an update to the virtio spec. However, it seems to me it would
>> be better to get generic PCI/PCIe working on the ARM virt
>> board instead; then we can let virtio-mmio quietly fade away.
>> This has been on the todo list for ages (and there have been
>> RFC patches posted for plain PCI), it's just nobody's had time
>> to work on it.
>>
>> thanks
>> -- PMM
>>
>
> So you mean virtio-mmio will be replaced by PCI/PCIe on ARM at last?
> If so, let this patch go with the wind:). Thx.
Hi,
As a fix of current situation where ISR is only partially updated when
vhost-irqfd handles standard IRQ and waiting for PCI emuluation,
wouldn't it make sense to store ISR content on vhost driver side and
introduce ioctls to read/write it. When using vhost BE, virtio QEMU
device would use those ioctl to read/update the ISR content. On top of
that we would update the ISR in vhost before triggering the irqfd. If I
do not miss anything this would at least make things functional with irqfd.
As a second step, we could try to introduce in-kernel emulation of
ISR/ACK to fix the performance issue related to going to user-side each
time ISR/ACK accesses are done.
Do you think it is worth investigating this direction?
Thank you in advance
Best Regards
Eric
>
> Li.
>> .
>>
>
>
next prev parent reply other threads:[~2014-11-05 8:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-25 8:24 [Qemu-devel] [RFC PATCH 0/2] virtio-mmio: add irqfd support for vhost-net based on virtio-mmio john.liuli
2014-10-25 8:24 ` [Qemu-devel] [RFC PATCH 1/2] Add a new register offset let interrupt reason available john.liuli
2014-10-26 12:01 ` Michael S. Tsirkin
2014-10-25 8:24 ` [Qemu-devel] [RFC PATCH 2/2] Assign a new irq handler while irqfd enabled john.liuli
2014-10-26 11:56 ` Michael S. Tsirkin
2014-10-27 11:04 ` Li Liu
2014-10-27 12:03 ` Michael S. Tsirkin
2014-10-26 11:52 ` [Qemu-devel] [RFC PATCH 0/2] virtio-mmio: add irqfd support for vhost-net based on virtio-mmio Michael S. Tsirkin
2014-10-27 9:19 ` Li Liu
2014-10-27 10:48 ` Michael S. Tsirkin
2014-10-27 9:37 ` Peter Maydell
2014-10-27 11:23 ` Li Liu
2014-10-27 11:58 ` Peter Maydell
2014-11-05 9:30 ` Christoffer Dall
2014-11-05 8:43 ` Eric Auger [this message]
2014-11-06 1:59 ` Shannon Zhao
2014-11-06 9:24 ` Li Liu
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=5459E343.6030907@linaro.org \
--to=eric.auger@linaro.org \
--cc=christoffer.dall@linaro.org \
--cc=eric.auger@st.com \
--cc=joel.schopp@amd.com \
--cc=john.liuli@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=n.nikolaev@virtualopensystems.com \
--cc=peter.huangpeng@huawei.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=remy.gauguey@cea.fr \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.org \
--cc=yingshiuan.pan@gmail.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).