[Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Anthony Liguori]

Consider this a friendly reminder that we're only three weeks away from the soft 
feature freeze for 1.0.  I've written a wiki page about my expectations for the 
soft feature freeze.  It's inlined here for easier commenting.

== What is the soft feature freeze? ==

The soft feature freeze is the beginning of the stabilization phase of QEMU's 
development process.  By the date of the soft feature freeze, any major feature 
should have some code posted to the qemu-devel mailing list if it's targeting a 
given release.

== What should I do by the soft feature freeze? ==

For any major feature that you're targeting to the next release, you should:

# Make sure that you've posted a patch series to qemu-devel
# Write a Feature page on the qemu.org wiki describing the feature and the 
motivation
# On the release planning wiki page, link to your feature wiki page.

== Will my patches be rejected if I don't post before the soft feature freeze? ==

That's ultimately up to the subsystem maintainer.  It's a value call based on 
the relative importance of the feature verses the disruptiveness of the feature. 
  It's always best to avoid this problem in the first place and release early, 
release often[http://en.wikipedia.org/wiki/Release_early,_release_often].

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Consider this a friendly reminder that we're only three weeks away from the
> soft feature freeze for 1.0.  I've written a wiki page about my expectations
> for the soft feature freeze.  It's inlined here for easier commenting.

I think the freezes and the release should be delayed until the memory
API conversion is finished, deliberately shipping semi-broken code
just to satisfy schedules does not benefit anyone but the schedule
creator. It looks to me that converting all buses and devices might be
finished by the deadline but it may as well take a bit more until
everything works again.

> == What is the soft feature freeze? ==
>
> The soft feature freeze is the beginning of the stabilization phase of
> QEMU's development process.  By the date of the soft feature freeze, any
> major feature should have some code posted to the qemu-devel mailing list if
> it's targeting a given release.
>
> == What should I do by the soft feature freeze? ==
>
> For any major feature that you're targeting to the next release, you should:
>
> # Make sure that you've posted a patch series to qemu-devel
> # Write a Feature page on the qemu.org wiki describing the feature and the
> motivation
> # On the release planning wiki page, link to your feature wiki page.
>
> == Will my patches be rejected if I don't post before the soft feature
> freeze? ==
>
> That's ultimately up to the subsystem maintainer.  It's a value call based
> on the relative importance of the feature verses the disruptiveness of the
> feature.  It's always best to avoid this problem in the first place and
> release early, release
> often[http://en.wikipedia.org/wiki/Release_early,_release_often].
>
>

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Avi Kivity]

On 09/24/2011 11:05 AM, Blue Swirl wrote:
> On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
> >  Consider this a friendly reminder that we're only three weeks away from the
> >  soft feature freeze for 1.0.  I've written a wiki page about my expectations
> >  for the soft feature freeze.  It's inlined here for easier commenting.
>
> I think the freezes and the release should be delayed until the memory
> API conversion is finished, deliberately shipping semi-broken code
> just to satisfy schedules does not benefit anyone but the schedule
> creator. It looks to me that converting all buses and devices might be
> finished by the deadline but it may as well take a bit more until
> everything works again.
>

There is a difference between "incomplete conversion" and "semi-broken 
code".  Any breakage should be fixed promptly, but after some freeze 
date (not sure if this is the one proposed), additional conversions 
would be pushed to 1.1.

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

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Sun, Sep 25, 2011 at 2:10 PM, Avi Kivity <avi@redhat.com> wrote:
> On 09/24/2011 11:05 AM, Blue Swirl wrote:
>>
>> On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>> >  Consider this a friendly reminder that we're only three weeks away from
>> > the
>> >  soft feature freeze for 1.0.  I've written a wiki page about my
>> > expectations
>> >  for the soft feature freeze.  It's inlined here for easier commenting.
>>
>> I think the freezes and the release should be delayed until the memory
>> API conversion is finished, deliberately shipping semi-broken code
>> just to satisfy schedules does not benefit anyone but the schedule
>> creator. It looks to me that converting all buses and devices might be
>> finished by the deadline but it may as well take a bit more until
>> everything works again.
>>
>
> There is a difference between "incomplete conversion" and "semi-broken
> code".  Any breakage should be fixed promptly, but after some freeze date
> (not sure if this is the one proposed), additional conversions would be
> pushed to 1.1.

Well, there's PPC VGA which is semi-broken by the incomplete conversion.

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Avi Kivity]

On 09/25/2011 07:36 PM, Blue Swirl wrote:
> On Sun, Sep 25, 2011 at 2:10 PM, Avi Kivity<avi@redhat.com>  wrote:
> >  On 09/24/2011 11:05 AM, Blue Swirl wrote:
> >>
> >>  On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori<anthony@codemonkey.ws>
> >>    wrote:
> >>  >    Consider this a friendly reminder that we're only three weeks away from
> >>  >  the
> >>  >    soft feature freeze for 1.0.  I've written a wiki page about my
> >>  >  expectations
> >>  >    for the soft feature freeze.  It's inlined here for easier commenting.
> >>
> >>  I think the freezes and the release should be delayed until the memory
> >>  API conversion is finished, deliberately shipping semi-broken code
> >>  just to satisfy schedules does not benefit anyone but the schedule
> >>  creator. It looks to me that converting all buses and devices might be
> >>  finished by the deadline but it may as well take a bit more until
> >>  everything works again.
> >>
> >
> >  There is a difference between "incomplete conversion" and "semi-broken
> >  code".  Any breakage should be fixed promptly, but after some freeze date
> >  (not sure if this is the one proposed), additional conversions would be
> >  pushed to 1.1.
>
> Well, there's PPC VGA which is semi-broken by the incomplete conversion.

Please point out a test case and I'll try to fix it.

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

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Sun, Sep 25, 2011 at 4:48 PM, Avi Kivity <avi@redhat.com> wrote:
> On 09/25/2011 07:36 PM, Blue Swirl wrote:
>>
>> On Sun, Sep 25, 2011 at 2:10 PM, Avi Kivity<avi@redhat.com>  wrote:
>> >  On 09/24/2011 11:05 AM, Blue Swirl wrote:
>> >>
>> >>  On Thu, Sep 22, 2011 at 12:34 AM, Anthony
>> >> Liguori<anthony@codemonkey.ws>
>> >>    wrote:
>> >>  >    Consider this a friendly reminder that we're only three weeks
>> >> away from
>> >>  >  the
>> >>  >    soft feature freeze for 1.0.  I've written a wiki page about my
>> >>  >  expectations
>> >>  >    for the soft feature freeze.  It's inlined here for easier
>> >> commenting.
>> >>
>> >>  I think the freezes and the release should be delayed until the memory
>> >>  API conversion is finished, deliberately shipping semi-broken code
>> >>  just to satisfy schedules does not benefit anyone but the schedule
>> >>  creator. It looks to me that converting all buses and devices might be
>> >>  finished by the deadline but it may as well take a bit more until
>> >>  everything works again.
>> >>
>> >
>> >  There is a difference between "incomplete conversion" and "semi-broken
>> >  code".  Any breakage should be fixed promptly, but after some freeze
>> > date
>> >  (not sure if this is the one proposed), additional conversions would be
>> >  pushed to 1.1.
>>
>> Well, there's PPC VGA which is semi-broken by the incomplete conversion.
>
> Please point out a test case and I'll try to fix it.

Run qemu-system-ppc without any arguments. There is a black bar
(because of vga.chain4), it shouldn't be there.

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Anthony Liguori]

On 09/25/2011 09:10 AM, Avi Kivity wrote:
> On 09/24/2011 11:05 AM, Blue Swirl wrote:
>> On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori<anthony@codemonkey.ws> wrote:
>> > Consider this a friendly reminder that we're only three weeks away from the
>> > soft feature freeze for 1.0. I've written a wiki page about my expectations
>> > for the soft feature freeze. It's inlined here for easier commenting.
>>
>> I think the freezes and the release should be delayed until the memory
>> API conversion is finished, deliberately shipping semi-broken code
>> just to satisfy schedules does not benefit anyone but the schedule
>> creator. It looks to me that converting all buses and devices might be
>> finished by the deadline but it may as well take a bit more until
>> everything works again.
>>
>
> There is a difference between "incomplete conversion" and "semi-broken code".
> Any breakage should be fixed promptly, but after some freeze date (not sure if
> this is the one proposed), additional conversions would be pushed to 1.1.

Right, it's up to the sub maintainers to determine whether something should be 
delayed once we're in soft feature freeze.

The dates are:

10/15 - Soft Feature Freeze
11/01 - Hard Freeze
11/01 - qemu-1.0-rc0 is tagged
11/04 - qemu-1.0-rc1 is tagged and released
11/11 - qemu-1.0-rc2 is tagged and released
11/18 - qemu-1.0-rc3 is tagged and released
11/23 - qemu-1.0-rc4 is tagged and released
12/01 - qemu-1.0 is tagged and released

Since there's a solid month of hard freeze, I would think that that's more than 
enough time to stablize memory API changes.

Regards,

Anthony Liguori

>

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Avi Kivity]

On 09/25/2011 08:31 PM, Blue Swirl wrote:
> >
> >  Please point out a test case and I'll try to fix it.
>
> Run qemu-system-ppc without any arguments. There is a black bar
> (because of vga.chain4), it shouldn't be there.

With your pci hole patch, it's fixed, except for:

     escc_mem = escc_init(0x80013000, pic[0x25], pic[0x24],
                          serial_hds[0], serial_hds[1], ESCC_CLOCK, 4)

This puts escc bang into the framebuffer.  Changing it to 0x90013000 
makes the black bar go away.

Before the memory API, this worked, likely because the framebuffer 
overlays escc.

The correct fix depends on what the hardware does.  Is escc really 
registered into the pci area, and again as a BAR?

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

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Avi Kivity]

On 09/26/2011 01:08 PM, Avi Kivity wrote:
> On 09/25/2011 08:31 PM, Blue Swirl wrote:
>> >
>> >  Please point out a test case and I'll try to fix it.
>>
>> Run qemu-system-ppc without any arguments. There is a black bar
>> (because of vga.chain4), it shouldn't be there.
>
> With your pci hole patch, it's fixed, except for:
>
>     escc_mem = escc_init(0x80013000, pic[0x25], pic[0x24],
>                          serial_hds[0], serial_hds[1], ESCC_CLOCK, 4)
>
> This puts escc bang into the framebuffer.  Changing it to 0x90013000 
> makes the black bar go away.
>
> Before the memory API, this worked, likely because the framebuffer 
> overlays escc.
>
> The correct fix depends on what the hardware does.  Is escc really 
> registered into the pci area, and again as a BAR?
>

If we reenable the collision warning in memory.c, we see

   warning: subregion collision 80013000/40 (escc) vs 80000000/70000000 
(pci-hole)

I'll work on reenabling ir permanently.

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

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Mon, Sep 26, 2011 at 10:08 AM, Avi Kivity <avi@redhat.com> wrote:
> On 09/25/2011 08:31 PM, Blue Swirl wrote:
>>
>> >
>> >  Please point out a test case and I'll try to fix it.
>>
>> Run qemu-system-ppc without any arguments. There is a black bar
>> (because of vga.chain4), it shouldn't be there.
>
> With your pci hole patch, it's fixed, except for:
>
>    escc_mem = escc_init(0x80013000, pic[0x25], pic[0x24],
>                         serial_hds[0], serial_hds[1], ESCC_CLOCK, 4)
>
> This puts escc bang into the framebuffer.  Changing it to 0x90013000 makes
> the black bar go away.
>
> Before the memory API, this worked, likely because the framebuffer overlays
> escc.
>
> The correct fix depends on what the hardware does.  Is escc really
> registered into the pci area, and again as a BAR?

I think the previous code assumed that there is a single BAR with
default address of 0x80013000, but it can move as controlled by macio
mapping.

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Avi Kivity]

