On 11.08.2022 17:09, Andrew Cooper wrote:
> On 11/08/2022 14:26, Jan Beulich wrote:
>> On 11.08.2022 15:21, Andrew Cooper wrote:
>>> On 11/08/2022 11:52, Jan Beulich wrote:
>>>> --- a/xen/arch/x86/irq.c
>>>> +++ b/xen/arch/x86/irq.c
>>>> @@ -2162,7 +2162,7 @@ int map_domain_pirq(
>>>> if ( !cpu_has_apic )
>>>> goto done;
>>>>
>>>> - pdev = pci_get_pdev_by_domain(d, msi->seg, msi->bus, msi->devfn);
>>>> + pdev = pci_get_pdev(d, PCI_SBDF(msi->seg, msi->bus, msi->devfn));
>>> Oh, I should really have read this patch before trying to do the sbdf
>>> conversion in patch 1.
>>>
>>> However, it occurs to me that this:
>>>
>>> diff --git a/xen/arch/x86/include/asm/msi.h b/xen/arch/x86/include/asm/msi.h
>>> index 117379318f2c..6f0ab845017c 100644
>>> --- a/xen/arch/x86/include/asm/msi.h
>>> +++ b/xen/arch/x86/include/asm/msi.h
>>> @@ -59,9 +59,14 @@
>>> #define FIX_MSIX_MAX_PAGES 512
>>>
>>> struct msi_info {
>>> - u16 seg;
>>> - u8 bus;
>>> - u8 devfn;
>>> + union {
>>> + struct {
>>> + u8 devfn;
>>> + u8 bus;
>>> + u16 seg;
>>> + };
>>> + pci_sbdf_t sbdf;
>>> + };
>>> int irq;
>>> int entry_nr;
>>> uint64_t table_base;
>>>
>>> will simplify several hunks in this patch, because you can just pass
>>> msi->sbdf rather than reconstructing it by reversing 32 bits worth of
>>> data from their in-memory representation.
>> No, I'm strictly against introducing a 2nd instance of such aliasing
>> (we already have one in struct pci_dev, and that's bad enough). There
>> could be _only_ an "sbdf" field here, yes, but that'll have knock-on
>> effects elsewhere, so wants to be a separate change. And there are far
>> more places where imo we'll want to use pci_sbdf_t.
>
> What's the likelihood of getting to that before 4.17 goes out?
Well, I can try to get to making a patch tomorrow, just in time to meet
the submission deadline. But that's not really a promise ...
Jan
> I'd prefer to see it fixed, and obviously even more conversion to sbdf_t
> is better.
>
> Basically, I'm happy for the conversion to not be in this patch, as long
> it's not going to get forgotten.
>
> ~Andrew
