All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: stefan.bader@canonical.com,
	xen-devel <xen-devel@lists.xenproject.org>,
	xiantao.zhang@intel.com, suravee.suthikulpanit@amd.com
Subject: Re: [PATCH 1/1 V3] x86/AMD: Fix setup ssss:bb:dd:f for d0 failed
Date: Tue, 10 Sep 2013 13:52:49 +0100	[thread overview]
Message-ID: <522F1621.2020007@citrix.com> (raw)
In-Reply-To: <522F30EA02000078000F1E20@nat28.tlf.novell.com>

On 10/09/13 13:47, Jan Beulich wrote:
>>>> On 09.09.13 at 17:52, <suravee.suthikulpanit@amd.com> wrote:
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -147,9 +147,10 @@ static void amd_iommu_setup_domain_device(
>>  
>>          amd_iommu_flush_device(iommu, req_id);
>>  
>> -        AMD_IOMMU_DEBUG("Setup I/O page table: device id = %#x, "
>> +        AMD_IOMMU_DEBUG("Setup I/O page table: device id = %#x, type = %x, "
> Consistency please: Mixing hex and dec numbers in a single
> message almost requires disambiguating them. Please add the
> missing #.
>
>> @@ -175,6 +176,15 @@ static int __init amd_iommu_setup_dom0_device(u8 devfn, struct pci_dev *pdev)
>>  
>>      if ( unlikely(!iommu) )
>>      {
>> +        /* Filter the bridge devices */
>> +        if ( (pdev->type == DEV_TYPE_PCI_HOST_BRIDGE) )
> Superfluous parentheses.
>
>> +        {
>> +            AMD_IOMMU_DEBUG("Skipping host bridge %04x:%02x:%02x.%u (type %x)\n",
>> +                        pdev->seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),
>> +                        pdev->type);
> Saying "host bridge" _and_ being in a conditional only allowing host
> bridges in makes printing the type redundant.

I specifically asked for "host bridge" here for the benefit of people
just reading the boot dmesg.

~Andrew

>
>> --- a/xen/drivers/passthrough/vtd/intremap.c
>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>> @@ -439,6 +439,9 @@ static void set_msi_source_id(struct pci_dev *pdev, struct iremap_entry *ire)
>>      {
>>          unsigned int sq;
>>  
>> +    case DEV_TYPE_PCI_HOST_BRIDGE:
>> +	break;
>> +
> This can't be right, as it re-introduces the issue XSA-49 was about.
> The easiest is perhaps to simply have this handled together with
> the immediately subsequent cases.
>
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -1433,6 +1433,12 @@ static int domain_context_mapping(
>>  
>>      switch ( pdev->type )
>>      {
>> +    case DEV_TYPE_PCI_HOST_BRIDGE:
>> +	if (iommu_verbose)
> Hard tab and missing spaces.
>
>> +            dprintk(VTDPREFIX, "d%d:Hostbridge map skip %04x:%02x:%02x.%u\n",
>> +                domain->domain_id, seg, bus,
>> +                PCI_SLOT(devfn), PCI_FUNC(devfn));
>> +
> Fall-through in a switch statement needs to be annotated, to make
> clear it is intentional.
>
>>      case DEV_TYPE_PCIe_BRIDGE:
>>      case DEV_TYPE_PCIe2PCI_BRIDGE:
>>      case DEV_TYPE_LEGACY_PCI_BRIDGE:
>> @@ -1563,6 +1569,12 @@ static int domain_context_unmap(
>>  
>>      switch ( pdev->type )
>>      {
>> +    case DEV_TYPE_PCI_HOST_BRIDGE:
>> +	if (iommu_verbose)
> See above.
>
>> +            dprintk(VTDPREFIX, "d%d:Hostbridge unmap skip %04x:%02x:%02x.%u\n",
>> +                domain->domain_id, seg, bus,
>> +                PCI_SLOT(devfn), PCI_FUNC(devfn));
>> +
> See above.
>
>>      case DEV_TYPE_PCIe_BRIDGE:
>>      case DEV_TYPE_PCIe2PCI_BRIDGE:
>>      case DEV_TYPE_LEGACY_PCI_BRIDGE:
>> @@ -1885,7 +1897,8 @@ static int intel_iommu_add_device(u8 devfn, struct pci_dev *pdev)
>>      ret = domain_context_mapping(pdev->domain, devfn, pdev);
>>      if ( ret )
>>      {
>> -        dprintk(XENLOG_ERR VTDPREFIX, "d%d: context mapping failed\n",
>> +        if ( ret != -EPERM )
>> +            dprintk(XENLOG_ERR VTDPREFIX, "d%d: context mapping failed\n",
>>                  pdev->domain->domain_id);
> Where's that -EPERM coming from, and what's the reason for not
> printing the message in that case?
>
> And if there is a reason, you'd
> - probably want to also print the message when iommu_verbose,
> - need to change indentation of the rest of the function invocation.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

  reply	other threads:[~2013-09-10 12:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-09 15:52 [PATCH 1/1 V3] x86/AMD: Fix setup ssss:bb:dd:f for d0 failed suravee.suthikulpanit
2013-09-10 12:47 ` Jan Beulich
2013-09-10 12:52   ` Andrew Cooper [this message]
2013-09-10 12:59     ` Jan Beulich
2013-09-10 13:02       ` Andrew Cooper
2013-09-11 19:37   ` Suravee Suthikulpanit

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=522F1621.2020007@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=stefan.bader@canonical.com \
    --cc=suravee.suthikulpanit@amd.com \
    --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.