On Thu, Apr 02, 2015 at 09:09:07AM +0200, Michael Mueller wrote:
> On Wed, 1 Apr 2015 20:05:24 -0300
> Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote:
>
> > > >
> > > > If you don't want to encode that knowledge in libvirt or other
> > > > management software for s390, it looks like you need something like a
> > > > "stable-abi-safe" field on CpuDefinitionInfo?
> > >
> > > Exactly that fulfills the "name" field for s390 already in my view.
> > >
> > > And cpu model "none" just means that QEMU does not manage the cpu model. That's also
> > > the reason why I initially returned an empty "[]" model and not "none". This somewhat
> > > convinces me to go back to this approach...
> >
> > I understand the reasons for your approach and it seems to work for
> > s390, but the only problem I see is that you are adding an additional
> > (undocumented?) s390-specific constraint to the semantics of
> > query-cpu-models: that the model name will appear on the list only if it
> > can be safely migratable. This may prevent us from unifying CPU model
> > code into generic code later.
>
> I agree that an aliases is something different compared with the CPU model none as
> there is a CPU class representing it. And thus, when implicitly or explicitly selected,
> shall be presented in the CPU definition list as well. If I would set "runnable" to
> false as it now (bad), it would be sorted out by the "considered for migration" test but it
> would be misleading as it is always runnable. Though an additional field like "migrate-able"
> could express that characteristic.
Exactly.
>
> >
> > But if we add a simple stable-abi-safe field to the list (even if s390
> > set it to to true for all models and omit aliases and "none" in this
> > first version), we will have clearer semantics that can still be
> > honoured by other architectures (and by generic code) later.
>
> To be honest I currently don't right get the idea that you follow with that
> stable-abi-save field... But eventually yes (I wrote this before the section above)
>
> The stable-abi-save field means: "Take me into account for whatever kind of
> CPU model related comparison you perform between two running QEMU instances as I
> represent a well defined aspect.
Yes. "stable-abi-safe" would mean that nothing guest-visible will change
in the CPU model when running a different QEMU version or running in a
different host, thus making it safe to live-migrate (as long as you keep
the same machine+accelerator and don't change other guest-visible
configuration in the QEMU command-line, of course). That's a constraint
we already keep in the x86 CPU models, except for "-cpu host".
In other words, it means "as long as the name matches the query-cpus
output from the source host, it is guaranteed to be safe to
live-migrate". Which is the constraint you need, right?
(I am not 100% sure about the naming. Maybe we should call it
"live-migration-safe"?)
>
> Thus CPU model none will be { "name": "none", "runnable: true, "stable-abi-save": false } and
> the aliases can be represented as { "name": <alias>, "runnable": <true|false>, "stable-abi-save":
> false } in the s390 case, right?
Exactly. We don't need to return them in the first version if you don't
need to (althought I don't see a reason to not return them). It will
just allow us to return them in the future.
--
Eduardo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list