KVM call minutes July 31th

KVM call minutes July 31th

[Juan Quintela]

Hi

Today minutes:

- Avi fixed and got 9p working
- QEMU 1.2 Test Day (stefan)
  * Let's find -rc bugs and ensure the release is stable
  * We've done this in the past and have a wiki template but can
    discuss suggestions on the call
  * A date?

- 1.2 plans for CPU model versioning/compatibility (eduardo)
  (global properties vs QOM vs qdev)
  how to do it ?  configuration file?  moving back to the code?
  different external interface from internal one

  Eduardo/Andreas/Anthony, <fill here>

[Qemu-devel] KVM call minutes July 31th

[Juan Quintela]

Hi

Today minutes:

- Avi fixed and got 9p working
- QEMU 1.2 Test Day (stefan)
  * Let's find -rc bugs and ensure the release is stable
  * We've done this in the past and have a wiki template but can
    discuss suggestions on the call
  * A date?

- 1.2 plans for CPU model versioning/compatibility (eduardo)
  (global properties vs QOM vs qdev)
  how to do it ?  configuration file?  moving back to the code?
  different external interface from internal one

  Eduardo/Andreas/Anthony, <fill here>

[libvirt] QEMU CPU model versioning/compatibility (was Re: KVM call minutes July 31th)

[Eduardo Habkost]

On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>   (global properties vs QOM vs qdev)
>   how to do it ?  configuration file?  moving back to the code?
>   different external interface from internal one

(CCing libvir-list)

So, the problem is (please correct me if I am wrong):

- libvirt expects the CPU models from the current config file to be
  provided by QEMU. libvirt won't write a cpudef config file.
- Fixing compatibility problems on the CPU models (even the ones that
  are in config files) are expected to be QEMU's responsibility.

Moving the CPU models inside the code is a step backwards, IMO. I don't
think loading some kind of data from an external file (provided and
maintained by QEMU itself) should be considered something special and
magic, and make the data there a second-class citizen (that QEMU refuses
to give proper support and keep compatibility).

But if it will make us stop running in circles every time something
related to those files needs to be changed (remember the -no-user-config
discussion?), I think I will accept that.

-- 
Eduardo

[Qemu-devel] QEMU CPU model versioning/compatibility (was Re: KVM call minutes July 31th)

[Eduardo Habkost]

On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>   (global properties vs QOM vs qdev)
>   how to do it ?  configuration file?  moving back to the code?
>   different external interface from internal one

(CCing libvir-list)

So, the problem is (please correct me if I am wrong):

- libvirt expects the CPU models from the current config file to be
  provided by QEMU. libvirt won't write a cpudef config file.
- Fixing compatibility problems on the CPU models (even the ones that
  are in config files) are expected to be QEMU's responsibility.

Moving the CPU models inside the code is a step backwards, IMO. I don't
think loading some kind of data from an external file (provided and
maintained by QEMU itself) should be considered something special and
magic, and make the data there a second-class citizen (that QEMU refuses
to give proper support and keep compatibility).

But if it will make us stop running in circles every time something
related to those files needs to be changed (remember the -no-user-config
discussion?), I think I will accept that.

-- 
Eduardo

Re: QEMU CPU model versioning/compatibility (was Re: KVM call minutes July 31th)

[Avi Kivity]

On 07/31/2012 06:14 PM, Eduardo Habkost wrote:
> On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
>> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>>   (global properties vs QOM vs qdev)
>>   how to do it ?  configuration file?  moving back to the code?
>>   different external interface from internal one
> 
> (CCing libvir-list)
> 
> So, the problem is (please correct me if I am wrong):
> 
> - libvirt expects the CPU models from the current config file to be
>   provided by QEMU. libvirt won't write a cpudef config file.
> - Fixing compatibility problems on the CPU models (even the ones that
>   are in config files) are expected to be QEMU's responsibility.
> 
> Moving the CPU models inside the code is a step backwards, IMO. I don't
> think loading some kind of data from an external file (provided and
> maintained by QEMU itself) should be considered something special and
> magic, and make the data there a second-class citizen (that QEMU refuses
> to give proper support and keep compatibility).

I agree.

> But if it will make us stop running in circles every time something
> related to those files needs to be changed (remember the -no-user-config
> discussion?), I think I will accept that.

The issue is that we have a lot of machinery for backwards compatibility
in the code, and none in cpu definitions parser.  Yes we could mark up
the cpu definitions so it could be text driven, but that's effort that
could be spent elsewhere.  Moving it to a data-driven C implementation
that can rely on the existing backwards compat code is a good tradeoff IMO.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] QEMU CPU model versioning/compatibility (was Re: KVM call minutes July 31th)

[Avi Kivity]

