From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v2 4/5] hvmloader: Fix check for needing a 64-bit bar Date: Thu, 20 Jun 2013 11:21:12 +0100 Message-ID: <51C2D798.20404@eu.citrix.com> References: <1371573984-28514-1-git-send-email-george.dunlap@eu.citrix.com> <1371573984-28514-4-git-send-email-george.dunlap@eu.citrix.com> <51C2EF2402000078000DF497@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51C2EF2402000078000DF497@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Ian Jackson , xen-devel@lists.xen.org, Stefano Stabellini , Ian Campbell , Hanweidong List-Id: xen-devel@lists.xenproject.org On 20/06/13 11:01, Jan Beulich wrote: >>>> On 18.06.13 at 18:46, George Dunlap wrote: >> After attempting to resize the MMIO hole, the check to determine >> whether there is a need to relocate BARs into 64-bit space checks the >> specific thing that caused the loop to exit (MMIO hole == 2GiB) rather >> than checking whether the required MMIO will fit in the hole. >> >> This should have no functional change now, but will make the next patch >> (when we add more conditions for exiting the loop) more clean. > This does change functionality, but in a desirable way: With what > the code did before, even if pci_mem_start remained at its start > value, bar64_relocate would end up getting set to 1, while it would > be left at 0 when pci_mem_start got lowered down to 2Gb. I.e. it > seems to me that the original condition was inverted. Oh -- good point. But the relocation was never triggered before because bar_sz was always < mmio_left. In that case, this patch should go earlier in the series, before we actually start doing functional changes. -George