Re: [Xen-devel] null scheduler bug

[Milan Boberic <milanboberic94@xxxxxxxxx>]

I'm sorry for html and dropping xen-devel and dropping other CCs,
missed to read the rules.
I tried 4.10 version and checked for commits you asked in earlier reply.

2b936ea7b "xen: RCU: avoid busy waiting until the end of grace period."
38ad8151f "xen: RCU: don't let a CPU with a callback go idle."

Commits are there and I will definitely continue with 4.10 version.
But it didn't solve my problem entirely.

I create my bare-metal application (with xl create) and destroy it
with xl destroy (it disappears from xl list) and when I try to create
it again same error pops but if I immediately run xl create command
again it creates it without error.
If I run xl create twice fast sometimes bare-metal application isn't
in any state (it should be in "running" state).
If I wait some time (approximately between 30 and 90 seconds) after
destruction of that bm app and then run xl create it will create it
without error.

This is github repository of Xen I use:
https://github.com/Xilinx/xen/tree/xilinx/stable-4.10

Is there anything else I can send that would be helpful?

Thanks in advance, best regards, Milan Boberic.

On Thu, Sep 13, 2018 at 10:24 AM Dario Faggioli <dfaggioli@xxxxxxxx> wrote:
>
> Hi,
>
> So, first of all:
> 1. use plaintext, not HTML
> 2. don't drop the xen-devel list (and other Cc-s) when replying.
>
> :-)
>
> That being said...
>
> On Thu, 2018-09-13 at 09:38 +0200, Milan Boberic wrote:
> > Hi Dario,
> > yes passtrhough is involved.
> >
> Ok.
>
> > This is everything I did so far:
> >
> > I implemented Xen Hypervisor 4.9.2 on UltraZed-EG board with carrier
> > card following these steps:
> > 1.) installed petalinux 2018.2 on Ubuntu 16.04
> > 2.) dowloaded  UltraZed-EG IO Carrier Card - PetaLinux 2018.2
> > Standard BSP
> > 3.) created project:   petalinux-create -t project –s  <path_to_BSP>
> > 4.) copied xen-overlay.dtsi from ZCU102 project (also made with BSP)
> > to my project
> > 5.) built xen hypervisor following this guide link  (booting with SD
> > card)
> > 6.) made baremetal application that blinks PS LED with Vivado
> > 7.) measured signals jitted when application is on board with and
> > with out Xen
> >
> I am not familiar with building an SD-Card image for an ARM system with
> Xen on it. What I can tell, though, is that Xen 4.9.2 does not look to
> me to include the RCU subsystem fixes that I mentioned in my reply.
>
> I don't recall why we did not backport them. It may be that they're not
> entirely trivial, and they fix a behavior which manifests only in not
> fully supported cases. Or that we (well, I :-/) forgot.
>
> I can have a look, at how challenging it is to apply the patches to
> 4.9.x (but no hard feelings if anyone beats me at it, I promise
> :-D).
>
> In the meantime, if you have the chance of trying Xen 4.10 or 4.10.1,
> which has those fixes, that would be great. In fact, in case everything
> would work with such version, that would be another clue that the RCU
> issue is the actual culprit.
>
> > I menaged to decrease jitter adding sched=null vwfi=native in xen-
> > overlay.dtsi file in xen-bootargs.
> >
> > The problem is when I add sched=null vwfi=native, I can create my
> > bare-metal application with xl create and destroy it with xl destroy
> > (it disappears from xl list) but when I want to start it again (xl
> > create) this error pops:
> >
> > root@uz3eg-iocc-2018-2:~# xl create bm1.cfg
> > Parsing config from bm1.cfg
> > (XEN) IRQ 48 is already used by domain 1
> > libxl: error: libxl_create.c:1278:domcreate_launch_dm: Domain
> > 2:failed give domain access to irq 48: Device or resource busy
> > libxl: error: libxl_domain.c:1003:libxl__destroy_domid: Domain 2:Non-
> > existant domain
> > libxl: error: libxl_domain.c:962:domain_destroy_callback: Domain
> > 2:Unable to destroy guest
> > libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain
> > 2:Destruction of domain failed
> >
> > When I remove  sched=null vwfi=native and build project again
> > everything works fine, I can create and destroy bm app as many times
> > as I want.
> >
> Yes. If you look at the email (and to the full thread) I put links to,
> you'll see that the behavior is exactly the same. It mentions the
> Credit2 scheduler not working, rather than null, but the problem is the
> same, i.e., that there is no periodic timer tick neither in Credit2 nor
> in null.
>
> Regards,
> Dario
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Software Engineer @ SUSE https://www.suse.com/

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel