Description of problem:
On armv7hl (Fedora 20):
$ grep VIRTIO.CONSOLE /boot/config-3.11.0-3.fc20.armv7hl
# CONFIG_VIRTIO_CONSOLE is not set
whereas on x86_64 (Fedora 19):
$ grep VIRTIO.CONSOLE /boot/config-3.10.9-200.fc19.x86_64
I checked and virtio-serial works fine on arm (using virtio-mmio),
so we should enable it on arm too.
Version-Release number of selected component (if applicable):
It's enabled as a module in the lpae config fwiw.
OK, although this is for a guest kernel, so there's
not really a need for us to use the LPAE kernel -- it'd be
nice if it just worked with any kernel that the guest
I actually tried to see if I could use the LPAE kernel
but it's a non-starter. That kernel only supports Samsung
Exygnos devices. qemu only emulates Versatile Express A15.
Loading the vexpress-v2p-ca15-tc1.dtb with the LPAE kernel
0xc08677b7 <__log_buf+591>: "\202\nError: unrecognized/unsupported device tree compatible list:\n[ 'arm,vexpress,v2p-ca15,tc1' 'arm,vexpress,v2p-ca15' 'arm,vexpress' ]\n"
0xc086784f <__log_buf+743>: "\202Available machine support:\n\nID (hex)\tNAME"
0xc086788f <__log_buf+807>: "\202ffffffff\tSAMSUNG EXYNOS5 (Flattened Device Tree)"
0xc08678cf <__log_buf+871>: "\202\nPlease check your kernel config and/or bootloader."
So we really do need virtio-console to be supported in the regular kernel.
I built a scratch kernel with virtio-console support and
confirmed it lets libguestfs work:
I went ahead and changed this.
kernel-3.11.2-301.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.11.2-301.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
kernel-3.11.2-301.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This caused issues in the qemu/vexpress image and, from memory, the highbank HW in the past and hence the reason it was disabled. It might well be fixed but it would be useful to actually CC ARM people in to check why it might have been explicitly disabled. Has it been confirmed those issues are now fixed?
(In reply to Peter Robinson from comment #9)
> This caused issues in the qemu/vexpress image and, from memory, the highbank
> HW in the past and hence the reason it was disabled. It might well be fixed
> but it would be useful to actually CC ARM people in to check why it might
> have been explicitly disabled. Has it been confirmed those issues are now
I did CC ARM people. The bug was assigned to the ARM kernel maintainer.
> I did CC ARM people. The bug was assigned to the ARM kernel maintainer.
But not added to the ARMTracker bug or anyone else that have history as to why it might have been originally disabled
Ultimately it doesn't matter if there's confirmation that the original issue is now fixed
I can't find anything related to virtio-console, highbank and
vexpress, either on the mailing list nor on Google (except for
Also note virtio-serial is not some nice-to-have, it's a vital
device for virtualization, enabling libguestfs and qemu-ga.
> Also note virtio-serial is not some nice-to-have, it's a vital
> device for virtualization, enabling libguestfs and qemu-ga.
I don't disagree, I'm just mentioning the reason it was disabled was because it broke things in the past so we need to confirm this is no longer the case.
I've just got around to using this new kernel and can report that
virtio-console/virtio-serial works, so thanks.