xc_altp2m_set_vcpu_enable_notify fail

xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 653 bytes --]

I've successfully add a new physical page to guest and trying to use it as
the virtualization exception (#VE) infomation page. However, the function:
xc_altp2m_set_vcpu_enable_notify(xci, domid, vcpuid, gfn)
failed for unknown reason (return -1). The only related info I can get is
by `dmesg`:

[605716.546390] vmfunc[16835]: segfault at 0 ip 00000000004009fb sp
> 00007fff3a7b87a0 error 4 in vmfunc[400000+1000]
> [605781.162125] vmfunc[16840]: segfault at 0 ip 00000000004009fb sp
> 00007fffd84c86d0 error 4 in vmfunc[400000+1000]
> [606113.290934] vmfunc[16860]: segfault at 0 ip 00000000004009fb sp
> 00007fffaa076fb0 error 4 in vmfunc[400000+1000]

[-- Attachment #1.2: Type: text/html, Size: 914 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Wei Liu]

On Mon, May 02, 2016 at 04:36:11PM +0800, Big Strong wrote:
> I've successfully add a new physical page to guest and trying to use it as
> the virtualization exception (#VE) infomation page. However, the function:
> xc_altp2m_set_vcpu_enable_notify(xci, domid, vcpuid, gfn)
> failed for unknown reason (return -1). The only related info I can get is

Check the errno please, thats' where the information is stored.

Wei.

> by `dmesg`:
> 
> [605716.546390] vmfunc[16835]: segfault at 0 ip 00000000004009fb sp
> > 00007fff3a7b87a0 error 4 in vmfunc[400000+1000]
> > [605781.162125] vmfunc[16840]: segfault at 0 ip 00000000004009fb sp
> > 00007fffd84c86d0 error 4 in vmfunc[400000+1000]
> > [606113.290934] vmfunc[16860]: segfault at 0 ip 00000000004009fb sp
> > 00007fffaa076fb0 error 4 in vmfunc[400000+1000]

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 1619 bytes --]

>
> Check the errno please, thats' where the information is stored.


I looked up in the source code of xen 4.6, and find that errno 4 indicates
"Interrupted system call
<http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/errno.h;h=8c88bb1d40ff370c2824bb214bddfda4540528ed;hb=b24ad7ba911a9f0688ab179736476e44c52144f1#l36>",
I'm not sure if it is the cause.

Another information about VMFUNC error is from the Intel Manual:

25.5.5.2 General Operation of the VMFUNC Instruction
> The VMFUNC instruction causes an invalid-opcode exception (#UD) if the
> “enable VM functions” VM-execution
> controls is 0 or the value of EAX is greater than 63 (only VM functions
> 0–63 can be enable). Otherwise, the
> instruction causes a VM exit if the bit at position EAX is 0 in the
> VM-function controls (the selected VM function is
> not enabled). If such a VM exit occurs, the basic exit reason used is 59
> (3BH), indicating “VMFUNC”, and the length
> of the VMFUNC instruction is saved into the VM-exit instruction-length
> field. If the instruction causes neither an
> invalid-opcode exception nor a VM exit due to a disabled VM function, it
> performs the functionality of the
> VM function specified by the value in EAX.


 i.e. In conditions when guest software invoked a VM function with the
VMFUNC instruction and the VM function either was not
enabled or generated a function-specific condition causing a VM exit.

But I've already enabled VM function and the conditions described in the
manual are not true (EAX is 0), so I'm still not clear the real reason

[-- Attachment #1.2: Type: text/html, Size: 2154 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Wei Liu]

On Mon, May 02, 2016 at 07:42:34PM +0800, Big Strong wrote:
> >
> > Check the errno please, thats' where the information is stored.
> 
> 
> I looked up in the source code of xen 4.6, and find that errno 4 indicates
> "Interrupted system call
> <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/errno.h;h=8c88bb1d40ff370c2824bb214bddfda4540528ed;hb=b24ad7ba911a9f0688ab179736476e44c52144f1#l36>",
> I'm not sure if it is the cause.
> 

That error number is internal to Xen, so you could be looking at the
wrong source.

The errno business is a bit messy. In general privcmd translates Xen's
errno into OS's errno. So in this case you need to look at your
operating system's errno.

> Another information about VMFUNC error is from the Intel Manual:
> 
> 25.5.5.2 General Operation of the VMFUNC Instruction
> > The VMFUNC instruction causes an invalid-opcode exception (#UD) if the
> > “enable VM functions” VM-execution
> > controls is 0 or the value of EAX is greater than 63 (only VM functions
> > 0–63 can be enable). Otherwise, the
> > instruction causes a VM exit if the bit at position EAX is 0 in the
> > VM-function controls (the selected VM function is
> > not enabled). If such a VM exit occurs, the basic exit reason used is 59
> > (3BH), indicating “VMFUNC”, and the length
> > of the VMFUNC instruction is saved into the VM-exit instruction-length
> > field. If the instruction causes neither an
> > invalid-opcode exception nor a VM exit due to a disabled VM function, it
> > performs the functionality of the
> > VM function specified by the value in EAX.
> 
> 
>  i.e. In conditions when guest software invoked a VM function with the
> VMFUNC instruction and the VM function either was not
> enabled or generated a function-specific condition causing a VM exit.
> 
> But I've already enabled VM function and the conditions described in the
> manual are not true (EAX is 0), so I'm still not clear the real reason

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Wei Liu]

On Wed, May 04, 2016 at 11:43:04AM +0100, Wei Liu wrote:
> On Mon, May 02, 2016 at 07:42:34PM +0800, Big Strong wrote:
> > >
> > > Check the errno please, thats' where the information is stored.
> > 
> > 
> > I looked up in the source code of xen 4.6, and find that errno 4 indicates
> > "Interrupted system call
> > <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/errno.h;h=8c88bb1d40ff370c2824bb214bddfda4540528ed;hb=b24ad7ba911a9f0688ab179736476e44c52144f1#l36>",
> > I'm not sure if it is the cause.
> > 
> 
> That error number is internal to Xen, so you could be looking at the
> wrong source.
> 
> The errno business is a bit messy. In general privcmd translates Xen's
> errno into OS's errno. So in this case you need to look at your
> operating system's errno.

A bit more information on this. There is a on-going discussion on the
errno topic on xen-devel. The safe bet is that if you use errno in the
os it is probably in the os name space. If you get errno from hypercall
struct it should be in xen's name space.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 2073 bytes --]

>
> A bit more information on this. There is a on-going discussion on the
> errno topic on xen-devel. The safe bet is that if you use errno in the
> os it is probably in the os name space. If you get errno from hypercall
> struct it should be in xen's name space.
>
> Wei.
>

I don't know what is the cause of the vmfunc error, but I'm afraid that
this is not caused by xc_altp2m_set_vcpu_enable_notify, as I can't
reproduce the error using the code below:

#include <xenctrl.h>
> #include <stdlib.h>
> int main(int argc, char *argv[]){
>     domid_t domid;
>     int vcpuid;
>     int rc = -1;
>     if (argc != 3)
>     {
>         printf("arguments error, please input domid vcpuid\n");
>         return -1;
>     }
>     else
>     {
>         domid = atoi(argv[1]);
>         vcpuid = atoi(argv[2]);
>     }
>


    xen_pfn_t new_gfn;
>


    //increase memory reservation for guest
>     rc = xc_domain_increase_reservation_exact(xci, domid, 1,
>         0, 0, &new_gfn);
>     if(rc<0)
>     {
>         printf("fail to increase memory reservation\n");
>         return -1;
>     }
>     printf("added memory:%ld\n",new_gfn);
>


    //map the memory to guest memory space
>     rc = xc_domain_populate_physmap_exact(xci, domid, 1, 0, 0, &new_gfn);
>     if(rc<0)
>     {
>         printf("fail to map increased memory\n");
>         return -1;
>     }
>


    //set #VE info area in VMCS

   * rc = xc_altp2m_set_vcpu_enable_notify(xci, domid, vcpuid, new_gfn);*
>     if(rc<0)
>     {
>         printf("fail to set #ve info page:%ld \n",new_gfn);
>         return -1;
>     }
>     printf("succeed setting #ve info for page:%ld\n",new_gfn);
>

>     //enable #VE in VMCS

    rc = xc_altp2m_set_domain_state(xci,domid,1);
>     if(rc<0)
>     {
>         printf("error enabing #VE\n");
>         return -1;
>     }
>     return 0;


 The code always stops at the xc_altp2m_set_vcpu_enable_notify, which is
used to assign the new page as #VE info page. As I can't debug the Xen
source code, I don't why xc_altp2m_set_vcpu_enable_notify always return -1.
Any ideas?

[-- Attachment #1.2: Type: text/html, Size: 4931 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Wei Liu]

On Wed, May 04, 2016 at 08:59:35PM +0800, Big Strong wrote:
[...]
> 
> 
>  The code always stops at the xc_altp2m_set_vcpu_enable_notify, which is
> used to assign the new page as #VE info page. As I can't debug the Xen
> source code, I don't why xc_altp2m_set_vcpu_enable_notify always return -1.
> Any ideas?

libxc functions always return -1 when it fails. You need the specific
errno to know what went wrong.

I think it wouldn't be too hard to figure out which error code the
hypervisor returns and dig into the source code.

I don't have enough knowledge in altp2m. I'm afraid you need to either
dig into hypervisor code and read Intel manuals or wait for people who
are more familiar with the code to chime in.

Do you have any difficulty debugging Xen? We might be able to give some
pointers on how to do that.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 1020 bytes --]

>
> libxc functions always return -1 when it fails. You need the specific
> errno to know what went wrong.


Yeah, I know it means a failure. Actually, I noticed that there is a
comment at the source code of xen
<http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxc/xc_altp2m.c;hb=3e9b0d540837c4641783adcc5449d3762469ff9d#l71>,
which says :

"This is a bit odd to me that it acts on current..  it return -1 directly"

which is exactly about xc_altp2m_set_vcpu_enable_notify.  In my case,
xc_altp2m_set_vcpu_enable_notify always return -1 just as the author
comments.Besides, I've also found no existing usage about this function all
over the Internet. So I'm wondering if this function actually works or not.
Anyway, why would the author comments that? @Ian @Tamas


Do you have any difficulty debugging Xen? We might be able to give some
> pointers on how to do that.


Yeah, I've enabled debug option when compiling xen, what else steps should
I take to use a remote gdb to debug xen instead of dom0 or domU?

[-- Attachment #1.2: Type: text/html, Size: 1694 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Tamas K Lengyel]

[-- Attachment #1.1: Type: text/plain, Size: 1302 bytes --]

On May 7, 2016 03:34, "Big Strong" <fangtuo90@gmail.com> wrote:
>>
>> libxc functions always return -1 when it fails. You need the specific
>> errno to know what went wrong.
>
>
> Yeah, I know it means a failure. Actually, I noticed that there is a
comment at the source code of xen, which says :
>
> "This is a bit odd to me that it acts on current..  it return -1 directly"
>
> which is exactly about xc_altp2m_set_vcpu_enable_notify.  In my case,
xc_altp2m_set_vcpu_enable_notify always return -1 just as the author
comments.Besides, I've also found no existing usage about this function all
over the Internet. So I'm wondering if this function actually works or not.
Anyway, why would the author comments that? @Ian @Tamas

That's a comment I made while reviewing back when I wrote the userspace
components and was left in and should be probably removed.

>
>> Do you have any difficulty debugging Xen? We might be able to give some
>> pointers on how to do that.
>
>
> Yeah, I've enabled debug option when compiling xen, what else steps
should I take to use a remote gdb to debug xen instead of dom0 or domU?

You should put in some extra gdprintk's into the altp2m path of Xen to see
how far it gets when you try to enable VE. That would enable us to pinpoint
where it gets stuck exactly.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 1626 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 384 bytes --]

>
> You should put in some extra gdprintk's into the altp2m path of Xen to see
> how far it gets when you try to enable VE. That would enable us to pinpoint
> where it gets stuck exactly.
>
> Tamas
>
I've added gdprintk into HVMOP_altp2m_vcpu_enable_notify section of
do_altp2m_op function, but no output is generated using "xl dmesg". Is
there any other place where gdprintk prints?

[-- Attachment #1.2: Type: text/html, Size: 735 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Wei Liu]

On Mon, May 09, 2016 at 03:37:25PM +0800, Big Strong wrote:
> >
> > You should put in some extra gdprintk's into the altp2m path of Xen to see
> > how far it gets when you try to enable VE. That would enable us to pinpoint
> > where it gets stuck exactly.
> >
> > Tamas
> >
> I've added gdprintk into HVMOP_altp2m_vcpu_enable_notify section of
> do_altp2m_op function, but no output is generated using "xl dmesg". Is
> there any other place where gdprintk prints?

You need to have appropriate log level set.

Try adding loglvl=all guest_loglvl=all to your xen command line and
reboot.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 1360 bytes --]

>
> You need to have appropriate log level set.
>
> Try adding loglvl=all guest_loglvl=all to your xen command line and
> reboot.
>
> Wei.
>

I've enabled all the log level just as you said, but no outputs happen at
 HVMOP_altp2m_vcpu_enable_notify section of do_altp2m_op function, so does
that means the function are not called at all?

    case HVMOP_altp2m_vcpu_enable_notify:
>     {
>         struct vcpu *curr = current;
>         p2m_type_t p2mt;
>         if ( a.u.enable_notify.pad || a.domain != DOMID_SELF ||
>              a.u.enable_notify.vcpu_id != curr->vcpu_id )
>         {
>             rc = -EINVAL;
>
> * gdprintk(XENLOG_INFO, "enable_notify args error pad:%d domain:%d vcpu:%d
> curr->vcpu:%d\n",**                a.u.enable_notify.pad, a.domain,
> a.u.enable_notify.vcpu_id, curr->vcpu_id);*
>         }
>         if ( (gfn_x(vcpu_altp2m(curr).veinfo_gfn) != INVALID_GFN) ||
>              (mfn_x(get_gfn_query_unlocked(curr->domain,
>                     a.u.enable_notify.gfn, &p2mt)) == INVALID_MFN) )
>         {
>             return -EINVAL;
>            * gdprintk(XENLOG_INFO, "veinfo page is invalid\n");*
>         }
>         vcpu_altp2m(curr).veinfo_gfn = _gfn(a.u.enable_notify.gfn);
>         altp2m_vcpu_update_vmfunc_ve(curr);
>         *gdprintk(XENLOG_INFO, "veinfo page set successfully\n");*
>         break;
>     }

[-- Attachment #1.2: Type: text/html, Size: 3302 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Wei Liu]

On Mon, May 09, 2016 at 11:30:34PM +0800, Big Strong wrote:
> >
> > You need to have appropriate log level set.
> >
> > Try adding loglvl=all guest_loglvl=all to your xen command line and
> > reboot.
> >
> > Wei.
> >
> 
> I've enabled all the log level just as you said, but no outputs happen at
>  HVMOP_altp2m_vcpu_enable_notify section of do_altp2m_op function, so does
> that means the function are not called at all?
> 

I think you need to add more printk to find out.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 882 bytes --]

>
> I think you need to add more printk to find out.
>
> Wei.
>

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?

[-- Attachment #1.2: Type: text/html, Size: 1280 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 1850 bytes --]

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?
>>
>

[-- Attachment #1.2: Type: text/html, Size: 2503 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 2190 bytes --]

>From what I analyzed, can I draw a concolusion that the current
implementation of do_altp2m_op means #ve info page can only be set on dom0
memory and the dom0 must be a hvm? This seems like ridiculous as dom0 is a
special pv guest.

2016-05-11 11:37 GMT+08:00 Big Strong <fangtuo90@gmail.com>:

> 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 of
> 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?
>>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 3153 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 2473 bytes --]

Is that a bug or does #ve info page can only exist on dom0? If this is
true, why would there be a is_hvm_domain check which will stop the
execution of xc_altp2m_vcpu_enable_notify?

2016-05-11 15:56 GMT+08:00 Big Strong <fangtuo90@gmail.com>:

> From what I analyzed, can I draw a concolusion that the current
> implementation of do_altp2m_op means #ve info page can only be set on dom0
> memory and the dom0 must be a hvm? This seems like ridiculous as dom0 is a
> special pv guest.
>
> 2016-05-11 11:37 GMT+08:00 Big Strong <fangtuo90@gmail.com>:
>
>> 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 of
>> 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?
>>>>
>>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 3704 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Sahita, Ravi]

[-- Attachment #1.1: Type: text/plain, Size: 2817 bytes --]

Hi Fangtuo,

#VE can be setup to be delivered to any dom that is a HVM.

Ravi

From: Big Strong [mailto:fangtuo90@gmail.com]
Sent: Wednesday, May 11, 2016 8:38 AM
To: Wei Liu <wei.liu2@citrix.com>
Cc: Tamas K Lengyel <tamas.k.lengyel@gmail.com>; Sahita, Ravi <ravi.sahita@intel.com>; Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

Is that a bug or does #ve info page can only exist on dom0? If this is true, why would there be a is_hvm_domain check which will stop the execution of xc_altp2m_vcpu_enable_notify?

2016-05-11 15:56 GMT+08:00 Big Strong <fangtuo90@gmail.com<mailto:fangtuo90@gmail.com>>:
From what I analyzed, can I draw a concolusion that the current implementation of do_altp2m_op means #ve info page can only be set on dom0 memory and the dom0 must be a hvm? This seems like ridiculous as dom0 is a special pv guest.

2016-05-11 11:37 GMT+08:00 Big Strong <fangtuo90@gmail.com<mailto:fangtuo90@gmail.com>>:
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 of 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?




[-- Attachment #1.2: Type: text/html, Size: 7346 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 3520 bytes --]

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.

2016-05-12 0:26 GMT+08:00 Sahita, Ravi <ravi.sahita@intel.com>:

> Hi Fangtuo,
>
>
>
> #VE can be setup to be delivered to any dom that is a HVM.
>
>
>
> Ravi
>
>
>
> *From:* Big Strong [mailto:fangtuo90@gmail.com]
> *Sent:* Wednesday, May 11, 2016 8:38 AM
> *To:* Wei Liu <wei.liu2@citrix.com>
> *Cc:* Tamas K Lengyel <tamas.k.lengyel@gmail.com>; Sahita, Ravi <
> ravi.sahita@intel.com>; Xen-devel <xen-devel@lists.xen.org>
> *Subject:* Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
>
>
>
> Is that a bug or does #ve info page can only exist on dom0? If this is
> true, why would there be a is_hvm_domain check which will stop the
> execution of xc_altp2m_vcpu_enable_notify?
>
>
>
> 2016-05-11 15:56 GMT+08:00 Big Strong <fangtuo90@gmail.com>:
>
> From what I analyzed, can I draw a concolusion that the current
> implementation of do_altp2m_op means #ve info page can only be set on dom0
> memory and the dom0 must be a hvm? This seems like ridiculous as dom0 is a
> special pv guest.
>
>
>
> 2016-05-11 11:37 GMT+08:00 Big Strong <fangtuo90@gmail.com>:
>
> 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 of
> 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?
>
>

[-- Attachment #1.2: Type: text/html, Size: 7148 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Tamas K Lengyel]

On Thu, May 12, 2016 at 9:17 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> 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.
>

That sounds like a reasonable explanation. When I wrote the libxc
wrapper I pretty much just exposed what was available based on the
hypervisor side. As my off-hand comment in the code states I did find
it odd that this op works on current vCPU. So if it's actually issued
from the domain itself it would make sense. So with that we should
probably remove the libxc wrapper for this hvmop as it won't work/not
designed to be issued from dom0 and should add some comments in the
header explaining its intended use.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Sahita, Ravi]

>-----Original Message-----
>From: Tamas K Lengyel [mailto:tamas.k.lengyel@gmail.com]
>Sent: Thursday, May 12, 2016 8:54 AM
>To: Wei Liu <wei.liu2@citrix.com>
>Cc: Big Strong <fangtuo90@gmail.com>; Sahita, Ravi <ravi.sahita@intel.com>;
>White, Edmund H <edmund.h.white@intel.com>; Jan Beulich
><jbeulich@suse.com>; Xen-devel <xen-devel@lists.xen.org>
>Subject: Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
>
>On Thu, May 12, 2016 at 9:17 AM, Wei Liu <wei.liu2@citrix.com> wrote:
>> 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/h
>>> vm.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.
>>
>
>That sounds like a reasonable explanation. When I wrote the libxc wrapper I
>pretty much just exposed what was available based on the hypervisor side. As my
>off-hand comment in the code states I did find it odd that this op works on
>current vCPU. So if it's actually issued from the domain itself it would make sense.
>So with that we should probably remove the libxc wrapper for this hvmop as it
>won't work/not designed to be issued from dom0 and should add some
>comments in the header explaining its intended use.

Agree with that (and Wei's explanation is accurate).
Ravi

>
>Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 1792 bytes --]

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.liu2@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.
>

[-- Attachment #1.2: Type: text/html, Size: 2682 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 2430 bytes --]

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
<http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=7492030a131a4212d9ca8e700621b2c8836867a9;hb=4f6aea066fe2cf3bf4929d6dac1e558071566f73#l5238>.
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 <fangtuo90@gmail.com>:

> 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.liu2@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.
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3748 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 2970 bytes --]

I just set the domid to DOMID_SELF to pass the check, but another problem
is how to assign the gfn used to store #ve infomation. As I'm doing all the
things in user space, directly assign a new physical page seems impossible.
While LKM can do that with kmalloc and virt_to_phys, it cannot call user
space functions of libxc. Is there a libxc function to translate the
virtual address of malloc() to physical address?

2016-05-16 23:05 GMT+08:00 Big Strong <fangtuo90@gmail.com>:

> 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
> <http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=7492030a131a4212d9ca8e700621b2c8836867a9;hb=4f6aea066fe2cf3bf4929d6dac1e558071566f73#l5238>.
> 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 <fangtuo90@gmail.com>:
>
>> 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.liu2@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.
>>>
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 4555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

[-- Attachment #1.1: Type: text/plain, Size: 733 bytes --]

Should the VMFUNC and #VE must run in kernel mode? I.E. as a linux kernel
module or windows driver? if it is, how to invoke hypercall from the domU
kernel, by ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall) or directly issue
0x82 interrupt?

2016-05-17 20:05 GMT+08:00 Big Strong <fangtuo90@gmail.com>:

> I just set the domid to DOMID_SELF to pass the check, but another problem
> is how to assign the gfn used to store #ve infomation. As I'm doing all the
> things in user space, directly assign a new physical page seems impossible.
> While LKM can do that with kmalloc and virt_to_phys, it cannot call user
> space functions of libxc. Is there a libxc function to translate the
> virtual address of malloc() to physical address?
>

[-- Attachment #1.2: Type: text/html, Size: 1102 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Tamas K Lengyel]

On Tue, May 17, 2016 at 8:43 PM, Big Strong <fangtuo90@gmail.com> wrote:
> Should the VMFUNC and #VE must run in kernel mode? I.E. as a linux kernel
> module or windows driver? if it is, how to invoke hypercall from the domU
> kernel, by ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall) or directly issue
> 0x82 interrupt?

The idea with #VE is that it converts the EPT violation to a specific
in-guest interrupt. Interrupts are handled by the kernel, so you will
need a kernel module that is handling that interrupt. Also, you can
take a look at the xen-privcmd kernel module in the Linux kernel to
get an idea on how to issue hypercalls.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Wei Liu]

On Tue, May 17, 2016 at 08:05:23PM +0800, Big Strong wrote:
> Is there a libxc function to translate the
> virtual address of malloc() to physical address?

Only to answer this question: no. There isn't one.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Tamas K Lengyel]

On Wed, May 18, 2016 at 3:48 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> On Tue, May 17, 2016 at 08:05:23PM +0800, Big Strong wrote:
>> Is there a libxc function to translate the
>> virtual address of malloc() to physical address?
>
> Only to answer this question: no. There isn't one.
>
> Wei.

Technically there is! The function xc_translate_foreign_address can be
used to translate in-guest virtual addresses to physical, works for
both PV and HVM guests. AFAIK a tool on dom0 can run it on itself.
Never tried it that way though.

Cheers,
Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xc_altp2m_set_vcpu_enable_notify fail

[Wei Liu]

On Wed, May 18, 2016 at 07:14:23AM -0600, Tamas K Lengyel wrote:
> On Wed, May 18, 2016 at 3:48 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Tue, May 17, 2016 at 08:05:23PM +0800, Big Strong wrote:
> >> Is there a libxc function to translate the
> >> virtual address of malloc() to physical address?
> >
> > Only to answer this question: no. There isn't one.
> >
> > Wei.
> 
> Technically there is! The function xc_translate_foreign_address can be
> used to translate in-guest virtual addresses to physical, works for
> both PV and HVM guests. AFAIK a tool on dom0 can run it on itself.
> Never tried it that way though.
> 

Right. I missed that one. Thanks for correction.

Wei.

> Cheers,
> Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel