| Message ID | 30f29dde-15e1-4af9-b86f-0040658c381a@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | AMD/IOMMU: assorted corrections | expand |
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 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
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
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