Runing Chromium OS in a virtual machine

[Nathan]

Hi all,

I've been following the instructions in the documentation to run an image I built inside a VM[1]. I'm building for the amd64-generic board.

I managed to get it to run inside QEMU, but the graphics are glitchy and most notably the cursor is quite glitched. I found this discussion from a few years ago where some folks suggest the cursor might not work at all. That seems to have been partially, but not completely, fixed. I tried using both the version of QEMU in the source tree and also the version of QEMU I installed locally from my distro's repository[2].

I tried some of the other VGA options that QEMU supports. virtio will boot (at 640x480) but won't give any cursor at all. None of the other options would even boot into the window manager. I also tried converting the image into a vmdk and booting it in VirtualBox, but the window manager wouldn't start then either (I'm assuming in both cases it was due to the display driver for the VGA system presented by the virtualization layer not being present).

Is running CrOS in a VM something that anyone here does for testing purposes? Or does everyone test on hardware? Is the glitchy cursor a problem that only I'm seeing, or is it expected? Am I asking too many questions in one post? :)

Thanks!

Nathan


[1] Side note: The documentation is out of date in that qemu-kvm is no longer maintained. I note that the helper scripts are aware of that, but for anyone who might find this via a web search, just installing the qemu package and ensuring that the kvm modules are loaded and functional should be sufficient.

[2] The version of QEMU included in the source tree--which is the version launched by the cros_start_vm helper tool--will start a VNC server even when -vnc is not specified on the command line. Running my locally-installed version of QEMU will spawn a window, as expected. I found adding the extra layer of VNC in the mix turned the VM from "barely usable" into "not usable".

[Zach Reizner]

The cursor should work in qemu with cirrus graphics. I assume you're using the 4.4 kernel which supports cursor with since this patch.

On Fri, Nov 4, 2016 at 9:47 AM Nathan <nat...@lenovo-chrome.com> wrote:

Hi all,

I've been following the instructions in the documentation to run an image I built inside a VM[1]. I'm building for the amd64-generic board.

I managed to get it to run inside QEMU, but the graphics are glitchy and most notably the cursor is quite glitched. I found this discussion from a few years ago where some folks suggest the cursor might not work at all. That seems to have been partially, but not completely, fixed. I tried using both the version of QEMU in the source tree and also the version of QEMU I installed locally from my distro's repository[2].

In what way is the cursor glitched? Could you describe it our send an image of it? 

I tried some of the other VGA options that QEMU supports. virtio will boot (at 640x480) but won't give any cursor at all. None of the other options would even boot into the window manager. I also tried converting the image into a vmdk and booting it in VirtualBox, but the window manager wouldn't start then either (I'm assuming in both cases it was due to the display driver for the VGA system presented by the virtualization layer not being present).

Is running CrOS in a VM something that anyone here does for testing purposes? Or does everyone test on hardware? Is the glitchy cursor a problem that only I'm seeing, or is it expected? Am I asking too many questions in one post? :)

Thanks!

Nathan


[1] Side note: The documentation is out of date in that qemu-kvm is no longer maintained. I note that the helper scripts are aware of that, but for anyone who might find this via a web search, just installing the qemu package and ensuring that the kvm modules are loaded and functional should be sufficient.

[2] The version of QEMU included in the source tree--which is the version launched by the cros_start_vm helper tool--will start a VNC server even when -vnc is not specified on the command line. Running my locally-installed version of QEMU will spawn a window, as expected. I found adding the extra layer of VNC in the mix turned the VM from "barely usable" into "not usable".

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Nicholas Bishop]

I have seen this issue as well. Here's a screenshot: http://pasteboard.co/nekNGEwYs.png

The square of vertical lines is the mouse cursor. The pattern of lines does not change as the cursor is moved.

This is with cirrus graphics, QEMU 2.6.2

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

[Zach Reizner]

I'm away from my workstation this week, so I can't try to repro it right now. Could you try running drm_cursor_test from the drm-tests package? Quick overview to do that follows.

From your workstation's chroot:

$ emerge-${BOARD} drm-tests

$ cros deploy ${IP} drm-tests

$ ssh root@${IP}

From that root ssh session:

# stop ui

# drm_cursor_test

On Fri, Nov 4, 2016 at 10:26 AM Nicholas Bishop <nbi...@neverware.com> wrote:

I have seen this issue as well. Here's a screenshot: http://pasteboard.co/nekNGEwYs.png

The square of vertical lines is the mouse cursor. The pattern of lines does not change as the cursor is moved.

This is with cirrus graphics, QEMU 2.6.2

On Fri, Nov 4, 2016 at 11:54 AM, 'Zach Reizner' via Chromium OS dev <chromiu...@chromium.org> wrote:

The cursor should work in qemu with cirrus graphics. I assume you're using the 4.4 kernel which supports cursor with since this patch.

On Fri, Nov 4, 2016 at 9:47 AM Nathan <nat...@lenovo-chrome.com> wrote:

Hi all,

I've been following the instructions in the documentation to run an image I built inside a VM[1]. I'm building for the amd64-generic board.

I managed to get it to run inside QEMU, but the graphics are glitchy and most notably the cursor is quite glitched. I found this discussion from a few years ago where some folks suggest the cursor might not work at all. That seems to have been partially, but not completely, fixed. I tried using both the version of QEMU in the source tree and also the version of QEMU I installed locally from my distro's repository[2].

In what way is the cursor glitched? Could you describe it our send an image of it? 

I tried some of the other VGA options that QEMU supports. virtio will boot (at 640x480) but won't give any cursor at all. None of the other options would even boot into the window manager. I also tried converting the image into a vmdk and booting it in VirtualBox, but the window manager wouldn't start then either (I'm assuming in both cases it was due to the display driver for the VGA system presented by the virtualization layer not being present).

Is running CrOS in a VM something that anyone here does for testing purposes? Or does everyone test on hardware? Is the glitchy cursor a problem that only I'm seeing, or is it expected? Am I asking too many questions in one post? :)

Thanks!

Nathan


[1] Side note: The documentation is out of date in that qemu-kvm is no longer maintained. I note that the helper scripts are aware of that, but for anyone who might find this via a web search, just installing the qemu package and ensuring that the kvm modules are loaded and functional should be sufficient.

[2] The version of QEMU included in the source tree--which is the version launched by the cros_start_vm helper tool--will start a VNC server even when -vnc is not specified on the command line. Running my locally-installed version of QEMU will spawn a window, as expected. I found adding the extra layer of VNC in the mix turned the VM from "barely usable" into "not usable".

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Nicholas Bishop]

Cursor looks the same under that test: http://pasteboard.co/nfm8TFsdt.png

(drm_cursor_test didn't output anything and exited zero, in case that matters)

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

[Zach Reizner]

Fascinating. Do you see any interesting errors in the kernel logs (dmesg)?

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Nicholas Bishop]

Nothing jumps out at me. Here's an excerpt:

root@localhost log # dmesg | egrep -i 'drm|ttm'

[    0.560644] [drm:drm_core_init] Initialized drm 1.1.0 20060810

[    0.562036] [TTM] Zone  kernel: Available graphics memory: 4080748 kiB

[    0.562037] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB

[    0.562038] [TTM] Initializing pool allocator

[    0.562041] [TTM] Initializing DMA pool allocator

[    0.562522] [drm:cirrusfb_create] fb mappable at 0xFC000000

[    0.562524] [drm:cirrusfb_create] vram aper at 0xFC000000

[    0.562525] [drm:cirrusfb_create] size 1440000

[    0.562525] [drm:cirrusfb_create] fb depth is 24

[    0.562526] [drm:cirrusfb_create]    pitch is 2400

[    0.562786] cirrus 0000:00:02.0: fb0: cirrusdrmfb frame buffer device

[    0.568073] [drm:drm_vblank_init] Supports vblank timestamp caching Rev 2 (21.10.2013).

[    0.568075] [drm:drm_vblank_init] No driver support for vblank timestamp query.

[    0.568077] [drm:drm_get_pci_dev] Initialized cirrus 1.0.0 20110418 for 0000:00:02.0 on minor 0

[    0.568335] [drm:drm_get_platform_dev] Initialized vgem 1.0.0 20120112 on minor 1

[    1.185338] frecon(218): Frecon using drm driver cirrus, version 1.0, date(20110418), desc(qemu Cirrus emulation)

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

[Nathan]

Nicholas: Thanks for jumping in!

Zach: My results mirror those Nicholas posted. Screenshot attached (spoiler alert: it looks like the one he posted).

I'm using the cirrus driver as well.

On the VM:

localhost ~ # uname -a
Linux localhost 4.4.21-05976-g2b1dece #1 SMP PREEMPT Wed Nov 2 02:17:22 PDT 2016 x86_64 QEMU Virtual CPU version 2.5+ GenuineIntel GNU/Linux

On the host:

[nathan@nathanb-linux ~] qemu-system-x86_64 --version
QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

[nathan@nathanb-linux ~] uname -a
Linux nathanb-linux 4.8.6-1-ARCH #1 SMP PREEMPT Mon Oct 31 18:51:30 CET 2016 x86_64 GNU/Linux

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Nathan]

I spent some more time playing with the virtio driver this morning. The mouse is present (in the sense that clicking has an effect) but no cursor is drawn at all. Chromium OS is also not very usable at 640x480, which in my opinion is a completely reasonable decision. Interestingly, with virtio I didn't see any of the display flickers I saw with cirrus.

Hopefully we can get something figured out regarding the cirrus driver and maybe come up with a workable solution.

Nathan

[Nicolas Norvez]

Hi Nathan,

If you haven't already, can you try with the -show-cursor switch in the qemu command line? Does it help?

Is VNC an option? You can pass "-vnc 127.0.0.1:0,ipv4" to the command line and connect to localhost:5900

With virtio resolution should be better than 640x480. Once you've logged in, can you change it in Settings->Display settings?

Nicolas.

[Nathan]

Hi Nicolas,

Thanks for your reply!

-show-cursor does not help either with the virtio or with the cirrus driver, unfortunately.

VNC is an option, but it seems to suffer from the same problem. In the case of the cirrus driver it actually makes things worse, as the cursor can't seem to keep up with the host's cursor.

Without a cursor, logging in is difficult, and I can't click "continue as guest" because 640x480 truncates the screen to the point where the text is not visible. Same with accessing settings once logged in. If I manage to press through and try it, I will let you know if I can change the resolution.

