From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"aaronlewis@google.com" <aaronlewis@google.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"dmatlack@google.com" <dmatlack@google.com>,
"vipinsh@google.com" <vipinsh@google.com>,
"seanjc@google.com" <seanjc@google.com>,
"jrhilke@google.com" <jrhilke@google.com>
Subject: Re: [PATCH] vfio/pci: Separate SR-IOV VF dev_set
Date: Thu, 3 Jul 2025 10:23:50 -0300 [thread overview]
Message-ID: <20250703132350.GC1209783@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB52760707F9A737186D818D1F8C43A@BN9PR11MB5276.namprd11.prod.outlook.com>
On Thu, Jul 03, 2025 at 06:10:19AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Thursday, July 3, 2025 1:56 AM
> >
> > On Wed, Jul 02, 2025 at 11:50:32AM -0600, Alex Williamson wrote:
> > > I haven't tried it, but it may be possible to trigger a hot reset
> > > on a user owned PF while there are open VFs. If that is possible, I
> > > wonder if it isn't just a userspace problem though, it doesn't seem
> > > there's anything fundamentally wrong with it from a vfio perspective.
> > > The vf-token already indicates at the kernel level that there is
> > > collaboration between PF and VF userspace drivers.
> >
> > I think it will disable SRIOV and that will leave something of a
> > mess. Arguably we should be blocking resets that disable SRIOV inside
> > vfio?
> >
>
> Is there any reset which doesn't disable SRIOV? According to PCIe
> spec both conventional reset and FLR targeting a PF clears the
> VF enable bit.
This is my understanding, I think there might be a little hole here in
the vfio SRIOV support?
Jason
next prev parent reply other threads:[~2025-07-03 13:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 22:56 [PATCH] vfio/pci: Separate SR-IOV VF dev_set Alex Williamson
2025-06-30 6:32 ` Tian, Kevin
2025-06-30 13:15 ` Yi Liu
2025-06-30 14:57 ` Alex Williamson
2025-07-02 16:00 ` Jason Gunthorpe
2025-07-02 17:50 ` Alex Williamson
2025-07-02 17:55 ` Jason Gunthorpe
2025-07-03 6:10 ` Tian, Kevin
2025-07-03 13:23 ` Jason Gunthorpe [this message]
2025-07-03 20:29 ` Alex Williamson
2025-07-03 23:35 ` Jason Gunthorpe
2025-07-15 18:42 ` Alex Williamson
2025-07-15 18:53 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250703132350.GC1209783@nvidia.com \
--to=jgg@nvidia.com \
--cc=aaronlewis@google.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=dmatlack@google.com \
--cc=jrhilke@google.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=seanjc@google.com \
--cc=vipinsh@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.