Generally speaking, the event channel local/remote port is fixed for the
lifetime of the associated domain object. The exception to this is a
secondary XS_INTRODUCE (defined to re-bind to a new event channel) which pokes
around at the domain object's internal state.
We need to refactor the evtchn handling to support live update, so start by
moving the relevant manipulation into Domain.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Edwin Török <edvin.torok@citrix.com>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
(cherry picked from commit
aecdc28d9538ca2a1028ef9bc6550cb171dbbed4)
let dump d chan =
fprintf chan "dom,%d,%nd,%d\n" d.id d.mfn d.remote_port
+let rebind_evtchn d remote_port =
+ begin match d.port with
+ | None -> ()
+ | Some p -> Event.unbind d.eventchn p
+ end;
+ let local = Event.bind_interdomain d.eventchn d.id remote_port in
+ debug "domain %d rebind (l %s, r %d) => (l %d, r %d)"
+ d.id (string_of_port d.port) d.remote_port
+ (Xeneventchn.to_int local) remote_port;
+ d.remote_port <- remote_port;
+ d.port <- Some (local)
+
let notify dom =
match dom.port with
| None -> warn "domain %d: attempt to notify on unknown port" dom.id
let edom = Domains.find domains domid in
if (Domain.get_mfn edom) = mfn && (Connections.find_domain cons domid) != con then begin
(* Use XS_INTRODUCE for recreating the xenbus event-channel. *)
- edom.remote_port <- remote_port;
- Domain.bind_interdomain edom;
+ Domain.rebind_evtchn edom remote_port;
end;
edom
else try