From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: George.Dunlap@eu.citrix.com, tim@xen.org, eddie.dong@intel.com,
keir.xen@gmail.com, jun.nakajima@intel.com,
xen-devel@lists.xenproject.org
Subject: Re: [V12 PATCH 3/4] pvh dom0: Add and remove foreign pages
Date: Wed, 14 May 2014 18:59:17 -0700 [thread overview]
Message-ID: <20140514185917.6c185e9b@mantra.us.oracle.com> (raw)
In-Reply-To: <5373305C0200007800011FEB@mail.emea.novell.com>
On Wed, 14 May 2014 07:59:08 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:
> >>> On 14.05.14 at 02:55, <mukesh.rathor@oracle.com> wrote:
> > On Tue, 13 May 2014 08:09:42 +0100
...
> >> >> And a more general question: How is the insertion of p2m_foreign
> >> >> entries working together with the controlled domain (i.e. the
> >> >> one owning the page) being subject to paging/sharing? I only
> >> >> recall fixme-s having got added for the two features presently
> >> >> not being supported for PVH domains...
> >> >
> >> > Right, the two features are not supported presently, the caller
> >> > will get -EINVAL if attempted. No further progress.
> >>
> >> Will it? Where is that being enforced? I just went down (as an
> >
> > In p2m_add_foreign() we return -EINVAL if the foreign gfn is not
> > one of: ram_rw | ram_logdirty | ram_ro | paging_out.
> >
> > Also, patch 8ff5c1d added checks in set_typed_p2m_entry() and
> > p2m_change_type_one().
>
> But that's way too late, isn't it? You ought to disallow
> paging/sharing (and whatever else you can't support right now) from
> the beginning, i.e. it shouldn't even get enabled on a DomU if the
> controlling domain is PVH.
Ah, I see. The concern here is an HVM gfn say p2m_ram_rw, being mapped
foreign into dom0, then going into sharing/paging. Yes, we should just
disable/disallow from the beginning for now. Long term, we would need to
keep track somehow of guest gfns that are mapped foreign so we could
just disallow operations on those... I frankly see no reason to support
these features for foreign types.
Code wise several options, but seems mem_event.c would be the best
place to put checks (would ENOSYS be more appropriate?):
+++ b/xen/arch/x86/mm/mem_event.c
@@ -538,6 +538,13 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event
case XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE:
{
struct p2m_domain *p2m = p2m_get_hostp2m(d);
+ struct domain *hwdom = rcu_lock_domain_by_id(hardware_domid);
+
+ rcu_unlock_domain(hwdom);
+ rc = -EOPNOTSUPP;
+ /* pvh fixme: support paging */
+ if ( is_pvh_domain(hwdom) )
+ break;
+
rc = -ENODEV;
/* Only HAP is supported */
if ( !hap_enabled(d) )
@@ -620,6 +627,13 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event
{
case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ENABLE:
{
+ struct domain *hwdom = rcu_lock_domain_by_id(hardware_domid);
+
+ rcu_unlock_domain(hwdom);
+ rc = -EOPNOTSUPP;
+ /* pvh fixme: support sharing */
+ if ( is_pvh_domain(hwdom) )
+ break;
+
rc = -ENODEV;
/* Only HAP is supported */
if ( !hap_enabled(d) )
BTW, how come you let these get away without "fixme" tags :).. :
/* Only HAP is supported */
if ( !hap_enabled(d) )
break;
/* Currently only EPT is supported */
if ( !cpu_has_vmx )
thanks
Mukesh
next prev parent reply other threads:[~2014-05-15 1:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-10 0:50 [V12 PATCH 0/4] pvh dom0 patches Mukesh Rathor
2014-05-10 0:50 ` [V12 PATCH 1/4] pvh dom0: construct_dom0 changes Mukesh Rathor
2014-05-10 0:50 ` [V12 PATCH 2/4] pvh dom0: Add checks and restrictions for p2m_is_foreign Mukesh Rathor
2014-05-10 0:50 ` [V12 PATCH 3/4] pvh dom0: Add and remove foreign pages Mukesh Rathor
2014-05-12 10:34 ` Jan Beulich
2014-05-13 1:02 ` Mukesh Rathor
2014-05-13 7:09 ` Jan Beulich
2014-05-14 0:55 ` Mukesh Rathor
2014-05-14 6:59 ` Jan Beulich
2014-05-15 1:59 ` Mukesh Rathor [this message]
2014-05-15 8:02 ` Jan Beulich
2014-05-16 1:39 ` Mukesh Rathor
2014-05-10 0:50 ` [V12 PATCH 4/4] dom0: add opt_dom0pvh to setup.c Mukesh Rathor
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=20140514185917.6c185e9b@mantra.us.oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=eddie.dong@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir.xen@gmail.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.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).