From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80B2B1C07FA for ; Mon, 13 Jan 2025 10:19:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736763542; cv=none; b=flyE98+eveo2/2V8rZMlSTdd9IodLF5JrrRm8rhA5tvZmEDBNIl1lrVzURMFiwVZlnBrXl6lQYF06T/vlW1L+viNSYM6ZqfRB+lhXmLpIyzyPSaHpveKEqQJ1Um58LW6LVniKf0hGn6I/by9DtS+KK+k1xAbEbVMNBcwvw5ZWkU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736763542; c=relaxed/simple; bh=/uc7KULkbXtDvw7U3Z3smtdsodVDJeEn9qRT6ETYb18=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lEuFHF3aWFbv7XgclTXNiU/xGHgO5xo1Ua8rI6jK8yhC4ICw6MWa8Vd1YkHP5PmFsJgJlAR6KSeGua3DVDdUk0S1FRRX9ad4ULADZiYlwEaOySZQrXsBP0q6LsglVxWOELVhrLfKBBGrObnAyhZGxgZkypfhuvfM8i380xBD9R0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=citrix.com; spf=pass smtp.mailfrom=cloud.com; dkim=pass (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b=IM/Qw2vG; arc=none smtp.client-ip=209.85.218.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=citrix.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloud.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="IM/Qw2vG" Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-aae81f4fdc4so802129966b.0 for ; Mon, 13 Jan 2025 02:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1736763539; x=1737368339; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=VrEW9RapkLUvbhwp5lZsmgCTaBubEpv7gR1Du+cFUKw=; b=IM/Qw2vGLDb38snxc1G1TQ+N6/KDuZzszncAYixMLOdZxBXlVEeFQcuI/XVNVRLoeL JqTuw5Hkt9zXicg8qgnXVyLv0H/+UG7fc11WjvwlCPOVD0WOToVQAH7fBxq5oLwLvMdc VhGzsyOsQFXWdAf5Xrhl+xAuBOOK0Pxk9yhig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736763539; x=1737368339; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VrEW9RapkLUvbhwp5lZsmgCTaBubEpv7gR1Du+cFUKw=; b=MjpcVo+8aH6DwjuKPhN4f3BKHnussKycLJSdahnThdvHSWv+wDg8GcpgGi0cwY0hpK jG/qnK+Qtnwns2Ucc+AJgpsn7/gBwB/zLSTm3lM4Nu74Vyarl0Owgc1Kkquv1d20F6ac ujZ7bhCKuxBBp1/l1w9pPqfNVWlNFchOD3nPVq9I1tF17quXBZJWcU+OGLeCPPPxXJNn H/WaChZdtirzB8mQMFFmvF5OLEGf1ntTeBlFB52driROFfSk4XA/2x+rGGHZoUfo776d ipsD+xRhfWPtdAY3ixgMSi82fcL4xKNOflmafg0bQ+AL5shx1hGLPESQL5iG87PtuzDX SvmQ== X-Gm-Message-State: AOJu0YwI5tJ6F8P7AzSK1LxzNgF9g7tNQ7Wp7eVRkkWNFHQNwCP/QRPT 7/Um7F3q1AvAPZWi4xTlXc0tTZityTTmk4ctZqV1Py5sDoJh4EeJ7vSd77pImDU= X-Gm-Gg: ASbGnctdwy3z4k01rUDTEQCxavbC6j/597F4FWl2yqFUaijrJCP9iKadaa5r7Q7yrEI W8HJ6hhJOGTrX5iS7iHuZZ0SvgxRB3iSi62coUzmOIt1Jmtb6S608iAgrn9CQSYLebayIopq8So lfYPYdKHi2D0C2jdEZ9UHgO3LownkwhfSSwknsxq1HxHYs6msBL4wb4s1hsNGQz4khzVvAGTUui 9ukTpIkvDg8bzlSnCjCxMYaBw/Q23dZHIdcrRQzFGFs9TE37pxTbBj0v69jfw== X-Google-Smtp-Source: AGHT+IFj27FBVfZTJ7AzO9lrawoAO53MNm4jmh4KeKFNibSqpwXUBrNBlB8upGMQuZot38gb5qnfxw== X-Received: by 2002:a17:907:2d94:b0:aa6:66eb:9c06 with SMTP id a640c23a62f3a-ab2ab6a8e01mr1928797466b.5.1736763538798; Mon, 13 Jan 2025 02:18:58 -0800 (PST) Received: from localhost ([84.78.159.3]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab2c95b1207sm480261466b.153.2025.01.13.02.18.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2025 02:18:58 -0800 (PST) Date: Mon, 13 Jan 2025 11:18:57 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Bjorn Helgaas 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: References: <20250110140152.27624-2-roger.pau@citrix.com> <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 In-Reply-To: <20250110222129.GA317771@bhelgaas> On Fri, Jan 10, 2025 at 04:21:29PM -0600, Bjorn Helgaas wrote: > 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? In the interface between Xen and Linux the segment field is 16 bit width, so with the current interface is not possible to reference devices that are past the 0xffff segment. I also wonder whether Xen and Linux (or guest OSes in general) would agree on how to reference such devices. AFAICT VMD segment numbers are purely a software construct, but not something enforced by the specification. Could for example FreeBSD assign a different segment to VMD devices? If so we would need some kind of specification about how VMD segment values are assigned so that OSes have a coherent way of referencing VMD devices without ambiguity. Thanks, Roger.