On Tue, 26 Feb 2013 16:16:55 -0300 Eduardo Habkost <ehabk...@redhat.com> 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. > > -- > Eduardo > -- Regards, Igor
