On 2017-08-01 20:20, [email protected] wrote: > Host = Dual Socket Ivy Bridge Xeon(though I see the same behavior on others) > > Using an Arch Linux image I created for jailhouse, I boot into qemu and > follow the instructions for starting jailhouse. ie.: > > insmod /root/jailhouse/driver/jailhouse.ko > /root/jailhouse/tools/jailhouse enable > /root/jailhouse/configs/qemu-vm.cell > > On a corei7, this works as expected and drops me back to the shell where I > can then start another inmate such as the apci demo. > > However, when using Xeon, the shell becomes unresponsive. > > According to gdb attached to qemu, the four cores are either in > native_safe_halt() or native_apic_msr_eoi_write(). Now of course, I'm only > looking at snapshots in time right now, and haven't done full instruction > dumps. > > However, before I did that I wanted to see if this is expected behavior, or > if I potentially need to do something else to get this to work on Xeon. > > The interest comes from wanting to potentially do some light smoke tests > without needing physical hardware outside of a build machine. >
Did you use all -cpu QEMU switches mentioned in the readme and only varied the host CPU? It might be a nested KVM issue. What is your host kernel version? Can you retry with the latest one? Taking ftraces on the host, focusing on KVM events can then be a next step. In a first step, a comparison of the KVM activities between working and non-working would be good. Further analysis may eventually require to get some KVM folks involved (I'm no longer up-to-date with nested virt of KVM on Intel). Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
