From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Xen 4.2 TODO / Release Plan Date: Thu, 31 May 2012 10:37:47 +0100 Message-ID: <4FC7580B02000078000871BB@nat28.tlf.novell.com> References: <1336991215.31817.59.camel@zakaz.uk.xensource.com> <4FB1052D02000078000836D8@nat28.tlf.novell.com> <1338283962.14158.86.camel@zakaz.uk.xensource.com> <4FC4BCB002000078000868E0@nat28.tlf.novell.com> <20120531092427.GA5937@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120531092427.GA5937@aepfle.de> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering Cc: xen-devel , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org >>> On 31.05.12 at 11:24, Olaf Hering wrote: > On Tue, May 29, Jan Beulich wrote: > >> >>> On 29.05.12 at 11:32, Ian Campbell wrote: >> > On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote: >> >> >> >> >>> On 14.05.12 at 12:26, Ian Campbell >> >> wrote: >> >> > tools, blockers: >> >> >> >> Adjustments needed for qdisk backend to work on non-pvops Linux. >> > >> > Can you remind me what those are please. >> >> "qemu/xendisk: set maximum number of grants to be used" >> (http://lists.xen.org/archives/html/xen-devel/2012-05/msg00715.html). >> >> Unfortunately I didn't hear back from Olaf regarding the updated >> value that the supposed v2 of the patch (see the thread), which >> is at least partly due to him having further problems with the qdisk >> backend. Olaf - did you ever see gntdev allocation failures again >> after switching to the higher value? > > I just did a successful installation of sles11sp2 guest on a > xen-unstable host with changeset 25427:ad348c6575b8, and with the change > below, and the second attempt I just started seems get through as well. > > I'm sure I used this variant already two weeks ago, and the install > still failed. Perhaps other changes made during the last two weeks make > a difference. That would be odd. > I will also doublecheck how it goes without this change. > > Olaf > > --- a/hw/xen_disk.c > +++ b/hw/xen_disk.c > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * > if (xen_mode != XEN_EMULATE) { > batch_maps = 1; > } > + if (xc_gnttab_set_max_grants(xendev->gnttabdev, > + 2 * max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) The + 1 at the end is certainly not needed anymore after the doubling. > + xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n", > + strerror(errno)); > } > > static int blk_init(struct XenDevice *xendev) So I think I'll re-submit with the doubled values then. That's in any case better than not setting an upper limit at all on those older kernels. Jan