All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>
To: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Cc: Leonid Shatz <leonid.shatz@ravellosystems.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Idan Brown <idan.brown@ravellosystems.com>,
	Knut Omang <knut.omang@oracle.com>,
	qemu-devel@nongnu.org, Hannes Reinecke <hare@suse.de>
Subject: Re: [Qemu-devel] [PATCH v1] pci: Don't register a specialized 'config_write' if default behavior is intended
Date: Wed, 17 Jun 2015 22:17:58 +0300	[thread overview]
Message-ID: <20150617221758.529fae93@pixies> (raw)
In-Reply-To: <55813FCE.2090405@gmail.com>

Hi,

On Wed, 17 Jun 2015 12:37:18 +0300, marcel.apfelbaum@gmail.com wrote:
> BTW, did you notice a bug here?  If yes, can you elaborate?

No, not a direct bug.
We noticed this while working on related code areas.

There's some history behind this.

In 95d6580 'msi: Invoke msi/msix_write_config from PCI core', the calls
to msi[x]_write_config have been added into pci_default_write_config,
and many specialized 'config_write' methods have been eliminated.

However there was a bug in 95d6580 - the values written to msi/msix
were always 0.
This was recently fixed in d7efb7e
     'pci: avoid losing config updates to MSI/MSIX cap regs'

I assume that device authors were either (1) unware of the
generalization, thus kept invoking msi[x]_write_config explicitly, or
(2) trying to overcome the "lost writes".

Anyway, I'm no PCI expert here, but I assume the side-effect invoking
msi[x]_write_config twice (explicitly from the specialized config_write,
then implicitly from pci_default_write_config) isn't desired.

Meaning, the suggested patch follows the spirit of 95d6580.
Let me know if my analysis is flawed.

Regards,
Shmulik

  reply	other threads:[~2015-06-17 19:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16  8:24 [Qemu-devel] [PATCH v1] pci: Don't register a specialized 'config_write' if default behavior is intended Shmulik Ladkani
2015-06-17  9:36 ` Marcel Apfelbaum
2015-06-17  9:37   ` Marcel Apfelbaum
2015-06-17 19:17     ` Shmulik Ladkani [this message]
2015-06-21  8:20       ` Marcel Apfelbaum
2015-06-21  8:28         ` Shmulik Ladkani
2015-06-17 18:46   ` Shmulik Ladkani
2015-06-21  8:16     ` Marcel Apfelbaum

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=20150617221758.529fae93@pixies \
    --to=shmulik.ladkani@ravellosystems.com \
    --cc=hare@suse.de \
    --cc=idan.brown@ravellosystems.com \
    --cc=jan.kiszka@siemens.com \
    --cc=knut.omang@oracle.com \
    --cc=leonid.shatz@ravellosystems.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.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.