On Tue, 2011-09-20 at 12:57 +0100, Jan Beulich wrote:
>
> > The waiting is not working, but If I wait enough time, the ring will
> > contain the answer, but apparently I have a problem with my event
> > channel port. So to test this theory I am using event channel status
> > hypercall, and I get:
> > Status 2 (meaning interdomain connected)
> > VCPU 0
> > The Union reports dom 32752 and port 2.
You can also use lsevtchn in dom0, it lives in the /usr/lib/xen/bin dir.
You can give it a domid and therefore check that you can see both ends
look sane e.g. if I run it on an hvm domain I see:
# lsevtchn 3
1: VCPU 0: Interdomain (Connected) - Remote Domain 0, Port 51
2: VCPU 1: Interdomain (Connected) - Remote Domain 0, Port 52
3: VCPU 0: Interdomain (Connected) - Remote Domain 0, Port 49
4: VCPU 0: Interdomain (Connected) - Remote Domain 0, Port 50
and in dom0 I see:
# lsevtchn 0 | grep Domain.3
49: VCPU 0: Interdomain (Connected) - Remote Domain 3, Port 3
50: VCPU 0: Interdomain (Connected) - Remote Domain 3, Port 4
51: VCPU 3: Interdomain (Connected) - Remote Domain 3, Port 1
52: VCPU 3: Interdomain (Connected) - Remote Domain 3, Port 2
i.e. everything matches up.
> 32752 == DOMID_SELF. And I can't see where the hypercall
> implementation would return DOMID_SELF here.
Daniel, are you 100% sure you are printing/looking at
evtchn_status_t->u.interdomain.dom and not evtchn_status_t->dom?
Oh wait, you discovered that you weren't already.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home