On 09/26/2011 08:15 PM, Blue Swirl wrote:
> On Mon, Sep 26, 2011 at 10:08 AM, Avi Kivity<avi@redhat.com>  wrote:
> >  On 09/25/2011 08:31 PM, Blue Swirl wrote:
> >>
> >>  >
> >>  >    Please point out a test case and I'll try to fix it.
> >>
> >>  Run qemu-system-ppc without any arguments. There is a black bar
> >>  (because of vga.chain4), it shouldn't be there.
> >
> >  With your pci hole patch, it's fixed, except for:
> >
> >      escc_mem = escc_init(0x80013000, pic[0x25], pic[0x24],
> >                           serial_hds[0], serial_hds[1], ESCC_CLOCK, 4)
> >
> >  This puts escc bang into the framebuffer.  Changing it to 0x90013000 makes
> >  the black bar go away.
> >
> >  Before the memory API, this worked, likely because the framebuffer overlays
> >  escc.
> >
> >  The correct fix depends on what the hardware does.  Is escc really
> >  registered into the pci area, and again as a BAR?
>
> I think the previous code assumed that there is a single BAR with
> default address of 0x80013000, but it can move as controlled by macio
> mapping.

So the fix would be to just drop this extraneous mapping?

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

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Mon, Sep 26, 2011 at 5:18 PM, Avi Kivity <avi@redhat.com> wrote:
> On 09/26/2011 08:15 PM, Blue Swirl wrote:
>>
>> On Mon, Sep 26, 2011 at 10:08 AM, Avi Kivity<avi@redhat.com>  wrote:
>> >  On 09/25/2011 08:31 PM, Blue Swirl wrote:
>> >>
>> >>  >
>> >>  >    Please point out a test case and I'll try to fix it.
>> >>
>> >>  Run qemu-system-ppc without any arguments. There is a black bar
>> >>  (because of vga.chain4), it shouldn't be there.
>> >
>> >  With your pci hole patch, it's fixed, except for:
>> >
>> >      escc_mem = escc_init(0x80013000, pic[0x25], pic[0x24],
>> >                           serial_hds[0], serial_hds[1], ESCC_CLOCK, 4)
>> >
>> >  This puts escc bang into the framebuffer.  Changing it to 0x90013000
>> > makes
>> >  the black bar go away.
>> >
>> >  Before the memory API, this worked, likely because the framebuffer
>> > overlays
>> >  escc.
>> >
>> >  The correct fix depends on what the hardware does.  Is escc really
>> >  registered into the pci area, and again as a BAR?
>>
>> I think the previous code assumed that there is a single BAR with
>> default address of 0x80013000, but it can move as controlled by macio
>> mapping.
>
> So the fix would be to just drop this extraneous mapping?

The default address is used for early serial printk in OpenBIOS, so it
should still work.

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Avi Kivity]

On 09/26/2011 08:20 PM, Blue Swirl wrote:
> On Mon, Sep 26, 2011 at 5:18 PM, Avi Kivity<avi@redhat.com>  wrote:
> >  On 09/26/2011 08:15 PM, Blue Swirl wrote:
> >>
> >>  On Mon, Sep 26, 2011 at 10:08 AM, Avi Kivity<avi@redhat.com>    wrote:
> >>  >    On 09/25/2011 08:31 PM, Blue Swirl wrote:
> >>  >>
> >>  >>    >
> >>  >>    >      Please point out a test case and I'll try to fix it.
> >>  >>
> >>  >>    Run qemu-system-ppc without any arguments. There is a black bar
> >>  >>    (because of vga.chain4), it shouldn't be there.
> >>  >
> >>  >    With your pci hole patch, it's fixed, except for:
> >>  >
> >>  >        escc_mem = escc_init(0x80013000, pic[0x25], pic[0x24],
> >>  >                             serial_hds[0], serial_hds[1], ESCC_CLOCK, 4)
> >>  >
> >>  >    This puts escc bang into the framebuffer.  Changing it to 0x90013000
> >>  >  makes
> >>  >    the black bar go away.
> >>  >
> >>  >    Before the memory API, this worked, likely because the framebuffer
> >>  >  overlays
> >>  >    escc.
> >>  >
> >>  >    The correct fix depends on what the hardware does.  Is escc really
> >>  >    registered into the pci area, and again as a BAR?
> >>
> >>  I think the previous code assumed that there is a single BAR with
> >>  default address of 0x80013000, but it can move as controlled by macio
> >>  mapping.
> >
> >  So the fix would be to just drop this extraneous mapping?
>
> The default address is used for early serial printk in OpenBIOS, so it
> should still work.

Ok, so drop the extra mapping, but init the dynamic mapping to 0x80013000.

The whole dual mapping thing is wierd and set up some hoops for me to 
jump through, it's probably completely bogus.


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

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Mon, Sep 26, 2011 at 5:24 PM, Avi Kivity <avi@redhat.com> wrote:
> On 09/26/2011 08:20 PM, Blue Swirl wrote:
>>
>> On Mon, Sep 26, 2011 at 5:18 PM, Avi Kivity<avi@redhat.com>  wrote:
>> >  On 09/26/2011 08:15 PM, Blue Swirl wrote:
>> >>
>> >>  On Mon, Sep 26, 2011 at 10:08 AM, Avi Kivity<avi@redhat.com>    wrote:
>> >>  >    On 09/25/2011 08:31 PM, Blue Swirl wrote:
>> >>  >>
>> >>  >>    >
>> >>  >>    >      Please point out a test case and I'll try to fix it.
>> >>  >>
>> >>  >>    Run qemu-system-ppc without any arguments. There is a black bar
>> >>  >>    (because of vga.chain4), it shouldn't be there.
>> >>  >
>> >>  >    With your pci hole patch, it's fixed, except for:
>> >>  >
>> >>  >        escc_mem = escc_init(0x80013000, pic[0x25], pic[0x24],
>> >>  >                             serial_hds[0], serial_hds[1],
>> >> ESCC_CLOCK, 4)
>> >>  >
>> >>  >    This puts escc bang into the framebuffer.  Changing it to
>> >> 0x90013000
>> >>  >  makes
>> >>  >    the black bar go away.
>> >>  >
>> >>  >    Before the memory API, this worked, likely because the
>> >> framebuffer
>> >>  >  overlays
>> >>  >    escc.
>> >>  >
>> >>  >    The correct fix depends on what the hardware does.  Is escc
>> >> really
>> >>  >    registered into the pci area, and again as a BAR?
>> >>
>> >>  I think the previous code assumed that there is a single BAR with
>> >>  default address of 0x80013000, but it can move as controlled by macio
>> >>  mapping.
>> >
>> >  So the fix would be to just drop this extraneous mapping?
>>
>> The default address is used for early serial printk in OpenBIOS, so it
>> should still work.
>
> Ok, so drop the extra mapping, but init the dynamic mapping to 0x80013000.

That should work.

> The whole dual mapping thing is wierd and set up some hoops for me to jump
> through, it's probably completely bogus.

Yes.

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Avi Kivity]

On 09/26/2011 09:07 PM, Blue Swirl wrote:
> >>  The default address is used for early serial printk in OpenBIOS, so it
> >>  should still work.
> >
> >  Ok, so drop the extra mapping, but init the dynamic mapping to 0x80013000.
>
> That should work.

It's already there (macio.c):

     if (macio_state->escc_mem) {
         memory_region_add_subregion(bar, 0x13000, macio_state->escc_mem);
     }

I'll drop the extra mapping.

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

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Avi Kivity]

On 09/27/2011 11:33 AM, Avi Kivity wrote:
> On 09/26/2011 09:07 PM, Blue Swirl wrote:
>> >>  The default address is used for early serial printk in OpenBIOS, 
>> so it
>> >>  should still work.
>> >
>> >  Ok, so drop the extra mapping, but init the dynamic mapping to 
>> 0x80013000.
>>
>> That should work.
>
> It's already there (macio.c):
>
>     if (macio_state->escc_mem) {
>         memory_region_add_subregion(bar, 0x13000, macio_state->escc_mem);
>     }
>
> I'll drop the extra mapping.
>

Well, it's not that easy.  As the other mapping is part of an ordinary 
BAR, you need to setup the device (at least PCI_COMMAND and 
PCI_BASE_ADDRESS_0) so it responds to memory requests, and also enable 
the bridge.

We could hack it by having a low-priority mapping at 0x80013000, but it 
seems wrong.  Maybe the firmware should configure that BAR first?  What 
happens on real hardware?

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

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Tue, Sep 27, 2011 at 8:57 AM, Avi Kivity <avi@redhat.com> wrote:
> On 09/27/2011 11:33 AM, Avi Kivity wrote:
>>
>> On 09/26/2011 09:07 PM, Blue Swirl wrote:
>>>
>>> >>  The default address is used for early serial printk in OpenBIOS, so
>>> >> it
>>> >>  should still work.
>>> >
>>> >  Ok, so drop the extra mapping, but init the dynamic mapping to
>>> > 0x80013000.
>>>
>>> That should work.
>>
>> It's already there (macio.c):
>>
>>    if (macio_state->escc_mem) {
>>        memory_region_add_subregion(bar, 0x13000, macio_state->escc_mem);
>>    }
>>
>> I'll drop the extra mapping.
>>
>
> Well, it's not that easy.  As the other mapping is part of an ordinary BAR,
> you need to setup the device (at least PCI_COMMAND and PCI_BASE_ADDRESS_0)
> so it responds to memory requests, and also enable the bridge.
>
> We could hack it by having a low-priority mapping at 0x80013000, but it
> seems wrong.  Maybe the firmware should configure that BAR first?  What
> happens on real hardware?

In this message I seem to confess that the address is arbitrary and in
the subsequent messages the overlap with PCI region is also discussed.
http://lists.nongnu.org/archive/html/qemu-devel/2009-01/msg00542.html

Maybe the address of macio should be fixed as Laurent suggested.

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Avi Kivity]

On 09/27/2011 07:39 PM, Blue Swirl wrote:
> >
> >  Well, it's not that easy.  As the other mapping is part of an ordinary BAR,
> >  you need to setup the device (at least PCI_COMMAND and PCI_BASE_ADDRESS_0)
> >  so it responds to memory requests, and also enable the bridge.
> >
> >  We could hack it by having a low-priority mapping at 0x80013000, but it
> >  seems wrong.  Maybe the firmware should configure that BAR first?  What
> >  happens on real hardware?
>
> In this message I seem to confess that the address is arbitrary and in
> the subsequent messages the overlap with PCI region is also discussed.
> http://lists.nongnu.org/archive/html/qemu-devel/2009-01/msg00542.html
>
> Maybe the address of macio should be fixed as Laurent suggested.

I'll leave it up to you - I'm out of my depth here.

Meanwhile I suggest applying the pci alias patch - the bug is 
independent of the vga issue.


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

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Tue, Sep 27, 2011 at 4:44 PM, Avi Kivity <avi@redhat.com> wrote:
> On 09/27/2011 07:39 PM, Blue Swirl wrote:
>>
>> >
>> >  Well, it's not that easy.  As the other mapping is part of an ordinary
>> > BAR,
>> >  you need to setup the device (at least PCI_COMMAND and
>> > PCI_BASE_ADDRESS_0)
>> >  so it responds to memory requests, and also enable the bridge.
>> >
>> >  We could hack it by having a low-priority mapping at 0x80013000, but it
>> >  seems wrong.  Maybe the firmware should configure that BAR first?  What
>> >  happens on real hardware?
>>
>> In this message I seem to confess that the address is arbitrary and in
>> the subsequent messages the overlap with PCI region is also discussed.
>> http://lists.nongnu.org/archive/html/qemu-devel/2009-01/msg00542.html
>>
>> Maybe the address of macio should be fixed as Laurent suggested.
>
> I'll leave it up to you - I'm out of my depth here.
>
> Meanwhile I suggest applying the pci alias patch - the bug is independent of
> the vga issue.

OK, pushed.

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Alexander Graf]

