From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Hervé Poussineau" <hpoussin@reactos.org>
Cc: "Isaku Yamahata" <yamahata@valinux.co.jp>,
"Andreas Färber" <andreas.faerber@web.de>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH, RFC] pci: allow PCI devices to fix address space
Date: Wed, 22 Dec 2010 08:49:22 +0200 [thread overview]
Message-ID: <20101222064921.GE7814@redhat.com> (raw)
In-Reply-To: <4D119B09.30103@reactos.org>
On Wed, Dec 22, 2010 at 07:30:33AM +0100, Hervé Poussineau wrote:
> Isaku Yamahata a écrit :
> >On Wed, Dec 22, 2010 at 12:20:23AM +0100, Andreas Färber wrote:
> >>From: Hervé Poussineau <hpoussin@reactos.org>
> >>
> >>v1:
> >>* Rebased.
> >>
> >>Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
> >>Cc: Michael S. Tsirkin <mst@redhat.com>
> >>Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> >>---
> >> Hello Michael,
> >> Could you please take a look at this? I'm out of my field here.
> >> The intention of the first part appears to be to save (val & ~mask),
> >> whereas the inline helper would've returned (val & mask).
> >
> >Such behavior is intended.
> >The returned value is just discarded in this case.
> >test-and-clear means
> > clear the bits
> > return if those cleared bits were really set.
> >
What about this first chunk? Is it necessary.
> >> The second part makes existing code conditional on that value.
> >
> >What issue are you addressing?
> >Although the spec doesn't says about the default value of BAR registers
> >after reset, the current code assumes that almost all the pci devices clear
> >those registers.
> >Anyway after cold/warm reset firmware sets up BARs, so it doesn't matter.
> >You, however, seem to want to keep BARs over resets.
> >
> >thanks,
> >
> >
> As you have seen, the intend here is to be able to keep BARs over resets.
> It is required for some really specific devices, like a PCI to ISA
> bridge, where MMIO is always at the same address.
> In that case, the device keeps PCI_COMMAND_MEMORY and/or
> PCI_COMMAND_IO flags as read-only.
>
> Hervé
Aha. Are the BARs still writeable? If not maybe that's the right thing
to check? If yes maybe the device simply should have a reset
handler to rewrite them?
Also I would like the above text (maybe a bit shortened) to replace the comment:
/* Reset region address, as it it is not read-only */
the general idea is to document the reason the code
is what it is, not restate what it does.
Something similar should also go into the commit message I think.
> >> Regards,
> >> Andreas
> >> hw/pci.c | 22 ++++++++++++++--------
> >> 1 files changed, 14 insertions(+), 8 deletions(-)
> >>
> >>diff --git a/hw/pci.c b/hw/pci.c
> >>index ef00d20..4db4b1f 100644
> >>--- a/hw/pci.c
> >>+++ b/hw/pci.c
> >>@@ -140,6 +140,7 @@ static void pci_update_irq_status(PCIDevice *dev)
> >> static void pci_device_reset(PCIDevice *dev)
> >> {
> >> int r;
> >>+ uint16_t cmd;
> >> /* TODO: call the below unconditionally once all pci devices
> >> * are qdevified */
> >> if (dev->qdev.info) {
> >>@@ -149,9 +150,10 @@ static void pci_device_reset(PCIDevice *dev)
> >> dev->irq_state = 0;
> >> pci_update_irq_status(dev);
> >> /* Clear all writeable bits */
> >>- pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
> >>- pci_get_word(dev->wmask + PCI_COMMAND) |
> >>- pci_get_word(dev->w1cmask + PCI_COMMAND));
> >>+ cmd = pci_get_word(dev->config + PCI_COMMAND);
> >>+ cmd &= ~(pci_get_word(dev->wmask + PCI_COMMAND) |
> >>+ pci_get_word(dev->w1cmask + PCI_COMMAND));
> >>+ pci_set_word(dev->config + PCI_COMMAND, cmd);
> >> pci_word_test_and_clear_mask(dev->config + PCI_STATUS,
> >> pci_get_word(dev->wmask + PCI_STATUS) |
> >> pci_get_word(dev->w1cmask + PCI_STATUS));
> >>@@ -163,11 +165,15 @@ static void pci_device_reset(PCIDevice *dev)
> >> continue;
> >> }
> >>- if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
> >>- region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> >>- pci_set_quad(dev->config + pci_bar(dev, r), region->type);
> >>- } else {
> >>- pci_set_long(dev->config + pci_bar(dev, r), region->type);
> >>+ if ((region->type == PCI_BASE_ADDRESS_SPACE_IO && !(cmd & PCI_COMMAND_MEMORY)) ||
> >>+ (region->type == PCI_BASE_ADDRESS_SPACE_MEMORY && !(cmd & PCI_COMMAND_IO))) {
These lines are too long.
> >>+ /* Reset region address, as it it is not read-only */
Checking wmask would be more straight-forward?
> >>+ if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
> >>+ region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> >>+ pci_set_quad(dev->config + pci_bar(dev, r), region->type);
> >>+ } else {
> >>+ pci_set_long(dev->config + pci_bar(dev, r), region->type);
> >>+ }
> >> }
> >> }
> >> pci_update_mappings(dev);
> >>--
> >>1.7.3.4
> >>
> >>
> >
next prev parent reply other threads:[~2010-12-22 6:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-21 23:20 [Qemu-devel] [PATCH, RFC] pci: allow PCI devices to fix address space Andreas Färber
2010-12-22 2:50 ` Isaku Yamahata
2010-12-22 6:24 ` Michael S. Tsirkin
2010-12-22 6:30 ` Hervé Poussineau
2010-12-22 6:49 ` Michael S. Tsirkin [this message]
2011-06-12 11:36 ` Andreas Färber
2011-06-12 12:40 ` Hervé Poussineau
2011-06-12 14:20 ` Andreas Färber
2011-06-12 18:28 ` Hervé Poussineau
2011-06-12 19:35 ` Michael S. Tsirkin
2011-06-12 19:53 ` Michael S. Tsirkin
2011-06-12 19:33 ` Michael S. Tsirkin
2011-06-12 19:50 ` Hervé Poussineau
2011-06-12 19:59 ` 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=20101222064921.GE7814@redhat.com \
--to=mst@redhat.com \
--cc=andreas.faerber@web.de \
--cc=hpoussin@reactos.org \
--cc=qemu-devel@nongnu.org \
--cc=yamahata@valinux.co.jp \
/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 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).