All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.