[LITMUS^RT] Running LITMUS-RT on ARM64

[Björn Brandenburg]

> On 29. Aug 2017, at 16:45, Meng Xu <xumengpanda at gmail.com> wrote:
> 
> On Tue, Aug 29, 2017 at 10:26 AM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> 
> > On 29. Aug 2017, at 16:23, Meng Xu <xumengpanda at gmail.com> wrote:
> >
> >>> 3) It’s not just rtspin that will be confused — likely all of LITMUS^RT’s
> >>> budget tracking and enforcement code will not work as expected under
> >>> virtualization (when given vCPUs with non-100% utilization). This is because
> >>> the scheduler is not aware of any times during which a vCPU does not receive
> >>> service, so tasks will be charged for bogus execution time.
> >>
> >> This sounds really bad.
> >
> > I'm wondering if it's designed for this on purpose by Linux people?
> > If yes, they must have discussed some tradeoffs; otherwise, it could
> > lead to some issues.
> 
> What is the alternative? The guest kernel does not know when the vCPU is actually making progress. So how could it react in any other way? Or is there some interface exported by Xen that would allow us to infer exactly how much service a vCPU received?
> 
> ​When a VCPU is preempted, it notify the guest kernel; when a VCPU resumes, it notify the guest kernel. Then the guest kernel knows how long the vcpu is preempted.
> ​I'm unaware this interface has been implemented in Xen or not. But I think it's doable.​ 

I agree that it’s definitely doable in a para-virtualization setting with a cooperative guest kernel, and I’d bet something similar has been done in the context of the lock-holder preemption problem. 

It’s less obvious to me how one would solve this under full/native virtualization, where the guest OS is blissfully unaware of the fact that it is being virtualized without 100% CPU capacity.

> ​(I'm thinking in research perspective. If this issue is serious enough, I guess it could be a research problem to look at)​

Let me know if you end up working on this and need a collaborator. ;-)

- Björn