[-- Attachment #1: Type: text/plain, Size: 4661 bytes --]


On 27.09.2011, at 21:19, Blue Swirl wrote:

> On Tue, Sep 27, 2011 at 4:44 PM, Avi Kivity <avi@redhat.com> wrote:
>> On 09/27/2011 07:39 PM, Blue Swirl wrote:
>>> 
>>>> 
>>>>  Well, it's not that easy.  As the other mapping is part of an ordinary
>>>> BAR,
>>>>  you need to setup the device (at least PCI_COMMAND and
>>>> PCI_BASE_ADDRESS_0)
>>>>  so it responds to memory requests, and also enable the bridge.
>>>> 
>>>>  We could hack it by having a low-priority mapping at 0x80013000, but it
>>>>  seems wrong.  Maybe the firmware should configure that BAR first?  What
>>>>  happens on real hardware?
>>> 
>>> In this message I seem to confess that the address is arbitrary and in
>>> the subsequent messages the overlap with PCI region is also discussed.
>>> http://lists.nongnu.org/archive/html/qemu-devel/2009-01/msg00542.html
>>> 
>>> Maybe the address of macio should be fixed as Laurent suggested.
>> 
>> I'll leave it up to you - I'm out of my depth here.
>> 
>> Meanwhile I suggest applying the pci alias patch - the bug is independent of
>> the vga issue.
> 
> OK, pushed.
> 

Ah, after digging into the issue for a while myself I stumbled over this thread, explaining what I figured would be the culprit. Please CC qemu-ppc for these discussions :).

Either way, I'm seeing 2 issues here. I enhanced the "info mtree" command to also display the region we're currently looking at, so the first tuple shows the region we're in, the second tuple the region we're trying to map into the first region (addresses aligned on each other). I also print out alias information directly:

[ 00000000-7ffffffffffffffe ] 00000000-7ffffffffffffffe : system
  [ 80013000-8001303f ] 80013000-8001303f : escc
  [ fee00000-fee00fff ] fee00000-fee00fff : pci-data-idx
  [ fec00000-fec00fff ] fec00000-fec00fff : pci-conf-idx
  [ 80000000-fdffffff ] 80000000-fdffffff : pci-hole
   -> alias (0000000080000000, 0000000000000000)
    [ 80000000-fdffffff ] 00000000-ffffffff : pci-mmio
      [ 80880000-808fffff ] 80880000-808fffff : macio
        [ 808e0000-808fffff ] 808e0000-808fffff : macio-nvram
        [ 808a0000-808a0fff ] 808a0000-808a0fff : pmac-ide
        [ 80896000-80897fff ] 80896000-80897fff : cuda
        [ 80893000-8089303f ] 80893000-8089303f : escc-bar
         -> alias (0000000000000000, 0000000080013000)
          [ 80893000-8089303f ] 80893000-8089303f : escc
        [ 80888000-80888fff ] 80888000-80888fff : dbdma
        [ 80880000-80880fff ] 80880000-80880fff : heathrow-pic
      [ 80800000-8080ffff ] 80800000-8080ffff : vga.rom
      [ 80000000-807fffff ] 80000000-807fffff : vga.vram
  [ fe000000-fe1fffff ] fe000000-fe1fffff : isa-mmio
I/O
[ 00000000-0000ffff ] 00000000-0000ffff : io
  [ 00000700-0000070f ] 00000700-0000070f : cmd646-bmdma
    [ 0000070c-0000070f ] 0000070c-0000070f : cmd646-bmdma-ioport
    [ 00000708-0000070b ] 00000708-0000070b : cmd646-bmdma-bus
    [ 00000704-00000707 ] 00000704-00000707 : cmd646-bmdma-ioport
    [ 00000700-00000703 ] 00000700-00000703 : cmd646-bmdma-bus
  [ 00000680-00000683 ] 00000680-00000683 : cmd646-cmd
  [ 00000600-00000607 ] 00000600-00000607 : cmd646-data
  [ 00000580-00000583 ] 00000580-00000583 : cmd646-cmd
  [ 00000500-00000507 ] 00000500-00000507 : cmd646-data
  [ 00000400-000004ff ] 00000400-000004ff : ne2000

I did another small hack to display the flat memory view:

  ranges[0] = { 80000000, 13000 } vga.vram
  ranges[1] = { 80013000, 40 } escc
  ranges[2] = { 80013040, 7ecfc0 } vga.vram
  ranges[3] = { 80800000, 10000 } vga.rom
  ranges[4] = { 80880000, 1000 } heathrow-pic
  ranges[5] = { 80888000, 1000 } dbdma
  ranges[6] = { 80893000, 40 } escc
  ranges[7] = { 80896000, 2000 } cuda
  ranges[8] = { 808a0000, 1000 } pmac-ide
  ranges[9] = { 808e0000, 20000 } macio-nvram
  ranges[10] = { fe000000, 200000 } isa-mmio
  ranges[11] = { fec00000, 1000 } pci-conf-idx
  ranges[12] = { fee00000, 1000 } pci-data-idx

Now to the issues:

1)

ESCC is mapped inside the VGA region. That's what you discussed in this thread. It's wrong. Please check this bug for a dump of a real G3 Beige's memory layout:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555651

I don't think we really need to have serial available before PCI enum, so let's just ditch the first map.

2)

vga.vram continues to be mapped, but apparently isn't accessible. I would expect the hole of 40 bytes to be non-accessible / broken, but what ends up happening is that the whole second region apparently is unusable. What exactly is going on there? Sounds like a memory API bug to me.


Alex


