FS#46505 - [linux] should be built w CONFIG_USB_SERIAL_CONSOLE=y to use usb serial converters on boot
Attached to Project:
Arch Linux
Opened by Niccolò Belli (darkbasic) - Thursday, 01 October 2015, 07:57 GMT
Last edited by Jan Alexander Steffens (heftig) - Friday, 26 October 2018, 18:58 GMT
Opened by Niccolò Belli (darkbasic) - Thursday, 01 October 2015, 07:57 GMT
Last edited by Jan Alexander Steffens (heftig) - Friday, 26 October 2018, 18:58 GMT
|
Details
If you enable this option theoretically users should be able
to add "usb_common usbcore usbserial pl2303" to MODULES= in
mkinitcpio.conf to log early boot messages with a usb serial
converter.
Please see this topic: https://bbs.archlinux.org/viewtopic.php?pid=1566230 |
This task depends upon
Closed by Jan Alexander Steffens (heftig)
Friday, 26 October 2018, 18:58 GMT
Reason for closing: Fixed
Additional comments about closing: 4.19.arch1-1
Friday, 26 October 2018, 18:58 GMT
Reason for closing: Fixed
Additional comments about closing: 4.19.arch1-1
Also CONFIG_USB_SERIAL_CONSOLE=n prevents debugging kernel crashes (and you DEFINITELY want your users to report bugs).
USB: Remove EXPERIMENTAL designation from USB serial/ Kconfig entries
Since nothing under the USB serial/ directory seems to be obviously
experimental, remove the EXPERIMENTAL dependency from all of those
Kconfig entries.
...
Seems like maybe it was never intended to be experimental at all?
Though perhaps given that the function of vfio is to preempt drivers binding to devices, it ought to just be in the kernel already?
softdep: post: vfio_iommu_type1 vfio_iommu_spapr_tce
depends:
$ modinfo vfio-pci | grep dep
depends: vfio,irqbypass,vfio_virqfd
I guess it would have to be all the vfio- mods
I checked for other distros:
Debian doesn't have CONFIG_USB_SERIAL_CONSOLE=y
Fedora has CONFIG_USB_SERIAL_CONSOLE=y
None of them have CONFIG_VFIO=y (only m)
At least Arch will be in sync with others.
My thinking on VFIO in the kernel or not:
Leave as module:
* Most people likely don't use this
* What's next? There's a reason the kernel is modular; let's not bloat it
* In-line with other distributions
Change to static compile:
* VFIO is special in it's function. Its not a physical device, its a meta driver for binding to devices. PCI_STUB was marked y!
* Its not that big
* It would greatly simplify the configuration of VFIO if people didn't have to generate special initramfs images to use it.
I'm sure there are things I don't know though, anyone have other arguments for not putting it in the kernel as 'y'?
CONFIG_USB_SERIAL_CONSOLE can't be module. It's either Y or N:
https://cateee.net/lkddb/web-lkddb/USB_SERIAL_CONSOLE.html
Is this true? Is there a parallel thread on this somewhere we missed?
https://www.reddit.com/r/VFIO/comments/9qizja/archlinux_since_41816_vfiopci_is_compiledin_no/
I still don't think making all the USB host and hid drivers builtin a good idea though. Sometimes the "disability" could be quite important in case of a bug or such, unless again there's a way to "blacklist" builtin driver that I am not aware of.
While CONFIG_USB_SERIAL_CONSOLE can only be y or n, the db site you guys having been quoting ONLY states that it requires CONFIG_USB_SERIAL to be y. So does the feature not practically work without all the m to y changes in the commit or what?
Is there a way to blacklist a pci device with the radeon driver? I cannot blacklist the whole module since I have another AMD card with a different model id.
You need a script like the one described here:
https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Script_variants
Since its not longer a module, you need to put it elsewhere in the initramfs by using HOOKS.
I haven't had time to update my system, but I suggested the config and had someone confirm that it worked in this reddit post:
https://www.reddit.com/r/VFIO/comments/9qizja/archlinux_since_41816_vfiopci_is_compiledin_no/e8ccujm/
Be sure to scroll down to see that the install script needed some lines for the binary dependencies.
Once I've had time to do this myself I'll see if I can get it added to the wiki...
Thanks for the tip. I've tried it, but unfortunately it didn't help. The device is still bound to the radeon driver :\
# grep '^HOOKS' /etc/mkinitcpio.conf
HOOKS=(base udev vfio autodetect modconf block filesystems keyboard fsck)
# cat /etc/initcpio/hooks/vfio
#!/usr/bin/ash
run_hook() {
echo vfio-pci > /sys/bus/pci/devices/0000:09:00.0/driver_override
echo vfio-pci > /sys/bus/pci/devices/0000:09:00.1/driver_override
}
# lspci -knn -d 1002:683d
08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X] [1002:683d]
Subsystem: Gigabyte Technology Co., Ltd Cape Verde XT [Radeon HD 7770/8760 / R7 250X] [1458:2283]
Kernel driver in use: radeon
Kernel modules: radeon, amdgpu
Oh wait, you're overriding the devices with address 09.00.0/1,
But your lspci shows the device at 08:00.0. Is that the boot vga then or did you override the wrong one maybe?
% lspci -nnk -d 1002:67b0
09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT / Grenada XT [Radeon R9 290X/390X] [1002:67b0]
Subsystem: PC Partner Limited / Sapphire Technology R9 290X Tri-X OC [174b:e285]
Kernel modules: radeon, amdgpu
# cat /etc/initcpio/install/vfio
#!/bin/bash
build() {
add_runscript
}
help() {
cat <<EOF
Configure vfio
EOF
}
How were you doing it before vfio and usb got compiled in?
MODULES=(vfio vfio_iommu_type1 vfio_pci vfio_virqfd)
and set the following in /etc/modprobe.d/vfio.conf:
options vfio-pci ids=1002:67b0,1002:aac8
This works like a charm with the previous kernel. I've also wrote a small SUID binary (https://github.com/mrschyte/vfioctl) which rebinds a USB hub and my soundcard to vfio when I start the VM.
Unfortunately I cannot rebind the VGA since that results in a kernel panic.
Are you saying it wasn't picking up kernel command line params? Or you're saying now the initramfs scripts work?
After switching to systemd-boot, I can now see the vfio-pci.ids parameter in /proc/cmdline
I've also removed the vfio initramfs script; turns out it wasn't needed at all.