[Qemu-devel] KVM call agenfda for 2014-04-01

[Qemu-devel] KVM call agenfda for 2014-04-01

[Juan Quintela]

Hi

Please, send any topic that you are interested in covering.

Thanks, Juan.

Call details:

10:00 AM to 11:00 AM EDT
Every two weeks

If you need phone number details,  contact me privately.

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Andreas Färber]

Hi,

Am 31.03.2014 12:40, schrieb Juan Quintela:
> 
> Please, send any topic that you are interested in covering.

I would like to discuss the state of the QEMU release process, please:

* -rc1 has not been tagged.
* Who besides Anthony could upload a tarball if we tag and create it?
* make-release fix for SeaBIOS on the list. Ping, and are more affected?

Thanks,
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 agenda for 2014-04-01

[Stefan Hajnoczi]

On Mon, Mar 31, 2014 at 12:51:31PM +0200, Andreas Färber wrote:
> Am 31.03.2014 12:40, schrieb Juan Quintela:
> > 
> > Please, send any topic that you are interested in covering.
> 
> I would like to discuss the state of the QEMU release process, please:
> 
> * -rc1 has not been tagged.
> * Who besides Anthony could upload a tarball if we tag and create it?
> * make-release fix for SeaBIOS on the list. Ping, and are more affected?

+1

Stefan

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Christian Borntraeger]

On 31/03/14 12:51, Andreas Färber wrote:
> Hi,
> 
> Am 31.03.2014 12:40, schrieb Juan Quintela:
>>
>> Please, send any topic that you are interested in covering.
> 
> I would like to discuss the state of the QEMU release process, please:
> 
> * -rc1 has not been tagged.
> * Who besides Anthony could upload a tarball if we tag and create it?
> * make-release fix for SeaBIOS on the list. Ping, and are more affected?

+1 for this one.

Another thing might be the release process in general. Currently it seems
that everybody tries to push everything just before the hard freeze.  I had
to debug some problems introduced _after_ soft freeze. Is there some
interest in having a Linux-like process (merge window + stabilization)? This
would require shorter release cycles of course.

Christian

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Peter Maydell]

On 31 March 2014 14:21, Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> Another thing might be the release process in general. Currently it seems
> that everybody tries to push everything just before the hard freeze.  I had
> to debug some problems introduced _after_ soft freeze. Is there some
> interest in having a Linux-like process (merge window + stabilization)? This
> would require shorter release cycles of course.

"merge window" has been suggested before. I think it would be
a terrible idea for QEMU, personally. We're not the kernel in
many ways, notably dev community size and a greater tendency
to changes that have effects across the whole tree.

Soft + hard freeze is our stabilization period currently.

thanks
-- PMM

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Anthony Liguori]

On Mon, Mar 31, 2014 at 6:25 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 31 March 2014 14:21, Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>> Another thing might be the release process in general. Currently it seems
>> that everybody tries to push everything just before the hard freeze.  I had
>> to debug some problems introduced _after_ soft freeze. Is there some
>> interest in having a Linux-like process (merge window + stabilization)? This
>> would require shorter release cycles of course.
>
> "merge window" has been suggested before. I think it would be
> a terrible idea for QEMU, personally. We're not the kernel in
> many ways, notably dev community size and a greater tendency
> to changes that have effects across the whole tree.
>
> Soft + hard freeze is our stabilization period currently.

Peter, are you willing to do the tagging and announcement for the 2.0
rcs?  I sent instructions privately and between stefanha and I we can
get your permissions sorted out.

Regards,

Anthony Liguori

> thanks
> -- PMM

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Paolo Bonzini]

Il 31/03/2014 16:01, Anthony Liguori ha scritto:
>> > "merge window" has been suggested before. I think it would be
>> > a terrible idea for QEMU, personally. We're not the kernel in
>> > many ways, notably dev community size and a greater tendency
>> > to changes that have effects across the whole tree.
>> >
>> > Soft + hard freeze is our stabilization period currently.
> Peter, are you willing to do the tagging and announcement for the 2.0
> rcs?  I sent instructions privately and between stefanha and I we can
> get your permissions sorted out.

