All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: bhelgaas@google.com, alexander.h.duyck@intel.com,
	linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, netdev@vger.kernel.org, dan.daly@intel.com,
	linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
	keith.busch@intel.com, netanel@amazon.com, ddutile@redhat.com,
	mheyne@amazon.de, liang-min.wang@intel.com,
	mark.d.rustad@intel.com, dwmw2@infradead.org, hch@lst.de,
	dwmw@amazon.co.uk
Subject: Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Date: Tue, 3 Apr 2018 16:11:33 +0300	[thread overview]
Message-ID: <20180403160847-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180315184132.3102.90947.stgit@localhost.localdomain>

On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> Hardware-realized virtio_pci devices can implement SR-IOV, so this
> patch enables its use. The device in question is an upcoming Intel
> NIC that implements both a virtio_net PF and virtio_net VFs. These
> are hardware realizations of what has been up to now been a software
> interface.
> 
> The device in question has the following 4-part PCI IDs:
> 
> PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
> VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe
> 
> The patch currently needs no check for device ID, because the callback
> will never be made for devices that do not assert the capability or
> when run on a platform incapable of SR-IOV.
> 
> One reason for this patch is because the hardware requires the
> vendor ID of a VF to be the same as the vendor ID of the PF that
> created it. So it seemed logical to simply have a fully-functioning
> virtio_net PF create the VFs. This patch makes that possible.
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>

I thought hard about this, and I think we need a feature
bit for this. This way host can detect support,
and we can also change our minds later if we need
to modify the interface and manage VFs after all.

It seems PCI specific so non pci transports would disable the feature
for now.

> ---
> 
> v4: Dropped call to pci_disable_sriov in virtio_pci_remove function
> v5: Replaced call to pci_sriov_configure_unmanaged with
>         pci_sriov_configure_simple
> v6: Dropped "#ifdef" checks for IOV wrapping sriov_configure definition
> v7: No code change, added Reviewed-by
> 
>  drivers/virtio/virtio_pci_common.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
> index 48d4d1cf1cb6..67a227fd7aa0 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -596,6 +596,7 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)
>  #ifdef CONFIG_PM_SLEEP
>  	.driver.pm	= &virtio_pci_pm_ops,
>  #endif
> +	.sriov_configure = pci_sriov_configure_simple,
>  };
>  
>  module_pci_driver(virtio_pci_driver);
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: bhelgaas@google.com, alexander.h.duyck@intel.com,
	linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, netdev@vger.kernel.org, dan.daly@intel.com,
	linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
	keith.busch@intel.com, netanel@amazon.com, ddutile@redhat.com,
	mheyne@amazon.de, liang-min.wang@intel.com,
	mark.d.rustad@intel.com, dwmw2@infradead.org, hch@lst.de,
	dwmw@amazon.co.uk
Subject: Re: [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Date: Tue, 3 Apr 2018 16:11:33 +0300	[thread overview]
Message-ID: <20180403160847-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180315184132.3102.90947.stgit@localhost.localdomain>

On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> Hardware-realized virtio_pci devices can implement SR-IOV, so this
> patch enables its use. The device in question is an upcoming Intel
> NIC that implements both a virtio_net PF and virtio_net VFs. These
> are hardware realizations of what has been up to now been a software
> interface.
> 
> The device in question has the following 4-part PCI IDs:
> 
> PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
> VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe
> 
> The patch currently needs no check for device ID, because the callback
> will never be made for devices that do not assert the capability or
> when run on a platform incapable of SR-IOV.
> 
> One reason for this patch is because the hardware requires the
> vendor ID of a VF to be the same as the vendor ID of the PF that
> created it. So it seemed logical to simply have a fully-functioning
> virtio_net PF create the VFs. This patch makes that possible.
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>

I thought hard about this, and I think we need a feature
bit for this. This way host can detect support,
and we can also change our minds later if we need
to modify the interface and manage VFs after all.

It seems PCI specific so non pci transports would disable the feature
for now.

> ---
> 
> v4: Dropped call to pci_disable_sriov in virtio_pci_remove function
> v5: Replaced call to pci_sriov_configure_unmanaged with
>         pci_sriov_configure_simple
> v6: Dropped "#ifdef" checks for IOV wrapping sriov_configure definition
> v7: No code change, added Reviewed-by
> 
>  drivers/virtio/virtio_pci_common.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
> index 48d4d1cf1cb6..67a227fd7aa0 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -596,6 +596,7 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)
>  #ifdef CONFIG_PM_SLEEP
>  	.driver.pm	= &virtio_pci_pm_ops,
>  #endif
> +	.sriov_configure = pci_sriov_configure_simple,
>  };
>  
>  module_pci_driver(virtio_pci_driver);
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

WARNING: multiple messages have this Message-ID (diff)
From: mst@redhat.com (Michael S. Tsirkin)
Subject: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Date: Tue, 3 Apr 2018 16:11:33 +0300	[thread overview]
Message-ID: <20180403160847-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180315184132.3102.90947.stgit@localhost.localdomain>

