public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Vandrovec <petr@vmware.com>
To: "Pan, Jacob jun" <jacob.jun.pan@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"x86@kernel.org" <x86@kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH 2.6.34-rcX] Do not expect PCI devices to return zeroes in PCIe space
Date: Tue, 04 May 2010 00:31:01 -0700	[thread overview]
Message-ID: <4BDFCD35.1070109@vmware.com> (raw)
In-Reply-To: <43F901BD926A4E43B106BF17856F0755A3D633B4@orsmsx508.amr.corp.intel.com>

On 05/03/10 23:21, Pan, Jacob jun wrote:
> Hi Petr,
>
> There are other code in the kernel makes similar assumption of accessing pci cfg above 0x100. (but they do not hang in a loop)
> e.g. in drivers/pci/probe.c
> * accesses, or the device is behind a reverse Express bridge.  So we try
>   * reading the dword at 0x100 which must either be 0 or a valid extended
>   * capability header.
>   */
> int pci_cfg_space_size_ext(struct pci_dev *dev)
> {
> 	u32 status;
> 	int pos = PCI_CFG_SPACE_SIZE;
>
> 	if (pci_read_config_dword(dev, pos,&status) != PCIBIOS_SUCCESSFUL)
> 		goto fail;
> 	if (status == 0xffffffff)
> 		goto fail;
>
>
> Back to the problem itself, hpa has suggested a better fix might be using cfg_size for checking in fixed_bar_cap. But we can not use it right now since we have cfg_size set to 0x100 on MRST (due to lack of PCI_CAP_ID_EXP in the PCI shim). I will negotiate with FW guys so that we have the correct return from pci_cfg_space_size() for Moorestown.
>
> Until then, your current fix should be good.

Thanks.  Other possibility would be to modify amd_bus.c to verify that
ENABLE_CF8_EXT_CFG bit in MSR_AMD64_NB_CFG is actually writeable, and
not set PCI_HAS_IO_ECS if bit is read-as-zero.  That would fix both
Moorestown code as well as pci_cfg_space_size_ext - patch below can be
applied instead of mrst.c changes.
							Petr


Do not report AMD processors in VMware as ECS capable

In a VM AMD processors do not have integrated northbridge, and so their
northbridge-related MSRs do not work, and do not enable PCIe configuration
space accesses via I/O ports 0xCF8/0xCFC.  Virtualized processor can be
detected by having NB_CFG register read-only.

Signed-off-by: Petr Vandrovec <petr@vandrovec.name>

diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c
index fc1e8fe..cf03bff 100644
--- a/arch/x86/pci/amd_bus.c
+++ b/arch/x86/pci/amd_bus.c
@@ -349,6 +349,8 @@ static int __init early_fill_mp_bus_info(void)

  #define ENABLE_CF8_EXT_CFG      (1ULL << 46)

+static int ecs_ok = 1;
+
  static void enable_pci_io_ecs(void *unused)
  {
  	u64 reg;
@@ -356,6 +358,10 @@ static void enable_pci_io_ecs(void *unused)
  	if (!(reg & ENABLE_CF8_EXT_CFG)) {
  		reg |= ENABLE_CF8_EXT_CFG;
  		wrmsrl(MSR_AMD64_NB_CFG, reg);
+		/* VMware implements NB_CFG MSR as read-only.  Verify write worked... */
+		rdmsrl(MSR_AMD64_NB_CFG, reg);
+		if (!(reg & ENABLE_CF8_EXT_CFG))
+			ecs_ok = 0;
  	}
  }

@@ -390,7 +396,8 @@ static int __init pci_io_ecs_init(void)
  	for_each_online_cpu(cpu)
  		amd_cpu_notify(&amd_cpu_notifier, (unsigned long)CPU_ONLINE,
  			       (void *)(long)cpu);
-	pci_probe |= PCI_HAS_IO_ECS;
+	if (ecs_ok)
+		pci_probe |= PCI_HAS_IO_ECS;

  	return 0;
  }

  reply	other threads:[~2010-05-04  7:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-01  2:54 [PATCH 2.6.34-rcX] Do not expect PCI devices to return zeroes in PCIe space Petr Vandrovec
2010-05-04  6:21 ` Pan, Jacob jun
2010-05-04  7:31   ` Petr Vandrovec [this message]
2010-05-14 18:37 ` H. Peter Anvin
2010-05-14 20:51   ` Petr Vandrovec
2010-05-14 21:39     ` [tip:x86/urgent] x86, mrst: Don't blindly access extended config space tip-bot for H. Peter Anvin

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=4BDFCD35.1070109@vmware.com \
    --to=petr@vmware.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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