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

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

Hello Ian,

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. Moreover, we need a coprocessor device tree node for domU. Because it could describe some specifics beyond an iomem/irq presentation of the coprocessor.

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.
Those which are not configured to have - will not.
I would not set any specific limitations here. Shall I?

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. So the number of context switches is rather matter of the scheduling algorithm I guess.


*Andrii Anisov*

Xen-devel mailing list



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