Re: xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen

From: Julien Grall <julien.grall@arm.com>
To: Vijay Kilari <vijay.kilari@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Steve Capper <Steve.Capper@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Jiandi An <anjiandi@codeaurora.org>,
	Punit Agrawal <punit.agrawal@arm.com>,
	Vijaya Kumar K <Vijaya.Kumar@cavium.com>,
	sgoel@codeaurora.org, xen-devel <xen-devel@lists.xenproject.org>,
	nd@arm.com,
	"manish.jaggi@caviumnetworks.com"
	<manish.jaggi@caviumnetworks.com>,
	Shanker Donthineni <shankerd@codeaurora.org>
Subject: Re: xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen
Date: Mon, 27 Feb 2017 14:12:39 +0000	[thread overview]
Message-ID: <d18f4748-d11b-7d3e-0dad-8e94054e34f1@arm.com> (raw)
In-Reply-To: <CALicx6tS7-WyKvOAVd8LTQWh0ozuwnTr9QkmqBztmqqpHY=5Dg@mail.gmail.com>

On 27/02/17 13:23, Vijay Kilari wrote:
> Hi Julien,

Hello Vijay,

> On Wed, Feb 22, 2017 at 7:40 PM, Julien Grall <julien.grall@arm.com> wrote:
>> Hello,
>>
>> There was few discussions recently about hiding SMMUs from DOM0 when using
>> ACPI. I thought it would be good to have a separate thread for this.
>>
>> When using ACPI, the SMMUs will be described in the IO Remapping Table
>> (IORT). The specification can be found on the ARM website [1].
>>
>> For a brief summary, the IORT can be used to discover the SMMUs present on
>> the platform and find for a given device the ID to configure components such
>> as ITS (DeviceID) and SMMU (StreamID).
>>
>> The appendix A in the specification gives an example how DeviceID and
>> StreamID can be found. For instance, when a PCI device is both protected by
>> an SMMU and MSI-capable the following translation will happen:
>>         RID -> StreamID -> DeviceID
>>
>> Currently, SMMUs are hidden from DOM0 because they are been used by Xen and
>> we don't support stage-1 SMMU. If we pass the IORT as it is, DOM0 will try
>> to initialize SMMU and crash.
>>
>> I first thought about using a Xen specific way (STAO) or extending a flag in
>> IORT. But that is not ideal.
>>
>> So we would have to rewrite the IORT for DOM0. Given that a range of RID can
>> mapped to multiple ranges of DeviceID, we would have to translate RID one by
>> one to find the associated DeviceID. I think this may end up to complex code
>> and have a big IORT table.
>
> Why can't we replace Output base of IORT of PCI node with SMMU output base?.
> I mean similar to PCI node without SMMU, why can't replace output base
> of PCI node with
> SMMU's output base?.

Because I don't see anything in the spec preventing one RC ID mapping to 
produce multiple SMMU ID mapping. So which output base would you use?

>
> The issue I see is RID is [15:0] where is DeviceID is [17:0].
>
>>
>> However, given that DeviceID will be used by DOM0 to only configure the ITS.
>> We have no need to use to have the DOM0 DeviceID equal to the host DeviceID.
>> So I think we could simplify our life by generating DeviceID for each RID
>> range.
>
> If DOM0 DeviceID != host Device ID, then we cannot initialize ITS using DOM0
> ITS commands (MAPD). So, is it concluded that ITS initializes all the devices
> with platform specific Device ID's in Xen?.

Initializing ITS using DOM0 ITS command is a workaround until we get PCI 
passthrough done. It would still be possible to implement that with 
vDeviceID != pDeviceID as Xen would likely have the mapping between the 
2 DeviceID.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel