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@lists.xen.org
https://lists.xen.org/xen-devel
