[RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Manish Jaggi]

ACPI/IORT Support in Xen.
--------------------------
	Draft 2

Revision History:

Changes since v1-
- Modified IORT Parsing data structures.
- Added RID->StreamID and RID->DeviceID map as per Andre's suggestion.
- Added reference code which can be read along with this document.
- Removed domctl for DomU, it would be covered in PCI-PT design.

Introduction:
-------------

I had sent out patch series [0] to hide smmu from Dom0 IORT.
This document is a rework of the series as it:
(a) extends scope by adding parsing of IORT table once
and storing it in in-memory data structures, which can then be used
for querying. This would eliminate the need to parse complete iort
table multiple times.

(b) Generation of IORT for domains be independent using a set of
helper routines.

Index
--------

1. What is IORT. What are its components ?
2. Current Support in Xen
3. IORT for Dom0
4. IORT for DomU
5. Parsing of IORT in Xen
6. Generation of IORT
7. Implementation Phases
8. References

1. IORT Structure ?
--------------------------------------------
IORT refers to Input Output remapping table. It is essentially used to find
information about the IO topology (PCIRC-SMMU-ITS) and relationships between
devices.

A general structure of IORT [1]:
It has nodes for PCI RC, SMMU, ITS and Platform devices. Using an IORT table
relationship between RID -> StreamID -> DeviceId can be obtained.
Which device is behind which SMMU and which interrupt controller, topology
is described in IORT Table.

Some PCI RC may be not behind an SMMU, and directly map RID->DeviceID.

RID is a requester ID in PCI context,
StreamID is the ID of the device in SMMU context,
DeviceID is the ID programmed in ITS.

Each iort_node contains an ID map array to translate one ID into another.
IDmap Entry {input_range, output_range, output_node_ref, id_count}
This array is associated with PCI RC node, SMMU node, Named component node.
and can reference to a SMMU or ITS node.

2. Current Support of IORT
---------------------------
IORT is proposed to be used by Xen to setup SMMU's and platform devices
and for translating RID->StreamID and RID->DeviceID.

It is proposed in this document to parse iort once and use the information
to translate RID without traversing IORT again and again.

Also Xen prepares an IORT table for dom0 based on host IORT.
For DomU IORT table proposed only in case of device passthrough.

3. IORT for Dom0
-----------------
IORT for Dom0 is based on host iort. Few nodes could be removed or modified.
  For instance
- Host SMMU nodes should not be present as Xen should only touch it.
- platform nodes (named components) may be controlled by xen command line.

4. IORT for DomU
-----------------
IORT for DomU should be generated by toolstack. IORT table is only present
in case of device passthrough.

At a minimum domU IORT should include a single PCIRC and ITS Group.
Similar PCIRC can be added in DSDT.
The exact structure of DomU IORT would be covered along with PCI PT design.

5. Parsing of IORT in Xen
--------------------------
IORT nodes can be saved in structures so that IORT table parsing can be done
once and is reused by all xen subsystems like ITS / SMMU etc, domain creation.
Proposed are the structures to hold IORT information. [4]

struct rid_map_struct {
	void *pcirc_node;
	u16 ib; /* Input base */
	u32 ob; /* Output base */
	u16 idc; /* Id Count */
  	struct list_head entry;
};

struct iort_ref
{
	struct list_head rid_streamId_map;
	struct list_head rid_deviceId_map;
}iortref;

5.1 Functions to query StreamID and DeviceID from RID.

void query_streamId(void *pcirc_node, u16 rid, u32 *streamId);
void query_deviceId(void *pcirc_node, u16 rid, u32 *deviceId);

Adding a mapping is done via helper functions

intadd_rid_streamId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) 
intadd_rid_deviceId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) - rid-streamId map is straight forward and is created using pci_rc's idmap
- rid-deviceId map is created by translating streamIds to deviceIds.
	fixup_rid_deviceId_map function does that. (See [6])

It is proposed that query functions should replace functions like
iort_node_map_rid which is currently used in linux and is imported in Xen
in the patchset [2][5]

5.2 Proposed Flow of parsing
The flow is based on the patchset in [5]. I have added a reference code on
top of it which does IORT parsing as described in this section. The code
is available at [6].

