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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A6E0C04AB5 for ; Mon, 3 Jun 2019 22:32:11 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 19BF426AE0 for ; Mon, 3 Jun 2019 22:32:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 19BF426AE0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id AC68A4A3B4; Mon, 3 Jun 2019 18:32:09 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KptWzQtBdUY; Mon, 3 Jun 2019 18:32:07 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0FB284A4A0; Mon, 3 Jun 2019 18:32:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 779CB4A47A for ; Mon, 3 Jun 2019 18:32:05 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHBx4c1q1oBN for ; Mon, 3 Jun 2019 18:32:03 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id C92B94A4A0 for ; Mon, 3 Jun 2019 18:32:03 -0400 (EDT) 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 2496B3087945; Mon, 3 Jun 2019 22:32:03 +0000 (UTC) Received: from x1.home (ovpn-116-22.phx2.redhat.com [10.3.116.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 032CF611D2; Mon, 3 Jun 2019 22:31:59 +0000 (UTC) Date: Mon, 3 Jun 2019 16:31:59 -0600 From: Alex Williamson To: Eric Auger Subject: Re: [PATCH v8 25/29] vfio-pci: Add a new VFIO_REGION_TYPE_NESTED region type Message-ID: <20190603163159.31e7ae23@x1.home> In-Reply-To: <20190526161004.25232-26-eric.auger@redhat.com> References: <20190526161004.25232-1-eric.auger@redhat.com> <20190526161004.25232-26-eric.auger@redhat.com> Organization: Red Hat MIME-Version: 1.0 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.45]); Mon, 03 Jun 2019 22:32:03 +0000 (UTC) Cc: kevin.tian@intel.com, jacob.jun.pan@linux.intel.com, ashok.raj@intel.com, kvm@vger.kernel.org, joro@8bytes.org, will.deacon@arm.com, linux-kernel@vger.kernel.org, marc.zyngier@arm.com, iommu@lists.linux-foundation.org, yi.l.liu@intel.com, vincent.stehle@arm.com, robin.murphy@arm.com, kvmarm@lists.cs.columbia.edu, eric.auger.pro@gmail.com X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Sun, 26 May 2019 18:10:00 +0200 Eric Auger wrote: > This patch adds two new regions aiming to handle nested mode > translation faults. > > The first region (two host kernel pages) is read-only from the > user-space perspective. The first page contains an header > that provides information about the circular buffer located in the > second page. The circular buffer is put in a different page in > the prospect to be mmappable. > > The max user API version supported by the kernel is returned > through a dedicated fault region capability. > > The prod header contains > - the user API version in use (potentially inferior to the one > returned in the capability), > - the offset of the queue within the region, > - the producer index relative to the start of the queue > - the max number of fault records, > - the size of each record. > > The second region is write-only from the user perspective. It > contains the version of the requested fault ABI and the consumer > index that is updated by the userspace each time this latter has > consumed fault records. > > The natural order of operation for the userspace is: > - retrieve the highest supported fault ABI version > - set the requested fault ABI version in the consumer region > > Until the ABI version is not set by the userspace, the kernel > cannot return a comprehensive set of information inside the > prod header (entry size and number of entries in the fault queue). It's not clear to me why two regions are required for this. If the first page is not mmap capable, why does it need to be read-only? If it were not read-only couldn't the fields of the second region also fit within this first page? If you wanted to deal with an mmap capable writeable region, it could just be yet a 3rd page in the first region. > > Signed-off-by: Eric Auger > > --- > > v4 -> v5 > - check cons is not null in vfio_pci_check_cons_fault > > v3 -> v4: > - use 2 separate regions, respectively in read and write modes > - add the version capability > --- > drivers/vfio/pci/vfio_pci.c | 105 ++++++++++++++++++++++++++++ > drivers/vfio/pci/vfio_pci_private.h | 17 +++++ > drivers/vfio/pci/vfio_pci_rdwr.c | 73 +++++++++++++++++++ > include/uapi/linux/vfio.h | 42 +++++++++++ > 4 files changed, 237 insertions(+) > > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c > index cab71da46f4a..f75f61127277 100644 > --- a/drivers/vfio/pci/vfio_pci.c > +++ b/drivers/vfio/pci/vfio_pci.c > @@ -261,6 +261,106 @@ int vfio_pci_set_power_state(struct vfio_pci_device *vdev, pci_power_t state) > return ret; > } > > +void vfio_pci_fault_release(struct vfio_pci_device *vdev, > + struct vfio_pci_region *region) > +{ > +} > + > +static const struct vfio_pci_fault_abi fault_abi_versions[] = { > + [0] = { > + .entry_size = sizeof(struct iommu_fault), > + }, > +}; > + > +#define NR_FAULT_ABIS ARRAY_SIZE(fault_abi_versions) This looks like it's leading to some dangerous complicated code to support multiple user selected ABIs. How many ABIs do we plan to support? The region capability also exposes a type, sub-type, and version. How much of this could be exposed that way? ie. if we need to support multiple versions, expose multiple regions. > + > +static int vfio_pci_fault_prod_add_capability(struct vfio_pci_device *vdev, > + struct vfio_pci_region *region, struct vfio_info_cap *caps) > +{ > + struct vfio_region_info_cap_fault cap = { > + .header.id = VFIO_REGION_INFO_CAP_PRODUCER_FAULT, > + .header.version = 1, > + .version = NR_FAULT_ABIS, > + }; > + return vfio_info_add_capability(caps, &cap.header, sizeof(cap)); > +} > + > +static const struct vfio_pci_regops vfio_pci_fault_cons_regops = { > + .rw = vfio_pci_fault_cons_rw, > + .release = vfio_pci_fault_release, > +}; > + > +static const struct vfio_pci_regops vfio_pci_fault_prod_regops = { > + .rw = vfio_pci_fault_prod_rw, > + .release = vfio_pci_fault_release, > + .add_capability = vfio_pci_fault_prod_add_capability, > +}; > + > +static int vfio_pci_init_fault_region(struct vfio_pci_device *vdev) > +{ > + struct vfio_region_fault_prod *header; > + int ret; > + > + mutex_init(&vdev->fault_queue_lock); > + > + vdev->fault_pages = kzalloc(3 * PAGE_SIZE, GFP_KERNEL); > + if (!vdev->fault_pages) > + return -ENOMEM; > + > + ret = vfio_pci_register_dev_region(vdev, > + VFIO_REGION_TYPE_NESTED, > + VFIO_REGION_SUBTYPE_NESTED_FAULT_PROD, > + &vfio_pci_fault_prod_regops, 2 * PAGE_SIZE, > + VFIO_REGION_INFO_FLAG_READ, vdev->fault_pages); If mmap isn't supported yet, why are we pushing the queue out to the 2nd page? We're just wasting space. vfio_region_fault_prod.offset allows us to relocate it when/if it is mmap capable. > + if (ret) > + goto out; > + > + ret = vfio_pci_register_dev_region(vdev, > + VFIO_REGION_TYPE_NESTED, > + VFIO_REGION_SUBTYPE_NESTED_FAULT_CONS, > + &vfio_pci_fault_cons_regops, > + sizeof(struct vfio_region_fault_cons), > + VFIO_REGION_INFO_FLAG_WRITE, > + vdev->fault_pages + 2 * PAGE_SIZE); What's the remaining (PAGE_SIZE - sizeof(struct vfio_region_fault_cons)) bytes used for? > + if (ret) > + goto out; > + > + header = (struct vfio_region_fault_prod *)vdev->fault_pages; > + header->version = -1; > + header->offset = PAGE_SIZE; > + return 0; > +out: > + kfree(vdev->fault_pages); > + return ret; > +} > + > +int vfio_pci_check_cons_fault(struct vfio_pci_device *vdev, > + struct vfio_region_fault_cons *cons_header) > +{ > + struct vfio_region_fault_prod *prod_header = > + (struct vfio_region_fault_prod *)vdev->fault_pages; > + > + if (cons_header->version > NR_FAULT_ABIS) > + return -EINVAL; > + > + if (!vdev->fault_abi) { > + vdev->fault_abi = cons_header->version; > + prod_header->entry_size = > + fault_abi_versions[vdev->fault_abi - 1].entry_size; > + prod_header->nb_entries = PAGE_SIZE / prod_header->entry_size; Is this sufficient for 4K hosts? Clearly a 64K host has 16x the number of entries, so if this is a heuristic the results are vastly different. > + return 0; > + } > + > + /* Fault ABI is set */ > + if (cons_header->version != vdev->fault_abi) > + return -EINVAL; > + > + if (cons_header->cons && cons_header->cons >= prod_header->nb_entries) First test seems unnecessary. > + return -EINVAL; > + > + return 0; > +} > + > static int vfio_pci_enable(struct vfio_pci_device *vdev) > { > struct pci_dev *pdev = vdev->pdev; > @@ -359,6 +459,10 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev) > } > } > > + ret = vfio_pci_init_fault_region(vdev); > + if (ret) > + goto disable_exit; > + > vfio_pci_probe_mmaps(vdev); > > return 0; > @@ -1374,6 +1478,7 @@ static void vfio_pci_remove(struct pci_dev *pdev) > > vfio_iommu_group_put(pdev->dev.iommu_group, &pdev->dev); > kfree(vdev->region); > + kfree(vdev->fault_pages); > mutex_destroy(&vdev->ioeventfds_lock); > > if (!disable_idle_d3) > diff --git a/drivers/vfio/pci/vfio_pci_private.h b/drivers/vfio/pci/vfio_pci_private.h > index 1812cf22fc4f..8e0a55682d3f 100644 > --- a/drivers/vfio/pci/vfio_pci_private.h > +++ b/drivers/vfio/pci/vfio_pci_private.h > @@ -122,9 +122,12 @@ struct vfio_pci_device { > int ioeventfds_nr; > struct eventfd_ctx *err_trigger; > struct eventfd_ctx *req_trigger; > + struct mutex fault_queue_lock; > + int fault_abi; > struct list_head dummy_resources_list; > struct mutex ioeventfds_lock; > struct list_head ioeventfds_list; > + u8 *fault_pages; > }; > > #define is_intx(vdev) (vdev->irq_type == VFIO_PCI_INTX_IRQ_INDEX) > @@ -153,6 +156,18 @@ extern ssize_t vfio_pci_vga_rw(struct vfio_pci_device *vdev, char __user *buf, > extern long vfio_pci_ioeventfd(struct vfio_pci_device *vdev, loff_t offset, > uint64_t data, int count, int fd); > > +struct vfio_pci_fault_abi { > + u32 entry_size; > +}; > + > +extern size_t vfio_pci_fault_cons_rw(struct vfio_pci_device *vdev, > + char __user *buf, size_t count, > + loff_t *ppos, bool iswrite); > + > +extern size_t vfio_pci_fault_prod_rw(struct vfio_pci_device *vdev, > + char __user *buf, size_t count, > + loff_t *ppos, bool iswrite); > + > extern int vfio_pci_init_perm_bits(void); > extern void vfio_pci_uninit_perm_bits(void); > > @@ -166,6 +181,8 @@ extern int vfio_pci_register_dev_region(struct vfio_pci_device *vdev, > > extern int vfio_pci_set_power_state(struct vfio_pci_device *vdev, > pci_power_t state); > +extern int vfio_pci_check_cons_fault(struct vfio_pci_device *vdev, > + struct vfio_region_fault_cons *header); > > #ifdef CONFIG_VFIO_PCI_IGD > extern int vfio_pci_igd_init(struct vfio_pci_device *vdev); > diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c > index a6029d0a5524..67cd9363f4e7 100644 > --- a/drivers/vfio/pci/vfio_pci_rdwr.c > +++ b/drivers/vfio/pci/vfio_pci_rdwr.c > @@ -277,6 +277,79 @@ ssize_t vfio_pci_vga_rw(struct vfio_pci_device *vdev, char __user *buf, > return done; > } > > +/* Read-only region */ > +size_t vfio_pci_fault_prod_rw(struct vfio_pci_device *vdev, char __user *buf, > + size_t count, loff_t *ppos, bool iswrite) > +{ > + unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) - VFIO_PCI_NUM_REGIONS; > + void *base = vdev->region[i].data; > + loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK; > + int ret = 0; > + > + if (iswrite) > + return 0; > + > + if (!vdev->fault_abi) > + return -EINVAL; > + > + if (pos >= vdev->region[i].size) > + return -EINVAL; > + > + count = min(count, (size_t)(vdev->region[i].size - pos)); > + > + mutex_lock(&vdev->fault_queue_lock); > + > + if (copy_to_user(buf, base + pos, count)) { > + ret = -EFAULT; > + goto unlock; > + } > + *ppos += count; > + ret = count; > +unlock: > + mutex_unlock(&vdev->fault_queue_lock); > + return ret; > +} > + > + > +/* write only */ > +size_t vfio_pci_fault_cons_rw(struct vfio_pci_device *vdev, char __user *buf, > + size_t count, loff_t *ppos, bool iswrite) > +{ > + unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) - VFIO_PCI_NUM_REGIONS; > + void *base = vdev->region[i].data; > + loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK; > + struct vfio_region_fault_cons *header; > + struct vfio_region_fault_cons orig_header = > + *(struct vfio_region_fault_cons *)base; > + int ret = 0; > + > + if (!iswrite) > + return 0; > + > + if (pos >= vdev->region[i].size) > + return -EINVAL; > + > + count = min(count, (size_t)(vdev->region[i].size - pos)); > + > + mutex_lock(&vdev->fault_queue_lock); > + > + if (copy_from_user(base + pos, buf, count)) { > + ret = -EFAULT; > + goto unlock; > + } > + header = (struct vfio_region_fault_cons *)base; > + ret = vfio_pci_check_cons_fault(vdev, header); > + if (ret) { > + *header = orig_header; > + goto unlock; > + } > + *ppos += count; > + ret = count; > +unlock: > + mutex_unlock(&vdev->fault_queue_lock); > + return ret; > +} > + > static int vfio_pci_ioeventfd_handler(void *opaque, void *unused) > { > struct vfio_pci_ioeventfd *ioeventfd = opaque; > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h > index 2774a1ab37ae..13e041b84d48 100644 > --- a/include/uapi/linux/vfio.h > +++ b/include/uapi/linux/vfio.h > @@ -307,6 +307,10 @@ struct vfio_region_info_cap_type { > #define VFIO_REGION_TYPE_GFX (1) > #define VFIO_REGION_SUBTYPE_GFX_EDID (1) > > +#define VFIO_REGION_TYPE_NESTED (2) > +#define VFIO_REGION_SUBTYPE_NESTED_FAULT_PROD (1) > +#define VFIO_REGION_SUBTYPE_NESTED_FAULT_CONS (2) > + > /** > * struct vfio_region_gfx_edid - EDID region layout. > * > @@ -701,6 +705,44 @@ struct vfio_device_ioeventfd { > > #define VFIO_DEVICE_IOEVENTFD _IO(VFIO_TYPE, VFIO_BASE + 16) > > + > +/* > + * Capability exposed by the Producer Fault Region > + * @version: max fault ABI version supported by the kernel > + */ > +#define VFIO_REGION_INFO_CAP_PRODUCER_FAULT 6 > + > +struct vfio_region_info_cap_fault { > + struct vfio_info_cap_header header; > + __u32 version; > +}; > + > +/* > + * Producer Fault Region (Read-Only from user space perspective) > + * Contains the fault circular buffer and the producer index > + * @version: version of the fault record uapi > + * @entry_size: size of each fault record > + * @offset: offset of the start of the queue > + * @prod: producer index relative to the start of the queue > + */ > +struct vfio_region_fault_prod { > + __u32 version; > + __u32 nb_entries; > + __u32 entry_size; > + __u32 offset; > + __u32 prod; > +}; > + > +/* > + * Consumer Fault Region (Write-Only from the user space perspective) > + * @version: ABI version requested by the userspace > + * @cons: consumer index relative to the start of the queue > + */ > +struct vfio_region_fault_cons { > + __u32 version; > + __u32 cons; > +}; I think there are more common semantics than this prod/cons terminology, for example head/tail. > + > /* -------- API for Type1 VFIO IOMMU -------- */ > > /** _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm