[Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 1618 bytes --]

Hi,

I have a multi-function PCI device, behind a PCI bridge, that normally
I assign to a single domain. But now it fails with:

(XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)

This is Xen 4.8.5 + XSA patches. It started happening after some update
during last few months, not really sure which one.

I guess it is because quarantine feature, so initial ownership of
0000:05:00.0 is different than the bridge it is connected to.
I'm not sure if relevant for this case, but I also set
pcidev->rdm_policy = LIBXL_RDM_RESERVE_POLICY_RELAXED.

Booting with iommu=no-quarantine helps. Note I do not use `xl
pci-assignable-add` command, only bind the device to the pciback driver
in dom0.

Relevant part of lspci and lspci -t:

00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
..
00:1c.3 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 4 (rev d0)
..
04:00.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 41)
05:00.0 USB controller: NEC Corporation OHCI USB Controller (rev 43)
05:00.1 USB controller: NEC Corporation OHCI USB Controller (rev 43)
05:00.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04)

-[0000:00]-+-00.0
..
           +-1c.3-[04-05]----00.0-[05]--+-00.0
           |                            +-00.1
           |                            \-00.2


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Jan Beulich]

On 04.01.2020 02:07, Marek Marczykowski-Górecki  wrote:
> I have a multi-function PCI device, behind a PCI bridge, that normally
> I assign to a single domain. But now it fails with:
> 
> (XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)

Is this on the 1st attempt, or after the device had already been
assigned to some (same or other) guest? After quite a bit of
staring at the code I can't seem to be able to spot a difference
in behavior for the 1st attempt, but you not saying explicitly
that it would only happen on subsequent ones makes me assume you
run into the issue right away.

> This is Xen 4.8.5 + XSA patches. It started happening after some update
> during last few months, not really sure which one.

Having a smaller window would of course help, as would ...

> I guess it is because quarantine feature, so initial ownership of
> 0000:05:00.0 is different than the bridge it is connected to.
> I'm not sure if relevant for this case, but I also set
> pcidev->rdm_policy = LIBXL_RDM_RESERVE_POLICY_RELAXED.
> 
> Booting with iommu=no-quarantine helps. Note I do not use `xl
> pci-assignable-add` command, only bind the device to the pciback driver
> in dom0.

... knowing whether behavior differs when using this preparatory
step.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 2659 bytes --]

On Mon, Jan 06, 2020 at 12:18:31PM +0100, Jan Beulich wrote:
> On 04.01.2020 02:07, Marek Marczykowski-Górecki  wrote:
> > I have a multi-function PCI device, behind a PCI bridge, that normally
> > I assign to a single domain. But now it fails with:
> > 
> > (XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)
> 
> Is this on the 1st attempt, or after the device had already been
> assigned to some (same or other) guest? After quite a bit of
> staring at the code I can't seem to be able to spot a difference
> in behavior for the 1st attempt, but you not saying explicitly
> that it would only happen on subsequent ones makes me assume you
> run into the issue right away.

Yes, it was the first try.

> > This is Xen 4.8.5 + XSA patches. It started happening after some update
> > during last few months, not really sure which one.
> 
> Having a smaller window would of course help, as would ...

The working version was just before XSAs of 2019-10-31  (which include
XSA-302).
But at this point, I'm not sure if no other configuration changes were
made (see below).

> > I guess it is because quarantine feature, so initial ownership of
> > 0000:05:00.0 is different than the bridge it is connected to.
> > I'm not sure if relevant for this case, but I also set
> > pcidev->rdm_policy = LIBXL_RDM_RESERVE_POLICY_RELAXED.
> > 
> > Booting with iommu=no-quarantine helps. Note I do not use `xl
> > pci-assignable-add` command, only bind the device to the pciback driver
> > in dom0.
> 
> ... knowing whether behavior differs when using this preparatory
> step.

xl pci-assignable-add doesn't make a difference with XSA-306 applied.
But I've tried xl pci-assignable-remove with interesting result:
It succeeded for 0000:05:00.0 and 0000:05:00.2, but failed for
0000:05:00.1 with this message:

(XEN) [VT-D]d0: 0000:05:00.1 owned by d32753!<G><0>deassign 0000:05:00.1
from dom32753 failed (-22)

