[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] cpu_set vs device_add (was Re: [PATCH 03/10] target-i38
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] cpu_set vs device_add (was Re: [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState) |
Date: |
Tue, 26 Feb 2013 16:46:49 -0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Feb 26, 2013 at 08:22:13PM +0100, Igor Mammedov wrote:
> On Tue, 26 Feb 2013 16:16:55 -0300
> Eduardo Habkost <address@hidden> wrote:
>
> > On Tue, Feb 26, 2013 at 08:03:16PM +0100, Igor Mammedov wrote:
> > [...]
> > > > > > > > > > Won't -cpu/parse_featurestr() simply set global properties?
> > > > > > > > > > In this
> > > > > > > > > > case, the common case would be to call "device_add XXX"
> > > > > > > > > > with no
> > > > > > > > > > extra options at all, so there's no option to be excluded
> > > > > > > > > > and no
> > > > > > > > > > special case to care about.
> > > > > > > > > That is if global properties will made to 1.5 which I highly
> > > > > > > > > doubt
> > > > > > > > > taking in account how fast patches are reviewed and accepted.
> > > > > > > > > Otherwise release would be broken.
> > > > > > > >
> > > > > > > > IMO it _has_ to make 1.5 and is a requirement to make
> > > > > > > > device_add usable
> > > > > > > > for CPU hotplug. Otherwise we would have to change the behavior
> > > > > > > > of -cpu
> > > > > > > > + device_add in an incompatible way.
> > > > > > > if all -cpu features are converted to static properties, we do
> > > > > > > not have to
> > > > > > > have global properties working. In absence of 'global
> > > > > > > properties', user
> > > > > > > will have to use the same properties at device_add that was
> > > > > > > specified at
> > > > > > > -cpu. And introduction of global properties won't regress it, it
> > > > > > > will
> > > > > > > just allow to use device_add without features specified on -cpu
> > > > > >
> > > > > > Strictly, we do not have to, but changing -cpu to set global
> > > > > > properties
> > > > > > only later would change the behavior of "-cpu XXX,foo=1,bar=2"
> > > > > > followed
> > > > > > by "device_add XXX" in an incompatible way. So if our long-term
> > > > > > plan is
> > > > > Could you explain how ^^^ it will be incompatible, pls?
> > > >
> > > > Suppose that "foo" defaults to 0, and we run: "-cpu XXX,foo=1", followed
> > > > by "device_add XXX".
> > > >
> > > > Without globals/defaults set by -cpu, the above will create a new CPU
> > > > with foo=0.
> > > >
> > > > With globals/defaults set by -cpu, the above will create a new CPU with
> > > > foo=1.
> > > >
> > > > If I recall correctly, we agreed that the latter is the behavior we
> > > > wanted (because it is simpler for users, matches the fact that "-cpu"
> > > > already affects multiple CPU devices [it already affects all the CPUs
> > > > created on startup], and is the most common use-case [creating CPUs that
> > > > look basically the same]).
> > > Yes, that is the goal. I wouldn't say incompatible if user will start
> > > QEMU with "-cpu XXX,foo=1" and then use "device_add XXX,foo=1". That's a
> > > strict minimum that would work for hot-plug. Plain "device_add XXX" is an
> > > invalid in this case since it won't produce the same CPU.
> > > So later on top of "-cpu XXX,foo=1" + "device_add XXX,foo=1" we add up
> > > conversion of -cpu to global properties it shouldn't break anything, only
> > > add
> > > new option to create the same CPU usin "device_add XXX", users will still
> > > be
> > > able to use "device_add XXX,foo=1" if desired.
> > >
> > > I hope that -cpu => global properties will make it in 1.5, but it is not
> > > must have show-stopper for hot-plug if it misses it.
> > >
> >
> > OK, so without it we would only support a very strict subset of
> > device_add command (specifically: only if the device_add arguments match
> > exactly what was given to -cpu).
> >
> > This would work if carefully and clearly documented, true. But if we are
> > going to have such a severe limitation, why not use "cpu_set" in 1.5
> > instead? cpu_set is not perfect, not the long-term solution we want, and
> > it is also very limited, but at least it is already supported by libvirt
> > and won't let users shoot their own foot.
> cpu_set is backup plan that I'm working on.
> So in case properties/subclasses won't make into 1.5, I'll post cpu_set
> alternative.
OK. But I would also suggest that we follow the cpu_set plan in case we
don't manage to make "-cpu" set defaults/global-properties in 1.5.
--
Eduardo
- Re: [Qemu-devel] [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState, (continued)
- Re: [Qemu-devel] [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState, Eduardo Habkost, 2013/02/26
- Re: [Qemu-devel] [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState, Igor Mammedov, 2013/02/26
- Re: [Qemu-devel] [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState, Eduardo Habkost, 2013/02/26
- Re: [Qemu-devel] [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState, Igor Mammedov, 2013/02/26
- Re: [Qemu-devel] [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState, Eduardo Habkost, 2013/02/26
- Re: [Qemu-devel] [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState, Igor Mammedov, 2013/02/26
- Re: [Qemu-devel] [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState, Eduardo Habkost, 2013/02/26
- Re: [Qemu-devel] [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState, Igor Mammedov, 2013/02/26
- [Qemu-devel] cpu_set vs device_add (was Re: [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState), Eduardo Habkost, 2013/02/26
- Re: [Qemu-devel] cpu_set vs device_add (was Re: [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState), Igor Mammedov, 2013/02/26
- Re: [Qemu-devel] cpu_set vs device_add (was Re: [PATCH 03/10] target-i386: move hyperv_* static globals to CPUState),
Eduardo Habkost <=
[Qemu-devel] [PATCH 02/10] target-i386: cpu: convert existing dynamic properties into static properties, Igor Mammedov, 2013/02/24
[Qemu-devel] [PATCH 07/10] target-i386: convert 'check' and 'enforce' to static properties, Igor Mammedov, 2013/02/24
[Qemu-devel] [PATCH 05/10] target-i386: convert 'hv_relaxed' to static property, Igor Mammedov, 2013/02/24
[Qemu-devel] [PATCH 08/10] target-i386: cleanup 'foo' feature handling', Igor Mammedov, 2013/02/24
[Qemu-devel] [PATCH 04/10] target-i386: convert 'hv_spinlocks' to static property, Igor Mammedov, 2013/02/24