The commit also describes the code flow and assumptions.

6. IORT Generation
-------------------
It is proposed to have a common helper library to generate IORT for dom0/U.
Note: it is desired to have IORT generation code sharing between toolstack
and Xen.

a. For Dom0
  rid_deviceId_map can be used directly to generate dom0 IORT table.
  Exclusions of nodes is still open for suggestions.

b. For DomU
  Minimal structure is discussed in section 4. It will be further discussed
  in the context of PCI PT design.
	
7. Implementation Phases
-------------------------
a. IORT Parsing and RID Query
b. IORT Generation for Dom0
c. IORT Generation for DomU.

8. References:
-------------
[0] https://www.mail-archive.com/xen-devel@lists.xen.org/msg121667.html
[1] ARM DEN0049C: http://infocenter.arm.com/help/topic/com.arm.doc.den0049c/DEN0049C_IO_Remapping_Table.pdf
[2] https://www.mail-archive.com/xen-devel@lists.xen.org/msg123082.html
[3] NA.
[4] https://www.mail-archive.com/xen-devel@lists.xen.org/msg123434.html
[5] https://www.mail-archive.com/xen-devel@lists.xen.org/msg123080.html
[6] https://github.com/mjaggi-cavium/xen-wip/commit/df006d64bdbb5c8344de5a710da8bf64c9e8edd5



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

Re: [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Julien Grall]

Hi Manish,

On 08/11/17 14:38, Manish Jaggi wrote:
> ACPI/IORT Support in Xen.
> --------------------------
>      Draft 2
> 
> Revision History:
> 
> Changes since v1-
> - Modified IORT Parsing data structures.
> - Added RID->StreamID and RID->DeviceID map as per Andre's suggestion.
> - Added reference code which can be read along with this document.
> - Removed domctl for DomU, it would be covered in PCI-PT design.
> 
> Introduction:
> -------------
> 
> I had sent out patch series [0] to hide smmu from Dom0 IORT.
> This document is a rework of the series as it:
> (a) extends scope by adding parsing of IORT table once
> and storing it in in-memory data structures, which can then be used
> for querying. This would eliminate the need to parse complete iort
> table multiple times.
> 
> (b) Generation of IORT for domains be independent using a set of
> helper routines.
> 
> Index
> --------
> 
> 1. What is IORT. What are its components ?
> 2. Current Support in Xen
> 3. IORT for Dom0
> 4. IORT for DomU
> 5. Parsing of IORT in Xen
> 6. Generation of IORT
> 7. Implementation Phases
> 8. References
> 
> 1. IORT Structure ?
> --------------------------------------------
> IORT refers to Input Output remapping table. It is essentially used to find
> information about the IO topology (PCIRC-SMMU-ITS) and relationships 
> between
> devices.
> 
> A general structure of IORT [1]:
> It has nodes for PCI RC, SMMU, ITS and Platform devices. Using an IORT 
> table
> relationship between RID -> StreamID -> DeviceId can be obtained.
> Which device is behind which SMMU and which interrupt controller, topology
> is described in IORT Table.
> 
> Some PCI RC may be not behind an SMMU, and directly map RID->DeviceID.
> 
> RID is a requester ID in PCI context,
> StreamID is the ID of the device in SMMU context,
> DeviceID is the ID programmed in ITS.
> 
> Each iort_node contains an ID map array to translate one ID into another.
> IDmap Entry {input_range, output_range, output_node_ref, id_count}
> This array is associated with PCI RC node, SMMU node, Named component node.
> and can reference to a SMMU or ITS node.
> 
> 2. Current Support of IORT
> ---------------------------
> IORT is proposed to be used by Xen to setup SMMU's and platform devices
> and for translating RID->StreamID and RID->DeviceID.

I am not sure to understand "to setup SMMU's and platform devices...". 
With IORT, a software can discover list of SMMUs and the IDs to 
configure the ITS and SMMUs for each device (e.g PCI, integrated...) on 
the platform. You will not be able to discover the list of platform 
devices through it.

Also, it is not really "proposed". It is the only way to get those 
information from ACPI.

