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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 26/05/17 20:28, Volodymyr Babchuk 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.

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.

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?

 -George

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