|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 06/21] IOMMU/x86: perform PV Dom0 mappings in batches
On 04.05.2022 15:55, Roger Pau Monné wrote:
> On Wed, May 04, 2022 at 02:27:14PM +0200, Jan Beulich wrote:
>> On 04.05.2022 13:20, Roger Pau Monné wrote:
>>> On Wed, May 04, 2022 at 11:46:37AM +0200, Jan Beulich wrote:
>>>> On 03.05.2022 16:49, Roger Pau Monné wrote:
>>>>> On Mon, Apr 25, 2022 at 10:34:59AM +0200, Jan Beulich wrote:
>>>>>> @@ -390,20 +390,41 @@ void __hwdom_init arch_iommu_hwdom_init(
>>>>>> if ( !perms )
>>>>>> rc = 0;
>>>>>> else if ( paging_mode_translate(d) )
>>>>>> + {
>>>>>> rc = p2m_add_identity_entry(d, pfn,
>>>>>> perms & IOMMUF_writable ?
>>>>>> p2m_access_rw
>>>>>> :
>>>>>> p2m_access_r,
>>>>>> 0);
>>>>>> + if ( rc )
>>>>>> + printk(XENLOG_WARNING
>>>>>> + "%pd: identity mapping of %lx failed: %d\n",
>>>>>> + d, pfn, rc);
>>>>>> + }
>>>>>> + else if ( pfn != start + count || perms != start_perms )
>>>>>> + {
>>>>>> + commit:
>>>>>> + rc = iommu_map(d, _dfn(start), _mfn(start), count,
>>>>>> start_perms,
>>>>>> + &flush_flags);
>>>>>> + if ( rc )
>>>>>> + printk(XENLOG_WARNING
>>>>>> + "%pd: IOMMU identity mapping of [%lx,%lx)
>>>>>> failed: %d\n",
>>>>>> + d, pfn, pfn + count, rc);
>>>>>> + SWAP(start, pfn);
>>>>>> + start_perms = perms;
>>>>>> + count = 1;
>>>>>> + }
>>>>>> else
>>>>>> - rc = iommu_map(d, _dfn(pfn), _mfn(pfn), 1ul <<
>>>>>> PAGE_ORDER_4K,
>>>>>> - perms, &flush_flags);
>>>>>> + {
>>>>>> + ++count;
>>>>>> + rc = 0;
>>>>>
>>>>> Seeing as we want to process this in blocks now, I wonder whether it
>>>>> would make sense to take a different approach, and use a rangeset to
>>>>> track which regions need to be mapped. What gets added would be based
>>>>> on the host e820 plus the options
>>>>> iommu_hwdom_{strict,inclusive,reserved}. We would then punch holes
>>>>> based on the logic in hwdom_iommu_map() and finally we could iterate
>>>>> over the regions afterwards using rangeset_consume_ranges().
>>>>>
>>>>> Not that you strictly need to do it here, just think the end result
>>>>> would be clearer.
>>>>
>>>> The end result might indeed be, but it would be more of a change right
>>>> here. Hence I'd prefer to leave that out of the series for now.
>>>
>>> OK. I think it might be nice to add a comment in that regard, mostly
>>> because I tend to forget myself.
>>
>> Sure, I've added another post-commit-message remark.
>
> Sorry for being confused, but are those reflected in the final commit
> message, or in the code itself?
Neither - I didn't think we have any code comments anywhere which outline
future plans, including reasons why not doing so right away. When writing
that new remark I didn't even think it would belong in the commit message.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |