[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 4/4] x86/iommu: add reserved dom0-iommu option to map reserved memory ranges
>>> On 09.08.18 at 12:23, <roger.pau@xxxxxxxxxx> wrote: > On Thu, Aug 09, 2018 at 01:36:57AM -0600, Jan Beulich wrote: >> >>> On 08.08.18 at 18:18, <roger.pau@xxxxxxxxxx> wrote: >> > On Wed, Aug 08, 2018 at 07:15:54AM -0600, Jan Beulich wrote: >> >> >>> On 08.08.18 at 12:07, <roger.pau@xxxxxxxxxx> wrote: >> >> > + /* >> >> > + * If dom0-strict mode is enabled or the guest type is PVH/HVM >> >> > then exclude >> >> > + * conventional RAM and let the common code map dom0's pages. >> >> > + */ >> >> > + if ( page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL) && >> >> > + (iommu_dom0_strict || is_hvm_domain(d)) ) >> >> > + return false; >> >> > + if ( page_is_ram_type(pfn, RAM_TYPE_RESERVED) && >> >> > + !iommu_dom0_reserved && !iommu_dom0_inclusive ) >> >> > + return false; >> >> > + if ( !page_is_ram_type(pfn, RAM_TYPE_UNUSABLE) && >> >> > + !page_is_ram_type(pfn, RAM_TYPE_RESERVED) && >> >> > + !page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL) && >> >> > + (!iommu_dom0_inclusive || pfn > max_pfn) ) >> >> > + return false; >> >> >> >> As page_is_ram_type() is, especially on systems with many E820 >> >> entries, not really cheap, I think at least a minimum amount of >> >> optimization is on order here - after all you do this for every >> >> single page of the system. Hence minimally the result of the first >> >> CONVENTIONAL and RESERVED queries should be latched and >> >> re-used (or "else" be used suitably). Ideally an approach would >> >> be used which involved just a single iteration through the E820 >> >> map, but I realize this may be more than is feasible here. >> > >> > This would be quite better if I could just fetch the type, then I >> > could add a switch (type) { ... and it would be better IMO. >> >> Except that, as said, there's no "the" type for an entire page. >> Only a single byte can have an exact type. > > Right, I don0t think the original code was much better in that regard > anyway, neither I'm sure about how to handle this any better. And I'm not demanding that you improve it beyond what's there at this point. But we need to be reasonably certain it doesn't regress. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |