Tamas, My experiment is using the same HVMOP - HVMOP_get_param. Usermode code is using it from https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/hvm/hvm_op.h;hb=2a99aa99fc84a45f505f84802af56b006d14c52e Kernelmode is using it from http://lxr.free-electrons.com/source/include/xen/interface/hvm/hvm_op.h?v=3.16#L27
One difference I see, in usermode we are allocating buffer with DECLARE_HYPERCALL_BUFFER in CPL3 space, in kernelmode it's made in CPL0 space, however privcmd IOCTL handler does copy_from_user call for argument buffer... I'm very confused, why it happens :-( Best Regards, Rockosov Dmitry 2016-08-22 21:54 GMT+03:00 Tamas K Lengyel <tamas.k.leng...@gmail.com>: > On Mon, Aug 22, 2016 at 12:42 PM, Dmitry Rockosov <rocko...@gmail.com> > wrote: > > Tamas, what do you think, why the same hypercall operations (get_param) > are > > executed by Xen differently? Does Xen know anything about caller domU > CPL: > > usermode or kernelmode? > > It's not about the guest's CPL - all hypercalls are issued ultimately > from kernelmode anyway - but depending on which HVMOP the guest issues > it can get treated differently by Xen. You can follow the path from > here: https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f= > xen/arch/x86/hvm/hvm.c;h=0180f26b56b75c08c8c53b58a599de > 6085949bce;hb=HEAD#l5510. > I'm not sure which HVMOPs are allowed by default to be executed by the > guest itself. > > Tamas > > > > > Thank you for answers! > > > > Best Regards, > > Rockosov Dmitry > > > > 2016-08-22 21:28 GMT+03:00 Tamas K Lengyel <tamas.k.leng...@gmail.com>: > >> > >> On Mon, Aug 22, 2016 at 12:12 PM, Dmitry Rockosov <rocko...@gmail.com> > >> wrote: > >> > The problem is in hypervisor checking definitely. I deeper debugged > the > >> > code, I met vmcall instruction execution. This means EFAULT is coming > >> > from > >> > hypervisor. > >> > >> As it should, question is where exactly it gets denied in Xen. > >> > >> > > >> > Best Regards, > >> > Rockosov Dmitry > >> > > >> > 2016-08-22 18:09 GMT+03:00 Dmitry Rockosov <rocko...@gmail.com>: > >> >> > >> >> Hello Tamas, > >> >> > >> >> Thank you for the answer! > >> >> > >> >> I installed the same xen source code (4.7.0) as on dom0 to domU, > built > >> >> dist-tools, installed xen-tools, updated rc.d configuration and > >> >> rebooted. > >> >> IOCTL channel to privcmd driver is working fine, but all requests to > >> >> hypervisor like hvm_get_param, translate_foreign_address, > >> >> altp2m_vcpu_enable_notify return EFAULT errno (Bad access). > >> >> > >> >> Just for experiment I wrote below code in usermode: > >> >> =================================== > >> >> ... > >> >> rc = xc_hvm_param_get(xch, DOMID_SELF, HVM_PARAM_CONSOLE_PFN, > &value); > >> >> if (rc < 0) { > >> >> PERROR("Fail to get CONSOLE PFN HVM PARAM\n"); > >> >> goto exit; > >> >> } > >> >> DPRINTF("CONSOLE PFN == %llx", (unsigned long long)value); > >> >> ... > >> >> =================================== > >> >> > >> >> and below code in kernelmode: > >> >> =================================== > >> >> ... > >> >> printk(KERN_INFO "We are in Xen domain HVM = %d\n", > xen_hvm_domain()); > >> >> err = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &value); > >> >> printk(KERN_INFO "err = %d\n", err); > >> >> printk(KERN_INFO "CONSOLE PFN = %llx\n", value); > >> >> ... > >> >> =================================== > >> >> > >> >> In the usermode I got an error: > >> >> =================================== > >> >> Fail to get CONSOLE PFN HVM PARAM > >> >> : Bad address > >> >> =================================== > >> >> > >> >> In the kernelmode code executed fine: > >> >> =================================== > >> >> [23261.230188] We are in Xen domain HVM = 1 > >> >> [23261.307840] err = 0 > >> >> [23261.352587] CONSOLE PFN = fefff > >> >> =================================== > >> >> > >> >> Looks like usermode wrappers don't support many requests to > hypervisor, > >> >> right? > >> > >> Not sure about HVMOP_get_param but AFAIK for > >> HVMOP_altp2m_vcpu_enable_notify to work you would have to create the > >> domain with altp2mhvm=1 enabled, then also issue the required commands > >> from dom0 to enable it (xc_altp2m_set_domain_state) and also perhaps > >> create a couple altp2m views. > >> > >> Tamas > >> > >> >> > >> >> Best Regards, > >> >> Rockosov Dmitry > >> >> > >> >> 2016-08-21 20:27 GMT+03:00 Tamas K Lengyel < > tamas.k.leng...@gmail.com>: > >> >>> > >> >>> Hi Dmitry, > >> >>> as long as you are testing with a HVM Linux guest you should be able > >> >>> to just compile the Xen tools in the guest and then use libxc from > >> >>> within the guest to issue that hypercall via > >> >>> xc_altp2m_set_vcpu_enable_notify. You will need to load a couple > Xen > >> >>> related kernel-modules for it to work (like xen-privcmd). Let us > know > >> >>> if you got it working! > >> >>> > >> >>> Cheers, > >> >>> Tamas > >> >>> > >> >>> On Fri, Aug 19, 2016 at 1:19 PM, Dmitry Rockosov < > rocko...@gmail.com> > >> >>> wrote: > >> >>> > Hello Xen Team! > >> >>> > > >> >>> > Does anybody have any code examples of > >> >>> > HVMOP_altp2m_vcpu_enable_notify? > >> >>> > > >> >>> > I want to fully test #VE, VMFUNC and EPTP Switching VM Function 0 > in > >> >>> > Xen, > >> >>> > but doesn't have any documentations/examples for it. > >> >>> > I tried xen-access test from tools/tests/xen-access, but looks > like > >> >>> > it > >> >>> > doesn't use VMFUNC and #VE, it simply changes VMCS entries with > >> >>> > vmwrite, w/o > >> >>> > VMFUNC 0 (EPTP Switching). > >> >>> > > >> >>> > Thanks in advance! > >> >>> > > >> >>> > Best Regards, > >> >>> > Rockosov Dmitry > >> >>> > > >> >>> > _______________________________________________ > >> >>> > Xen-devel mailing list > >> >>> > Xen-devel@lists.xen.org > >> >>> > https://lists.xen.org/xen-devel > >> >>> > > >> >> > >> >> > >> > > > > > >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
