preparing for 4.2.2 and 4.1.5

preparing for 4.2.2 and 4.1.5

[Jan Beulich]

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

Re: preparing for 4.2.2 and 4.1.5

[Alex Bligh]

--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

Re: preparing for 4.2.2 and 4.1.5

[Jan Beulich]

>>> 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

Re: preparing for 4.2.2 and 4.1.5

[Alex Bligh]

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

Re: preparing for 4.2.2 and 4.1.5

[Jan Beulich]

>>> 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

Re: preparing for 4.2.2 and 4.1.5

[Stefano Stabellini]

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).

Re: preparing for 4.2.2 and 4.1.5

[Alex Bligh]

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

Re: preparing for 4.2.2 and 4.1.5

[M A Young]

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

Re: preparing for 4.2.2 and 4.1.5

[Ian Jackson]

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.

Re: preparing for 4.2.2 and 4.1.5

[Egger Christoph]

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?
> 
> Jan

Hi Jan,

I request the backport of
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c40e24a8ef74f9d0ee59dd9b8ca890be08b0b874
to Xen 4.2.

Christoph

Re: preparing for 4.2.2 and 4.1.5

[Jan Beulich]

>>> 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

Re: preparing for 4.2.2 and 4.1.5

[Andrew Cooper]

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?
>
> Jan

Would 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

Re: preparing for 4.2.2 and 4.1.5

[Jan Beulich]

>>> 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

Re: preparing for 4.2.2 and 4.1.5

[Andrew Cooper]

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?
>
> Jan

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.

~Andrew

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: preparing for 4.2.2 and 4.1.5

[Jan Beulich]

>>> 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

Re: preparing for 4.2.2 and 4.1.5

[Andrew Cooper]

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

Re: preparing for 4.2.2 and 4.1.5

[Andrew Cooper]

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?
>
> Jan

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 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

Re: preparing for 4.2.2 and 4.1.5

[Jan Beulich]

>>> 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 former

Tim 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

Re: preparing for 4.2.2 and 4.1.5

[Jan Beulich]

>>> 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

Re: preparing for 4.2.2 and 4.1.5

[Marek Marczykowski]

[-- Attachment #1.1: Type: text/plain, Size: 1029 bytes --]

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: preparing for 4.2.2 and 4.1.5

[Ian Campbell]

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.

>  (it is already in 4.2).

Because it was committed before 4.2 branched, I think.

Ian.

Re: preparing for 4.2.2 and 4.1.5

[Marek Marczykowski]

[-- Attachment #1.1: Type: text/plain, Size: 1295 bytes --]

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: preparing for 4.2.2 and 4.1.5

[Alex Bligh]

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

Re: preparing for 4.2.2 and 4.1.5

[Jan Beulich]

>>> 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=2 

You'll have to work this out with Stefano and Ian.

Jan

Re: preparing for 4.2.2 and 4.1.5 / libxl blktap2 patch

[Pasi Kärkkäinen]

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

Re: preparing for 4.2.2 and 4.1.5 / libxl blktap2 patch

[Pasi Kärkkäinen]

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