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

[Mike Wray <mike.wray@xxxxxx>]

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