Re: VMX device models not getting created anymore?

[Mike Wray <mike.wray@hp.com>]

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