From: Alex Williamson <alex.williamson@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: chrisw@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Re: [PATCH 1/8] pci: pci_default_cap_write_config ignores wmask
Date: Thu, 11 Nov 2010 23:03:19 -0700 [thread overview]
Message-ID: <1289541799.2805.45.camel@x201> (raw)
In-Reply-To: <20101112052216.GA7631@redhat.com>
On Fri, 2010-11-12 at 07:22 +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 11, 2010 at 07:55:01PM -0700, Alex Williamson wrote:
> > Make use of wmask, just like the rest of config space.
> >
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> >
> > hw/pci.c | 19 ++++++++-----------
> > 1 files changed, 8 insertions(+), 11 deletions(-)
> >
> > diff --git a/hw/pci.c b/hw/pci.c
> > index 92aaa85..12c47ac 100644
> > --- a/hw/pci.c
> > +++ b/hw/pci.c
> > @@ -1175,13 +1175,14 @@ uint32_t pci_default_read_config(PCIDevice *d,
> > return pci_read_config(d, address, len);
> > }
> >
> > -static void pci_write_config(PCIDevice *pci_dev,
> > - uint32_t address, uint32_t val, int len)
> > +static void pci_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int l)
> > {
> > int i;
> > - for (i = 0; i < len; i++) {
> > - pci_dev->config[address + i] = val & 0xff;
> > - val >>= 8;
> > + uint32_t config_size = pci_config_size(d);
> > +
> > + for (i = 0; i < l && addr + i < config_size; val >>= 8, ++i) {
> > + uint8_t wmask = d->wmask[addr + i];
> > + d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val & wmask);
> > }
> > }
> >
>
>
> Let's not name an internal static helper pci_write_config.
> This is really update_config_by_mask or something like that.
> But see below: maybe we don't need it at all?
The function already exists, I just made it do what it seems like it
should have been doing already.
> > @@ -1207,18 +1208,14 @@ void pci_default_cap_write_config(PCIDevice *pci_dev,
> >
> > void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int l)
> > {
> > - int i, was_irq_disabled = pci_irq_disabled(d);
> > - uint32_t config_size = pci_config_size(d);
> > + int was_irq_disabled = pci_irq_disabled(d);
> >
> > if (pci_access_cap_config(d, addr, l)) {
> > d->cap.config_write(d, addr, val, l);
> > return;
> > }
> >
>
> I would like to also examine the need for _cap_
> functions. Why can assigned devices just do
>
> pci_default_write_config
> if (range_overlap(...msi)) {
> }
> if (range_overlap(...msix)) {
> }
> and then we could remove all the _cap_ extensions
> altogether?
I think that somewhere we need to track what capabilities are at what
offset, config space isn't a performance path, but that look horribly
inefficient and gets worse with more capabilities.
Why don't we define capability id 0xff as normal config space (first 64
bytes), then add the capability id to read/write_config (this is what
vfio does). Then the driver can split capability handling off from
their main functions if they want. Anyway, I think such an improvement
could be added incrementally later. Thanks,
Alex
> > - for (i = 0; i < l && addr + i < config_size; val >>= 8, ++i) {
> > - uint8_t wmask = d->wmask[addr + i];
> > - d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val & wmask);
> > - }
> > + pci_write_config(d, addr, val, l);
> >
> > #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
> > if (kvm_enabled() && kvm_irqchip_in_kernel() &&
next prev parent reply other threads:[~2010-11-12 6:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-12 2:54 [Qemu-devel] [PATCH 0/8] PCI capability and device assignment improvements Alex Williamson
2010-11-12 2:55 ` [Qemu-devel] [PATCH 1/8] pci: pci_default_cap_write_config ignores wmask Alex Williamson
2010-11-12 5:22 ` [Qemu-devel] " Michael S. Tsirkin
2010-11-12 6:03 ` Alex Williamson [this message]
2010-11-12 8:48 ` Michael S. Tsirkin
2010-11-12 15:49 ` Alex Williamson
2010-11-16 16:12 ` Michael S. Tsirkin
2010-11-12 2:55 ` [Qemu-devel] [PATCH 2/8] pci: Remove pci_enable_capability_support() Alex Williamson
2010-11-12 2:55 ` [Qemu-devel] [PATCH 3/8] device-assignment: Use PCI capabilities support Alex Williamson
2010-11-12 2:55 ` [Qemu-devel] [PATCH 4/8] pci: Replace used bitmap with capability byte map Alex Williamson
2010-11-12 5:40 ` [Qemu-devel] " Michael S. Tsirkin
2010-11-12 6:07 ` Alex Williamson
2010-11-12 9:02 ` Michael S. Tsirkin
2010-11-12 15:32 ` Alex Williamson
2010-11-12 2:55 ` [Qemu-devel] [PATCH 5/8] pci: Remove cap.length, cap.start, cap.supported Alex Williamson
2010-11-12 2:56 ` [Qemu-devel] [PATCH 6/8] device-assignment: Move PCI capabilities to match physical hardware Alex Williamson
2010-11-12 9:20 ` [Qemu-devel] " Michael S. Tsirkin
2010-11-12 13:53 ` Alex Williamson
2010-11-12 2:56 ` [Qemu-devel] [PATCH 7/8] pci: Pass ID for capability read/write handlers Alex Williamson
2010-11-12 2:56 ` [Qemu-devel] [RFC PATCH 8/8] device-assignment: pass through and stub more PCI caps Alex Williamson
2010-11-12 5:36 ` [Qemu-devel] " Michael S. Tsirkin
2010-11-12 6:30 ` Alex Williamson
2010-11-12 9:11 ` Michael S. Tsirkin
2010-11-12 15:42 ` Alex Williamson
2010-11-16 16:08 ` Michael S. Tsirkin
2010-11-12 5:39 ` [Qemu-devel] Re: [PATCH 0/8] PCI capability and device assignment improvements 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=1289541799.2805.45.camel@x201 \
--to=alex.williamson@redhat.com \
--cc=chrisw@redhat.com \
--cc=kvm@vger.kernel.org \
--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 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).