I think it would be a good idea to separate the committer and release 
manager roles.  Peter is providing the community with a wonderful 
service, just like you were; putting too much work on his shoulders 
risks getting us in the same situation if anything were to affect his 
ability to provide it.

Paolo

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Peter Maydell]

On 31 March 2014 15:28, Paolo Bonzini <pbonzini@redhat.com> wrote:
> I think it would be a good idea to separate the committer and release
> manager roles.  Peter is providing the community with a wonderful service,
> just like you were; putting too much work on his shoulders risks getting us
> in the same situation if anything were to affect his ability to provide it.

Yes, I strongly agree with this. I think we'll do much better
if we can manage to share out responsibilities among a wider
group of people.

thanks
-- PMM

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Andreas Färber]

Am 31.03.2014 16:32, schrieb Peter Maydell:
> On 31 March 2014 15:28, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> I think it would be a good idea to separate the committer and release
>> manager roles.  Peter is providing the community with a wonderful service,
>> just like you were; putting too much work on his shoulders risks getting us
>> in the same situation if anything were to affect his ability to provide it.
> 
> Yes, I strongly agree with this. I think we'll do much better
> if we can manage to share out responsibilities among a wider
> group of people.

May I propose Michael Roth, who is already experienced from the N-1
stable releases?

If we can enable him to upload the tarballs created from his tags that
would also streamline the stable workflow while at it.

Regards,
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 agenda for 2014-04-01

[Anthony Liguori]

On Mon, Mar 31, 2014 at 7:46 AM, Andreas Färber <afaerber@suse.de> wrote:
> Am 31.03.2014 16:32, schrieb Peter Maydell:
>> On 31 March 2014 15:28, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> I think it would be a good idea to separate the committer and release
>>> manager roles.  Peter is providing the community with a wonderful service,
>>> just like you were; putting too much work on his shoulders risks getting us
>>> in the same situation if anything were to affect his ability to provide it.
>>
>> Yes, I strongly agree with this. I think we'll do much better
>> if we can manage to share out responsibilities among a wider
>> group of people.
>
> May I propose Michael Roth, who is already experienced from the N-1
> stable releases?
>
> If we can enable him to upload the tarballs created from his tags that
> would also streamline the stable workflow while at it.

If mdroth is willing to take this on, I am very supportive.

Regards,

Anthony Liguori

>
> Regards,
> 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 agenda for 2014-04-01

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> On Mon, Mar 31, 2014 at 7:46 AM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 31.03.2014 16:32, schrieb Peter Maydell:
>>> On 31 March 2014 15:28, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>> I think it would be a good idea to separate the committer and release
>>>> manager roles.  Peter is providing the community with a wonderful service,
>>>> just like you were; putting too much work on his shoulders risks getting us
>>>> in the same situation if anything were to affect his ability to provide it.
>>>
>>> Yes, I strongly agree with this. I think we'll do much better
>>> if we can manage to share out responsibilities among a wider
>>> group of people.
>>
>> May I propose Michael Roth, who is already experienced from the N-1
>> stable releases?
>>
>> If we can enable him to upload the tarballs created from his tags that
>> would also streamline the stable workflow while at it.
>
> If mdroth is willing to take this on, I am very supportive.

Another vote of confidence from me.

Re: [Qemu-devel] KVM call agenda for 2014-04-01

[Michael Roth]

Quoting Andreas Färber (2014-03-31 09:46:45)
> Am 31.03.2014 16:32, schrieb Peter Maydell:
> > On 31 March 2014 15:28, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >> I think it would be a good idea to separate the committer and release
> >> manager roles.  Peter is providing the community with a wonderful service,
> >> just like you were; putting too much work on his shoulders risks getting us
> >> in the same situation if anything were to affect his ability to provide it.
> > 
> > Yes, I strongly agree with this. I think we'll do much better
> > if we can manage to share out responsibilities among a wider
> > group of people.
> 
> May I propose Michael Roth, who is already experienced from the N-1
> stable releases?

