Aiming at a release towards the end of March, I''d like to cut RC1-s at the beginning of next week. Please indicate any bug fixes that so far may have been missed in the backports already done. Quite a few fixes are currently stuck in master''s staging branch - these don''t need to be named explicitly, I''m already planning to pull over the hypervisor ones as soon as they get out of staging (and I''m sure Ian is planning the same - if applicable at all - for the tools side). Ian - one thing I think is still open for 4.1.5 is the xz kernel decompression support that was explicitly requested on the list. Can this be expected to go in for RC1? Jan
--On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> wrote:> Aiming at a release towards the end of March, I''d like to cut RC1-s > at the beginning of next week.I''d ask for the ''don''t use O_DIRECT change''. I realise I owe the list a blktrace. -- Alex Bligh
>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote: > --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> wrote: >> Aiming at a release towards the end of March, I''d like to cut RC1-s >> at the beginning of next week. > > I''d ask for the ''don''t use O_DIRECT change''. I realise I owe the list > a blktrace.To me, the title you mention means nothing. It being on the tools side, it would be Ian anyway to take care of this, but can''t you be a bit more specific and indicate which changeset/commit you''re talking of? As well as reasoning why it would be needed (or at least desirable) to have on either or both trees? Jan
Jan, --On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@suse.com> wrote:>>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote: >> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> >> wrote: >>> Aiming at a release towards the end of March, I''d like to cut RC1-s >>> at the beginning of next week. >> >> I''d ask for the ''don''t use O_DIRECT change''. I realise I owe the list >> a blktrace. > > To me, the title you mention means nothing. It being on the tools > side, it would be Ian anyway to take care of this, but can''t you be > a bit more specific and indicate which changeset/commit you''re > talking of? As well as reasoning why it would be needed (or at > least desirable) to have on either or both trees?See this message and the surrounding thread: http://markmail.org/message/iy32akdzmbjo7uiz In essence any domU PV disk usage backended onto something that uses TCP (e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate this 100%. The root cause is a very-hard-to-fix skb refcount problem in the kernel, but the obvious fix is to disable O_DIRECT in qemu''s xendisk driver. People seemed generally happy with this provided the barriers get through (which I need to demonstrate). -- Alex Bligh
>>> On 28.02.13 at 10:21, Alex Bligh <alex@alex.org.uk> wrote: > Jan, > > --On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@suse.com> wrote: > >>>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote: >>> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> >>> wrote: >>>> Aiming at a release towards the end of March, I''d like to cut RC1-s >>>> at the beginning of next week. >>> >>> I''d ask for the ''don''t use O_DIRECT change''. I realise I owe the list >>> a blktrace. >> >> To me, the title you mention means nothing. It being on the tools >> side, it would be Ian anyway to take care of this, but can''t you be >> a bit more specific and indicate which changeset/commit you''re >> talking of? As well as reasoning why it would be needed (or at >> least desirable) to have on either or both trees? > > See this message and the surrounding thread: > http://markmail.org/message/iy32akdzmbjo7uiz > > In essence any domU PV disk usage backended onto something that uses TCP > (e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate > this 100%. The root cause is a very-hard-to-fix skb refcount problem > in the kernel, but the obvious fix is to disable O_DIRECT in qemu''s > xendisk driver. People seemed generally happy with this provided the > barriers get through (which I need to demonstrate).Oh, that would actually be Stefano, not Ian then. And it doesn''t look like you''re asking for a backport - neither upstream qemu nor either of our trees appears to have the suggested change yet. If the change doesn''t go into any of these, there''s no way for it to go into a stable release. Jan
On Wed, 27 Feb 2013, Jan Beulich wrote:> Please indicate any bug fixes that so far may have been missed > in the backports already done. Quite a few fixes are currently > stuck in master''s staging branch - these don''t need to be named > explicitly, I''m already planning to pull over the hypervisor ones > as soon as they get out of staging (and I''m sure Ian is planning > the same - if applicable at all - for the tools side).The patch "tools: Fix memset(&p,0,sizeof(p)) idiom in several places." http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=d119301b5816b39b5ba722a2f8b301b37e8e34bd may be worth backporting. It should apply cleanly to 4.2. For 4.1 it should apply with the tools/libxl/libxl_qmp.c piece removed. Michael Young
M A Young writes ("Re: [Xen-devel] preparing for 4.2.2 and
4.1.5"):> On Wed, 27 Feb 2013, Jan Beulich wrote:
> > Please indicate any bug fixes that so far may have been missed
> > in the backports already done. Quite a few fixes are currently
> > stuck in master''s staging branch - these don''t need
to be named
> > explicitly, I''m already planning to pull over the hypervisor
ones
> > as soon as they get out of staging (and I''m sure Ian is
planning
> > the same - if applicable at all - for the tools side).
>
> The patch "tools: Fix memset(&p,0,sizeof(p)) idiom in several
places."
>
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=d119301b5816b39b5ba722a2f8b301b37e8e34bd
> may be worth backporting. It should apply cleanly to 4.2. For 4.1 it
> should apply with the tools/libxl/libxl_qmp.c piece removed.
Done, thanks.
Ian.
On Thu, 28 Feb 2013, Jan Beulich wrote:> >>> On 28.02.13 at 10:21, Alex Bligh <alex@alex.org.uk> wrote: > > Jan, > > > > --On 28 February 2013 07:31:32 +0000 Jan Beulich <JBeulich@suse.com> wrote: > > > >>>>> On 27.02.13 at 19:44, Alex Bligh <alex@alex.org.uk> wrote: > >>> --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> > >>> wrote: > >>>> Aiming at a release towards the end of March, I''d like to cut RC1-s > >>>> at the beginning of next week. > >>> > >>> I''d ask for the ''don''t use O_DIRECT change''. I realise I owe the list > >>> a blktrace. > >> > >> To me, the title you mention means nothing. It being on the tools > >> side, it would be Ian anyway to take care of this, but can''t you be > >> a bit more specific and indicate which changeset/commit you''re > >> talking of? As well as reasoning why it would be needed (or at > >> least desirable) to have on either or both trees? > > > > See this message and the surrounding thread: > > http://markmail.org/message/iy32akdzmbjo7uiz > > > > In essence any domU PV disk usage backended onto something that uses TCP > > (e.g. iSCSI, NFS) in dom0 has the potential to crash dom0. We can replicate > > this 100%. The root cause is a very-hard-to-fix skb refcount problem > > in the kernel, but the obvious fix is to disable O_DIRECT in qemu''s > > xendisk driver. People seemed generally happy with this provided the > > barriers get through (which I need to demonstrate). > > Oh, that would actually be Stefano, not Ian then. > > And it doesn''t look like you''re asking for a backport - neither > upstream qemu nor either of our trees appears to have the > suggested change yet. If the change doesn''t go into any of > these, there''s no way for it to go into a stable release.Right, as written in http://markmail.org/message/iy32akdzmbjo7uiz, I agree that we should disable O_DIRECT, once you have proven that the barriers and flushes are handled correctly (henceforth we wouldn''t cause data corruptions).
On 27.02.13 17:12, Jan Beulich wrote:> Aiming at a release towards the end of March, I''d like to cut RC1-s > at the beginning of next week. > > Please indicate any bug fixes that so far may have been missed > in the backports already done. Quite a few fixes are currently > stuck in master''s staging branch - these don''t need to be named > explicitly, I''m already planning to pull over the hypervisor ones > as soon as they get out of staging (and I''m sure Ian is planning > the same - if applicable at all - for the tools side). > > Ian - one thing I think is still open for 4.1.5 is the xz kernel > decompression support that was explicitly requested on the list. > Can this be expected to go in for RC1? > > JanHi Jan, I request the backport of http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c40e24a8ef74f9d0ee59dd9b8ca890be08b0b874 to Xen 4.2. Christoph
>>> On 28.02.13 at 16:31, Egger Christoph <chegger@amazon.de> wrote: > On 27.02.13 17:12, Jan Beulich wrote: >> Aiming at a release towards the end of March, I''d like to cut RC1-s >> at the beginning of next week. >> >> Please indicate any bug fixes that so far may have been missed >> in the backports already done. Quite a few fixes are currently >> stuck in master''s staging branch - these don''t need to be named >> explicitly, I''m already planning to pull over the hypervisor ones >> as soon as they get out of staging (and I''m sure Ian is planning >> the same - if applicable at all - for the tools side). > > I request the backport of > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c40e24a8ef74f9d0ee59 > dd9b8ca890be08b0b874 > to Xen 4.2.That''s among the ones mentioned above (which meanwhile came out of staging, but I didn''t get around to make all of them apply to 4.2 [and 4.1 where necessary] yet). Jan
Stefano, --On 28 February 2013 12:40:52 +0000 Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:> Right, as written in http://markmail.org/message/iy32akdzmbjo7uiz, I > agree that we should disable O_DIRECT, once you have proven that the > barriers and flushes are handled correctly (henceforth we wouldn''t > cause data corruptions).Indeed. That''s what I meant by I owe you a blktrace. -- Alex Bligh
On 27/02/13 16:12, Jan Beulich wrote:> Aiming at a release towards the end of March, I''d like to cut RC1-s > at the beginning of next week. > > Please indicate any bug fixes that so far may have been missed > in the backports already done. Quite a few fixes are currently > stuck in master''s staging branch - these don''t need to be named > explicitly, I''m already planning to pull over the hypervisor ones > as soon as they get out of staging (and I''m sure Ian is planning > the same - if applicable at all - for the tools side). > > Ian - one thing I think is still open for 4.1.5 is the xz kernel > decompression support that was explicitly requested on the list. > Can this be expected to go in for RC1? > > JanWould changesets 26060, 26062 and 26074 which all deal with ACPI/APEI bugfixes be suitable for backport? ~Andrew> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
>>> On 01.03.13 at 16:23, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 27/02/13 16:12, Jan Beulich wrote: >> Aiming at a release towards the end of March, I''d like to cut RC1-s >> at the beginning of next week. >> >> Please indicate any bug fixes that so far may have been missed >> in the backports already done. Quite a few fixes are currently >> stuck in master''s staging branch - these don''t need to be named >> explicitly, I''m already planning to pull over the hypervisor ones >> as soon as they get out of staging (and I''m sure Ian is planning >> the same - if applicable at all - for the tools side). >> >> Ian - one thing I think is still open for 4.1.5 is the xz kernel >> decompression support that was explicitly requested on the list. >> Can this be expected to go in for RC1? > > Would changesets 26060, 26062 and 26074 which all deal with ACPI/APEI > bugfixes be suitable for backport?No, I wasn''t intending to pull those over until the AMD side issue here is understood. Which I hope we can achieve by the time 4.3 gets released, at which time pulling the complete set of fixes over will be The Right Thing To Do (tm). Jan
On 27/02/13 16:12, Jan Beulich wrote:> Aiming at a release towards the end of March, I''d like to cut RC1-s > at the beginning of next week. > > Please indicate any bug fixes that so far may have been missed > in the backports already done. Quite a few fixes are currently > stuck in master''s staging branch - these don''t need to be named > explicitly, I''m already planning to pull over the hypervisor ones > as soon as they get out of staging (and I''m sure Ian is planning > the same - if applicable at all - for the tools side). > > Ian - one thing I think is still open for 4.1.5 is the xz kernel > decompression support that was explicitly requested on the list. > Can this be expected to go in for RC1? > > JanCan I nominate c/s 26533:f9016812f0e4 "x86/setup: don''t relocate the VGA hole." (git 0b76ce20de85ad7c23c47ee3275020859b91d46b) for backport, because of its impact for Xen on Xen uses. ~Andrew> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
>>> On 06.03.13 at 19:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > Can I nominate c/s 26533:f9016812f0e4 "x86/setup: don''t relocate the VGA > hole." (git 0b76ce20de85ad7c23c47ee3275020859b91d46b) for backport, > because of its impact for Xen on Xen uses.Done for 4.2; do you see this as also being necessary for 4.1? Jan
On 08/03/13 09:57, Jan Beulich wrote:>>>> On 06.03.13 at 19:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> Can I nominate c/s 26533:f9016812f0e4 "x86/setup: don''t relocate the VGA >> hole." (git 0b76ce20de85ad7c23c47ee3275020859b91d46b) for backport, >> because of its impact for Xen on Xen uses. > Done for 4.2; do you see this as also being necessary for 4.1? > > Jan >I would suggest so. It applies cleanly to 4.1 as well, as I have already backported it for XenServer. ~Andrew
On 27/02/13 16:12, Jan Beulich wrote:> Aiming at a release towards the end of March, I''d like to cut RC1-s > at the beginning of next week. > > Please indicate any bug fixes that so far may have been missed > in the backports already done. Quite a few fixes are currently > stuck in master''s staging branch - these don''t need to be named > explicitly, I''m already planning to pull over the hypervisor ones > as soon as they get out of staging (and I''m sure Ian is planning > the same - if applicable at all - for the tools side). > > Ian - one thing I think is still open for 4.1.5 is the xz kernel > decompression support that was explicitly requested on the list. > Can this be expected to go in for RC1? > > JanFollowing the inclusion of 3c4cd2c6a0e1795c837dd0cfb15db08a5d6694eb "x86/mm: Take the p2m lock even in shadow mode." into 4.2, can I request 7f05d3ff7692574f40d0b337d767a216f347dcdb "x86/mm: avoid locked lookups in shadow emulation" which fixes the performance regression introduced by the former I have had these running in our testing for several weeks now without incident. ~Andrew> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
>>> On 08.03.13 at 13:01, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > Following the inclusion of 3c4cd2c6a0e1795c837dd0cfb15db08a5d6694eb > "x86/mm: Take the p2m lock even in shadow mode." into 4.2, can I request > 7f05d3ff7692574f40d0b337d767a216f347dcdb "x86/mm: avoid locked lookups > in shadow emulation" which fixes the performance regression introduced > by the formerTim indicated otherwise (see http://lists.xen.org/archives/html/xen-devel/2013-02/msg01753.html), and therefore I won''t throw it in without him overriding his earlier statement. Jan
>>> On 27.02.13 at 17:12, "Jan Beulich" <JBeulich@suse.com> wrote: > Ian - one thing I think is still open for 4.1.5 is the xz kernel > decompression support that was explicitly requested on the list. > Can this be expected to go in for RC1?Ping? Jan
On 27.02.2013 17:12, Jan Beulich wrote:> Aiming at a release towards the end of March, I''d like to cut RC1-s > at the beginning of next week. > > Please indicate any bug fixes that so far may have been missed > in the backports already done. Quite a few fixes are currently > stuck in master''s staging branch - these don''t need to be named > explicitly, I''m already planning to pull over the hypervisor ones > as soon as they get out of staging (and I''m sure Ian is planning > the same - if applicable at all - for the tools side). > > Ian - one thing I think is still open for 4.1.5 is the xz kernel > decompression support that was explicitly requested on the list. > Can this be expected to go in for RC1?I''d like "libxc: do not "panic" if a kernel is not a bzImage." [1] to be backported to xen-4.1 (it is already in 4.2). [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1dedb82654ef936f189813e5002af825d81e9b1c -- Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Jan, --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> wrote:> Aiming at a release towards the end of March, I''d like to cut RC1-s > at the beginning of next week. > > Please indicate any bug fixes that so far may have been missed > in the backports already done.What is the current proposed timing of 4.2.2-rc1? I''m still hoping the O_DIRECT patch (third version) will get into 4.2.2: http://marc.info/?l=xen-devel&m=136274297519842&w=2 -- Alex Bligh
>>> On 11.03.13 at 12:36, Alex Bligh <alex@alex.org.uk> wrote: > --On 27 February 2013 16:12:57 +0000 Jan Beulich <JBeulich@suse.com> wrote: >> Aiming at a release towards the end of March, I''d like to cut RC1-s >> at the beginning of next week. >> >> Please indicate any bug fixes that so far may have been missed >> in the backports already done. > > What is the current proposed timing of 4.2.2-rc1?If all goes well, later this week. I saw no point in pushing it out earlier given the not insignificant number of bug fixes wanting to be backported yet stuck in unstable''s staging tree.> I''m still hoping the O_DIRECT patch (third version) will get into 4.2.2: > http://marc.info/?l=xen-devel&m=136274297519842&w=2You''ll have to work this out with Stefano and Ian. Jan
On Sun, 2013-03-10 at 22:53 +0000, Marek Marczykowski wrote:> On 27.02.2013 17:12, Jan Beulich wrote: > > Aiming at a release towards the end of March, I''d like to cut RC1-s > > at the beginning of next week. > > > > Please indicate any bug fixes that so far may have been missed > > in the backports already done. Quite a few fixes are currently > > stuck in master''s staging branch - these don''t need to be named > > explicitly, I''m already planning to pull over the hypervisor ones > > as soon as they get out of staging (and I''m sure Ian is planning > > the same - if applicable at all - for the tools side). > > > > Ian - one thing I think is still open for 4.1.5 is the xz kernel > > decompression support that was explicitly requested on the list. > > Can this be expected to go in for RC1? > > I''d like "libxc: do not "panic" if a kernel is not a bzImage." [1] to be > backported to xen-4.1I think this is a purely cosmetic fix? Not that I mind but that should be taken into consideration.> (it is already in 4.2).Because it was committed before 4.2 branched, I think. Ian.
On 12.03.2013 12:55, Ian Campbell wrote:> On Sun, 2013-03-10 at 22:53 +0000, Marek Marczykowski wrote: >> On 27.02.2013 17:12, Jan Beulich wrote: >>> Aiming at a release towards the end of March, I''d like to cut RC1-s >>> at the beginning of next week. >>> >>> Please indicate any bug fixes that so far may have been missed >>> in the backports already done. Quite a few fixes are currently >>> stuck in master''s staging branch - these don''t need to be named >>> explicitly, I''m already planning to pull over the hypervisor ones >>> as soon as they get out of staging (and I''m sure Ian is planning >>> the same - if applicable at all - for the tools side). >>> >>> Ian - one thing I think is still open for 4.1.5 is the xz kernel >>> decompression support that was explicitly requested on the list. >>> Can this be expected to go in for RC1? >> >> I''d like "libxc: do not "panic" if a kernel is not a bzImage." [1] to be >> backported to xen-4.1 > > I think this is a purely cosmetic fix? Not that I mind but that should > be taken into consideration.Yes, but annoying one. Especially it causes confusing error message when starting HVM with stubdom (only message, doesn''t break start). -- Best Regards / Pozdrawiam, Marek Marczykowski Invisible Things Lab _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Pasi Kärkkäinen
2013-Mar-19 07:50 UTC
Re: preparing for 4.2.2 and 4.1.5 / libxl blktap2 patch
On Wed, Feb 27, 2013 at 04:12:57PM +0000, Jan Beulich wrote:> Aiming at a release towards the end of March, I''d like to cut RC1-s > at the beginning of next week. > > Please indicate any bug fixes that so far may have been missed > in the backports already done. Quite a few fixes are currently > stuck in master''s staging branch - these don''t need to be named > explicitly, I''m already planning to pull over the hypervisor ones > as soon as they get out of staging (and I''m sure Ian is planning > the same - if applicable at all - for the tools side). >I''d like to get the libxl blktap2 patch applied for 4.2.2, it''s already in master / xen-unstable: "[PATCH] libxl: don''t launch more than one tapdisk process for each disk" http://xenbits.xen.org/hg/xen-unstable.hg/rev/948f232e0228 http://lists.xen.org/archives/html/xen-devel/2013-03/msg01104.html Thanks, -- Pasi
Pasi Kärkkäinen
2013-Mar-27 09:52 UTC
Re: preparing for 4.2.2 and 4.1.5 / libxl blktap2 patch
On Tue, Mar 19, 2013 at 09:50:31AM +0200, Pasi Kärkkäinen wrote:> On Wed, Feb 27, 2013 at 04:12:57PM +0000, Jan Beulich wrote: > > Aiming at a release towards the end of March, I''d like to cut RC1-s > > at the beginning of next week. > > > > Please indicate any bug fixes that so far may have been missed > > in the backports already done. Quite a few fixes are currently > > stuck in master''s staging branch - these don''t need to be named > > explicitly, I''m already planning to pull over the hypervisor ones > > as soon as they get out of staging (and I''m sure Ian is planning > > the same - if applicable at all - for the tools side). > > > > I''d like to get the libxl blktap2 patch applied for 4.2.2, > it''s already in master / xen-unstable: >So these patches still need to be applied to Xen 4.2 branch: "[PATCH] libxl: don''t launch more than one tapdisk process for each disk" http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=ec398660e89ca18bb8d061d5047d682bd383778a Xen 4.2 backport of the above patch is here: http://lists.xen.org/archives/html/xen-devel/2013-03/msg00778.html And now there''s other tapdisk patch in xen-unstable aswell: "tools: Retry blktap2 tapdisk message on interrupt": http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=6cffb2b469a55032a2900ccb8776c0082f346758 Both are needed in Xen 4.2 branch, please backport/apply before next Xen 4.2.2-rc ! I''m asking because we''ve seen these problems with the CentOS 6 Xen 4.2 rpms, and it''d be good to get them fixed in upstream Xen 4.2 aswell. Thanks, -- Pasi