Hi Dario,
Dario Faggioli writes: > On Thu, 2020-09-24 at 18:08 +0000, Volodymyr Babchuk wrote: >> So, as I see this, functions are called in the following way (on >> x86): >> >> 1. do_softirq() calls vcpu_begin_hyp_task() and then executes >> __do_softirq() >> >> 2. __do_softirq() does different jobs and eventually calls schedule() >> >> 3. schedule() calls vcpu_end_hyp_task() and makes scheduling decision >> which leads to call to context_switch() >> >> 4. On end context_switch() we will exit hypervisor and enter VM. At >> least, this is how I understand >> >> nextd->arch.ctxt_switch->tail(next); >> >> call. >> >> So, no need to call vcpu_begin_hyp_task() in context_switch() for >> x86. >> > Mmm... This looks correct to me too. > > And what about the cases where schedule() does return? Can it return on x86? I want to test this case, but how force it? Null scheduler, perhaps? > Are these also fine because they're handled within __do_softirq() > (i.e., without actually going back to do_softirq() and hence never > calling end_hyp_task() for a second time)? I afraid, that there will be a bug. schedule() calls end_hyp_task(), and if it will eventually return from __do_softirq() to do_softirq(), end_hyp_task() will be called twice. > >> I have put bunch of ASSERTs to ensure that vcpu_begin_hyp_task() or >> vcpu_end_hyp_task() are not called twice and that vcpu_end_hyp_task() >> is >> called after vcpu_begin_hyp_task(). Those asserts are not failing, so >> I >> assume that I did all this in the right way :) >> > Yeah, good to know. :-) > > Are you doing these tests with both core-scheduling disabled and > enabled? Good question. On x86 I am running Xen in QEMU. With -smp=2 it sees two CPUs: (XEN) Brought up 2 CPUs (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource You are right, I need to try other variants of scheduling granularity. Do you by any chance know how to emulate more complex setup in QEMU? Also, what is the preferred way to test/debug Xen on x86? -- Volodymyr Babchuk at EPAM
