[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Manish,

On 10/31/2017 12:05 PM, Manish Jaggi wrote:
On 10/27/2017 7:35 PM, Andre Przywara wrote:
When PCI device passthrough is supported, the PCIRC is itself virtual
(emulated by Xen).
One can have any number of virtual PCIRC  and may be virtual SMMUs.
Hence the topology can vary.
I think I don't disagree, my initial comment was just about the
confusion that this "IORT topology is *different* from" term created.
Ok, I will move it in a different section and remove the term "different".

Now read the below lines.
At a minimum domU IORT should include a single PCIRC and ITS Group.
Similar PCIRC can be added in DSDT.
Additional node can be added if platform device is assigned to domU.
No extra node should be required for PCI device pass-through.
Again I don't fully understand this last sentence.
The last line is continuation of the first line "At a minimum..."
OK, but still I don't get how we would end up with an IORT without
(pass-throughed) PCI devices in the first place?
If hypothetically a platform device uses MSI.

I would move out of the equation platform device passthrough. Most of use case I am aware is around embedded and controlled environment. It would be difficult to provide a generic way for Server.

To give a bit more details, when using device-tree the user needs to provide a partial device-tree describing the device passthrough. For ACPI, you would need to do the same but with DSDT.

I will let Sameer comment on it.
Our platform does not have a Named Component node in IORT.

[...]

6. IORT Generation
-------------------
There would be a common code to generate IORT table from
iort_table_struct.
That sounds useful, but we would need to be careful with sharing code
between Xen and the tool stack. Has this actually been done before?
I added the code sharing part here, but I am not hopeful that this would
work as it would require lot of code change on toolstack.
A simple difference is that the acpi header structures have different
member variables. This is same for other structures.
So we might have to create a lot of defines in common code for sharing
and possibility of errors.

See: struct acpi_header in acpi2_0.h (tools/libacpi)
and struct acpi_table_header in actbl.h (xen/include/acpi)
What do you think about this difference in basic structures in toolstack and xen code. When we write a common library should I include a #define for mapping xen structure to toolstack. Would it have more overhead than duplication, that is an implementation issue.
That is why I preferred a domctl, so xen coud prepare IORT for DomU.
I don't this it's justified to move a simple table generation task
into Xen, just to allow code sharing. After all this does not require
any Xen internal knowledge. So it should be done definitely in the
toolstack.
Yes. Fully agree.
The point here is duplication or code reuse.
See above.
Can we please focus on what matters, i.e what is necessary from an high-level perspective to support IORT in the hypervisor.

We can discuss about code sharing/duplication when we get to the support IORT for the guests.

Cheers,

--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.