[-- Attachment #2: Type: text/html, Size: 8056 bytes --]

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Wed, Sep 28, 2011 at 9:21 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 27.09.2011, at 21:19, Blue Swirl wrote:
>
> On Tue, Sep 27, 2011 at 4:44 PM, Avi Kivity <avi@redhat.com> wrote:
>
> On 09/27/2011 07:39 PM, Blue Swirl wrote:
>
>
>  Well, it's not that easy.  As the other mapping is part of an ordinary
>
> BAR,
>
>  you need to setup the device (at least PCI_COMMAND and
>
> PCI_BASE_ADDRESS_0)
>
>  so it responds to memory requests, and also enable the bridge.
>
>  We could hack it by having a low-priority mapping at 0x80013000, but it
>
>  seems wrong.  Maybe the firmware should configure that BAR first?  What
>
>  happens on real hardware?
>
> In this message I seem to confess that the address is arbitrary and in
>
> the subsequent messages the overlap with PCI region is also discussed.
>
> http://lists.nongnu.org/archive/html/qemu-devel/2009-01/msg00542.html
>
> Maybe the address of macio should be fixed as Laurent suggested.
>
> I'll leave it up to you - I'm out of my depth here.
>
> Meanwhile I suggest applying the pci alias patch - the bug is independent of
>
> the vga issue.
>
> OK, pushed.
>
>
> Ah, after digging into the issue for a while myself I stumbled over this
> thread, explaining what I figured would be the culprit. Please CC qemu-ppc
> for these discussions :).
> Either way, I'm seeing 2 issues here. I enhanced the "info mtree" command to
> also display the region we're currently looking at, so the first tuple shows
> the region we're in, the second tuple the region we're trying to map into
> the first region (addresses aligned on each other). I also print out alias
> information directly:

That way you miss for example vga.chain4.

> [ 00000000-7ffffffffffffffe ] 00000000-7ffffffffffffffe : system
>   [ 80013000-8001303f ] 80013000-8001303f : escc
>   [ fee00000-fee00fff ] fee00000-fee00fff : pci-data-idx
>   [ fec00000-fec00fff ] fec00000-fec00fff : pci-conf-idx
>   [ 80000000-fdffffff ] 80000000-fdffffff : pci-hole
>    -> alias (0000000080000000, 0000000000000000)
>     [ 80000000-fdffffff ] 00000000-ffffffff : pci-mmio
>       [ 80880000-808fffff ] 80880000-808fffff : macio
>         [ 808e0000-808fffff ] 808e0000-808fffff : macio-nvram
>         [ 808a0000-808a0fff ] 808a0000-808a0fff : pmac-ide
>         [ 80896000-80897fff ] 80896000-80897fff : cuda
>         [ 80893000-8089303f ] 80893000-8089303f : escc-bar
>          -> alias (0000000000000000, 0000000080013000)
>           [ 80893000-8089303f ] 80893000-8089303f : escc
>         [ 80888000-80888fff ] 80888000-80888fff : dbdma
>         [ 80880000-80880fff ] 80880000-80880fff : heathrow-pic
>       [ 80800000-8080ffff ] 80800000-8080ffff : vga.rom
>       [ 80000000-807fffff ] 80000000-807fffff : vga.vram
>   [ fe000000-fe1fffff ] fe000000-fe1fffff : isa-mmio
> I/O
> [ 00000000-0000ffff ] 00000000-0000ffff : io
>   [ 00000700-0000070f ] 00000700-0000070f : cmd646-bmdma
>     [ 0000070c-0000070f ] 0000070c-0000070f : cmd646-bmdma-ioport
>     [ 00000708-0000070b ] 00000708-0000070b : cmd646-bmdma-bus
>     [ 00000704-00000707 ] 00000704-00000707 : cmd646-bmdma-ioport
>     [ 00000700-00000703 ] 00000700-00000703 : cmd646-bmdma-bus
>   [ 00000680-00000683 ] 00000680-00000683 : cmd646-cmd
>   [ 00000600-00000607 ] 00000600-00000607 : cmd646-data
>   [ 00000580-00000583 ] 00000580-00000583 : cmd646-cmd
>   [ 00000500-00000507 ] 00000500-00000507 : cmd646-data
>   [ 00000400-000004ff ] 00000400-000004ff : ne2000
> I did another small hack to display the flat memory view:
>   ranges[0] = { 80000000, 13000 } vga.vram
>   ranges[1] = { 80013000, 40 } escc
>   ranges[2] = { 80013040, 7ecfc0 } vga.vram
>   ranges[3] = { 80800000, 10000 } vga.rom
>   ranges[4] = { 80880000, 1000 } heathrow-pic
>   ranges[5] = { 80888000, 1000 } dbdma
>   ranges[6] = { 80893000, 40 } escc
>   ranges[7] = { 80896000, 2000 } cuda
>   ranges[8] = { 808a0000, 1000 } pmac-ide
>   ranges[9] = { 808e0000, 20000 } macio-nvram
>   ranges[10] = { fe000000, 200000 } isa-mmio
>   ranges[11] = { fec00000, 1000 } pci-conf-idx
>   ranges[12] = { fee00000, 1000 } pci-data-idx
> Now to the issues:
> 1)
> ESCC is mapped inside the VGA region. That's what you discussed in this
> thread. It's wrong. Please check this bug for a dump of a real G3 Beige's
> memory layout:
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555651
> I don't think we really need to have serial available before PCI enum, so
> let's just ditch the first map.

OK, though it would be useful for -nographic mode. OpenBIOS can queue
the output until a serial device has been probed and then print the
buffer, but if it crashes before that, we're out of luck.

BTW, -nographic does not work anymore for PPC, there is no output.

> 2)
> vga.vram continues to be mapped, but apparently isn't accessible. I would
> expect the hole of 40 bytes to be non-accessible / broken, but what ends up
> happening is that the whole second region apparently is unusable. What
> exactly is going on there? Sounds like a memory API bug to me.
>
> Alex
>

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Alexander Graf]

Am 29.09.2011 um 21:28 schrieb Blue Swirl <blauwirbel@gmail.com>:

> On Wed, Sep 28, 2011 at 9:21 PM, Alexander Graf <agraf@suse.de> wrote:
>> 
>> On 27.09.2011, at 21:19, Blue Swirl wrote:
>> 
>> On Tue, Sep 27, 2011 at 4:44 PM, Avi Kivity <avi@redhat.com> wrote:
>> 
>> On 09/27/2011 07:39 PM, Blue Swirl wrote:
>> 
>> 
>>  Well, it's not that easy.  As the other mapping is part of an ordinary
>> 
>> BAR,
>> 
>>  you need to setup the device (at least PCI_COMMAND and
>> 
>> PCI_BASE_ADDRESS_0)
>> 
>>  so it responds to memory requests, and also enable the bridge.
>> 
>>  We could hack it by having a low-priority mapping at 0x80013000, but it
>> 
>>  seems wrong.  Maybe the firmware should configure that BAR first?  What
>> 
>>  happens on real hardware?
>> 
>> In this message I seem to confess that the address is arbitrary and in
>> 
>> the subsequent messages the overlap with PCI region is also discussed.
>> 
>> http://lists.nongnu.org/archive/html/qemu-devel/2009-01/msg00542.html
>> 
>> Maybe the address of macio should be fixed as Laurent suggested.
>> 
>> I'll leave it up to you - I'm out of my depth here.
>> 
>> Meanwhile I suggest applying the pci alias patch - the bug is independent of
>> 
>> the vga issue.
>> 
>> OK, pushed.
>> 
>> 
>> Ah, after digging into the issue for a while myself I stumbled over this
>> thread, explaining what I figured would be the culprit. Please CC qemu-ppc
>> for these discussions :).
>> Either way, I'm seeing 2 issues here. I enhanced the "info mtree" command to
>> also display the region we're currently looking at, so the first tuple shows
>> the region we're in, the second tuple the region we're trying to map into
>> the first region (addresses aligned on each other). I also print out alias
>> information directly:
> 
> That way you miss for example vga.chain4.
> 
>> [ 00000000-7ffffffffffffffe ] 00000000-7ffffffffffffffe : system
>>   [ 80013000-8001303f ] 80013000-8001303f : escc
>>   [ fee00000-fee00fff ] fee00000-fee00fff : pci-data-idx
>>   [ fec00000-fec00fff ] fec00000-fec00fff : pci-conf-idx
>>   [ 80000000-fdffffff ] 80000000-fdffffff : pci-hole
>>    -> alias (0000000080000000, 0000000000000000)
>>     [ 80000000-fdffffff ] 00000000-ffffffff : pci-mmio
>>       [ 80880000-808fffff ] 80880000-808fffff : macio
>>         [ 808e0000-808fffff ] 808e0000-808fffff : macio-nvram
>>         [ 808a0000-808a0fff ] 808a0000-808a0fff : pmac-ide
>>         [ 80896000-80897fff ] 80896000-80897fff : cuda
>>         [ 80893000-8089303f ] 80893000-8089303f : escc-bar
>>          -> alias (0000000000000000, 0000000080013000)
>>           [ 80893000-8089303f ] 80893000-8089303f : escc
>>         [ 80888000-80888fff ] 80888000-80888fff : dbdma
>>         [ 80880000-80880fff ] 80880000-80880fff : heathrow-pic
>>       [ 80800000-8080ffff ] 80800000-8080ffff : vga.rom
>>       [ 80000000-807fffff ] 80000000-807fffff : vga.vram
>>   [ fe000000-fe1fffff ] fe000000-fe1fffff : isa-mmio
>> I/O
>> [ 00000000-0000ffff ] 00000000-0000ffff : io
>>   [ 00000700-0000070f ] 00000700-0000070f : cmd646-bmdma
>>     [ 0000070c-0000070f ] 0000070c-0000070f : cmd646-bmdma-ioport
>>     [ 00000708-0000070b ] 00000708-0000070b : cmd646-bmdma-bus
>>     [ 00000704-00000707 ] 00000704-00000707 : cmd646-bmdma-ioport
>>     [ 00000700-00000703 ] 00000700-00000703 : cmd646-bmdma-bus
>>   [ 00000680-00000683 ] 00000680-00000683 : cmd646-cmd
>>   [ 00000600-00000607 ] 00000600-00000607 : cmd646-data
>>   [ 00000580-00000583 ] 00000580-00000583 : cmd646-cmd
>>   [ 00000500-00000507 ] 00000500-00000507 : cmd646-data
>>   [ 00000400-000004ff ] 00000400-000004ff : ne2000
>> I did another small hack to display the flat memory view:
>>   ranges[0] = { 80000000, 13000 } vga.vram
>>   ranges[1] = { 80013000, 40 } escc
>>   ranges[2] = { 80013040, 7ecfc0 } vga.vram
>>   ranges[3] = { 80800000, 10000 } vga.rom
>>   ranges[4] = { 80880000, 1000 } heathrow-pic
>>   ranges[5] = { 80888000, 1000 } dbdma
>>   ranges[6] = { 80893000, 40 } escc
>>   ranges[7] = { 80896000, 2000 } cuda
>>   ranges[8] = { 808a0000, 1000 } pmac-ide
>>   ranges[9] = { 808e0000, 20000 } macio-nvram
>>   ranges[10] = { fe000000, 200000 } isa-mmio
>>   ranges[11] = { fec00000, 1000 } pci-conf-idx
>>   ranges[12] = { fee00000, 1000 } pci-data-idx
>> Now to the issues:
>> 1)
>> ESCC is mapped inside the VGA region. That's what you discussed in this
>> thread. It's wrong. Please check this bug for a dump of a real G3 Beige's
>> memory layout:
>>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555651
>> I don't think we really need to have serial available before PCI enum, so
>> let's just ditch the first map.
> 
> OK, though it would be useful for -nographic mode. OpenBIOS can queue
> the output until a serial device has been probed and then print the
> buffer, but if it crashes before that, we're out of luck.

Then we need to gdb into openBIOS and read out the buffer. I do that with Linux's log_buf all the time :)

> 
> BTW, -nographic does not work anymore for PPC, there is no output.

Hrm. That's new. Last time I checked there was output. I'll look at what's going on...

Alex

> 

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Stefan Berger]

On 09/21/2011 08:34 PM, Anthony Liguori wrote:
>
>
> For any major feature that you're targeting to the next release, you 
> should:
>
> # Make sure that you've posted a patch series to qemu-devel
> # Write a Feature page on the qemu.org wiki describing the feature and 
> the motivation
> # On the release planning wiki page, link to your feature wiki page.
Did that now for Phase I of TPM integration.

    Stefan

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Anthony Liguori]