> 
> It is proposed in this document to parse iort once and use the information
> to translate RID without traversing IORT again and again.
> 
> Also Xen prepares an IORT table for dom0 based on host IORT.
> For DomU IORT table proposed only in case of device passthrough.
> 
> 3. IORT for Dom0
> -----------------
> IORT for Dom0 is based on host iort. Few nodes could be removed or 
> modified.
>   For instance
> - Host SMMU nodes should not be present as Xen should only touch it.
> - platform nodes (named components) may be controlled by xen command line.

I am not sure where does this example come from? As I said, there are no 
plan to support Platform Device passthrough with ACPI. A better example 
here would removing PMCG.

> 
> 4. IORT for DomU
> -----------------
> IORT for DomU should be generated by toolstack. IORT table is only present
> in case of device passthrough.
> 
> At a minimum domU IORT should include a single PCIRC and ITS Group.
> Similar PCIRC can be added in DSDT.
> The exact structure of DomU IORT would be covered along with PCI PT design.
> 
> 5. Parsing of IORT in Xen
> --------------------------
> IORT nodes can be saved in structures so that IORT table parsing can be 
> done
> once and is reused by all xen subsystems like ITS / SMMU etc, domain 
> creation.
> Proposed are the structures to hold IORT information. [4]
> 
> struct rid_map_struct {
>      void *pcirc_node;
>      u16 ib; /* Input base */
>      u32 ob; /* Output base */
>      u16 idc; /* Id Count */
>       struct list_head entry;
> };
> 
> struct iort_ref
> {
>      struct list_head rid_streamId_map;
>      struct list_head rid_deviceId_map;
> }iortref;
> 
> 5.1 Functions to query StreamID and DeviceID from RID.
> 
> void query_streamId(void *pcirc_node, u16 rid, u32 *streamId);
> void query_deviceId(void *pcirc_node, u16 rid, u32 *deviceId);
> 
> Adding a mapping is done via helper functions
> 
> intadd_rid_streamId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) 
> intadd_rid_deviceId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) - 
> rid-streamId map is straight forward and is created using pci_rc's idmap
> - rid-deviceId map is created by translating streamIds to deviceIds.
>      fixup_rid_deviceId_map function does that. (See [6])
> 
> It is proposed that query functions should replace functions like
> iort_node_map_rid which is currently used in linux and is imported in Xen
> in the patchset [2][5]
> 
> 5.2 Proposed Flow of parsing
> The flow is based on the patchset in [5]. I have added a reference code on
> top of it which does IORT parsing as described in this section. The code
> is available at [6].
> 
> The commit also describes the code flow and assumptions.

Which assumptions? I can't see any in the commit message.

Cheers,

-- 
Julien Grall

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

Re: [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Manish Jaggi]

On 11/14/2017 6:53 PM, Julien Grall wrote:
> Hi Manish,
Hey Julien,

