From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83F03C433F5 for ; Mon, 25 Oct 2021 12:43:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5DF0260EE9 for ; Mon, 25 Oct 2021 12:43:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233162AbhJYMpc (ORCPT ); Mon, 25 Oct 2021 08:45:32 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:33538 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233055AbhJYMpa (ORCPT ); Mon, 25 Oct 2021 08:45:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635165787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=79f/9afnwtB829IMzgS0+GQeVHdsj73e3rNCJCAuleY=; b=HCyLbi0U5zqfqHeHOYLO4DPdGb0S8HcW1uHyQr0ELtTvGCpem91NAi4cR2ZXF/NOjk9S5b UIGInqJ8xl4mdmfj+BHm9s/S19sapCPSI8XAf/MG6zR2vOVtmeqVmVjWn+I9lMGqJVpvM+ NUuY5wX6yR543GgdLMbjCFkS/cELpZw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-272-dUyAEKn0Ne6zLaA8wcLKsw-1; Mon, 25 Oct 2021 08:43:04 -0400 X-MC-Unique: dUyAEKn0Ne6zLaA8wcLKsw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AACF0101F000; Mon, 25 Oct 2021 12:43:02 +0000 (UTC) Received: from localhost (unknown [10.39.192.215]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53C825BAFB; Mon, 25 Oct 2021 12:42:57 +0000 (UTC) Date: Mon, 25 Oct 2021 13:42:56 +0100 From: Stefan Hajnoczi To: elena Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, mst@redhat.com, john.g.johnson@oracle.com, dinechin@redhat.com, cohuck@redhat.com, jasowang@redhat.com, felipe@nutanix.com, jag.raman@oracle.com, eafanasova@gmail.com Subject: Re: MMIO/PIO dispatch file descriptors (ioregionfd) design discussion Message-ID: References: <88ca79d2e378dcbfb3988b562ad2c16c4f929ac7.camel@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PKDBWrlb7QGTn9i6" Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org --PKDBWrlb7QGTn9i6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 11, 2021 at 10:34:29PM -0700, elena wrote: > On Wed, Nov 25, 2020 at 12:44:07PM -0800, Elena Afanasova wrote: > > Hello, > > >=20 > Hi >=20 > Sorry for top-posting, just wanted to provide a quik update. > We are currently working on the support for ioregionfd in Qemu and will > be posting the patches soon. Plus the KVM patches will be posted based > of the RFC v3 with some fixes if there are no objections from Elena's side > who originally posted KVM RFC patchset. Hi Elena, I'm curious what approach you want to propose for QEMU integration. A while back I thought about the QEMU API. It's possible to implement it along the lines of the memory_region_add_eventfd() API where each ioregionfd is explicitly added by device emulation code. An advantage of this approach is that a MemoryRegion can have multiple ioregionfds, but I'm not sure if that is a useful feature. An alternative is to cover the entire MemoryRegion with one ioregionfd. That way the device emulation code can use ioregionfd without much fuss since there is a 1:1 mapping between MemoryRegions, which are already there in existing devices. There is no need to think deeply about which ioregionfds to create for a device. A new API called memory_region_set_aio_context(MemoryRegion *mr, AioContext *ctx) would cause ioregionfd (or a userspace fallback for non-KVM cases) to execute the MemoryRegion->read/write() accessors from the given AioContext. The details of ioregionfd are hidden behind the memory_region_set_aio_context() API, so the device emulation code doesn't need to know the capabilities of ioregionfd. The second approach seems promising if we want more devices to use ioregionfd inside QEMU because it requires less ioregionfd-specific code. Stefan --PKDBWrlb7QGTn9i6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmF2plAACgkQnKSrs4Gr c8hugQgAsK965URBPD6/lg7f0ucQqEchs2Spk7bGtxC1VOoSL7mxqgDmaNGfqzME BWlS7vNeCaaiT13vsw1H0rDh6QumtlQpnJfNkNnX+K2tjxjZIftNnhlRiN/NHbzN ZbeBAJKlf6yf9wuePTMwu+zxR6yPFIAVVZrvPh27OInSOEkRMCx1MmjqyA3pRnFX gyY8Krxcrgh1rgoyC03MNOkTRTEHExn40sNcIXcqcNfwd1k/dEAXnaiulT1qya1i o/b6L4LGDpw5BwwqsTu2dSJ6+cjhiaJ2BPuSewFjGf8xr37IXKB2hexPmar958sI gvbcgCEHS+0KtUXXb5O8VA3f5HRmNQ== =zbN3 -----END PGP SIGNATURE----- --PKDBWrlb7QGTn9i6-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67359C433F5 for ; Mon, 25 Oct 2021 12:54:57 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1A95761027 for ; Mon, 25 Oct 2021 12:54:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1A95761027 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:48128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mezVA-0002te-3A for qemu-devel@archiver.kernel.org; Mon, 25 Oct 2021 08:54:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56228) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mezJp-00006z-7v for qemu-devel@nongnu.org; Mon, 25 Oct 2021 08:43:13 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:21975) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mezJm-0003dB-M5 for qemu-devel@nongnu.org; Mon, 25 Oct 2021 08:43:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635165789; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=79f/9afnwtB829IMzgS0+GQeVHdsj73e3rNCJCAuleY=; b=DVJnsMPhEtwXBJ0U4ryCGl+rWG5xnhqnwJJ0YK56tdBLRoH1UhOdNsEum6gHlqGC+zcnXw fwZQSdxfdeNIRQsAr0VbTsoktWTkw9PYt6oesKQVmk90im0G97mpRbYt/ZjE7NNVBKKc22 YAIVZnYR5aatyusg9pKAF3SmqsgkwZo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-272-dUyAEKn0Ne6zLaA8wcLKsw-1; Mon, 25 Oct 2021 08:43:04 -0400 X-MC-Unique: dUyAEKn0Ne6zLaA8wcLKsw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AACF0101F000; Mon, 25 Oct 2021 12:43:02 +0000 (UTC) Received: from localhost (unknown [10.39.192.215]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53C825BAFB; Mon, 25 Oct 2021 12:42:57 +0000 (UTC) Date: Mon, 25 Oct 2021 13:42:56 +0100 From: Stefan Hajnoczi To: elena Subject: Re: MMIO/PIO dispatch file descriptors (ioregionfd) design discussion Message-ID: References: <88ca79d2e378dcbfb3988b562ad2c16c4f929ac7.camel@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PKDBWrlb7QGTn9i6" Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Received-SPF: pass client-ip=170.10.133.124; envelope-from=stefanha@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: john.g.johnson@oracle.com, jag.raman@oracle.com, kvm@vger.kernel.org, mst@redhat.com, jasowang@redhat.com, cohuck@redhat.com, qemu-devel@nongnu.org, eafanasova@gmail.com, felipe@nutanix.com, dinechin@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --PKDBWrlb7QGTn9i6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 11, 2021 at 10:34:29PM -0700, elena wrote: > On Wed, Nov 25, 2020 at 12:44:07PM -0800, Elena Afanasova wrote: > > Hello, > > >=20 > Hi >=20 > Sorry for top-posting, just wanted to provide a quik update. > We are currently working on the support for ioregionfd in Qemu and will > be posting the patches soon. Plus the KVM patches will be posted based > of the RFC v3 with some fixes if there are no objections from Elena's side > who originally posted KVM RFC patchset. Hi Elena, I'm curious what approach you want to propose for QEMU integration. A while back I thought about the QEMU API. It's possible to implement it along the lines of the memory_region_add_eventfd() API where each ioregionfd is explicitly added by device emulation code. An advantage of this approach is that a MemoryRegion can have multiple ioregionfds, but I'm not sure if that is a useful feature. An alternative is to cover the entire MemoryRegion with one ioregionfd. That way the device emulation code can use ioregionfd without much fuss since there is a 1:1 mapping between MemoryRegions, which are already there in existing devices. There is no need to think deeply about which ioregionfds to create for a device. A new API called memory_region_set_aio_context(MemoryRegion *mr, AioContext *ctx) would cause ioregionfd (or a userspace fallback for non-KVM cases) to execute the MemoryRegion->read/write() accessors from the given AioContext. The details of ioregionfd are hidden behind the memory_region_set_aio_context() API, so the device emulation code doesn't need to know the capabilities of ioregionfd. The second approach seems promising if we want more devices to use ioregionfd inside QEMU because it requires less ioregionfd-specific code. Stefan --PKDBWrlb7QGTn9i6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmF2plAACgkQnKSrs4Gr c8hugQgAsK965URBPD6/lg7f0ucQqEchs2Spk7bGtxC1VOoSL7mxqgDmaNGfqzME BWlS7vNeCaaiT13vsw1H0rDh6QumtlQpnJfNkNnX+K2tjxjZIftNnhlRiN/NHbzN ZbeBAJKlf6yf9wuePTMwu+zxR6yPFIAVVZrvPh27OInSOEkRMCx1MmjqyA3pRnFX gyY8Krxcrgh1rgoyC03MNOkTRTEHExn40sNcIXcqcNfwd1k/dEAXnaiulT1qya1i o/b6L4LGDpw5BwwqsTu2dSJ6+cjhiaJ2BPuSewFjGf8xr37IXKB2hexPmar958sI gvbcgCEHS+0KtUXXb5O8VA3f5HRmNQ== =zbN3 -----END PGP SIGNATURE----- --PKDBWrlb7QGTn9i6--