From: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
To: Shmulik Ladkani <shmulik.ladkani@ravellosystems.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: Sun, 21 Jun 2015 11:20:18 +0300 [thread overview]
Message-ID: <558673C2.1000909@gmail.com> (raw)
In-Reply-To: <20150617221758.529fae93@pixies>
On 06/17/2015 10:17 PM, Shmulik Ladkani wrote:
> 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'
Got it.
>
> 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.
Of course.
>
> Meaning, the suggested patch follows the spirit of 95d6580.
> Let me know if my analysis is flawed.
Thank you for the patch, you are completely right.
My 'Reviewed-by' tag is there, I think Michael, the PCI
maintainer, will take it shortly.
Thanks,
Marcel
>
> Regards,
> Shmulik
>
next prev parent reply other threads:[~2015-06-21 8:20 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
2015-06-21 8:20 ` Marcel Apfelbaum [this message]
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=558673C2.1000909@gmail.com \
--to=marcel.apfelbaum@gmail.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@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shmulik.ladkani@ravellosystems.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.