On 24/06/2015 17:58, Eduardo Habkost wrote:
> > 3) regarding "enforce", there are indeed some cases where it would break:
> >
> > - Haswell/Broadwell CPU model after TSX removal
> >
> > - qemu64 with KVM
> >
> > - pretty much everything including qemu64 with TCG
>
> - Everything involving KVM
On Wed, Jun 24, 2015 at 04:38:51PM +0200, Paolo Bonzini wrote:
[...]
> 1) libvirt should _not_ change the flags that the user passes via XML
> just because it thinks that QEMU has those flags. This makes it
> possible for libvirt to keep cpu_map.xml up-to-date without worrying
> about versioning.
Am 24.06.2015 um 16:57 schrieb Michael S. Tsirkin:
> On Wed, Jun 24, 2015 at 04:35:13PM +0200, Andreas Färber wrote:
>> Am 24.06.2015 um 16:19 schrieb Michael S. Tsirkin:
>>> On Wed, Jun 24, 2015 at 11:16:51AM -0300, Eduardo Habkost wrote:
> IMHO -M pc is not supposed to mean "can break at any
On Wed, Jun 24, 2015 at 04:35:13PM +0200, Andreas Färber wrote:
> Am 24.06.2015 um 16:19 schrieb Michael S. Tsirkin:
> > On Wed, Jun 24, 2015 at 11:16:51AM -0300, Eduardo Habkost wrote:
> >>> IMHO -M pc is not supposed to mean "can break at any time".
> >>
> >> It means "it may have new host-side r
Am 24.06.2015 um 16:19 schrieb Michael S. Tsirkin:
> On Wed, Jun 24, 2015 at 11:16:51AM -0300, Eduardo Habkost wrote:
>>> IMHO -M pc is not supposed to mean "can break at any time".
>>
>> It means "it may have new host-side requirements and may become runnable
>> in your host (or require additional
On 24/06/2015 16:54, Peter Maydell wrote:
> > It's certainly okay for libvirt and OpenStack to use the host CPU
> > features in order to check whether a node will run a given VM. However,
> > libvirt should trust that QEMU developers will not prevent a VM from
> > running on a previously viable
On 24 June 2015 at 15:38, Paolo Bonzini wrote:
> It's certainly okay for libvirt and OpenStack to use the host CPU
> features in order to check whether a node will run a given VM. However,
> libvirt should trust that QEMU developers will not prevent a VM from
> running on a previously viable host
On 24/06/2015 16:16, Eduardo Habkost wrote:
> > So any single CPU flag now needs to be added in
> > - kvm
> > - qemu
> > - libvirt
> >
> > Next thing libvirt will decide it's a policy thing and so
> > needs to be pushed up to openstack.
>
> I don't think that will happen, but if they really dec
On Wed, Jun 24, 2015 at 11:24:46AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 23, 2015 at 11:34:45PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Jun 23, 2015 at 02:11:22PM -0300, Eduardo Habkost wrote:
> > > Even if it is a bug fix. If it is a change that can make the VM
> > > unrunnable, it need
On Tue, Jun 23, 2015 at 11:34:45PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2015 at 02:11:22PM -0300, Eduardo Habkost wrote:
> > Even if it is a bug fix. If it is a change that can make the VM
> > unrunnable, it needs to be controlled by a separate flag, not by the
> > machine-type.
>
>
On Wed, Jun 24, 2015 at 11:18:18AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 23, 2015 at 11:28:06PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Jun 23, 2015 at 02:42:37PM -0300, Eduardo Habkost wrote:
> > > On Tue, Jun 23, 2015 at 07:29:15PM +0200, Andreas Färber wrote:
> > > > In summary you se
On Wed, Jun 24, 2015 at 11:16:51AM -0300, Eduardo Habkost wrote:
> > IMHO -M pc is not supposed to mean "can break at any time".
>
> It means "it may have new host-side requirements and may become runnable
> in your host (or require additional command-line flags to run) at any time".
That would b
On Tue, Jun 23, 2015 at 11:28:06PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2015 at 02:42:37PM -0300, Eduardo Habkost wrote:
> > On Tue, Jun 23, 2015 at 07:29:15PM +0200, Andreas Färber wrote:
> > > In summary you seem to be saying that all the years we have spent
> > > fiddling around wi
On Tue, Jun 23, 2015 at 11:23:16PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2015 at 05:42:04PM +0100, Daniel P. Berrange wrote:
> > On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
> > > > On Tue,
On Wed, Jun 24, 2015 at 11:31:37AM +0100, Daniel P. Berrange wrote:
> On Wed, Jun 24, 2015 at 12:21:57PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Jun 24, 2015 at 11:20:50AM +0200, Jiri Denemark wrote:
> > > On Tue, Jun 23, 2015 at 14:32:00 +0200, Andreas Färber wrote:
> > > > Am 08.06.2015 um 2
On 24/06/2015 12:21, Michael S. Tsirkin wrote:
> > QEMU provides stable ABI for x86 CPUs only if you use -cpu ...,enforce.
> > Without enforce the CPU may change everytime a domain is started or
> > migrated. A small example: let's say a CPU model called "Model" includes
> > feature "xyz"; when Q
On Wed, Jun 24, 2015 at 09:52:09AM +0100, Daniel P. Berrange wrote:
> On Tue, Jun 23, 2015 at 11:23:16PM +0200, Michael S. Tsirkin wrote:
> >
> > So any single CPU flag now needs to be added in
> > - kvm
> > - qemu
> > - libvirt
>
> This is in fact already the case, and it will also possibly need
On Wed, Jun 24, 2015 at 12:21:57PM +0200, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2015 at 11:20:50AM +0200, Jiri Denemark wrote:
> > On Tue, Jun 23, 2015 at 14:32:00 +0200, Andreas Färber wrote:
> > > Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> > > >> To help libvirt in the transition, a x8
On Wed, Jun 24, 2015 at 11:20:50AM +0200, Jiri Denemark wrote:
> On Tue, Jun 23, 2015 at 14:32:00 +0200, Andreas Färber wrote:
> > Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> > >> To help libvirt in the transition, a x86-cpu-model-dump script is
> > >> provided,
> > >> that will generate a con
On Tue, Jun 23, 2015 at 14:32:00 +0200, Andreas Färber wrote:
> Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> >> To help libvirt in the transition, a x86-cpu-model-dump script is provided,
> >> that will generate a config file that can be loaded using -readconfig,
> >> based on
> >> the -cpu and
On Tue, Jun 23, 2015 at 11:23:16PM +0200, Michael S. Tsirkin wrote:
>
> So any single CPU flag now needs to be added in
> - kvm
> - qemu
> - libvirt
This is in fact already the case, and it will also possibly need
to be added to openstack too.
> Next thing libvirt will decide it's a policy thing
On Tue, Jun 23, 2015 at 05:26:38PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 23, 2015 at 09:41:51PM +0200, Andreas Färber wrote:
> [...]
> > Given that we have had this versioning system for years and no problem
> > specifically with 2.4 has been raised, I see this as 2.5+ material at
> > this po
On Tue, Jun 23, 2015 at 02:11:22PM -0300, Eduardo Habkost wrote:
> Even if it is a bug fix. If it is a change that can make the VM
> unrunnable, it needs to be controlled by a separate flag, not by the
> machine-type.
I agree - command line compatibility is important. But we are supposed
to provi
On Tue, Jun 23, 2015 at 02:42:37PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 23, 2015 at 07:29:15PM +0200, Andreas Färber wrote:
> > In summary you seem to be saying that all the years we have spent
> > fiddling around with those mind-boggling compat_props in QEMU were in
> > vain because libvirt
On Tue, Jun 23, 2015 at 06:13:24PM +0100, Daniel P. Berrange wrote:
> On Tue, Jun 23, 2015 at 06:47:16PM +0200, Andreas Färber wrote:
> > Am 23.06.2015 um 18:42 schrieb Daniel P. Berrange:
> > > On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
> > >> On Tue, Jun 23, 2015 at 05:25
On Tue, Jun 23, 2015 at 05:42:04PM +0100, Daniel P. Berrange wrote:
> On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
> > > On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
> > > > Am 23.06.20
On Tue, Jun 23, 2015 at 09:41:51PM +0200, Andreas Färber wrote:
[...]
> Given that we have had this versioning system for years and no problem
> specifically with 2.4 has been raised, I see this as 2.5+ material at
> this point.
I see this on 2.4 schedule:
"2015-06-16 Soft feature freeze. All
On Tue, Jun 23, 2015 at 09:41:51PM +0200, Andreas Färber wrote:
[...]
> I am going to stop arguing here and suggest you put this on the agenda
> for the next KVM call.
I am a bit confused. You said "I don't mind there being an optional
custom model" in a previous message.
If you have objections t
Am 23.06.2015 um 21:25 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 08:35:54PM +0200, Andreas Färber wrote:
>> Am 23.06.2015 um 19:39 schrieb Eduardo Habkost:
>>> On Tue, Jun 23, 2015 at 07:18:06PM +0200, Andreas Färber wrote:
Am 23.06.2015 um 19:08 schrieb Eduardo Habkost:
> On Tue,
On Tue, Jun 23, 2015 at 08:35:54PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 19:39 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 07:18:06PM +0200, Andreas Färber wrote:
> >> Am 23.06.2015 um 19:08 schrieb Eduardo Habkost:
> >>> On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas Färber w
Am 23.06.2015 um 19:39 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 07:18:06PM +0200, Andreas Färber wrote:
>> Am 23.06.2015 um 19:08 schrieb Eduardo Habkost:
>>> On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas Färber wrote:
Am 23.06.2015 um 18:38 schrieb Eduardo Habkost:
> On Tue,
On Tue, Jun 23, 2015 at 07:58:44PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 19:45 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 07:41:50PM +0200, Andreas Färber wrote:
> > [...]
> >> If that is the whole problem here, then why not just add a global flag
> >> to only enable explicitly
On Tue, Jun 23, 2015 at 07:58:44PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 19:45 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 07:41:50PM +0200, Andreas Färber wrote:
> > [...]
> >> If that is the whole problem here, then why not just add a global flag
> >> to only enable explicitly
On Tue, Jun 23, 2015 at 07:41:50PM +0200, Andreas Färber wrote:
> Only if you use "-cpu ...,enforce", no?
>
> The KVM feature filtering should take care of dropping features that are
> not available otherwise.
>
> So we seem to be getting to the interesting case of the same machine
> (different f
Am 23.06.2015 um 19:45 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 07:41:50PM +0200, Andreas Färber wrote:
> [...]
>> If that is the whole problem here, then why not just add a global flag
>> to only enable explicitly requested KVM features? All other features
>> should not depend on the hos
On Tue, Jun 23, 2015 at 07:55:14PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 19:42 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 07:29:15PM +0200, Andreas Färber wrote:
> >> In summary you seem to be saying that all the years we have spent
> >> fiddling around with those mind-boggling
Am 23.06.2015 um 19:42 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 07:29:15PM +0200, Andreas Färber wrote:
>> In summary you seem to be saying that all the years we have spent
>> fiddling around with those mind-boggling compat_props in QEMU were in
>> vain because libvirt now wants to start
On Tue, Jun 23, 2015 at 07:41:50PM +0200, Andreas Färber wrote:
[...]
> If that is the whole problem here, then why not just add a global flag
> to only enable explicitly requested KVM features? All other features
> should not depend on the host, and the whole discussion about -x.y seems
> like a d
On Tue, Jun 23, 2015 at 07:29:15PM +0200, Andreas Färber wrote:
> In summary you seem to be saying that all the years we have spent
> fiddling around with those mind-boggling compat_props in QEMU were in
> vain because libvirt now wants to start their own versioning system to
> give users more degr
Am 23.06.2015 um 19:27 schrieb Daniel P. Berrange:
> On Tue, Jun 23, 2015 at 07:18:06PM +0200, Andreas Färber wrote:
>> Am 23.06.2015 um 19:08 schrieb Eduardo Habkost:
>>> On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas Färber wrote:
Am 23.06.2015 um 18:38 schrieb Eduardo Habkost:
> On T
On Tue, Jun 23, 2015 at 07:18:06PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 19:08 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas Färber wrote:
> >> Am 23.06.2015 um 18:38 schrieb Eduardo Habkost:
> >>> On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirk
On Tue, Jun 23, 2015 at 02:24:16PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 23, 2015 at 07:10:11PM +0200, Andreas Färber wrote:
> > Am 23.06.2015 um 18:53 schrieb Daniel P. Berrange:
> > > On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas Färber wrote:
> > >> Am 23.06.2015 um 18:25 schrieb Danie
Am 23.06.2015 um 19:13 schrieb Daniel P. Berrange:
> On Tue, Jun 23, 2015 at 06:47:16PM +0200, Andreas Färber wrote:
>> Am 23.06.2015 um 18:42 schrieb Daniel P. Berrange:
>>> On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P.
On Tue, Jun 23, 2015 at 07:18:06PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 19:08 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas Färber wrote:
> >> Am 23.06.2015 um 18:38 schrieb Eduardo Habkost:
> >>> On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirk
On Tue, Jun 23, 2015 at 07:10:11PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 18:53 schrieb Daniel P. Berrange:
> > On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas Färber wrote:
> >> Am 23.06.2015 um 18:25 schrieb Daniel P. Berrange:
> >>> Whether QEMU changed the CPU for existing machines,
Am 23.06.2015 um 19:08 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas Färber wrote:
>> Am 23.06.2015 um 18:38 schrieb Eduardo Habkost:
>>> On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berra
On Tue, Jun 23, 2015 at 06:47:16PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 18:42 schrieb Daniel P. Berrange:
> > On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
> >> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
> >>> On Tue, Jun 23, 2015 at 06:15:5
On Tue, Jun 23, 2015 at 06:47:16PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 18:42 schrieb Daniel P. Berrange:
> > On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
> >> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
> >>> On Tue, Jun 23, 2015 at 06:15:5
Am 23.06.2015 um 18:53 schrieb Daniel P. Berrange:
> On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas Färber wrote:
>> Am 23.06.2015 um 18:25 schrieb Daniel P. Berrange:
>>> Whether QEMU changed the CPU for existing machines, or only for new
>>> machines is actually not the core problem. Even if w
On Tue, Jun 23, 2015 at 06:44:57PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 18:38 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
> >> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
> >>> Whether QEMU changed the CPU for e
Am 23.06.2015 um 18:32 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
>> Am 23.06.2015 um 17:58 schrieb Eduardo Habkost:
>>> On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote:
On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost
On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 18:25 schrieb Daniel P. Berrange:
> > Whether QEMU changed the CPU for existing machines, or only for new
> > machines is actually not the core problem. Even if we only changed
> > the CPU in new machines that would
Am 23.06.2015 um 18:42 schrieb Daniel P. Berrange:
> On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
>> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
>>> On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
Am 23.06.2015 um 17:58 schrieb Edu
Am 23.06.2015 um 18:38 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
>> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
>>> Whether QEMU changed the CPU for existing machines, or only for new
>>> machines is actually not the core
On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
> > On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
> > > Am 23.06.2015 um 17:58 schrieb Eduardo Habkost:
> > > > On Tue, Jun 23, 2015 at 05:32:4
Am 23.06.2015 um 18:25 schrieb Daniel P. Berrange:
> Whether QEMU changed the CPU for existing machines, or only for new
> machines is actually not the core problem. Even if we only changed
> the CPU in new machines that would still be an unsatisfactory situation
> because we want to be able to be
On Tue, Jun 23, 2015 at 06:33:05PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
> > On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
> > > Am 23.06.2015 um 17:58 schrieb Eduardo Habkost:
> > > > On Tue, Jun 23, 2015 at 05:32:4
On Tue, Jun 23, 2015 at 05:25:55PM +0100, Daniel P. Berrange wrote:
> On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
> > Am 23.06.2015 um 17:58 schrieb Eduardo Habkost:
> > > On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote:
> > >> On Tue, Jun 23, 2015 at 12:08:28
On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 17:58 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote:
> >> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> >>> On Tue, Jun 23, 2015 at 02:32:00PM +0
On Tue, Jun 23, 2015 at 05:00:54PM +0100, Daniel P. Berrange wrote:
> On Tue, Jun 23, 2015 at 05:56:35PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Jun 23, 2015 at 04:51:00PM +0100, Daniel P. Berrange wrote:
> > > On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> > > > On Tue, Ju
On Tue, Jun 23, 2015 at 06:15:51PM +0200, Andreas Färber wrote:
> Am 23.06.2015 um 17:58 schrieb Eduardo Habkost:
> > On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote:
> >> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> >>> On Tue, Jun 23, 2015 at 02:32:00PM +0
Am 23.06.2015 um 17:58 schrieb Eduardo Habkost:
> On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote:
>> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
>>> On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
Am 08.06.2015 um 22:18 schrieb Jiri Dene
On Tue, Jun 23, 2015 at 05:56:35PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2015 at 04:51:00PM +0100, Daniel P. Berrange wrote:
> > On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> > > On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
> > > > Am 08.06.2015
On Tue, Jun 23, 2015 at 05:32:42PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> > On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
> > > Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> > > >> To help libvirt in the transition,
On Tue, Jun 23, 2015 at 04:51:00PM +0100, Daniel P. Berrange wrote:
> On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> > On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
> > > Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> > > >> To help libvirt in the transition,
On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
> > Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> > >> To help libvirt in the transition, a x86-cpu-model-dump script is
> > >> provided,
> > >> that will generate a
On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
> > Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> > >> To help libvirt in the transition, a x86-cpu-model-dump script is
> > >> provided,
> > >> that will generate a
On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote:
> Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> >> To help libvirt in the transition, a x86-cpu-model-dump script is provided,
> >> that will generate a config file that can be loaded using -readconfig,
> >> based on
> >> the -cpu a
Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
>> To help libvirt in the transition, a x86-cpu-model-dump script is provided,
>> that will generate a config file that can be loaded using -readconfig, based
>> on
>> the -cpu and -machine options provided in the command-line.
>
> Thanks Eduardo, I n
Ping? Any feedback? I want to get this into 2.4.
On Mon, Jun 08, 2015 at 04:07:38PM -0300, Eduardo Habkost wrote:
> The problem:
>
> The existing libvirt APIs assume that if a given CPU model is runnable in a
> host kernel+hardware combination, it will be always runnable on that host even
> if t
On Tue, Jun 09, 2015 at 09:56:25AM +0100, Daniel P. Berrange wrote:
> On Mon, Jun 08, 2015 at 10:18:35PM +0200, Jiri Denemark wrote:
> > On Mon, Jun 08, 2015 at 16:07:38 -0300, Eduardo Habkost wrote:
> > ...
> > > libvirt can solve this problem partially by making sure every feature in
> > > a CPU
On Mon, Jun 08, 2015 at 10:18:35PM +0200, Jiri Denemark wrote:
> On Mon, Jun 08, 2015 at 16:07:38 -0300, Eduardo Habkost wrote:
> ...
> > libvirt can solve this problem partially by making sure every feature in a
> > CPU
> > model is explicitly configured, instead of (incorrectly) expecting that a
On Mon, Jun 08, 2015 at 16:07:38 -0300, Eduardo Habkost wrote:
...
> libvirt can solve this problem partially by making sure every feature in a CPU
> model is explicitly configured, instead of (incorrectly) expecting that a
> named
> CPU model will never change in QEMU. But this doesn't solve the
The problem:
The existing libvirt APIs assume that if a given CPU model is runnable in a
host kernel+hardware combination, it will be always runnable on that host even
if the machine-type changes.
That assumption is implied in some of libvirt interfaces, for example, at:
1) Host capabilities, wh
74 matches
Mail list logo
