From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: Re: Still struggling with HVM: tx timeouts on emulated nics Date: Thu, 6 Oct 2011 11:12:12 +0100 Message-ID: References: <4E7B4768.8060103@canonical.com> <4E85883C.7030808@canonical.com> <4E85E8E8.2020702@canonical.com> <4E860382.7040108@canonical.com> <4E8C816B.7060608@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: <4E8C816B.7060608@canonical.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefan Bader Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Wed, 5 Oct 2011, Stefan Bader wrote: > On 03.10.2011 19:24, Stefano Stabellini wrote: > > I am going to send a different patch upstream for Xen 4.2, because I > > would also like it to cover the very unlikely scenario in which a PV > > guest (like dom0 or a PV guest with PCI passthrough) is loosing level > > interrupts because when Xen tries to set the corresponding event channel > > pending the bit is alreay set. The codebase is different enough that > > making the same change on 4.1 is non-trivial. I am appending the new > > patch to this email, it would be great if you could test it. You just > > need a 4.2 hypervisor, not the entire system. You should be able to > > perform the test updating only xen.gz. > > If you have trouble if xen-unstable.hg tip, try changeset 23843. > > Hi Stefano, > > currently I would have the problem that I don't have too much time to move to > another hypervisor (tests may or may not be useful there with substantial > changes beside this one) with our next release being close. > But I think I got a usable backport of your change to 4.1.1 (you think it looks > ok?) and have given that a quick test which seems to be ok... > Though one drawback is that I don't have a setup which would use passthrough, so > that path is not tested. I think I did see (with a debugging version) that the > lost count was incremented and decremented in dom0, though. > Honestly if you have to commit to a backport for your package right now, I would go for the previous version, because it is simpler and less likely to introduce regressions.