Nathan

[Zach Reizner]

So I did reproduce a different cursor problem than what you guys seem to be seeing. My cursor isn't showing up at all, i.e. a totally invisible cursor. Still looking into why that might be.

[Nathan]

Thanks for digging into this. I'm very curious to find out what the problem could be, especially since you're seeing different results out of the cirrus driver than Nicholas and myself.

Nathan

[Nathan]

An update as a result of my experimentation:
* I tried using -usbdevice mouse just to see if it would improve anything, but no result
* If I boot using virtio and use the keyboard (+ guessing where the mouse cursor is), I can change the resolution of the guest, though the behavior is very strange: rather than resizing the window the window stays the same and the size of the virtual display shrinks. When I release the mouse, I can't move the cursor -- it tries to move but then snaps back to its previous position. This behavior persists until I kill QEMU
* I tried booting the image in QEMU without KVM just to see what would happen. It booted extremely slowly and never actually got to the point of loading the graphical interface.

I'm not sure how much more I can investigate on my end, though if you have any thoughts then you are welcome to let me know!

Nathan

[Zach Reizner]

I'm able to recreate the broken cursor bug. I was getting an invisible cursor in qemu was using SDL2 but not in SDL1.2. Still looking into things. Everything seems to be working kernel side. This might be a qemu bug.

[Zach Reizner]

Aha! Progress. I was able to narrow down the problem to an error is cirrus vram size detection. This is important because the cursor data is always stored in the last 16K of VRAM. Sadly the kernel is detecting 32MB from the PCI bar data, but qemu seems to think vram size is 4MB. Not sure which is at fault here yet. A workaround is to hardcore the cirrus kernel module to be 4MB (or whatever size qemu happens to be emulating). With the following kernel patch (and using either SDL1.2 or gtk for display) I was able to see the cursor properly.

--- a/drivers/gpu/drm/cirrus/cirrus_main.c

+++ b/drivers/gpu/drm/cirrus/cirrus_main.c

@@ -100,7 +100,7 @@ static int cirrus_vram_init(struct cirrus_device *cdev)

 {

        /* BAR 0 is VRAM */

        cdev->mc.vram_base = pci_resource_start(cdev->dev->pdev, 0);

-       cdev->mc.vram_size = pci_resource_len(cdev->dev->pdev, 0);

+       cdev->mc.vram_size = 1024 * 1024 * 4; //pci_resource_len(cdev->dev->pdev, 0);

        /* The last 16K of VRAM is for cursor */

        cdev->cursor_ram_size = 16 * 1024;

[Zach Reizner]

I've submitted a CL with that patch that you can try out. Disappointingly, there seems to be no way to detect the place qemu expects to find cursor bitmaps. Seeing as qemu hardcodes 4MB for the "real vram size", the best thing we can do is hardcode it as well.

[Nathan]

Great work Zach, thanks so much!

I'll apply that patch to my tree and give it a go today.

Nathan

[Nathan]

It's working now! Thanks so much.

Graphics are a bit glitchy / flickery sometimes, but I can certainly live with that. The pointer is usable!

Nathan

[Zach Reizner]

Glad it worked for you.

The glitchy / flickeryness is the same on my end and nothing new. It happens because there isn't any synchronization going on between the framebuffer and qemu redrawing the window.