From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>,
Asit K Mallick <asit.k.mallick@intel.com>,
Donald D Dugger <donald.d.dugger@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>,
xen-devel <xen-devel@lists.xenproject.org>,
xiantao.zhang@intel.com
Subject: Re: [PATCH 3/3] passthrough: allow to suppress SERR and PERR signaling altogether
Date: Mon, 7 Apr 2014 13:47:40 +0100 [thread overview]
Message-ID: <53429E6C.4090105@citrix.com> (raw)
In-Reply-To: <533D48D50200007800005128@nat28.tlf.novell.com>
[-- Attachment #1.1: Type: text/plain, Size: 5660 bytes --]
On 03/04/14 10:41, Jan Beulich wrote:
> This is just to have a workaround at hand in case other chipsets (not
> covered by the previous two patches) also have similar issues.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -154,6 +154,112 @@ static void __init parse_phantom_dev(cha
> }
> custom_param("pci-phantom", parse_phantom_dev);
>
> +static u16 __read_mostly command_mask;
> +static u16 __read_mostly bridge_ctl_mask;
> +
> +/*
> + * The 'pci' parameter controls certain PCI device aspects.
> + * Optional comma separated value may contain:
> + *
> + * serr don't suppress system errors (default)
> + * no-serr suppress system errors
> + * perr don't suppress parity errors (default)
> + * no-perr suppress parity errors
> + */
> +static void __init parse_pci_param(char *s)
> +{
> + char *ss;
> +
> + do {
> + bool_t on = !!strncmp(s, "no-", 3);
> + u16 cmd_mask = 0, brctl_mask = 0;
> +
> + if ( !on )
> + s += 3;
> +
> + ss = strchr(s, ',');
> + if ( ss )
> + *ss = '\0';
> +
> + if ( !strcmp(s, "serr") )
> + {
> + cmd_mask = PCI_COMMAND_SERR;
> + brctl_mask = PCI_BRIDGE_CTL_SERR | PCI_BRIDGE_CTL_DTMR_SERR;
> + }
> + else if ( !strcmp(s, "perr") )
> + {
> + cmd_mask = PCI_COMMAND_PARITY;
> + brctl_mask = PCI_BRIDGE_CTL_PARITY;
> + }
> +
> + if ( on )
> + {
> + command_mask &= ~cmd_mask;
> + bridge_ctl_mask &= ~brctl_mask;
> + }
> + else
> + {
> + command_mask |= cmd_mask;
> + bridge_ctl_mask |= brctl_mask;
> + }
> +
> + s = ss + 1;
> + } while ( ss );
> +}
> +custom_param("pci", parse_pci_param);
> +
> +static void check_pdev(const struct pci_dev *pdev)
> +{
> +#define PCI_STATUS_CHECK \
> + (PCI_STATUS_PARITY | PCI_STATUS_SIG_TARGET_ABORT | \
> + PCI_STATUS_REC_TARGET_ABORT | PCI_STATUS_REC_MASTER_ABORT | \
> + PCI_STATUS_SIG_SYSTEM_ERROR | PCI_STATUS_DETECTED_PARITY)
> + u16 seg = pdev->seg;
> + u8 bus = pdev->bus;
> + u8 dev = PCI_SLOT(pdev->devfn);
> + u8 func = PCI_FUNC(pdev->devfn);
> + u16 val;
> +
> + if ( command_mask )
> + {
> + val = pci_conf_read16(seg, bus, dev, func, PCI_COMMAND);
> + if ( val & command_mask )
> + pci_conf_write16(seg, bus, dev, func, PCI_COMMAND,
> + val & ~command_mask);
> + val = pci_conf_read16(seg, bus, dev, func, PCI_STATUS);
> + if ( val & PCI_STATUS_CHECK )
> + {
> + printk(XENLOG_INFO "%04x:%02x:%02x.%u status %04x\n",
> + seg, bus, dev, func, val);
What is the purpose of this printk? From the text alone it is not obvious.
> + pci_conf_write16(seg, bus, dev, func, PCI_STATUS, val);
I dont think this code has any right to clear status bits other than the
ones it is checking for, so the write should be "val & PCI_STATUS_CHECK"
~Andrew
> + }
> + }
> +
> + switch ( pci_conf_read8(seg, bus, dev, func, PCI_HEADER_TYPE) & 0x7f )
> + {
> + case PCI_HEADER_TYPE_BRIDGE:
> + if ( !bridge_ctl_mask )
> + break;
> + val = pci_conf_read16(seg, bus, dev, func, PCI_BRIDGE_CONTROL);
> + if ( val & bridge_ctl_mask )
> + pci_conf_write16(seg, bus, dev, func, PCI_BRIDGE_CONTROL,
> + val & ~bridge_ctl_mask);
> + val = pci_conf_read16(seg, bus, dev, func, PCI_SEC_STATUS);
> + if ( val & PCI_STATUS_CHECK )
> + {
> + printk(XENLOG_INFO "%04x:%02x:%02x.%u secondary status %04x\n",
> + seg, bus, dev, func, val);
> + pci_conf_write16(seg, bus, dev, func, PCI_SEC_STATUS, val);
> + }
> + break;
> +
> + case PCI_HEADER_TYPE_CARDBUS:
> + /* TODO */
> + break;
> + }
> +#undef PCI_STATUS_CHECK
> +}
> +
> static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn)
> {
> struct pci_dev *pdev;
> @@ -252,6 +358,8 @@ static struct pci_dev *alloc_pdev(struct
> break;
> }
>
> + check_pdev(pdev);
> +
> return pdev;
> }
>
> @@ -566,6 +674,8 @@ int pci_add_device(u16 seg, u8 bus, u8 d
> seg, bus, slot, func, ctrl);
> }
>
> + check_pdev(pdev);
> +
> ret = 0;
> if ( !pdev->domain )
> {
> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -125,7 +125,7 @@
> #define PCI_IO_RANGE_TYPE_16 0x00
> #define PCI_IO_RANGE_TYPE_32 0x01
> #define PCI_IO_RANGE_MASK (~0x0fUL)
> -#define PCI_SEC_STATUS 0x1e /* Secondary status register, only bit 14 used */
> +#define PCI_SEC_STATUS 0x1e /* Secondary status register */
> #define PCI_MEMORY_BASE 0x20 /* Memory range behind */
> #define PCI_MEMORY_LIMIT 0x22
> #define PCI_MEMORY_RANGE_TYPE_MASK 0x0fUL
> @@ -152,6 +152,7 @@
> #define PCI_BRIDGE_CTL_MASTER_ABORT 0x20 /* Report master aborts */
> #define PCI_BRIDGE_CTL_BUS_RESET 0x40 /* Secondary bus reset */
> #define PCI_BRIDGE_CTL_FAST_BACK 0x80 /* Fast Back2Back enabled on secondary interface */
> +#define PCI_BRIDGE_CTL_DTMR_SERR 0x800 /* SERR upon discard timer expiry */
>
> /* Header type 2 (CardBus bridges) */
> #define PCI_CB_CAPABILITY_LIST 0x14
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 6436 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-04-07 12:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-03 9:33 [PATCH 0/3] fixes (read: workarounds) for XSA-59 Jan Beulich
2014-04-03 9:39 ` [PATCH 1/3] VT-d: suppress UR signaling for server chipsets Jan Beulich
2014-04-07 12:12 ` Andrew Cooper
2014-04-07 13:11 ` Jan Beulich
2014-04-03 9:40 ` [PATCH 2/3] VT-d: suppress UR signaling for desktop chipsets Jan Beulich
2014-04-07 12:21 ` Andrew Cooper
2014-04-03 9:41 ` [PATCH 3/3] passthrough: allow to suppress SERR and PERR signaling altogether Jan Beulich
2014-04-07 10:05 ` Andrew Cooper
2014-04-07 10:21 ` Jan Beulich
2014-04-07 12:47 ` Andrew Cooper [this message]
2014-04-07 13:05 ` Jan Beulich
2014-04-07 13:17 ` Andrew Cooper
2014-04-07 13:43 ` Jan Beulich
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=53429E6C.4090105@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=asit.k.mallick@intel.com \
--cc=donald.d.dugger@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xenproject.org \
--cc=xiantao.zhang@intel.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.