OK, thanks for the reply. In that case I think I will just forego KVM support and base it 100% around QEMU itself. I also fear I could run into other problems along the same lines, including possibly unsolvable problems since it is not given that the underlying virtualization technology (i.e. VMX) would support all the extensions I'm making, given its purpose is to provide a faithful emulation of the host architecture.
2014-08-04 14:22 GMT+02:00 Paolo Bonzini <pbonz...@redhat.com>: > Il 04/08/2014 10:37, Morty Andersen ha scritto: > > Hi > > > > I'm working on an extension to QEMU (target i386). This involves adding > > new MSR's. I've got it working in non-KVM mode by adding these MSR's to > > the state and adding extra cases to helper_wrmsr(), helper_rdmsr(). The > > guest can now read/write these MSR's as expected. However, it fails when > > running in KVM-mode. Specifically, writing the MSR's causes GPF. Note > > that these MSR's are not natively supported by the host CPU. I don't > > know enough about Intel's VMX to tell if it is even reasonable to expect > > that this could work for a non-natively supported MSR. As far as I can > > read in the VMX documentation, the hypervisor can setup a bitmap of > > which MSR's should cause trap's to the hypervisor and which shouldn't. I > > guess it would be the KVM kernel module that does this based on input it > > receives from QEMU. But I haven't been able to find the part of QEMU > > that negotiates this. I guess the solution for me is to set the > > necessary bits to that access to the new MSR's causes traps. Next, I > > need to add/modify the trap handler so that it can handle the MSR's. > > Hi, > > handling of the MSRs in KVM is done entirely in the hypervisor. QEMU > only gets/sets them in order to support migration. You need to modify > the KVM kernel module for the VM to recognize your special MSRs. > > Paolo >
