From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v3][PATCH 07/16] hvmloader/pci: skip reserved ranges Date: Wed, 17 Jun 2015 15:10:08 +0800 Message-ID: <55811D50.2070002@intel.com> References: <1433985325-16676-1-git-send-email-tiejun.chen@intel.com> <1433985325-16676-8-git-send-email-tiejun.chen@intel.com> <557A9000.600@intel.com> <557FEC6A.1080003@intel.com> <55800B21020000780008561E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55800B21020000780008561E@mail.emea.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: "tim@xen.org" , Kevin Tian , "wei.liu2@citrix.com" , "ian.campbell@citrix.com" , "andrew.cooper3@citrix.com" , "Ian.Jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , "stefano.stabellini@citrix.com" , Yang Z Zhang List-Id: xen-devel@lists.xenproject.org On 2015/6/16 17:40, Jan Beulich wrote: >>>> On 16.06.15 at 11:29, wrote: >> I'm trying to walk into this direction: >> >> /* >> * We'll skip all space overlapping with reserved memory later, >> * so we need to increase mmio_total to compensate them. >> */ >> for ( j = 0; j < memory_map.nr_map ; j++ ) >> { >> uint64_t conflict_size = 0; >> if ( memory_map.map[j].type != E820_RAM ) >> { >> reserved_start = memory_map.map[j].addr; >> reserved_size = memory_map.map[j].size; >> reserved_end = reserved_start + reserved_size; >> if ( check_overlap(pci_mem_start, pci_mem_end - pci_mem_start, >> reserved_start, reserved_size) ) >> { >> /* >> * Calculate how much mmio range conflict with >> * reserved device memory. >> */ >> conflict_size += reserved_size; >> >> /* >> * But we may need to subtract those sizes beyond the >> * pci memory, [pci_mem_start, pci_mem_end]. >> */ >> if ( reserved_start < pci_mem_start ) >> conflict_size -= (pci_mem_start - reserved_start); >> if ( reserved_end > pci_mem_end ) >> conflict_size -= (reserved_end - pci_mem_end); >> } >> } >> >> if ( conflict_size ) >> { >> uint64_t conflict_size = max_t( >> uint64_t, conflict_size, max_bar_sz); >> conflict_size &= ~(conflict_size - 1); >> mmio_total += conflict_size; >> } >> } > > This last thing goes in the right direction, but is complete overkill > when you have a small reserved region and a huge BAR. You Yeah, this may waste some spaces in this worst case but I this think this can guarantee our change don't impact on the original expectation, right? > ought to work out the smallest power-of-2 region enclosing the Okay. I remember the smallest size of a given PCI I/O space is 8 bytes, and the smallest size of a PCI memory space is 16 bytes. So /* At least 16 bytes to align a PCI BAR size. */ uint64_t align = 16; reserved_start = memory_map.map[j].addr; reserved_size = memory_map.map[j].size; reserved_start = (reserved_star + align) & ~(align - 1); reserved_size = (reserved_size + align) & ~(align - 1); Is this correct? > reserved range (albeit there are tricky corner cases to consider). > Yeah, its a little tricky since RMRR always owns a fixed start address, so we can't reorder them with all pci bars. I just think at least we should provide a correct solution now, then further look into what can be optimized. So I think we'd better get conflict_size with max(conflict_size, max_bar_sz), right? Thanks Tiejun