Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752683AbbHaLdr (ORCPT ); Mon, 31 Aug 2015 07:33:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39083 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751322AbbHaLdq (ORCPT ); Mon, 31 Aug 2015 07:33:46 -0400 Date: Mon, 31 Aug 2015 14:33:43 +0300 From: "Michael S. Tsirkin" To: Jason Wang Cc: gleb@kernel.org, pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, cornelia.huck@de.ibm.com Subject: Re: [PATCH V3 2/3] kvm: don't register wildcard MMIO EVENTFD on two buses Message-ID: <20150831143047-mutt-send-email-mst@redhat.com> References: <1440493548-2971-1-git-send-email-jasowang@redhat.com> <1440493548-2971-2-git-send-email-jasowang@redhat.com> <20150825144925-mutt-send-email-mst@redhat.com> <55DD4A5A.3080006@redhat.com> <55E3C607.1060005@redhat.com> <20150831102838-mutt-send-email-mst@redhat.com> <55E40A6F.5010003@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55E40A6F.5010003@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2609 Lines: 60 On Mon, Aug 31, 2015 at 04:03:59PM +0800, Jason Wang wrote: > > > On 08/31/2015 03:29 PM, Michael S. Tsirkin wrote: > >>>>> Thinking more about this, invoking the 0-length write after > >>>>> > >> > the != 0 length one would be better: it would mean we only > >>>>> > >> > handle the userspace MMIO like this. > >>> > > Right. > >>> > > > >> > > >> > Using current unittest. This patch is about 2.9% slower than before, and > >> > invoking 0-length write after is still 1.1% slower (mmio-datamatch-eventfd). > >> > > >> > /patch/result/-+%/ > >> > /base/2957/0/ > >> > /V3/3043/+2.9%/ > >> > /V3+invoking != 0 length first/2990/+1.1%/ > >> > > >> > So looks like the best method is not searching KVM_FAST_MMIO_BUS during > >> > KVM_MMIO_BUS. Instead, let userspace to register both datamatch and > >> > wildcard in this case. Does this sound good to you? > > No - we can't change userspace. > > Actually, the change was as simple as following. So I don't get the > reason why. Because it's too late - we committed to a specific userspace ABI when this was merged in kernel, we must maintain it. Even if I thought yours is a good API (and I don't BTW - it's exposing internal implementation details) it's too late to change it. > diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c > index 9935029..42ee986 100644 > --- a/hw/virtio/virtio-pci.c > +++ b/hw/virtio/virtio-pci.c > @@ -288,6 +288,8 @@ static int > virtio_pci_set_host_notifier_internal(VirtIOPCIProxy *proxy, > if (modern) { > memory_region_add_eventfd(modern_mr, modern_addr, 2, > true, n, notifier); > + memory_region_add_eventfd(modern_mr, modern_addr, 0, > + false, n, notifier); > } > if (legacy) { > memory_region_add_eventfd(legacy_mr, legacy_addr, 2, > @@ -297,6 +299,8 @@ static int > virtio_pci_set_host_notifier_internal(VirtIOPCIProxy *proxy, > if (modern) { > memory_region_del_eventfd(modern_mr, modern_addr, 2, > true, n, notifier); > + memory_region_del_eventfd(modern_mr, modern_addr, 0, > + false, n, notifier); > } > if (legacy) { > memory_region_del_eventfd(legacy_mr, legacy_addr, 2, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/