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;
}
next prev parent 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