From patchwork Tue Nov 28 09:12:44 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Christian_K=C3=B6nig?= X-Patchwork-Id: 10079027 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 240FB60353 for ; Tue, 28 Nov 2017 09:13:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 142DC291E9 for ; Tue, 28 Nov 2017 09:13:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 08C35291ED; Tue, 28 Nov 2017 09:13:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6FAEC291E8 for ; Tue, 28 Nov 2017 09:13:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751908AbdK1JNE (ORCPT ); Tue, 28 Nov 2017 04:13:04 -0500 Received: from mail-dm3nam03on0051.outbound.protection.outlook.com ([104.47.41.51]:10912 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751664AbdK1JM7 (ORCPT ); Tue, 28 Nov 2017 04:12:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amdcloud.onmicrosoft.com; s=selector1-amd-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DY6VsLg0R1MBQhpcC4p/1JVIvf0vsqx+zyWyrxFeUD0=; b=14WD5aCtquj6qlZg25bb+GbLi1KeQ7e/ylkR5UNqoXNYI5/ZtPBse0SmRazncp/rl6UlJxsrn2IoyUNTeOSCF5YrE0Rfs72gUB8NRb8fnlVeQbuqh5d8tph5L8zXqg68DLZovxC4narQEmhUMzfBusuBAxg20jALEuyIc6b8eMo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Christian.Koenig@amd.com; Received: from [IPv6:2a02:908:1251:7981:b169:9ad5:fb55:6cfe] (2a02:908:1251:7981:b169:9ad5:fb55:6cfe) by DM5PR12MB1307.namprd12.prod.outlook.com (10.168.237.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 28 Nov 2017 09:12:55 +0000 Subject: Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5 To: Boris Ostrovsky , helgaas@kernel.org, linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, xen-devel References: <20171018135821.3248-1-deathsimple@vodafone.de> <20171018135821.3248-5-deathsimple@vodafone.de> <26df0a78-8028-e42c-ce50-4cefe612a7e1@oracle.com> <3443aad0-8c3b-b97e-685a-96b0866827be@amd.com> <7936fdd3-1615-ac1f-7b75-330ccb6a1a3f@amd.com> <0bb468d9-bc1d-e3c5-e313-1cf9408380f0@oracle.com> <275e859a-0ddd-ea7f-a681-67e42a5233fe@amd.com> <38bc76d9-2ed5-61f3-24b3-085031825181@oracle.com> <65885386-3dde-de23-7e95-7d96dfdf6033@oracle.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <0ab28334-3ccc-2a93-9991-396ee01a3662@amd.com> Date: Tue, 28 Nov 2017 10:12:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <65885386-3dde-de23-7e95-7d96dfdf6033@oracle.com> Content-Language: en-US X-Originating-IP: [2a02:908:1251:7981:b169:9ad5:fb55:6cfe] X-ClientProxiedBy: VI1P189CA0004.EURP189.PROD.OUTLOOK.COM (10.165.188.17) To DM5PR12MB1307.namprd12.prod.outlook.com (10.168.237.150) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9fb135b9-562f-42b5-0279-08d5364036f5 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258)(49563074); SRVR:DM5PR12MB1307; X-Microsoft-Exchange-Diagnostics: 1; DM5PR12MB1307; 3:+7KhcwAjX6/BEQz8EuXQiXlGoylQxGmJ4vdwrQiJ/qnMip5d1kAFJxSGVbglUQQtGptSlihM6jZq/cOkw5sQYBvC1wotXBgLgYuTu4ahZBoNgj+XR+14Mb+tkchprBT2VxiPPNMhPCfY4Q9Nrd72Bvzu7xPjqMjGJYGdairbUOmua7v3btUkf98CJm2D7Fa/45d5P/PcRmxxIC9VB25L37K8KEihzzJplrNdQld17JW9Vb5wCYQ6i/JaJCGhHoKC; 25:aNfBaQGHTDMyJ427cEfacu4R/PrxbUXJiLLaZ2CqLnDT0WojRYxc104GpHqQfqYlUbAXmHClws9xFaYI0xIFre2eYCmUquxMEBoyUe/J7ePoiGSsUzFU9H19OpULhqv2IXq+vs7yH8zILdOcTfFpDybS/02HwqNfBPYOl9LNvfgTETTWtJWzzZtCljRevSKhr8IDZWTaOEgClrcehXwWoe/h5pxmzwppMkVlOhDBHVZsmZp/fMlIe/m8Ww+bAJuBzj08bAEV12jxU8uFBjvdOjMEF/fmW3tR/HcipLVTwit59l4xT3pLaBSUS6fSPdCdFY26cPC/2JXW0o1PzV2DSw==; 31:xtqqLiVuXwd+WDQhsojdEGjDTfQPbA4b65SPbCrKG73uvoVo3uC82TFPCxbWCoBs2zxxVafTxWrwhxKDU/jro+OPRoavsWRH6GkxC8Tbugr7GLXXfcKB6FC5TiDK8dyfsUqqCwU1TRb2JL6BPGMLBE0VtV5nyocTFyf2npRZtZ/7oaucFxiQejYJt9fTa5GxJkGoCpYzi33AG3DxgBjSOZjHupJSkYrFBgv2e85HjaI= X-MS-TrafficTypeDiagnostic: DM5PR12MB1307: X-Microsoft-Exchange-Diagnostics: 1; DM5PR12MB1307; 20:fhCpGXTje+y1eD8eDeupg46soNLzjXt8Cw+uBxRh7Iuw65rqRlfQ1UTPX9H4xVqAy78P7OVf0cQny4beTLShtWiZ6nbvlkZMd4rfmjxxO7mMEPj4Aak5x1JgZxc7J2YrwgqYcbCZNBViNFiHVnkdXiwWWj6vc0KZa/nE/vS0T1pRfhvbswoqwUS/ffKsSJhvhnc8a+33WUAsDdJDLbkBDnsyfQYWGgZGDt82ezUBKSwKAAbuVR8y49skF82wg70yzVahs/0swuMb5tVFLfCIxGKGR7LCHfTKO3QvMYfVvulpduBZDldLp0oaY1f8gQEegmHpCRhmxSlEg2CznpwOWMf0+UB39NIx50wzNEe54b/M1nIJcV25h1sp+q0dkMMWrD87mPV+mpF7szgFgRD0zHsC60OgTFcRc8UCsC0zEG7wx+zlxQe2TQ/KXbORzfjome0Yjtuqw2oF++3n+7swCFKtS0h3r0vGYtAjN3I6LYs7Ky8LI2ec/+tIi0ZaabmA; 4:LUp+0rxOAQiH8/+vcWWqgO8V7JnRmlcW0xlOeHlTAdnq2q8PMxg+qujRNntgHQ3LHqzrfm0GHSN8Rt8CJGHZOuDp2iQNr4BP+3wd+PtaEton04612l4NPK1fGGh0K7Aho+nOxVqo7uRurkPdEY9r4mMsZy7jIfiS6ElIfAn5ldZ50U0gr0fpx/yattQXWxhinEoeQmm251gkpcZeckJ0zAMsv0rJmQQPE8QNxucYeGJHzJ7xRzdaEo7OxLRNL+tpOFUy08LwuXjkzEYljQ3Aaw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(3231022)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011); SRVR:DM5PR12MB1307; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR12MB1307; X-Forefront-PRVS: 0505147DDB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(366004)(376002)(51444003)(24454002)(199003)(189002)(189998001)(93886005)(6666003)(6246003)(2476003)(25786009)(97736004)(5890100001)(52396003)(64126003)(36756003)(2950100002)(106356001)(105586002)(6116002)(53936002)(16586007)(53546010)(110136005)(316002)(31696002)(65806001)(52116002)(86362001)(65826007)(229853002)(58126008)(37036004)(4610100001)(65956001)(33646002)(305945005)(54356999)(76176999)(8676002)(31686004)(101416001)(7736002)(72206003)(1706002)(84326002)(83506002)(5660300001)(478600001)(50986999)(2906002)(568964002)(8936002)(6486002)(81156014)(81166006)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR12MB1307; H:[IPv6:2a02:908:1251:7981:b169:9ad5:fb55:6cfe]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: amd.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR12MB1307; 23:+R9Sn9CNlf34KnqvuMH7dUXJFxwVc/1y/FZ8a3k0h?= =?us-ascii?Q?+Dg4lz3yi9cudF8dABf61F9hVs91qmhdmjl0e4kbuXqK1/xt86iSP5c7f5qQ?= =?us-ascii?Q?uZYBxaPIaJvqtspc1FurtPnhrl/f6fwpA0XmP5vMoWf6ukQB2Gb5GS4zkdyx?= =?us-ascii?Q?I9IvNT0307gXUrSBmNkU/VpCLoKnhHogzK8ecdeBwaq8FEnyT1ywldZWIyMH?= =?us-ascii?Q?JZFnw2G6ub5GS+nawbUkUY+7qH4FpohmWw7zke/lDFU6NFDWCFvXRTkEOLYM?= =?us-ascii?Q?xhmcImRDTdJFEEmRSZJtl6eW1rPN3X1B78uh8786aXZtQVVZ8fZh3A0+yZUO?= =?us-ascii?Q?Q0clQaUIYgUuFg9lIRAW+CjDJlChhzrefL0hE5EkHB/eY2sN+vWZRDBTYJB+?= =?us-ascii?Q?mWVs50Y8spOmfAVD1B7F2GeKKKmw2oBL/RZSYelUMBmRurp/E8EH0cUDtmOF?= =?us-ascii?Q?EzQSXNwLwZX8j9yXfghqhIY7GxDCkmq+V2Z4wPQnPsvRgT07dZv/IDFrtViN?= =?us-ascii?Q?ggmJKT3UPFM2JzyjLdaqg2aVM7UFYsy/9GAl8FBpunRA92F/YpDX0PqMlueV?= =?us-ascii?Q?rgr/7wPngJjgZPb0nOqQYDE/D51tvdrAlkVb3IYwBfufoeNvyGEY9up2qdfB?= =?us-ascii?Q?cc0cKmlhjghHtpB5kn7UVZjivkG57tIZUp1TpMxwtJSzCJ5fYSHGSV7Iw72x?= =?us-ascii?Q?lhbtwfMswtsns3yZ9g/ZQOJlobDIn5rzwB0g7olFreDxDZmprIWCcI9bEpdr?= =?us-ascii?Q?OTIhxfV8HQkqL/SYgGJIXsOSlNFj8WAAOe+dE/98JYfQUFPWcm3ptJfRMU6/?= =?us-ascii?Q?uQbU1CpQphaWLeUf5KL1ybswpQ3VFETYg4pwWreCa1gbfjk6w2dTFpj0Zjph?= =?us-ascii?Q?j28ZxWminrIRcom7zTWmL2po71uOopOqyXJI2nbn9XPWHyhSFlVmdBQvAHIf?= =?us-ascii?Q?d2cIaZ4OMjFO+QzQ/j+4iLd3owLzWNh0ww4eFVYSUBwjAtRG72xyp0evvu6B?= =?us-ascii?Q?3EM1ilzj2EG4qY2lGEYjMKUvFqPmsjDzdXH7enroxHS4hwQ22pQ83pC3dv2O?= =?us-ascii?Q?88pl+0m9mWejOuq9bdIKHK1ers9IzCAAymXDGHEZ3Ww0P4hEnE+CqcgdMwlV?= =?us-ascii?Q?t2V6f6kol3vtJDtC6ADD+VPTToOWdX8ZEaW+2YFwpY586NiEJFOCX+FJzl9l?= =?us-ascii?Q?hfZ+d1hLY41uiDg/pEemUnZMZ4UdxGdUvns5OlcJNluKr8ZgncM9su47ZxqK?= =?us-ascii?Q?B4m6F/1ZTYeq9sJRESp4Gv3+QKe2uQIXLnmO5B8zH1k5KI4C9lH5FrD2NOEx?= =?us-ascii?Q?b6x0Ke3f4GcOQJgROnA0/ozdfpRvvItNpEbEghQoxWxOk5EZq+gjd4n3EG+c?= =?us-ascii?Q?c+QRImu5h4P0rqeOU8/2iJEQu0apFW2FOXcp6jlUlh/WtPMm3id+Bqesc/6J?= =?us-ascii?Q?zcnFAj+bg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR12MB1307; 6:xAUZMjNgwZ0IL8Ueba8vDUs7hHlB7hJ9IsRnG4XD8YUvPlB24I1U9QrnLSPI8ig7xgTUOkvKST6szVbFzVw+NGDuoOvkHDASj2umETf0Jq7mwIj/SpeJfT6s3+O27rwF2pBz6PYG9R7tFd2/Lo19tMb0ERuFbqj95U7WhLvu7hbgTC4DA6j2cUIesYvHfSJnummpR3gtAdZdmNg1lpi5+ZvV/xCPMFbvTd4EpKYP0bVMvOJ5HZAtobRx6tJr78IYype2IAjguOLcnihgbfZ17QNR8RACQkeCmYPGc+ZwLRcMBu9FhH8OqJT7j8/CCtlD8fShWWd4vUDlKmB8YVbS3P8Mw0KjnPNlO8QmCZZFfDM=; 5:tMxM8YNsQaDpo1Bg5l4TFDmXf6ziNQB7eaRTiTtnCDGxVWj2iRqdPqckZJHuylv1Nm7vDsQN16ZIrMkPFd3Aa8WUQRxAhQwt0/qgBIcsAgsYrYDCUr0ffpTvIPORHoD3k5NfImGoFMgT4T/JViylx4VMi/brW1/9K/n3wBToyIw=; 24:AfGtiYAntKwrCBZhytR+28RaVEqlYZsYiou0XApGHuZCg0rIWv14g2RCVLT8W8sVNqSIWKfqkzKXRwk+odFK2gP0L9EUg2ZtuAWQDoI4NIM=; 7:MSQ/+nwUeMF8yNOS/WHZDsEpFwgwtkHV+zInPYGdtuIR6QtD9CwPIt0bj0ee9Og2+jcPtiNWId9ERVwHiDXoyFh1wd2xHN6oWTtlOJhbr7Bnk+KOO+wgXAUZ83+7K4RSL3y8kciARm+eBb1jfAZPp01O2iMB+tRse6Etm46s59fWoU/nkC4tb/NCyly4TlWTo7xNjmwlT3Yj0Uzqq2649c9pJaxguFlKfn79t2ojvFKZpnCAxKvvvKC4HHaF/sk6 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR12MB1307; 20:JppzVxs+nRFVXBGnubhDftnyY3LdZlXjo6W4IihkglOzHWL0xXbzymsE+Cn605RRZvtXnkOKYT+tM9lw7d6rO38A+tlHpWH0vnBkwxT5OuYaO788mF/sQThHScpHGME7P2+1B4phtaBSV+ZeESDR7kRg+jfI5K1PR1NQ3Mn38p3r3Ohy+vh6dobN06ntc8vuxenmTA9mnInQVrYO8JvO9XL/wd0r2WkkdZVu1nVy6R8ApXHqd3XG2UkW50DeVrJY X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2017 09:12:55.6095 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9fb135b9-562f-42b5-0279-08d5364036f5 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1307 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Am 27.11.2017 um 19:30 schrieb Boris Ostrovsky: > On 11/23/2017 09:12 AM, Boris Ostrovsky wrote: >> >> On 11/23/2017 03:11 AM, Christian König wrote: >>> Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: >>>> On 11/22/2017 11:54 AM, Christian König wrote: >>>>> Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: >>>>>> On 11/22/2017 05:09 AM, Christian König wrote: >>>>>>> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: >>>>>>>> On 11/21/2017 08:34 AM, Christian König wrote: >>>>>>>>> Hi Boris, >>>>>>>>> >>>>>>>>> attached are two patches. >>>>>>>>> >>>>>>>>> The first one is a trivial fix for the infinite loop issue, it now >>>>>>>>> correctly aborts the fixup when it can't find address space for >>>>>>>>> the >>>>>>>>> root window. >>>>>>>>> >>>>>>>>> The second is a workaround for your board. It simply checks if >>>>>>>>> there >>>>>>>>> is exactly one Processor Function to apply this fix on. >>>>>>>>> >>>>>>>>> Both are based on linus current master branch. Please test if they >>>>>>>>> fix >>>>>>>>> your issue. >>>>>>>> Yes, they do fix it but that's because the feature is disabled. >>>>>>>> >>>>>>>> Do you know what the actual problem was (on Xen)? >>>>>>> I still haven't understood what you actually did with Xen. >>>>>>> >>>>>>> When you used PCI pass through with those devices then you have >>>>>>> made a >>>>>>> major configuration error. >>>>>>> >>>>>>> When the problem happened on dom0 then the explanation is most >>>>>>> likely >>>>>>> that some PCI device ended up in the configured space, but the >>>>>>> routing >>>>>>> was only setup correctly on one CPU socket. >>>>>> The problem is that dom0 can be (and was in my case() booted with >>>>>> less >>>>>> than full physical memory and so the "rest" of the host memory is not >>>>>> necessarily reflected in iomem. Your patch then tried to configure >>>>>> that >>>>>> memory for MMIO and the system hang. >>>>>> >>>>>> And so my guess is that this patch will break dom0 on a single-socket >>>>>> system as well. >>>>> Oh, thanks! >>>>> >>>>> I've thought about that possibility before, but wasn't able to find a >>>>> system which actually does that. >>>>> >>>>> May I ask why the rest of the memory isn't reported to the OS? >>>> That memory doesn't belong to the OS (dom0), it is owned by the >>>> hypervisor. >>>> >>>>> Sounds like I can't trust Linux resource management and probably need >>>>> to read the DRAM config to figure things out after all. >>>> My question is whether what you are trying to do should ever be done >>>> for >>>> a guest at all (any guest, not necessarily Xen). >>> The issue is probably that I don't know enough about Xen: What >>> exactly is dom0? My understanding was that dom0 is the hypervisor, >>> but that seems to be incorrect. >>> >>> The issue is that under no circumstances *EVER* a virtualized guest >>> should have access to the PCI devices marked as "Processor Function" >>> on AMD platforms. Otherwise it is trivial to break out of the >>> virtualization. >>> >>> When dom0 is something like the system domain with all hardware >>> access then the approach seems legitimate, but then the hypervisor >>> should report the stolen memory to the OS using the e820 table. >>> >>> When the hypervisor doesn't do that and the Linux kernel isn't aware >>> that there is memory at a given location mapping PCI space there will >>> obviously crash the hypervisor. >>> >>> Possible solutions as far as I can see are either disabling this >>> feature when we detect that we are a Xen dom0, scanning the DRAM >>> settings to update Linux resource handling or fixing Xen to report >>> stolen memory to the dom0 OS as reserved. >>> >>> Opinions? >> You are right, these functions are not exposed to a regular guest. >> >> I think for dom0 (which is a special Xen guest, with additional >> privileges) we may be able to add a reserved e820 region for host >> memory that is not assigned to dom0. Let me try it on Monday (I am out >> until then). > > One thing I realized while looking at solution for Xen dom0 is that this > patch may cause problems for memory hotplug. Good point. My assumption was that when you got an BIOS which can handle memory hotplug then you also got an BIOS which doesn't need this fixup. But I've never validated that assumption. > What happens if new memory > is added to the system and we have everything above current memory set > to MMIO? In theory the BIOS would search for address space and won't find anything, so the hotplug operation should fail even before it reaches the kernel in the first place. In practice I think that nobody ever tested if that works correctly. So I'm pretty sure the system would just crash. How about the attached patch? It limits the newly added MMIO space to the upper 256GB of the address space. That should still be enough for most devices, but we avoid both issues with Xen dom0 as most likely problems with memory hotplug as well. Christian. > > -boris > From 586bd9d67ebb6ca48bd0a6b1bd9203e94093cc8e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= Date: Tue, 28 Nov 2017 10:02:35 +0100 Subject: [PATCH] x86/PCI: limit the size of the 64bit BAR to 256GB MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This avoids problems with Xen which hides some memory resources from the OS and potentially also allows memory hotplug while this fixup is enabled. Signed-off-by: Christian König --- arch/x86/pci/fixup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c index 56c39a7bd080..6dffdee8a2de 100644 --- a/arch/x86/pci/fixup.c +++ b/arch/x86/pci/fixup.c @@ -690,7 +690,7 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev) res->name = "PCI Bus 0000:00"; res->flags = IORESOURCE_PREFETCH | IORESOURCE_MEM | IORESOURCE_MEM_64 | IORESOURCE_WINDOW; - res->start = 0x100000000ull; + res->start = 0xbd00000000ull; res->end = 0xfd00000000ull - 1; /* Just grab the free area behind system memory for this */ -- 2.11.0