Sure, I would be willing.

> 
> If we can enable him to upload the tarballs created from his tags that
> would also streamline the stable workflow while at it.

Agreed, though I feel a little weird about creating releases for tags that
aren't in the official repo. Would that be acceptable from a community
stand-point? I'm honestly not sure.

Otherwise I think Anthony/Peter would probably still need to process a pull
for stable-y.x branch in advance before we do the tarball/release. Would
still help simplify things a bit though by keeping tasks compartmentalized.

Anthony, Peter: in the past, prior to release, I just sent an email with
a pointer to my github branch with the stable release tagged. Would a proper
pull request (with a for-stable-x.y tag or somesuch) be preferable?

If we opt to align the stable repo updates with the actual release, what kind
of lead time would we need prior to actual release?

> 
> Regards,
> 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 agenda for 2014-04-01

[Peter Maydell]

On 31 March 2014 20:57, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> Agreed, though I feel a little weird about creating releases for tags that
> aren't in the official repo. Would that be acceptable from a community
> stand-point? I'm honestly not sure.
>
> Otherwise I think Anthony/Peter would probably still need to process a pull
> for stable-y.x branch in advance before we do the tarball/release. Would
> still help simplify things a bit though by keeping tasks compartmentalized.
>
> Anthony, Peter: in the past, prior to release, I just sent an email with
> a pointer to my github branch with the stable release tagged. Would a proper
> pull request (with a for-stable-x.y tag or somesuch) be preferable?

The simplest approach seems to me to be giving you commit access
to master so you can directly push release tags to it as part of
making a release.

thanks
-- PMM

Re: [Qemu-devel] KVM call agenfda for 2014-04-01

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:
> Hi
>
> Please, send any topic that you are interested in covering.
>
> Thanks, Juan.
>
> Call details:
>
> 10:00 AM to 11:00 AM EDT
> Every two weeks

Time clarification.  This time was wrong, it is 1h early.

15:00 CEST
13:00 UTC
09:00 EDT

Sorry for the inconvenience (I copy & paste from and old email, and  did
it wrong.)

Later, Juan.

>
> If you need phone number details,  contact me privately.

Re: [Qemu-devel] KVM call agenfda for 2014-04-01

[Alexander Graf]

On 31.03.2014, at 12:40, Juan Quintela <quintela@redhat.com> wrote:

> 
> Hi
> 
> Please, send any topic that you are interested in covering.
> 
> Thanks, Juan.
> 
> Call details:
> 
> 10:00 AM to 11:00 AM EDT
> Every two weeks
> 
> If you need phone number details,  contact me privately.
> 

For the next call, I would propose to revive the "platform bus" (aka: how to create non-PCI devices with -device) discussions to make sure we're all on the same page.


Alex

Re: [Qemu-devel] KVM call agenfda for 2014-04-01

[Peter Maydell]

On 10 April 2014 16:49, Alexander Graf <agraf@suse.de> wrote:
> For the next call, I would propose to revive the "platform bus"
> (aka: how to create non-PCI devices with -device) discussions
> to make sure we're all on the same page.

I rather suspect we are not :-)  Do you have a link to
the current proposals for prior reading?

thanks
-- PMM

Re: [Qemu-devel] KVM call agenfda for 2014-04-01

[Alexander Graf]

On 10.04.2014, at 17:52, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 10 April 2014 16:49, Alexander Graf <agraf@suse.de> wrote:
>> For the next call, I would propose to revive the "platform bus"
>> (aka: how to create non-PCI devices with -device) discussions
>> to make sure we're all on the same page.
> 
> I rather suspect we are not :-)  Do you have a link to
> the current proposals for prior reading?

The only thing I could find is the old thread about my platform bus approach (which Anthony disliked):

  https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03614.html