On 09/29/2011 10:21 PM, Stefan Berger wrote:
> On 09/21/2011 08:34 PM, Anthony Liguori wrote:
>>
>>
>> For any major feature that you're targeting to the next release, you should:
>>
>> # Make sure that you've posted a patch series to qemu-devel
>> # Write a Feature page on the qemu.org wiki describing the feature and the
>> motivation
>> # On the release planning wiki page, link to your feature wiki page.
> Did that now for Phase I of TPM integration.

Thanks!

Regards,

Anthony Liguori

>
> Stefan
>
>

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Stefan Berger]

On 09/30/2011 08:59 AM, Anthony Liguori wrote:
> On 09/29/2011 10:21 PM, Stefan Berger wrote:
>> On 09/21/2011 08:34 PM, Anthony Liguori wrote:
>>>
>>>
>>> For any major feature that you're targeting to the next release, you 
>>> should:
>>>
>>> # Make sure that you've posted a patch series to qemu-devel
>>> # Write a Feature page on the qemu.org wiki describing the feature 
>>> and the
>>> motivation
>>> # On the release planning wiki page, link to your feature wiki page.
>> Did that now for Phase I of TPM integration.
>
> Thanks!

The latest revision of the patches can be found here:

https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03534.html


Previous noticable remarks from Michael Tsirkin here :-) :

http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03265.html

Regards,
    Stefan

>
> Regards,
>
> Anthony Liguori
>
>>
>> Stefan
>>
>>
>
>

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Max Filippov]

> For any major feature that you're targeting to the next release, you should:
>
> # Make sure that you've posted a patch series to qemu-devel
> # Write a Feature page on the qemu.org wiki describing the feature and the
> motivation
> # On the release planning wiki page, link to your feature wiki page.

Have done that for the target-xtensa.

-- 
Thanks.
-- Max

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Blue Swirl]

On Sat, Sep 24, 2011 at 9:56 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>
> On Sep 24, 2011 3:05 AM, "Blue Swirl" <blauwirbel@gmail.com> wrote:
>>
>> On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori <anthony@codemonkey.ws>
>> wrote:
>> > Consider this a friendly reminder that we're only three weeks away from
>> > the
>> > soft feature freeze for 1.0.  I've written a wiki page about my
>> > expectations
>> > for the soft feature freeze.  It's inlined here for easier commenting.
>>
>> I think the freezes and the release should be delayed until the memory
>> API conversion is finished, deliberately shipping semi-broken code
>> just to satisfy schedules does not benefit anyone but the schedule
>> creator. It looks to me that converting all buses and devices might be
>> finished by the deadline but it may as well take a bit more until
>> everything works again.
>
> The point of having a freeze period is to give time to fix any problems.
> Six weeks should be plenty of time to fix any memory API fall out.

Maybe I'm too pessimistic about the schedule, but we'll see.

>
> Regards,
>
> Anthony Liguori
>
>> > == What is the soft feature freeze? ==
>> >
>> > The soft feature freeze is the beginning of the stabilization phase of
>> > QEMU's development process.  By the date of the soft feature freeze, any
>> > major feature should have some code posted to the qemu-devel mailing
>> > list if
>> > it's targeting a given release.
>> >
>> > == What should I do by the soft feature freeze? ==
>> >
>> > For any major feature that you're targeting to the next release, you
>> > should:
>> >
>> > # Make sure that you've posted a patch series to qemu-devel
>> > # Write a Feature page on the qemu.org wiki describing the feature and
>> > the
>> > motivation
>> > # On the release planning wiki page, link to your feature wiki page.
>> >
>> > == Will my patches be rejected if I don't post before the soft feature
>> > freeze? ==
>> >
>> > That's ultimately up to the subsystem maintainer.  It's a value call
>> > based
>> > on the relative importance of the feature verses the disruptiveness of
>> > the
>> > feature.  It's always best to avoid this problem in the first place and
>> > release early, release
>> > often[http://en.wikipedia.org/wiki/Release_early,_release_often].
>> >
>> >
>

Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

On Sep 24, 2011 3:05 AM, "Blue Swirl" <blauwirbel@gmail.com> wrote:
>
> On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori <anthony@codemonkey.ws>
wrote:
> > Consider this a friendly reminder that we're only three weeks away from
the
> > soft feature freeze for 1.0.  I've written a wiki page about my
expectations
> > for the soft feature freeze.  It's inlined here for easier commenting.
>
> I think the freezes and the release should be delayed until the memory
> API conversion is finished, deliberately shipping semi-broken code
> just to satisfy schedules does not benefit anyone but the schedule
> creator. It looks to me that converting all buses and devices might be
> finished by the deadline but it may as well take a bit more until
> everything works again.

The point of having a freeze period is to give time to fix any problems.
Six weeks should be plenty of time to fix any memory API fall out.

Regards,

Anthony Liguori

> > == What is the soft feature freeze? ==
> >
> > The soft feature freeze is the beginning of the stabilization phase of
> > QEMU's development process.  By the date of the soft feature freeze, any
> > major feature should have some code posted to the qemu-devel mailing
list if
> > it's targeting a given release.
> >
> > == What should I do by the soft feature freeze? ==
> >
> > For any major feature that you're targeting to the next release, you
should:
> >
> > # Make sure that you've posted a patch series to qemu-devel
> > # Write a Feature page on the qemu.org wiki describing the feature and
the
> > motivation
> > # On the release planning wiki page, link to your feature wiki page.
> >
> > == Will my patches be rejected if I don't post before the soft feature
> > freeze? ==
> >
> > That's ultimately up to the subsystem maintainer.  It's a value call
based
> > on the relative importance of the feature verses the disruptiveness of
the
> > feature.  It's always best to avoid this problem in the first place and
> > release early, release
> > often[http://en.wikipedia.org/wiki/Release_early,_release_often].
> >
> >

[-- Attachment #2: Type: text/html, Size: 2758 bytes --]