* Gustavo Lima Chaves <[email protected]> [2017-07-26 15:53:45 
-0700]:

> * Jan Kiszka <[email protected]> [2017-07-26 07:38:41 +0200]:
> 
> [...]
> 
> > >> Valentine
> > > 
> > > That's interesting. So we kidnap one of those timers to the hypervisor 
> > > only (since the cells are using APIC timers and are good with them) and 
> > > gain timers on that level, right? Leaving the root cell out of the way on 
> > > the watchdog task looks safer for me as well (reading through the 
> > > thread). We could have policies to reload cells even without 
> > > participation of the root one. Has anyone experimented with those 
> > > different clocks on x86 already?
> > > 
> > 
> > In this last comments, I was not talking about a timer but a clock. We
> > already share the PM "Timer" (which is a clock in reality) across all
> > cells (because it is read-only and trivially handed out via PIO access
> > masks). We could also use it in the hypervisor on x86 in order to gain a
> 
> Do you say it is read-only because we only see an inl() call on that
> address at timing.c or because any write would be Jailhouse-blocked (I
> could not find any code doing said block, but maybe I missed it)?
> 
> I also ask that targeting another thing: would it be trivial, as the
> code is, to enable the RTC region on both root and inmate cell, so
> that an inmate Linux is given a permanent clock as well? I'm doing the
> test now, but just in case...

INTx sharing is the issue here, I guess, ugh. Any clues on how to
provide non "Jan 1 1970" dates for Linux inmates?

-- 
Gustavo Lima Chaves
Intel - Open Source Technology Center

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to