Re: [PATCH v4 4/4] x86/iommu: add reserved dom0-iommu option to map reserved memory ranges

["Jan Beulich" <JBeulich@suse.com>]

>>> On 09.08.18 at 12:23, <roger.pau@citrix.com> wrote:
> On Thu, Aug 09, 2018 at 01:36:57AM -0600, Jan Beulich wrote:
>> >>> On 08.08.18 at 18:18, <roger.pau@citrix.com> wrote:
>> > On Wed, Aug 08, 2018 at 07:15:54AM -0600, Jan Beulich wrote:
>> >> >>> On 08.08.18 at 12:07, <roger.pau@citrix.com> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel