Getting ACRN to work


Geoffroy Van Cutsem
 

Hi Dubravko,

 

These are the same that I see on my system, but my terminal is starting and running correctly.

 

Do I understand (and remember) correctly that the only differences between the terminal functioning correctly and when it’s not, is when running under ACRN? If true, is that happening with a kernel you built yourself (with igb built in) or also with the ACRN kernel from Clear Linux (iot-lts2018-sos)? If it’s the former, can you check the CONFIG_UNIX98_PTYS option in your kernel (maybe send us a diff between your kernel config and the acrn-kernel config [1]?

 

[1] https://github.com/projectacrn/acrn-kernel/blob/master/kernel_config_uefi_sos

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, March 12, 2020 6:10 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

gnome-terminal results in the same error, "There was an error creating child process...". In ssh session I see this:

clear@clr-sos-guest~ $ gnome-terminal -v --display :0

# _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’

# _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’

# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)

# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)

# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)

Ctrl-alt-f3 works, I can log in. Ctrl-alt-f2 returns me to the GUI, where terminal still refuses to work.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Thursday, March 12, 2020 3:20 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko.

 

I agree, it does not look like the minor differences would be the cause of your troubles.

 

If/when you get an SSH session going, can you try to launch the gnome-terminal from that session (for GNOME on X): gnome-terminal -v --display :1

 

When you have a graphical environment up and running, are you able to use one of the other tty session (Ctrl-Alt-F3 as an example)?

 

I must confess that I’m rather puzzled by this problem…

 

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 10, 2020 1:45 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

Please find attached the comparison of /proc/mounts content, left side with ACRN, right side without ACRN but with the same kernel. They're mostly identical, I don't know if smaller differences could be important.

 

In both cases where terminal does and doesn't work, I've got all the logs by running a shell script at Linux startup. I think the script runs under root account.

 

I've wanted to use ssh over network, but I suspect there is something wrong with the Ethernet IC - some days it works, some days it doesn't. We don't think it has anything to do with ACRN, must be the IC or the soldering or something on the PCB. Yesterday it didn't work so I've made the script. Today it works, but I don't trust it so I've reused the script anyway.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Tuesday, March 10, 2020 12:10 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

 

Can you check (paste) the actual content of /proc/mounts, I want to make sure that devpts is mounted under /dev/pts in both cases.

 

When you checked the output of ‘ls -l /dev/pts/*’ in the config where the terminal works, did you run that from a terminal or a console (or a serial port connection)?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Monday, March 9, 2020 4:09 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

With ACRN (Terminal doesn't work):

 

/proc/mounts:

lrwxrwxrwx 1 root root 11 Nov 29 17:32 /proc/mounts -> self/mounts

 

/dev/pts/*:

c--------- 1 root root 5, 2 Nov 29 17:32 /dev/pts/ptmx

 

Without ACRN but with the same kernel (Terminal works), the content is the same.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Friday, March 6, 2020 11:21 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Regarding the terminal problem, can you check the content of /proc/mounts (to see if devpts is mounted) and also check the output of ‘ls -l /dev/pts/*’?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, March 5, 2020 5:01 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Xinjun and Geofrroy,

 

I've made more tests and found a combination of settings where mouse cursor is working well.

 

This doesn't work, kernel starts loading but crashes; I'm not sure what exactly happens because I only see kernel printouts stopping scrolling, while no errors are visible:

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"

 

If I modify just these two settings in the list above, that crashes too:

"i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"

 

This, however, works (found on a link provided by Geoffroy):

i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0

With these, at the login screen, depending on which desktop compositor I choose, this happens:

  • GNOME of Xorg (default) = bad flickering mouse
  • GNOME Flashback / Metacity = good mouse cursor
  • GNOME on Wayland = good mouse cursor
  • Weston = mouse ok, but I see only Terminal icon, and even that won't start? perhaps I don't know how to use it

In all 4 variations, Terminal doesn't work.

 

Terminal settings:

$ uname -r
4.19.94-PKT-200203T060100Z-00001-gb288780f868f

 

$ ls -l /usr/lib/modules

total 16

drwxrwxrwx 3 root root 4096 Feb 26 18:34 4.19.94-PKT-200203T060100Z-00001-gb288780f868f /* my customized kernel, with igb driver enabled */

drwxr-xr-x 3 root root 4096 Feb 26 13:29 4.19.97-104.iot-lts2018-sos /* default ACRN kernel */

drwxr-xr-x 3 root root 4096 Feb 25 16:34 5.5.6-914.native /* Clear Linux kernel */

drwxr-xr-x 3 root root 4096 Mar  3 13:45 5.5.7-916.native /* another Clear Linux kernel, before I remembered I should disable auto-updates */

 

$ sudo cat /sys/kernel/debug/dri/0/i915_display_info

Password:

CRTC info

---------

CRTC 44: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24

        fb: 93, pos: 0x0, size: 1920x1080

        encoder 57: type: DDI B, connectors:

                connector 58: type: DP-1, status: connected, mode:

                id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

        No cursor plane available on this platform

        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0

        --Plane id 29: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)

        --Plane id 34: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        --Plane id 39: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        underrun reporting: cpu=yes pch=yes

CRTC 50: pipe: B, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

 

Connector info

--------------

connector 58: type DP-1, status: connected

        name:

        physical dimensions: 480x270mm

        subpixel order: Unknown

        CEA rev: 0

        DPCD rev: 11

        audio support: no

        DP branch device present: no

        modes:

                id 77:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

                id 80:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse 1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5

                id 85:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 79:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 78:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse 1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5

                id 86:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse 1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5

                id 87:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa

                id 88:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5

                id 81:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5

                id 82:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa

                id 83:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa

                id 84:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6

connector 68: type HDMI-A-1, status: disconnected

        audio support: no

        modes:

I've attached a screenshot. "Relaunch" doesn't help and neither do any of the settings. It's the same if I start if from the menu, or with ctrl+alt+t.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Xinyun Liu via Lists.Projectacrn.Org <xinyun.liu=intel.com@...>
Sent: Thursday, March 5, 2020 6:35 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners ), which is a hack in kernel driver i915 display module.  To make it's work,  it requires both UOS and SOS has the correct kernel parameters.  And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)  and uos is Android.
here is  the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"

You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.

And after switch to kbl/whl nuc platform, things changed.  As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor.  We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design.  The cursor plane could be used by App who explicity claimed.
2. Pipe A.  Currently we focus on WaaG (Windows  as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111" in SOS to let SOS use pipe B or others.  Then UOS and SOS should both have display output now but has some limitations.  Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting.  The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.

Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output. 

Thanks,
Xinyun


Dubravko Moravski | Exor Embedded S.r.l. <dubravko.moravski@...>
 

Hi Geoffroy,

gnome-terminal results in the same error, "There was an error creating child process...". In ssh session I see this:
clear@clr-sos-guest~ $ gnome-terminal -v --display :0
# _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
# _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)
# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)
Ctrl-alt-f3 works, I can log in. Ctrl-alt-f2 returns me to the GUI, where terminal still refuses to work.

Regards,
Dubravko


Dubravko Moravski
SW engineering
Exor Embedded S.r.l.
p: +38 512455659  m: +38 5915402413
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy
From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Thursday, March 12, 2020 3:20 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
 

Hi Dubravko.

 

I agree, it does not look like the minor differences would be the cause of your troubles.

 

If/when you get an SSH session going, can you try to launch the gnome-terminal from that session (for GNOME on X): gnome-terminal -v --display :1

 

When you have a graphical environment up and running, are you able to use one of the other tty session (Ctrl-Alt-F3 as an example)?

 

I must confess that I’m rather puzzled by this problem…

 

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 10, 2020 1:45 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

Please find attached the comparison of /proc/mounts content, left side with ACRN, right side without ACRN but with the same kernel. They're mostly identical, I don't know if smaller differences could be important.

 

In both cases where terminal does and doesn't work, I've got all the logs by running a shell script at Linux startup. I think the script runs under root account.

 

I've wanted to use ssh over network, but I suspect there is something wrong with the Ethernet IC - some days it works, some days it doesn't. We don't think it has anything to do with ACRN, must be the IC or the soldering or something on the PCB. Yesterday it didn't work so I've made the script. Today it works, but I don't trust it so I've reused the script anyway.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Tuesday, March 10, 2020 12:10 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

 

Can you check (paste) the actual content of /proc/mounts, I want to make sure that devpts is mounted under /dev/pts in both cases.

 

When you checked the output of ‘ls -l /dev/pts/*’ in the config where the terminal works, did you run that from a terminal or a console (or a serial port connection)?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Monday, March 9, 2020 4:09 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

With ACRN (Terminal doesn't work):

 

/proc/mounts:

lrwxrwxrwx 1 root root 11 Nov 29 17:32 /proc/mounts -> self/mounts

 

/dev/pts/*:

c--------- 1 root root 5, 2 Nov 29 17:32 /dev/pts/ptmx

 

Without ACRN but with the same kernel (Terminal works), the content is the same.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Friday, March 6, 2020 11:21 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Regarding the terminal problem, can you check the content of /proc/mounts (to see if devpts is mounted) and also check the output of ‘ls -l /dev/pts/*’?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, March 5, 2020 5:01 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Xinjun and Geofrroy,

 

I've made more tests and found a combination of settings where mouse cursor is working well.

 

This doesn't work, kernel starts loading but crashes; I'm not sure what exactly happens because I only see kernel printouts stopping scrolling, while no errors are visible:

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"

 

If I modify just these two settings in the list above, that crashes too:

"i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"

 

This, however, works (found on a link provided by Geoffroy):

i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0

With these, at the login screen, depending on which desktop compositor I choose, this happens:

  • GNOME of Xorg (default) = bad flickering mouse
  • GNOME Flashback / Metacity = good mouse cursor
  • GNOME on Wayland = good mouse cursor
  • Weston = mouse ok, but I see only Terminal icon, and even that won't start? perhaps I don't know how to use it

In all 4 variations, Terminal doesn't work.

 

Terminal settings:

$ uname -r
4.19.94-PKT-200203T060100Z-00001-gb288780f868f

 

$ ls -l /usr/lib/modules

total 16

drwxrwxrwx 3 root root 4096 Feb 26 18:34 4.19.94-PKT-200203T060100Z-00001-gb288780f868f /* my customized kernel, with igb driver enabled */

drwxr-xr-x 3 root root 4096 Feb 26 13:29 4.19.97-104.iot-lts2018-sos /* default ACRN kernel */

drwxr-xr-x 3 root root 4096 Feb 25 16:34 5.5.6-914.native /* Clear Linux kernel */

drwxr-xr-x 3 root root 4096 Mar  3 13:45 5.5.7-916.native /* another Clear Linux kernel, before I remembered I should disable auto-updates */

 

$ sudo cat /sys/kernel/debug/dri/0/i915_display_info

Password:

CRTC info

---------

CRTC 44: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24

        fb: 93, pos: 0x0, size: 1920x1080

        encoder 57: type: DDI B, connectors:

                connector 58: type: DP-1, status: connected, mode:

                id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

        No cursor plane available on this platform

        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0

        --Plane id 29: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)

        --Plane id 34: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        --Plane id 39: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        underrun reporting: cpu=yes pch=yes

CRTC 50: pipe: B, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

 

Connector info

--------------

connector 58: type DP-1, status: connected

        name:

        physical dimensions: 480x270mm

        subpixel order: Unknown

        CEA rev: 0

        DPCD rev: 11

        audio support: no

        DP branch device present: no

        modes:

                id 77:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

                id 80:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse 1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5

                id 85:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 79:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 78:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse 1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5

                id 86:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse 1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5

                id 87:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa

                id 88:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5

                id 81:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5

                id 82:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa

                id 83:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa

                id 84:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6

connector 68: type HDMI-A-1, status: disconnected

        audio support: no

        modes:

I've attached a screenshot. "Relaunch" doesn't help and neither do any of the settings. It's the same if I start if from the menu, or with ctrl+alt+t.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Xinyun Liu via Lists.Projectacrn.Org <xinyun.liu=intel.com@...>
Sent: Thursday, March 5, 2020 6:35 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners ), which is a hack in kernel driver i915 display module.  To make it's work,  it requires both UOS and SOS has the correct kernel parameters.  And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)  and uos is Android.
here is  the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"

You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.

And after switch to kbl/whl nuc platform, things changed.  As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor.  We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design.  The cursor plane could be used by App who explicity claimed.
2. Pipe A.  Currently we focus on WaaG (Windows  as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111" in SOS to let SOS use pipe B or others.  Then UOS and SOS should both have display output now but has some limitations.  Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting.  The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.

Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output. 

Thanks,
Xinyun


Geoffroy Van Cutsem
 

Hi Dubravko.

 

I agree, it does not look like the minor differences would be the cause of your troubles.

 

If/when you get an SSH session going, can you try to launch the gnome-terminal from that session (for GNOME on X): gnome-terminal -v --display :1

 

When you have a graphical environment up and running, are you able to use one of the other tty session (Ctrl-Alt-F3 as an example)?

 

I must confess that I’m rather puzzled by this problem…

 

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 10, 2020 1:45 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

Please find attached the comparison of /proc/mounts content, left side with ACRN, right side without ACRN but with the same kernel. They're mostly identical, I don't know if smaller differences could be important.

 

In both cases where terminal does and doesn't work, I've got all the logs by running a shell script at Linux startup. I think the script runs under root account.

 

I've wanted to use ssh over network, but I suspect there is something wrong with the Ethernet IC - some days it works, some days it doesn't. We don't think it has anything to do with ACRN, must be the IC or the soldering or something on the PCB. Yesterday it didn't work so I've made the script. Today it works, but I don't trust it so I've reused the script anyway.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Tuesday, March 10, 2020 12:10 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

 

Can you check (paste) the actual content of /proc/mounts, I want to make sure that devpts is mounted under /dev/pts in both cases.

 

When you checked the output of ‘ls -l /dev/pts/*’ in the config where the terminal works, did you run that from a terminal or a console (or a serial port connection)?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Monday, March 9, 2020 4:09 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

With ACRN (Terminal doesn't work):

 

/proc/mounts:

lrwxrwxrwx 1 root root 11 Nov 29 17:32 /proc/mounts -> self/mounts

 

/dev/pts/*:

c--------- 1 root root 5, 2 Nov 29 17:32 /dev/pts/ptmx

 

Without ACRN but with the same kernel (Terminal works), the content is the same.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Friday, March 6, 2020 11:21 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Regarding the terminal problem, can you check the content of /proc/mounts (to see if devpts is mounted) and also check the output of ‘ls -l /dev/pts/*’?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, March 5, 2020 5:01 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Xinjun and Geofrroy,

 

I've made more tests and found a combination of settings where mouse cursor is working well.

 

This doesn't work, kernel starts loading but crashes; I'm not sure what exactly happens because I only see kernel printouts stopping scrolling, while no errors are visible:

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"

 

If I modify just these two settings in the list above, that crashes too:

"i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"

 

This, however, works (found on a link provided by Geoffroy):

i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0

With these, at the login screen, depending on which desktop compositor I choose, this happens:

  • GNOME of Xorg (default) = bad flickering mouse
  • GNOME Flashback / Metacity = good mouse cursor
  • GNOME on Wayland = good mouse cursor
  • Weston = mouse ok, but I see only Terminal icon, and even that won't start? perhaps I don't know how to use it

In all 4 variations, Terminal doesn't work.

 

Terminal settings:

$ uname -r
4.19.94-PKT-200203T060100Z-00001-gb288780f868f

 

$ ls -l /usr/lib/modules

total 16

drwxrwxrwx 3 root root 4096 Feb 26 18:34 4.19.94-PKT-200203T060100Z-00001-gb288780f868f /* my customized kernel, with igb driver enabled */

drwxr-xr-x 3 root root 4096 Feb 26 13:29 4.19.97-104.iot-lts2018-sos /* default ACRN kernel */

drwxr-xr-x 3 root root 4096 Feb 25 16:34 5.5.6-914.native /* Clear Linux kernel */

drwxr-xr-x 3 root root 4096 Mar  3 13:45 5.5.7-916.native /* another Clear Linux kernel, before I remembered I should disable auto-updates */

 

$ sudo cat /sys/kernel/debug/dri/0/i915_display_info

Password:

CRTC info

---------

CRTC 44: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24

        fb: 93, pos: 0x0, size: 1920x1080

        encoder 57: type: DDI B, connectors:

                connector 58: type: DP-1, status: connected, mode:

                id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

        No cursor plane available on this platform

        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0

        --Plane id 29: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)

        --Plane id 34: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        --Plane id 39: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        underrun reporting: cpu=yes pch=yes

CRTC 50: pipe: B, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

 

Connector info

--------------

connector 58: type DP-1, status: connected

        name:

        physical dimensions: 480x270mm

        subpixel order: Unknown

        CEA rev: 0

        DPCD rev: 11

        audio support: no

        DP branch device present: no

        modes:

                id 77:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

                id 80:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse 1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5

                id 85:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 79:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 78:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse 1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5

                id 86:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse 1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5

                id 87:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa

                id 88:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5

                id 81:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5

                id 82:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa

                id 83:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa

                id 84:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6

connector 68: type HDMI-A-1, status: disconnected

        audio support: no

        modes:

I've attached a screenshot. "Relaunch" doesn't help and neither do any of the settings. It's the same if I start if from the menu, or with ctrl+alt+t.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Xinyun Liu via Lists.Projectacrn.Org <xinyun.liu=intel.com@...>
Sent: Thursday, March 5, 2020 6:35 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners ), which is a hack in kernel driver i915 display module.  To make it's work,  it requires both UOS and SOS has the correct kernel parameters.  And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)  and uos is Android.
here is  the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"

You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.

