From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 26FCC208978 for ; Fri, 10 Jan 2025 22:21:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736547691; cv=none; b=sKT8D/4dwuocBheqms73EgFdlN4UVTQ2LT6A5HP+tiXhjfk9rMWx6/3unav6U/ag6IYRlkC5lORdJOBZIB7cRH57NMHL+/pG/vTTYeKOxzOXsyh7sMOvRyn02cZ27QAGmQKlqXiZSzYn5FfVuG+n831TAqFf6CLEELnrnGUGnz8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736547691; c=relaxed/simple; bh=qRzXS2cPJbaQPT6VO1nJCsDiE6wZHCk69MWbzsLdJlw=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=o5/rFTVP5WeQ4L/vuBiH632p9fzutvZ5bc6d9S6yjelVqD9WT0QwFmO+3noG0oz/H+28dK5pI69kFIFBhd0VDd0OBAInYnuBL9WD1K4xHq3sMqXW4bRplGD8pDNZ6WhepkDYOXQxp0sdcPOKGQ+IQ99DIBHCKSlEHhFSCbb3Z9c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pj+fUwX5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pj+fUwX5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D2ADC4CED6; Fri, 10 Jan 2025 22:21:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736547690; bh=qRzXS2cPJbaQPT6VO1nJCsDiE6wZHCk69MWbzsLdJlw=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=pj+fUwX5Yye14PC5hRy0JgM6ta4tEh6f9nuN2mMCGvoXLDnym0raxlIziHWvKQUMN 67SvwmJBIhIkCEd6yyoXvWUuOMzaCdu+TzVQNy6ClhnPpWtAvNPQR2SAy175sIXEnu CBwBPljbt5WTQgSZvQo3A/ATY7wjKy0B7Y0yQnepi9+7dfaw5D7fTyMjyGdch6Quxe iEj89ipnrrqx3zcXrMD3oVTVbqdCV/4leLX4T5DgkB+LMx6eGe/MQLAmrE8VOXkx8l tTHxwCGKhdL5hJqs25kG82FMvhlCrrPzAgfQYkQVvFAwep5M8tnm7HDShvZw62arGO GMonTgtfEnzNw== Date: Fri, 10 Jan 2025 16:21:29 -0600 From: Bjorn Helgaas To: Roger Pau Monne Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: [PATCH 1/3] xen/pci: do not register devices outside of PCI segment scope Message-ID: <20250110222129.GA317771@bhelgaas> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250110140152.27624-2-roger.pau@citrix.com> On Fri, Jan 10, 2025 at 03:01:48PM +0100, Roger Pau Monne wrote: > The PCI segment value is limited to 16 bits, however there are buses like VMD > that fake being part of the PCI topology by adding segment with a number > outside the scope of the PCI firmware specification range (>= 0x10000). The > MCFG ACPI Table "PCI Segment Group Number" field is defined as having a 16 bit > width. > > Attempting to register or manage those devices with Xen would result in errors > at best, or overlaps with existing devices living on the truncated equivalent > segment values. The ACPI _SEG method (ACPI r6.5, sec 6.5.6) and the corresponding value in the MCFG table (PCI Firmware r3.3, sec 4.1.2) are clearly 16-bit values. But otherwise, the segment value is pretty much an arbitrary software value, and the kernel works fine with the larger domain values from vmd_find_free_domain(), so this isn't quite enough to explain what the issue with Xen is. Does Xen truncate the domain to 16 bits or use it to look up something in ACPI? > Skip notifying Xen about those devices. > > Signed-off-by: Roger Pau Monné > --- > drivers/xen/pci.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c > index 416f231809cb..08e82fd1263e 100644 > --- a/drivers/xen/pci.c > +++ b/drivers/xen/pci.c > @@ -43,6 +43,13 @@ static int xen_add_device(struct device *dev) > pci_mcfg_reserved = true; > } > #endif > + > + if (pci_domain_nr(pci_dev->bus) >> 16) { > + dev_info(dev, > + "not registering with Xen: invalid PCI segment\n"); > + return 0; > + } > + > if (pci_seg_supported) { > DEFINE_RAW_FLEX(struct physdev_pci_device_add, add, optarr, 1); > > @@ -149,6 +156,12 @@ static int xen_remove_device(struct device *dev) > int r; > struct pci_dev *pci_dev = to_pci_dev(dev); > > + if (pci_domain_nr(pci_dev->bus) >> 16) { > + dev_info(dev, > + "not unregistering with Xen: invalid PCI segment\n"); > + return 0; > + } > + > if (pci_seg_supported) { > struct physdev_pci_device device = { > .seg = pci_domain_nr(pci_dev->bus), > @@ -182,6 +195,12 @@ int xen_reset_device(const struct pci_dev *dev) > .flags = PCI_DEVICE_RESET_FLR, > }; > > + if (pci_domain_nr(dev->bus) >> 16) { > + dev_info(&dev->dev, > + "unable to notify Xen of device reset: invalid PCI segment\n"); > + return 0; > + } > + > return HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_reset, &device); > } > EXPORT_SYMBOL_GPL(xen_reset_device); > -- > 2.46.0 >