Anyway, I think my previous testing was inaccurate:
Looks like the issue is caused by me failing to set rdm_policy, contrary
to the above message. I get the above error only without
LIBXL_RDM_RESERVE_POLICY_RELAXED set. When I set it properly, domain
starts even without iommu=no-quarantine. I still have some issues with
the device within the domain, but not sure if relevant to this or
something else.

Does it make sense now?
Is the patch from your other message still relevant?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 2826 bytes --]

On Mon, Jan 06, 2020 at 03:04:20PM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 06, 2020 at 12:18:31PM +0100, Jan Beulich wrote:
> > On 04.01.2020 02:07, Marek Marczykowski-Górecki  wrote:
> > > I have a multi-function PCI device, behind a PCI bridge, that normally
> > > I assign to a single domain. But now it fails with:
> > > 
> > > (XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)
> > 
> > Is this on the 1st attempt, or after the device had already been
> > assigned to some (same or other) guest? After quite a bit of
> > staring at the code I can't seem to be able to spot a difference
> > in behavior for the 1st attempt, but you not saying explicitly
> > that it would only happen on subsequent ones makes me assume you
> > run into the issue right away.
> 
> Yes, it was the first try.
> 
> > > This is Xen 4.8.5 + XSA patches. It started happening after some update
> > > during last few months, not really sure which one.
> > 
> > Having a smaller window would of course help, as would ...
> 
> The working version was just before XSAs of 2019-10-31  (which include
> XSA-302).
> But at this point, I'm not sure if no other configuration changes were
> made (see below).
> 
> > > I guess it is because quarantine feature, so initial ownership of
> > > 0000:05:00.0 is different than the bridge it is connected to.
> > > I'm not sure if relevant for this case, but I also set
> > > pcidev->rdm_policy = LIBXL_RDM_RESERVE_POLICY_RELAXED.
> > > 
> > > Booting with iommu=no-quarantine helps. Note I do not use `xl
> > > pci-assignable-add` command, only bind the device to the pciback driver
> > > in dom0.
> > 
> > ... knowing whether behavior differs when using this preparatory
> > step.
> 
> xl pci-assignable-add doesn't make a difference with XSA-306 applied.
> But I've tried xl pci-assignable-remove with interesting result:
> It succeeded for 0000:05:00.0 and 0000:05:00.2, but failed for
> 0000:05:00.1 with this message:
> 
> (XEN) [VT-D]d0: 0000:05:00.1 owned by d32753!<G><0>deassign 0000:05:00.1
> from dom32753 failed (-22)

And now, after this operation (failed -remove) I get the following error
on domain start, even with LIBXL_RDM_RESERVE_POLICY_RELAXED properly
set:

(XEN) [VT-D]d13: 0000:05:00.1 owned by d32753!<G><0>assign 0000:05:00.1 to dom13 failed (-22)

I've tried doing -add and -remove in different order and every time it
fails for 0000:05:00.1, but works for other functions.
I don't see anything special about this function, compared to others.

I'll reboot the system and try again...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 3552 bytes --]

