From: "Sahita, Ravi" <ravi.sahita@intel.com>
To: Big Strong <fangtuo90@gmail.com>, Wei Liu <wei.liu2@citrix.com>
Cc: Tamas K Lengyel <tamas.k.lengyel@gmail.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: xc_altp2m_set_vcpu_enable_notify fail
Date: Wed, 11 May 2016 16:26:08 +0000 [thread overview]
Message-ID: <DBC12B0F5509554280826E40BCDEE8BE633B6528@ORSMSX104.amr.corp.intel.com> (raw)
In-Reply-To: <CAFnE1f2gTRjsxi_v_baocxWKFOM5KvERn=nE9LB8u530i9Y4Kw@mail.gmail.com>
[-- 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
next prev parent reply other threads:[~2016-05-11 16:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 8:36 xc_altp2m_set_vcpu_enable_notify fail Big Strong
2016-05-02 10:47 ` Wei Liu
2016-05-02 11:42 ` Big Strong
2016-05-04 10:43 ` Wei Liu
2016-05-04 10:48 ` Wei Liu
2016-05-04 12:59 ` Big Strong
2016-05-06 11:10 ` Wei Liu
2016-05-07 7:34 ` Big Strong
[not found] ` <CABfawhkfYqX6t2QFDfE=SF+xjBzqGtn7kvA0hfkDv841CarYBQ@mail.gmail.com>
2016-05-07 14:47 ` Tamas K Lengyel
2016-05-09 7:37 ` Big Strong
2016-05-09 8:59 ` Wei Liu
2016-05-09 15:30 ` Big Strong
2016-05-10 10:07 ` Wei Liu
2016-05-10 16:29 ` Big Strong
2016-05-11 3:37 ` Big Strong
2016-05-11 7:56 ` Big Strong
2016-05-11 15:37 ` Big Strong
2016-05-11 16:26 ` Sahita, Ravi [this message]
2016-05-12 13:00 ` Big Strong
2016-05-12 15:17 ` Wei Liu
2016-05-12 15:53 ` Tamas K Lengyel
2016-05-12 15:59 ` Sahita, Ravi
2016-05-16 9:06 ` Big Strong
2016-05-16 15:05 ` Big Strong
2016-05-17 12:05 ` Big Strong
2016-05-18 2:43 ` Big Strong
2016-05-18 4:56 ` Tamas K Lengyel
2016-05-18 9:48 ` Wei Liu
2016-05-18 13:14 ` Tamas K Lengyel
2016-05-18 13:22 ` Wei Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DBC12B0F5509554280826E40BCDEE8BE633B6528@ORSMSX104.amr.corp.intel.com \
--to=ravi.sahita@intel.com \
--cc=fangtuo90@gmail.com \
--cc=tamas.k.lengyel@gmail.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).