To solve that, I install xen and tools in the guest, so as to access its domain id and vcpu info to overcome the 'domain is null' error. Now the problem is solved, but errors comes at 'domain != DOMID_SELF' checking . The DOMID_SELF is always 32752 (0x7FF0), while a.domain is the domid of the guest, which induce the checking failed and exit. Any helps? 2016-05-16 17:06 GMT+08:00 Big Strong : > Your opinion is inspiring. During the past days, I've tried to directly > call HVMOP_altp2m_vcpu_enable_notify in guest by ioctl, this time it fails > for "domain is null" checking. > I > thought it might because the guest is not able to achieve the vcpu info > of its current state > . > While in dom0, this is not a problem. But dom0 is unable to > call HVMOP_altp2m_vcpu_enable_notify for the guest. How can I solve this > contradiction? > > 2016-05-12 23:17 GMT+08:00 Wei Liu : > >> On Thu, May 12, 2016 at 09:00:12PM +0800, Big Strong wrote: >> > I'm still not very clear why would do_altp2m_op change the domain to >> > current domain (which is dom0 in my case) when the cmd is >> > HVMOP_altp2m_vcpu_enable_notify >> > < >> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;hb=743289d0296268fe6bad64531a24d8053afeb062#l6198 >> >. >> > As to my case, it would prevent the dom0 to set the #ve info page for >> other >> > domUs because the check of is_hvm_domain would fail >> > < >> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;hb=743289d0296268fe6bad64531a24d8053afeb062#l6204 >> >and >> > the function will returns directly. >> > >> >> Maybe the intent of that HVMOP is to get called directly by the guest >> that is interested in such event? >> >> I looks like a natural restriction to me because the vcpu needs to set >> up handler for #ve AIUI. It's not likely that Dom0 can do this for >> arbitrary guest. >> >> Wei. >> > >