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. <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=7492030a131a4212d9ca8e700621b2c8836867a9;hb=4f6aea066fe2cf3bf4929d6dac1e558071566f73#l5167> I thought it might because the guest is not able to achieve the vcpu info of its current state <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=7492030a131a4212d9ca8e700621b2c8836867a9;hb=4f6aea066fe2cf3bf4929d6dac1e558071566f73#l5164>. 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 <wei.l...@citrix.com>: > 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. >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