On Mon, Jan 06, 2020 at 03:16:11PM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 06, 2020 at 03:04:20PM +0100, Marek Marczykowski-Górecki wrote:
> > On Mon, Jan 06, 2020 at 12:18:31PM +0100, Jan Beulich wrote:
> > > On 04.01.2020 02:07, Marek Marczykowski-Górecki  wrote:
> > > > I have a multi-function PCI device, behind a PCI bridge, that normally
> > > > I assign to a single domain. But now it fails with:
> > > > 
> > > > (XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)
> > > 
> > > Is this on the 1st attempt, or after the device had already been
> > > assigned to some (same or other) guest? After quite a bit of
> > > staring at the code I can't seem to be able to spot a difference
> > > in behavior for the 1st attempt, but you not saying explicitly
> > > that it would only happen on subsequent ones makes me assume you
> > > run into the issue right away.
> > 
> > Yes, it was the first try.
> > 
> > > > This is Xen 4.8.5 + XSA patches. It started happening after some update
> > > > during last few months, not really sure which one.
> > > 
> > > Having a smaller window would of course help, as would ...
> > 
> > The working version was just before XSAs of 2019-10-31  (which include
> > XSA-302).
> > But at this point, I'm not sure if no other configuration changes were
> > made (see below).
> > 
> > > > I guess it is because quarantine feature, so initial ownership of
> > > > 0000:05:00.0 is different than the bridge it is connected to.
> > > > I'm not sure if relevant for this case, but I also set
> > > > pcidev->rdm_policy = LIBXL_RDM_RESERVE_POLICY_RELAXED.
> > > > 
> > > > Booting with iommu=no-quarantine helps. Note I do not use `xl
> > > > pci-assignable-add` command, only bind the device to the pciback driver
> > > > in dom0.
> > > 
> > > ... knowing whether behavior differs when using this preparatory
> > > step.
> > 
> > xl pci-assignable-add doesn't make a difference with XSA-306 applied.
> > But I've tried xl pci-assignable-remove with interesting result:
> > It succeeded for 0000:05:00.0 and 0000:05:00.2, but failed for
> > 0000:05:00.1 with this message:
> > 
> > (XEN) [VT-D]d0: 0000:05:00.1 owned by d32753!<G><0>deassign 0000:05:00.1
> > from dom32753 failed (-22)
> 
> And now, after this operation (failed -remove) I get the following error
> on domain start, even with LIBXL_RDM_RESERVE_POLICY_RELAXED properly
> set:
> 
> (XEN) [VT-D]d13: 0000:05:00.1 owned by d32753!<G><0>assign 0000:05:00.1 to dom13 failed (-22)
> 
> I've tried doing -add and -remove in different order and every time it
> fails for 0000:05:00.1, but works for other functions.
> I don't see anything special about this function, compared to others.
> 
> I'll reboot the system and try again...

After fresh reboot:

1. xl debug-keys Q says 0000:05:00.* are assigned to dom0.
2. xl pci-assignable-add 0000:05:00.* (in order: .0, .1, .2)
3. domain start (with LIBXL_RDM_RESERVE_POLICY_RELAXED set) fails:

(XEN) [VT-D]d5: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.2 to dom5 failed (-22)

4. xl debug-keys Q says 0000:05:00.* are assigned to d32753
5. domain start (with LIBXL_RDM_RESERVE_POLICY_RELAXED set) fails:

(XEN) [VT-D]d7: 0000:05:00.2 owned by d32753!<G><0>assign 0000:05:00.2 to dom7 failed (-22)

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Jan Beulich]

On 06.01.2020 15:04, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 06, 2020 at 12:18:31PM +0100, Jan Beulich wrote:
>> On 04.01.2020 02:07, Marek Marczykowski-Górecki  wrote:
>>> I have a multi-function PCI device, behind a PCI bridge, that normally
>>> I assign to a single domain. But now it fails with:
>>>
>>> (XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)
>>
>> Is this on the 1st attempt, or after the device had already been
>> assigned to some (same or other) guest? After quite a bit of
>> staring at the code I can't seem to be able to spot a difference
>> in behavior for the 1st attempt, but you not saying explicitly
>> that it would only happen on subsequent ones makes me assume you
>> run into the issue right away.
> 
> Yes, it was the first try.
> 
>>> This is Xen 4.8.5 + XSA patches. It started happening after some update
>>> during last few months, not really sure which one.
>>
>> Having a smaller window would of course help, as would ...
> 
> The working version was just before XSAs of 2019-10-31  (which include
> XSA-302).
> But at this point, I'm not sure if no other configuration changes were
> made (see below).
> 
>>> I guess it is because quarantine feature, so initial ownership of
>>> 0000:05:00.0 is different than the bridge it is connected to.
>>> I'm not sure if relevant for this case, but I also set
>>> pcidev->rdm_policy = LIBXL_RDM_RESERVE_POLICY_RELAXED.
>>>
>>> Booting with iommu=no-quarantine helps. Note I do not use `xl
>>> pci-assignable-add` command, only bind the device to the pciback driver
>>> in dom0.
>>
>> ... knowing whether behavior differs when using this preparatory
>> step.
> 
> xl pci-assignable-add doesn't make a difference with XSA-306 applied.
> But I've tried xl pci-assignable-remove with interesting result:
> It succeeded for 0000:05:00.0 and 0000:05:00.2, but failed for
> 0000:05:00.1 with this message:
> 
> (XEN) [VT-D]d0: 0000:05:00.1 owned by d32753!<G><0>deassign 0000:05:00.1
> from dom32753 failed (-22)
> 
> Anyway, I think my previous testing was inaccurate:
> Looks like the issue is caused by me failing to set rdm_policy, contrary
> to the above message. I get the above error only without
> LIBXL_RDM_RESERVE_POLICY_RELAXED set. When I set it properly, domain
> starts even without iommu=no-quarantine. I still have some issues with
> the device within the domain, but not sure if relevant to this or
> something else.
> 
> Does it make sense now?

