[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PATCH v2 2/3] VT-d: PCI segments are up to 16 bits wide
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
- Date: Sat, 18 Sep 2021 00:49:49 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5dTTKHcpujEOYDG34UvjZmvHsr0DQdB8zXpj7ac5aQk=; b=C1uVo0kikXJ44Me+xQh3ajgSZyO69JKQWWnejLNdSdFb2/wHl7eitn37+8qtqC2LUvr7uXm7HGC2xUlGbYKr48BeEVvaZgCcMa/bx1HTDWjbOY3Cddykj2RX1DHRtIwPUPL6gju0PFM35I+hbXiq7MM4JS9nDYaV+D1zkdw8SolppRZPMFd85TkIgK9j3amEu3AfD+lWgAf/M3cSHQGrYxRH4McEYRl8YkW4j3Qul8NaHIphMcuI+VwGLC1/GVoFYzl6AjxPTnUIKBOHuKLtMe98aLycV4ROxI3E1oprhA4fia4phn2CW+N2M/ozPMH++cZteR1OCT1iefTJp1uGVQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NTPUwn85ORayBI/GP58oeb3h095DX9aTn+IvDZCNacSIZQEyht61qvLarL8B9xt1VeTPR3h9pmM5rh+uDGXE5G443bSJ6MuWLO6yOWKIAAW/eftF6vYkRTr2TaKXiX1JANt7RbzprySclQ92SDh0t4ee924JK2mdT1wcY4GdZsUsGce8T74LC/JUvyQAusMwo7HioKYcSI9kz/j7hkEHssO3JFe9xTB0UvapDIGiGHsXKNRXpjNgyWDYBAC50ujilukYCzk/fLifCzuV90o2kZeoFkiIyyLTOrcYckSWDVImv9DsWCgH9bQOLqm5eViNRNWxRM15Ytcvt+GTEpEgZQ==
- Authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=intel.com;
- Cc: Paul Durrant <paul@xxxxxxx>
- Delivery-date: Sat, 18 Sep 2021 00:49:59 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHXq7NLI4GDIompwEO0/aktEApWj6uo9l8Q
- Thread-topic: [PATCH v2 2/3] VT-d: PCI segments are up to 16 bits wide
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Friday, September 17, 2021 7:00 PM
>
> We shouldn't silently truncate respective values.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> ---
> Strictly speaking we shouldn't use uint<N>_t here at all. I wasn't sure
> though whether going straight to unsigned int wouldn't be viewed as
> introducing inconsistencies.
> ---
> v2: New.
>
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1462,7 +1462,8 @@ static int domain_context_mapping(struct
> {
> const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
> int ret = 0;
> - u8 seg = pdev->seg, bus = pdev->bus, secbus;
> + uint16_t seg = pdev->seg;
> + uint8_t bus = pdev->bus, secbus;
>
> /*
> * Generally we assume only devices from one node to get assigned to a
> @@ -1677,7 +1678,8 @@ static int domain_context_unmap(struct d
> const struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
> struct vtd_iommu *iommu = drhd ? drhd->iommu : NULL;
> int ret;
> - u8 seg = pdev->seg, bus = pdev->bus, tmp_bus, tmp_devfn, secbus;
> + uint16_t seg = pdev->seg;
> + uint8_t bus = pdev->bus, tmp_bus, tmp_devfn, secbus;
> bool found;
>
> switch ( pdev->type )
|