> On 08/11/17 14:38, Manish Jaggi wrote:
>> ACPI/IORT Support in Xen.
>> --------------------------
>>      Draft 2
>>
>> Revision History:
>>
>> Changes since v1-
>> - Modified IORT Parsing data structures.
>> - Added RID->StreamID and RID->DeviceID map as per Andre's suggestion.
>> - Added reference code which can be read along with this document.
>> - Removed domctl for DomU, it would be covered in PCI-PT design.
>>
>> Introduction:
>> -------------
>>
>> I had sent out patch series [0] to hide smmu from Dom0 IORT.
>> This document is a rework of the series as it:
>> (a) extends scope by adding parsing of IORT table once
>> and storing it in in-memory data structures, which can then be used
>> for querying. This would eliminate the need to parse complete iort
>> table multiple times.
>>
>> (b) Generation of IORT for domains be independent using a set of
>> helper routines.
>>
>> Index
>> --------
>>
>> 1. What is IORT. What are its components ?
>> 2. Current Support in Xen
>> 3. IORT for Dom0
>> 4. IORT for DomU
>> 5. Parsing of IORT in Xen
>> 6. Generation of IORT
>> 7. Implementation Phases
>> 8. References
>>
>> 1. IORT Structure ?
>> --------------------------------------------
>> IORT refers to Input Output remapping table. It is essentially used 
>> to find
>> information about the IO topology (PCIRC-SMMU-ITS) and relationships 
>> between
>> devices.
>>
>> A general structure of IORT [1]:
>> It has nodes for PCI RC, SMMU, ITS and Platform devices. Using an 
>> IORT table
>> relationship between RID -> StreamID -> DeviceId can be obtained.
>> Which device is behind which SMMU and which interrupt controller, 
>> topology
>> is described in IORT Table.
>>
>> Some PCI RC may be not behind an SMMU, and directly map RID->DeviceID.
>>
>> RID is a requester ID in PCI context,
>> StreamID is the ID of the device in SMMU context,
>> DeviceID is the ID programmed in ITS.
>>
>> Each iort_node contains an ID map array to translate one ID into 
>> another.
>> IDmap Entry {input_range, output_range, output_node_ref, id_count}
>> This array is associated with PCI RC node, SMMU node, Named component 
>> node.
>> and can reference to a SMMU or ITS node.
>>
>> 2. Current Support of IORT
>> ---------------------------
>> IORT is proposed to be used by Xen to setup SMMU's and platform devices
>> and for translating RID->StreamID and RID->DeviceID.
>
> I am not sure to understand "to setup SMMU's and platform devices...". 
> With IORT, a software can discover list of SMMUs and the IDs to 
> configure the ITS and SMMUs for each device (e.g PCI, integrated...) 
> on the platform. You will not be able to discover the list of platform 
> devices through it.
>
> Also, it is not really "proposed". It is the only way to get those 
> information from ACPI.
ok, I will rephrase it.
>
>>
>> It is proposed in this document to parse iort once and use the 
>> information
>> to translate RID without traversing IORT again and again.
>>
>> Also Xen prepares an IORT table for dom0 based on host IORT.
>> For DomU IORT table proposed only in case of device passthrough.
>>
>> 3. IORT for Dom0
>> -----------------
>> IORT for Dom0 is based on host iort. Few nodes could be removed or 
>> modified.
>>   For instance
>> - Host SMMU nodes should not be present as Xen should only touch it.
>> - platform nodes (named components) may be controlled by xen command 
>> line.
>
> I am not sure where does this example come from? As I said, there are 
> no plan to support Platform Device passthrough with ACPI. A better 
> example here would removing PMCG.
>
It came from review comments on my previous IORT SMMU hiding patch. 
Andre suggested that Platform Nodes are needed.

After some brainstorming with Julien we found two problems:
1) This only covers RC nodes, but not "named components" (platform
devices), which we will need. ...

From: https://www.mail-archive.com/xen-devel@lists.xen.org/msg123434.html

>>
>> 4. IORT for DomU
>> -----------------
>> IORT for DomU should be generated by toolstack. IORT table is only 
>> present
>> in case of device passthrough.
>>
>> At a minimum domU IORT should include a single PCIRC and ITS Group.
>> Similar PCIRC can be added in DSDT.
>> The exact structure of DomU IORT would be covered along with PCI PT 
>> design.
>>
>> 5. Parsing of IORT in Xen
>> --------------------------
>> IORT nodes can be saved in structures so that IORT table parsing can 
>> be done
>> once and is reused by all xen subsystems like ITS / SMMU etc, domain 
>> creation.
>> Proposed are the structures to hold IORT information. [4]
>>
>> struct rid_map_struct {
>>      void *pcirc_node;
>>      u16 ib; /* Input base */
>>      u32 ob; /* Output base */
>>      u16 idc; /* Id Count */
>>       struct list_head entry;
>> };
>>
>> struct iort_ref
>> {
>>      struct list_head rid_streamId_map;
>>      struct list_head rid_deviceId_map;
>> }iortref;
>>
>> 5.1 Functions to query StreamID and DeviceID from RID.
>>
>> void query_streamId(void *pcirc_node, u16 rid, u32 *streamId);
>> void query_deviceId(void *pcirc_node, u16 rid, u32 *deviceId);
>>
>> Adding a mapping is done via helper functions
>>
>> intadd_rid_streamId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) 
>> intadd_rid_deviceId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) - 
>> rid-streamId map is straight forward and is created using pci_rc's idmap
>> - rid-deviceId map is created by translating streamIds to deviceIds.
>>      fixup_rid_deviceId_map function does that. (See [6])
>>
>> It is proposed that query functions should replace functions like
>> iort_node_map_rid which is currently used in linux and is imported in 
>> Xen
>> in the patchset [2][5]
>>
>> 5.2 Proposed Flow of parsing
>> The flow is based on the patchset in [5]. I have added a reference 
>> code on
>> top of it which does IORT parsing as described in this section. The code
>> is available at [6].
>>
>> The commit also describes the code flow and assumptions.
>
> Which assumptions? I can't see any in the commit message.
>
Oh yes, it only describes the code flow.
> Cheers,
>


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

