Hey all,
So I've began work on implementing APIC support in my kernel. However, this required me to do some fiddling around with what happened first (e.g.: the memory manager is initialized before anything else in the system). However, I'm now getting really strange warnings from QEMU, like:
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
I've never seen these warnings emitted by Qemu before, and am wondering if they're a bug with Qemu on windows, a bug with Qemu in general, or something in my kernel (or its dependencies) is attempting to utilize a feature I'm unaware of. Or something else I haven't thought of yet. To further exacerbate the problem, my kernel prints its "Loading kernel" message, then Qemu immediately triple faults (though I can't tell that this is actually happening). Debugging it with GDB gives me nothing -- Qemu just immediately exits. I can't enable interrupts at this stage because I need to map the APIC, and I can't do that until my memory manager is initialized. I'd prefer not to set up the PIC, then have to disable it to switch over to the APIC later on, but is this something I should do? Or should I just go immediately to the APIC or PIC depending on what's supported? Finally, is there any way around these strange QEMU warnings? Some of these, like X2APIC, should be supported, I'd think. For reference, I'm using Qemu version 5.0.0. This does, however, also happen on Qemu 4.2.0.
Possible QEMU bug or something else
Re: Possible QEMU bug or something else
Hi,
You need to compile qemu with TCG support for these features. Then you have to specify them via "-cpu IvyBridge,+pcid,+x2apic" for example (you need to list only the features that are not enabled by default for the specified CPU). If your host CPU supports these features and you have kvm installed, there's an easy way out, switch from TCG to KVM with "-enable-kvm -cpu host". I would suggest to use kvm if you can anyway, as it runs your vm much-much faster. Not sure about how kvm works under Windows though, haven't used it myself. Under Linux, you list the host CPU features with "cat /proc/cpuinfo | grep flags", and the kvm kernel module is automatically installed and enabled (use "lsmod | grep kvm" to check).
About the PIC, you need to reroute it and disable it, even if you don't receive a single interrupt. That's because many APIC hardware has a PIC-legacy emulation layer, and you'll get spurious interrupts later with APIC enabled if you haven't disabled the PIC properly. Not all hardware affected by this, but better to be safe than sorry.
Cheers,
bzt
You need to compile qemu with TCG support for these features. Then you have to specify them via "-cpu IvyBridge,+pcid,+x2apic" for example (you need to list only the features that are not enabled by default for the specified CPU). If your host CPU supports these features and you have kvm installed, there's an easy way out, switch from TCG to KVM with "-enable-kvm -cpu host". I would suggest to use kvm if you can anyway, as it runs your vm much-much faster. Not sure about how kvm works under Windows though, haven't used it myself. Under Linux, you list the host CPU features with "cat /proc/cpuinfo | grep flags", and the kvm kernel module is automatically installed and enabled (use "lsmod | grep kvm" to check).
About the PIC, you need to reroute it and disable it, even if you don't receive a single interrupt. That's because many APIC hardware has a PIC-legacy emulation layer, and you'll get spurious interrupts later with APIC enabled if you haven't disabled the PIC properly. Not all hardware affected by this, but better to be safe than sorry.
Cheers,
bzt
-
- Member
- Posts: 5575
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Possible QEMU bug or something else
Did you change the command line you're using to invoke QEMU? Those warnings indicate you've selected CPU features that aren't supported by QEMU's binary translator.Ethin wrote:I've never seen these warnings emitted by Qemu before, and am wondering if they're a bug with Qemu on windows, a bug with Qemu in general, or something in my kernel (or its dependencies) is attempting to utilize a feature I'm unaware of.
Are you trying to use any of the features listed in the warning? If not, pick a different CPU to emulate.
If you really do need those four missing CPU features, you'll have to use hardware virtualization. On Windows, you can use HAXM or WHPX. (Fair warning: I've never tried it myself, so I don't know how well it will work.)
You would need to write the code for it first!bzt wrote:You need to compile qemu with TCG support for these features.
Re: Possible QEMU bug or something else
True, but I'm pretty sure these are already implemented. I've only used "-cpu host,+x2apic,+tsc-deadline", and it worked for me, but look:Octocontrabass wrote:You would need to write the code for it first!bzt wrote:You need to compile qemu with TCG support for these features.
- all of fma, pcid, x2apic, tsc-deadline enabled for cpu "Haswell" here.
- furthermore, for x2apic: here and here for example.
- and for tsc-deadline msr here.
But kvm emulation also works for all of these, so if the OP can do kvm, they definitely should. Just for the records, x2apic and tsc-deadline works since SandyBridge, it's only fma and pcid that requires Haswell. If I were in the OP shoes, I'd reconsider if that latter two features are really necessary for my kernel.
Cheers,
bzt
Re: Possible QEMU bug or something else
OK, so I've switched to Skylake-Client-v3 (I can't use -cpu host). Was using EPYC-v3. Still gives me those warnings, which is odd. But the problem is fixed -- my kernel page faults now but I can (hopefully) fix that.