Hello,
We are wondering whether someone can confirm that there is a bug in the
netback driver in dom0 Linux - that shows up in Xen 3.2.
We cannot create a domU that uses networking - as soon as we try dom0
reboots after a crash in net_rx_action.
In netbk_gop_frag we find the following code:
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
new_mfn = alloc_mfn();
/*
* Set the new P2M table entry before
* reassigning the old data page. Heed the
* comment in pgtable-2level.h:pte_page(). :-)
*/
set_phys_to_machine(page_to_pfn(page), new_mfn);
mcl = npo->mcl + npo->mcl_prod++;
Notice !xen_feature(XENFEAT_auto_translated_physmap) and
npo->mcl_prod++
Now in net_rx_action we find the following code
if (npo.mcl_prod) {
BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap));
As far as I can tell mcl_prod is only increased in netbk_gop_frag and
only if the auto_translated_physmap feature is not available. However,
in net_rx_action we will crash if the auto_translated_physmap feature is
not available - hence - if auto_translated_physmap is not available
netback always crashes.
We are not using HVM.
In Xen 3.1 the code in net_rx_action looked like this:
if (npo.mcl_prod &&
!xen_feature(XENFEAT_auto_translated_physmap))
It seems like someone wanted to avoid the check in the if-statement and
turned it into a BUG_ON statement inside the if instead - but forgot to
invert the condition.
Can anyone confirm?
Best Regards,
Joakim Dahlstedt
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity named
in this message. If you are not the intended recipient, and have received this
message in error, please immediately return this by email and then delete it.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 5/2/08 09:52, "Joakim Dahlstedt" <jda@bea.com> wrote:> In Xen 3.1 the code in net_rx_action looked like this: > if (npo.mcl_prod && > !xen_feature(XENFEAT_auto_translated_physmap)) > > It seems like someone wanted to avoid the check in the if-statement and > turned it into a BUG_ON statement inside the if instead - but forgot to > invert the condition. > > Can anyone confirm?Yes, that''s a bug. It would only trigger with old domUs which have a netfront driver that does not have the new ''copying receiver'' support. It was introduced by c/s 393 a couple of weeks ago. Thanks for tracking it down! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 05.02.08 11:03 >>> >On 5/2/08 09:52, "Joakim Dahlstedt" <jda@bea.com> wrote: > >> In Xen 3.1 the code in net_rx_action looked like this: >> if (npo.mcl_prod && >> !xen_feature(XENFEAT_auto_translated_physmap)) >> >> It seems like someone wanted to avoid the check in the if-statement and >> turned it into a BUG_ON statement inside the if instead - but forgot to >> invert the condition. >> >> Can anyone confirm? > >Yes, that''s a bug. It would only trigger with old domUs which have a >netfront driver that does not have the new ''copying receiver'' support. It >was introduced by c/s 393 a couple of weeks ago.Oh, yes, my bad.>Thanks for tracking it down!Keir, I assume you already created a fix to invert the condition... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Yes, that''s a bug. It would only trigger with old domUs which have a >netfront driver that does not have the new ''copying receiver'' support.It>was introduced by c/s 393 a couple of weeks ago.That reminds me of another question - Maybe I have missed the discussion on this e-mail list, but in the netback code I have found the following comment: /* * We don''t support rx-flip path (except old guests who don''t * grok this feature flag). */ I am a little bit confused by that comment - I think it means we would prefer not to use rx-flip but we have to anyhow for guests that don''t understand the rx-flip-feature. Is that correct? Or does it mean something else? Is there some sort of plan to long-term completely remove rx-flip from netback then? /Joakim Dahlstedt Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/2/08 10:18, "Jan Beulich" <jbeulich@novell.com> wrote:>> Yes, that''s a bug. It would only trigger with old domUs which have a >> netfront driver that does not have the new ''copying receiver'' support. It >> was introduced by c/s 393 a couple of weeks ago. > > Oh, yes, my bad. > >> Thanks for tracking it down! > > Keir, I assume you already created a fix to invert the condition...Yes indeed. Thanks, Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/2/08 10:20, "Joakim Dahlstedt" <jda@bea.com> wrote:> /* > * We don''t support rx-flip path (except old guests who don''t > * grok this feature flag). > */ > > I am a little bit confused by that comment - I think it means we would > prefer not to use rx-flip but we have to anyhow for guests that don''t > understand the rx-flip-feature. Is that correct? Or does it mean > something else?You are exactly correct.> Is there some sort of plan to long-term completely remove rx-flip from > netback then?No, but there are moves to create a new netchannel2 protocol which will be more extensible, better documented and better able to support new hardware features like multiple receive queues. Of course it will allow us also to drop support for rx flip. The likelihood, however, is that we will continue to support it as a new plug-in datapath in the existing netfront/netback drivers, and negotiation will be required to use it. So we will basically continue to support rx-flip as a fallback option for the foreseeable future. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel