On 27 October 2016 at 21:53, Wei Huang <w...@redhat.com> wrote: > On 10/27/2016 12:15 PM, Peter Maydell wrote: >> Right, but at the moment the commit message says there's no >> PMU in TCG at all. What's missing that causes there not to be one? >> (I think maybe we just don't report it in the feature register, >> which might be a bug.) > > This sounds like a bug (or incomplete). In current version of QEMU, if I > forced vPMU declaration in the feature register under TCG mode, PMU > driver will be loaded in VM. But as soon as "perf stat" is executed, > guest VM panic. I think some features, like PMU IRQ, is still missing > for TCG to turn vPMU on. I will debug it further.
You're right, we don't have the PMU IRQ implemented. I wouldn't expect that to cause the guest to panic, though... > Let me clarify. Assuming we can get TCG mode to support VM's PMU driver > (see discussion above, only cycle counter supported for TCG), will the > following be sufficient? > (1) ,pmu=on > perf driver can be loaded in VM, and "perf" command can use HW counters > to profile. > (2) ,pmu=off > perf feature can't be detected, so the perf driver can't be loaded > inside VM. "perf" can't use HW perf counters. But PMU registers (PMCR, > PMCCNTR, ...) can still be accessed inside VM. I think that's what we get today (with this patch set). But it would seem more consistent if pmu=off didn't provide the PMCR, PMCCNTR, etc to the guest under TCG in the same way that you don't get them under KVM if you say pmu=off. Anyway, I think that these patches are the right thing for KVM, so I'm going to apply them to target-arm.next. We should probably look at straightening out the TCG situation, but we can do that with a separate patchset (and perhaps not for 2.8). Thanks for your patience in working through all the revisions of this series. -- PMM
