WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] VMX device models not getting created anymore?

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: <EventChannel dom1:0:19 dom2:5:2> [2005-06-17 12:06:07 xend] INFO (channel:32) created event channel: <EventChannel dom1:0:20 dom2:5:3>

[..]


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:

<EventChannel dom1:0:19 dom2:5:2>

but the user space device models were listening on:

<EventChannel dom1:0:20 dom2:5:3>

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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel