[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [v3][PATCH 07/16] hvmloader/pci: skip reserved ranges



On 2015/6/16 17:40, Jan Beulich wrote:
On 16.06.15 at 11:29, <tiejun.chen@xxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.