All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Rui Guo <firemeteor@users.sourceforge.net>
Cc: stefano.stabellini@citrix.com, ian.campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci cap on host bridge.
Date: Thu, 07 Feb 2013 16:40:43 +0000	[thread overview]
Message-ID: <5113E71B02000078000BCF86@nat28.tlf.novell.com> (raw)
In-Reply-To: <1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>

>>> On 07.02.13 at 17:12, Rui Guo <firemeteor@users.sourceforge.net> wrote:
> +static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
> +                                        uint32_t *val)
> +{
> +    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    uint32_t vendor_cap = 0;
> +    uint32_t cap_type = 0;
> +    uint32_t cap_size = 0;
> +
> +    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
> +    if (!vendor_cap)
> +        return 0;
> +
> +    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
> +    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
> +        return 0;
> +
> +    if (config_addr == PCI_INTEL_VENDOR_CAP)
> +    {
> +        *val = vendor_cap;
> +        return 1;
> +    }
> +
> +    /* Remove the next capability link */
> +    if (config_addr == vendor_cap + 1)
> +    {
> +        *val = 0;
> +        return 1;
> +    }

It doesn't look right to ignore "len" up to here? What if this is a
word read at "vendor_cap"?

Also, why would removing the next capability be correct here,
when you're not removing _all_ other capabilities?

> +
> +    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
> +    if (config_addr >= vendor_cap &&
> +            config_addr + len <= vendor_cap + cap_size)
> +    {
> +        *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> +        return 1;
> +    }

Similarly such a read wouldn't get handled consistently (with the
above intention) here: You're not masking off the byte at
"vendor_cap + 1".

> +    /* Exposing writable register does not lead to security risk since this
> +       only apply to read. This may confuse the guest, but it works good so far.
> +       Will switch to mask & merge style only if this is proved broken.
> +       Note: Always expose aligned address if any byte of the dword is to be
> +       exposed. This provides a consistent view, at least for read. */

Such a comment is certainly not helping being confident in the
changes you're trying to get merged in.

Jan

  reply	other threads:[~2013-02-07 16:40 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-07 16:12 Patch series for IGD passthrough Rui Guo
2013-02-07 16:12 ` [PATCH 1/3] qemu-xen-trad/pt_msi_disable: do not clear all MSI flags Rui Guo
2013-02-07 16:12 ` [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA bridge for IGD passthrough Rui Guo
2013-02-07 16:30   ` Jan Beulich
2013-02-07 17:43     ` G.R.
2013-02-08  7:51       ` Jan Beulich
2013-05-21 15:39         ` G.R.
2013-05-24  4:02           ` G.R.
2013-02-08 11:30       ` Stefano Stabellini
2013-02-08 11:36         ` Jan Beulich
2013-02-08 11:48           ` Stefano Stabellini
2013-05-21 15:52             ` G.R.
2013-05-21 15:57               ` Jan Beulich
2013-02-07 16:12 ` [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci cap on host bridge Rui Guo
2013-02-07 16:40   ` Jan Beulich [this message]
2013-02-07 17:38     ` G.R.
2013-02-08  7:56       ` Jan Beulich
2013-06-19 10:37         ` G.R.
2013-06-21 18:03           ` Konrad Rzeszutek Wilk
2013-06-25 14:08             ` Ross Philipson
2013-06-25 14:54               ` Konrad Rzeszutek Wilk
2013-06-25 15:01                 ` Ross Philipson
2013-06-26  4:18                   ` G.R.
2013-06-26 12:53                     ` Konrad Rzeszutek Wilk
2013-06-26 17:26                       ` Ross Philipson
2013-06-27  7:27                       ` G.R.
2013-07-01 13:06                         ` Konrad Rzeszutek Wilk
2013-07-15 16:06                           ` Pasi Kärkkäinen
2013-07-15 17:47                             ` Ross Philipson
2013-07-15 22:55                               ` Pasi Kärkkäinen
2013-08-05 16:15                                 ` Pasi Kärkkäinen
2013-08-06  3:44                                   ` G.R.
2013-09-25 14:28                                     ` Pasi Kärkkäinen
2014-08-20 15:20                                     ` Pasi Kärkkäinen
2013-06-25 14:26             ` G.R.
2013-02-08 11:14 ` Patch series for IGD passthrough Stefano Stabellini
2013-03-20 17:17 ` Pasi Kärkkäinen
2013-04-15 20:48   ` Pasi Kärkkäinen
2013-04-16 10:56     ` George Dunlap
2013-04-16 15:59       ` Pasi Kärkkäinen
2013-04-18 11:48       ` Stefano Stabellini
2012-12-19 13:06         ` [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge " G.R.
2012-12-20 13:13           ` Stefano Stabellini
2013-02-22 18:05           ` Ian Jackson
2013-02-25 10:10             ` Jan Beulich
2013-02-25 11:24               ` Ian Jackson
2013-02-25 11:29                 ` Jan Beulich
2013-02-25 12:49                   ` Stefano Stabellini
2013-05-07 17:12                     ` [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge for IGD passthrough [and 2 more messages] Ian Jackson
2013-05-09 13:17                       ` Pasi Kärkkäinen
2013-05-10  9:12                         ` Jan Beulich
2013-05-10  9:40                           ` Pasi Kärkkäinen
2013-05-10 10:00                             ` Ian Campbell
2013-05-10 10:09                               ` George Dunlap
2013-05-10 10:33                                 ` Ian Campbell
2013-05-10 10:44                                   ` Pasi Kärkkäinen
2013-05-10 10:35                                 ` Jan Beulich
2013-02-25 16:46                   ` [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge for IGD passthrough Ian Jackson
2013-04-18 11:47     ` Patch series " Stefano Stabellini
2013-05-03 15:14       ` Pasi Kärkkäinen

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=5113E71B02000078000BCF86@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=firemeteor@users.sourceforge.net \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=xen-devel@lists.xen.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.