xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Cc: 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, nd@arm.com,
	"manish.jaggi@caviumnetworks.com"
	<manish.jaggi@caviumnetworks.com>,
	Shanker Donthineni <shankerd@codeaurora.org>
Subject: xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen
Date: Wed, 22 Feb 2017 14:10:12 +0000	[thread overview]
Message-ID: <c454c458-8bbb-ea24-b830-a2c700362cfc@arm.com> (raw)

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.

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.

Any opinions?

Cheers,

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf

-- 
Julien Grall

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

             reply	other threads:[~2017-02-22 14:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-22 14:10 Julien Grall [this message]
2017-02-27 13:23 ` xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen Vijay Kilari
2017-02-27 14:12   ` Julien Grall
2017-02-27 16:58     ` Shanker Donthineni
2017-02-27 18:12       ` Julien Grall
2017-05-18 11:59         ` Manish Jaggi
2017-05-18 14:57           ` Julien Grall
2017-05-18 20:02             ` Manish Jaggi
2017-05-18 20:09               ` Julien Grall
2017-06-08 12:38                 ` Manish Jaggi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c454c458-8bbb-ea24-b830-a2c700362cfc@arm.com \
    --to=julien.grall@arm.com \
    --cc=Steve.Capper@arm.com \
    --cc=Vijaya.Kumar@cavium.com \
    --cc=andre.przywara@arm.com \
    --cc=anjiandi@codeaurora.org \
    --cc=manish.jaggi@caviumnetworks.com \
    --cc=nd@arm.com \
    --cc=punit.agrawal@arm.com \
    --cc=sgoel@codeaurora.org \
    --cc=shankerd@codeaurora.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).