Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp859120rwl; Wed, 5 Apr 2023 08:35:47 -0700 (PDT) X-Google-Smtp-Source: AKy350YmH9Qe6RZ+sQAQvdLyRS1j/sa+vEfUH8y0DEasIEfTRAbRzoB3x3k2Z67a/8Mku10XG996 X-Received: by 2002:a05:6402:3d3:b0:4fa:e8f3:9685 with SMTP id t19-20020a05640203d300b004fae8f39685mr2078944edw.28.1680708947631; Wed, 05 Apr 2023 08:35:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680708947; cv=none; d=google.com; s=arc-20160816; b=PDBV9qH9aI/MRaNNse3rRjcltc1Bb0hkTeEIp8+bNogLBrAWPAFManvp3TEnuJqYf2 Qwc9V+OVaoQVr4ZsdHdLa3yVkPBNQFJrA5rmvYwCAisWDBf/WhUFbhgPHEnhCXg7X7WC GbOpQfooxxW27nUGC5Ty02zzIXoveGcboZ4yd2M3RzND0obWG8LTsaSRvg+P5HUT7gCr nZ/SXn7+ty2IikbSGEtM102cOqcptbgxlxcIndVq+VdbBATOr9wGbxpLsWHQoO7DfjZI JgGFJSlusTx+pfRXRlGFwk3bXh9VZnRfUXIKYrFLkPqqx8OKHBvf9tuenYkU+9OtIcsK 4tsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=JAA83h3rMO9yiss39MIEuvqUfO0ThiaUitzgjnYkq/E=; b=ORITPh/IlAqahdcjLRGCGuqtMBafYHZ7krRSRMk9c4Z6f8K67eoH5KQbetSUYx+QCS zOurkRu01P6sk3HBgvk0ltgZXRReya0vtFMc5D4cI8aMO2ecoa4DvpC2Adc+T6IaCfWu XbYeZpRAFO8HlR6zWev6J/oKykgbLli98JaUb9ulfYcHKLiH3dmkCCLu2vDNhsJ2v3Kn wyQaw7NYvZzXHO/mn5hHxZ2NV2FkRF5iuB/EgsPcWOO8F3iCsYESWhVg57MdzdYh/V0C EXNfZ5R+Td7Oe9/zLfiTXwL+AdiO3nVWlvpr2dHCBk+/0X9H4H0R0mo3BTIYTl8MYq8d cYjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=VFVjB+wa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g12-20020a056402180c00b005021f0d5755si1398764edy.668.2023.04.05.08.35.23; Wed, 05 Apr 2023 08:35:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=VFVjB+wa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238413AbjDEPdp (ORCPT + 99 others); Wed, 5 Apr 2023 11:33:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237929AbjDEPdn (ORCPT ); Wed, 5 Apr 2023 11:33:43 -0400 Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4ABEE83 for ; Wed, 5 Apr 2023 08:33:42 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id ga7so35361580qtb.2 for ; Wed, 05 Apr 2023 08:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1680708821; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=JAA83h3rMO9yiss39MIEuvqUfO0ThiaUitzgjnYkq/E=; b=VFVjB+wajJZwttZLFmf3dH6GInBwfa6fgjRbdG4XHeLh8yVA+kDknIw516FXMYv7gX SF45vZdirh06fUl+obsZmsZTMVmlK3sbHEmnLMLrlinCZvBHyOK6D00LTyFid2/Uenpx JCdm/5J2HOw2ZLn0wL7sWdFccemN8yuW2S5qA5BbzbpVvN4eMI3j0CSfFH1zA50mzVN9 oSYsv5JvTyg7SDNQMP4nIj9xHu3oeIuYxX+KWDQvTkvKvb1XMedpjmvky27E4AAoGSAt mz3tgDEDM+lt1ipLb9cut24IDz8vWCXeoYiDQximUhIrfv8S4C149xyyu40wmuYsn0Qj AJsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680708821; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JAA83h3rMO9yiss39MIEuvqUfO0ThiaUitzgjnYkq/E=; b=epprPSiTSyELbXQkiBwmSB0saUlYu1PUEVl8X/9dnOjSwbS98AaeapaSwxRnriZ4B7 Xz4cmSclZi1PraCfFAdSr004FPEjt/ZKUQPo9ZIeslWok/J81fcLqcvFIZ8MmLPFKJpE 6fK3pGFapL0ozyxJkhwQYAi/LM9CFi39MjUaV01V1tU8yMAv07C6LR2l1t2tUQbiXKht 7WX0T795uwL2Y6viAXSWSil7FU5PaF3SIRD1xn8OtuzEQkfQ2FFxq4ovQv0CNPqIPF60 1QdBsajTSSgbSjMwOywODlASgDc0yEbz8gdqNI07dpG2FfmO+va6G985HQ9i65s5Pmv2 pNuQ== X-Gm-Message-State: AAQBX9dWAlV3t1qZIyLwNiTov2/RyBJ4eehdq6aKctbCqUVEwlQZHuPw b2ph5lwnz0j9T/Cysp4QvcqJYQ== X-Received: by 2002:a05:622a:1749:b0:3e3:86d4:5df0 with SMTP id l9-20020a05622a174900b003e386d45df0mr5606985qtk.55.1680708821401; Wed, 05 Apr 2023 08:33:41 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-68-25-194.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.25.194]) by smtp.gmail.com with ESMTPSA id 84-20020a370a57000000b007422fa6376bsm4500271qkk.77.2023.04.05.08.33.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Apr 2023 08:33:40 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1pk58m-007MHn-08; Wed, 05 Apr 2023 12:33:40 -0300 Date: Wed, 5 Apr 2023 12:33:39 -0300 From: Jason Gunthorpe To: Nipun Gupta Cc: alex.williamson@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, git@amd.com, harpreet.anand@amd.com, michal.simek@amd.com Subject: Re: [PATCH] vfio/cdx: add support for CDX bus Message-ID: References: <20230403142525.29494-1-nipun.gupta@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230403142525.29494-1-nipun.gupta@amd.com> X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 03, 2023 at 07:55:25PM +0530, Nipun Gupta wrote: > +enum { > + CDX_ID_F_VFIO_DRIVER_OVERRIDE = 1, > +}; This seems to be missing the file2alias part. > +static void vfio_cdx_regions_cleanup(struct vfio_cdx_device *vdev) > +{ > + kfree(vdev->regions); > +} > + > +static int vfio_cdx_reset_device(struct vfio_cdx_device *vdev) > +{ > + return cdx_dev_reset(&vdev->cdx_dev->dev); > +} Wrapper functions should be avoided. > +static void vfio_cdx_close_device(struct vfio_device *core_vdev) > +{ > + struct vfio_cdx_device *vdev = > + container_of(core_vdev, struct vfio_cdx_device, vdev); > + int ret; > + > + vfio_cdx_regions_cleanup(vdev); > + > + /* reset the device before cleaning up the interrupts */ > + ret = vfio_cdx_reset_device(vdev); > + if (WARN_ON(ret)) > + dev_warn(core_vdev->dev, > + "VFIO_CDX: reset device has failed (%d)\n", ret); This is pretty problematic.. if the reset can fail the device is returned to the system in an unknown state and it seems pretty likely that it can be a way to attack the kernel. > + case VFIO_DEVICE_RESET: > + { > + return vfio_cdx_reset_device(vdev); > + } What happens to MMIO access during this reset? > +static int vfio_cdx_mmap_mmio(struct vfio_cdx_region region, > + struct vm_area_struct *vma) > +{ > + u64 size = vma->vm_end - vma->vm_start; > + u64 pgoff, base; > + > + pgoff = vma->vm_pgoff & > + ((1U << (VFIO_CDX_OFFSET_SHIFT - PAGE_SHIFT)) - 1); > + base = pgoff << PAGE_SHIFT; > + > + if (region.size < PAGE_SIZE || base + size > region.size) > + return -EINVAL; > + > + vma->vm_pgoff = (region.addr >> PAGE_SHIFT) + pgoff; > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); pgprot_device > + return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, > + size, vma->vm_page_prot); io_remap_pfn_range > +static int vfio_cdx_mmap(struct vfio_device *core_vdev, > + struct vm_area_struct *vma) > +{ > + struct vfio_cdx_device *vdev = > + container_of(core_vdev, struct vfio_cdx_device, vdev); > + struct cdx_device *cdx_dev = vdev->cdx_dev; > + unsigned int index; > + > + index = vma->vm_pgoff >> (VFIO_CDX_OFFSET_SHIFT - PAGE_SHIFT); > + > + if (vma->vm_end < vma->vm_start) > + return -EINVAL; > + if (vma->vm_start & ~PAGE_MASK) > + return -EINVAL; > + if (vma->vm_end & ~PAGE_MASK) > + return -EINVAL; The core code already assures these checks. > + if (!(vma->vm_flags & VM_SHARED)) > + return -EINVAL; > + if (index >= cdx_dev->res_count) > + return -EINVAL; > + > + if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_MMAP)) > + return -EINVAL; > + > + if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_READ) && > + (vma->vm_flags & VM_READ)) > + return -EINVAL; > + > + if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE) && > + (vma->vm_flags & VM_WRITE)) > + return -EINVAL; > + > + vma->vm_private_data = cdx_dev; not needed > diff --git a/drivers/vfio/cdx/vfio_cdx_private.h b/drivers/vfio/cdx/vfio_cdx_private.h > new file mode 100644 > index 000000000000..8b6f1ee3f5cd > --- /dev/null > +++ b/drivers/vfio/cdx/vfio_cdx_private.h > @@ -0,0 +1,32 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2022-2023, Advanced Micro Devices, Inc. > + */ > + > +#ifndef VFIO_CDX_PRIVATE_H > +#define VFIO_CDX_PRIVATE_H > + > +#define VFIO_CDX_OFFSET_SHIFT 40 > +#define VFIO_CDX_OFFSET_MASK (((u64)(1) << VFIO_CDX_OFFSET_SHIFT) - 1) > + > +#define VFIO_CDX_OFFSET_TO_INDEX(off) ((off) >> VFIO_CDX_OFFSET_SHIFT) > + > +#define VFIO_CDX_INDEX_TO_OFFSET(index) \ > + ((u64)(index) << VFIO_CDX_OFFSET_SHIFT) use static inlines for function-line macros > +struct vfio_cdx_region { > + u32 flags; > + u32 type; > + u64 addr; > + resource_size_t size; > + void __iomem *ioaddr; > +}; > + > +struct vfio_cdx_device { > + struct vfio_device vdev; > + struct cdx_device *cdx_dev; > + struct device *dev; > + struct vfio_cdx_region *regions; > +}; This header file does not seem necessary right now Jason