Received: by 10.223.176.5 with SMTP id f5csp198167wra; Tue, 6 Feb 2018 20:26:32 -0800 (PST) X-Google-Smtp-Source: AH8x227o9T4O6XeTVl83sqgSXyqd5bH8ZfZhNWUI65S48lokAciqzyaNlBfntR0QTg2M+TwCrF// X-Received: by 2002:a17:902:7e43:: with SMTP id a3-v6mr4757925pln.138.1517977592477; Tue, 06 Feb 2018 20:26:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517977592; cv=none; d=google.com; s=arc-20160816; b=j/r0OL15pTJkXiYgWOg57wVYtfPah+bQvlfyGK1MpcLO8/9gR4Z/6QACdy20XjKVmB tLchfBIvjLWZUMWFC4gpcsR1FZ5d+Mdq8lVsCnzor1dbm7RAoQCGpHb36Ky6iWiTl+PI IAvif4T8rgeKpIxANfRMlRePPbYUICQKmAWmepiSpg9l673qvEKakjEbX7LJ0GX2YsAH UYGArS6bl1Py5Qvd2E9dkF7H67xuw3rfhcUxQzr/QzdC/uUl4WN6nWVvqNFht9UthkXm 2cD5JiIL3hDj811QLooe7/H5HoVZcCLgBfRpgtJAEVKz7POV5prt0B7aHARL5vyOtdn3 k6eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=WOXR6nkH7L99fhnkoKFoBCXXgyKuoEAS8HFEY/gabeQ=; b=QwH+qgdnC0NaIPzWfMwQVzq0F/4Yw0DBtm1a9v+XUBOg30XR0cnijitLJNhVeQqmR8 LYMpEZLMm1ApXyzirX0UcvTka2XnMSHhI+yoKVCp1YE69ne/u/TIYPkf5yWi6kv/LWAX k4Gw8/pvnRoucHajnVnsoZDi1CIxGP0QNRbmxzQsbU9v2nyHYpFKlvLRCX8sWPAMEuUQ XrJpQXvhcKpybgsQY4qlhCMmjoA71tQx6soYeGNSp7OA9yTF+rCe1L5gngJuKmDolgsV H1zK3r28yJ4zwfMBvKohK3b/Gmp3e0gbGLjoFt88qNlnd4EMn09vD3tYVIjmg03lvOgd PjHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bb10-v6si474008plb.290.2018.02.06.20.26.18; Tue, 06 Feb 2018 20:26:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753174AbeBGEZl (ORCPT + 99 others); Tue, 6 Feb 2018 23:25:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55918 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752540AbeBGEZj (ORCPT ); Tue, 6 Feb 2018 23:25:39 -0500 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 mx1.redhat.com (Postfix) with ESMTPS id C4B6F80468; Wed, 7 Feb 2018 04:25:39 +0000 (UTC) Received: from w520.home (ovpn-117-203.phx2.redhat.com [10.3.117.203]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7364D6E3E2; Wed, 7 Feb 2018 04:25:39 +0000 (UTC) Date: Tue, 6 Feb 2018 21:25:38 -0700 From: Alex Williamson To: Alexey Kardashevskiy Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org Subject: Re: [RFC PATCH] vfio/pci: Add ioeventfd support Message-ID: <20180206212538.50ef0e13@w520.home> In-Reply-To: References: <20180207000731.32764.95992.stgit@gimli.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 07 Feb 2018 04:25:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Feb 2018 15:09:22 +1100 Alexey Kardashevskiy wrote: > On 07/02/18 11:08, Alex Williamson wrote: > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h > > index e3301dbd27d4..07966a5f0832 100644 > > --- a/include/uapi/linux/vfio.h > > +++ b/include/uapi/linux/vfio.h > > @@ -503,6 +503,30 @@ struct vfio_pci_hot_reset { > > > > #define VFIO_DEVICE_PCI_HOT_RESET _IO(VFIO_TYPE, VFIO_BASE + 13) > > > > +/** > > + * VFIO_DEVICE_IOEVENTFD - _IOW(VFIO_TYPE, VFIO_BASE + 14, > > + * struct vfio_device_ioeventfd) > > + * > > + * Perform a write to the device at the specified device fd offset, with > > + * the specified data and width when the provided eventfd is triggered. > > + * > > + * Return: 0 on success, -errno on failure. > > + */ > > +struct vfio_device_ioeventfd { > > + __u32 argsz; > > + __u32 flags; > > +#define VFIO_DEVICE_IOEVENTFD_8 (1 << 0) /* 1-byte write */ > > +#define VFIO_DEVICE_IOEVENTFD_16 (1 << 1) /* 2-byte write */ > > +#define VFIO_DEVICE_IOEVENTFD_32 (1 << 2) /* 4-byte write */ > > +#define VFIO_DEVICE_IOEVENTFD_64 (1 << 3) /* 8-byte write */ > > +#define VFIO_DEVICE_IOEVENTFD_SIZE_MASK (0xf) > > + __u64 offset; /* device fd offset of write */ > > + __u64 data; /* data to be written */ > > + __s32 fd; /* -1 for de-assignment */ > > +}; > > + > > +#define VFIO_DEVICE_IOEVENTFD _IO(VFIO_TYPE, VFIO_BASE + 14) > > > Is this a first ioctl with endianness fixed to little-endian? I'd suggest > to comment on that as things like vfio_info_cap_header do use the host > endianness. Look at our current read and write interface, we call leXX_to_cpu before calling iowriteXX there and I think a user would logically expect to use the same data format here as they would there. Also note that iowriteXX does a cpu_to_leXX, so are we really defining the interface as little-endian or are we just trying to make ourselves endian neutral and counter that implicit conversion? Thanks, Alex