"Michael S. Tsirkin" <m...@redhat.com> writes: > (((sid) >> 8) && 0xff) makes no sense > (((sid) >> 8) & 0xff) seems to be what was meant. > > Suggested-by: Markus Armbruster <arm...@redhat.com>
Actually by the reporter of https://bugs.launchpad.net/bugs/1382477 > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > --- > > Compile-tested only. > > include/hw/i386/intel_iommu.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h > index f4701e1..e321ee4 100644 > --- a/include/hw/i386/intel_iommu.h > +++ b/include/hw/i386/intel_iommu.h > @@ -37,7 +37,7 @@ > #define VTD_PCI_DEVFN_MAX 256 > #define VTD_PCI_SLOT(devfn) (((devfn) >> 3) & 0x1f) > #define VTD_PCI_FUNC(devfn) ((devfn) & 0x07) > -#define VTD_SID_TO_BUS(sid) (((sid) >> 8) && 0xff) > +#define VTD_SID_TO_BUS(sid) (((sid) >> 8) & 0xff) > #define VTD_SID_TO_DEVFN(sid) ((sid) & 0xff) > > #define DMAR_REG_SIZE 0x230 Can't find the spec right now, but it looks plausible enough. Only use is in vtd_context_device_invalidate(). Bug's impact isn't obvious to me. Reviewed-by: Markus Armbruster <arm...@redhat.com>
