From: Julien Grall <jgrall@amazon.com>
When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will throw
the following splat:
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in quirks.c:449:63
(XEN) left shift of 1 by 31 places cannot be represented in type 'int'
(XEN) ----[ Xen-4.11.4 x86_64 debug=y Not tainted ]----
[...]
(XEN) Xen call trace:
(XEN) [<ffff82d0802c0ccc>] ubsan.c#ubsan_epilogue+0xa/0xad
(XEN) [<ffff82d0802c16c9>] __ubsan_handle_shift_out_of_bounds+0xb4/0x145
(XEN) [<ffff82d0802eeecd>] pci_vtd_quirk+0x3d3/0x74f
(XEN) [<ffff82d0802e508b>] iommu.c#domain_context_mapping+0x45b/0x46f
(XEN) [<ffff82d08053f39e>] iommu.c#setup_hwdom_device+0x22/0x3a
(XEN) [<ffff82d08053dfbc>] pci.c#setup_one_hwdom_device+0x8c/0x124
(XEN) [<ffff82d08053e302>] pci.c#_setup_hwdom_pci_devices+0xbb/0x2f7
(XEN) [<ffff82d0802da5b7>] pci.c#pci_segments_iterate+0x4c/0x8c
(XEN) [<ffff82d08053e8bd>] setup_hwdom_pci_devices+0x25/0x2c
(XEN) [<ffff82d08053e916>] iommu.c#intel_iommu_hwdom_init+0x52/0x2f3
(XEN) [<ffff82d08053d6da>] iommu_hwdom_init+0x4e/0xa4
(XEN) [<ffff82d080577f32>] dom0_construct_pv+0x23c8/0x2476
(XEN) [<ffff82d08057cb50>] construct_dom0+0x6c/0xa3
(XEN) [<ffff82d080564822>] __start_xen+0x4651/0x4b55
(XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
Note that splat is from 4.11.4 and not staging. Although, the problem is
still present.
This can be solved by making the first operand unsigned int.
Signed-off-by: Julien Grall <jgrall@amazon.com>
CR: https://code.amazon.com/reviews/CR-38873112
---
xen/drivers/passthrough/vtd/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/vtd/quirks.c b/xen/drivers/passthrough/vtd/quirks.c
index a8330f17bc0c..8a81d9c9308b 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -435,7 +435,7 @@ void pci_vtd_quirk(const struct pci_dev *pdev)
case 0x3728: /* Xeon C5500/C3500 (JasperForest) */
case 0x3c28: /* Sandybridge */
val = pci_conf_read32(pdev->sbdf, 0x1AC);
- pci_conf_write32(pdev->sbdf, 0x1AC, val | (1 << 31));
+ pci_conf_write32(pdev->sbdf, 0x1AC, val | (1U << 31));
printk(XENLOG_INFO "Masked VT-d error signaling on %pp\n", &pdev->sbdf);
break;
--
2.17.1
On 19.11.2020 15:52, Julien Grall wrote: > From: Julien Grall <jgrall@amazon.com> > > When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will throw > the following splat: > > (XEN) ================================================================================ > (XEN) UBSAN: Undefined behaviour in quirks.c:449:63 > (XEN) left shift of 1 by 31 places cannot be represented in type 'int' > (XEN) ----[ Xen-4.11.4 x86_64 debug=y Not tainted ]---- > > [...] > > (XEN) Xen call trace: > (XEN) [<ffff82d0802c0ccc>] ubsan.c#ubsan_epilogue+0xa/0xad > (XEN) [<ffff82d0802c16c9>] __ubsan_handle_shift_out_of_bounds+0xb4/0x145 > (XEN) [<ffff82d0802eeecd>] pci_vtd_quirk+0x3d3/0x74f > (XEN) [<ffff82d0802e508b>] iommu.c#domain_context_mapping+0x45b/0x46f > (XEN) [<ffff82d08053f39e>] iommu.c#setup_hwdom_device+0x22/0x3a > (XEN) [<ffff82d08053dfbc>] pci.c#setup_one_hwdom_device+0x8c/0x124 > (XEN) [<ffff82d08053e302>] pci.c#_setup_hwdom_pci_devices+0xbb/0x2f7 > (XEN) [<ffff82d0802da5b7>] pci.c#pci_segments_iterate+0x4c/0x8c > (XEN) [<ffff82d08053e8bd>] setup_hwdom_pci_devices+0x25/0x2c > (XEN) [<ffff82d08053e916>] iommu.c#intel_iommu_hwdom_init+0x52/0x2f3 > (XEN) [<ffff82d08053d6da>] iommu_hwdom_init+0x4e/0xa4 > (XEN) [<ffff82d080577f32>] dom0_construct_pv+0x23c8/0x2476 > (XEN) [<ffff82d08057cb50>] construct_dom0+0x6c/0xa3 > (XEN) [<ffff82d080564822>] __start_xen+0x4651/0x4b55 > (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55 > > Note that splat is from 4.11.4 and not staging. Although, the problem is > still present. > > This can be solved by making the first operand unsigned int. > > Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> > --- a/xen/drivers/passthrough/vtd/quirks.c > +++ b/xen/drivers/passthrough/vtd/quirks.c > @@ -435,7 +435,7 @@ void pci_vtd_quirk(const struct pci_dev *pdev) > case 0x3728: /* Xeon C5500/C3500 (JasperForest) */ > case 0x3c28: /* Sandybridge */ > val = pci_conf_read32(pdev->sbdf, 0x1AC); > - pci_conf_write32(pdev->sbdf, 0x1AC, val | (1 << 31)); > + pci_conf_write32(pdev->sbdf, 0x1AC, val | (1U << 31)); I can see a couple of similar uses in arm/ipmmu-vmsa.c and arm/smmu.c. These are all #define-s though, so would be an issue only if these #define-s actually get used anywhere. Jan
Hi Jan, On 19/11/2020 15:02, Jan Beulich wrote: > On 19.11.2020 15:52, Julien Grall wrote: >> From: Julien Grall <jgrall@amazon.com> >> >> When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will throw >> the following splat: >> >> (XEN) ================================================================================ >> (XEN) UBSAN: Undefined behaviour in quirks.c:449:63 >> (XEN) left shift of 1 by 31 places cannot be represented in type 'int' >> (XEN) ----[ Xen-4.11.4 x86_64 debug=y Not tainted ]---- >> >> [...] >> >> (XEN) Xen call trace: >> (XEN) [<ffff82d0802c0ccc>] ubsan.c#ubsan_epilogue+0xa/0xad >> (XEN) [<ffff82d0802c16c9>] __ubsan_handle_shift_out_of_bounds+0xb4/0x145 >> (XEN) [<ffff82d0802eeecd>] pci_vtd_quirk+0x3d3/0x74f >> (XEN) [<ffff82d0802e508b>] iommu.c#domain_context_mapping+0x45b/0x46f >> (XEN) [<ffff82d08053f39e>] iommu.c#setup_hwdom_device+0x22/0x3a >> (XEN) [<ffff82d08053dfbc>] pci.c#setup_one_hwdom_device+0x8c/0x124 >> (XEN) [<ffff82d08053e302>] pci.c#_setup_hwdom_pci_devices+0xbb/0x2f7 >> (XEN) [<ffff82d0802da5b7>] pci.c#pci_segments_iterate+0x4c/0x8c >> (XEN) [<ffff82d08053e8bd>] setup_hwdom_pci_devices+0x25/0x2c >> (XEN) [<ffff82d08053e916>] iommu.c#intel_iommu_hwdom_init+0x52/0x2f3 >> (XEN) [<ffff82d08053d6da>] iommu_hwdom_init+0x4e/0xa4 >> (XEN) [<ffff82d080577f32>] dom0_construct_pv+0x23c8/0x2476 >> (XEN) [<ffff82d08057cb50>] construct_dom0+0x6c/0xa3 >> (XEN) [<ffff82d080564822>] __start_xen+0x4651/0x4b55 >> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55 >> >> Note that splat is from 4.11.4 and not staging. Although, the problem is >> still present. >> >> This can be solved by making the first operand unsigned int. >> >> Signed-off-by: Julien Grall <jgrall@amazon.com> > > Reviewed-by: Jan Beulich <jbeulich@suse.com> > >> --- a/xen/drivers/passthrough/vtd/quirks.c >> +++ b/xen/drivers/passthrough/vtd/quirks.c >> @@ -435,7 +435,7 @@ void pci_vtd_quirk(const struct pci_dev *pdev) >> case 0x3728: /* Xeon C5500/C3500 (JasperForest) */ >> case 0x3c28: /* Sandybridge */ >> val = pci_conf_read32(pdev->sbdf, 0x1AC); >> - pci_conf_write32(pdev->sbdf, 0x1AC, val | (1 << 31)); >> + pci_conf_write32(pdev->sbdf, 0x1AC, val | (1U << 31)); > > I can see a couple of similar uses in arm/ipmmu-vmsa.c and > arm/smmu.c. These are all #define-s though, so would be an issue > only if these #define-s actually get used anywhere. There are a few on Arm. I have a couple of patches to fix them. Although, I don't think I discovered them one in arm/ipmmu-vmsa.c and arm/smmu.c yet. I will have a look. Cheers, -- Julien Grall
On 19/11/2020 14:52, Julien Grall wrote: > Note that splat is from 4.11.4 and not staging. Although, the problem is > still present. > > This can be solved by making the first operand unsigned int. > > Signed-off-by: Julien Grall <jgrall@amazon.com> > > CR: https://code.amazon.com/reviews/CR-38873112 IIRC, this is an internal link, which doesn't want including on the upstream commit? ~Andrew
On 19/11/2020 16:38, Andrew Cooper wrote: > On 19/11/2020 14:52, Julien Grall wrote: >> Note that splat is from 4.11.4 and not staging. Although, the problem is >> still present. >> >> This can be solved by making the first operand unsigned int. >> >> Signed-off-by: Julien Grall <jgrall@amazon.com> >> >> CR: https://code.amazon.com/reviews/CR-38873112 > > IIRC, this is an internal link, which doesn't want including on the > upstream commit? Yes. I forgot to sanitize commit message when sending it. I will remove it while committing unless there is a need to send a new version. Cheers, -- Julien Grall
On 19/11/2020 16:40, Julien Grall wrote: > > > On 19/11/2020 16:38, Andrew Cooper wrote: >> On 19/11/2020 14:52, Julien Grall wrote: >>> Note that splat is from 4.11.4 and not staging. Although, the >>> problem is >>> still present. >>> >>> This can be solved by making the first operand unsigned int. >>> >>> Signed-off-by: Julien Grall <jgrall@amazon.com> >>> >>> CR: https://code.amazon.com/reviews/CR-38873112 >> >> IIRC, this is an internal link, which doesn't want including on the >> upstream commit? > > Yes. I forgot to sanitize commit message when sending it. > > I will remove it while committing unless there is a need to send a new > version. No problem. FWIW, Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> ~Andrew
Hi, On 19/11/2020 14:52, Julien Grall wrote: > From: Julien Grall <jgrall@amazon.com> > > When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will throw > the following splat: > > (XEN) ================================================================================ > (XEN) UBSAN: Undefined behaviour in quirks.c:449:63 > (XEN) left shift of 1 by 31 places cannot be represented in type 'int' > (XEN) ----[ Xen-4.11.4 x86_64 debug=y Not tainted ]---- > > [...] > > (XEN) Xen call trace: > (XEN) [<ffff82d0802c0ccc>] ubsan.c#ubsan_epilogue+0xa/0xad > (XEN) [<ffff82d0802c16c9>] __ubsan_handle_shift_out_of_bounds+0xb4/0x145 > (XEN) [<ffff82d0802eeecd>] pci_vtd_quirk+0x3d3/0x74f > (XEN) [<ffff82d0802e508b>] iommu.c#domain_context_mapping+0x45b/0x46f > (XEN) [<ffff82d08053f39e>] iommu.c#setup_hwdom_device+0x22/0x3a > (XEN) [<ffff82d08053dfbc>] pci.c#setup_one_hwdom_device+0x8c/0x124 > (XEN) [<ffff82d08053e302>] pci.c#_setup_hwdom_pci_devices+0xbb/0x2f7 > (XEN) [<ffff82d0802da5b7>] pci.c#pci_segments_iterate+0x4c/0x8c > (XEN) [<ffff82d08053e8bd>] setup_hwdom_pci_devices+0x25/0x2c > (XEN) [<ffff82d08053e916>] iommu.c#intel_iommu_hwdom_init+0x52/0x2f3 > (XEN) [<ffff82d08053d6da>] iommu_hwdom_init+0x4e/0xa4 > (XEN) [<ffff82d080577f32>] dom0_construct_pv+0x23c8/0x2476 > (XEN) [<ffff82d08057cb50>] construct_dom0+0x6c/0xa3 > (XEN) [<ffff82d080564822>] __start_xen+0x4651/0x4b55 > (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55 > > Note that splat is from 4.11.4 and not staging. Although, the problem is > still present. > > This can be solved by making the first operand unsigned int. > > Signed-off-by: Julien Grall <jgrall@amazon.com> Kevin, can I get an ack on this small patch? Cheers. -- Julien Grall
> From: Julien Grall <julien@xen.org> > Sent: Thursday, November 19, 2020 10:52 PM > > From: Julien Grall <jgrall@amazon.com> > > When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will > throw > the following splat: > > (XEN) > ================================================================ > ================ > (XEN) UBSAN: Undefined behaviour in quirks.c:449:63 > (XEN) left shift of 1 by 31 places cannot be represented in type 'int' > (XEN) ----[ Xen-4.11.4 x86_64 debug=y Not tainted ]---- > > [...] > > (XEN) Xen call trace: > (XEN) [<ffff82d0802c0ccc>] ubsan.c#ubsan_epilogue+0xa/0xad > (XEN) [<ffff82d0802c16c9>] > __ubsan_handle_shift_out_of_bounds+0xb4/0x145 > (XEN) [<ffff82d0802eeecd>] pci_vtd_quirk+0x3d3/0x74f > (XEN) [<ffff82d0802e508b>] > iommu.c#domain_context_mapping+0x45b/0x46f > (XEN) [<ffff82d08053f39e>] iommu.c#setup_hwdom_device+0x22/0x3a > (XEN) [<ffff82d08053dfbc>] pci.c#setup_one_hwdom_device+0x8c/0x124 > (XEN) [<ffff82d08053e302>] pci.c#_setup_hwdom_pci_devices+0xbb/0x2f7 > (XEN) [<ffff82d0802da5b7>] pci.c#pci_segments_iterate+0x4c/0x8c > (XEN) [<ffff82d08053e8bd>] setup_hwdom_pci_devices+0x25/0x2c > (XEN) [<ffff82d08053e916>] > iommu.c#intel_iommu_hwdom_init+0x52/0x2f3 > (XEN) [<ffff82d08053d6da>] iommu_hwdom_init+0x4e/0xa4 > (XEN) [<ffff82d080577f32>] dom0_construct_pv+0x23c8/0x2476 > (XEN) [<ffff82d08057cb50>] construct_dom0+0x6c/0xa3 > (XEN) [<ffff82d080564822>] __start_xen+0x4651/0x4b55 > (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55 > > Note that splat is from 4.11.4 and not staging. Although, the problem is > still present. > > This can be solved by making the first operand unsigned int. > > Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> > > CR: https://code.amazon.com/reviews/CR-38873112 > --- > xen/drivers/passthrough/vtd/quirks.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/drivers/passthrough/vtd/quirks.c > b/xen/drivers/passthrough/vtd/quirks.c > index a8330f17bc0c..8a81d9c9308b 100644 > --- a/xen/drivers/passthrough/vtd/quirks.c > +++ b/xen/drivers/passthrough/vtd/quirks.c > @@ -435,7 +435,7 @@ void pci_vtd_quirk(const struct pci_dev *pdev) > case 0x3728: /* Xeon C5500/C3500 (JasperForest) */ > case 0x3c28: /* Sandybridge */ > val = pci_conf_read32(pdev->sbdf, 0x1AC); > - pci_conf_write32(pdev->sbdf, 0x1AC, val | (1 << 31)); > + pci_conf_write32(pdev->sbdf, 0x1AC, val | (1U << 31)); > printk(XENLOG_INFO "Masked VT-d error signaling on %pp\n", &pdev- > >sbdf); > break; > > -- > 2.17.1
Hi, On 30/11/2020 02:50, Tian, Kevin wrote: >> From: Julien Grall <julien@xen.org> >> Sent: Thursday, November 19, 2020 10:52 PM >> >> From: Julien Grall <jgrall@amazon.com> >> >> When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will >> throw >> the following splat: >> >> (XEN) >> ================================================================ >> ================ >> (XEN) UBSAN: Undefined behaviour in quirks.c:449:63 >> (XEN) left shift of 1 by 31 places cannot be represented in type 'int' >> (XEN) ----[ Xen-4.11.4 x86_64 debug=y Not tainted ]---- >> >> [...] >> >> (XEN) Xen call trace: >> (XEN) [<ffff82d0802c0ccc>] ubsan.c#ubsan_epilogue+0xa/0xad >> (XEN) [<ffff82d0802c16c9>] >> __ubsan_handle_shift_out_of_bounds+0xb4/0x145 >> (XEN) [<ffff82d0802eeecd>] pci_vtd_quirk+0x3d3/0x74f >> (XEN) [<ffff82d0802e508b>] >> iommu.c#domain_context_mapping+0x45b/0x46f >> (XEN) [<ffff82d08053f39e>] iommu.c#setup_hwdom_device+0x22/0x3a >> (XEN) [<ffff82d08053dfbc>] pci.c#setup_one_hwdom_device+0x8c/0x124 >> (XEN) [<ffff82d08053e302>] pci.c#_setup_hwdom_pci_devices+0xbb/0x2f7 >> (XEN) [<ffff82d0802da5b7>] pci.c#pci_segments_iterate+0x4c/0x8c >> (XEN) [<ffff82d08053e8bd>] setup_hwdom_pci_devices+0x25/0x2c >> (XEN) [<ffff82d08053e916>] >> iommu.c#intel_iommu_hwdom_init+0x52/0x2f3 >> (XEN) [<ffff82d08053d6da>] iommu_hwdom_init+0x4e/0xa4 >> (XEN) [<ffff82d080577f32>] dom0_construct_pv+0x23c8/0x2476 >> (XEN) [<ffff82d08057cb50>] construct_dom0+0x6c/0xa3 >> (XEN) [<ffff82d080564822>] __start_xen+0x4651/0x4b55 >> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55 >> >> Note that splat is from 4.11.4 and not staging. Although, the problem is >> still present. >> >> This can be solved by making the first operand unsigned int. >> >> Signed-off-by: Julien Grall <jgrall@amazon.com> > > Reviewed-by: Kevin Tian <kevin.tian@intel.com> Thanks! I have committed the patch. Cheers, -- Julien Grall
© 2016 - 2024 Red Hat, Inc.