The first two patches are functionally independent, and they're presented
here merely in the order I came to notice the respective issues. At least
patch 2 wants seriously considering for 4.20.

While alternatives were considered for patch 2, it's left as it was in v1
for now. The disposition there depends on (a) the four new patches, in
particular what the last patch does and (b) backporting considerations
(we probably don't want to backport any of the radix tree tidying).

1: AMD/IOMMU: drop stray MSI enabling
2: x86/PCI: init segments earlier
3: radix-tree: purge node allocation override hooks
4: radix-tree: drop "root" parameters from radix_tree_node_{alloc,free}()
5: radix-tree: introduce RADIX_TREE{,_INIT}()
6: PCI: drop pci_segments_init()

Jan

On 2/3/25 5:22 PM, Jan Beulich wrote:
> The first two patches are functionally independent, and they're presented
> here merely in the order I came to notice the respective issues. At least
> patch 2 wants seriously considering for 4.20.
>
> While alternatives were considered for patch 2, it's left as it was in v1
> for now. The disposition there depends on (a) the four new patches, in
> particular what the last patch does and (b) backporting considerations
> (we probably don't want to backport any of the radix tree tidying).
>
> 1: AMD/IOMMU: drop stray MSI enabling
> 2: x86/PCI: init segments earlier

R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com> for first two patches.

For others it seems like nothing serious will happen if to merge them after 4.20.

~ Oleksii

> 3: radix-tree: purge node allocation override hooks
> 4: radix-tree: drop "root" parameters from radix_tree_node_{alloc,free}()
> 5: radix-tree: introduce RADIX_TREE{,_INIT}()
> 6: PCI: drop pci_segments_init()
>
> Jan

On 03.02.2025 17:38, Oleksii Kurochko wrote:
> 
> On 2/3/25 5:22 PM, Jan Beulich wrote:
>> The first two patches are functionally independent, and they're presented
>> here merely in the order I came to notice the respective issues. At least
>> patch 2 wants seriously considering for 4.20.
>>
>> While alternatives were considered for patch 2, it's left as it was in v1
>> for now. The disposition there depends on (a) the four new patches, in
>> particular what the last patch does and (b) backporting considerations
>> (we probably don't want to backport any of the radix tree tidying).
>>
>> 1: AMD/IOMMU: drop stray MSI enabling
>> 2: x86/PCI: init segments earlier
> 
> R-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com> for first two patches.
> 
> For others it seems like nothing serious will happen if to merge them after 4.20.

It took me some time to actually take two and two together, but: With the
observation underlying patch 6, patch 2 can actually be dropped altogether,
with what is now patch 5 taking the role of the bug fix. That'll make what
is now patch 3 a strict prereq then, though. I'll cut a shrunk down v3.

Jan

On 03/02/2025 4:38 pm, Oleksii Kurochko wrote:
> On 2/3/25 5:22 PM, Jan Beulich wrote:
>> The first two patches are functionally independent, and they're presented
>> here merely in the order I came to notice the respective issues. At least
>> patch 2 wants seriously considering for 4.20.
>>
>> While alternatives were considered for patch 2, it's left as it was in v1
>> for now. The disposition there depends on (a) the four new patches, in
>> particular what the last patch does and (b) backporting considerations
>> (we probably don't want to backport any of the radix tree tidying).
>>
>> 1: AMD/IOMMU: drop stray MSI enabling
>> 2: x86/PCI: init segments earlier
> R-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> for first two patches.
> For others it seems like nothing serious will happen if to merge them after 4.20.

The reason I asked for them is because I think they're a far more robust
fix than just patch 2 in isolation.  That goes for older versions of Xen
too.

~Andrew