[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH V6 0/2] Add option to configure guest

From: Peter Maydell
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH V6 0/2] Add option to configure guest vPMU
Date: Tue, 18 Oct 2016 18:22:41 +0100

On 18 October 2016 at 18:16, Andrew Jones <address@hidden> 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.

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]