I compiled Xen for SMP and for some strange reason I could not always get the network interface connected to the backend - same for the TPM frontend and probably also block frontend. The attached patch fixes this problem for all three drivers by explicitly setting the requested port for the channel to 0. Since the structure is on the stack (and not declared static) all its members should be explicitly initialized. I don''t know why I did not encounter this problem on non-SMP systems before... [[ Maybe a function requiring all necessary parameters passed to it explicitly as parameters would be a less errro-prone solution?]] Signed-off-by: Stefan Berger <stefanb@us.ibm.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6 Oct 2005, at 04:05, Stefan Berger wrote:> > I compiled Xen for SMP and for some strange reason I could not always > get the network interface connected to the backend - same for the TPM > frontend and probably also block frontend. The attached patch fixes > this problem for all three drivers by explicitly setting the requested > port for the channel to 0. Since the structure is on the stack (and > not declared static) all its members should be explicitly initialized. > I don''t know why I did not encounter this problem on non-SMP systems > before...I broke it yesterday. Previously ''cmd'' was statically initialised, and that caused all other fields to get filled with zero automatically. Oops. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 10/06/2005 04:21:02 AM:> > On 6 Oct 2005, at 04:05, Stefan Berger wrote: > > > > > I compiled Xen for SMP and for some strange reason I could not always > > get the network interface connected to the backend - same for the TPM > > frontend and probably also block frontend. The attached patch fixes > > this problem for all three drivers by explicitly setting the requested> > port for the channel to 0. Since the structure is on the stack (and > > not declared static) all its members should be explicitly initialized.> > I don''t know why I did not encounter this problem on non-SMP systems > > before... > > I broke it yesterday. Previously ''cmd'' was statically initialised, and > that caused all other fields to get filled with zero automatically. > Oops. :-)What about introducing functions like inline int HV_EVTCHNOP_alloc_unbound(domid_t ldom, domid_t rdom, U32 *port ) { int err; evtchn_op_t op = { .cmd = EVTCHNOP_alloc_unbound; .u.alloc_unbound.dom = ldom; .u.alloc_unbound.remote_dom = rdom; .u.alloc_unbound.port = *port; } err = HYPERVISOR_event_channel_op(&op); *port = op.u.alloc_unbound.port; return err; } to hide the specifics of the structure that needs to be filled out and provide a form of parameter safety by forcing the caller to pass all necessary paramers. Stefan> > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel