From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f50.google.com (mail-dl1-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 625BD3B7748 for ; Mon, 13 Apr 2026 18:08:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776103724; cv=none; b=FwZYF51XsTwatSBThvWWws0E0e1zF1ES51T+VR21K8iYHZ6/G3qn3vgQ6qhjNDgDIwWhr/kzyUOKTNsTGPLSGpBf5r9gW2XUY83z8C24Lw52Isi+fyqogU0iFoAIw39qNpBakCOLpwiiCFq1gB3ppX6fHOGI0A8aHowkMrxhUEQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776103724; c=relaxed/simple; bh=sTTBFXUQvlG7va6ESRKWpJsoua7hOEDkjIePlaumAi0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=E15HeZVZqbBeP0RfRwrIkZoLK7mX5YpCtMkg3SUasD4FjVcPAAy7LocZomvk/P7s8d39xpMLRw84hH5rKwgONmuimyJZwnAcK0+ob0rPnwLMZV5HjdmPTKKpmrB4puoUBNoqKufmDIEpxnC5tpOa02D3eMK4XgU7zaxpm9XSng0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=otYht39s; arc=none smtp.client-ip=74.125.82.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="otYht39s" Received: by mail-dl1-f50.google.com with SMTP id a92af1059eb24-126ea4e9697so41158c88.1 for ; Mon, 13 Apr 2026 11:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776103722; x=1776708522; darn=vger.kernel.org; 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=ihnbQ8DAwZ608jSyPeNkvNqcC3UO+2nLmbAoi4r5+eE=; b=otYht39sD9AvSFujZ3I/39+EosuPsYltPCZJy9O/XYrgQHNc9QHvlJIZDpgG7NIPCF EAfMgBcmENkz+cMA9czguCw8UHg5P05I+8/AG6kM6MfwukCbeq89gkMWW9CTZmVfSua0 tZQ3JnIGJg0jSzSdYo8jatpADuqkTYUpCnX+Stwg3EVPVzX/vorL5/8haYeH9BXAQBSX QhXqvnUCt/RXf3J5NnrJy6MprppiaX7UDcl5N4ZgvLcWtAz38CHpUA95ZoKFTtT9ykHL svamRMf+fAgxSf+vVVQPZUYAFvAsSzd7HLBXwMqD52499clSVLpTa6ujwc+BoKzQarjk zGFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776103722; x=1776708522; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ihnbQ8DAwZ608jSyPeNkvNqcC3UO+2nLmbAoi4r5+eE=; b=AGNjlrKCY2l5MpYRApdGZkI6F4rAyJRgsjlWag+Bh3YJSHmmwDFYJwYgBTZpJETrW6 2tZbWS23RDLUeIOrtOF6MrsRhr+xt/wobN7640jiwf0jsZRFwHiZIv1jGI9oCEsJvn27 J+vi6uCptki9vFgijlAGQGnURx6KyOvAQI9A3pzBgFGz951bWbMKh2mNPOoeInCjb65p d5Y7lVp04oIiafZeGY9r2V30vYHnANdIaXZp4iiM/ezUVpHtOKLWciQXOFtilnrpADkr wJlwL1IRKWiW5rTVr2RRglhgoWXbinKKBn61uorPhB7LUOVuI7aPdGGM8cDvtPM8AsbK jHMA== X-Forwarded-Encrypted: i=1; AFNElJ+0DcuIyc+mVE4Y1frUFMbZlb6VejT0+ww+RE+FSvQWjblhfBtVZiV9GhHfvFjqOSGnDKYu4bzglEyZCsE=@vger.kernel.org X-Gm-Message-State: AOJu0YyDRWkS7DBgpPRurFcqY7n6w1HTp94ztJ68W6kI1VxFhm1iGrxJ VtDidIt/PDy1tlV57Pf40cympwQHJQ7yVs3PhjowlTuZkFRInlxg3L3Y/72oszQyaA== X-Gm-Gg: AeBDieuCqmBn0PDs6COULa0HP0td6UVZ+MdEUppZPeLUQzb1KpCq1HqTZhY9tCYRUHT ClT49Bumlm+4shrZDqsfWffeRTns1+xDhW5UsS/neyuXkQckDWd0JzdZ18vznYnJGJDFQZ8vXJL GoOR+0uo7mFaajiJ6rCm78IclTKKCCVHFs3A6DM+DJdye/oy/lAjSpWtPkBZAQCh92qlht6Bbeo Y7/dSiAx1kChPUh2mO9R1ooJ1p8guSEN52nLVk81v8v7gz/o9I9YBtyuYgmlbfS1yIia+wHh92y uXgtMZE2mS7d0X5R6FgErDOFellO6j1C9aTR7KoBqK8+8CRlAxWoA9RbKRBLyoGDkejIUgSeVGd LhXEwt4kCgmttmZZELJvQCVaFShNx/86wJN+qppZuwTEqpyTe/R6Wbgp0VYE4y5Hd7azCbxDxup seB7jWSLQ5T2oOID4VFINaKGMQCiCwGN7sW7OtZMg+hzYujToy8ExvXFSp0V+8aB2UjoAWI3v+u WZveWSQ X-Received: by 2002:a05:7022:48e:b0:128:ba6e:f809 with SMTP id a92af1059eb24-12c28ea0f68mr695867c88.6.1776103721868; Mon, 13 Apr 2026 11:08:41 -0700 (PDT) Received: from google.com (60.89.247.35.bc.googleusercontent.com. [35.247.89.60]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2d561cd2c09sm20302457eec.18.2026.04.13.11.08.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2026 11:08:41 -0700 (PDT) Date: Mon, 13 Apr 2026 11:08:36 -0700 From: Vipin Sharma To: Raghavendra Rao Ananta Cc: David Matlack , Alex Williamson , Josh Hilke , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 8/8] vfio: selftests: Add tests to validate SR-IOV UAPI Message-ID: <20260413165308.GA3034974.vipinsh@google.com> References: <20260402173059.1018805-1-rananta@google.com> <20260402173059.1018805-9-rananta@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260402173059.1018805-9-rananta@google.com> On Thu, Apr 02, 2026 at 05:30:59PM +0000, Raghavendra Rao Ananta wrote: > diff --git a/tools/testing/selftests/vfio/vfio_pci_sriov_uapi_test.c b/tools/testing/selftests/vfio/vfio_pci_sriov_uapi_test.c > +static struct vfio_pci_device *device_init(const char *bdf, struct iommu *iommu, > + const char *vf_token, int *out_ret) > +{ > + struct vfio_pci_device *device = vfio_pci_device_alloc(bdf, iommu); > + > + if (iommu->mode->container_path) > + *out_ret = container_setup(device, bdf, vf_token); > + else > + *out_ret = iommufd_setup(device, bdf, vf_token); > + > + return device; I will recommend to return the error code and pass struct vfio_pci_device **out_dev in the arguments. This seems more natural compared to having a last argument as an ret value which is checked in the caller. > + > +/* > + * PF's token is always set with UUID_1 and VF's token is rotated with > + * various tokens (including UUID_1 and NULL). Nit: s/UUID_1/UUID_2 > + * This asserts if the VF device is successfully created for a match > + * in the token or actually fails during a mismatch. > + */ > +#define ASSERT_VF_CREATION(_ret) do { \ > + if (!variant->vf_token || strcmp(UUID_1, variant->vf_token)) { \ > + ASSERT_NE((_ret), 0); \ > + } else { \ > + ASSERT_EQ((_ret), 0); \ > + } \ > +} while (0) > + > +/* > + * Validate if the UAPI handles correctly and incorrectly set token on the VF. > + */ > +TEST_F(vfio_pci_sriov_uapi_test, init_token_match) > +{ > + struct vfio_pci_device *pf; > + struct vfio_pci_device *vf; > + struct iommu *iommu; > + int ret; > + > + iommu = iommu_init(variant->iommu_mode); > + > + pf = device_init(pf_bdf, iommu, UUID_1, &ret); > + ASSERT_EQ(ret, 0); > + > + vf = device_init(vf_bdf, iommu, variant->vf_token, &ret); > + ASSERT_VF_CREATION(ret); ASSERT_VF_CREATION() name is confusing, as it is asserting both success and failure ret value based on the variant passed. I will recommend to rename it to ASSERT_COND_VF_CREATION(), or, may be create a wrapper function to check if current test is a UUID_1 variant or not, and then directly the assert needed. > +/* > + * After setting a token on the PF, validate if the VF can still set the > + * expected token. > + */ This comment seems incorrect. VF doesn't set the token, it just provides the token which is set on a PF. May be a comment can be "After closing the PF, validate VF access still needs the right token. > +TEST_F(vfio_pci_sriov_uapi_test, override_token) > +{ > + struct vfio_pci_device *pf; > + struct vfio_pci_device *vf; > + struct iommu *iommu; > + int ret; > + > + iommu = iommu_init(variant->iommu_mode); > + > + pf = device_init(pf_bdf, iommu, UUID_2, &ret); I am assuming because of this, you cannot move device_init and device_cleanup calls to FIXTURE_SETUP and FIXTURE_TEARDOWN respectively. Can we just start this test with device_cleanup(), then do init with UUID_2? This will allow to reduce the code in all of the tests by moving things to corresponding setup and teardown functions. WDYT? > + > +static void vf_setup(void) > +{ > + char *vf_driver; > + int nr_vfs; > + > + nr_vfs = sysfs_sriov_totalvfs_get(pf_bdf); > + if (nr_vfs <= 0) > + ksft_exit_skip("SR-IOV may not be supported by the PF: %s\n", pf_bdf); > + > + nr_vfs = sysfs_sriov_numvfs_get(pf_bdf); > + if (nr_vfs != 0) > + ksft_exit_skip("SR-IOV already configured for the PF: %s\n", pf_bdf); Why would we want to skip if VFs are already enabled. Just set it to 0 if it is already there and set it to 1 unconditionally after that.