On Mon, Sep 28, 2020 at 12:42:37PM +0000, Kang, Luwei wrote: > > >>>> No, it's not possible. KVM doesn't have a say on what the > > >>>> processor writes in the tracing packets. > > >>> Can KVM refuse to enable packet generation if CSbase is not zero and > > >>> CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from host? > > >> > > >> Yes, but the processor could change operating mode (and hence CSbase) > > >> while tracing is active. This is very unlikely, since it would > > >> require nonzero CS-base and a 32-bit host, but in principle not > > >> impossible (could be a firmware call, for example). > > >> > > >> The only solution is for KVM to accept both, and for QEMU to refuse a > > >> setting that does not match the host. > > >> > > > > > > So I need to add a patch in KVM to disabled the Intel PT when the > > > CSbase is not zero and the guest LIP different from the host. And this > > > limitation in qemu (disabled the PT when LIP is enabled in the host) > > > can be remove. Is that right? > > > > No, if a feature cannot be emulated, that means it cannot be enabled unless > > it > > matches the host. That's generally not a problem since Intel PT is usually > > used > > only with "-cpu host". > > > > The limitation of LIP in qemu will mask off the Intel PT in KVM > guest even with "-cpu host". e.g. This bit will be set in > SnowRidge HW and later.
This behavior can and should be changed. > > How about "-cpu cpu_model, +intel-pt" use case? The current > value of Intel PT CPUID is a constant. Can we make the ICX > CPUID as basic inforation(LIP is 0) and using "+intel-pt-lip" > to make Intel PT work on the CPU which LIP is 1 on the host? As > you mentioned before, Intel PT cannot be enabled in guest > unless it matches the host. This makes sense, but you can also make each CPU model set a default for the LIP bit. "-cpu SnowRidge,+intel-pt" could set LIP=1 by default. -- Eduardo
