Re: [Xen-devel] Notes on stubdoms and latency on ARM

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 01/06/17 13:40, Dario Faggioli wrote:
> On Thu, 2017-06-01 at 12:52 +0200, George Dunlap wrote:
>>> On May 31, 2017, at 6:45 PM, Stefano Stabellini <sstabellini@kernel
>>> .org> wrote:
>>>
>>> I don't think we should provide that. If the user wants a stable
>>> interface, she can use domains. I suggested that the code for the
>>> EL0
>>> app should come out of the Xen repository directly. Like for the
>>> Xen
>>> tools, they would be expected to be always in-sync.
>>
>> Hmm, it sounds like perhaps I misunderstood you and Volodymyr.  I
>> took “you just call function `handle_mmio()` right in the app” to
>> mean that the *app* calls the *hypervisor* function named
>> “handle_mmio”.
>>
> Right. That what I had understood too.
> 
>> It sounds like what he (or at least you) actually meant was that the
>> *hypervisor* calls the function named “handle_mmio” in the *app*?
>>
> Mmm... it's clearly me that am being dense, but what do you exactly
> mean with "the hypervisor calls the function named handle_mmio() in the
> app"? In particular the "in the app" part, and how is the hypervisor
> going to be "in" the app...

Well it sounds to me similar to what Linux would do with modules: the
module has the symbols encoded somewhere in it.  The hypervisor would
load the "app" binary; and when the appropriate device MMIO happened, it
would call the "handle_mmio()" function (which would be a bit more like
an entry point).

But it seems to me like having an interface where the app actively
registers callbacks for specific events is a lot easier than working out
how to store the dynamic linking information in the module and then
parse it in Xen.

 -George

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