Re: [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Julien Grall]

On 16/11/17 07:39, Manish Jaggi wrote:
> On 11/14/2017 6:53 PM, Julien Grall wrote:
>>> 3. IORT for Dom0
>>> -----------------
>>> IORT for Dom0 is based on host iort. Few nodes could be removed or 
>>> modified.
>>>   For instance
>>> - Host SMMU nodes should not be present as Xen should only touch it.
>>> - platform nodes (named components) may be controlled by xen command 
>>> line.
>>
>> I am not sure where does this example come from? As I said, there are 
>> no plan to support Platform Device passthrough with ACPI. A better 
>> example here would removing PMCG.
>>
> It came from review comments on my previous IORT SMMU hiding patch. 
> Andre suggested that Platform Nodes are needed.
> 
> After some brainstorming with Julien we found two problems:
> 1) This only covers RC nodes, but not "named components" (platform
> devices), which we will need. ...
> 
> From: https://www.mail-archive.com/xen-devel@lists.xen.org/msg123434.html

I think you misunderstood my comment here... What I call "device 
passthrough" is giving access to a device to a domain other than the 
Hardware Domain

There are no plan for supporting platform device-passthrough on ACPI and 
I don't understand why you would like to control that using the command 
line.

What Andre was saying is your series was not covering the "named 
components" for the Hardware Domain.

Cheers,

-- 
Julien Grall

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

Re: [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Manish Jaggi]

On 11/16/2017 5:07 PM, Julien Grall wrote:
>
>
> On 16/11/17 07:39, Manish Jaggi wrote:
>> On 11/14/2017 6:53 PM, Julien Grall wrote:
>>>> 3. IORT for Dom0
>>>> -----------------
>>>> IORT for Dom0 is based on host iort. Few nodes could be removed or 
>>>> modified.
>>>>   For instance
>>>> - Host SMMU nodes should not be present as Xen should only touch it.
>>>> - platform nodes (named components) may be controlled by xen 
>>>> command line.
>>>
>>> I am not sure where does this example come from? As I said, there 
>>> are no plan to support Platform Device passthrough with ACPI. A 
>>> better example here would removing PMCG.
>>>
>> It came from review comments on my previous IORT SMMU hiding patch. 
>> Andre suggested that Platform Nodes are needed.
>>
>> After some brainstorming with Julien we found two problems:
>> 1) This only covers RC nodes, but not "named components" (platform
>> devices), which we will need. ...
>>
>> From: 
>> https://www.mail-archive.com/xen-devel@lists.xen.org/msg123434.html
>
> I think you misunderstood my comment here... What I call "device 
> passthrough" is giving access to a device to a domain other than the 
> Hardware Domain
>
> There are no plan for supporting platform device-passthrough on ACPI 
> and I don't understand why you would like to control that using the 
> command line.
>
> What Andre was saying is your series was not covering the "named 
> components" for the Hardware Domain.

The section 3 is IORT for Dom0, where I mentioned that  some platform 
devices can be hidden from dom0.
So your comment on Platform device Passthrough might not be valid then 
as it is for domU's only.

Regarding the visibility of a platform device for dom0, I took cue from 
your comment below

This has two benefits:

...
3) We could decide in a finer grain which devices (e.g platform 
device)Dom0 can see.
From: https://www.mail-archive.com/xen-devel@lists.xen.org/msg124534.html

>
> Cheers,
>


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

Re: [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Julien Grall]

Hi Manish,

