From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [early RFC] ARM PCI Passthrough design document Date: Fri, 6 Jan 2017 13:16:58 -0800 (PST) Message-ID: References: <5cf9128e-e845-2a89-f7c7-ac8616941ab9@linaro.org> <20170106151200.r6r424aabhlly2df@dhcp-3-221.uk.xensource.com> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-114804375-1483737419=:2866" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPbso-0001up-QU for xen-devel@lists.xenproject.org; Fri, 06 Jan 2017 21:17:06 +0000 In-Reply-To: <20170106151200.r6r424aabhlly2df@dhcp-3-221.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "Edgar Iglesias (edgar.iglesias@xilinx.com)" , Stefano Stabellini , Wei Chen , Punit Agrawal , Steve Capper , Jiandi An , Julien Grall , alistair.francis@xilinx.com, Shanker Donthineni , xen-devel , "manish.jaggi@caviumnetworks.com" , Campbell Sean List-Id: xen-devel@lists.xenproject.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-114804375-1483737419=:2866 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Fri, 6 Jan 2017, Roger Pau Monné wrote: > > bridge. See [6] for more details. > > > > XXX: I think this could be solved by using the host memory layout when > > creating a guest with PCI devices => Detail it. > > I'm not really sure I follow here, but if this write to the MSI doorbell > doesn't go through the SMMU, and instead is handled by the bridge, isn't there > a chance that a gust might be able to write anywhere in physical memory? > > Or this only happens when a guest writes to a MSI doorbell that's trapped by > the bridge and not forwarded anywhere else? It only happens when a device (not a cpu) writes to the MSI doorbell. > > So Xen needs to rely on DOM0 to discover the host bridges and notify Xen > > with all the relevant informations. This will be done via a new hypercall > > PHYSDEVOP_pci_host_bridge_add. The layout of the structure will be: > > > > struct physdev_pci_host_bridge_add > > { > > /* IN */ > > uint16_t seg; > > /* Range of bus supported by the host bridge */ > > uint8_t bus_start; > > uint8_t bus_nr; > > uint32_t res0; /* Padding */ > > /* Information about the configuration space region */ > > uint64_t cfg_base; > > uint64_t cfg_size; > > } > > Why do you need to cfg_size attribute? Isn't it always going to be 4096 bytes > in size? > > If that field is removed you could use the PHYSDEVOP_pci_mmcfg_reserved > hypercalls. > > > DOM0 will issue the hypercall PHYSDEVOP_pci_host_bridge_add for each host > > bridge available on the platform. When Xen is receiving the hypercall, the > > the driver associated to the host bridge will be instantiated. > > > > XXX: Shall we limit DOM0 the access to the configuration space from that > > moment? > > Most definitely yes, you should instantiate an emulated bridge over the real > one, in order to proxy Dom0 accesses to the PCI configuration space. You for > example don't want Dom0 moving the position of the BARs of PCI devices without > Xen being aware (and properly changing the second stage translation). > > > ## Discovering and register PCI > > > > Similarly to x86, PCI devices will be discovered by DOM0 and register > > using the hypercalls PHYSDEVOP_pci_add_device or PHYSDEVOP_manage_pci_add_ext. > > Why do you need this? If you have access to the bridges you can scan them from > Xen and discover the devices AFAICT. I think the same > > By default all the PCI devices will be assigned to DOM0. So Xen would have > > to configure the SMMU and Interrupt Controller to allow DOM0 to use the PCI > > devices. As mentioned earlier, those subsystems will require the StreamID > > and DeviceID. Both can be deduced from the RID. > > > > XXX: How to hide PCI devices from DOM0? > > By adding the ACPI namespace of the device to the STAO and blocking Dom0 > access to this device in the emulated bridge that Dom0 will have access to > (returning 0xFFFF when Dom0 tries to read the vendor ID from the PCI header). Good suggestion --8323329-114804375-1483737419=:2866 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --8323329-114804375-1483737419=:2866--