[Xen-changelog] [xen stable-4.8] x86/hvm: don't unconditionally create a default ioreq server

[patchbot@xxxxxxx]

commit e298344e4a43ce72999cb7efaa0132d0077da08d
Author:     Paul Durrant <paul.durrant@xxxxxxxxxx>
AuthorDate: Wed Jan 18 09:46:26 2017 +0100
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Wed Jan 18 09:46:26 2017 +0100

    x86/hvm: don't unconditionally create a default ioreq server
    
    Avoid doing so if the domain is not under construction.
    
    If upstream QEMU is in use then it will explicitly create an ioreq server
    rather than implicitly creating the default ioreq server, which is a
    side-effect of reading HVM_PARAM_IOREQ_PFN, HVM_PARAM_BUFIOREQ_PFN,
    or HVM_PARAM_BUFIOREQ_EVTCHN (as is done by legacy QEMUs).
    
    However, if the domain is subsequently saved/migrated then those parameters
    are read and hence the default server will be unnecessarily instantiated.
    
    This patch adds an extra check of the 'creation_finished' flag when those
    HVM params are read and will only instantiate the server if the domain is
    under construction, which will always be the case when QEMU is invoked.
    
    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Tested-by: Zhang Chen <zhangchen.fnst@xxxxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    
    x86/hvm: Fix HVMOP_get_param when skipping creating the default ioreq server
    
    c/s e7dabe5 "x86/hvm: don't unconditionally create a default ioreq server"
    added a break statement, but the logic previously depended on falling 
through
    into the default case to fill in the value the caller asked for.
    
    This causes the sending migration code to put a junk PARAM into the stream,
    and the receiving side to fail to zero the IOREQ pages, causing QEMU to 
object
    when it finds stale requests while starting up.
    
    Reorder the code so it more clearly falls through into the default case.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    master commit: e7dabe59c3239dc9ef9edbc49ed54f754616ebf7
    master date: 2016-12-12 09:49:10 +0100
    master commit: 451c9938c68ccb77ff94765f7ac47e8de51d3f43
    master date: 2016-12-13 09:58:33 +0000
---
 xen/arch/x86/hvm/hvm.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 25dc759..f8ef6e5 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5339,16 +5339,23 @@ static int hvmop_get_param(
     case HVM_PARAM_IOREQ_PFN:
     case HVM_PARAM_BUFIOREQ_PFN:
     case HVM_PARAM_BUFIOREQ_EVTCHN:
-    {
-        domid_t domid;
+        /*
+         * It may be necessary to create a default ioreq server here,
+         * because legacy versions of QEMU are not aware of the new API for
+         * explicit ioreq server creation. However, if the domain is not
+         * under construction then it will not be QEMU querying the
+         * parameters and thus the query should not have that side-effect.
+         */
+        if ( !d->creation_finished )
+        {
+            domid_t domid = d->arch.hvm_domain.params[HVM_PARAM_DM_DOMAIN];
+
+            rc = hvm_create_ioreq_server(d, domid, 1,
+                                         HVM_IOREQSRV_BUFIOREQ_LEGACY, NULL);
+            if ( rc != 0 && rc != -EEXIST )
+                goto out;
+        }
 
-        /* May need to create server. */
-        domid = d->arch.hvm_domain.params[HVM_PARAM_DM_DOMAIN];
-        rc = hvm_create_ioreq_server(d, domid, 1,
-                                     HVM_IOREQSRV_BUFIOREQ_LEGACY, NULL);
-        if ( rc != 0 && rc != -EEXIST )
-            goto out;
-    }
     /*FALLTHRU*/
     default:
         a.value = d->arch.hvm_domain.params[a.index];
--
generated by git-patchbot for /home/xen/git/xen.git#stable-4.8

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
https://lists.xenproject.org/xen-changelog