And after switch to kbl/whl nuc platform, things changed.  As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor.  We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design.  The cursor plane could be used by App who explicity claimed.
2. Pipe A.  Currently we focus on WaaG (Windows  as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111" in SOS to let SOS use pipe B or others.  Then UOS and SOS should both have display output now but has some limitations.  Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting.  The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.

Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output. 

Thanks,
Xinyun


Dubravko Moravski | Exor Embedded S.r.l. <dubravko.moravski@...>
 

Hi Geoffroy,

Please find attached the comparison of /proc/mounts content, left side with ACRN, right side without ACRN but with the same kernel. They're mostly identical, I don't know if smaller differences could be important.

In both cases where terminal does and doesn't work, I've got all the logs by running a shell script at Linux startup. I think the script runs under root account.

I've wanted to use ssh over network, but I suspect there is something wrong with the Ethernet IC - some days it works, some days it doesn't. We don't think it has anything to do with ACRN, must be the IC or the soldering or something on the PCB. Yesterday it didn't work so I've made the script. Today it works, but I don't trust it so I've reused the script anyway.

Regards,
Dubravko


Dubravko Moravski
SW engineering
Exor Embedded S.r.l.
p: +38 512455659  m: +38 5915402413
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy
From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Tuesday, March 10, 2020 12:10 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
 

Hi Dubravko,

 

Can you check (paste) the actual content of /proc/mounts, I want to make sure that devpts is mounted under /dev/pts in both cases.

 

When you checked the output of ‘ls -l /dev/pts/*’ in the config where the terminal works, did you run that from a terminal or a console (or a serial port connection)?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Monday, March 9, 2020 4:09 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

With ACRN (Terminal doesn't work):

 

/proc/mounts:

lrwxrwxrwx 1 root root 11 Nov 29 17:32 /proc/mounts -> self/mounts

 

/dev/pts/*:

c--------- 1 root root 5, 2 Nov 29 17:32 /dev/pts/ptmx

 

Without ACRN but with the same kernel (Terminal works), the content is the same.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Friday, March 6, 2020 11:21 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Regarding the terminal problem, can you check the content of /proc/mounts (to see if devpts is mounted) and also check the output of ‘ls -l /dev/pts/*’?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, March 5, 2020 5:01 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Xinjun and Geofrroy,

 

I've made more tests and found a combination of settings where mouse cursor is working well.

 

This doesn't work, kernel starts loading but crashes; I'm not sure what exactly happens because I only see kernel printouts stopping scrolling, while no errors are visible:

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"

 

If I modify just these two settings in the list above, that crashes too:

"i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"

 

This, however, works (found on a link provided by Geoffroy):

i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0

With these, at the login screen, depending on which desktop compositor I choose, this happens:

  • GNOME of Xorg (default) = bad flickering mouse
  • GNOME Flashback / Metacity = good mouse cursor
  • GNOME on Wayland = good mouse cursor
  • Weston = mouse ok, but I see only Terminal icon, and even that won't start? perhaps I don't know how to use it

In all 4 variations, Terminal doesn't work.

 

Terminal settings:

$ uname -r
4.19.94-PKT-200203T060100Z-00001-gb288780f868f

 

$ ls -l /usr/lib/modules

total 16

drwxrwxrwx 3 root root 4096 Feb 26 18:34 4.19.94-PKT-200203T060100Z-00001-gb288780f868f /* my customized kernel, with igb driver enabled */

drwxr-xr-x 3 root root 4096 Feb 26 13:29 4.19.97-104.iot-lts2018-sos /* default ACRN kernel */

drwxr-xr-x 3 root root 4096 Feb 25 16:34 5.5.6-914.native /* Clear Linux kernel */

drwxr-xr-x 3 root root 4096 Mar  3 13:45 5.5.7-916.native /* another Clear Linux kernel, before I remembered I should disable auto-updates */

 

$ sudo cat /sys/kernel/debug/dri/0/i915_display_info

Password:

CRTC info

---------

CRTC 44: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24

        fb: 93, pos: 0x0, size: 1920x1080

        encoder 57: type: DDI B, connectors:

                connector 58: type: DP-1, status: connected, mode:

                id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

        No cursor plane available on this platform

        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0

        --Plane id 29: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)

        --Plane id 34: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        --Plane id 39: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        underrun reporting: cpu=yes pch=yes

CRTC 50: pipe: B, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

 

Connector info

--------------

connector 58: type DP-1, status: connected

        name:

        physical dimensions: 480x270mm

        subpixel order: Unknown

        CEA rev: 0

        DPCD rev: 11

        audio support: no

        DP branch device present: no

        modes:

                id 77:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

                id 80:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse 1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5

                id 85:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 79:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 78:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse 1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5

                id 86:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse 1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5

                id 87:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa

                id 88:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5

                id 81:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5

                id 82:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa

                id 83:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa

                id 84:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6

connector 68: type HDMI-A-1, status: disconnected

        audio support: no

        modes:

I've attached a screenshot. "Relaunch" doesn't help and neither do any of the settings. It's the same if I start if from the menu, or with ctrl+alt+t.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Xinyun Liu via Lists.Projectacrn.Org <xinyun.liu=intel.com@...>
Sent: Thursday, March 5, 2020 6:35 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners ), which is a hack in kernel driver i915 display module.  To make it's work,  it requires both UOS and SOS has the correct kernel parameters.  And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)  and uos is Android.
here is  the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"

You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.

And after switch to kbl/whl nuc platform, things changed.  As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor.  We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design.  The cursor plane could be used by App who explicity claimed.
2. Pipe A.  Currently we focus on WaaG (Windows  as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111" in SOS to let SOS use pipe B or others.  Then UOS and SOS should both have display output now but has some limitations.  Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting.  The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.

Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output. 

Thanks,
Xinyun


Geoffroy Van Cutsem
 

Hi Dubravko,

 

Can you check (paste) the actual content of /proc/mounts, I want to make sure that devpts is mounted under /dev/pts in both cases.

 

When you checked the output of ‘ls -l /dev/pts/*’ in the config where the terminal works, did you run that from a terminal or a console (or a serial port connection)?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Monday, March 9, 2020 4:09 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

With ACRN (Terminal doesn't work):

 

/proc/mounts:

lrwxrwxrwx 1 root root 11 Nov 29 17:32 /proc/mounts -> self/mounts

 

/dev/pts/*:

c--------- 1 root root 5, 2 Nov 29 17:32 /dev/pts/ptmx

 

Without ACRN but with the same kernel (Terminal works), the content is the same.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Friday, March 6, 2020 11:21 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Regarding the terminal problem, can you check the content of /proc/mounts (to see if devpts is mounted) and also check the output of ‘ls -l /dev/pts/*’?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, March 5, 2020 5:01 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Xinjun and Geofrroy,

 

I've made more tests and found a combination of settings where mouse cursor is working well.

 

This doesn't work, kernel starts loading but crashes; I'm not sure what exactly happens because I only see kernel printouts stopping scrolling, while no errors are visible:

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"

 

If I modify just these two settings in the list above, that crashes too:

"i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"

 

This, however, works (found on a link provided by Geoffroy):

i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0

With these, at the login screen, depending on which desktop compositor I choose, this happens:

  • GNOME of Xorg (default) = bad flickering mouse
  • GNOME Flashback / Metacity = good mouse cursor
  • GNOME on Wayland = good mouse cursor
  • Weston = mouse ok, but I see only Terminal icon, and even that won't start? perhaps I don't know how to use it

In all 4 variations, Terminal doesn't work.

 

Terminal settings:

$ uname -r
4.19.94-PKT-200203T060100Z-00001-gb288780f868f

 

$ ls -l /usr/lib/modules

total 16

drwxrwxrwx 3 root root 4096 Feb 26 18:34 4.19.94-PKT-200203T060100Z-00001-gb288780f868f /* my customized kernel, with igb driver enabled */

drwxr-xr-x 3 root root 4096 Feb 26 13:29 4.19.97-104.iot-lts2018-sos /* default ACRN kernel */

drwxr-xr-x 3 root root 4096 Feb 25 16:34 5.5.6-914.native /* Clear Linux kernel */

drwxr-xr-x 3 root root 4096 Mar  3 13:45 5.5.7-916.native /* another Clear Linux kernel, before I remembered I should disable auto-updates */

 

$ sudo cat /sys/kernel/debug/dri/0/i915_display_info

Password:

CRTC info

---------

CRTC 44: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24

        fb: 93, pos: 0x0, size: 1920x1080

        encoder 57: type: DDI B, connectors:

                connector 58: type: DP-1, status: connected, mode:

                id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

        No cursor plane available on this platform

        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0

        --Plane id 29: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)

        --Plane id 34: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        --Plane id 39: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        underrun reporting: cpu=yes pch=yes

CRTC 50: pipe: B, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

 

Connector info

--------------

connector 58: type DP-1, status: connected

        name:

        physical dimensions: 480x270mm

        subpixel order: Unknown

        CEA rev: 0

        DPCD rev: 11

        audio support: no

        DP branch device present: no

        modes:

                id 77:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

                id 80:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse 1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5

                id 85:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 79:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 78:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse 1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5

                id 86:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse 1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5

                id 87:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa

                id 88:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5

                id 81:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5

                id 82:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa

                id 83:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa

                id 84:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6

connector 68: type HDMI-A-1, status: disconnected

        audio support: no

        modes:

I've attached a screenshot. "Relaunch" doesn't help and neither do any of the settings. It's the same if I start if from the menu, or with ctrl+alt+t.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Xinyun Liu via Lists.Projectacrn.Org <xinyun.liu=intel.com@...>
Sent: Thursday, March 5, 2020 6:35 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners ), which is a hack in kernel driver i915 display module.  To make it's work,  it requires both UOS and SOS has the correct kernel parameters.  And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)  and uos is Android.
here is  the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"

You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.

And after switch to kbl/whl nuc platform, things changed.  As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor.  We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design.  The cursor plane could be used by App who explicity claimed.
2. Pipe A.  Currently we focus on WaaG (Windows  as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111" in SOS to let SOS use pipe B or others.  Then UOS and SOS should both have display output now but has some limitations.  Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting.  The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.

Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output. 

Thanks,
Xinyun


Dubravko Moravski | Exor Embedded S.r.l. <dubravko.moravski@...>
 

Hi Geoffroy,

With ACRN (Terminal doesn't work):

/proc/mounts:
lrwxrwxrwx 1 root root 11 Nov 29 17:32 /proc/mounts -> self/mounts

/dev/pts/*:
c--------- 1 root root 5, 2 Nov 29 17:32 /dev/pts/ptmx

Without ACRN but with the same kernel (Terminal works), the content is the same.

Regards,
Dubravko


Dubravko Moravski
SW engineering
Exor Embedded S.r.l.
p: +38 512455659  m: +38 5915402413
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy
From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Friday, March 6, 2020 11:21 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
 

Regarding the terminal problem, can you check the content of /proc/mounts (to see if devpts is mounted) and also check the output of ‘ls -l /dev/pts/*’?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, March 5, 2020 5:01 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Xinjun and Geofrroy,

 

I've made more tests and found a combination of settings where mouse cursor is working well.

 

This doesn't work, kernel starts loading but crashes; I'm not sure what exactly happens because I only see kernel printouts stopping scrolling, while no errors are visible:

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"

 

If I modify just these two settings in the list above, that crashes too:

"i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"

 

This, however, works (found on a link provided by Geoffroy):

i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0

With these, at the login screen, depending on which desktop compositor I choose, this happens:

  • GNOME of Xorg (default) = bad flickering mouse
  • GNOME Flashback / Metacity = good mouse cursor
  • GNOME on Wayland = good mouse cursor
  • Weston = mouse ok, but I see only Terminal icon, and even that won't start? perhaps I don't know how to use it

In all 4 variations, Terminal doesn't work.

 

Terminal settings:

$ uname -r
4.19.94-PKT-200203T060100Z-00001-gb288780f868f

 

$ ls -l /usr/lib/modules

total 16

drwxrwxrwx 3 root root 4096 Feb 26 18:34 4.19.94-PKT-200203T060100Z-00001-gb288780f868f /* my customized kernel, with igb driver enabled */

drwxr-xr-x 3 root root 4096 Feb 26 13:29 4.19.97-104.iot-lts2018-sos /* default ACRN kernel */

drwxr-xr-x 3 root root 4096 Feb 25 16:34 5.5.6-914.native /* Clear Linux kernel */

drwxr-xr-x 3 root root 4096 Mar  3 13:45 5.5.7-916.native /* another Clear Linux kernel, before I remembered I should disable auto-updates */

 

$ sudo cat /sys/kernel/debug/dri/0/i915_display_info

Password:

CRTC info

---------

CRTC 44: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24

        fb: 93, pos: 0x0, size: 1920x1080

        encoder 57: type: DDI B, connectors:

                connector 58: type: DP-1, status: connected, mode:

                id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

        No cursor plane available on this platform

        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0

        --Plane id 29: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)

        --Plane id 34: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        --Plane id 39: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        underrun reporting: cpu=yes pch=yes

CRTC 50: pipe: B, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

 

Connector info

--------------

connector 58: type DP-1, status: connected

        name:

        physical dimensions: 480x270mm

        subpixel order: Unknown

        CEA rev: 0

        DPCD rev: 11

        audio support: no

        DP branch device present: no

        modes:

                id 77:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

                id 80:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse 1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5

                id 85:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 79:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 78:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse 1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5

                id 86:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse 1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5

                id 87:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa

                id 88:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5

                id 81:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5

                id 82:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa

                id 83:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa

                id 84:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6

connector 68: type HDMI-A-1, status: disconnected

        audio support: no

        modes:

I've attached a screenshot. "Relaunch" doesn't help and neither do any of the settings. It's the same if I start if from the menu, or with ctrl+alt+t.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Xinyun Liu via Lists.Projectacrn.Org <xinyun.liu=intel.com@...>
Sent: Thursday, March 5, 2020 6:35 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners ), which is a hack in kernel driver i915 display module.  To make it's work,  it requires both UOS and SOS has the correct kernel parameters.  And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)  and uos is Android.
here is  the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"

You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.

And after switch to kbl/whl nuc platform, things changed.  As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor.  We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design.  The cursor plane could be used by App who explicity claimed.
2. Pipe A.  Currently we focus on WaaG (Windows  as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111" in SOS to let SOS use pipe B or others.  Then UOS and SOS should both have display output now but has some limitations.  Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting.  The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.

Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output. 

Thanks,
Xinyun


Geoffroy Van Cutsem
 

Regarding the terminal problem, can you check the content of /proc/mounts (to see if devpts is mounted) and also check the output of ‘ls -l /dev/pts/*’?

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, March 5, 2020 5:01 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Xinjun and Geofrroy,

 

I've made more tests and found a combination of settings where mouse cursor is working well.

 

This doesn't work, kernel starts loading but crashes; I'm not sure what exactly happens because I only see kernel printouts stopping scrolling, while no errors are visible:

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"

 

If I modify just these two settings in the list above, that crashes too:

"i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"

 

This, however, works (found on a link provided by Geoffroy):

i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0

With these, at the login screen, depending on which desktop compositor I choose, this happens:

  • GNOME of Xorg (default) = bad flickering mouse
  • GNOME Flashback / Metacity = good mouse cursor
  • GNOME on Wayland = good mouse cursor
  • Weston = mouse ok, but I see only Terminal icon, and even that won't start? perhaps I don't know how to use it

In all 4 variations, Terminal doesn't work.

 

Terminal settings:

$ uname -r
4.19.94-PKT-200203T060100Z-00001-gb288780f868f

 

$ ls -l /usr/lib/modules

total 16

drwxrwxrwx 3 root root 4096 Feb 26 18:34 4.19.94-PKT-200203T060100Z-00001-gb288780f868f /* my customized kernel, with igb driver enabled */

drwxr-xr-x 3 root root 4096 Feb 26 13:29 4.19.97-104.iot-lts2018-sos /* default ACRN kernel */

drwxr-xr-x 3 root root 4096 Feb 25 16:34 5.5.6-914.native /* Clear Linux kernel */

drwxr-xr-x 3 root root 4096 Mar  3 13:45 5.5.7-916.native /* another Clear Linux kernel, before I remembered I should disable auto-updates */

 

$ sudo cat /sys/kernel/debug/dri/0/i915_display_info

Password:

CRTC info

---------

CRTC 44: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24

        fb: 93, pos: 0x0, size: 1920x1080

        encoder 57: type: DDI B, connectors:

                connector 58: type: DP-1, status: connected, mode:

                id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

        No cursor plane available on this platform

        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0

        --Plane id 29: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)

        --Plane id 34: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        --Plane id 39: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)

        underrun reporting: cpu=yes pch=yes

CRTC 50: pipe: B, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0

        underrun reporting: cpu=yes pch=yes

 

Connector info

--------------

connector 58: type DP-1, status: connected

        name:

        physical dimensions: 480x270mm

        subpixel order: Unknown

        CEA rev: 0

        DPCD rev: 11

        audio support: no

        DP branch device present: no

        modes:

                id 77:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

                id 80:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse 1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5

                id 85:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 79:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5

                id 78:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse 1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5

                id 86:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse 1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5

                id 87:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa

                id 88:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5

                id 81:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5

                id 82:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa

                id 83:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa

                id 84:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6

connector 68: type HDMI-A-1, status: disconnected

        audio support: no

        modes:

I've attached a screenshot. "Relaunch" doesn't help and neither do any of the settings. It's the same if I start if from the menu, or with ctrl+alt+t.

 

Regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Xinyun Liu via Lists.Projectacrn.Org <xinyun.liu=intel.com@...>
Sent: Thursday, March 5, 2020 6:35 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners ), which is a hack in kernel driver i915 display module.  To make it's work,  it requires both UOS and SOS has the correct kernel parameters.  And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)  and uos is Android.
here is  the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"

You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.

And after switch to kbl/whl nuc platform, things changed.  As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor.  We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design.  The cursor plane could be used by App who explicity claimed.
2. Pipe A.  Currently we focus on WaaG (Windows  as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111" in SOS to let SOS use pipe B or others.  Then UOS and SOS should both have display output now but has some limitations.  Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting.  The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.

Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output. 

Thanks,
Xinyun


Xinyun Liu
 

Hi Dubravko,

I am using acrn-kernel (https://github.com/projectacrn/acrn-kernel) on a kabylake nuc.   The cursor has some flicker issue with X. But if use weston, it's good. both has terminal. 

sos:  clearlinux  with 4.19.94-uefi-sos+             (b288780f868fa3b4a6b5fdae997c00a2c7314dd7)
uos:  ubuntu with 4.19.68-uos+             (f92a20f4a84b7aed25d581e4c061431dc06a98cc)

sos:
root=PARTUUID=7bd1404d-89ef-45a8-8635-227d5b02546a console=tty0 console=ttyS0,115200n8 rw rootwait loglevel=8 no_timer_check consoleblank=0 i915.avail_planes_per_pipe=0x0F i915.domain_plane_owners=0x11110000 i915.domain_scaler_owner=0x1100 i915.enable_guc_loading=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1 i915.enable_guc=0 i915.enable_context_restore=0 hvlog=2M@0x1FE00000  nox2apic drm.debug=0x6 dyndbg="file *gvt* -p" nokaslr i915.enable_initial_modeset=0
uos: 
BOOT_IMAGE=/boot/bzImage-v4.19 root=UUID=c4fd12f3-2237-4d7c-955a-ee5370888327 ro console=tty0 console=ttyS0,115200 i915.avail_planes_per_pipe=0x000f00 use_nuclear_flip=1 i915.enable_guc_submission=0 i915.enable_guc=0 drm.debug=6

The display solution has limitations but works for the specific scenario. To make it more univesal and for more scenarios,  we need to revist the design and improve it. It's in my todo list.


Dubravko Moravski | Exor Embedded S.r.l. <dubravko.moravski@...>
 

Hi Xinjun and Geofrroy,

I've made more tests and found a combination of settings where mouse cursor is working well.

This doesn't work, kernel starts loading but crashes; I'm not sure what exactly happens because I only see kernel printouts stopping scrolling, while no errors are visible:
sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"

If I modify just these two settings in the list above, that crashes too:
"i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111"

This, however, works (found on a link provided by Geoffroy):
i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0
With these, at the login screen, depending on which desktop compositor I choose, this happens:
  • GNOME of Xorg (default) = bad flickering mouse
  • GNOME Flashback / Metacity = good mouse cursor
  • GNOME on Wayland = good mouse cursor
  • Weston = mouse ok, but I see only Terminal icon, and even that won't start? perhaps I don't know how to use it
In all 4 variations, Terminal doesn't work.

Terminal settings:
$ uname -r
4.19.94-PKT-200203T060100Z-00001-gb288780f868f

$ ls -l /usr/lib/modules
total 16
drwxrwxrwx 3 root root 4096 Feb 26 18:34 4.19.94-PKT-200203T060100Z-00001-gb288780f868f /* my customized kernel, with igb driver enabled */
drwxr-xr-x 3 root root 4096 Feb 26 13:29 4.19.97-104.iot-lts2018-sos /* default ACRN kernel */
drwxr-xr-x 3 root root 4096 Feb 25 16:34 5.5.6-914.native /* Clear Linux kernel */
drwxr-xr-x 3 root root 4096 Mar  3 13:45 5.5.7-916.native /* another Clear Linux kernel, before I remembered I should disable auto-updates */

$ sudo cat /sys/kernel/debug/dri/0/i915_display_info
Password:
CRTC info
---------
CRTC 44: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24
        fb: 93, pos: 0x0, size: 1920x1080
        encoder 57: type: DDI B, connectors:
                connector 58: type: DP-1, status: connected, mode:
                id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5
        No cursor plane available on this platform
        num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0
        --Plane id 29: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)
        --Plane id 34: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)
        --Plane id 39: type=OVL, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)
        underrun reporting: cpu=yes pch=yes
CRTC 50: pipe: B, active=no, (size=0x0), dither=no, bpp=0
        underrun reporting: cpu=yes pch=yes
CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0
        underrun reporting: cpu=yes pch=yes

Connector info
--------------
connector 58: type DP-1, status: connected
        name:
        physical dimensions: 480x270mm
        subpixel order: Unknown
        CEA rev: 0
        DPCD rev: 11
        audio support: no
        DP branch device present: no
        modes:
                id 77:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5
                id 80:"1600x900" freq 60 clock 108000 hdisp 1600 hss 1624 hse 1704 htot 1800 vdisp 900 vss 901 vse 904 vtot 1000 type 0x40 flags 0x5
                id 85:"1280x1024" freq 75 clock 135000 hdisp 1280 hss 1296 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5
                id 79:"1280x1024" freq 60 clock 108000 hdisp 1280 hss 1328 hse 1440 htot 1688 vdisp 1024 vss 1025 vse 1028 vtot 1066 type 0x40 flags 0x5
                id 78:"1152x864" freq 75 clock 108000 hdisp 1152 hss 1216 hse 1344 htot 1600 vdisp 864 vss 865 vse 868 vtot 900 type 0x40 flags 0x5
                id 86:"1024x768" freq 75 clock 78750 hdisp 1024 hss 1040 hse 1136 htot 1312 vdisp 768 vss 769 vse 772 vtot 800 type 0x40 flags 0x5
                id 87:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa
                id 88:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5
                id 81:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5
                id 82:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa
                id 83:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa
                id 84:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6
connector 68: type HDMI-A-1, status: disconnected
        audio support: no
        modes:
I've attached a screenshot. "Relaunch" doesn't help and neither do any of the settings. It's the same if I start if from the menu, or with ctrl+alt+t.

Regards,
Dubravko


Dubravko Moravski
SW engineering
Exor Embedded S.r.l.
p: +38 512455659  m: +38 5915402413
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy
From: acrn-users@... <acrn-users@...> on behalf of Xinyun Liu via Lists.Projectacrn.Org <xinyun.liu=intel.com@...>
Sent: Thursday, March 5, 2020 6:35 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
 
Hi Dubravko,

For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(
https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners ), which is a hack in kernel driver i915 display module.  To make it's work,  it requires both UOS and SOS has the correct kernel parameters.  And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)  and uos is Android.
here is  the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"

You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.

And after switch to kbl/whl nuc platform, things changed.  As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor.  We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design.  The cursor plane could be used by App who explicity claimed.
2. Pipe A.  Currently we focus on WaaG (Windows  as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111" in SOS to let SOS use pipe B or others.  Then UOS and SOS should both have display output now but has some limitations.  Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting.  The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.

Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output. 

Thanks,
Xinyun


Xinyun Liu
 

Hi Dubravko,

For cursor invisible issue, here is my understanding:
Previously, acrngt display solution is based on plane restriction feature(
https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#i915-avail-planes-owners ), which is a hack in kernel driver i915 display module.  To make it's work,  it requires both UOS and SOS has the correct kernel parameters.  And it does work well for it's original use case: sos is clear linux with IAS ( Intel modified weston for IVI)  and uos is Android.
here is  the sample for apl_mrb: (https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/samples/apl-mrb/launch_uos.sh)

sos:  "i915.enable_initial_modeset=1 video=DP-1:d video=DP-2:d i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011011100000 i915.enable_guc_loadin  g=0 i915.enable_guc_submission=0 i915.enable_preemption=1 i915.context_priority_mode=2 i915.enable_gvt=1"
uos: "i915.enable_rc6=1 i915.enable_fbc=0 i915.enable_guc_loading=0 i915.avail_planes_per_pipe=0x070F00"

You can try above setting for your configuration: clearlinux + other linux. Make sure clearlinux has the duplicated mornitor setting.

And after switch to kbl/whl nuc platform, things changed.  As the default desktop env may be changed to X windows, there are some issues. For example
1. Cursor.  We haven't enabled H/W cursor plane in SOS during mode setting stage because it's not implemented according the original design.  The cursor plane could be used by App who explicity claimed.
2. Pipe A.  Currently we focus on WaaG (Windows  as a guest). Windows (and vanilar linux) kernel doesn't has plane restriction feature, and they use pipe A as the default/first output pipe. So we have to set "i915.avail_planes_per_pipe=0x000F00 i915.domain_plane_owners=0x0000001111" in SOS to let SOS use pipe B or others.  Then UOS and SOS should both have display output now but has some limitations.  Some App in SOS also select pipeA as the default output, so there is problems.
3. Mode setting.  The assumption is mode setting is done in SOS and no one should touch the pipe/crtc settings. But X and other app may explictly change the mode and cause UOS display issue.

Above are the issues I have met if SOS has a desktop environment. But for RT env, the requirement is different. Only UOS needs graphics UI and others has no output. 

Thanks,
Xinyun


Geoffroy Van Cutsem
 

Hi Dubravko,

 

Regarding 3) (ACRN with GVT-g settings), is this with the kernel you have built yourself (from https:/github.com/projectacrn/acrn-kernel)?

 

I have never seen the PTY error myself, can you provide the following info:

$ uname -r

$ ls -l /usr/lib/modules

# cat /sys/kernel/debug/dri/0/i915_display_info

 

If I remember correctly, the changes you made are overwritten by the driver (see https://github.com/projectacrn/acrn-kernel/blob/master/drivers/gpu/drm/i915/intel_display.c#L15498-L15508). I think they do this because there could be some issues related to the initialization of monitors if the Service VM does not own a plane in each pipe… or something like that (I hope if there are GVT-g experts on the mailing list that they will correct me if this is wrong 😉)

 

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Wednesday, March 4, 2020 7:17 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

I've tried your recommendations, they partially work but not quite. I did already have acrn.conf, some tool must have generated it at some point.

 

I have three different situations, depending on how I start the system:

 

1) Regular Clear Linux - mouse works normally; and Terminal too.

 

2) ACRN without GVT settings - mouse is invisible; Terminal works normally.

 

3) ACRN with GVT settings - mouse is visible but it's flickering and duplicated several times (in all the assigned planes?); Terminal now doesn't work, the application window opens but it's unusable and it shows this message:

"There was an error creating the child process for this terminal.

Failed to open PTY: Permission denied"

Other applications, e.g. file browser and Firefox, do work.

I've also tried changing avail_planes_per_pipe to 0x00000F, it seemed more clean, if I've understood the documentation correctly. This changed nothing, except maybe reduced the flickering a bit.

 

All the tests were done without launching UOS. I'm using display port output. Our board also has eDP and HDMI outputs, which are all verified to work but aren't connected to a display at the moment.

 

Best regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Wednesday, March 4, 2020 4:33 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

 

That’s most likely the problem then, GVT-g needs to be specifically enabled. These command-line parameters are the default ones from Clear Linux. Do you have an acrn.conf [1] file on your ESP? If not, I’d recommend you add one and make it the default boot entry (modify /boot/loader/loader.conf after mounting the ESP under /boot).

 

If you look inside that file, you’ll find a number of i915 that are set for GVT (i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0), and if you’re curious as to what they mean, they are documented here: https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#intel-gvt-g-acrngt-parameters

 

[1] https://github.com/projectacrn/acrn-hypervisor/blob/master/misc/efi-stub/clearlinux/acrn.conf

 

Hope this helps!
Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Wednesday, March 4, 2020 2:14 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

SOS command line parameters are:

initrd=\EFI\org.clearlinux\freestanding-00-intel-ucode.cpio initrd=\EFI\org.clearlinux\freestanding-i915-firmware.cpio.xz root=PARTUUID=ef5fabcd-7773-447d-ad51-0fb2b6522c90 quiet console=tty0 console=ttyS0,115200n8 cryptomgr.notests init=/usr/bin/initra-desktop initcall_debug intel_iommu=igfx_off kvm-intel.nested=1 no_timer_check noreplace-smp page_alloc.shuffle=1 rcu_nocbs=0-64 rcupdate.rcu_expedited=1 rootfstype=ext4,btrfs,xfs tsc=reliable rw ignore_loglevel earlyprintk=serial,ttyS0,115200n8,keep

 

I've searched for all config parameters containing 915_GVT substring, CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_ACRN are on, CONFIG_DRM_I915_GVT_KVMGT is off.

 

Regard,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Tuesday, March 3, 2020 10:33 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Can you send your kernel command-line parameters (in the SOS): $ cat /proc/cmdline?

 

We should also check in the kernel config (/proc/config.gz) in case GVT got inadvertently turned off (CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_ACRN) when you reconfigured and recompiled your kernel.

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 3, 2020 7:52 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Zide and Geoffroy,

 

Yes, igb i211 driver now works on SOS, and UOS can access the network too, without changing any setting or modifying the kernel. Usually I would suspect some hardware issue, but we haven't seen any issues with PCIe so far on the board, so this is puzzling.

 

Invisible mouse cursor, it works on regular Clear Linux with the same SOS kernel (that I've built, with igb driver), and the same rootfs (/dev/mmcblk1p3, and we have only one MMC device so it can't be confused with anything else).

"sudo dmesg | grep -i mouse" produces identical output when it's visible and invisible, and nothing looks suspicious.

 

It looks like I don't need GVT, but just in case it's simple to fix, I've checked dmesg (no mentions of it) and /sys/kernel/ directory. Here, gvt/ subfolder is missing, and UOS launching script complains about that. Do I just need to enable some driver or start some service to get it?

 

Best regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
Sent: Tuesday, March 3, 2020 5:40 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

I'm not familiar with GVT, and let other guys to comment on this topic.
You meant lgb i211 driver is working on SOS now? I'm sure it has nothing to do with acrn-dm which has impacts on UOS only.

The invisible mouse cursor issue, you meant it works on regular (native) Linux with same SOS kernel? Did you use the same
rootfs with SOS? I feel it more likely a rootfs issue and may not related Hypervisor. We need to look at Hypervisor only
when SOS Kernel + rootfs work on native Linux but not on top of ACRN.

Best Regards,
Zide


On 3/3/20 5:41 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
> Hi Zide,
>
> Your advice was helpful again. I have recompiled acrn-dm, edited the launch script, and now UOS works. I'm not exactly
> sure why, but Ethernet works too! I'm using the same board and the same kernel as few days ago. Does acrn-dm somehow
> affect it?
>
> I have changed the launch script like this:
>
>     acrn-dm -A -m $mem_size -s 0:0,hostbridge \
>        -s 5,virtio-console,@stdio:stdio_port \
>        -s 6,virtio-hyper_dmabuf \
>        -s 3,virtio-blk,/home/clear/work/uos/uos.img \
>        -s 4,virtio-net,tap0 \
>        -s 7,virtio-rnd \
>        --ovmf /usr/share/acrn/bios/OVMF.fd \
>        $pm_channel $pm_by_vuart $pm_vuart_node \
>        $logger_setting \
>        --mac_seed $mac_seed \
>        $vm_name
>     }
>
> Apparently it doesn't like this line, now commented out:
>
>     #  -s 2,pci-gvt -G "$2" \
>
> This happens if it's enabled:
>
>     vm_init_vdevs
>     polling 38...
>     Listening 38...
>     pci init hostbridge
>     pci init lpc
>     pci init pci-gvt
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>     GVT: init failed
>     pci pci-gvt init failed
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>     Stop listening 38...
>     Stop polling 38...
>     Unable to init vdev (2)
>
> Reading the documentation, I'm not precisely sure what GVT does. Would it be beneficial to have it for using more display
> outputs simultaneously and drawing/compositing 2D graphics?
>
> About using the same kernel as acrn in regular Linux and testing Ethernet and the mouse, both work in regular Linux. In
> acrn, the mouse is still functional, but invisible (it's a plain Logitech USB mouse, nothing special about it).
>
> Best regards,
> Dubravko
>
>
> *Dubravko Moravski*
> /SW engineering/
> *Exor Embedded S.r.l.*
> p:     +38 512455659 <tel:+38 512455659>  m:+38 5915402413 <tel:+38 5915402413>
> a:     Slavonska avenija, 50, Zagreb, Croatia, 10000
> w:     exorint.com <https://exorint.com/>
>
>       
>
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
> --------------------------------------------------------------------------------------------------------------------------
> *From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via
> Lists.Projectacrn.Org <zide.chen=intel.com@...>
> *Sent:* Saturday, February 29, 2020 9:04 AM
> *To:* acrn-users@... <acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same
> acrn tree to avoid any version compatibility issue.
>
> $ cd acrn-hypervisor
>
> $ make devicemodel
>
> $ scp build/devicemodel/acrn-dm target:/usr/bin
>
> For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you
> may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of
> initializing that device.
>
> Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems
> not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.
>
> Best Regards,
>
> Zide
>
> *From:* acrn-users@... <acrn-users@...> *On Behalf Of *Dubravko Moravski | Exor
> Embedded S.r.l.
> *Sent:* Friday, February 28, 2020 9:57 AM
> *To:* acrn-users@...
> *Cc:* Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui
> <conghui.chen@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi everyone,
>
> I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to
> the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical,
> "PCIe link lost". If you have any other ideas for me to try, please let me know.
>
> Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the
> acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything
> related to hardware acceleration. If you have any other ideas...
>
> Unfortunately I'm also having issues launching User OS. I've followed instructions from here:
> https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it
> up goes well, but in the end it fails to launch:
>
>     clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh
>
>     cpu1 online=1
>
>     cpu2 online=1
>
>     cpu3 online=1
>
>     cat: '/sys/class/net/e*/address': No such file or directory
>
>     passed gvt-g optargs low_gm 64, high_gm 448, fence 8
>
>     SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000
>
>     pm by vuart node-index = 0
>
>     logger: name=console, level=4
>
>     logger: name=kmsg, level=3
>
>     logger: name=disk, level=5
>
>     vm_create: vm1
>
>     VHM api version 1.0
>
>     vm_setup_memory: size=0x80000000
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643
>
>     level 0 free/need pages:0/1 page size:0x200000
>
>     level 1 free/need pages:0/2 page size:0x40000000
>
>     to reserve more free pages:
>
>     to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
>
>     to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
>
>     now enough free pages are reserved!
>
>     try to setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     total_size 0x180000000
>
>     mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000
>
>     mmap 0x80000000@0x7fdbc0000000
>
>     touch 2 pages with pagesz 0x40000000
>
>     mmap 0x200000@0x7fdcbfe00000
>
>     touch 1 pages with pagesz 0x200000
>
>     really setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     vm_init_vdevs
>
>     polling 38...
>
>     Listening 38...
>
>     pci init hostbridge
>
>     pci init lpc
>
>     pci init pci-gvt
>
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>
>     GVT: init failed
>
>     pci pci-gvt init failed
>
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>
>     Stop listening 38...
>
>     Stop polling 38...
>
>     Unable to init vdev (2)
>
> I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in
> configuring ACRN or UOS, I'll re-check what I have done.
>
> Best regards,
>
> Dubravko
>
> *Dubravko Moravski*
>
> /SW engineering/
>
> *Exor Embedded S.r.l.*
>
> p:
>
>       
>
> +38 512455659 <tel:+38%20512455659>  m: +38 5915402413 <tel:+38%205915402413>
>
> a:
>
>       
>
> Slavonska avenija, 50, Zagreb, Croatia, 10000
>
> w:
>
>       
>
> exorint.com <https://exorint.com/>
>
>       
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
>
> --------------------------------------------------------------------------------------------------------------------------
>
> *From:*acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> on behalf of Shuo A Liu via Lists.Projectacrn.Org
> <shuo.a.liu=intel.com@... <mailto:shuo.a.liu=intel.com@...>>
> *Sent:* Friday, February 28, 2020 9:41 AM
> *To:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>>
> *Cc:* Wang, Hongbo <hongbo.wang@... <mailto:hongbo.wang@...>>; Wang, Yu1 <yu1.wang@...
> <mailto:yu1.wang@...>>; Li, Fei1 <fei1.li@... <mailto:fei1.li@...>>; Chen, Conghui
> <conghui.chen@... <mailto:conghui.chen@...>>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help
> check if your HV include it?
>
> commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379
>
> Author: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> Date:   Thu Dec 5 22:51:06 2019 +0800
>
>      hv: vpci: trap PCIe ECAM access for SOS
>
>      SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this
>
>      access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched
>
>      VM trap PCIe ECAM access in DM).
>
>      Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through
>
>      platform hide PCI devices by BIOS to SOS.
>
>      Tracked-On: #3475
>
>      Signed-off-by: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> You can have a quick try to revert it firstly if it is included.
>
> Thanks
>
> shuo
>
> *From:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> *On Behalf Of *Dubravko Moravski | Exor Embedded S.r.l.
> *Sent:* Thursday, February 27, 2020 02:19
> *To:* acrn-users@... <mailto:acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Zide,
>
> Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.
>
> I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the
> kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
> The new kernel mostly works, however igb driver doesn't (and we really need the network):
>
>     clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb
>
>     [    3.708554] calling  igb_init_module+0x0/0x4d @ 1
>
>     [    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
>
>     [    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): *PCIe link lost*
>
>     [    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.
>
>     [    7.504456] igb 0000:04:00.0: Invalid MAC Address
>
>     [    7.505779] igb: probe of 0000:04:00.0 failed with error -5
>
>     [    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs
>
> The "PCIe link lost" message originates in igb_main.c, approx line 740:
>
>     u32 igb_rd32(struct e1000_hw *hw, u32 reg)
>
>     {
>
>              struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);
>
>              u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
>
>              u32 value = 0;
>
>              if (E1000_REMOVED(hw_addr))
>
>                      return ~value;
>
>              value = readl(&hw_addr[reg]);
>
>              /* reads should not return all F's */
>
>              if (!(~value) && (!reg || !(~readl(hw_addr)))) {
>
>                      struct net_device *netdev = igb->netdev;
>
>                      hw->hw_addr = NULL;
>
>                      netdev_err(netdev, "*PCIe link lost*\n");
>
>              }
>
>              return value;
>
>     }
>
> I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible
> level, looking from the software side of things, so it doesn't look like I could do much debugging here.
>
> In regular Clear Linux, the driver consistently works and there are never any link issues:
>
>     clear@clr-sos-guest~ $ sudo dmesg | grep -i igb
>
>     Password:
>
>     [    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317
>
>     [    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
>
>     [    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    4.519304] igb 0000:04:00.0: added PHC on eth0
>
>     [    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection
>
>     [    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84
>
>     [    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF
>
>     [    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
>
>     [    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs
>
>     [    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0
>
>     [    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>
> So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?
>
> Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with
> the same file system and GUI and system settings, the mouse works and the cursor is visible.
>
> Best regards,
>
> Dubravko
>
>


Dubravko Moravski | Exor Embedded S.r.l. <dubravko.moravski@...>
 

Hi Geoffroy,

I've tried your recommendations, they partially work but not quite. I did already have acrn.conf, some tool must have generated it at some point.

I have three different situations, depending on how I start the system:

1) Regular Clear Linux - mouse works normally; and Terminal too.

2) ACRN without GVT settings - mouse is invisible; Terminal works normally.

3) ACRN with GVT settings - mouse is visible but it's flickering and duplicated several times (in all the assigned planes?); Terminal now doesn't work, the application window opens but it's unusable and it shows this message:
"There was an error creating the child process for this terminal.
Failed to open PTY: Permission denied"
Other applications, e.g. file browser and Firefox, do work.
I've also tried changing avail_planes_per_pipe to 0x00000F, it seemed more clean, if I've understood the documentation correctly. This changed nothing, except maybe reduced the flickering a bit.

All the tests were done without launching UOS. I'm using display port output. Our board also has eDP and HDMI outputs, which are all verified to work but aren't connected to a display at the moment.

Best regards,
Dubravko


Dubravko Moravski
SW engineering
Exor Embedded S.r.l.
p: +38 512455659  m: +38 5915402413
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy
From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Wednesday, March 4, 2020 4:33 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
 

Hi Dubravko,

 

That’s most likely the problem then, GVT-g needs to be specifically enabled. These command-line parameters are the default ones from Clear Linux. Do you have an acrn.conf [1] file on your ESP? If not, I’d recommend you add one and make it the default boot entry (modify /boot/loader/loader.conf after mounting the ESP under /boot).

 

If you look inside that file, you’ll find a number of i915 that are set for GVT (i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0), and if you’re curious as to what they mean, they are documented here: https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#intel-gvt-g-acrngt-parameters

 

[1] https://github.com/projectacrn/acrn-hypervisor/blob/master/misc/efi-stub/clearlinux/acrn.conf

 

Hope this helps!
Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Wednesday, March 4, 2020 2:14 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

SOS command line parameters are:

initrd=\EFI\org.clearlinux\freestanding-00-intel-ucode.cpio initrd=\EFI\org.clearlinux\freestanding-i915-firmware.cpio.xz root=PARTUUID=ef5fabcd-7773-447d-ad51-0fb2b6522c90 quiet console=tty0 console=ttyS0,115200n8 cryptomgr.notests init=/usr/bin/initra-desktop initcall_debug intel_iommu=igfx_off kvm-intel.nested=1 no_timer_check noreplace-smp page_alloc.shuffle=1 rcu_nocbs=0-64 rcupdate.rcu_expedited=1 rootfstype=ext4,btrfs,xfs tsc=reliable rw ignore_loglevel earlyprintk=serial,ttyS0,115200n8,keep

 

I've searched for all config parameters containing 915_GVT substring, CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_ACRN are on, CONFIG_DRM_I915_GVT_KVMGT is off.

 

Regard,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Tuesday, March 3, 2020 10:33 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Can you send your kernel command-line parameters (in the SOS): $ cat /proc/cmdline?

 

We should also check in the kernel config (/proc/config.gz) in case GVT got inadvertently turned off (CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_ACRN) when you reconfigured and recompiled your kernel.

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 3, 2020 7:52 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Zide and Geoffroy,

 

Yes, igb i211 driver now works on SOS, and UOS can access the network too, without changing any setting or modifying the kernel. Usually I would suspect some hardware issue, but we haven't seen any issues with PCIe so far on the board, so this is puzzling.

 

Invisible mouse cursor, it works on regular Clear Linux with the same SOS kernel (that I've built, with igb driver), and the same rootfs (/dev/mmcblk1p3, and we have only one MMC device so it can't be confused with anything else).

"sudo dmesg | grep -i mouse" produces identical output when it's visible and invisible, and nothing looks suspicious.

 

It looks like I don't need GVT, but just in case it's simple to fix, I've checked dmesg (no mentions of it) and /sys/kernel/ directory. Here, gvt/ subfolder is missing, and UOS launching script complains about that. Do I just need to enable some driver or start some service to get it?

 

Best regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
Sent: Tuesday, March 3, 2020 5:40 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

I'm not familiar with GVT, and let other guys to comment on this topic.
You meant lgb i211 driver is working on SOS now? I'm sure it has nothing to do with acrn-dm which has impacts on UOS only.

The invisible mouse cursor issue, you meant it works on regular (native) Linux with same SOS kernel? Did you use the same
rootfs with SOS? I feel it more likely a rootfs issue and may not related Hypervisor. We need to look at Hypervisor only
when SOS Kernel + rootfs work on native Linux but not on top of ACRN.

Best Regards,
Zide


On 3/3/20 5:41 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
> Hi Zide,
>
> Your advice was helpful again. I have recompiled acrn-dm, edited the launch script, and now UOS works. I'm not exactly
> sure why, but Ethernet works too! I'm using the same board and the same kernel as few days ago. Does acrn-dm somehow
> affect it?
>
> I have changed the launch script like this:
>
>     acrn-dm -A -m $mem_size -s 0:0,hostbridge \
>        -s 5,virtio-console,@stdio:stdio_port \
>        -s 6,virtio-hyper_dmabuf \
>        -s 3,virtio-blk,/home/clear/work/uos/uos.img \
>        -s 4,virtio-net,tap0 \
>        -s 7,virtio-rnd \
>        --ovmf /usr/share/acrn/bios/OVMF.fd \
>        $pm_channel $pm_by_vuart $pm_vuart_node \
>        $logger_setting \
>        --mac_seed $mac_seed \
>        $vm_name
>     }
>
> Apparently it doesn't like this line, now commented out:
>
>     #  -s 2,pci-gvt -G "$2" \
>
> This happens if it's enabled:
>
>     vm_init_vdevs
>     polling 38...
>     Listening 38...
>     pci init hostbridge
>     pci init lpc
>     pci init pci-gvt
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>     GVT: init failed
>     pci pci-gvt init failed
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>     Stop listening 38...
>     Stop polling 38...
>     Unable to init vdev (2)
>
> Reading the documentation, I'm not precisely sure what GVT does. Would it be beneficial to have it for using more display
> outputs simultaneously and drawing/compositing 2D graphics?
>
> About using the same kernel as acrn in regular Linux and testing Ethernet and the mouse, both work in regular Linux. In
> acrn, the mouse is still functional, but invisible (it's a plain Logitech USB mouse, nothing special about it).
>
> Best regards,
> Dubravko
>
>
> *Dubravko Moravski*
> /SW engineering/
> *Exor Embedded S.r.l.*
> p:     +38 512455659 <tel:+38 512455659>  m:+38 5915402413 <tel:+38 5915402413>
> a:     Slavonska avenija, 50, Zagreb, Croatia, 10000
> w:     exorint.com <https://exorint.com/>
>
>       
>
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
> --------------------------------------------------------------------------------------------------------------------------
> *From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via
> Lists.Projectacrn.Org <zide.chen=intel.com@...>
> *Sent:* Saturday, February 29, 2020 9:04 AM
> *To:* acrn-users@... <acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same
> acrn tree to avoid any version compatibility issue.
>
> $ cd acrn-hypervisor
>
> $ make devicemodel
>
> $ scp build/devicemodel/acrn-dm target:/usr/bin
>
> For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you
> may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of
> initializing that device.
>
> Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems
> not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.
>
> Best Regards,
>
> Zide
>
> *From:* acrn-users@... <acrn-users@...> *On Behalf Of *Dubravko Moravski | Exor
> Embedded S.r.l.
> *Sent:* Friday, February 28, 2020 9:57 AM
> *To:* acrn-users@...
> *Cc:* Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui
> <conghui.chen@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi everyone,
>
> I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to
> the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical,
> "PCIe link lost". If you have any other ideas for me to try, please let me know.
>
> Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the
> acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything
> related to hardware acceleration. If you have any other ideas...
>
> Unfortunately I'm also having issues launching User OS. I've followed instructions from here:
> https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it
> up goes well, but in the end it fails to launch:
>
>     clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh
>
>     cpu1 online=1
>
>     cpu2 online=1
>
>     cpu3 online=1
>
>     cat: '/sys/class/net/e*/address': No such file or directory
>
>     passed gvt-g optargs low_gm 64, high_gm 448, fence 8
>
>     SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000
>
>     pm by vuart node-index = 0
>
>     logger: name=console, level=4
>
>     logger: name=kmsg, level=3
>
>     logger: name=disk, level=5
>
>     vm_create: vm1
>
>     VHM api version 1.0
>
>     vm_setup_memory: size=0x80000000
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643
>
>     level 0 free/need pages:0/1 page size:0x200000
>
>     level 1 free/need pages:0/2 page size:0x40000000
>
>     to reserve more free pages:
>
>     to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
>
>     to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
>
>     now enough free pages are reserved!
>
>     try to setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     total_size 0x180000000
>
>     mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000
>
>     mmap 0x80000000@0x7fdbc0000000
>
>     touch 2 pages with pagesz 0x40000000
>
>     mmap 0x200000@0x7fdcbfe00000
>
>     touch 1 pages with pagesz 0x200000
>
>     really setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     vm_init_vdevs
>
>     polling 38...
>
>     Listening 38...
>
>     pci init hostbridge
>
>     pci init lpc
>
>     pci init pci-gvt
>
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>
>     GVT: init failed
>
>     pci pci-gvt init failed
>
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>
>     Stop listening 38...
>
>     Stop polling 38...
>
>     Unable to init vdev (2)
>
> I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in
> configuring ACRN or UOS, I'll re-check what I have done.
>
> Best regards,
>
> Dubravko
>
> *Dubravko Moravski*
>
> /SW engineering/
>
> *Exor Embedded S.r.l.*
>
> p:
>
>       
>
> +38 512455659 <tel:+38%20512455659>  m: +38 5915402413 <tel:+38%205915402413>
>
> a:
>
>       
>
> Slavonska avenija, 50, Zagreb, Croatia, 10000
>
> w:
>
>       
>
> exorint.com <https://exorint.com/>
>
>       
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
>
> --------------------------------------------------------------------------------------------------------------------------
>
> *From:*acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> on behalf of Shuo A Liu via Lists.Projectacrn.Org
> <shuo.a.liu=intel.com@... <mailto:shuo.a.liu=intel.com@...>>
> *Sent:* Friday, February 28, 2020 9:41 AM
> *To:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>>
> *Cc:* Wang, Hongbo <hongbo.wang@... <mailto:hongbo.wang@...>>; Wang, Yu1 <yu1.wang@...
> <mailto:yu1.wang@...>>; Li, Fei1 <fei1.li@... <mailto:fei1.li@...>>; Chen, Conghui
> <conghui.chen@... <mailto:conghui.chen@...>>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help
> check if your HV include it?
>
> commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379
>
> Author: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> Date:   Thu Dec 5 22:51:06 2019 +0800
>
>      hv: vpci: trap PCIe ECAM access for SOS
>
>      SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this
>
>      access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched
>
>      VM trap PCIe ECAM access in DM).
>
>      Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through
>
>      platform hide PCI devices by BIOS to SOS.
>
>      Tracked-On: #3475
>
>      Signed-off-by: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> You can have a quick try to revert it firstly if it is included.
>
> Thanks
>
> shuo
>
> *From:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> *On Behalf Of *Dubravko Moravski | Exor Embedded S.r.l.
> *Sent:* Thursday, February 27, 2020 02:19
> *To:* acrn-users@... <mailto:acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Zide,
>
> Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.
>
> I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the
> kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
> The new kernel mostly works, however igb driver doesn't (and we really need the network):
>
>     clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb
>
>     [    3.708554] calling  igb_init_module+0x0/0x4d @ 1
>
>     [    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
>
>     [    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): *PCIe link lost*
>
>     [    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.
>
>     [    7.504456] igb 0000:04:00.0: Invalid MAC Address
>
>     [    7.505779] igb: probe of 0000:04:00.0 failed with error -5
>
>     [    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs
>
> The "PCIe link lost" message originates in igb_main.c, approx line 740:
>
>     u32 igb_rd32(struct e1000_hw *hw, u32 reg)
>
>     {
>
>              struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);
>
>              u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
>
>              u32 value = 0;
>
>              if (E1000_REMOVED(hw_addr))
>
>                      return ~value;
>
>              value = readl(&hw_addr[reg]);
>
>              /* reads should not return all F's */
>
>              if (!(~value) && (!reg || !(~readl(hw_addr)))) {
>
>                      struct net_device *netdev = igb->netdev;
>
>                      hw->hw_addr = NULL;
>
>                      netdev_err(netdev, "*PCIe link lost*\n");
>
>              }
>
>              return value;
>
>     }
>
> I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible
> level, looking from the software side of things, so it doesn't look like I could do much debugging here.
>
> In regular Clear Linux, the driver consistently works and there are never any link issues:
>
>     clear@clr-sos-guest~ $ sudo dmesg | grep -i igb
>
>     Password:
>
>     [    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317
>
>     [    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
>
>     [    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    4.519304] igb 0000:04:00.0: added PHC on eth0
>
>     [    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection
>
>     [    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84
>
>     [    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF
>
>     [    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
>
>     [    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs
>
>     [    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0
>
>     [    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>
> So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?
>
> Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with
> the same file system and GUI and system settings, the mouse works and the cursor is visible.
>
> Best regards,
>
> Dubravko
>
>


Geoffroy Van Cutsem
 

Hi Dubravko,

 

That’s most likely the problem then, GVT-g needs to be specifically enabled. These command-line parameters are the default ones from Clear Linux. Do you have an acrn.conf [1] file on your ESP? If not, I’d recommend you add one and make it the default boot entry (modify /boot/loader/loader.conf after mounting the ESP under /boot).

 

If you look inside that file, you’ll find a number of i915 that are set for GVT (i915.nuclear_pageflip=1 i915.avail_planes_per_pipe=0x01010F i915.domain_plane_owners=0x011111110000 i915.enable_gvt=1 i915.enable_guc=0), and if you’re curious as to what they mean, they are documented here: https://projectacrn.github.io/latest/user-guides/kernel-parameters.html#intel-gvt-g-acrngt-parameters

 

[1] https://github.com/projectacrn/acrn-hypervisor/blob/master/misc/efi-stub/clearlinux/acrn.conf

 

Hope this helps!
Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Wednesday, March 4, 2020 2:14 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Geoffroy,

 

SOS command line parameters are:

initrd=\EFI\org.clearlinux\freestanding-00-intel-ucode.cpio initrd=\EFI\org.clearlinux\freestanding-i915-firmware.cpio.xz root=PARTUUID=ef5fabcd-7773-447d-ad51-0fb2b6522c90 quiet console=tty0 console=ttyS0,115200n8 cryptomgr.notests init=/usr/bin/initra-desktop initcall_debug intel_iommu=igfx_off kvm-intel.nested=1 no_timer_check noreplace-smp page_alloc.shuffle=1 rcu_nocbs=0-64 rcupdate.rcu_expedited=1 rootfstype=ext4,btrfs,xfs tsc=reliable rw ignore_loglevel earlyprintk=serial,ttyS0,115200n8,keep

 

I've searched for all config parameters containing 915_GVT substring, CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_ACRN are on, CONFIG_DRM_I915_GVT_KVMGT is off.

 

Regard,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Tuesday, March 3, 2020 10:33 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Can you send your kernel command-line parameters (in the SOS): $ cat /proc/cmdline?

 

We should also check in the kernel config (/proc/config.gz) in case GVT got inadvertently turned off (CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_ACRN) when you reconfigured and recompiled your kernel.

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 3, 2020 7:52 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Zide and Geoffroy,

 

Yes, igb i211 driver now works on SOS, and UOS can access the network too, without changing any setting or modifying the kernel. Usually I would suspect some hardware issue, but we haven't seen any issues with PCIe so far on the board, so this is puzzling.

 

Invisible mouse cursor, it works on regular Clear Linux with the same SOS kernel (that I've built, with igb driver), and the same rootfs (/dev/mmcblk1p3, and we have only one MMC device so it can't be confused with anything else).

"sudo dmesg | grep -i mouse" produces identical output when it's visible and invisible, and nothing looks suspicious.

 

It looks like I don't need GVT, but just in case it's simple to fix, I've checked dmesg (no mentions of it) and /sys/kernel/ directory. Here, gvt/ subfolder is missing, and UOS launching script complains about that. Do I just need to enable some driver or start some service to get it?

 

Best regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
Sent: Tuesday, March 3, 2020 5:40 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

I'm not familiar with GVT, and let other guys to comment on this topic.
You meant lgb i211 driver is working on SOS now? I'm sure it has nothing to do with acrn-dm which has impacts on UOS only.

The invisible mouse cursor issue, you meant it works on regular (native) Linux with same SOS kernel? Did you use the same
rootfs with SOS? I feel it more likely a rootfs issue and may not related Hypervisor. We need to look at Hypervisor only
when SOS Kernel + rootfs work on native Linux but not on top of ACRN.

Best Regards,
Zide


On 3/3/20 5:41 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
> Hi Zide,
>
> Your advice was helpful again. I have recompiled acrn-dm, edited the launch script, and now UOS works. I'm not exactly
> sure why, but Ethernet works too! I'm using the same board and the same kernel as few days ago. Does acrn-dm somehow
> affect it?
>
> I have changed the launch script like this:
>
>     acrn-dm -A -m $mem_size -s 0:0,hostbridge \
>        -s 5,virtio-console,@stdio:stdio_port \
>        -s 6,virtio-hyper_dmabuf \
>        -s 3,virtio-blk,/home/clear/work/uos/uos.img \
>        -s 4,virtio-net,tap0 \
>        -s 7,virtio-rnd \
>        --ovmf /usr/share/acrn/bios/OVMF.fd \
>        $pm_channel $pm_by_vuart $pm_vuart_node \
>        $logger_setting \
>        --mac_seed $mac_seed \
>        $vm_name
>     }
>
> Apparently it doesn't like this line, now commented out:
>
>     #  -s 2,pci-gvt -G "$2" \
>
> This happens if it's enabled:
>
>     vm_init_vdevs
>     polling 38...
>     Listening 38...
>     pci init hostbridge
>     pci init lpc
>     pci init pci-gvt
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>     GVT: init failed
>     pci pci-gvt init failed
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>     Stop listening 38...
>     Stop polling 38...
>     Unable to init vdev (2)
>
> Reading the documentation, I'm not precisely sure what GVT does. Would it be beneficial to have it for using more display
> outputs simultaneously and drawing/compositing 2D graphics?
>
> About using the same kernel as acrn in regular Linux and testing Ethernet and the mouse, both work in regular Linux. In
> acrn, the mouse is still functional, but invisible (it's a plain Logitech USB mouse, nothing special about it).
>
> Best regards,
> Dubravko
>
>
> *Dubravko Moravski*
> /SW engineering/
> *Exor Embedded S.r.l.*
> p:     +38 512455659 <tel:+38 512455659>  m:+38 5915402413 <tel:+38 5915402413>
> a:     Slavonska avenija, 50, Zagreb, Croatia, 10000
> w:     exorint.com <https://exorint.com/>
>
>       
>
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
> --------------------------------------------------------------------------------------------------------------------------
> *From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via
> Lists.Projectacrn.Org <zide.chen=intel.com@...>
> *Sent:* Saturday, February 29, 2020 9:04 AM
> *To:* acrn-users@... <acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same
> acrn tree to avoid any version compatibility issue.
>
> $ cd acrn-hypervisor
>
> $ make devicemodel
>
> $ scp build/devicemodel/acrn-dm target:/usr/bin
>
> For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you
> may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of
> initializing that device.
>
> Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems
> not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.
>
> Best Regards,
>
> Zide
>
> *From:* acrn-users@... <acrn-users@...> *On Behalf Of *Dubravko Moravski | Exor
> Embedded S.r.l.
> *Sent:* Friday, February 28, 2020 9:57 AM
> *To:* acrn-users@...
> *Cc:* Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui
> <conghui.chen@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi everyone,
>
> I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to
> the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical,
> "PCIe link lost". If you have any other ideas for me to try, please let me know.
>
> Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the
> acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything
> related to hardware acceleration. If you have any other ideas...
>
> Unfortunately I'm also having issues launching User OS. I've followed instructions from here:
> https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it
> up goes well, but in the end it fails to launch:
>
>     clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh
>
>     cpu1 online=1
>
>     cpu2 online=1
>
>     cpu3 online=1
>
>     cat: '/sys/class/net/e*/address': No such file or directory
>
>     passed gvt-g optargs low_gm 64, high_gm 448, fence 8
>
>     SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000
>
>     pm by vuart node-index = 0
>
>     logger: name=console, level=4
>
>     logger: name=kmsg, level=3
>
>     logger: name=disk, level=5
>
>     vm_create: vm1
>
>     VHM api version 1.0
>
>     vm_setup_memory: size=0x80000000
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643
>
>     level 0 free/need pages:0/1 page size:0x200000
>
>     level 1 free/need pages:0/2 page size:0x40000000
>
>     to reserve more free pages:
>
>     to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
>
>     to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
>
>     now enough free pages are reserved!
>
>     try to setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     total_size 0x180000000
>
>     mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000
>
>     mmap 0x80000000@0x7fdbc0000000
>
>     touch 2 pages with pagesz 0x40000000
>
>     mmap 0x200000@0x7fdcbfe00000
>
>     touch 1 pages with pagesz 0x200000
>
>     really setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     vm_init_vdevs
>
>     polling 38...
>
>     Listening 38...
>
>     pci init hostbridge
>
>     pci init lpc
>
>     pci init pci-gvt
>
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>
>     GVT: init failed
>
>     pci pci-gvt init failed
>
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>
>     Stop listening 38...
>
>     Stop polling 38...
>
>     Unable to init vdev (2)
>
> I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in
> configuring ACRN or UOS, I'll re-check what I have done.
>
> Best regards,
>
> Dubravko
>
> *Dubravko Moravski*
>
> /SW engineering/
>
> *Exor Embedded S.r.l.*
>
> p:
>
>       
>
> +38 512455659 <tel:+38%20512455659>  m: +38 5915402413 <tel:+38%205915402413>
>
> a:
>
>       
>
> Slavonska avenija, 50, Zagreb, Croatia, 10000
>
> w:
>
>       
>
> exorint.com <https://exorint.com/>
>
>       
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
>
> --------------------------------------------------------------------------------------------------------------------------
>
> *From:*acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> on behalf of Shuo A Liu via Lists.Projectacrn.Org
> <shuo.a.liu=intel.com@... <mailto:shuo.a.liu=intel.com@...>>
> *Sent:* Friday, February 28, 2020 9:41 AM
> *To:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>>
> *Cc:* Wang, Hongbo <hongbo.wang@... <mailto:hongbo.wang@...>>; Wang, Yu1 <yu1.wang@...
> <mailto:yu1.wang@...>>; Li, Fei1 <fei1.li@... <mailto:fei1.li@...>>; Chen, Conghui
> <conghui.chen@... <mailto:conghui.chen@...>>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help
> check if your HV include it?
>
> commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379
>
> Author: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> Date:   Thu Dec 5 22:51:06 2019 +0800
>
>      hv: vpci: trap PCIe ECAM access for SOS
>
>      SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this
>
>      access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched
>
>      VM trap PCIe ECAM access in DM).
>
>      Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through
>
>      platform hide PCI devices by BIOS to SOS.
>
>      Tracked-On: #3475
>
>      Signed-off-by: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> You can have a quick try to revert it firstly if it is included.
>
> Thanks
>
> shuo
>
> *From:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> *On Behalf Of *Dubravko Moravski | Exor Embedded S.r.l.
> *Sent:* Thursday, February 27, 2020 02:19
> *To:* acrn-users@... <mailto:acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Zide,
>
> Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.
>
> I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the
> kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
> The new kernel mostly works, however igb driver doesn't (and we really need the network):
>
>     clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb
>
>     [    3.708554] calling  igb_init_module+0x0/0x4d @ 1
>
>     [    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
>
>     [    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): *PCIe link lost*
>
>     [    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.
>
>     [    7.504456] igb 0000:04:00.0: Invalid MAC Address
>
>     [    7.505779] igb: probe of 0000:04:00.0 failed with error -5
>
>     [    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs
>
> The "PCIe link lost" message originates in igb_main.c, approx line 740:
>
>     u32 igb_rd32(struct e1000_hw *hw, u32 reg)
>
>     {
>
>              struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);
>
>              u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
>
>              u32 value = 0;
>
>              if (E1000_REMOVED(hw_addr))
>
>                      return ~value;
>
>              value = readl(&hw_addr[reg]);
>
>              /* reads should not return all F's */
>
>              if (!(~value) && (!reg || !(~readl(hw_addr)))) {
>
>                      struct net_device *netdev = igb->netdev;
>
>                      hw->hw_addr = NULL;
>
>                      netdev_err(netdev, "*PCIe link lost*\n");
>
>              }
>
>              return value;
>
>     }
>
> I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible
> level, looking from the software side of things, so it doesn't look like I could do much debugging here.
>
> In regular Clear Linux, the driver consistently works and there are never any link issues:
>
>     clear@clr-sos-guest~ $ sudo dmesg | grep -i igb
>
>     Password:
>
>     [    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317
>
>     [    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
>
>     [    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    4.519304] igb 0000:04:00.0: added PHC on eth0
>
>     [    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection
>
>     [    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84
>
>     [    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF
>
>     [    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
>
>     [    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs
>
>     [    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0
>
>     [    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>
> So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?
>
> Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with
> the same file system and GUI and system settings, the mouse works and the cursor is visible.
>
> Best regards,
>
> Dubravko
>
>


Dubravko Moravski | Exor Embedded S.r.l. <dubravko.moravski@...>
 

Hi Geoffroy,

SOS command line parameters are:
initrd=\EFI\org.clearlinux\freestanding-00-intel-ucode.cpio initrd=\EFI\org.clearlinux\freestanding-i915-firmware.cpio.xz root=PARTUUID=ef5fabcd-7773-447d-ad51-0fb2b6522c90 quiet console=tty0 console=ttyS0,115200n8 cryptomgr.notests init=/usr/bin/initra-desktop initcall_debug intel_iommu=igfx_off kvm-intel.nested=1 no_timer_check noreplace-smp page_alloc.shuffle=1 rcu_nocbs=0-64 rcupdate.rcu_expedited=1 rootfstype=ext4,btrfs,xfs tsc=reliable rw ignore_loglevel earlyprintk=serial,ttyS0,115200n8,keep

I've searched for all config parameters containing 915_GVT substring, CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_ACRN are on, CONFIG_DRM_I915_GVT_KVMGT is off.

Regard,
Dubravko


Dubravko Moravski
SW engineering
Exor Embedded S.r.l.
p: +38 512455659  m: +38 5915402413
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy
From: acrn-users@... <acrn-users@...> on behalf of Geoffroy Van Cutsem via Lists.Projectacrn.Org <geoffroy.vancutsem=intel.com@...>
Sent: Tuesday, March 3, 2020 10:33 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
 

Can you send your kernel command-line parameters (in the SOS): $ cat /proc/cmdline?

 

We should also check in the kernel config (/proc/config.gz) in case GVT got inadvertently turned off (CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_ACRN) when you reconfigured and recompiled your kernel.

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 3, 2020 7:52 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Zide and Geoffroy,

 

Yes, igb i211 driver now works on SOS, and UOS can access the network too, without changing any setting or modifying the kernel. Usually I would suspect some hardware issue, but we haven't seen any issues with PCIe so far on the board, so this is puzzling.

 

Invisible mouse cursor, it works on regular Clear Linux with the same SOS kernel (that I've built, with igb driver), and the same rootfs (/dev/mmcblk1p3, and we have only one MMC device so it can't be confused with anything else).

"sudo dmesg | grep -i mouse" produces identical output when it's visible and invisible, and nothing looks suspicious.

 

It looks like I don't need GVT, but just in case it's simple to fix, I've checked dmesg (no mentions of it) and /sys/kernel/ directory. Here, gvt/ subfolder is missing, and UOS launching script complains about that. Do I just need to enable some driver or start some service to get it?

 

Best regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
Sent: Tuesday, March 3, 2020 5:40 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

I'm not familiar with GVT, and let other guys to comment on this topic.
You meant lgb i211 driver is working on SOS now? I'm sure it has nothing to do with acrn-dm which has impacts on UOS only.

The invisible mouse cursor issue, you meant it works on regular (native) Linux with same SOS kernel? Did you use the same
rootfs with SOS? I feel it more likely a rootfs issue and may not related Hypervisor. We need to look at Hypervisor only
when SOS Kernel + rootfs work on native Linux but not on top of ACRN.

Best Regards,
Zide


On 3/3/20 5:41 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
> Hi Zide,
>
> Your advice was helpful again. I have recompiled acrn-dm, edited the launch script, and now UOS works. I'm not exactly
> sure why, but Ethernet works too! I'm using the same board and the same kernel as few days ago. Does acrn-dm somehow
> affect it?
>
> I have changed the launch script like this:
>
>     acrn-dm -A -m $mem_size -s 0:0,hostbridge \
>        -s 5,virtio-console,@stdio:stdio_port \
>        -s 6,virtio-hyper_dmabuf \
>        -s 3,virtio-blk,/home/clear/work/uos/uos.img \
>        -s 4,virtio-net,tap0 \
>        -s 7,virtio-rnd \
>        --ovmf /usr/share/acrn/bios/OVMF.fd \
>        $pm_channel $pm_by_vuart $pm_vuart_node \
>        $logger_setting \
>        --mac_seed $mac_seed \
>        $vm_name
>     }
>
> Apparently it doesn't like this line, now commented out:
>
>     #  -s 2,pci-gvt -G "$2" \
>
> This happens if it's enabled:
>
>     vm_init_vdevs
>     polling 38...
>     Listening 38...
>     pci init hostbridge
>     pci init lpc
>     pci init pci-gvt
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>     GVT: init failed
>     pci pci-gvt init failed
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>     Stop listening 38...
>     Stop polling 38...
>     Unable to init vdev (2)
>
> Reading the documentation, I'm not precisely sure what GVT does. Would it be beneficial to have it for using more display
> outputs simultaneously and drawing/compositing 2D graphics?
>
> About using the same kernel as acrn in regular Linux and testing Ethernet and the mouse, both work in regular Linux. In
> acrn, the mouse is still functional, but invisible (it's a plain Logitech USB mouse, nothing special about it).
>
> Best regards,
> Dubravko
>
>
> *Dubravko Moravski*
> /SW engineering/
> *Exor Embedded S.r.l.*
> p:     +38 512455659 <tel:+38 512455659>  m:+38 5915402413 <tel:+38 5915402413>
> a:     Slavonska avenija, 50, Zagreb, Croatia, 10000
> w:     exorint.com <https://exorint.com/>
>
>       
>
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
> --------------------------------------------------------------------------------------------------------------------------
> *From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via
> Lists.Projectacrn.Org <zide.chen=intel.com@...>
> *Sent:* Saturday, February 29, 2020 9:04 AM
> *To:* acrn-users@... <acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same
> acrn tree to avoid any version compatibility issue.
>
> $ cd acrn-hypervisor
>
> $ make devicemodel
>
> $ scp build/devicemodel/acrn-dm target:/usr/bin
>
> For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you
> may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of
> initializing that device.
>
> Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems
> not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.
>
> Best Regards,
>
> Zide
>
> *From:* acrn-users@... <acrn-users@...> *On Behalf Of *Dubravko Moravski | Exor
> Embedded S.r.l.
> *Sent:* Friday, February 28, 2020 9:57 AM
> *To:* acrn-users@...
> *Cc:* Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui
> <conghui.chen@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi everyone,
>
> I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to
> the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical,
> "PCIe link lost". If you have any other ideas for me to try, please let me know.
>
> Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the
> acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything
> related to hardware acceleration. If you have any other ideas...
>
> Unfortunately I'm also having issues launching User OS. I've followed instructions from here:
> https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it
> up goes well, but in the end it fails to launch:
>
>     clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh
>
>     cpu1 online=1
>
>     cpu2 online=1
>
>     cpu3 online=1
>
>     cat: '/sys/class/net/e*/address': No such file or directory
>
>     passed gvt-g optargs low_gm 64, high_gm 448, fence 8
>
>     SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000
>
>     pm by vuart node-index = 0
>
>     logger: name=console, level=4
>
>     logger: name=kmsg, level=3
>
>     logger: name=disk, level=5
>
>     vm_create: vm1
>
>     VHM api version 1.0
>
>     vm_setup_memory: size=0x80000000
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643
>
>     level 0 free/need pages:0/1 page size:0x200000
>
>     level 1 free/need pages:0/2 page size:0x40000000
>
>     to reserve more free pages:
>
>     to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
>
>     to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
>
>     now enough free pages are reserved!
>
>     try to setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     total_size 0x180000000
>
>     mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000
>
>     mmap 0x80000000@0x7fdbc0000000
>
>     touch 2 pages with pagesz 0x40000000
>
>     mmap 0x200000@0x7fdcbfe00000
>
>     touch 1 pages with pagesz 0x200000
>
>     really setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     vm_init_vdevs
>
>     polling 38...
>
>     Listening 38...
>
>     pci init hostbridge
>
>     pci init lpc
>
>     pci init pci-gvt
>
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>
>     GVT: init failed
>
>     pci pci-gvt init failed
>
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>
>     Stop listening 38...
>
>     Stop polling 38...
>
>     Unable to init vdev (2)
>
> I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in
> configuring ACRN or UOS, I'll re-check what I have done.
>
> Best regards,
>
> Dubravko
>
> *Dubravko Moravski*
>
> /SW engineering/
>
> *Exor Embedded S.r.l.*
>
> p:
>
>       
>
> +38 512455659 <tel:+38%20512455659>  m: +38 5915402413 <tel:+38%205915402413>
>
> a:
>
>       
>
> Slavonska avenija, 50, Zagreb, Croatia, 10000
>
> w:
>
>       
>
> exorint.com <https://exorint.com/>
>
>       
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
>
> --------------------------------------------------------------------------------------------------------------------------
>
> *From:*acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> on behalf of Shuo A Liu via Lists.Projectacrn.Org
> <shuo.a.liu=intel.com@... <mailto:shuo.a.liu=intel.com@...>>
> *Sent:* Friday, February 28, 2020 9:41 AM
> *To:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>>
> *Cc:* Wang, Hongbo <hongbo.wang@... <mailto:hongbo.wang@...>>; Wang, Yu1 <yu1.wang@...
> <mailto:yu1.wang@...>>; Li, Fei1 <fei1.li@... <mailto:fei1.li@...>>; Chen, Conghui
> <conghui.chen@... <mailto:conghui.chen@...>>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help
> check if your HV include it?
>
> commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379
>
> Author: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> Date:   Thu Dec 5 22:51:06 2019 +0800
>
>      hv: vpci: trap PCIe ECAM access for SOS
>
>      SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this
>
>      access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched
>
>      VM trap PCIe ECAM access in DM).
>
>      Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through
>
>      platform hide PCI devices by BIOS to SOS.
>
>      Tracked-On: #3475
>
>      Signed-off-by: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> You can have a quick try to revert it firstly if it is included.
>
> Thanks
>
> shuo
>
> *From:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> *On Behalf Of *Dubravko Moravski | Exor Embedded S.r.l.
> *Sent:* Thursday, February 27, 2020 02:19
> *To:* acrn-users@... <mailto:acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Zide,
>
> Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.
>
> I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the
> kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
> The new kernel mostly works, however igb driver doesn't (and we really need the network):
>
>     clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb
>
>     [    3.708554] calling  igb_init_module+0x0/0x4d @ 1
>
>     [    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
>
>     [    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): *PCIe link lost*
>
>     [    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.
>
>     [    7.504456] igb 0000:04:00.0: Invalid MAC Address
>
>     [    7.505779] igb: probe of 0000:04:00.0 failed with error -5
>
>     [    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs
>
> The "PCIe link lost" message originates in igb_main.c, approx line 740:
>
>     u32 igb_rd32(struct e1000_hw *hw, u32 reg)
>
>     {
>
>              struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);
>
>              u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
>
>              u32 value = 0;
>
>              if (E1000_REMOVED(hw_addr))
>
>                      return ~value;
>
>              value = readl(&hw_addr[reg]);
>
>              /* reads should not return all F's */
>
>              if (!(~value) && (!reg || !(~readl(hw_addr)))) {
>
>                      struct net_device *netdev = igb->netdev;
>
>                      hw->hw_addr = NULL;
>
>                      netdev_err(netdev, "*PCIe link lost*\n");
>
>              }
>
>              return value;
>
>     }
>
> I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible
> level, looking from the software side of things, so it doesn't look like I could do much debugging here.
>
> In regular Clear Linux, the driver consistently works and there are never any link issues:
>
>     clear@clr-sos-guest~ $ sudo dmesg | grep -i igb
>
>     Password:
>
>     [    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317
>
>     [    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
>
>     [    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    4.519304] igb 0000:04:00.0: added PHC on eth0
>
>     [    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection
>
>     [    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84
>
>     [    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF
>
>     [    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
>
>     [    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs
>
>     [    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0
>
>     [    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>
> So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?
>
> Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with
> the same file system and GUI and system settings, the mouse works and the cursor is visible.
>
> Best regards,
>
> Dubravko
>
>



Geoffroy Van Cutsem
 

Can you send your kernel command-line parameters (in the SOS): $ cat /proc/cmdline?

 

We should also check in the kernel config (/proc/config.gz) in case GVT got inadvertently turned off (CONFIG_DRM_I915_GVT and CONFIG_DRM_I915_GVT_ACRN) when you reconfigured and recompiled your kernel.

 

Thanks,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 3, 2020 7:52 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Zide and Geoffroy,

 

Yes, igb i211 driver now works on SOS, and UOS can access the network too, without changing any setting or modifying the kernel. Usually I would suspect some hardware issue, but we haven't seen any issues with PCIe so far on the board, so this is puzzling.

 

Invisible mouse cursor, it works on regular Clear Linux with the same SOS kernel (that I've built, with igb driver), and the same rootfs (/dev/mmcblk1p3, and we have only one MMC device so it can't be confused with anything else).

"sudo dmesg | grep -i mouse" produces identical output when it's visible and invisible, and nothing looks suspicious.

 

It looks like I don't need GVT, but just in case it's simple to fix, I've checked dmesg (no mentions of it) and /sys/kernel/ directory. Here, gvt/ subfolder is missing, and UOS launching script complains about that. Do I just need to enable some driver or start some service to get it?

 

Best regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
Sent: Tuesday, March 3, 2020 5:40 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

I'm not familiar with GVT, and let other guys to comment on this topic.
You meant lgb i211 driver is working on SOS now? I'm sure it has nothing to do with acrn-dm which has impacts on UOS only.

The invisible mouse cursor issue, you meant it works on regular (native) Linux with same SOS kernel? Did you use the same
rootfs with SOS? I feel it more likely a rootfs issue and may not related Hypervisor. We need to look at Hypervisor only
when SOS Kernel + rootfs work on native Linux but not on top of ACRN.

Best Regards,
Zide


On 3/3/20 5:41 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
> Hi Zide,
>
> Your advice was helpful again. I have recompiled acrn-dm, edited the launch script, and now UOS works. I'm not exactly
> sure why, but Ethernet works too! I'm using the same board and the same kernel as few days ago. Does acrn-dm somehow
> affect it?
>
> I have changed the launch script like this:
>
>     acrn-dm -A -m $mem_size -s 0:0,hostbridge \
>        -s 5,virtio-console,@stdio:stdio_port \
>        -s 6,virtio-hyper_dmabuf \
>        -s 3,virtio-blk,/home/clear/work/uos/uos.img \
>        -s 4,virtio-net,tap0 \
>        -s 7,virtio-rnd \
>        --ovmf /usr/share/acrn/bios/OVMF.fd \
>        $pm_channel $pm_by_vuart $pm_vuart_node \
>        $logger_setting \
>        --mac_seed $mac_seed \
>        $vm_name
>     }
>
> Apparently it doesn't like this line, now commented out:
>
>     #  -s 2,pci-gvt -G "$2" \
>
> This happens if it's enabled:
>
>     vm_init_vdevs
>     polling 38...
>     Listening 38...
>     pci init hostbridge
>     pci init lpc
>     pci init pci-gvt
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>     GVT: init failed
>     pci pci-gvt init failed
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>     Stop listening 38...
>     Stop polling 38...
>     Unable to init vdev (2)
>
> Reading the documentation, I'm not precisely sure what GVT does. Would it be beneficial to have it for using more display
> outputs simultaneously and drawing/compositing 2D graphics?
>
> About using the same kernel as acrn in regular Linux and testing Ethernet and the mouse, both work in regular Linux. In
> acrn, the mouse is still functional, but invisible (it's a plain Logitech USB mouse, nothing special about it).
>
> Best regards,
> Dubravko
>
>
> *Dubravko Moravski*
> /SW engineering/
> *Exor Embedded S.r.l.*
> p:     +38 512455659 <tel:+38 512455659>  m:+38 5915402413 <tel:+38 5915402413>
> a:     Slavonska avenija, 50, Zagreb, Croatia, 10000
> w:     exorint.com <https://exorint.com/>
>
>       
>
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
> --------------------------------------------------------------------------------------------------------------------------
> *From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via
> Lists.Projectacrn.Org <zide.chen=intel.com@...>
> *Sent:* Saturday, February 29, 2020 9:04 AM
> *To:* acrn-users@... <acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same
> acrn tree to avoid any version compatibility issue.
>
> $ cd acrn-hypervisor
>
> $ make devicemodel
>
> $ scp build/devicemodel/acrn-dm target:/usr/bin
>
> For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you
> may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of
> initializing that device.
>
> Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems
> not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.
>
> Best Regards,
>
> Zide
>
> *From:* acrn-users@... <acrn-users@...> *On Behalf Of *Dubravko Moravski | Exor
> Embedded S.r.l.
> *Sent:* Friday, February 28, 2020 9:57 AM
> *To:* acrn-users@...
> *Cc:* Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui
> <conghui.chen@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi everyone,
>
> I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to
> the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical,
> "PCIe link lost". If you have any other ideas for me to try, please let me know.
>
> Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the
> acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything
> related to hardware acceleration. If you have any other ideas...
>
> Unfortunately I'm also having issues launching User OS. I've followed instructions from here:
> https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it
> up goes well, but in the end it fails to launch:
>
>     clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh
>
>     cpu1 online=1
>
>     cpu2 online=1
>
>     cpu3 online=1
>
>     cat: '/sys/class/net/e*/address': No such file or directory
>
>     passed gvt-g optargs low_gm 64, high_gm 448, fence 8
>
>     SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000
>
>     pm by vuart node-index = 0
>
>     logger: name=console, level=4
>
>     logger: name=kmsg, level=3
>
>     logger: name=disk, level=5
>
>     vm_create: vm1
>
>     VHM api version 1.0
>
>     vm_setup_memory: size=0x80000000
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643
>
>     level 0 free/need pages:0/1 page size:0x200000
>
>     level 1 free/need pages:0/2 page size:0x40000000
>
>     to reserve more free pages:
>
>     to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
>
>     to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
>
>     now enough free pages are reserved!
>
>     try to setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     total_size 0x180000000
>
>     mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000
>
>     mmap 0x80000000@0x7fdbc0000000
>
>     touch 2 pages with pagesz 0x40000000
>
>     mmap 0x200000@0x7fdcbfe00000
>
>     touch 1 pages with pagesz 0x200000
>
>     really setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     vm_init_vdevs
>
>     polling 38...
>
>     Listening 38...
>
>     pci init hostbridge
>
>     pci init lpc
>
>     pci init pci-gvt
>
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>
>     GVT: init failed
>
>     pci pci-gvt init failed
>
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>
>     Stop listening 38...
>
>     Stop polling 38...
>
>     Unable to init vdev (2)
>
> I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in
> configuring ACRN or UOS, I'll re-check what I have done.
>
> Best regards,
>
> Dubravko
>
> *Dubravko Moravski*
>
> /SW engineering/
>
> *Exor Embedded S.r.l.*
>
> p:
>
>       
>
> +38 512455659 <tel:+38%20512455659>  m: +38 5915402413 <tel:+38%205915402413>
>
> a:
>
>       
>
> Slavonska avenija, 50, Zagreb, Croatia, 10000
>
> w:
>
>       
>
> exorint.com <https://exorint.com/>
>
>       
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
>
> --------------------------------------------------------------------------------------------------------------------------
>
> *From:*acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> on behalf of Shuo A Liu via Lists.Projectacrn.Org
> <shuo.a.liu=intel.com@... <mailto:shuo.a.liu=intel.com@...>>
> *Sent:* Friday, February 28, 2020 9:41 AM
> *To:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>>
> *Cc:* Wang, Hongbo <hongbo.wang@... <mailto:hongbo.wang@...>>; Wang, Yu1 <yu1.wang@...
> <mailto:yu1.wang@...>>; Li, Fei1 <fei1.li@... <mailto:fei1.li@...>>; Chen, Conghui
> <conghui.chen@... <mailto:conghui.chen@...>>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help
> check if your HV include it?
>
> commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379
>
> Author: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> Date:   Thu Dec 5 22:51:06 2019 +0800
>
>      hv: vpci: trap PCIe ECAM access for SOS
>
>      SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this
>
>      access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched
>
>      VM trap PCIe ECAM access in DM).
>
>      Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through
>
>      platform hide PCI devices by BIOS to SOS.
>
>      Tracked-On: #3475
>
>      Signed-off-by: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> You can have a quick try to revert it firstly if it is included.
>
> Thanks
>
> shuo
>
> *From:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> *On Behalf Of *Dubravko Moravski | Exor Embedded S.r.l.
> *Sent:* Thursday, February 27, 2020 02:19
> *To:* acrn-users@... <mailto:acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Zide,
>
> Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.
>
> I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the
> kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
> The new kernel mostly works, however igb driver doesn't (and we really need the network):
>
>     clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb
>
>     [    3.708554] calling  igb_init_module+0x0/0x4d @ 1
>
>     [    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
>
>     [    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): *PCIe link lost*
>
>     [    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.
>
>     [    7.504456] igb 0000:04:00.0: Invalid MAC Address
>
>     [    7.505779] igb: probe of 0000:04:00.0 failed with error -5
>
>     [    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs
>
> The "PCIe link lost" message originates in igb_main.c, approx line 740:
>
>     u32 igb_rd32(struct e1000_hw *hw, u32 reg)
>
>     {
>
>              struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);
>
>              u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
>
>              u32 value = 0;
>
>              if (E1000_REMOVED(hw_addr))
>
>                      return ~value;
>
>              value = readl(&hw_addr[reg]);
>
>              /* reads should not return all F's */
>
>              if (!(~value) && (!reg || !(~readl(hw_addr)))) {
>
>                      struct net_device *netdev = igb->netdev;
>
>                      hw->hw_addr = NULL;
>
>                      netdev_err(netdev, "*PCIe link lost*\n");
>
>              }
>
>              return value;
>
>     }
>
> I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible
> level, looking from the software side of things, so it doesn't look like I could do much debugging here.
>
> In regular Clear Linux, the driver consistently works and there are never any link issues:
>
>     clear@clr-sos-guest~ $ sudo dmesg | grep -i igb
>
>     Password:
>
>     [    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317
>
>     [    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
>
>     [    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    4.519304] igb 0000:04:00.0: added PHC on eth0
>
>     [    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection
>
>     [    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84
>
>     [    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF
>
>     [    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
>
>     [    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs
>
>     [    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0
>
>     [    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>
> So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?
>
> Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with
> the same file system and GUI and system settings, the mouse works and the cursor is visible.
>
> Best regards,
>
> Dubravko
>
>



Dubravko Moravski | Exor Embedded S.r.l. <dubravko.moravski@...>
 

Hi Zide and Geoffroy,

Yes, igb i211 driver now works on SOS, and UOS can access the network too, without changing any setting or modifying the kernel. Usually I would suspect some hardware issue, but we haven't seen any issues with PCIe so far on the board, so this is puzzling.

Invisible mouse cursor, it works on regular Clear Linux with the same SOS kernel (that I've built, with igb driver), and the same rootfs (/dev/mmcblk1p3, and we have only one MMC device so it can't be confused with anything else).
"sudo dmesg | grep -i mouse" produces identical output when it's visible and invisible, and nothing looks suspicious.

It looks like I don't need GVT, but just in case it's simple to fix, I've checked dmesg (no mentions of it) and /sys/kernel/ directory. Here, gvt/ subfolder is missing, and UOS launching script complains about that. Do I just need to enable some driver or start some service to get it?

Best regards,
Dubravko


Dubravko Moravski
SW engineering
Exor Embedded S.r.l.
p: +38 512455659  m: +38 5915402413
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy
From: acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
Sent: Tuesday, March 3, 2020 5:40 PM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
 
Hi Dubravko,

I'm not familiar with GVT, and let other guys to comment on this topic.
You meant lgb i211 driver is working on SOS now? I'm sure it has nothing to do with acrn-dm which has impacts on UOS only.

The invisible mouse cursor issue, you meant it works on regular (native) Linux with same SOS kernel? Did you use the same
rootfs with SOS? I feel it more likely a rootfs issue and may not related Hypervisor. We need to look at Hypervisor only
when SOS Kernel + rootfs work on native Linux but not on top of ACRN.

Best Regards,
Zide


On 3/3/20 5:41 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
> Hi Zide,
>
> Your advice was helpful again. I have recompiled acrn-dm, edited the launch script, and now UOS works. I'm not exactly
> sure why, but Ethernet works too! I'm using the same board and the same kernel as few days ago. Does acrn-dm somehow
> affect it?
>
> I have changed the launch script like this:
>
>     acrn-dm -A -m $mem_size -s 0:0,hostbridge \
>        -s 5,virtio-console,@stdio:stdio_port \
>        -s 6,virtio-hyper_dmabuf \
>        -s 3,virtio-blk,/home/clear/work/uos/uos.img \
>        -s 4,virtio-net,tap0 \
>        -s 7,virtio-rnd \
>        --ovmf /usr/share/acrn/bios/OVMF.fd \
>        $pm_channel $pm_by_vuart $pm_vuart_node \
>        $logger_setting \
>        --mac_seed $mac_seed \
>        $vm_name
>     }
>
> Apparently it doesn't like this line, now commented out:
>
>     #  -s 2,pci-gvt -G "$2" \
>
> This happens if it's enabled:
>
>     vm_init_vdevs
>     polling 38...
>     Listening 38...
>     pci init hostbridge
>     pci init lpc
>     pci init pci-gvt
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>     GVT: init failed
>     pci pci-gvt init failed
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>     Stop listening 38...
>     Stop polling 38...
>     Unable to init vdev (2)
>
> Reading the documentation, I'm not precisely sure what GVT does. Would it be beneficial to have it for using more display
> outputs simultaneously and drawing/compositing 2D graphics?
>
> About using the same kernel as acrn in regular Linux and testing Ethernet and the mouse, both work in regular Linux. In
> acrn, the mouse is still functional, but invisible (it's a plain Logitech USB mouse, nothing special about it).
>
> Best regards,
> Dubravko
>
>
> *Dubravko Moravski*
> /SW engineering/
> *Exor Embedded S.r.l.*
> p:     +38 512455659 <tel:+38 512455659>  m:+38 5915402413 <tel:+38 5915402413>
> a:     Slavonska avenija, 50, Zagreb, Croatia, 10000
> w:     exorint.com <https://exorint.com/>
>
>       
>
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
> --------------------------------------------------------------------------------------------------------------------------
> *From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via
> Lists.Projectacrn.Org <zide.chen=intel.com@...>
> *Sent:* Saturday, February 29, 2020 9:04 AM
> *To:* acrn-users@... <acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same
> acrn tree to avoid any version compatibility issue.
>
> $ cd acrn-hypervisor
>
> $ make devicemodel
>
> $ scp build/devicemodel/acrn-dm target:/usr/bin
>
> For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you
> may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of
> initializing that device.
>
> Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems
> not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.
>
> Best Regards,
>
> Zide
>
> *From:* acrn-users@... <acrn-users@...> *On Behalf Of *Dubravko Moravski | Exor
> Embedded S.r.l.
> *Sent:* Friday, February 28, 2020 9:57 AM
> *To:* acrn-users@...
> *Cc:* Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui
> <conghui.chen@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi everyone,
>
> I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to
> the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical,
> "PCIe link lost". If you have any other ideas for me to try, please let me know.
>
> Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the
> acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything
> related to hardware acceleration. If you have any other ideas...
>
> Unfortunately I'm also having issues launching User OS. I've followed instructions from here:
> https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it
> up goes well, but in the end it fails to launch:
>
>     clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh
>
>     cpu1 online=1
>
>     cpu2 online=1
>
>     cpu3 online=1
>
>     cat: '/sys/class/net/e*/address': No such file or directory
>
>     passed gvt-g optargs low_gm 64, high_gm 448, fence 8
>
>     SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000
>
>     pm by vuart node-index = 0
>
>     logger: name=console, level=4
>
>     logger: name=kmsg, level=3
>
>     logger: name=disk, level=5
>
>     vm_create: vm1
>
>     VHM api version 1.0
>
>     vm_setup_memory: size=0x80000000
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643
>
>     open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643
>
>     level 0 free/need pages:0/1 page size:0x200000
>
>     level 1 free/need pages:0/2 page size:0x40000000
>
>     to reserve more free pages:
>
>     to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
>
>     to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
>
>     now enough free pages are reserved!
>
>     try to setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     total_size 0x180000000
>
>     mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000
>
>     mmap 0x80000000@0x7fdbc0000000
>
>     touch 2 pages with pagesz 0x40000000
>
>     mmap 0x200000@0x7fdcbfe00000
>
>     touch 1 pages with pagesz 0x200000
>
>     really setup hugepage with:
>
>              level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
>
>              level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
>
>     vm_init_vdevs
>
>     polling 38...
>
>     Listening 38...
>
>     pci init hostbridge
>
>     pci init lpc
>
>     pci init pci-gvt
>
>     GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
>
>     GVT: init failed
>
>     pci pci-gvt init failed
>
>     mngr_client_new: Failed to accept from fd 38, err: Invalid argument
>
>     Stop listening 38...
>
>     Stop polling 38...
>
>     Unable to init vdev (2)
>
> I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in
> configuring ACRN or UOS, I'll re-check what I have done.
>
> Best regards,
>
> Dubravko
>
> *Dubravko Moravski*
>
> /SW engineering/
>
> *Exor Embedded S.r.l.*
>
> p:
>
>       
>
> +38 512455659 <tel:+38%20512455659>  m: +38 5915402413 <tel:+38%205915402413>
>
> a:
>
>       
>
> Slavonska avenija, 50, Zagreb, Croatia, 10000
>
> w:
>
>       
>
> exorint.com <https://exorint.com/>
>
>       
>
>   Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
>
> Privacy <https://www.exorint.com/it/privacy>
>
> --------------------------------------------------------------------------------------------------------------------------
>
> *From:*acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> on behalf of Shuo A Liu via Lists.Projectacrn.Org
> <shuo.a.liu=intel.com@... <mailto:shuo.a.liu=intel.com@...>>
> *Sent:* Friday, February 28, 2020 9:41 AM
> *To:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>>
> *Cc:* Wang, Hongbo <hongbo.wang@... <mailto:hongbo.wang@...>>; Wang, Yu1 <yu1.wang@...
> <mailto:yu1.wang@...>>; Li, Fei1 <fei1.li@... <mailto:fei1.li@...>>; Chen, Conghui
> <conghui.chen@... <mailto:conghui.chen@...>>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Dubravko,
>
> I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help
> check if your HV include it?
>
> commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379
>
> Author: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> Date:   Thu Dec 5 22:51:06 2019 +0800
>
>      hv: vpci: trap PCIe ECAM access for SOS
>
>      SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this
>
>      access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched
>
>      VM trap PCIe ECAM access in DM).
>
>      Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through
>
>      platform hide PCI devices by BIOS to SOS.
>
>      Tracked-On: #3475
>
>      Signed-off-by: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
>
> You can have a quick try to revert it firstly if it is included.
>
> Thanks
>
> shuo
>
> *From:* acrn-users@... <mailto:acrn-users@...> <acrn-users@...
> <mailto:acrn-users@...>> *On Behalf Of *Dubravko Moravski | Exor Embedded S.r.l.
> *Sent:* Thursday, February 27, 2020 02:19
> *To:* acrn-users@... <mailto:acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
>
> Hi Zide,
>
> Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.
>
> I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the
> kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
> The new kernel mostly works, however igb driver doesn't (and we really need the network):
>
>     clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb
>
>     [    3.708554] calling  igb_init_module+0x0/0x4d @ 1
>
>     [    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
>
>     [    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): *PCIe link lost*
>
>     [    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.
>
>     [    7.504456] igb 0000:04:00.0: Invalid MAC Address
>
>     [    7.505779] igb: probe of 0000:04:00.0 failed with error -5
>
>     [    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs
>
> The "PCIe link lost" message originates in igb_main.c, approx line 740:
>
>     u32 igb_rd32(struct e1000_hw *hw, u32 reg)
>
>     {
>
>              struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);
>
>              u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
>
>              u32 value = 0;
>
>              if (E1000_REMOVED(hw_addr))
>
>                      return ~value;
>
>              value = readl(&hw_addr[reg]);
>
>              /* reads should not return all F's */
>
>              if (!(~value) && (!reg || !(~readl(hw_addr)))) {
>
>                      struct net_device *netdev = igb->netdev;
>
>                      hw->hw_addr = NULL;
>
>                      netdev_err(netdev, "*PCIe link lost*\n");
>
>              }
>
>              return value;
>
>     }
>
> I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible
> level, looking from the software side of things, so it doesn't look like I could do much debugging here.
>
> In regular Clear Linux, the driver consistently works and there are never any link issues:
>
>     clear@clr-sos-guest~ $ sudo dmesg | grep -i igb
>
>     Password:
>
>     [    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317
>
>     [    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
>
>     [    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.
>
>     [    4.519304] igb 0000:04:00.0: added PHC on eth0
>
>     [    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection
>
>     [    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84
>
>     [    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF
>
>     [    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
>
>     [    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs
>
>     [    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0
>
>     [    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
>
> So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?
>
> Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with
> the same file system and GUI and system settings, the mouse works and the cursor is visible.
>
> Best regards,
>
> Dubravko
>
>




Chen, Zide
 

Hi Dubravko,

I'm not familiar with GVT, and let other guys to comment on this topic.
You meant lgb i211 driver is working on SOS now? I'm sure it has nothing to do with acrn-dm which has impacts on UOS only.

The invisible mouse cursor issue, you meant it works on regular (native) Linux with same SOS kernel? Did you use the same rootfs with SOS? I feel it more likely a rootfs issue and may not related Hypervisor. We need to look at Hypervisor only when SOS Kernel + rootfs work on native Linux but not on top of ACRN.

Best Regards,
Zide

On 3/3/20 5:41 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
Hi Zide,
Your advice was helpful again. I have recompiled acrn-dm, edited the launch script, and now UOS works. I'm not exactly sure why, but Ethernet works too! I'm using the same board and the same kernel as few days ago. Does acrn-dm somehow affect it?
I have changed the launch script like this:
acrn-dm -A -m $mem_size -s 0:0,hostbridge \
  -s 5,virtio-console,@stdio:stdio_port \
  -s 6,virtio-hyper_dmabuf \
  -s 3,virtio-blk,/home/clear/work/uos/uos.img \
  -s 4,virtio-net,tap0 \
  -s 7,virtio-rnd \
  --ovmf /usr/share/acrn/bios/OVMF.fd \
  $pm_channel $pm_by_vuart $pm_vuart_node \
  $logger_setting \
  --mac_seed $mac_seed \
  $vm_name
}
Apparently it doesn't like this line, now commented out:
#  -s 2,pci-gvt -G "$2" \
This happens if it's enabled:
vm_init_vdevs
polling 38...
Listening 38...
pci init hostbridge
pci init lpc
pci init pci-gvt
GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
GVT: init failed
pci pci-gvt init failed
mngr_client_new: Failed to accept from fd 38, err: Invalid argument
Stop listening 38...
Stop polling 38...
Unable to init vdev (2)
Reading the documentation, I'm not precisely sure what GVT does. Would it be beneficial to have it for using more display outputs simultaneously and drawing/compositing 2D graphics?
About using the same kernel as acrn in regular Linux and testing Ethernet and the mouse, both work in regular Linux. In acrn, the mouse is still functional, but invisible (it's a plain Logitech USB mouse, nothing special about it).
Best regards,
Dubravko
*Dubravko Moravski*
/SW engineering/
*Exor Embedded S.r.l.*
p: +38 512455659 <tel:+38 512455659>  m:+38 5915402413 <tel:+38 5915402413>
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com <https://exorint.com/>

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
Privacy <https://www.exorint.com/it/privacy>
--------------------------------------------------------------------------------------------------------------------------
*From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
*Sent:* Saturday, February 29, 2020 9:04 AM
*To:* acrn-users@... <acrn-users@...>
*Subject:* Re: [acrn-users] Getting ACRN to work
Hi Dubravko,
Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same acrn tree to avoid any version compatibility issue.
$ cd acrn-hypervisor
$ make devicemodel
$ scp build/devicemodel/acrn-dm target:/usr/bin
For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of initializing that device.
Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.
Best Regards,
Zide
*From:* acrn-users@... <acrn-users@...> *On Behalf Of *Dubravko Moravski | Exor Embedded S.r.l.
*Sent:* Friday, February 28, 2020 9:57 AM
*To:* acrn-users@...
*Cc:* Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui <conghui.chen@...>
*Subject:* Re: [acrn-users] Getting ACRN to work
Hi everyone,
I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical, "PCIe link lost". If you have any other ideas for me to try, please let me know.
Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything related to hardware acceleration. If you have any other ideas...
Unfortunately I'm also having issues launching User OS. I've followed instructions from here: https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it up goes well, but in the end it fails to launch:
clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh
cpu1 online=1
cpu2 online=1
cpu3 online=1
cat: '/sys/class/net/e*/address': No such file or directory
passed gvt-g optargs low_gm 64, high_gm 448, fence 8
SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000
pm by vuart node-index = 0
logger: name=console, level=4
logger: name=kmsg, level=3
logger: name=disk, level=5
vm_create: vm1
VHM api version 1.0
vm_setup_memory: size=0x80000000
open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643
open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643
level 0 free/need pages:0/1 page size:0x200000
level 1 free/need pages:0/2 page size:0x40000000
to reserve more free pages:
to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
now enough free pages are reserved!
try to setup hugepage with:
        level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
        level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
total_size 0x180000000
mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000
mmap 0x80000000@0x7fdbc0000000
touch 2 pages with pagesz 0x40000000
mmap 0x200000@0x7fdcbfe00000
touch 1 pages with pagesz 0x200000
really setup hugepage with:
        level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0
        level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0
vm_init_vdevs
polling 38...
Listening 38...
pci init hostbridge
pci init lpc
pci init pci-gvt
GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
GVT: init failed
pci pci-gvt init failed
mngr_client_new: Failed to accept from fd 38, err: Invalid argument
Stop listening 38...
Stop polling 38...
Unable to init vdev (2)
I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in configuring ACRN or UOS, I'll re-check what I have done.
Best regards,
Dubravko
*Dubravko Moravski*
/SW engineering/
*Exor Embedded S.r.l.*
p:

+38 512455659 <tel:+38%20512455659>  m: +38 5915402413 <tel:+38%205915402413>
a:

Slavonska avenija, 50, Zagreb, Croatia, 10000
w:

exorint.com <https://exorint.com/>

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
Privacy <https://www.exorint.com/it/privacy>
--------------------------------------------------------------------------------------------------------------------------
*From:*acrn-users@... <mailto:acrn-users@...> <acrn-users@... <mailto:acrn-users@...>> on behalf of Shuo A Liu via Lists.Projectacrn.Org <shuo.a.liu=intel.com@... <mailto:shuo.a.liu=intel.com@...>>
*Sent:* Friday, February 28, 2020 9:41 AM
*To:* acrn-users@... <mailto:acrn-users@...> <acrn-users@... <mailto:acrn-users@...>>
*Cc:* Wang, Hongbo <hongbo.wang@... <mailto:hongbo.wang@...>>; Wang, Yu1 <yu1.wang@... <mailto:yu1.wang@...>>; Li, Fei1 <fei1.li@... <mailto:fei1.li@...>>; Chen, Conghui <conghui.chen@... <mailto:conghui.chen@...>>
*Subject:* Re: [acrn-users] Getting ACRN to work
Hi Dubravko,
I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help check if your HV include it?
commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379
Author: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
Date:   Thu Dec 5 22:51:06 2019 +0800
    hv: vpci: trap PCIe ECAM access for SOS
    SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this
    access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched
    VM trap PCIe ECAM access in DM).
    Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through
    platform hide PCI devices by BIOS to SOS.
    Tracked-On: #3475
    Signed-off-by: Li Fei1 <fei1.li@... <mailto:fei1.li@...>>
You can have a quick try to revert it firstly if it is included.
Thanks
shuo
*From:* acrn-users@... <mailto:acrn-users@...> <acrn-users@... <mailto:acrn-users@...>> *On Behalf Of *Dubravko Moravski | Exor Embedded S.r.l.
*Sent:* Thursday, February 27, 2020 02:19
*To:* acrn-users@... <mailto:acrn-users@...>
*Subject:* Re: [acrn-users] Getting ACRN to work
Hi Zide,
Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.
I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
The new kernel mostly works, however igb driver doesn't (and we really need the network):
clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb
[    3.708554] calling  igb_init_module+0x0/0x4d @ 1
[    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.
[    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): *PCIe link lost*
[    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.
[    7.504456] igb 0000:04:00.0: Invalid MAC Address
[    7.505779] igb: probe of 0000:04:00.0 failed with error -5
[    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs
The "PCIe link lost" message originates in igb_main.c, approx line 740:
u32 igb_rd32(struct e1000_hw *hw, u32 reg)
{
        struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);
        u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
        u32 value = 0;
        if (E1000_REMOVED(hw_addr))
                return ~value;
        value = readl(&hw_addr[reg]);
        /* reads should not return all F's */
        if (!(~value) && (!reg || !(~readl(hw_addr)))) {
                struct net_device *netdev = igb->netdev;
                hw->hw_addr = NULL;
                netdev_err(netdev, "*PCIe link lost*\n");
        }
        return value;
}
I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible level, looking from the software side of things, so it doesn't look like I could do much debugging here.
In regular Clear Linux, the driver consistently works and there are never any link issues:
clear@clr-sos-guest~ $ sudo dmesg | grep -i igb
Password:
[    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317
[    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.
[    4.519304] igb 0000:04:00.0: added PHC on eth0
[    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection
[    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84
[    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF
[    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
[    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs
[    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0
[    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?
Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with the same file system and GUI and system settings, the mouse works and the cursor is visible.
Best regards,
Dubravko


Geoffroy Van Cutsem
 

Hi Dubravko,

 

GVT is the graphics (GPU) sharing capability, you can read more about it here: https://projectacrn.github.io/latest/developer-guides/GVT-g-porting.html

 

It’s essentially useful only if you want to share the GPU between different Virtual Machines (VMs). If you don’t need/want to do that, you don’t need it (and can still drive multiple displays from the Service VM). Note that there are kernel command-line parameters that we should adjust in that case too.

 

About the mouse issue, my suspicion is that it is something wrong with the GVT parameter (cursor plane not working correctly), if you don’t need GVT, you can try to disable it altogether (in /boot/loader/entries/acrn.conf).

 

Regards,

Geoffroy

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Tuesday, March 3, 2020 2:42 PM
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Zide,

 

Your advice was helpful again. I have recompiled acrn-dm, edited the launch script, and now UOS works. I'm not exactly sure why, but Ethernet works too! I'm using the same board and the same kernel as few days ago. Does acrn-dm somehow affect it?

 

I have changed the launch script like this:

acrn-dm -A -m $mem_size -s 0:0,hostbridge \

  -s 5,virtio-console,@stdio:stdio_port \

  -s 6,virtio-hyper_dmabuf \

  -s 3,virtio-blk,/home/clear/work/uos/uos.img \

  -s 4,virtio-net,tap0 \

  -s 7,virtio-rnd \

  --ovmf /usr/share/acrn/bios/OVMF.fd \

  $pm_channel $pm_by_vuart $pm_vuart_node \

  $logger_setting \

  --mac_seed $mac_seed \

  $vm_name

}

Apparently it doesn't like this line, now commented out:

#  -s 2,pci-gvt -G "$2" \

This happens if it's enabled:

vm_init_vdevs

polling 38...

Listening 38...

pci init hostbridge

pci init lpc

pci init pci-gvt

GVT: open /sys/kernel/gvt/control/create_gvt_instance failed

GVT: init failed

pci pci-gvt init failed

mngr_client_new: Failed to accept from fd 38, err: Invalid argument

Stop listening 38...

Stop polling 38...

Unable to init vdev (2)

Reading the documentation, I'm not precisely sure what GVT does. Would it be beneficial to have it for using more display outputs simultaneously and drawing/compositing 2D graphics?

 

About using the same kernel as acrn in regular Linux and testing Ethernet and the mouse, both work in regular Linux. In acrn, the mouse is still functional, but invisible (it's a plain Logitech USB mouse, nothing special about it).

 

Best regards,

Dubravko

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
Sent: Saturday, February 29, 2020 9:04 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

 

Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same acrn tree to avoid any version compatibility issue.

 

$ cd acrn-hypervisor

$ make devicemodel

$ scp build/devicemodel/acrn-dm target:/usr/bin

 

For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of initializing that device.

 

Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.

 

Best Regards,

Zide

 

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Friday, February 28, 2020 9:57 AM
To: acrn-users@...
Cc: Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui <conghui.chen@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi everyone,

 

I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical, "PCIe link lost". If you have any other ideas for me to try, please let me know.

 

Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything related to hardware acceleration. If you have any other ideas...

 

Unfortunately I'm also having issues launching User OS. I've followed instructions from here: https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it up goes well, but in the end it fails to launch:

clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh

cpu1 online=1

cpu2 online=1

cpu3 online=1

cat: '/sys/class/net/e*/address': No such file or directory

passed gvt-g optargs low_gm 64, high_gm 448, fence 8

SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000

pm by vuart node-index = 0

logger: name=console, level=4

logger: name=kmsg, level=3

logger: name=disk, level=5

vm_create: vm1

VHM api version 1.0

vm_setup_memory: size=0x80000000

open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643

open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643

level 0 free/need pages:0/1 page size:0x200000

level 1 free/need pages:0/2 page size:0x40000000

to reserve more free pages:

to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

now enough free pages are reserved!

 

try to setup hugepage with:

        level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0

        level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0

total_size 0x180000000

 

mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000

mmap 0x80000000@0x7fdbc0000000

touch 2 pages with pagesz 0x40000000

mmap 0x200000@0x7fdcbfe00000

touch 1 pages with pagesz 0x200000

 

really setup hugepage with:

        level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0

        level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0

vm_init_vdevs

polling 38...

Listening 38...

pci init hostbridge

pci init lpc

pci init pci-gvt

GVT: open /sys/kernel/gvt/control/create_gvt_instance failed

GVT: init failed

pci pci-gvt init failed

mngr_client_new: Failed to accept from fd 38, err: Invalid argument

Stop listening 38...

Stop polling 38...

Unable to init vdev (2)

I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in configuring ACRN or UOS, I'll re-check what I have done.

 

Best regards,

Dubravko

 

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Shuo A Liu via Lists.Projectacrn.Org <shuo.a.liu=intel.com@...>
Sent: Friday, February 28, 2020 9:41 AM
To: acrn-users@... <acrn-users@...>
Cc: Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui <conghui.chen@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

 

I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help check if your HV include it?

 

commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379

Author: Li Fei1 <fei1.li@...>

Date:   Thu Dec 5 22:51:06 2019 +0800

 

    hv: vpci: trap PCIe ECAM access for SOS

 

    SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this

    access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched

    VM trap PCIe ECAM access in DM).

    Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through

    platform hide PCI devices by BIOS to SOS.

 

    Tracked-On: #3475

    Signed-off-by: Li Fei1 <fei1.li@...>

 

You can have a quick try to revert it firstly if it is included.

 

Thanks

shuo

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, February 27, 2020 02:19
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Zide,

 

Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.

 

I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
The new kernel mostly works, however igb driver doesn't (and we really need the network):

clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb

[    3.708554] calling  igb_init_module+0x0/0x4d @ 1

[    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k

[    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.

[    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): PCIe link lost

[    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.

[    7.504456] igb 0000:04:00.0: Invalid MAC Address

[    7.505779] igb: probe of 0000:04:00.0 failed with error -5

[    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs

 

The "PCIe link lost" message originates in igb_main.c, approx line 740:

u32 igb_rd32(struct e1000_hw *hw, u32 reg)

{

        struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);

        u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);

        u32 value = 0;

 

        if (E1000_REMOVED(hw_addr))

                return ~value;

 

        value = readl(&hw_addr[reg]);

 

        /* reads should not return all F's */

        if (!(~value) && (!reg || !(~readl(hw_addr)))) {

                struct net_device *netdev = igb->netdev;

                hw->hw_addr = NULL;

                netdev_err(netdev, "PCIe link lost\n");

        }

 

        return value;

}

I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible level, looking from the software side of things, so it doesn't look like I could do much debugging here.

 

In regular Clear Linux, the driver consistently works and there are never any link issues:

clear@clr-sos-guest~ $ sudo dmesg | grep -i igb

Password:

[    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317

[    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k

[    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.

[    4.519304] igb 0000:04:00.0: added PHC on eth0

[    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection

[    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84

[    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF

[    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)

[    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs

[    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0

[    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?

 

Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with the same file system and GUI and system settings, the mouse works and the cursor is visible.

 

Best regards,

Dubravko

 


Dubravko Moravski | Exor Embedded S.r.l. <dubravko.moravski@...>
 

Hi Zide,

Your advice was helpful again. I have recompiled acrn-dm, edited the launch script, and now UOS works. I'm not exactly sure why, but Ethernet works too! I'm using the same board and the same kernel as few days ago. Does acrn-dm somehow affect it?

I have changed the launch script like this:
acrn-dm -A -m $mem_size -s 0:0,hostbridge \
  -s 5,virtio-console,@stdio:stdio_port \
  -s 6,virtio-hyper_dmabuf \
  -s 3,virtio-blk,/home/clear/work/uos/uos.img \
  -s 4,virtio-net,tap0 \
  -s 7,virtio-rnd \
  --ovmf /usr/share/acrn/bios/OVMF.fd \
  $pm_channel $pm_by_vuart $pm_vuart_node \
  $logger_setting \
  --mac_seed $mac_seed \
  $vm_name
}
Apparently it doesn't like this line, now commented out:
#  -s 2,pci-gvt -G "$2" \
This happens if it's enabled:
vm_init_vdevs
polling 38...
Listening 38...
pci init hostbridge
pci init lpc
pci init pci-gvt
GVT: open /sys/kernel/gvt/control/create_gvt_instance failed
GVT: init failed
pci pci-gvt init failed
mngr_client_new: Failed to accept from fd 38, err: Invalid argument
Stop listening 38...
Stop polling 38...
Unable to init vdev (2)
Reading the documentation, I'm not precisely sure what GVT does. Would it be beneficial to have it for using more display outputs simultaneously and drawing/compositing 2D graphics?

About using the same kernel as acrn in regular Linux and testing Ethernet and the mouse, both work in regular Linux. In acrn, the mouse is still functional, but invisible (it's a plain Logitech USB mouse, nothing special about it).

Best regards,
Dubravko


Dubravko Moravski
SW engineering
Exor Embedded S.r.l.
p: +38 512455659  m: +38 5915402413
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy
From: acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
Sent: Saturday, February 29, 2020 9:04 AM
To: acrn-users@... <acrn-users@...>
Subject: Re: [acrn-users] Getting ACRN to work
 

Hi Dubravko,

 

Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same acrn tree to avoid any version compatibility issue.

 

$ cd acrn-hypervisor

$ make devicemodel

$ scp build/devicemodel/acrn-dm target:/usr/bin

 

For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of initializing that device.

 

Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.

 

Best Regards,

Zide

 

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Friday, February 28, 2020 9:57 AM
To: acrn-users@...
Cc: Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui <conghui.chen@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi everyone,

 

I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical, "PCIe link lost". If you have any other ideas for me to try, please let me know.

 

Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything related to hardware acceleration. If you have any other ideas...

 

Unfortunately I'm also having issues launching User OS. I've followed instructions from here: https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it up goes well, but in the end it fails to launch:

clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh

cpu1 online=1

cpu2 online=1

cpu3 online=1

cat: '/sys/class/net/e*/address': No such file or directory

passed gvt-g optargs low_gm 64, high_gm 448, fence 8

SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000

pm by vuart node-index = 0

logger: name=console, level=4

logger: name=kmsg, level=3

logger: name=disk, level=5

vm_create: vm1

VHM api version 1.0

vm_setup_memory: size=0x80000000

open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643

open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643

level 0 free/need pages:0/1 page size:0x200000

level 1 free/need pages:0/2 page size:0x40000000

to reserve more free pages:

to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

now enough free pages are reserved!

 

try to setup hugepage with:

        level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0

        level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0

total_size 0x180000000

 

mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000

mmap 0x80000000@0x7fdbc0000000

touch 2 pages with pagesz 0x40000000

mmap 0x200000@0x7fdcbfe00000

touch 1 pages with pagesz 0x200000

 

really setup hugepage with:

        level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0

        level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0

vm_init_vdevs

polling 38...

Listening 38...

pci init hostbridge

pci init lpc

pci init pci-gvt

GVT: open /sys/kernel/gvt/control/create_gvt_instance failed

GVT: init failed

pci pci-gvt init failed

mngr_client_new: Failed to accept from fd 38, err: Invalid argument

Stop listening 38...

Stop polling 38...

Unable to init vdev (2)

I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in configuring ACRN or UOS, I'll re-check what I have done.

 

Best regards,

Dubravko

 

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Shuo A Liu via Lists.Projectacrn.Org <shuo.a.liu=intel.com@...>
Sent: Friday, February 28, 2020 9:41 AM
To: acrn-users@... <acrn-users@...>
Cc: Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui <conghui.chen@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

 

I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help check if your HV include it?

 

commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379

Author: Li Fei1 <fei1.li@...>

Date:   Thu Dec 5 22:51:06 2019 +0800

 

    hv: vpci: trap PCIe ECAM access for SOS

 

    SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this

    access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched

    VM trap PCIe ECAM access in DM).

    Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through

    platform hide PCI devices by BIOS to SOS.

 

    Tracked-On: #3475

    Signed-off-by: Li Fei1 <fei1.li@...>

 

You can have a quick try to revert it firstly if it is included.

 

Thanks

shuo

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, February 27, 2020 02:19
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Zide,

 

Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.

 

I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
The new kernel mostly works, however igb driver doesn't (and we really need the network):

clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb

[    3.708554] calling  igb_init_module+0x0/0x4d @ 1

[    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k

[    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.

[    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): PCIe link lost

[    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.

[    7.504456] igb 0000:04:00.0: Invalid MAC Address

[    7.505779] igb: probe of 0000:04:00.0 failed with error -5

[    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs

 

The "PCIe link lost" message originates in igb_main.c, approx line 740:

u32 igb_rd32(struct e1000_hw *hw, u32 reg)

{

        struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);

        u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);

        u32 value = 0;

 

        if (E1000_REMOVED(hw_addr))

                return ~value;

 

        value = readl(&hw_addr[reg]);

 

        /* reads should not return all F's */

        if (!(~value) && (!reg || !(~readl(hw_addr)))) {

                struct net_device *netdev = igb->netdev;

                hw->hw_addr = NULL;

                netdev_err(netdev, "PCIe link lost\n");

        }

 

        return value;

}

I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible level, looking from the software side of things, so it doesn't look like I could do much debugging here.

 

In regular Clear Linux, the driver consistently works and there are never any link issues:

clear@clr-sos-guest~ $ sudo dmesg | grep -i igb

Password:

[    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317

[    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k

[    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.

[    4.519304] igb 0000:04:00.0: added PHC on eth0

[    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection

[    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84

[    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF

[    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)

[    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs

[    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0

[    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?

 

Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with the same file system and GUI and system settings, the mouse works and the cursor is visible.

 

Best regards,

Dubravko

 


Chen, Zide
 

Hi Dubravko,

 

Since you are using the latest hypervisor code, I’d suggest build your own acrn-dm and use the launch script from the same acrn tree to avoid any version compatibility issue.

 

$ cd acrn-hypervisor

$ make devicemodel

$ scp build/devicemodel/acrn-dm target:/usr/bin

 

For the script, you may start from acrn-hypervisor/devicemodel/samples/nuc /launch_uos.sh. If it runs into problem, you may try customize the script, for example, remove some passthru device from acrn-dm command line if it complains issue of initializing that device.

 

Regarding the Ethernet/mouse driver, did you boot the native Linux with the SOS kernel and the same SOS rootfs? It seems not very likely a kernel config issue, but probably it’s still worthy to rule out kernel issue.

 

Best Regards,

Zide

 

 

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Friday, February 28, 2020 9:57 AM
To: acrn-users@...
Cc: Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui <conghui.chen@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi everyone,

 

I confirm my ACRN sources did include 65ed6c3529de8b3f3d890e95a7d816afba7bf379 commit. I've tried reverting it - due to the subsequent modifications it wasn't trivial but in the end I've managed - the behavior however remained identical, "PCIe link lost". If you have any other ideas for me to try, please let me know.

 

Regarding the invisible mouse pointer, I've found mouse acceleration settings in gnome-tweaks, but they relate only to the acceleration of the movement of the mouse pointer. I've checked all the other tweak pages, still I couldn't find anything related to hardware acceleration. If you have any other ideas...

 

Unfortunately I'm also having issues launching User OS. I've followed instructions from here: https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html#kbl-nuc-sdc, Set up Reference User VM chapter. Setting it up goes well, but in the end it fails to launch:

clear@clr-sos-guest~/work/uos $ sudo ./launch_uos.sh

cpu1 online=1

cpu2 online=1

cpu3 online=1

cat: '/sys/class/net/e*/address': No such file or directory

passed gvt-g optargs low_gm 64, high_gm 448, fence 8

SW_LOAD: get ovmf path /usr/share/acrn/bios/OVMF.fd, size 0x200000

pm by vuart node-index = 0

logger: name=console, level=4

logger: name=kmsg, level=3

logger: name=disk, level=5

vm_create: vm1

VHM api version 1.0

vm_setup_memory: size=0x80000000

open hugetlbfs file /run/hugepage/acrn/huge_lv1/vm1/D279543825D611E8864ECB7A18B34643

open hugetlbfs file /run/hugepage/acrn/huge_lv2/vm1/D279543825D611E8864ECB7A18B34643

level 0 free/need pages:0/1 page size:0x200000

level 1 free/need pages:0/2 page size:0x40000000

to reserve more free pages:

to reserve pages (+orig 0): echo 2 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

to reserve pages (+orig 0): echo 1 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

now enough free pages are reserved!

 

try to setup hugepage with:

        level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0

        level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0

total_size 0x180000000

 

mmap ptr 0x0x7fdbbc4e2000 -> baseaddr 0x0x7fdbc0000000

mmap 0x80000000@0x7fdbc0000000

touch 2 pages with pagesz 0x40000000

mmap 0x200000@0x7fdcbfe00000

touch 1 pages with pagesz 0x200000

 

really setup hugepage with:

        level 0 - lowmem 0x0, biosmem 0x200000, highmem 0x0

        level 1 - lowmem 0x80000000, biosmem 0x0, highmem 0x0

vm_init_vdevs

polling 38...

Listening 38...

pci init hostbridge

pci init lpc

pci init pci-gvt

GVT: open /sys/kernel/gvt/control/create_gvt_instance failed

GVT: init failed

pci pci-gvt init failed

mngr_client_new: Failed to accept from fd 38, err: Invalid argument

Stop listening 38...

Stop polling 38...

Unable to init vdev (2)

I've used the regular ACRN to test it (without reverted PCIe-related commits). I might have missed some required step in configuring ACRN or UOS, I'll re-check what I have done.

 

Best regards,

Dubravko

 

 

 

Dubravko Moravski

SW engineering

Exor Embedded S.r.l.

p:

+38 512455659  m: +38 5915402413

a:

Slavonska avenija, 50, Zagreb, Croatia, 10000

w:

exorint.com 

 

 Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.

Privacy


From: acrn-users@... <acrn-users@...> on behalf of Shuo A Liu via Lists.Projectacrn.Org <shuo.a.liu=intel.com@...>
Sent: Friday, February 28, 2020 9:41 AM
To: acrn-users@... <acrn-users@...>
Cc: Wang, Hongbo <hongbo.wang@...>; Wang, Yu1 <yu1.wang@...>; Li, Fei1 <fei1.li@...>; Chen, Conghui <conghui.chen@...>
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Dubravko,

 

I learned from Fei that one of his patch(merged, for security) might impact PCIe devices in SOS, could you please help check if your HV include it?

 

commit 65ed6c3529de8b3f3d890e95a7d816afba7bf379

Author: Li Fei1 <fei1.li@...>

Date:   Thu Dec 5 22:51:06 2019 +0800

 

    hv: vpci: trap PCIe ECAM access for SOS

 

    SOS will use PCIe ECAM access PCIe external configuration space. HV should trap this

    access for security(Now pre-launched VM doesn't want to support PCI ECAM; post-launched

    VM trap PCIe ECAM access in DM).

    Besides, update PCIe MMCONFIG region to be owned by hypervisor and expose and pass through

    platform hide PCI devices by BIOS to SOS.

 

    Tracked-On: #3475

    Signed-off-by: Li Fei1 <fei1.li@...>

 

You can have a quick try to revert it firstly if it is included.

 

Thanks

shuo

From: acrn-users@... <acrn-users@...> On Behalf Of Dubravko Moravski | Exor Embedded S.r.l.
Sent: Thursday, February 27, 2020 02:19
To: acrn-users@...
Subject: Re: [acrn-users] Getting ACRN to work

 

Hi Zide,

 

Thank you for explaining all the kernel and Ubuntu options. It looks like all the use cases we are interested in are covered.

 

I've got a replacement board and I'm continuing with ACRN. I've followed your instructions regarding rebuilding the kernel, in which I've enabled the Intel igb network driver we need for the I211 chip.
The new kernel mostly works, however igb driver doesn't (and we really need the network):

clear@clr-sos-guest~/work/acrn-kernel $ cat ../../dmesg_bad.txt | grep igb

[    3.708554] calling  igb_init_module+0x0/0x4d @ 1

[    3.709199] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k

[    3.710159] igb: Copyright (c) 2007-2014 Intel Corporation.

[    3.802746] igb 0000:04:00.0 0000:04:00.0 (uninitialized): PCIe link lost

[    4.120516] igb 0000:04:00.0: PHY reset is blocked due to SOL/IDER session.

[    7.504456] igb 0000:04:00.0: Invalid MAC Address

[    7.505779] igb: probe of 0000:04:00.0 failed with error -5

[    7.507585] initcall igb_init_module+0x0/0x4d returned 0 after 3709354 usecs

 

The "PCIe link lost" message originates in igb_main.c, approx line 740:

u32 igb_rd32(struct e1000_hw *hw, u32 reg)

{

        struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);

        u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);

        u32 value = 0;

 

        if (E1000_REMOVED(hw_addr))

                return ~value;

 

        value = readl(&hw_addr[reg]);

 

        /* reads should not return all F's */

        if (!(~value) && (!reg || !(~readl(hw_addr)))) {

                struct net_device *netdev = igb->netdev;

                hw->hw_addr = NULL;

                netdev_err(netdev, "PCIe link lost\n");

        }

 

        return value;

}

I think readl() for PCIe devices is basically a single PCIe transfer; in other words it's already the lowest possible level, looking from the software side of things, so it doesn't look like I could do much debugging here.

 

In regular Clear Linux, the driver consistently works and there are never any link issues:

clear@clr-sos-guest~ $ sudo dmesg | grep -i igb

Password:

[    4.473282] calling  igb_init_module+0x0/0x1000 [igb] @ 317

[    4.473306] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k

[    4.473307] igb: Copyright (c) 2007-2014 Intel Corporation.

[    4.519304] igb 0000:04:00.0: added PHC on eth0

[    4.519307] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection

[    4.519310] igb 0000:04:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:30:d8:05:55:84

[    4.519314] igb 0000:04:00.0: eth0: PBA No: FFFFFF-0FF

[    4.519316] igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)

[    4.519418] initcall igb_init_module+0x0/0x1000 [igb] returned 0 after 33714 usecs

[    5.390826] igb 0000:04:00.0 enp4s0: renamed from eth0

[    8.766862] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

So is there some setting in ACRN that can affect PCIe communication, that I need to adjust for (external) PCIe devices?

 

Also with my ACRN-kernel, the mouse works but the cursor is invisible. In regular Clear Linux with 'native' kernel, with the same file system and GUI and system settings, the mouse works and the cursor is visible.

 

Best regards,

Dubravko