xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Paul Durrant <paul.durrant@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v14 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted
Date: Thu, 7 Dec 2017 05:49:49 +0800	[thread overview]
Message-ID: <20171206214948.GA47014@op-computing> (raw)
In-Reply-To: <20171128150853.1927-5-paul.durrant@citrix.com>

On Tue, Nov 28, 2017 at 03:08:46PM +0000, Paul Durrant wrote:
>A subsequent patch will introduce a new scheme to allow an emulator to
>map ioreq server pages directly from Xen rather than the guest P2M.
>
>This patch lays the groundwork for that change by deferring mapping of
>gfns until their values are requested by an emulator. To that end, the
>pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
>to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
>behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
>requesting the gfn values.
>
>Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>Acked-by: Wei Liu <wei.liu2@citrix.com>
>Reviewed-by: Jan Beulich <jbeulich@suse.com>
>---
>Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>Cc: George Dunlap <George.Dunlap@eu.citrix.com>
>Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>Cc: Stefano Stabellini <sstabellini@kernel.org>
>Cc: Tim Deegan <tim@xen.org>
>
>v8:
> - For safety make all of the pointers passed to
>   hvm_get_ioreq_server_info() optional.
> - Shrink bufioreq_handling down to a uint8_t.
>
>v3:
> - Updated in response to review comments from Wei and Roger.
> - Added a HANDLE_BUFIOREQ macro to make the code neater.
> - This patch no longer introduces a security vulnerability since there
>   is now an explicit limit on the number of ioreq servers that may be
>   created for any one domain.
>---
> tools/libs/devicemodel/core.c                   |  8 +++++
> tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
> xen/arch/x86/hvm/dm.c                           |  9 +++--
> xen/arch/x86/hvm/ioreq.c                        | 47 ++++++++++++++-----------
> xen/include/asm-x86/hvm/domain.h                |  2 +-
> xen/include/public/hvm/dm_op.h                  | 32 ++++++++++-------
> 6 files changed, 63 insertions(+), 41 deletions(-)
>
>diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
>index b66d4f9294..e684e657b6 100644
>--- a/tools/libs/devicemodel/core.c
>+++ b/tools/libs/devicemodel/core.c
>@@ -204,6 +204,14 @@ int xendevicemodel_get_ioreq_server_info(
> 
>     data->id = id;
> 
>+    /*
>+     * If the caller is not requesting gfn values then instruct the
>+     * hypercall not to retrieve them as this may cause them to be
>+     * mapped.
>+     */
>+    if (!ioreq_gfn && !bufioreq_gfn)
>+        data->flags |= XEN_DMOP_no_gfns;
>+
>     rc = xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
>     if (rc)
>         return rc;
>diff --git a/tools/libs/devicemodel/include/xendevicemodel.h b/tools/libs/devicemodel/include/xendevicemodel.h
>index dda0bc7695..fffee3a4a0 100644
>--- a/tools/libs/devicemodel/include/xendevicemodel.h
>+++ b/tools/libs/devicemodel/include/xendevicemodel.h
>@@ -61,11 +61,11 @@ int xendevicemodel_create_ioreq_server(
>  * @parm domid the domain id to be serviced
>  * @parm id the IOREQ Server id.
>  * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
>- *                  gfn
>+ *                  gfn. (May be NULL if not required)
>  * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
>- *                    gfn
>+ *                    gfn. (May be NULL if not required)
>  * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
>- *                     ioreq event channel
>+ *                     ioreq event channel. (May be NULL if not required)
>  * @return 0 on success, -1 on failure.
>  */
> int xendevicemodel_get_ioreq_server_info(
>diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
>index a787f43737..3c617bd754 100644
>--- a/xen/arch/x86/hvm/dm.c
>+++ b/xen/arch/x86/hvm/dm.c
>@@ -416,16 +416,19 @@ static int dm_op(const struct dmop_args *op_args)
>     {
>         struct xen_dm_op_get_ioreq_server_info *data =
>             &op.u.get_ioreq_server_info;
>+        const uint16_t valid_flags = XEN_DMOP_no_gfns;
> 
>         const_op = false;
> 
>         rc = -EINVAL;
>-        if ( data->pad )
>+        if ( data->flags & ~valid_flags )
>             break;
> 
>         rc = hvm_get_ioreq_server_info(d, data->id,
>-                                       &data->ioreq_gfn,
>-                                       &data->bufioreq_gfn,
>+                                       (data->flags & XEN_DMOP_no_gfns) ?
>+                                       NULL : &data->ioreq_gfn,
>+                                       (data->flags & XEN_DMOP_no_gfns) ?
>+                                       NULL : &data->bufioreq_gfn,
>                                        &data->bufioreq_port);
>         break;
>     }
>diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
>index eec4e4771e..39de659ddf 100644
>--- a/xen/arch/x86/hvm/ioreq.c
>+++ b/xen/arch/x86/hvm/ioreq.c
>@@ -350,6 +350,9 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server *s,
>     }
> }
> 
>+#define HANDLE_BUFIOREQ(s) \
>+    ((s)->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF)
>+
> static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
>                                      struct vcpu *v)
> {
>@@ -371,7 +374,7 @@ static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
> 
>     sv->ioreq_evtchn = rc;
> 
>-    if ( v->vcpu_id == 0 && s->bufioreq.va != NULL )
>+    if ( v->vcpu_id == 0 && HANDLE_BUFIOREQ(s) )
>     {
>         struct domain *d = s->domain;
> 
>@@ -422,7 +425,7 @@ static void hvm_ioreq_server_remove_vcpu(struct hvm_ioreq_server *s,
> 
>         list_del(&sv->list_entry);
> 
>-        if ( v->vcpu_id == 0 && s->bufioreq.va != NULL )
>+        if ( v->vcpu_id == 0 && HANDLE_BUFIOREQ(s) )
>             free_xen_event_channel(v->domain, s->bufioreq_evtchn);
> 
>         free_xen_event_channel(v->domain, sv->ioreq_evtchn);
>@@ -449,7 +452,7 @@ static void hvm_ioreq_server_remove_all_vcpus(struct hvm_ioreq_server *s)
> 
>         list_del(&sv->list_entry);
> 
>-        if ( v->vcpu_id == 0 && s->bufioreq.va != NULL )
>+        if ( v->vcpu_id == 0 && HANDLE_BUFIOREQ(s) )
>             free_xen_event_channel(v->domain, s->bufioreq_evtchn);
> 
>         free_xen_event_channel(v->domain, sv->ioreq_evtchn);
>@@ -460,14 +463,13 @@ static void hvm_ioreq_server_remove_all_vcpus(struct hvm_ioreq_server *s)
>     spin_unlock(&s->lock);
> }
> 
>-static int hvm_ioreq_server_map_pages(struct hvm_ioreq_server *s,
>-                                      bool handle_bufioreq)
>+static int hvm_ioreq_server_map_pages(struct hvm_ioreq_server *s)
> {
>     int rc;
> 
>     rc = hvm_map_ioreq_gfn(s, false);
> 
>-    if ( !rc && handle_bufioreq )
>+    if ( !rc && HANDLE_BUFIOREQ(s) )
>         rc = hvm_map_ioreq_gfn(s, true);
> 
>     if ( rc )
>@@ -597,13 +599,7 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server *s,
>     if ( rc )
>         return rc;
> 
>-    if ( bufioreq_handling == HVM_IOREQSRV_BUFIOREQ_ATOMIC )
>-        s->bufioreq_atomic = true;
>-
>-    rc = hvm_ioreq_server_map_pages(
>-             s, bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF);

It seems that for default IO server, mapping gfns here is required. Old
qemu won't call hvm_get_ioreq_server_info() (and cannot because of the
assertion 'ASSERT(!IS_DEFAULT(s))') to set up the mapping.

Thanks
Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2017-12-07  4:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-28 15:08 [PATCH v14 00/11] x86: guest resource mapping Paul Durrant
2017-11-28 15:08 ` [PATCH v14 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list Paul Durrant
2017-11-28 15:08 ` [PATCH v14 02/11] x86/hvm/ioreq: simplify code and use consistent naming Paul Durrant
2017-11-28 15:08 ` [PATCH v14 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page Paul Durrant
2017-11-28 15:08 ` [PATCH v14 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted Paul Durrant
2017-12-06 21:49   ` Chao Gao [this message]
2017-12-07  8:38     ` Paul Durrant
2017-11-28 15:08 ` [PATCH v14 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources Paul Durrant
2017-11-28 18:50   ` Daniel De Graaf
2017-11-28 15:08 ` [PATCH v14 06/11] x86/hvm/ioreq: add a new mappable resource type Paul Durrant
2017-12-14  9:51   ` Paul Durrant
2017-12-14  9:52     ` Paul Durrant
2017-12-14 10:31     ` Paul Durrant
2017-12-14 13:46     ` Jan Beulich
2017-12-14 13:46       ` Paul Durrant
2017-11-28 15:08 ` [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update Paul Durrant
2017-12-12 13:25   ` Jan Beulich
2017-12-12 13:52     ` Andrew Cooper
2017-12-12 14:38       ` Jan Beulich
2017-12-13 12:06         ` Paul Durrant
2017-12-13 14:35           ` Jan Beulich
2017-12-13 14:49             ` Paul Durrant
2017-12-13 15:24               ` Jan Beulich
2017-12-13 17:03                 ` Paul Durrant
2017-12-14 13:50                   ` Jan Beulich
2017-12-12 14:54     ` Paul Durrant
2017-11-28 15:08 ` [PATCH v14 08/11] tools/libxenforeignmemory: add support for resource mapping Paul Durrant
2017-11-28 15:08 ` [PATCH v14 09/11] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint Paul Durrant
2017-11-28 15:08 ` [PATCH v14 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table Paul Durrant
2017-11-28 15:08 ` [PATCH v14 11/11] tools/libxenctrl: use new xenforeignmemory API to seed grant table Paul Durrant

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=20171206214948.GA47014@op-computing \
    --to=chao.gao@intel.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=paul.durrant@citrix.com \
    --cc=sstabellini@kernel.org \
    --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).