Re: [Xen-devel] [RFC] scf: SCF device tree and configuration documentation

[Andrii Anisov <andrii_anisov@xxxxxxxx>]

On 10.05.17 17:22, Ian Jackson wrote:
> The IO access emulation just directs the access to somewhere where it
> can be emulated.  Does that mean you intend for there to be a software
> emulation of the vcoproc, as well as hardware passthrough (with
> context switching) ?
The concept of an "access emulation" is not about emulating a coproc 
functionality, its only about reacting on mmio accesses appropriately 
from the user (domain) point of view.
Basically on a register read - return shadowed value; on writes - stack 
them, to replay them to the HW once this vcoproc context is scheduled in.
I do realize that this part could be the most complex part of some 
specific coprocessor SCF support code.

> Obviously I am still confused, because this doesn't seem to make sense
> to me.  I was imagining the toolstack generating virtual irqs/mmio
> ranges which the guest would see.  It would then arrange for Xen to
> program the hardware appropriately, to direct those ranges to the
> physical hardware (when the coproc is exposed to the guest).
While you are virtualizing a coprocessor, you can not map those address 
ranges for the domain permanently. At least during the period a vcoproc 
is scheduled out, ranges should be unmapped and accesses should be 
handled by access emulation mmio handlers.
> And I don't see why the physical address ranges used by Xen to
> manipulate the coproc would have to be the same as the guest
> pseudophysical addresses used by the guest.
No need to keep ranges the same. But for proper access emulation 
functionality you have to identify specific address ranges in order to 
assign appropriate mmio handlers.
> As for device tree generation, any kind of passthrough of a DT device
> is going to involve filtering/processing/amending the DT information
> for the device: something is going to have to take the information
> from the physical DT (as provided to Xen), find the relevant parts
> (the parts which relate to the particular device), and substitute
> addresses etc., and insert the result into the guest DT.
Something like this is done now, except taking the info from the physical DT. 
Now it is assumed that the pfdt OK, if the SCF is able to be configured with 
this pfdt. Not brilliant, but works for me this far.

> So this will be done by something in the domain configuration ?
Yes, sure. I think the domain configuration file should have the needed 
config options.
But so far I did not realize the appropriate config format, so I keep 
the configuration in a device tree both for Dom0 and DomU.
For DomU the partial device tree option only is used so far. Toolstack 
does parse the pfdt, in case nodes with "xen,vcoproc" are
found, actions to configure SCF are taken.



--

*Andrii Anisov*



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