I did some follow-up tests with qemu/ovmf. The main command was still: qemu-system-x86_64 -enable-kvm -drive file=grub.img -drive if=pflash,readonly,file=ovmf_x64.bin
with these in addition, respectively: 1. -device usb-ehci -device usb-kbd 2. -device nec-usb-xhci -device usb-kbd Here are the results: 1. on usb-ehci, with `nativedisk` I would lose keyboard control 2. on usb-ehci, with `nativedisk; insmod usb_keyboard` I could get a "usb_keyboard0" input terminal and keyboard control 3. on nec-usb-xhci, with `nativedisk` I would not lose keyboard control 4. on nec-usb-xhci, with `nativedisk; insmod usb_keyboard` I could not get any usb_keyboard input terminal but would not lose keyboard control I then start the VM without any USB host/device attached, ran `nativedisk` and then `lsmod`, I can see that o/u/ehci are all loaded automatically. I happened to notice that nativedisk can take a parameter as well, and I got one more result after that: 5. on usb-ehci, with `nativedisk pata` I would not lost keyboard control. So I guess I can conclude, usb_keyboard input terminal does rely on a working usb host controller grub driver, and if the corresponding one is loaded, the user will lose control to the USB keyboard (before a manual `insmod usb_keyboard`), and if it is not loaded, USB keyboard control will remain intact through console and the UEFI driver. I still don't understand why all disk access would (need to) be lost once _any_ of the so-called relevant module is loaded though, even when the disk is not attached to any of those kinds of hosts. For example, why can't virtio-blk/scsi drives at the very least remain "intact" just like the "XHCI keyboard"? But I guess that's a bit off from the original topic and I am not sure if I am interested in digging further on this anyway. So I'll just leave it *shrug* Anyway, thanks again! Regards, Tom From: Andrei Borzenkov <[email protected]> Sent: Monday, May 22, 2017 11:38 AM To: Tom Yan; [email protected] Cc: Bjørn Forsman Subject: Re: usb_keyboard not available as a terminal input? 21.05.2017 23:02, Tom Yan пишет: > It seems like the "disappearance" of storage drives after `insmod ehci` is > not relevant to whether the drives are USB ones. > > For example, if I start a virtual machine with this: > qemu-system-x86_64 -enable-kvm -drive file=grub.img -drive > if=pflash,readonly,file=ovmf_x64.bin > > And do this after grub started: > `ls; insmod ehci; ls` > > It will print only _one_ line with multiple storage drives: > (hd0), (hd0, gpt1), (fd0), (fd1), (cd0) > which indicates that _everything_ is gone after the insmod command. Same case > with ohci/uhci. > > This seems like a bug to me. > it works as designed. USB driver change hardware state, so we cannot give control back to firmware. You need to use direct hardware access drivers from this point on. "nativedisk" command handles disk access for you. This is still best effort. We hope that firmware won't try to access hardware on its own, but we do not really know it nor control it. _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
