From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24F5FC2BB85 for ; Tue, 14 Apr 2020 09:29:31 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 014EA206D5 for ; Tue, 14 Apr 2020 09:29:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 014EA206D5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jOHsU-0008Lq-F2; Tue, 14 Apr 2020 09:29:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jOHsT-0008Ll-AP for xen-devel@lists.xenproject.org; Tue, 14 Apr 2020 09:29:09 +0000 X-Inumbo-ID: 63cbfa84-7e32-11ea-b4f4-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 63cbfa84-7e32-11ea-b4f4-bc764e2007e4; Tue, 14 Apr 2020 09:29:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4EC51AEFD; Tue, 14 Apr 2020 09:29:06 +0000 (UTC) Subject: Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all resource allocation To: "Shamsundara Havanur, Harsha" References: <612892f2fed5cb02cbec289589e437d9badb8cc1.camel@amazon.com> <6e3732e8-01d0-e9de-e89a-cd1b5833e5a1@suse.com> From: Jan Beulich Message-ID: Date: Tue, 14 Apr 2020 11:29:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "wl@xen.org" , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 14.04.2020 11:22, Shamsundara Havanur, Harsha wrote: > On Tue, 2020-04-14 at 11:14 +0200, Jan Beulich wrote: >> CAUTION: This email originated from outside of the organization. Do >> not click links or open attachments unless you can confirm the sender >> and know the content is safe. >> >> >> >> On 14.04.2020 11:00, Shamsundara Havanur, Harsha wrote: >>> On Tue, 2020-04-14 at 09:42 +0200, Jan Beulich wrote: >>>> On 13.04.2020 23:33, Harsha Shamsundara Havanur wrote: >>>>> @@ -289,9 +293,22 @@ void pci_setup(void) >>>>> devfn>>3, devfn&7, 'A'+pin-1, isa_irq); >>>>> } >>>>> >>>>> - /* Enable bus mastering. */ >>>>> + /* >>>>> + * Disable bus mastering, memory and I/O space, which >>>>> is >>>>> typical device >>>>> + * reset state. It is recommended that BAR programming >>>>> be >>>>> done whilst >>>>> + * decode bits are cleared to avoid incorrect mappings >>>>> being created, >>>>> + * when 64-bit memory BAR is programmed first by >>>>> writing >>>>> the lower half >>>>> + * and then the upper half, which first maps to an >>>>> address >>>>> under 4G >>>>> + * replacing any RAM mapped in that address, which is >>>>> not >>>>> restored >>>>> + * back after the upper half is written and PCI memory >>>>> is >>>>> correctly >>>>> + * mapped to its intended high mem address. >>>>> + * >>>>> + * Capture the state of bus master to restore it back >>>>> once >>>>> BAR >>>>> + * programming is completed. >>>>> + */ >>>>> cmd = pci_readw(devfn, PCI_COMMAND); >>>>> - cmd |= PCI_COMMAND_MASTER; >>>>> + pci_devfn_decode_type[devfn] = cmd & >>>>> ~(PCI_COMMAND_MEMORY >>>>>> PCI_COMMAND_IO); >>>>> >>>>> + cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | >>>>> PCI_COMMAND_IO); >>>> >>>> The disabling of MASTER was put under question in v1 already. >>> >>> Disabling of MASTER is done whilst programming BARs and it is >>> restored >>> back to its previous value in the loop at the end of pci_setup >>> function. >> >> Yet didn't Andrew indicate he knows of devices which get upset if >> MASTER _ever_ gets cleared? > > Previous commit enabled MASTER for all functions. I am bit confused > here on the consensus on enabling/disabling/retaining BME. > Should we even care about MASTER? With the commit introducing its universal setting, I'm afraid to avoid regressions we can't sensibly alter the behavior unless it can be explained clearly why the original change must have been outright wrong. Jan