From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) (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 9C48D2114 for ; Sat, 11 Jan 2025 05:02:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736571745; cv=none; b=p2bBUbjY5lPmiaGgLgBZOJtiQoUWLmAyQWHcr9fEu2ol9NXSU22S/SaP+5OOlYiSGxP1Dvm7u/rW2WJSaByxbsCjDDRKO0J96+ueP9fZe1S+KvgmCXQEsa8tzUNf0fmFqP8he5VvbZAONKlAwNzMbkPB6l7SuJN4gWQh9rY60XY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736571745; c=relaxed/simple; bh=lXQ+4fameH3M8MHVRJJmDZ81eufW0DFRjZ9ZkSbUcN4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s7jQ4k7cTPcEAROgzQOn4HcFfgu+dl4FXtpdQXTj+C3BsiCb39lGVXwCIPC/mXqXNkXZENKsuEayNEDnn+CjUJpYVjfHPNzjOGL0c/ojH3WfHqyZEKPicE5wCUlKSkEQ4bUB0cGPG3yYG1p+y26jy85BiO8hDbDYTvhQ6YuKIMc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=C0zezy5P; arc=none smtp.client-ip=91.218.175.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="C0zezy5P" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1736571726; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=87PFbocV5iG/YEPJ261ZyupRxofHWTgUBw6ylFg04/A=; b=C0zezy5PH3NjJJ3rja00SNNPSHRoK8WteCqC6PRIpIiAhISp3YUvWQ6F/rB5uExooUh/5q P2EgIwDrZfl5AnTomUIUOUbdH0GAEdogAHNXGVJotDgyAgAaSj8KKZ/4nFsHh5KpBP06Dd B4MOur/ybskGrVPM4vzws7U/dGEGsbw= Date: Fri, 10 Jan 2025 22:02:00 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 2/3] vmd: disable MSI remapping bypass under Xen To: Bjorn Helgaas , Roger Pau Monne Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org, Nirmal Patel , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Rob Herring , Bjorn Helgaas References: <20250110222525.GA318386@bhelgaas> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Jonathan Derrick In-Reply-To: <20250110222525.GA318386@bhelgaas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Hi Bjorn, On 1/10/25 3:25 PM, Bjorn Helgaas wrote: > Match historical subject line style for prefix and capitalization: > > PCI: vmd: Set devices to D0 before enabling PM L1 Substates > PCI: vmd: Add DID 8086:B06F and 8086:B60B for Intel client SKUs > PCI: vmd: Fix indentation issue in vmd_shutdown() > > On Fri, Jan 10, 2025 at 03:01:49PM +0100, Roger Pau Monne wrote: >> MSI remapping bypass (directly configuring MSI entries for devices on the VMD >> bus) won't work under Xen, as Xen is not aware of devices in such bus, and >> hence cannot configure the entries using the pIRQ interface in the PV case, and >> in the PVH case traps won't be setup for MSI entries for such devices. >> >> Until Xen is aware of devices in the VMD bus prevent the >> VMD_FEAT_CAN_BYPASS_MSI_REMAP capability from being used when running as any >> kind of Xen guest. > > Wrap to fit in 75 columns. > > Can you include a hint about *why* Xen is not aware of devices below > VMD? That will help to know whether it's a permanent unfixable > situation or something that could be done eventually. > I wasn't aware of the Xen issue with VMD but if I had to guess it's probably due to the special handling of the downstream device into the dmar table. [1] 4fda230ecddc2 [2] 9b4a824b889e1 >> Signed-off-by: Roger Pau Monné >> --- >> drivers/pci/controller/vmd.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c >> index 264a180403a0..d9b7510ace29 100644 >> --- a/drivers/pci/controller/vmd.c >> +++ b/drivers/pci/controller/vmd.c >> @@ -965,6 +965,15 @@ static int vmd_probe(struct pci_dev *dev, const struct pci_device_id *id) >> struct vmd_dev *vmd; >> int err; >> >> + if (xen_domain()) >> + /* >> + * Xen doesn't have knowledge about devices in the VMD bus. > > Also here. > >> + * Bypass of MSI remapping won't work in that case as direct >> + * write to the MSI entries won't result in functional >> + * interrupts. >> + */ >> + features &= ~VMD_FEAT_CAN_BYPASS_MSI_REMAP; >> + >> if (resource_size(&dev->resource[VMD_CFGBAR]) < (1 << 20)) >> return -ENOMEM; >> >> -- >> 2.46.0 >>