archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <>
To: "Rustad, Mark D" <>
Cc: ""
	Netdev <>,
	LKML <>,
	"" <>,
	"Daly, Dan" <>,
	Alex Williamson <>,
	"" <>,
	"Michael S. Tsirkin" <>
Subject: Re: [RFC PATCH V4] pci: virtio_pci: Add SR-IOV support for virtio_pci devices
Date: Mon, 26 Feb 2018 10:05:31 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Feb 26, 2018 at 9:48 AM, Rustad, Mark D <> wrote:
> Alex,
>> On Feb 26, 2018, at 7:26 AM, Alexander Duyck <> wrote:
>> Mark,
>> In the future please don't put my "Reviewed-by" on a patch that I
>> haven't reviewed. I believe I reviewed one of the earlier patches, but
>> I hadn't reviewed this version.
> I'm very sorry. I completely spaced doing something about that. I think yours was the first Reviewed-by I ever had in this way. In the future I will remove such things from my changelog right after sending. Thanks for alerting me to what I had failed to do.
>> Also, after thinking about it over the weekend we may want to look at
>> just coming up with a truly "generic" solution that is applied to
>> SR-IOV capable devices that don't have a SR-IOV capable driver loaded
>> on them. That would allow us to handle the uio, vfio, pci-stub, and
>> virtio cases all in one fell swoop. I think us going though and
>> modifying one patch at a time to do this kind of thing isn't going to
>> scale.
> The notion of that kind of troubles me - at least pci-stub does. Having worked on ixgbe a bit, I have to wonder what kind of havoc would ensue if an ixgbe device were assigned to a guest, and an attempt was made to allocate VFs by the pci-stub. The guest could be running any version of the ixgbe driver, possibly even an old one that didn't support SR-IOV. Even if it did support SR-IOV, I don't know how it would respond to mailbox messages when it doesn't think it has VFs.

The assumption here is that the root user knows what they are doing.
We have already had some discussion on this in regards to VFIO. My
thought is we look at adding a new PCI sysfs option called
"sriov_unmanaged_autoprobe" that would be similar to
"sriov_drivers_autoprobe" and is used to determine if we allow for
auto probing of the VFs into the host kernel when SR-IOV is enabled. I
would want to default the value to false so that by default an
unmanaged PF wouldn't have its VFs assigned to the host unless we
specifically enable it by updating the sysfs value.

>> I'll try to do some digging and find the VFIO approach we had been
>> working on. I think with a couple tweaks we can probably make that
>> truly generic and ready for submission.
> I'd like to know more about you are thinking about.

Basic idea is to take your generic SR-IOV enable/disable bits from
( and combine it with the
some of the autoprobe bits and feedback comments from
( The idea would be when
either no driver is loaded, or a driver without the sriov_configure
method we update the iov auto probe setting based on the value we set
via sriov_unamanaged_autoprobe, and then call your generic
configuration method to enable SR-IOV.

  reply	other threads:[~2018-02-26 18:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26  4:48 [RFC PATCH V4] pci: virtio_pci: Add SR-IOV support for virtio_pci devices Mark Rustad
2018-02-26 15:26 ` Alexander Duyck
2018-02-26 17:48   ` Rustad, Mark D
2018-02-26 18:05     ` Alexander Duyck [this message]
2018-02-26 22:38       ` Michael S. Tsirkin
2018-02-26 22:44         ` Alexander Duyck
2018-02-26 22:32   ` Michael S. Tsirkin
2018-02-26 22:38     ` Alexander Duyck
2018-02-26 22:39       ` Michael S. Tsirkin

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).