All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	alvaro.karsz@solid-run.com, angus.chen@jaguarmicro.com,
	gavinl@nvidia.com, jasowang@redhat.com, lingshan.zhu@intel.com,
	wangdeming@inspur.com, xiujianfeng@huawei.com,
	linuxppc-dev@lists.ozlabs.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [GIT PULL] virtio: fixes, features
Date: Thu, 13 Oct 2022 00:28:25 +1100	[thread overview]
Message-ID: <87mta1marq.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20221012070532-mutt-send-email-mst@kernel.org>

[ Cc += Bjorn & linux-pci ]

"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Wed, Oct 12, 2022 at 05:21:24PM +1100, Michael Ellerman wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
...
>> > ----------------------------------------------------------------
>> > virtio: fixes, features
>> >
>> > 9k mtu perf improvements
>> > vdpa feature provisioning
>> > virtio blk SECURE ERASE support
>> >
>> > Fixes, cleanups all over the place.
>> >
>> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> >
>> > ----------------------------------------------------------------
>> > Alvaro Karsz (1):
>> >       virtio_blk: add SECURE ERASE command support
>> >
>> > Angus Chen (1):
>> >       virtio_pci: don't try to use intxif pin is zero
>> 
>> This commit breaks virtio_pci for me on powerpc, when running as a qemu
>> guest.
>> 
>> vp_find_vqs() bails out because pci_dev->pin == 0.
>> 
>> But pci_dev->irq is populated correctly, so vp_find_vqs_intx() would
>> succeed if we called it - which is what the code used to do.
>> 
>> I think this happens because pci_dev->pin is not populated in
>> pci_assign_irq().
>> 
>> I would absolutely believe this is bug in our PCI code, but I think it
>> may also affect other platforms that use of_irq_parse_and_map_pci().
>
> How about fixing this in of_irq_parse_and_map_pci then?
> Something like the below maybe?
> 
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 196834ed44fe..504c4d75c83f 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -446,6 +446,8 @@ static int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *
>  	if (pin == 0)
>  		return -ENODEV;
>  
> +	pdev->pin = pin;
> +
>  	/* Local interrupt-map in the device node? Use it! */
>  	if (of_get_property(dn, "interrupt-map", NULL)) {
>  		pin = pci_swizzle_interrupt_pin(pdev, pin);

That doesn't fix it in all cases, because there's an early return if
there's a struct device_node associated with the pci_dev, before we even
read the pin.

Also the pci_dev is const, and removing the const would propagate to a
few other places.

The other obvious place to fix it would be in pci_assign_irq(), as
below. That fixes this bug for me, but is otherwise very lightly tested.

cheers


diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
index cc7d26b015f3..0135413b33af 100644
--- a/drivers/pci/setup-irq.c
+++ b/drivers/pci/setup-irq.c
@@ -22,6 +22,15 @@ void pci_assign_irq(struct pci_dev *dev)
 	int irq = 0;
 	struct pci_host_bridge *hbrg = pci_find_host_bridge(dev->bus);
 
+	/* Make sure dev->pin is populated */
+	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
+
+	/* Cope with illegal. */
+	if (pin > 4)
+		pin = 1;
+
+	dev->pin = pin;
+
 	if (!(hbrg->map_irq)) {
 		pci_dbg(dev, "runtime IRQ mapping not provided by arch\n");
 		return;
@@ -34,11 +43,6 @@ void pci_assign_irq(struct pci_dev *dev)
 	 * time the interrupt line passes through a PCI-PCI bridge we must
 	 * apply the swizzle function.
 	 */
-	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
-	/* Cope with illegal. */
-	if (pin > 4)
-		pin = 1;
-
 	if (pin) {
 		/* Follow the chain of bridges, swizzling as we go. */
 		if (hbrg->swizzle_irq)

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: xiujianfeng@huawei.com, kvm@vger.kernel.org,
	alvaro.karsz@solid-run.com, netdev@vger.kernel.org,
	jasowang@redhat.com, wangdeming@inspur.com,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	angus.chen@jaguarmicro.com, Bjorn Helgaas <bhelgaas@google.com>,
	lingshan.zhu@intel.com, linuxppc-dev@lists.ozlabs.org,
	gavinl@nvidia.com
Subject: Re: [GIT PULL] virtio: fixes, features
Date: Thu, 13 Oct 2022 00:28:25 +1100	[thread overview]
Message-ID: <87mta1marq.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20221012070532-mutt-send-email-mst@kernel.org>

[ Cc += Bjorn & linux-pci ]

"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Wed, Oct 12, 2022 at 05:21:24PM +1100, Michael Ellerman wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
...
>> > ----------------------------------------------------------------
>> > virtio: fixes, features
>> >
>> > 9k mtu perf improvements
>> > vdpa feature provisioning
>> > virtio blk SECURE ERASE support
>> >
>> > Fixes, cleanups all over the place.
>> >
>> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> >
>> > ----------------------------------------------------------------
>> > Alvaro Karsz (1):
>> >       virtio_blk: add SECURE ERASE command support
>> >
>> > Angus Chen (1):
>> >       virtio_pci: don't try to use intxif pin is zero
>> 
>> This commit breaks virtio_pci for me on powerpc, when running as a qemu
>> guest.
>> 
>> vp_find_vqs() bails out because pci_dev->pin == 0.
>> 
>> But pci_dev->irq is populated correctly, so vp_find_vqs_intx() would
>> succeed if we called it - which is what the code used to do.
>> 
>> I think this happens because pci_dev->pin is not populated in
>> pci_assign_irq().
>> 
>> I would absolutely believe this is bug in our PCI code, but I think it
>> may also affect other platforms that use of_irq_parse_and_map_pci().
>
> How about fixing this in of_irq_parse_and_map_pci then?
> Something like the below maybe?
> 
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 196834ed44fe..504c4d75c83f 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -446,6 +446,8 @@ static int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *
>  	if (pin == 0)
>  		return -ENODEV;
>  
> +	pdev->pin = pin;
> +
>  	/* Local interrupt-map in the device node? Use it! */
>  	if (of_get_property(dn, "interrupt-map", NULL)) {
>  		pin = pci_swizzle_interrupt_pin(pdev, pin);

That doesn't fix it in all cases, because there's an early return if
there's a struct device_node associated with the pci_dev, before we even
read the pin.

Also the pci_dev is const, and removing the const would propagate to a
few other places.

The other obvious place to fix it would be in pci_assign_irq(), as
below. That fixes this bug for me, but is otherwise very lightly tested.

cheers


diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
index cc7d26b015f3..0135413b33af 100644
--- a/drivers/pci/setup-irq.c
+++ b/drivers/pci/setup-irq.c
@@ -22,6 +22,15 @@ void pci_assign_irq(struct pci_dev *dev)
 	int irq = 0;
 	struct pci_host_bridge *hbrg = pci_find_host_bridge(dev->bus);
 
+	/* Make sure dev->pin is populated */
+	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
+
+	/* Cope with illegal. */
+	if (pin > 4)
+		pin = 1;
+
+	dev->pin = pin;
+
 	if (!(hbrg->map_irq)) {
 		pci_dbg(dev, "runtime IRQ mapping not provided by arch\n");
 		return;
@@ -34,11 +43,6 @@ void pci_assign_irq(struct pci_dev *dev)
 	 * time the interrupt line passes through a PCI-PCI bridge we must
 	 * apply the swizzle function.
 	 */
-	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
-	/* Cope with illegal. */
-	if (pin > 4)
-		pin = 1;
-
 	if (pin) {
 		/* Follow the chain of bridges, swizzling as we go. */
 		if (hbrg->swizzle_irq)

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: xiujianfeng@huawei.com, kvm@vger.kernel.org,
	netdev@vger.kernel.org, wangdeming@inspur.com,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	angus.chen@jaguarmicro.com, Bjorn Helgaas <bhelgaas@google.com>,
	lingshan.zhu@intel.com, linuxppc-dev@lists.ozlabs.org,
	gavinl@nvidia.com
Subject: Re: [GIT PULL] virtio: fixes, features
Date: Thu, 13 Oct 2022 00:28:25 +1100	[thread overview]
Message-ID: <87mta1marq.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20221012070532-mutt-send-email-mst@kernel.org>

[ Cc += Bjorn & linux-pci ]

"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Wed, Oct 12, 2022 at 05:21:24PM +1100, Michael Ellerman wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
...
>> > ----------------------------------------------------------------
>> > virtio: fixes, features
>> >
>> > 9k mtu perf improvements
>> > vdpa feature provisioning
>> > virtio blk SECURE ERASE support
>> >
>> > Fixes, cleanups all over the place.
>> >
>> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> >
>> > ----------------------------------------------------------------
>> > Alvaro Karsz (1):
>> >       virtio_blk: add SECURE ERASE command support
>> >
>> > Angus Chen (1):
>> >       virtio_pci: don't try to use intxif pin is zero
>> 
>> This commit breaks virtio_pci for me on powerpc, when running as a qemu
>> guest.
>> 
>> vp_find_vqs() bails out because pci_dev->pin == 0.
>> 
>> But pci_dev->irq is populated correctly, so vp_find_vqs_intx() would
>> succeed if we called it - which is what the code used to do.
>> 
>> I think this happens because pci_dev->pin is not populated in
>> pci_assign_irq().
>> 
>> I would absolutely believe this is bug in our PCI code, but I think it
>> may also affect other platforms that use of_irq_parse_and_map_pci().
>
> How about fixing this in of_irq_parse_and_map_pci then?
> Something like the below maybe?
> 
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 196834ed44fe..504c4d75c83f 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -446,6 +446,8 @@ static int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *
>  	if (pin == 0)
>  		return -ENODEV;
>  
> +	pdev->pin = pin;
> +
>  	/* Local interrupt-map in the device node? Use it! */
>  	if (of_get_property(dn, "interrupt-map", NULL)) {
>  		pin = pci_swizzle_interrupt_pin(pdev, pin);

That doesn't fix it in all cases, because there's an early return if
there's a struct device_node associated with the pci_dev, before we even
read the pin.

Also the pci_dev is const, and removing the const would propagate to a
few other places.

The other obvious place to fix it would be in pci_assign_irq(), as
below. That fixes this bug for me, but is otherwise very lightly tested.

cheers


diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
index cc7d26b015f3..0135413b33af 100644
--- a/drivers/pci/setup-irq.c
+++ b/drivers/pci/setup-irq.c
@@ -22,6 +22,15 @@ void pci_assign_irq(struct pci_dev *dev)
 	int irq = 0;
 	struct pci_host_bridge *hbrg = pci_find_host_bridge(dev->bus);
 
+	/* Make sure dev->pin is populated */
+	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
+
+	/* Cope with illegal. */
+	if (pin > 4)
+		pin = 1;
+
+	dev->pin = pin;
+
 	if (!(hbrg->map_irq)) {
 		pci_dbg(dev, "runtime IRQ mapping not provided by arch\n");
 		return;
@@ -34,11 +43,6 @@ void pci_assign_irq(struct pci_dev *dev)
 	 * time the interrupt line passes through a PCI-PCI bridge we must
 	 * apply the swizzle function.
 	 */
-	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
-	/* Cope with illegal. */
-	if (pin > 4)
-		pin = 1;
-
 	if (pin) {
 		/* Follow the chain of bridges, swizzling as we go. */
 		if (hbrg->swizzle_irq)
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2022-10-12 13:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10 17:20 [GIT PULL] virtio: fixes, features Michael S. Tsirkin
2022-10-10 17:20 ` Michael S. Tsirkin
2022-10-10 21:23 ` pr-tracker-bot
2022-10-10 21:23   ` pr-tracker-bot
2022-10-12  6:21 ` Michael Ellerman
2022-10-12  6:21   ` Michael Ellerman
2022-10-12  6:21   ` Michael Ellerman
2022-10-12  6:45   ` Angus Chen
2022-10-12  6:45     ` Angus Chen
2022-10-12  7:35   ` Angus Chen
2022-10-12  7:35     ` Angus Chen
2022-10-12 11:11   ` Michael S. Tsirkin
2022-10-12 11:11     ` Michael S. Tsirkin
2022-10-12 11:11     ` Michael S. Tsirkin
2022-10-12 13:28     ` Michael Ellerman [this message]
2022-10-12 13:28       ` Michael Ellerman
2022-10-12 13:28       ` Michael Ellerman
2022-10-12 14:33       ` Michael Ellerman
2022-10-12 14:33         ` Michael Ellerman
2022-10-12 14:33         ` Michael Ellerman
2022-10-12 15:51         ` Michael S. Tsirkin
2022-10-12 15:51           ` Michael S. Tsirkin
2022-10-12 15:51           ` Michael S. Tsirkin
2022-10-12 17:22           ` Linus Torvalds
2022-10-12 17:22             ` Linus Torvalds
2022-10-12 17:22             ` Linus Torvalds
2022-10-12 21:06             ` Arnd Bergmann
2022-10-12 21:06               ` Arnd Bergmann
2022-10-12 21:06               ` Arnd Bergmann
2022-10-12 22:08               ` Michael S. Tsirkin
2022-10-12 22:08                 ` Michael S. Tsirkin
2022-10-12 22:08                 ` Michael S. Tsirkin
2022-10-13  6:28                 ` Arnd Bergmann
2022-10-13  6:28                   ` Arnd Bergmann
2022-10-13  6:28                   ` Arnd Bergmann
2022-10-13 17:19                   ` Linus Torvalds
2022-10-13 17:19                     ` Linus Torvalds
2022-10-13 17:19                     ` Linus Torvalds

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=87mta1marq.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=alvaro.karsz@solid-run.com \
    --cc=angus.chen@jaguarmicro.com \
    --cc=bhelgaas@google.com \
    --cc=gavinl@nvidia.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lingshan.zhu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wangdeming@inspur.com \
    --cc=xiujianfeng@huawei.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.