On Wed, Aug 25, 2021 at 02:59:37PM +0800, Xiaoyao Li wrote: > Hi Eduardo, > > I have some question regrading Intel PT live migration. > > Commit "e37a5c7fa459 (i386: Add Intel Processor Trace feature support)" > expose Intel PT with a fixed capabilities of CPUID 0x14 for live migration. > And the fixed capabilities are the value reported on ICX(IceLake). However, > the upcoming SPR(Sapphire Rapids) has less capabilities of > INTEL_PT_CYCLE_BITMAP than ICX. It fails to enable PT in guest on SPR > machine. > > If change the check on INTEL_PT_CYCLE_BITMAP to allow different value to > allow it work on SPR. I think it breaks live migration, right?
If I understand your description correctly, I don't think that would break live migration. Generating different CPUID data for the same CPU model+flags would break live migration. However, merely allowing a wider set of configurations to work wouldn't break live migration, as long as the same CPU model+flags generates the same CPUID data on any host. > > For me, not making each sub-function of PT as configurable in QEMU indeed > makes it hard for live migration. [...] Making all sub-functions of PT configurable would be welcome. actually. That would allow us to support a wider range of configurations and keep live migration working at the same time. > [...] Why not make PT as unmigratable in the > first place when introducing the support in QEMU? I don't know, this was not my decision. Now we support live migration in a few specific cases (ICX hosts), and I assume we don't want to stop supporting it. If you just want to support a larger set of hosts when live migration is not needed, you can add support to that use case too. e.g.: "-cpu host,migratable=off" and/or "-cpu ...,intel-pt-passthrough=on" could do host passthrough of intel-pt sub-leaves (and block live migration). -- Eduardo