From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Re: Still struggling with HVM: tx timeouts on emulated nics Date: Thu, 06 Oct 2011 14:16:34 +0200 Message-ID: <4E8D9C22.1050308@canonical.com> 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=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 06.10.2011 12:12, Stefano Stabellini wrote: > 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. Agreed. Well at least I hope that since that backport seemed to fix the issue I saw in 4.1.1 it will give some more confidence for you on the 4.2 version. With the drawback of the passthrough not being tested. -Stefan