So from what I remember the plan moving forward was to have a special device type similar to my platform bus devices that you can just create using -device, no bus involved. The machine file would then loop through them, interpret the "I sit at address x" and "I want interrupt number y" fields to link them to whatever the machine model thinks is a good fit.

The same way the machine model today has to have knowledge on each device tree node type it generates, it would do the same for these devices. So the machine has to have awareness of all the "funky special options" a device tree node receives - the same as for any other device. Just that in this case it wouldn't be able to hardcode them, but have to generate them on the fly when it sees a device in the object tree.


Alex

Re: [Qemu-devel] KVM call agenfda for 2014-04-01

[Stuart Yoder]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, April 10, 2014 10:57 AM
> To: Peter Maydell
> Cc: Juan Quintela; KVM devel mailing list; qemu list; Yoder Stuart-
> B08248; Alistair Francis; Peter Crosthwaite; Christoffer Dall
> Subject: Re: [Qemu-devel] KVM call agenfda for 2014-04-01
> 
> 
> On 10.04.2014, at 17:52, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> > On 10 April 2014 16:49, Alexander Graf <agraf@suse.de> wrote:
> >> For the next call, I would propose to revive the "platform bus"
> >> (aka: how to create non-PCI devices with -device) discussions
> >> to make sure we're all on the same page.
> >
> > I rather suspect we are not :-)  Do you have a link to
> > the current proposals for prior reading?
> 
> The only thing I could find is the old thread about my platform bus
> approach (which Anthony disliked):
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03614.html
> 
> So from what I remember the plan moving forward was to have a special
> device type similar to my platform bus devices that you can just create
> using -device, no bus involved. The machine file would then loop through
> them, interpret the "I sit at address x" and "I want interrupt number y"
> fields to link them to whatever the machine model thinks is a good fit.
> 
> The same way the machine model today has to have knowledge on each device
> tree node type it generates, it would do the same for these devices. So
> the machine has to have awareness of all the "funky special options" a
> device tree node receives - the same as for any other device. Just that
> in this case it wouldn't be able to hardcode them, but have to generate
> them on the fly when it sees a device in the object tree.

Another link that may help from a call we had back in Sept:
https://lists.cs.columbia.edu/pipermail/kvmarm/2013-September/005532.html

Stuart

Re: [Qemu-devel] KVM call agenfda for 2014-04-01

[Markus Armbruster]

[Cc: Andreas, Anthony]

Alexander Graf <agraf@suse.de> writes:

> On 10.04.2014, at 17:52, Peter Maydell <peter.maydell@linaro.org> wrote:
>
>> On 10 April 2014 16:49, Alexander Graf <agraf@suse.de> wrote:
>>> For the next call, I would propose to revive the "platform bus"
>>> (aka: how to create non-PCI devices with -device) discussions

Rather: devices that connect to more than just a bus.

Since pseudo-bus sysbus provides exactly no connections, sysbus devices
generally connect to more.

Currently, the only way to make such additional connections is
special-purpose code.  -device's connection engine can only connect to a
bus.

>>> to make sure we're all on the same page.
>> 
>> I rather suspect we are not :-)  Do you have a link to
>> the current proposals for prior reading?
>
> The only thing I could find is the old thread about my platform bus
> approach (which Anthony disliked):
>
>   https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03614.html
>
> So from what I remember the plan moving forward was to have a special
> device type similar to my platform bus devices that you can just
> create using -device, no bus involved. The machine file would then
> loop through them, interpret the "I sit at address x" and "I want
> interrupt number y" fields to link them to whatever the machine model
> thinks is a good fit.
>
> The same way the machine model today has to have knowledge on each
> device tree node type it generates, it would do the same for these
> devices. So the machine has to have awareness of all the "funky
> special options" a device tree node receives - the same as for any
> other device. Just that in this case it wouldn't be able to hardcode
> them, but have to generate them on the fly when it sees a device in
> the object tree.

The following is just my understanding of where we're trying to go.  The
people active in this field (Andreas?) should correct misunderstandings.

Our overall goal is building machines from components by *data* rather
than code.  Once it's data, it can be made run-time configuration.

The configuration describes how components are to be connected, and
generic connection code makes the connections guided by the
configuration.

The current generic connection code can only connect a device to a
single bus.

If you don't specify the bus, it picks one.  Which one it picks is
effectively ABI.

Picking a bus is a special case of "pick a connection if user didn't
specify one".  The current bus-picker doesn't depend on the machine
type, but that's not going to hold in general.

I like to think of the "pick connections the user didn't specify" engine
as conceptually separate from the "make connections driven by
configuration" engine.  The actual code isn't so separate, but that's
implementation.

How does your "platform device" proposal (for lack of a better
expression) fit into this general framework of ideas?

Re: [Qemu-devel] KVM call agenfda for 2014-04-01

[Alexander Graf]

On 11.04.14 09:46, Markus Armbruster wrote:
> [Cc: Andreas, Anthony]
>
> Alexander Graf <agraf@suse.de> writes:
>
>> On 10.04.2014, at 17:52, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>>> On 10 April 2014 16:49, Alexander Graf <agraf@suse.de> wrote:
>>>> For the next call, I would propose to revive the "platform bus"
>>>> (aka: how to create non-PCI devices with -device) discussions
> Rather: devices that connect to more than just a bus.
>
> Since pseudo-bus sysbus provides exactly no connections, sysbus devices
> generally connect to more.
>
> Currently, the only way to make such additional connections is
> special-purpose code.  -device's connection engine can only connect to a
> bus.
>
>>>> to make sure we're all on the same page.
>>> I rather suspect we are not :-)  Do you have a link to
>>> the current proposals for prior reading?
>> The only thing I could find is the old thread about my platform bus
>> approach (which Anthony disliked):
>>
>>    https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03614.html
>>
>> So from what I remember the plan moving forward was to have a special
>> device type similar to my platform bus devices that you can just
>> create using -device, no bus involved. The machine file would then
>> loop through them, interpret the "I sit at address x" and "I want
>> interrupt number y" fields to link them to whatever the machine model
>> thinks is a good fit.
>>
>> The same way the machine model today has to have knowledge on each
>> device tree node type it generates, it would do the same for these
>> devices. So the machine has to have awareness of all the "funky
>> special options" a device tree node receives - the same as for any
>> other device. Just that in this case it wouldn't be able to hardcode
>> them, but have to generate them on the fly when it sees a device in
>> the object tree.
> The following is just my understanding of where we're trying to go.  The
> people active in this field (Andreas?) should correct misunderstandings.
>
> Our overall goal is building machines from components by *data* rather
> than code.  Once it's data, it can be made run-time configuration.

I've had plenty of discussions on this with Anthony over the years 
(first time this came up was about 2 or 3 years ago) on this. Eventually 
his conclusion was that it's not desirable to build the machine from 
data. Instead it should get built from a script. The nice thing about a 
script is that it's also run-time, but not as restricted and as much 
special-cased as a mere description.

Unfortunately I don't know all of the rationale that went into the 
conclusion :).

> The configuration describes how components are to be connected, and
> generic connection code makes the connections guided by the
> configuration.
>
> The current generic connection code can only connect a device to a
> single bus.
>
> If you don't specify the bus, it picks one.  Which one it picks is
> effectively ABI.
>
> Picking a bus is a special case of "pick a connection if user didn't
> specify one".  The current bus-picker doesn't depend on the machine
> type, but that's not going to hold in general.
>
> I like to think of the "pick connections the user didn't specify" engine
> as conceptually separate from the "make connections driven by
> configuration" engine.  The actual code isn't so separate, but that's
> implementation.
>
> How does your "platform device" proposal (for lack of a better
> expression) fit into this general framework of ideas?

Any leaf devices that are not hooked up to anything get connected by 
machine specific code :). So the "pick connections the user didn't 
specify" logic would be machine specific.


Alex