On Thu, Mar 15, 2018@11:42:41AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck at intel.com>
> 
> Hardware-realized virtio_pci devices can implement SR-IOV, so this
> patch enables its use. The device in question is an upcoming Intel
> NIC that implements both a virtio_net PF and virtio_net VFs. These
> are hardware realizations of what has been up to now been a software
> interface.
> 
> The device in question has the following 4-part PCI IDs:
> 
> PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
> VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe
> 
> The patch currently needs no check for device ID, because the callback
> will never be made for devices that do not assert the capability or
> when run on a platform incapable of SR-IOV.
> 
> One reason for this patch is because the hardware requires the
> vendor ID of a VF to be the same as the vendor ID of the PF that
> created it. So it seemed logical to simply have a fully-functioning
> virtio_net PF create the VFs. This patch makes that possible.
> 
> Reviewed-by: Christoph Hellwig <hch at lst.de>
> Signed-off-by: Mark Rustad <mark.d.rustad at intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck at intel.com>

I thought hard about this, and I think we need a feature
bit for this. This way host can detect support,
and we can also change our minds later if we need
to modify the interface and manage VFs after all.

It seems PCI specific so non pci transports would disable the feature
for now.

> ---
> 
> v4: Dropped call to pci_disable_sriov in virtio_pci_remove function
> v5: Replaced call to pci_sriov_configure_unmanaged with
>         pci_sriov_configure_simple
> v6: Dropped "#ifdef" checks for IOV wrapping sriov_configure definition
> v7: No code change, added Reviewed-by
> 
>  drivers/virtio/virtio_pci_common.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
> index 48d4d1cf1cb6..67a227fd7aa0 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -596,6 +596,7 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)
>  #ifdef CONFIG_PM_SLEEP
>  	.driver.pm	= &virtio_pci_pm_ops,
>  #endif
> +	.sriov_configure = pci_sriov_configure_simple,
>  };
>  
>  module_pci_driver(virtio_pci_driver);
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe at lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help at lists.oasis-open.org

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: bhelgaas@google.com, alexander.h.duyck@intel.com,
	linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, netdev@vger.kernel.org, dan.daly@intel.com,
	linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
	keith.busch@intel.com, netanel@amazon.com, ddutile@redhat.com,
	mheyne@amazon.de, liang-min.wang@intel.com,
	mark.d.rustad@intel.com, dwmw2@infradead.org, hch@lst.de,
	dwmw@amazon.co.uk
Subject: Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
Date: Tue, 3 Apr 2018 16:11:33 +0300	[thread overview]
Message-ID: <20180403160847-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180315184132.3102.90947.stgit@localhost.localdomain>

On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> Hardware-realized virtio_pci devices can implement SR-IOV, so this
> patch enables its use. The device in question is an upcoming Intel
> NIC that implements both a virtio_net PF and virtio_net VFs. These
> are hardware realizations of what has been up to now been a software
> interface.
> 
> The device in question has the following 4-part PCI IDs:
> 
> PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
> VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe
> 
> The patch currently needs no check for device ID, because the callback
> will never be made for devices that do not assert the capability or
> when run on a platform incapable of SR-IOV.
> 
> One reason for this patch is because the hardware requires the
> vendor ID of a VF to be the same as the vendor ID of the PF that
> created it. So it seemed logical to simply have a fully-functioning
> virtio_net PF create the VFs. This patch makes that possible.
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>

I thought hard about this, and I think we need a feature
bit for this. This way host can detect support,
and we can also change our minds later if we need
to modify the interface and manage VFs after all.

It seems PCI specific so non pci transports would disable the feature
for now.

> ---
> 
> v4: Dropped call to pci_disable_sriov in virtio_pci_remove function
> v5: Replaced call to pci_sriov_configure_unmanaged with
>         pci_sriov_configure_simple
> v6: Dropped "#ifdef" checks for IOV wrapping sriov_configure definition
> v7: No code change, added Reviewed-by
> 
>  drivers/virtio/virtio_pci_common.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
> index 48d4d1cf1cb6..67a227fd7aa0 100644
> --- a/drivers/virtio/virtio_pci_common.c
> +++ b/drivers/virtio/virtio_pci_common.c
> @@ -596,6 +596,7 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)
>  #ifdef CONFIG_PM_SLEEP
>  	.driver.pm	= &virtio_pci_pm_ops,
>  #endif
> +	.sriov_configure = pci_sriov_configure_simple,
>  };
>  
>  module_pci_driver(virtio_pci_driver);
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  parent reply	other threads:[~2018-04-03 13:11 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 18:40 [pci PATCH v7 0/5] Add support for unmanaged SR-IOV Alexander Duyck
2018-03-15 18:40 ` [virtio-dev] " Alexander Duyck
2018-03-15 18:40 ` Alexander Duyck
2018-03-15 18:41 ` [pci PATCH v7 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources Alexander Duyck
2018-03-15 18:41   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:41   ` Alexander Duyck
2018-03-28 21:30   ` [virtio-dev] " Rustad, Mark D
2018-03-28 21:30     ` Rustad, Mark D
2018-03-28 21:30     ` Rustad, Mark D
2018-03-15 18:42 ` [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices Alexander Duyck
2018-03-15 18:42   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:42   ` Alexander Duyck
2018-03-16 16:34   ` [virtio-dev] " Michael S. Tsirkin
2018-03-16 16:34     ` Michael S. Tsirkin
2018-03-16 16:34     ` Michael S. Tsirkin
2018-03-16 16:40     ` Alexander Duyck
2018-03-16 16:40       ` Alexander Duyck
2018-03-16 16:40       ` Alexander Duyck
2018-04-03 13:12       ` Michael S. Tsirkin
2018-04-03 13:12         ` Michael S. Tsirkin
2018-04-03 13:12         ` Michael S. Tsirkin
2018-04-03 17:32         ` Alexander Duyck
2018-04-03 17:32           ` Alexander Duyck
2018-04-03 17:32           ` Alexander Duyck
2018-04-03 17:32           ` Alexander Duyck
2018-04-03 18:27           ` [virtio-dev] " Michael S. Tsirkin
2018-04-03 18:27             ` Michael S. Tsirkin
2018-04-03 18:27             ` Michael S. Tsirkin
2018-04-03 19:06             ` Alexander Duyck
2018-04-03 19:06               ` Alexander Duyck
2018-04-03 19:06               ` Alexander Duyck
2018-04-20  0:40               ` Michael S. Tsirkin
2018-04-20  0:40                 ` Michael S. Tsirkin
2018-04-20  0:40                 ` Michael S. Tsirkin
2018-04-20  0:40                 ` Michael S. Tsirkin
2018-04-20 14:56                 ` [virtio-dev] " Alexander Duyck
2018-04-20 14:56                   ` Alexander Duyck
2018-04-20 14:56                   ` Alexander Duyck
2018-04-20 15:28                   ` Michael S. Tsirkin
2018-04-20 15:28                     ` Michael S. Tsirkin
2018-04-20 15:28                     ` Michael S. Tsirkin
2018-04-20 15:28                     ` Michael S. Tsirkin
2018-04-20 16:08                     ` [virtio-dev] " Alexander Duyck
2018-04-20 16:08                       ` Alexander Duyck
2018-04-20 16:08                       ` Alexander Duyck
2018-04-20 16:14                       ` Michael S. Tsirkin
2018-04-20 16:14                         ` Michael S. Tsirkin
2018-04-20 16:14                         ` Michael S. Tsirkin
2018-04-21  7:05                     ` Christoph Hellwig
2018-04-21  7:05                       ` Christoph Hellwig
2018-04-03 19:18             ` Rustad, Mark D
2018-04-03 19:18               ` Rustad, Mark D
2018-04-03 19:18               ` Rustad, Mark D
2018-03-28 21:31   ` Rustad, Mark D
2018-03-28 21:31     ` [virtio-dev] " Rustad, Mark D
2018-03-28 21:31     ` Rustad, Mark D
2018-03-28 21:31     ` Rustad, Mark D
2018-04-03 13:11   ` Michael S. Tsirkin [this message]
2018-04-03 13:11     ` [virtio-dev] " Michael S. Tsirkin
2018-04-03 13:11     ` Michael S. Tsirkin
2018-04-03 13:11     ` Michael S. Tsirkin
2018-03-15 18:43 ` [pci PATCH v7 3/5] ena: Migrate over to unmanaged SR-IOV support Alexander Duyck
2018-03-15 18:43   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:43   ` Alexander Duyck
2018-03-15 18:43 ` [pci PATCH v7 4/5] nvme: " Alexander Duyck
2018-03-15 18:43   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:43   ` Alexander Duyck
2018-03-15 18:44 ` [pci PATCH v7 5/5] pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs Alexander Duyck
2018-03-15 18:44   ` [virtio-dev] " Alexander Duyck
2018-03-15 18:44   ` Alexander Duyck
2018-03-16 21:42 ` [pci PATCH v7 0/5] Add support for unmanaged SR-IOV Don Dutile
2018-03-16 21:42   ` Don Dutile
2018-04-19 22:54 ` Alexander Duyck
2018-04-19 22:54   ` [virtio-dev] " Alexander Duyck
2018-04-19 22:54   ` Alexander Duyck
2018-04-20  0:46   ` Michael S. Tsirkin
2018-04-20  0:46     ` [virtio-dev] " Michael S. Tsirkin
2018-04-20  0:46     ` 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:
  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=20180403160847-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=bhelgaas@google.com \
    --cc=dan.daly@intel.com \
    --cc=ddutile@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=dwmw@amazon.co.uk \
    --cc=hch@lst.de \
    --cc=keith.busch@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=liang-min.wang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mark.d.rustad@intel.com \
    --cc=mheyne@amazon.de \
    --cc=netanel@amazon.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtio-dev@lists.oasis-open.org \
    /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.