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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Andrii Anisov writes ("Re: [RFC] scf: SCF device tree and configuration 
documentation"):
> On 05.05.17 20:20, Ian Jackson wrote:
> > Why wouldn't the toolstack simply choose appropriate irqs/mmio
> > ranges ?  I would expect the virtual irqs/mmio ranges to not
> > necessarily match the physical ones anyway.  Is choosing these ranges
> > complicated ?
>
> This could make sense. Choosing ranges should not be really complicated. 
> The point here is that we need these ranges both for hypervisor and domU 
> device tree generation, and we should keep the accordance.

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).

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.

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.

> > What I mean is that your previous proposal doesn't provide any way to
> > say which guest(s) should get instances of this virtual coprocessor.
> > Some guests should get none; some one; etc.
> 
> I think those guests which are configured to have a virtual 
> coprocessor(s) will have some.

So this will be done by something in the domain configuration ?

> Those which are not configured to have - will not.
> I would not set any specific limitations here. Shall I?

Err, no.  At least, I don't think so.  That's not what I was asking
for.

> > Also, I am perplexed by your suggestion that a single physical coproc
> > might be presented to a guest as two vcoprocs.  If your sharing
> > strategy is context-switching, is this not going to result in a lot of
> > context-switching, whenever the guest (which thinks it has two
> > coprocs) touches one and then the other ?
> 
> I would not treat this case too specific. Any touches of the scheduled 
> out virtual coprocessor would be handled by IO access emulation 
> mechanism, and it is not necessary to evoke the context switch at the 
> moment.

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) ?

Ian.
(still rather baffled, I'm afraid)

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