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

Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.

On Tuesday 07 July 2015 04:54 PM, Ian Campbell wrote:
On Tue, 2015-07-07 at 14:16 +0530, Manish Jaggi wrote:
As asked you in the previous mail, can you please prove it? The
function used to get the requester ID (pci_for_each_dma_alias) is more
complex than a simple return sbdf.
I am not sure what you would like me to prove.
As of ThunderX Xen code we have assumed sbdf == deviceID.
Please remember that you are not writing "ThunderX Xen code" here, you
are writing generic Xen code which you happen to be testing on Thunder
X. The design and implementation does need to consider the more generic
case I'm afraid.

In particular if this is going to be a PHYSDEVOP then it needs to be
designed to be future proof, since PHYSDEVOP is a stable API i.e. it is
hard to change in the future.

I think I did ask elsewhere _why_ this was a physdev op, since I can't
see why it can't be done by the toolstack, and therefore why it can't be
a domctl.
If it can be done in domctl I prefer that. Will get back on this.

If this was a domctl there might be scope for accepting an
implementation which made assumptions such as sbdf == deviceid. However
I'd still like to see this topic given proper treatment in the design
and not just glossed over with "this is how ThunderX does things".
I got your point.
Or maybe the solution is simple and we should just do it now -- i.e. can
we add a new field to the PHYSDEVOP_pci_host_bridge_add argument struct
which contains the base deviceid for that bridge
deviceId would be same as sbdf. As we dont have a way to translate sbdf to deviceID.
What about SMMU streamID, can we also have sbdf = deviceID = smmuid_bdf
FYI: In thunder each RC is on a separate smmu.

Can we take that as step1.
  (since I believe both
DT and ACPI IORT assume a simple linear mapping[citation needed])?
I am ok with the approach but then we have to put something similar to IORT in device tree.
Currently it is not there.
If we take that route of creating IORT for host / guest it would be altogether different effort.

Xen-devel mailing list

Xen-devel mailing list



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