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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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