From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (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 A2488238C0A for ; Fri, 10 Apr 2026 18:18:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775845130; cv=none; b=o77hXGyienFMOR4sX1GrQB3mFuO6mPY97Gg1XoZncxQYbDj/BP58Rg0kAHb+enZhhqZqU32AwYsEiuGJhTb6yYijjTe7hk/PQ3ArVXTwRzgjbgH5PAtIY8wvmdu9ewEhAQVfSLrtpxklYZilIR29yqtNlMT15jGgVXyvmdIggx8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775845130; c=relaxed/simple; bh=82W37ZURpitumCfaNbWD0CDy2223Trc7ZxbLH7eGH/I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=E3BoTYWBI8I1nrMbvu+wyy0m2m/By+lQpYyRfgl/LOz/mpcyJTuZjEPMubJwLd6PDY3WLTHZHI1rxhWhJfsc8i78+YW1/nm7hWC6JRr9HnmAXOl3h/y0TDHsj8dTDn7UwyZWXkpGbVdRkWAPZYepwQPxAW7HQTucjnNid39tX/g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=Q7em18U3; arc=none smtp.client-ip=209.85.219.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="Q7em18U3" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-8a016799d2cso29017476d6.1 for ; Fri, 10 Apr 2026 11:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1775845128; x=1776449928; 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=TI60TYUX37UzbgHqtB7WH/OT/FyRRuVOskjfGwN9GEY=; b=Q7em18U3cAi0LssFNU4qwTlAKai7YkyCizqr2Qcy0FrAEB6eV1s2BCjsZY0aOONJdp AzYPUlwZ6dkgrCjpz6di7E3vPikls/dhovkkdLIBOSe6yocaWLpm4Deee3GGOJMxaYfi KjPKjaQ0AaL5nzeyT/75B3M+kmRhKiHAJcp9dW3MR0Me3Qaj/R1yhC+AsZS39yTttFVq YbfayNLVpvPWHXbPGgfo8abd/QPKGSbAApdLKwn7m4vhQardRTH0y2vv3m9P4hyQkxzS C08i+HG95xb53mX08bnrnEIvp/JWGAweLfL4W1PynPlLXXCbty0GeOVIsbbGyA1rameH /yxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775845128; x=1776449928; 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=TI60TYUX37UzbgHqtB7WH/OT/FyRRuVOskjfGwN9GEY=; b=Wt74tmi3JRUOveg6ebcuPA6RtuutzGP6STCgv2JZgzvADglhGAlZIbmJ3Rgj15MeBW lZQZs49qgA2N8GTk9VdGfjAY0APEOz7/6ipobbIhCovQPWYOoFRUOE54LSAXwYkZWLpK C0t911UzbhBEzEpMGH2Dm3dF0muHzhcIX+SUJS3OWr4+1FTqOON6tt3PEsraG/3AKas4 ccDo56wNrmt8f9z99OZVfr/Xht8iS78E0IfOxvLpY0vWGUEYpMmMBB9PaRyYt05M2C1W dMfkkELzjTNEt0BzeB5ib1r3EeVOactpYAL/28spsvPgc6Rh/wXKfsgWYf6V23VNiluq e7sQ== X-Forwarded-Encrypted: i=1; AJvYcCXgdR6lR+uGMJneR3cGFAeMX7ChVC/DXBmcvjhxy3oeHl7jp3551macVWh1MtIHC9q5a2+2qtgMSbBhP7U=@vger.kernel.org X-Gm-Message-State: AOJu0YwQoyAOcpWFms8YLNRuTvWs9kz7vzSbE+1Wv5vR0l8T0lPfkC2t zjq4wyDKvXmuZ0XMj2aI/b1pgfkIp8RXJ8PAeC9H9YzA4I3Zd++u8NTbZhLMIux5UVc= X-Gm-Gg: AeBDietpZcqWbjdQekBK7XGUazUE16wWEJNedz8GZDvvXVrPFFy452HjHqwe/YByZVM rKWbFHZamfwjuN533kqgfpEjV89OpOMLEtTb/uXsaYHAZ15c4QQUMyn5sIofbo+n0KWJThZ/eAG /gJGcgFoiE3i17JTFCr1QcDaaVTT1O3XxvX1PXFhBxBc8b6yaxVOHQEJTREERmdRGW+ZcdDJ2/0 DT6F7EYsQ5PcRSy72NX2H5o+wf0Hd27x4cQRJlDC3xw1FEeXYusnlrqdf1T8+VFQ7KFh/k4TNLz Vql0dLSvZG3W+tNnwxOhfegWOF2VGZuHKKHQFxfPkFVl0+Xw1/QSCgofyN5MjGODBjxZxAZlUxb s+AHcJoU/NJzLjgO9WAaNhEHY3mJKarsmmeXEmLUQUQ4QbN9XGeluIqATqp1wndmRhtZdbwHNUB oDdPayzVhz5DrUcHjYTodJaMgnxFv07NM9DCf35F9g1ixnsjN3gOa0YVoFwPowS1jRIRJ/jw== X-Received: by 2002:a05:6214:3f81:b0:895:48c2:aedc with SMTP id 6a1803df08f44-8ac862aaea0mr63595236d6.39.1775845127107; Fri, 10 Apr 2026 11:18:47 -0700 (PDT) Received: from ziepe.ca (mctnnbsa70w-159-2-73-22.dhcp-dynamic.fibreop.nb.bellaliant.net. [159.2.73.22]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ac849db735sm35512216d6.2.2026.04.10.11.18.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Apr 2026 11:18:46 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wBGRK-0000000FSR3-0OBy; Fri, 10 Apr 2026 15:18:46 -0300 Date: Fri, 10 Apr 2026 15:18:46 -0300 From: Jason Gunthorpe To: Paolo Bonzini Cc: Sean Christopherson , "Kernel Mailing List, Linux" , kvm , Steffen Eiden , Alex Williamson Subject: Re: [PATCH 1/3] VFIO: take reference to the KVM module Message-ID: <20260410181846.GH2551565@ziepe.ca> References: <20260407180107.1603697-1-pbonzini@redhat.com> <20260407180107.1603697-2-pbonzini@redhat.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: On Fri, Apr 10, 2026 at 10:16:09AM +0200, Paolo Bonzini wrote: > Il gio 9 apr 2026, 20:59 Sean Christopherson ha scritto: > > > > On Tue, Apr 07, 2026, Paolo Bonzini wrote: > > > VFIO is implicitly taking a reference to the KVM module between > > > vfio_device_get_kvm_safe and vfio_device_put_kvm, thanks to > > > symbol_get and symbol_put. > > > > > > In preparation for removing symbol_get and symbol_put themselves > > > from VFIO, actually store a pointer to the KVM module and use > > > module_get()/module_put() to keep KVM alive. > > > > NAK? :-) > > > > I really don't think we should do this. We're reinventing the wheel, and probably > > doing so poorly. As Jason suggested, the proper way to handle this is to pass > > a "struct file" so that e.g. fops_get() pins kvm.ko for us. > > We could get rid of the reference count completely (get_file() as a > replacement for kvm_get_kvm(), get_file_active() as a replacement for > kvm_get_kvm_safe()). struct kvm would need to add a back pointer from > struct kvm to struct file, therefore adding and removing a reference > count would have some additional pointer chasing. KVM has too many > kinds of files to seriously consider passing around struct file* in > virt/kvm/ and arch/*/kvm/, and you'd also have pointer chasing to get > filp->private_data so it wouldn't win much. > > Passing both struct kvm and struct file, instead, would be worse > conceptually than this patch (because VFIO doesn't really care about > the fops as opposed to the module) and uglier: > - you can introduce a back pointer to struct kvm > - you can change all struct kvm_device_ops implementations to receive > a struct file* > > While I can look at using the file reference for struct kvm, I'm not > sure it's a win overall. I would be much happier if vfio could just hang onto the file and kvm could use file->private to get its stuff. It is so much cleaner and simpler and keeps all the kvm stuff away from VFIO. We are trying to do the same design for iommufd's kvm handle too, so I would prefer the symmetry. It seems to hinge on if virt/kvm/vfio.c can call vfio_file_set_kvm() with a file * instead of a kvm *? A back pointer seems like an easy way to do that? Jason