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

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

Hello George,

On 31 May 2017 at 20:02, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>>> There is no way out: if the stubdom needs events, then we'll have to
>>> expose and context switch the vGIC. If it doesn't, then we can skip the
>>> vGIC. However, we would have a similar problem with EL0 apps: I am
>>> assuming that EL0 apps don't need to handle interrupts, but if they do,
>>> then they might need something like a vGIC.
>> Hm. Correct me, but if we want make stubdom to handle some requests
>> (e.g. emulate MMIO access), then it needs events, and thus it needs
>> interrupts. At least, I'm not aware about any other mechanism, that
>> allows hypervisor to signal to a domain.
>> On other hand, EL0 app (as I see them) does not need such events.
>> Basically, you just call function `handle_mmio()` right in the app.
>> So, apps can live without interrupts and they still be able to handle
>> request.
>
> So remember that "interrupt" and "event" are basically the same as
> "structured callback".  When anything happens that Xen wants to tell the
> EL0 app about, it has to have a way of telling it.  If the EL0 app is
> handling a device, it has to have some way of getting interrupts from
> that device; if it needs to emulate devices sent to the guest, it needs
> some way to tell Xen to deliver an interrupt to the guest.
Basically yes. There should be mechanism to request something from
native application. Question is how this mechanism can be implemented.
Classical approach is a even-driven loop:

while(1) {
    wait_for_event();
    handle_event_event();
    return_back_results();
}

wait_for_event() can by anything from WFI instruction to read() on
socket. This is how stubdoms are working. I agree with you: there are
no sense to repeat this in native apps.

> Now, we could make the EL0 app interface "interruptless".  Xen could
> write information about pending events in a shared memory region, and
> the EL0 app could check that before calling some sort of block()
> hypercall, and check it again when it returns from the block() call.

> But the shared event information starts to look an awful lot like events
> and/or pending bits on an interrupt controller -- the only difference
> being that you aren't interrupted if you're already running.

Actually there are third way, which I have used. I described it in
original email (check out [1]).
Basically, native application is dead until it is needed by
hypervisor. When hypervisor wants some services from app, it setups
parameters, switches mode to EL0 and jumps at app entry point.
> I'm pretty sure you could run in this mode using the existing interfaces
> if you didn't want the hassle of dealing with asynchrony.  If that's the
> case, then why bother inventing an entirely new interface, with its own
> bugs and duplication of functionality?  Why not just use what we already
> have?
Because we are concerned about latency. In my benchmark, my native app
PoC is 1.6 times faster than stubdom.


[1] http://marc.info/?l=xen-devel&m=149151018801649&w=2


-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@xxxxxxxxx

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