>>> On 20.11.14 at 09:12, <tiejun.c...@intel.com> wrote: > On 2014/11/20 15:31, Jan Beulich wrote: >>>>> On 19.11.14 at 02:26, <tiejun.c...@intel.com> wrote: >>> int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt) >>> { >>> struct acpi_rmrr_unit *rmrr; >>> int rc = 0; >>> unsigned int i; >>> u16 bdf; >>> >>> for_each_rmrr_device ( rmrr, bdf, i ) >>> { >>> rc = func(PFN_DOWN(rmrr->base_address), >>> PFN_UP(rmrr->end_address) - >>> PFN_DOWN(rmrr->base_address), >>> PCI_SBDF(rmrr->segment, bdf), >>> ctxt); >>> /* Hit this entry so just go next. */ >>> if ( rc == 1 ) >>> i = rmrr->scope.devices_cnt; >>> else if ( rc < 0 ) >>> return rc; >>> } >>> >>> return rc; >>> } >> >> Better. Another improvement would be make it not depend on the >> internal workings of for_each_rmrr_device()... And in any case you > > Yes but as you see, > > #define for_each_rmrr_device(rmrr, bdf, idx) \ > list_for_each_entry(rmrr, &acpi_rmrr_units, list) \ > /* assume there never is a bdf == 0 */ \ > for (idx = 0; (bdf = rmrr->scope.devices[idx]) && \ > idx < rmrr->scope.devices_cnt; idx++) > > So, > for_each_rmrr_device ( rmrr, bdf, i ) > { > rc = func(...); > /* Hit this entry so just go next. */ > if ( rc > 0 ) > i = rmrr->scope.devices_cnt; > > If you don't intend to reset something of this internal working, its > hard to go next rmrr entry. Maybe you already have idea, so could you > give me some hints?
Have a second struct acpi_rmrr_unit pointer, starting out as NULL and getting set to the current one when the callback returns a positive value. Skip further iterations as long as both pointers match. >> should not special case 1 - just return when rc is negative and skip >> the rest of the current RMRR when it's positive. And of course make >> the function's final return value predictable. >> > > Like this, > > /* Hit this entry so just go next. */ > if ( rc > 0 ) > xxxx; > else if ( rc < 0 ) > return rc; > } Yes, albeit swapping the order (and dropping the "else" along with adding unlikely() to the error case) would be preferred. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel