On 18 October 2016 at 18:16, Andrew Jones <drjo...@redhat.com> wrote: > On Fri, Oct 14, 2016 at 09:48:28AM +0200, Andrew Jones wrote: >> The feature needs to be managed in order for users to be able to trade-off >> features exposed vs. migratability. If the lack of an explicit pmu=on >> means either you get a PMU, when it's available, or you don't, when it's >> not, then managing the feature becomes more difficult. Also, libvirt >> already manages this cpu property for x86, and there it defaults off. > > We discussed this today with Andrea. He says libvirt doesn't mind the > default being on. x86 defaults pmu off, ppc defaults pmu on. I guess > we might as well stick with on, it should make things easier.
If we don't have a clear architectural consensus then I think we should stick with 'default is on'. That seems less confusing than "it was off, then in 2.7 it was on, then in 2.8 it's off again". > If we switch to default on, then the only way to turn it off is with > pmu=off added to the command line. So we'll know if pmu=off is given > and we can just ignore it for virt-2.7. If we don't care about keeping > the property off the virt-2.7 command line then there's no need for a > tri-state. I don't much mind what virt-2.7 does with pmu=anything, I just don't want a tri-state, and particularly I don't want a tri-state just to get a particular behaviour out of a machine=virt-2.7 command line that wouldn't have worked on the real 2.7 release. So we should arrange it whichever way is most convenient, I think. thanks -- PMM