* [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)
@ 2011-09-22 0:34 Anthony Liguori
2011-09-24 8:05 ` Blue Swirl
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: Anthony Liguori @ 2011-09-22 0:34 UTC (permalink / raw)
To: qemu-devel
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].
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-22 0:34 [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) Anthony Liguori @ 2011-09-24 8:05 ` Blue Swirl 2011-09-25 14:10 ` Avi Kivity 2011-09-30 3:21 ` Stefan Berger 2011-10-10 12:14 ` Max Filippov 2 siblings, 1 reply; 28+ messages in thread From: Blue Swirl @ 2011-09-24 8:05 UTC (permalink / raw) To: Anthony Liguori, Avi Kivity; +Cc: qemu-devel 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]. > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-24 8:05 ` Blue Swirl @ 2011-09-25 14:10 ` Avi Kivity 2011-09-25 16:36 ` Blue Swirl 2011-09-25 19:50 ` Anthony Liguori 0 siblings, 2 replies; 28+ messages in thread From: Avi Kivity @ 2011-09-25 14:10 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-25 14:10 ` Avi Kivity @ 2011-09-25 16:36 ` Blue Swirl 2011-09-25 16:48 ` Avi Kivity 2011-09-25 19:50 ` Anthony Liguori 1 sibling, 1 reply; 28+ messages in thread From: Blue Swirl @ 2011-09-25 16:36 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-25 16:36 ` Blue Swirl @ 2011-09-25 16:48 ` Avi Kivity 2011-09-25 17:31 ` Blue Swirl 0 siblings, 1 reply; 28+ messages in thread From: Avi Kivity @ 2011-09-25 16:48 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-25 16:48 ` Avi Kivity @ 2011-09-25 17:31 ` Blue Swirl 2011-09-26 10:08 ` Avi Kivity 0 siblings, 1 reply; 28+ messages in thread From: Blue Swirl @ 2011-09-25 17:31 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-25 17:31 ` Blue Swirl @ 2011-09-26 10:08 ` Avi Kivity 2011-09-26 10:10 ` Avi Kivity 2011-09-26 17:15 ` Blue Swirl 0 siblings, 2 replies; 28+ messages in thread From: Avi Kivity @ 2011-09-26 10:08 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-26 10:08 ` Avi Kivity @ 2011-09-26 10:10 ` Avi Kivity 2011-09-26 17:15 ` Blue Swirl 1 sibling, 0 replies; 28+ messages in thread From: Avi Kivity @ 2011-09-26 10:10 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-26 10:08 ` Avi Kivity 2011-09-26 10:10 ` Avi Kivity @ 2011-09-26 17:15 ` Blue Swirl 2011-09-26 17:18 ` Avi Kivity 1 sibling, 1 reply; 28+ messages in thread From: Blue Swirl @ 2011-09-26 17:15 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-26 17:15 ` Blue Swirl @ 2011-09-26 17:18 ` Avi Kivity 2011-09-26 17:20 ` Blue Swirl 0 siblings, 1 reply; 28+ messages in thread From: Avi Kivity @ 2011-09-26 17:18 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-26 17:18 ` Avi Kivity @ 2011-09-26 17:20 ` Blue Swirl 2011-09-26 17:24 ` Avi Kivity 0 siblings, 1 reply; 28+ messages in thread From: Blue Swirl @ 2011-09-26 17:20 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-26 17:20 ` Blue Swirl @ 2011-09-26 17:24 ` Avi Kivity 2011-09-26 18:07 ` Blue Swirl 0 siblings, 1 reply; 28+ messages in thread From: Avi Kivity @ 2011-09-26 17:24 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-26 17:24 ` Avi Kivity @ 2011-09-26 18:07 ` Blue Swirl 2011-09-27 8:33 ` Avi Kivity 0 siblings, 1 reply; 28+ messages in thread From: Blue Swirl @ 2011-09-26 18:07 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-26 18:07 ` Blue Swirl @ 2011-09-27 8:33 ` Avi Kivity 2011-09-27 8:57 ` Avi Kivity 0 siblings, 1 reply; 28+ messages in thread From: Avi Kivity @ 2011-09-27 8:33 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-27 8:33 ` Avi Kivity @ 2011-09-27 8:57 ` Avi Kivity 2011-09-27 16:39 ` Blue Swirl 0 siblings, 1 reply; 28+ messages in thread From: Avi Kivity @ 2011-09-27 8:57 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-27 8:57 ` Avi Kivity @ 2011-09-27 16:39 ` Blue Swirl 2011-09-27 16:44 ` Avi Kivity 0 siblings, 1 reply; 28+ messages in thread From: Blue Swirl @ 2011-09-27 16:39 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-27 16:39 ` Blue Swirl @ 2011-09-27 16:44 ` Avi Kivity 2011-09-27 19:19 ` Blue Swirl 0 siblings, 1 reply; 28+ messages in thread From: Avi Kivity @ 2011-09-27 16:44 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-27 16:44 ` Avi Kivity @ 2011-09-27 19:19 ` Blue Swirl 2011-09-28 21:21 ` Alexander Graf 0 siblings, 1 reply; 28+ messages in thread From: Blue Swirl @ 2011-09-27 19:19 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-27 19:19 ` Blue Swirl @ 2011-09-28 21:21 ` Alexander Graf 2011-09-29 19:28 ` Blue Swirl 0 siblings, 1 reply; 28+ messages in thread From: Alexander Graf @ 2011-09-28 21:21 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-ppc, Avi Kivity, qemu-devel Developers [-- 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 --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-28 21:21 ` Alexander Graf @ 2011-09-29 19:28 ` Blue Swirl 2011-09-29 21:19 ` Alexander Graf 0 siblings, 1 reply; 28+ messages in thread From: Blue Swirl @ 2011-09-29 19:28 UTC (permalink / raw) To: Alexander Graf; +Cc: qemu-ppc, Avi Kivity, qemu-devel Developers 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-29 19:28 ` Blue Swirl @ 2011-09-29 21:19 ` Alexander Graf 0 siblings, 0 replies; 28+ messages in thread From: Alexander Graf @ 2011-09-29 21:19 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-ppc, Avi Kivity, qemu-devel Developers 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-25 14:10 ` Avi Kivity 2011-09-25 16:36 ` Blue Swirl @ 2011-09-25 19:50 ` Anthony Liguori 1 sibling, 0 replies; 28+ messages in thread From: Anthony Liguori @ 2011-09-25 19:50 UTC (permalink / raw) To: Avi Kivity; +Cc: Blue Swirl, qemu-devel 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-22 0:34 [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) Anthony Liguori 2011-09-24 8:05 ` Blue Swirl @ 2011-09-30 3:21 ` Stefan Berger 2011-09-30 12:59 ` Anthony Liguori 2011-10-10 12:14 ` Max Filippov 2 siblings, 1 reply; 28+ messages in thread From: Stefan Berger @ 2011-09-30 3:21 UTC (permalink / raw) To: Anthony Liguori; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-30 3:21 ` Stefan Berger @ 2011-09-30 12:59 ` Anthony Liguori 2011-09-30 14:05 ` Stefan Berger 0 siblings, 1 reply; 28+ messages in thread From: Anthony Liguori @ 2011-09-30 12:59 UTC (permalink / raw) To: Stefan Berger; +Cc: qemu-devel 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 > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-30 12:59 ` Anthony Liguori @ 2011-09-30 14:05 ` Stefan Berger 0 siblings, 0 replies; 28+ messages in thread From: Stefan Berger @ 2011-09-30 14:05 UTC (permalink / raw) To: Anthony Liguori; +Cc: qemu-devel, Michael S. Tsirkin 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 >> >> > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-22 0:34 [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) Anthony Liguori 2011-09-24 8:05 ` Blue Swirl 2011-09-30 3:21 ` Stefan Berger @ 2011-10-10 12:14 ` Max Filippov 2 siblings, 0 replies; 28+ messages in thread From: Max Filippov @ 2011-10-10 12:14 UTC (permalink / raw) To: Anthony Liguori; +Cc: qemu-devel > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) @ 2011-09-24 21:56 Anthony Liguori 2011-09-25 16:28 ` Blue Swirl 0 siblings, 1 reply; 28+ messages in thread From: Anthony Liguori @ 2011-09-24 21:56 UTC (permalink / raw) To: Blue Swirl; +Cc: Avi Kivity, qemu-devel [-- 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 --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) 2011-09-24 21:56 Anthony Liguori @ 2011-09-25 16:28 ` Blue Swirl 0 siblings, 0 replies; 28+ messages in thread From: Blue Swirl @ 2011-09-25 16:28 UTC (permalink / raw) To: Anthony Liguori; +Cc: Avi Kivity, qemu-devel 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]. >> > >> > > ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2011-10-10 12:15 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-22 0:34 [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) Anthony Liguori 2011-09-24 8:05 ` Blue Swirl 2011-09-25 14:10 ` Avi Kivity 2011-09-25 16:36 ` Blue Swirl 2011-09-25 16:48 ` Avi Kivity 2011-09-25 17:31 ` Blue Swirl 2011-09-26 10:08 ` Avi Kivity 2011-09-26 10:10 ` Avi Kivity 2011-09-26 17:15 ` Blue Swirl 2011-09-26 17:18 ` Avi Kivity 2011-09-26 17:20 ` Blue Swirl 2011-09-26 17:24 ` Avi Kivity 2011-09-26 18:07 ` Blue Swirl 2011-09-27 8:33 ` Avi Kivity 2011-09-27 8:57 ` Avi Kivity 2011-09-27 16:39 ` Blue Swirl 2011-09-27 16:44 ` Avi Kivity 2011-09-27 19:19 ` Blue Swirl 2011-09-28 21:21 ` Alexander Graf 2011-09-29 19:28 ` Blue Swirl 2011-09-29 21:19 ` Alexander Graf 2011-09-25 19:50 ` Anthony Liguori 2011-09-30 3:21 ` Stefan Berger 2011-09-30 12:59 ` Anthony Liguori 2011-09-30 14:05 ` Stefan Berger 2011-10-10 12:14 ` Max Filippov 2011-09-24 21:56 Anthony Liguori 2011-09-25 16:28 ` Blue Swirl
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.