On 16/11/17 11:46, Manish Jaggi wrote:
> 
> 
> On 11/16/2017 5:07 PM, Julien Grall wrote:
>>
>>
>> On 16/11/17 07:39, Manish Jaggi wrote:
>>> On 11/14/2017 6:53 PM, Julien Grall wrote:
>>>>> 3. IORT for Dom0
>>>>> -----------------
>>>>> IORT for Dom0 is based on host iort. Few nodes could be removed or 
>>>>> modified.
>>>>>   For instance
>>>>> - Host SMMU nodes should not be present as Xen should only touch it.
>>>>> - platform nodes (named components) may be controlled by xen 
>>>>> command line.
>>>>
>>>> I am not sure where does this example come from? As I said, there 
>>>> are no plan to support Platform Device passthrough with ACPI. A 
>>>> better example here would removing PMCG.
>>>>
>>> It came from review comments on my previous IORT SMMU hiding patch. 
>>> Andre suggested that Platform Nodes are needed.
>>>
>>> After some brainstorming with Julien we found two problems:
>>> 1) This only covers RC nodes, but not "named components" (platform
>>> devices), which we will need. ...
>>>
>>> From: 
>>> https://www.mail-archive.com/xen-devel@lists.xen.org/msg123434.html
>>
>> I think you misunderstood my comment here... What I call "device 
>> passthrough" is giving access to a device to a domain other than the 
>> Hardware Domain
>>
>> There are no plan for supporting platform device-passthrough on ACPI 
>> and I don't understand why you would like to control that using the 
>> command line.
>>
>> What Andre was saying is your series was not covering the "named 
>> components" for the Hardware Domain.
> 
> The section 3 is IORT for Dom0, where I mentioned that  some platform 
> devices can be hidden from dom0.
> So your comment on Platform device Passthrough might not be valid then 
> as it is for domU's only.
> 
> Regarding the visibility of a platform device for dom0, I took cue from 
> your comment below

Where did I ever mention the command line solution? Please stop trying 
to put words in my mouth.

There are other reason than passthrough to hide device from the Hardware 
Domain.

> 
> This has two benefits:
> 
> ...
> 3) We could decide in a finer grain which devices (e.g platform 
> device)Dom0 can see.
> From: https://www.mail-archive.com/xen-devel@lists.xen.org/msg124534.html
> 
>>
>> Cheers,
>>
> 

-- 
Julien Grall

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

Re: [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Manish Jaggi]

On 11/16/2017 5:23 PM, Julien Grall wrote:
> Hi Manish,
>
> On 16/11/17 11:46, Manish Jaggi wrote:
>>
>>
>> On 11/16/2017 5:07 PM, Julien Grall wrote:
>>>
>>>
>>> On 16/11/17 07:39, Manish Jaggi wrote:
>>>> On 11/14/2017 6:53 PM, Julien Grall wrote:
>>>>>> 3. IORT for Dom0
>>>>>> -----------------
>>>>>> IORT for Dom0 is based on host iort. Few nodes could be removed 
>>>>>> or modified.
>>>>>>   For instance
>>>>>> - Host SMMU nodes should not be present as Xen should only touch it.
>>>>>> - platform nodes (named components) may be controlled by xen 
>>>>>> command line.
>>>>>
>>>>> I am not sure where does this example come from? As I said, there 
>>>>> are no plan to support Platform Device passthrough with ACPI. A 
>>>>> better example here would removing PMCG.
>>>>>
>>>> It came from review comments on my previous IORT SMMU hiding patch. 
>>>> Andre suggested that Platform Nodes are needed.
>>>>
>>>> After some brainstorming with Julien we found two problems:
>>>> 1) This only covers RC nodes, but not "named components" (platform
>>>> devices), which we will need. ...
>>>>
>>>> From: 
>>>> https://www.mail-archive.com/xen-devel@lists.xen.org/msg123434.html
>>>
>>> I think you misunderstood my comment here... What I call "device 
>>> passthrough" is giving access to a device to a domain other than the 
>>> Hardware Domain
>>>
>>> There are no plan for supporting platform device-passthrough on ACPI 
>>> and I don't understand why you would like to control that using the 
>>> command line.
>>>
>>> What Andre was saying is your series was not covering the "named 
>>> components" for the Hardware Domain.
>>
>> The section 3 is IORT for Dom0, where I mentioned that  some platform 
>> devices can be hidden from dom0.
>> So your comment on Platform device Passthrough might not be valid 
>> then as it is for domU's only.
>>
>> Regarding the visibility of a platform device for dom0, I took cue 
>> from your comment below
>
> Where did I ever mention the command line solution? Please stop trying 
> to put words in my mouth.
>
> There are other reason than passthrough to hide device from the 
> Hardware Domain.
>
Lets put some clarity on the below items specifically for dom0
a. can platform devices can be part of dom0 IORT ?
b. If (a) yes, then how to decide on a finer grain the visibility of 
platform devices for Dom0
     Update ACPI tables to remove the device?
