From: Alex Williamson <alex.williamson@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] pci: Error on PCI capability collisions
Date: Tue, 23 Aug 2011 13:12:19 -0600 [thread overview]
Message-ID: <1314126740.2859.108.camel@bling.home> (raw)
In-Reply-To: <20110823182632.GA6489@redhat.com>
On Tue, 2011-08-23 at 21:26 +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 23, 2011 at 12:21:47PM -0600, Alex Williamson wrote:
> > On Tue, 2011-08-23 at 21:17 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 23, 2011 at 07:28:08PM +0200, Jan Kiszka wrote:
> > > > From: Alex Williamson <alex.williamson@redhat.com>
> > > >
> > > > Nothing good can happen when we overlap capabilities
> > > >
> > > > [ Jan: rebased over qemu, minor formatting ]
> > > >
> > > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > >
> > > I'll stick an assert there instead. Normal devices
> > > don't generate overlapping caps unless there's a bug,
> > > and device assignment should do it's own checks.
> > >
> > > I really have a mind to rip out the used array too.
> >
> > So you'd rather kill qemu rather than have a reasonable error return
> > path... great :(
> >
> > Alex
>
> Well that will make it possible to make pci_add_capability return void,
> less work for callers :) Dev assignment is really the only place where
> capability offsets need to be verified.
A few issues with that... Since when is error handling so difficult that
we need to pretend that nothing ever fails just to make it easy for the
caller? Why is device assignment such a special case? It's actually
rather ironic that we're trying to add error checking to catch bugs that
real hardware is exposing, but assuming that emulated drivers always get
it right. How will a return void help the emulated driver that has a
coding error?
Alex
> > > > ---
> > > > hw/pci.c | 14 ++++++++++++++
> > > > 1 files changed, 14 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/hw/pci.c b/hw/pci.c
> > > > index 6124790..ff20631 100644
> > > > --- a/hw/pci.c
> > > > +++ b/hw/pci.c
> > > > @@ -1952,11 +1952,25 @@ int pci_add_capability(PCIDevice *pdev, uint8_t cap_id,
> > > > uint8_t offset, uint8_t size)
> > > > {
> > > > uint8_t *config;
> > > > + int i;
> > > > +
> > > > if (!offset) {
> > > > offset = pci_find_space(pdev, size);
> > > > if (!offset) {
> > > > return -ENOSPC;
> > > > }
> > > > + } else {
> > > > + for (i = offset; i < offset + size; i++) {
> > > > + if (pdev->used[i]) {
> > > > + fprintf(stderr, "ERROR: %04x:%02x:%02x.%x "
> > > > + "Attempt to add PCI capability %x at offset "
> > > > + "%x overlaps existing capability %x at offset %x\n",
> > > > + pci_find_domain(pdev->bus), pci_bus_num(pdev->bus),
> > > > + PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn),
> > > > + cap_id, offset, pdev->config_map[i], i);
> > > > + return -EFAULT;
> > > > + }
> > > > + }
> > > > }
> > > >
> > > > config = pdev->config + offset;
> > > > --
> > > > 1.7.3.4
> >
> >
next prev parent reply other threads:[~2011-08-23 19:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-23 17:28 [Qemu-devel] [PATCH] pci: Error on PCI capability collisions Jan Kiszka
2011-08-23 18:17 ` Michael S. Tsirkin
2011-08-23 18:21 ` Alex Williamson
2011-08-23 18:26 ` Michael S. Tsirkin
2011-08-23 19:12 ` Alex Williamson [this message]
2011-08-23 19:30 ` Michael S. Tsirkin
2011-08-23 19:38 ` Alex Williamson
2011-08-23 20:59 ` Don Dutile
2011-08-24 9:51 ` Michael S. Tsirkin
2011-08-24 10:04 ` Michael S. Tsirkin
2011-08-24 10:10 ` Jan Kiszka
2011-08-24 11:01 ` Michael S. Tsirkin
2011-08-24 11:58 ` Michael S. Tsirkin
2011-08-24 12:29 ` Jan Kiszka
2011-08-24 12:34 ` Michael S. Tsirkin
2011-08-24 12:36 ` Jan Kiszka
2011-08-24 12:39 ` Michael S. Tsirkin
2011-08-24 12:39 ` Jan Kiszka
2011-08-24 12:29 ` [Qemu-devel] [PATCH v2] " Jan Kiszka
2011-08-24 12:53 ` 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=1314126740.2859.108.camel@bling.home \
--to=alex.williamson@redhat.com \
--cc=jan.kiszka@siemens.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 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).