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

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

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.
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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