On 07/31/2012 06:14 PM, Eduardo Habkost wrote:
> On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
>> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>>   (global properties vs QOM vs qdev)
>>   how to do it ?  configuration file?  moving back to the code?
>>   different external interface from internal one
> 
> (CCing libvir-list)
> 
> So, the problem is (please correct me if I am wrong):
> 
> - libvirt expects the CPU models from the current config file to be
>   provided by QEMU. libvirt won't write a cpudef config file.
> - Fixing compatibility problems on the CPU models (even the ones that
>   are in config files) are expected to be QEMU's responsibility.
> 
> Moving the CPU models inside the code is a step backwards, IMO. I don't
> think loading some kind of data from an external file (provided and
> maintained by QEMU itself) should be considered something special and
> magic, and make the data there a second-class citizen (that QEMU refuses
> to give proper support and keep compatibility).

I agree.

> But if it will make us stop running in circles every time something
> related to those files needs to be changed (remember the -no-user-config
> discussion?), I think I will accept that.

The issue is that we have a lot of machinery for backwards compatibility
in the code, and none in cpu definitions parser.  Yes we could mark up
the cpu definitions so it could be text driven, but that's effort that
could be spent elsewhere.  Moving it to a data-driven C implementation
that can rely on the existing backwards compat code is a good tradeoff IMO.

-- 
error compiling committee.c: too many arguments to function

Re: KVM call minutes July 31th

[Eduardo Habkost]

On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>   (global properties vs QOM vs qdev)
>   how to do it ?  configuration file?  moving back to the code?
>   different external interface from internal one

Another question:

Anthony, you  mentioned that you had a series to convert the CPU to be
actual qdev device objects. Do you have a pointer for it? I couldn't
find it.

All I remember (from a call 2 or 3 weeks ago) was that the conversion
was difficult because it would make *-user pull qdev, and that was not a
trivial task.

-- 
Eduardo

Re: [Qemu-devel] KVM call minutes July 31th

[Eduardo Habkost]

On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>   (global properties vs QOM vs qdev)
>   how to do it ?  configuration file?  moving back to the code?
>   different external interface from internal one

Another question:

Anthony, you  mentioned that you had a series to convert the CPU to be
actual qdev device objects. Do you have a pointer for it? I couldn't
find it.

All I remember (from a call 2 or 3 weeks ago) was that the conversion
was difficult because it would make *-user pull qdev, and that was not a
trivial task.

-- 
Eduardo

Re: [Qemu-devel] KVM call minutes July 31th

[Andreas Färber]

Am 31.07.2012 17:40, schrieb Eduardo Habkost:
> On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
>> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>>   (global properties vs QOM vs qdev)
>>   how to do it ?  configuration file?  moving back to the code?
>>   different external interface from internal one
> 
> Another question:
> 
> Anthony, you  mentioned that you had a series to convert the CPU to be
> actual qdev device objects. Do you have a pointer for it? I couldn't
> find it.
> 
> All I remember (from a call 2 or 3 weeks ago) was that the conversion
> was difficult because it would make *-user pull qdev, and that was not a
> trivial task.

We had a KVM call on that topic. After that I was on vacation, we had
our Hackweek and this week is the one I started diving into QOM again -
Anthony said he already had something new and would post that.

I have added a feature item on the 1.2 feature page for the Soft Freeze.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] KVM call minutes July 31th

[Andreas Färber]

Am 31.07.2012 17:40, schrieb Eduardo Habkost:
> On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
>> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>>   (global properties vs QOM vs qdev)
>>   how to do it ?  configuration file?  moving back to the code?
>>   different external interface from internal one
> 
> Another question:
> 
> Anthony, you  mentioned that you had a series to convert the CPU to be
> actual qdev device objects. Do you have a pointer for it? I couldn't
> find it.
> 
> All I remember (from a call 2 or 3 weeks ago) was that the conversion
> was difficult because it would make *-user pull qdev, and that was not a
> trivial task.

We had a KVM call on that topic. After that I was on vacation, we had
our Hackweek and this week is the one I started diving into QOM again -
Anthony said he already had something new and would post that.

I have added a feature item on the 1.2 feature page for the Soft Freeze.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] KVM call minutes July 31th

[Igor Mammedov]

----- Original Message -----
> From: "Eduardo Habkost" <ehabkost@redhat.com>
> To: "Juan Quintela" <quintela@redhat.com>, "Anthony Liguori" <anthony@codemonkey.ws>
> Cc: qemu-devel@nongnu.org, "KVM devel mailing list" <kvm@vger.kernel.org>
> Sent: Tuesday, July 31, 2012 5:40:14 PM
> Subject: Re: [Qemu-devel] KVM call minutes July 31th
> 
> On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
> > - 1.2 plans for CPU model versioning/compatibility (eduardo)
> >   (global properties vs QOM vs qdev)
> >   how to do it ?  configuration file?  moving back to the code?
> >   different external interface from internal one
> 
> Another question:
> 
> Anthony, you  mentioned that you had a series to convert the CPU to
> be
> actual qdev device objects. Do you have a pointer for it? I couldn't
> find it.
it was http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg03847.html
but there is another earlier proposal by Andreas to make CPU as DEVICE only
for softmmu targets. 
So consensus wasn't reached yet.

If we are to to use global props creating CPU subclasses, we might have to
make CPU as DEVICE for *-user target as well and pull in qdev deps into it.


> All I remember (from a call 2 or 3 weeks ago) was that the conversion
> was difficult because it would make *-user pull qdev, and that was
> not a
> trivial task.
> 
> --
> Eduardo
> 
> 

Re: [Qemu-devel] KVM call minutes July 31th

[Igor Mammedov]

----- Original Message -----
> From: "Eduardo Habkost" <ehabkost@redhat.com>
> To: "Juan Quintela" <quintela@redhat.com>, "Anthony Liguori" <anthony@codemonkey.ws>
> Cc: qemu-devel@nongnu.org, "KVM devel mailing list" <kvm@vger.kernel.org>
> Sent: Tuesday, July 31, 2012 5:40:14 PM
> Subject: Re: [Qemu-devel] KVM call minutes July 31th
> 
> On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
> > - 1.2 plans for CPU model versioning/compatibility (eduardo)
> >   (global properties vs QOM vs qdev)
> >   how to do it ?  configuration file?  moving back to the code?
> >   different external interface from internal one
> 
> Another question:
> 
> Anthony, you  mentioned that you had a series to convert the CPU to
> be
> actual qdev device objects. Do you have a pointer for it? I couldn't
> find it.
it was http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg03847.html
but there is another earlier proposal by Andreas to make CPU as DEVICE only
for softmmu targets. 
So consensus wasn't reached yet.

If we are to to use global props creating CPU subclasses, we might have to
make CPU as DEVICE for *-user target as well and pull in qdev deps into it.


> All I remember (from a call 2 or 3 weeks ago) was that the conversion
> was difficult because it would make *-user pull qdev, and that was
> not a
> trivial task.
> 
> --
> Eduardo
> 
> 

Re: [Qemu-devel] KVM call minutes July 31th

[Andreas Färber]

Am 31.07.2012 18:06, schrieb Igor Mammedov:
> ----- Original Message -----
>> From: "Eduardo Habkost" <ehabkost@redhat.com>
>> To: "Juan Quintela" <quintela@redhat.com>, "Anthony Liguori" <anthony@codemonkey.ws>
>> Cc: qemu-devel@nongnu.org, "KVM devel mailing list" <kvm@vger.kernel.org>
>> Sent: Tuesday, July 31, 2012 5:40:14 PM
>> Subject: Re: [Qemu-devel] KVM call minutes July 31th
>>
>> On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
>>> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>>>   (global properties vs QOM vs qdev)
>>>   how to do it ?  configuration file?  moving back to the code?
>>>   different external interface from internal one
>>
>> Another question:
>>
>> Anthony, you  mentioned that you had a series to convert the CPU to
>> be
>> actual qdev device objects. Do you have a pointer for it? I couldn't
>> find it.
> it was http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg03847.html
> but there is another earlier proposal by Andreas to make CPU as DEVICE only
> for softmmu targets. 
> So consensus wasn't reached yet.
> 
> If we are to to use global props creating CPU subclasses, we might have to
> make CPU as DEVICE for *-user target as well and pull in qdev deps into it.

We don't version the user emulators, so there's no compatibility
properties to set if we follow the machine versioning scheme.
I expect Nehalem to resolve to Nehalem-1.2 but there's no strict need to
have a Nehalem-1.1 since there's no concept of migration.

Anything involving qdev in *-user will not make it in time for 1.2! :)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] KVM call minutes July 31th

[Andreas Färber]

Am 31.07.2012 18:06, schrieb Igor Mammedov:
> ----- Original Message -----
>> From: "Eduardo Habkost" <ehabkost@redhat.com>
>> To: "Juan Quintela" <quintela@redhat.com>, "Anthony Liguori" <anthony@codemonkey.ws>
>> Cc: qemu-devel@nongnu.org, "KVM devel mailing list" <kvm@vger.kernel.org>
>> Sent: Tuesday, July 31, 2012 5:40:14 PM
>> Subject: Re: [Qemu-devel] KVM call minutes July 31th
>>
>> On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
>>> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>>>   (global properties vs QOM vs qdev)
>>>   how to do it ?  configuration file?  moving back to the code?
>>>   different external interface from internal one
>>
>> Another question:
>>
>> Anthony, you  mentioned that you had a series to convert the CPU to
>> be
>> actual qdev device objects. Do you have a pointer for it? I couldn't
>> find it.
> it was http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg03847.html
> but there is another earlier proposal by Andreas to make CPU as DEVICE only
> for softmmu targets. 
> So consensus wasn't reached yet.
> 
> If we are to to use global props creating CPU subclasses, we might have to
> make CPU as DEVICE for *-user target as well and pull in qdev deps into it.

We don't version the user emulators, so there's no compatibility
properties to set if we follow the machine versioning scheme.
I expect Nehalem to resolve to Nehalem-1.2 but there's no strict need to
have a Nehalem-1.1 since there's no concept of migration.

Anything involving qdev in *-user will not make it in time for 1.2! :)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg