[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

>-----Original Message-----
>From: Tamas K Lengyel [mailto:tamas.k.lengyel@xxxxxxxxx]
>Sent: Thursday, May 12, 2016 8:54 AM
>To: Wei Liu <wei.liu2@xxxxxxxxxx>
>Cc: Big Strong <fangtuo90@xxxxxxxxx>; Sahita, Ravi <ravi.sahita@xxxxxxxxx>;
>White, Edmund H <edmund.h.white@xxxxxxxxx>; Jan Beulich
><jbeulich@xxxxxxxx>; Xen-devel <xen-devel@xxxxxxxxxxxxx>
>Subject: Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
>On Thu, May 12, 2016 at 9:17 AM, Wei Liu <wei.liu2@xxxxxxxxxx> 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
>>> 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 
>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).

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.