Wednesday, May 17, 2017

Turbo in text-only mode

Turbo is now booting in text-only mode, with a guest that has exclusive access to the NVIDIA M2000 card.

Refining patches

Refining my macOS enablement patches for spicy.

Dedicated NVIDIA card mapping on Turbo

I can connect to my f25-turbo guest with spice, and I see a graphic display. But I cannot login. It does not seem to take keyboard or mouse input.

Apparently, it successfully mapped the NVIDIA card. Here is dmesg on the host:

[May17 11:01] VFIO - User Level meta-driver version: 0.3
[  +0.014174] vfio-pci 0000:03:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[  +0.011820] vfio_pci: add [10de:1430[ffff:ffff]] class 0x000000/00000000
[  +0.000084] vfio_pci: add [10de:0fba[ffff:ffff]] class 0x000000/00000000
[  +0.539013] vfio_ecap_init: 0000:03:00.0 hiding ecap 0x1e@0x258
[  +0.000085] vfio_ecap_init: 0000:03:00.0 hiding ecap 0x19@0x900
[  +0.001086] pmd_set_huge: Cannot satisfy [mem 0xe0000000-0xe0200000] with a huge-page mapping due to MTRR override.

The 10de:1430 PCI ID is the M2000 card.

I can ssh into the guest too. But lspci seems to hang.

There are appropriate entries under /sys:

# echo /sys/bus/pci/devices/*/vendor
/sys/bus/pci/devices/0000:00:00.0/vendor
/sys/bus/pci/devices/0000:00:01.0/vendor
/sys/bus/pci/devices/0000:00:01.1/vendor
/sys/bus/pci/devices/0000:00:01.3/vendor
/sys/bus/pci/devices/0000:00:02.0/vendor
/sys/bus/pci/devices/0000:00:03.0/vendor
/sys/bus/pci/devices/0000:00:04.0/vendor
/sys/bus/pci/devices/0000:00:05.0/vendor
/sys/bus/pci/devices/0000:00:06.0/vendor
/sys/bus/pci/devices/0000:00:06.1/vendor
/sys/bus/pci/devices/0000:00:06.2/vendor
/sys/bus/pci/devices/0000:00:06.7/vendor
/sys/bus/pci/devices/0000:00:07.0/vendor
/sys/bus/pci/devices/0000:00:08.0/vendor
/sys/bus/pci/devices/0000:00:09.0/vendor
/sys/bus/pci/devices/0000:00:0a.0/vendor
/sys/bus/pci/devices/0000:00:0b.0/vendor

It seems to have initialized somewhat properly too:

# cat /sys/bus/pci/devices/0000:00:0b.0/driver/module/initstate
live

Managing the system remotely proves difficult.

• When I run virt-manager over X11, the virt-manager window opens, but it complains that it can't find a polkit agent to authenticate.
• If I do a ssh -Y root@turbo, then the virt-manager window does not open. It's a behavior that I had already observed: when I had a graphical console, it ignored the DISPLAY variable and went straight to the local display (another "security" feature? presumably).
• So I restarted Muse and tried to connect from it using a remote session. But then I hit another bug that I had not seen before: it shows a very rapid loop with a notification that virt-manager requires another software. The notification is dismissed as soon as it appears. So there is no way to know which software is missing.

I love it when multiple bugs combine perfectly to get in the way. So many ways to achieve my objective, none of them work, most of them fail due to some inane sense of "increased security because we know better than you do".