Well, hard to tell - I still can't see what might be wrong, beyond ...

> Is the patch from your other message still relevant?

... what this patch deals with. The answer to your question is "yes",
also in light of your subsequent replies, albeit I still wouldn't be
able to tell why things did work for you before.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Marek Marczykowski-Górecki]

[-- Attachment #1.1: Type: text/plain, Size: 675 bytes --]

On Mon, Jan 06, 2020 at 03:38:46PM +0100, Jan Beulich wrote:
> On 06.01.2020 15:04, Marek Marczykowski-Górecki wrote:
> > Is the patch from your other message still relevant?
> 
> ... what this patch deals with. The answer to your question is "yes",
> also in light of your subsequent replies, albeit I still wouldn't be
> able to tell why things did work for you before.

With your patch applied the domain starts now, regardless of
LIBXL_RDM_RESERVE_POLICY_RELAXED set or not.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Jan Beulich]

On 04.01.2020 02:07, Marek Marczykowski-Górecki  wrote:
> I have a multi-function PCI device, behind a PCI bridge, that normally
> I assign to a single domain. But now it fails with:
> 
> (XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)

I've tried this out in as close a setup as I could arrange for, but
not one matching your scenario. I didn't find a system with a
suitably placed (in the topology) multi-function device (had to use
a single-function one), and of course I did this on (close to)
master. No anomalies. Hence I wonder whether either of the two
differences mentioned matters, and - if, as I suspect, it's the
multi-function aspect that is relevant here - how things would have
worked at all before those recent changes. This is because I think
you should have hit the same error path even before, and it would
seem to me that the patch below might be (and have been) needed.

Jan

--- unstable.orig/xen/drivers/passthrough/vtd/iommu.c
+++ unstable/xen/drivers/passthrough/vtd/iommu.c
@@ -1505,7 +1505,7 @@ static int domain_context_mapping(struct
             break;
 
         ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn,
-                                         pci_get_pdev(seg, bus, devfn));
+                                         NULL);
 
         /*
          * Devices behind PCIe-to-PCI/PCIx bridge may generate different
@@ -1515,7 +1515,7 @@ static int domain_context_mapping(struct
         if ( !ret && pdev_type(seg, bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE &&
              (secbus != pdev->bus || pdev->devfn != 0) )
             ret = domain_context_mapping_one(domain, drhd->iommu, secbus, 0,
-                                             pci_get_pdev(seg, secbus, 0));
+                                             NULL);
 
         break;
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Pasi Kärkkäinen]

Hi,

On Mon, Jan 06, 2020 at 02:06:14PM +0100, Jan Beulich wrote:
> On 04.01.2020 02:07, Marek Marczykowski-Górecki  wrote:
> > I have a multi-function PCI device, behind a PCI bridge, that normally
> > I assign to a single domain. But now it fails with:
> > 
> > (XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)
> 
> I've tried this out in as close a setup as I could arrange for, but
> not one matching your scenario. I didn't find a system with a
> suitably placed (in the topology) multi-function device (had to use
> a single-function one), and of course I did this on (close to)
> master. No anomalies. Hence I wonder whether either of the two
> differences mentioned matters, and - if, as I suspect, it's the
> multi-function aspect that is relevant here - how things would have
> worked at all before those recent changes. This is because I think
> you should have hit the same error path even before, and it would
> seem to me that the patch below might be (and have been) needed.
> 

I think Marek confirmed in the other mail that this patch fixes the issue.

Are you planning to merge this patch?


Thanks,

-- Pasi

> Jan
> 
> --- unstable.orig/xen/drivers/passthrough/vtd/iommu.c
> +++ unstable/xen/drivers/passthrough/vtd/iommu.c
> @@ -1505,7 +1505,7 @@ static int domain_context_mapping(struct
>              break;
>  
>          ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn,
> -                                         pci_get_pdev(seg, bus, devfn));
> +                                         NULL);
>  
>          /*
>           * Devices behind PCIe-to-PCI/PCIx bridge may generate different
> @@ -1515,7 +1515,7 @@ static int domain_context_mapping(struct
>          if ( !ret && pdev_type(seg, bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE &&
>               (secbus != pdev->bus || pdev->devfn != 0) )
>              ret = domain_context_mapping_one(domain, drhd->iommu, secbus, 0,
> -                                             pci_get_pdev(seg, secbus, 0));
> +                                             NULL);
>  
>          break;
>  
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Jan Beulich]

On 19.01.2020 11:39, Pasi Kärkkäinen wrote:
> On Mon, Jan 06, 2020 at 02:06:14PM +0100, Jan Beulich wrote:
>> On 04.01.2020 02:07, Marek Marczykowski-Górecki  wrote:
>>> I have a multi-function PCI device, behind a PCI bridge, that normally
>>> I assign to a single domain. But now it fails with:
>>>
>>> (XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)
>>
>> I've tried this out in as close a setup as I could arrange for, but
>> not one matching your scenario. I didn't find a system with a
>> suitably placed (in the topology) multi-function device (had to use
>> a single-function one), and of course I did this on (close to)
>> master. No anomalies. Hence I wonder whether either of the two
>> differences mentioned matters, and - if, as I suspect, it's the
>> multi-function aspect that is relevant here - how things would have
>> worked at all before those recent changes. This is because I think
>> you should have hit the same error path even before, and it would
>> seem to me that the patch below might be (and have been) needed.
>>
> 
> I think Marek confirmed in the other mail that this patch fixes the issue.
> 
> Are you planning to merge this patch?

Well, it is still pending a maintainer ack. Kevin has requested a
(mechanical) change just over the weekend.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Broken PCI device passthrough, after XSA-302 fix?

[Pasi Kärkkäinen]

On Mon, Jan 20, 2020 at 09:36:27AM +0100, Jan Beulich wrote:
> On 19.01.2020 11:39, Pasi Kärkkäinen wrote:
> > On Mon, Jan 06, 2020 at 02:06:14PM +0100, Jan Beulich wrote:
> >> On 04.01.2020 02:07, Marek Marczykowski-Górecki  wrote:
> >>> I have a multi-function PCI device, behind a PCI bridge, that normally
> >>> I assign to a single domain. But now it fails with:
> >>>
> >>> (XEN) [VT-D]d14: 0000:04:00.0 owned by d0!<G><0>assign 0000:05:00.0 to dom14 failed (-22)
> >>
> >> I've tried this out in as close a setup as I could arrange for, but
> >> not one matching your scenario. I didn't find a system with a
> >> suitably placed (in the topology) multi-function device (had to use
> >> a single-function one), and of course I did this on (close to)
> >> master. No anomalies. Hence I wonder whether either of the two
> >> differences mentioned matters, and - if, as I suspect, it's the
> >> multi-function aspect that is relevant here - how things would have
> >> worked at all before those recent changes. This is because I think
> >> you should have hit the same error path even before, and it would
> >> seem to me that the patch below might be (and have been) needed.
> >>
> > 
> > I think Marek confirmed in the other mail that this patch fixes the issue.
> > 
> > Are you planning to merge this patch?
> 
> Well, it is still pending a maintainer ack. Kevin has requested a
> (mechanical) change just over the weekend.
>

Ah, sorry, I missed the other thread. The patch in question seems to be:

"[PATCH 1/2] VT-d: don't pass bridge devices to domain_context_mapping_one()",
in thread: "[PATCH 0/2] VT-d: domain_context_mapping_one() adjustments".


Thanks.

-- Pasi

> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel