From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752143AbaJ0Jhc (ORCPT ); Mon, 27 Oct 2014 05:37:32 -0400 Received: from mail-la0-f48.google.com ([209.85.215.48]:59029 "EHLO mail-la0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751180AbaJ0Jhb (ORCPT ); Mon, 27 Oct 2014 05:37:31 -0400 MIME-Version: 1.0 In-Reply-To: <1414225494-2208-1-git-send-email-john.liuli@huawei.com> References: <1414225494-2208-1-git-send-email-john.liuli@huawei.com> From: Peter Maydell Date: Mon, 27 Oct 2014 09:37:09 +0000 Message-ID: Subject: Re: [Qemu-devel] [RFC PATCH 0/2] virtio-mmio: add irqfd support for vhost-net based on virtio-mmio To: "john.liuli" Cc: lkml - Kernel Mailing List , Joel Schopp , Yingshiuan Pan , "Michael S. Tsirkin" , remy.gauguey@cea.fr, Rusty Russell , QEMU Developers , Nikolay Nikolaev , "virtualization@lists.linux-foundation.org" , peter.huangpeng@huawei.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25 October 2014 09:24, john.liuli 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60660) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xigk3-0007Sq-J3 for qemu-devel@nongnu.org; Mon, 27 Oct 2014 05:37:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xigjy-0002pc-PM for qemu-devel@nongnu.org; Mon, 27 Oct 2014 05:37:35 -0400 Received: from mail-la0-f47.google.com ([209.85.215.47]:41425) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xigjy-0002pO-Hy for qemu-devel@nongnu.org; Mon, 27 Oct 2014 05:37:30 -0400 Received: by mail-la0-f47.google.com with SMTP id pv20so5383772lab.6 for ; Mon, 27 Oct 2014 02:37:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1414225494-2208-1-git-send-email-john.liuli@huawei.com> References: <1414225494-2208-1-git-send-email-john.liuli@huawei.com> From: Peter Maydell Date: Mon, 27 Oct 2014 09:37:09 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [RFC PATCH 0/2] virtio-mmio: add irqfd support for vhost-net based on virtio-mmio List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "john.liuli" Cc: Joel Schopp , Yingshiuan Pan , "Michael S. Tsirkin" , remy.gauguey@cea.fr, Rusty Russell , lkml - Kernel Mailing List , Nikolay Nikolaev , QEMU Developers , peter.huangpeng@huawei.com, "virtualization@lists.linux-foundation.org" On 25 October 2014 09:24, john.liuli 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Maydell Subject: Re: [Qemu-devel] [RFC PATCH 0/2] virtio-mmio: add irqfd support for vhost-net based on virtio-mmio Date: Mon, 27 Oct 2014 09:37:09 +0000 Message-ID: References: <1414225494-2208-1-git-send-email-john.liuli@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1414225494-2208-1-git-send-email-john.liuli@huawei.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: "john.liuli" Cc: Joel Schopp , Yingshiuan Pan , "Michael S. Tsirkin" , remy.gauguey@cea.fr, lkml - Kernel Mailing List , Nikolay Nikolaev , QEMU Developers , peter.huangpeng@huawei.com, "virtualization@lists.linux-foundation.org" List-Id: virtualization@lists.linuxfoundation.org On 25 October 2014 09:24, john.liuli 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