Further debugging shows that the domain is changed to domain 0 during the check of whether the cmd of do_altp2m_op is HVMOP_altp2m_vcpu_enable_notify, located at here <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=615fa8908375aaad452e2be69fe183c2a12b82bf;hb=b24ad7ba911a9f0688ab179736476e44c52144f1#l6198>. As domain 0 is a pv guest, it causes the is_hvm_domain <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=615fa8908375aaad452e2be69fe183c2a12b82bf;hb=b24ad7ba911a9f0688ab179736476e44c52144f1#l6204> check failed, and thus the execution never goes to HVMOP_altp2m_vcpu_enable_notify <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=615fa8908375aaad452e2be69fe183c2a12b82bf;hb=b24ad7ba911a9f0688ab179736476e44c52144f1#l6267>, which in the end cause xc_altp2m_set_vcpu_enable_notify fail. Why would the logic of do_altp2m_op change the domain to dom0 when the cmd is do_altp2m_op is HVMOP_altp2m_vcpu_enable_notify?
Thanks for the suggestion, after adding printk to all the routines >> of xc_altp2m_set_vcpu_enable_notify, it turns out that the problem is >> because the check of is_hvm_domain() >> <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=615fa8908375aaad452e2be69fe183c2a12b82bf;hb=b24ad7ba911a9f0688ab179736476e44c52144f1#l6204> >> failed in function do_altp2m_op() >> <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=615fa8908375aaad452e2be69fe183c2a12b82bf;hb=b24ad7ba911a9f0688ab179736476e44c52144f1#l6179>. >> However, I've already configure the VM to build as a HVM by adding option >> "builder=hvm" in the config file, but for unknown reason the .printk of >> domain->type is guest_type_pv. I've tried both windows and linux as the >> guest VM, both failed for the same reason. Any ideas? >> >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
