[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 )


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.