c. Is fine grain visibility of platform device for dom0 to be covered in 
my current patchset

>> This has two benefits:
>>
>> ...
>> 3) We could decide in a finer grain which devices (e.g platform 
>> device)Dom0 can see.
>> From: 
>> https://www.mail-archive.com/xen-devel@lists.xen.org/msg124534.html
>>
>>>
>>> Cheers,
>>>
>>
>


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

Re: [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Julien Grall]

On 16/11/17 12:39, Manish Jaggi wrote:
> 
> 
> On 11/16/2017 5:23 PM, Julien Grall wrote:
>> Hi Manish,
>>
>> On 16/11/17 11:46, Manish Jaggi wrote:
>>>
>>>
>>> On 11/16/2017 5:07 PM, Julien Grall wrote:
>>>>
>>>>
>>>> On 16/11/17 07:39, Manish Jaggi wrote:
>>>>> On 11/14/2017 6:53 PM, Julien Grall wrote:
>>>>>>> 3. IORT for Dom0
>>>>>>> -----------------
>>>>>>> IORT for Dom0 is based on host iort. Few nodes could be removed 
>>>>>>> or modified.
>>>>>>>   For instance
>>>>>>> - Host SMMU nodes should not be present as Xen should only touch it.
>>>>>>> - platform nodes (named components) may be controlled by xen 
>>>>>>> command line.
>>>>>>
>>>>>> I am not sure where does this example come from? As I said, there 
>>>>>> are no plan to support Platform Device passthrough with ACPI. A 
>>>>>> better example here would removing PMCG.
>>>>>>
>>>>> It came from review comments on my previous IORT SMMU hiding patch. 
>>>>> Andre suggested that Platform Nodes are needed.
>>>>>
>>>>> After some brainstorming with Julien we found two problems:
>>>>> 1) This only covers RC nodes, but not "named components" (platform
>>>>> devices), which we will need. ...
>>>>>
>>>>> From: 
>>>>> https://www.mail-archive.com/xen-devel@lists.xen.org/msg123434.html
>>>>
>>>> I think you misunderstood my comment here... What I call "device 
>>>> passthrough" is giving access to a device to a domain other than the 
>>>> Hardware Domain
>>>>
>>>> There are no plan for supporting platform device-passthrough on ACPI 
>>>> and I don't understand why you would like to control that using the 
>>>> command line.
>>>>
>>>> What Andre was saying is your series was not covering the "named 
>>>> components" for the Hardware Domain.
>>>
>>> The section 3 is IORT for Dom0, where I mentioned that  some platform 
>>> devices can be hidden from dom0.
>>> So your comment on Platform device Passthrough might not be valid 
>>> then as it is for domU's only.
>>>
>>> Regarding the visibility of a platform device for dom0, I took cue 
>>> from your comment below
>>
>> Where did I ever mention the command line solution? Please stop trying 
>> to put words in my mouth.
>>
>> There are other reason than passthrough to hide device from the 
>> Hardware Domain.
>>
> Lets put some clarity on the below items specifically for dom0
> a. can platform devices can be part of dom0 IORT ?

Yes. Otherwise, how would you be able to use MSI with platform device?

> b. If (a) yes, then how to decide on a finer grain the visibility of 
> platform devices for Dom0
>      Update ACPI tables to remove the device?
> c. Is fine grain visibility of platform device for dom0 to be covered in 
> my current patchset

No.

Cheers,

-- 
Julien Grall

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