From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Wray Subject: Re: VMX device models not getting created anymore? Date: Wed, 22 Jun 2005 09:34:09 +0100 Message-ID: <42B92281.1010200@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> <42B6A4EE.4040203@hp.com> <42B88018.1010702@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: <42B88018.1010702@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: > Mike Wray wrote: > >>> 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. >> > > You probably missed the smiley :) > >>> 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. >> > > Yes of course, I promised to send a patch as well. The quick fix was for > those who couldn't wait. > >> 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: >> > > The problem is that: > > self.construct_image() > ... > xc_vmx_build() > self.configure() > ... > self.image.createDeviceModel() > > The event channel hasn't been created at the time of xc_vmx_build(). All the other build fns need the channel, so it is created before the domain image: def construct_image(self): """Construct the boot image for the domain. """ self.create_channel() self.image.createImage() self.exportToDB() self.storeConnect() From the linux build image: def buildDomain(self): control_evtchn = self.vm.channel.getRemotePort() ... d = xc.linux_build(dom = self.vm.getDomain(), image = self.kernel, control_evtchn = control_evtchn, store_evtchn = store_evtchn, cmdline = self.cmdline, ramdisk = self.ramdisk, flags = self.flags, vcpus = self.vm.vcpus) ... Mike