Re: null scheduler bug

[Dario Faggioli <dfaggioli@suse.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3354 bytes --]

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/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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