From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Wray Subject: Re: VMX device models not getting created anymore? Date: Mon, 20 Jun 2005 12:13:50 +0100 Message-ID: <42B6A4EE.4040203@hp.com> References: <42B03B76.7010701@hp.com> <42B060BA.3020404@intel.com> <42B13EC8.3090008@hp.com> <42B1B86D.6090503@intel.com> <42B2CB0B.1000502@hp.com> <42B3246E.3000706@intel.com> <42B32FE6.2090308@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <42B32FE6.2090308@intel.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: Arun Sharma Cc: Ian Pratt , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Arun Sharma wrote: > Arun Sharma wrote: > >> That seems to be the problem. If I add some logging, I see: >> >> [2005-06-17 12:06:07 xend] INFO (channel:32) created event channel: >> >> [2005-06-17 12:06:07 xend] INFO (channel:32) created event channel: >> > > [..] > >> >> Things get more interesting, because self.device_channel['port1'] for >> the second channel returns 19 instead of 20. >> > > This statement is not true. I got confused because the only the first > event channel shows up in xm list --long. > > The real issue is the hard coding in: > > xen/include/public/io/ioreq.h: > > #define IOPACKET_PORT 2 > > This was true before your changes went in. After your changes, xen > started sending IOPACKET events on: > > > > but the user space device models were listening on: > > > > However, if I subtract -1, everything magically works :) Having to add or subtract 1 to make something work is almost always not the right way to fix a problem - because it dosen't address the real issue. > I think the quick fix is to redefine IOPACKET_PORT to be 3. Will send a > patch to remove the hard coding ASAP. That's not the fix. That just replaces one hard-coded constant with another, when it shouldn't be hard-coded at all. It's going to break again if any other interdomain port is allocated. The port to use should be passed to the domain as a parameter. This is what is done with the domain controller port, and the xenstore port. The correct fix is to add the device model port as a parameter to xc_vmx_build. In fact this already has control_evtchn as a parameter, but ignores it - so you could use that. You could probably re-use the start_info field for it too as vmx domains don't seem to be using the control channel otherwise: Set domain_controller_evtchn in xc_vmx_build from control_evtchn, and use domain->start_info->domain_controller_evtchn intead of IOPACKET_PORT. In xend the vmx code can simply pass the domain control evtchn like the other build functions, since the existing control evtchn isn't being used. Hope this helps, Mike