ioreq: make use of 'legacy' GFNs

PATCH In review Paul Durrant 2 participants 10 messages Oct 5, 2018 – Oct 8, 2018

Share & tools

Paul Durrant

author

2018-10-05 13:43 UTC #0 lore raw

cover ioreq: make use of 'legacy' GFNs

Paul Durrant (2):
x86/hvm: make sure HVM_PARAM_[BUF]IOREQ_PFN can only be set once x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN

 xen/arch/x86/hvm/hvm.c           |  2 ++
 xen/arch/x86/hvm/ioreq.c         | 50 ++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/hvm/domain.h |  3 ++-
 3 files changed, 52 insertions(+), 3 deletions(-)

Signature · 7 lines

2.11.0


_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Paul Durrant

author

2018-10-05 13:43 UTC #1 lore raw

PATCH 1/2 x86/hvm: make sure HVM_PARAM_[BUF]IOREQ_PFN can only be set once

These parameters should have always been in the 'set once' category but this has, so far, not been enforced.

Signed-off-by Paul Durrant <[email protected]>

---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>
Cc: Wei Liu <[email protected]>

---
 xen/arch/x86/hvm/hvm.c | 2 ++
 1 file changed, 2 insertions(+)

xen/arch/x86/hvm/hvm.c +2 -0

index 51fc3ec07f..07ec20fb52 100644
@@ -4083,6 +4083,8 @@ static int hvm_allow_set_param(struct domain *d,
     {
     /* The following parameters should only be changed once. */
     case HVM_PARAM_VIRIDIAN:
+    case HVM_PARAM_IOREQ_PFN:
+    case HVM_PARAM_BUFIOREQ_PFN:
     case HVM_PARAM_IOREQ_SERVER_PFN:
     case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
     case HVM_PARAM_ALTP2M:

Signature · 7 lines

2.11.0


_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Jan Beulich

2018-10-08 13:16 UTC #2 lore raw

Re: [PATCH 1/2] x86/hvm: make sure HVM_PARAM_[BUF]IOREQ_PFN can only be set once

Quoted 3 lines

Quoted 1 line
Quoted 1 line · On 05.10.18 at 15:43, <[email protected]> wrote:
These parameters should have always been in the 'set once' category but this has, so far, not been enforced.

But now that we're not even handling these anymore, why is there a need to start doing so? If anything wouldn't it be better to add them to the deprecated group in that same function (and maybe also its "get" counterpart)?

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Jan Beulich

2018-10-08 13:20 UTC #3 lore raw

Re: [PATCH 1/2] x86/hvm: make sure HVM_PARAM_[BUF]IOREQ_PFN can only be set once

In reply to Paul Durrant

Quoted 3 lines

Quoted 1 line
Quoted 1 line · On 05.10.18 at 15:43, <[email protected]> wrote:
These parameters should have always been in the 'set once' category but this has, so far, not been enforced.

Hmm, now that I'm looking at patch 2 I see where this is coming from, but a hint towards this here would have helped, if this is to be a separate patch (folding into the second patch with a respective remark would perhaps have been better anyway).

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Paul Durrant

author

2018-10-08 13:21 UTC #4 lore raw

Re: [PATCH 1/2] x86/hvm: make sure HVM_PARAM_[BUF]IOREQ_PFN can only be set once

Quoted 9 lines

-----Original Message-----
From: Jan Beulich [mailto:[email protected]]
Sent: 08 October 2018 14:20
To: Paul Durrant <[email protected]>
Cc: Andrew Cooper <[email protected]>; Wei Liu <[email protected]>; xen-devel <[email protected]>
Subject: Re: [PATCH 1/2] x86/hvm: make sure HVM_PARAM_[BUF]IOREQ_PFN can only be set once

Quoted 9 lines

Quoted 3 lines
Quoted 1 line
Quoted 1 line · On 05.10.18 at 15:43, <[email protected]> wrote:
These parameters should have always been in the 'set once' category but this has, so far, not been enforced.
Hmm, now that I'm looking at patch 2 I see where this is coming from, but a hint towards this here would have helped, if this is to be a separate patch (folding into the second patch with a respective remark would perhaps have been better anyway).

Ok. I'll squash them together if I need to do a v2.

Paul

Quoted 2 lines

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Paul Durrant

author

2018-10-05 13:43 UTC #5 lore raw

PATCH 2/2 x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN

In reply to Paul Durrant

Since commit 2c257bd6 "x86/hvm: remove default ioreq server (again)" the GFNs allocated by the toolstack and set in HVM_PARAM_IOREQ_PFN and HVM_PARAM_BUFIOREQ_PFN have been unused. This patch allows them to be used by (non-default) ioreq servers.

NOTE: This fixes a compatibility issue. A guest created on a version of
Xen that pre-dates the initial ioreq server implementation and then migrated in will currently fail to resume because its migration stream will lack values for HVM_PARAM_IOREQ_SERVER_PFN and HVM_PARAM_NR_IOREQ_SERVER_PAGES *unless* the system has an emulator domain that uses direct resource mapping (which depends on the version of privcmd it happens to have) in which case it will not require use of GFNs for the ioreq server shared pages.

Signed-off-by Paul Durrant <[email protected]>

---
Cc: Jan Beulich <[email protected]>
Cc: Andrew Cooper <[email protected]>
Cc: Wei Liu <[email protected]>

A similar compatibility issue with migrated-in VMs exists with Xen 4.11 because the upstream QEMU fall-back to use legacy ioreq server was broken when direct resource mapping was introduced.
This is because, prior to the resource mapping patches, it was the creation of the non-default ioreq server that failed if GFNs were not available whereas, as of 4.11, it is retrieval of the info that fails which does not trigger the fall-back.

---
 xen/arch/x86/hvm/ioreq.c         | 50 ++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/hvm/domain.h |  3 ++-
 2 files changed, 50 insertions(+), 3 deletions(-)

xen/arch/x86/hvm/ioreq.c +48 -2

index 3569beaad5..4bac0a100c 100644
@@ -237,6 +237,26 @@ bool handle_hvm_io_completion(struct vcpu *v)
     return true;
 }
 
+static gfn_t hvm_alloc_legacy_ioreq_gfn(struct hvm_ioreq_server *s)
+{
+    struct domain *d = s->target;
+    unsigned int i;
+
+    BUILD_BUG_ON(HVM_PARAM_IOREQ_PFN >
+                 sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
+    BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN >
+                 sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
+    BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN != HVM_PARAM_IOREQ_PFN + 1);
+
+    for ( i = HVM_PARAM_IOREQ_PFN; i <= HVM_PARAM_BUFIOREQ_PFN; i++ )
+    {
+        if ( !test_and_set_bit(i, &d->arch.hvm.ioreq_gfn.legacy_mask) )
+            return _gfn(d->arch.hvm.params[i]);
+    }
+
+    return INVALID_GFN;
+}
+
 static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
     struct domain *d = s->target;

@@ -248,7 +268,29 @@ static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
             return _gfn(d->arch.hvm.ioreq_gfn.base + i);
     }
 
-    return INVALID_GFN;
+    /*
+     * If we are out of 'normal' GFNs then we may still have a 'legacy'
+     * GFN available.
+     */
+    return hvm_alloc_legacy_ioreq_gfn(s);
+}
+
+static bool hvm_free_legacy_ioreq_gfn(struct hvm_ioreq_server *s,
+                                      gfn_t gfn)
+{
+    struct domain *d = s->target;
+    unsigned int i;
+
+    for ( i = HVM_PARAM_IOREQ_PFN; i <= HVM_PARAM_BUFIOREQ_PFN; i++ )
+    {
+        if ( gfn_eq(gfn, _gfn(d->arch.hvm.params[i])) )
+             break;
+    }
+    if ( i > HVM_PARAM_BUFIOREQ_PFN )
+        return false;
+
+    clear_bit(i, &d->arch.hvm.ioreq_gfn.legacy_mask);
+    return true;
 }
 
 static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn)

@@ -258,7 +300,11 @@ static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn)
 
     ASSERT(!gfn_eq(gfn, INVALID_GFN));
 
-    set_bit(i, &d->arch.hvm.ioreq_gfn.mask);
+    if ( !hvm_free_legacy_ioreq_gfn(s, gfn) )
+    {
+        ASSERT(i < sizeof(d->arch.hvm.ioreq_gfn.mask) * 8);
+        set_bit(i, &d->arch.hvm.ioreq_gfn.mask);
+    }
 }
 
 static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)

xen/include/asm-x86/hvm/domain.h +2 -1

index 80b2ab041e..a9f68d9571 100644
@@ -95,7 +95,8 @@ struct hvm_domain {
     /* Guest page range used for non-default ioreq servers */
     struct {
         unsigned long base;
-        unsigned long mask;
+        unsigned long mask; /* clear to allocate */
+        unsigned long legacy_mask; /* set to allocate */
     } ioreq_gfn;
 
     /* Lock protects all other values in the sub-struct and the default */

Signature · 7 lines

2.11.0


_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Jan Beulich

2018-10-08 13:29 UTC #6 lore raw

Re: [PATCH 2/2] x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN

Quoted 6 lines

Quoted 1 line
Quoted 1 line · On 05.10.18 at 15:43, <[email protected]> wrote:
Since commit 2c257bd6 "x86/hvm: remove default ioreq server (again)" the GFNs allocated by the toolstack and set in HVM_PARAM_IOREQ_PFN and HVM_PARAM_BUFIOREQ_PFN have been unused. This patch allows them to be used by (non-default) ioreq servers.

Quoted 9 lines

NOTE: This fixes a compatibility issue. A guest created on a version of
Xen that pre-dates the initial ioreq server implementation and then migrated in will currently fail to resume because its migration stream will lack values for HVM_PARAM_IOREQ_SERVER_PFN and HVM_PARAM_NR_IOREQ_SERVER_PAGES *unless* the system has an emulator domain that uses direct resource mapping (which depends on the version of privcmd it happens to have) in which case it will not require use of GFNs for the ioreq server shared pages.

Meaning this wants to be backported till where?

Quoted 7 lines

A similar compatibility issue with migrated-in VMs exists with Xen 4.11 because the upstream QEMU fall-back to use legacy ioreq server was broken when direct resource mapping was introduced.
This is because, prior to the resource mapping patches, it was the creation of the non-default ioreq server that failed if GFNs were not available whereas, as of 4.11, it is retrieval of the info that fails which does not trigger the fall-back.

Are you working on a fix or workaround for this, too, then?

Quoted 11 lines

xen/arch/x86/hvm/ioreq.c +5 -0

@@ -237,6 +237,26 @@ bool handle_hvm_io_completion(struct vcpu *v)
     return true;
 }
 
+static gfn_t hvm_alloc_legacy_ioreq_gfn(struct hvm_ioreq_server *s)
+{
+    struct domain *d = s->target;
+    unsigned int i;
+

xen/arch/x86/hvm/ioreq.c bool handle_hvm_io_completion(struct vcpu *v) · line 254

Quoted 10 lines

xen/arch/x86/hvm/ioreq.c +10 -0

+    BUILD_BUG_ON(HVM_PARAM_IOREQ_PFN >
+                 sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
+    BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN >
+                 sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
+    BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN != HVM_PARAM_IOREQ_PFN + 1);
+
+    for ( i = HVM_PARAM_IOREQ_PFN; i <= HVM_PARAM_BUFIOREQ_PFN; i++ )
+    {
+        if ( !test_and_set_bit(i, &d->arch.hvm.ioreq_gfn.legacy_mask) )
+            return _gfn(d->arch.hvm.params[i]);

Aren't you risking to use GFN 0 here, if the param was never set? Since in theory GFN 0 could be valid here, perhaps whether these MFNs may be used should be tracked by starting out legacy_mask such that allocations are impossible, while the setting of the params would then make the slots available for allocating from?

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Paul Durrant

author

2018-10-08 14:38 UTC #7 lore raw

Re: [PATCH 2/2] x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN

Quoted 27 lines

-----Original Message-----
From: Jan Beulich [mailto:[email protected]]
Sent: 08 October 2018 14:29
To: Paul Durrant <[email protected]>
Cc: Andrew Cooper <[email protected]>; Wei Liu <[email protected]>; xen-devel <[email protected]>
Subject: Re: [PATCH 2/2] x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN
Quoted 4 lines
Quoted 1 line
Quoted 1 line · On 05.10.18 at 15:43, <[email protected]> wrote:
Since commit 2c257bd6 "x86/hvm: remove default ioreq server (again)" the GFNs allocated by the toolstack and set in HVM_PARAM_IOREQ_PFN and HVM_PARAM_BUFIOREQ_PFN have been unused. This patch allows them to be
used
Quoted 4 lines
by (non-default) ioreq servers.
NOTE: This fixes a compatibility issue. A guest created on a version of
Xen that pre-dates the initial ioreq server implementation and
then
Quoted 7 lines
migrated in will currently fail to resume because its migration stream will lack values for HVM_PARAM_IOREQ_SERVER_PFN and HVM_PARAM_NR_IOREQ_SERVER_PAGES *unless* the system has an emulator domain that uses direct resource mapping (which depends on the version of privcmd it happens to have) in which case it will not require use of GFNs for the ioreq server shared pages.

Quoted 2 lines

Meaning this wants to be backported till where?

This fix is 4.12 specific because it is predicated on removal of default ioreq server support.

Quoted 5 lines

Quoted 2 lines
A similar compatibility issue with migrated-in VMs exists with Xen 4.11 because the upstream QEMU fall-back to use legacy ioreq server was
broken
Quoted 2 lines
when direct resource mapping was introduced.
This is because, prior to the resource mapping patches, it was the

Quoted 8 lines

creation
Quoted 2 lines
of the non-default ioreq server that failed if GFNs were not available whereas, as of 4.11, it is retrieval of the info that fails which does
not
Quoted 1 line
trigger the fall-back.
Are you working on a fix or workaround for this, too, then?

Not yet. I'm not sure how to approach this. There are a few options:

1. Backport default IOREQ server removal and this fix
2. Do a bespoke 4.11 fix that forces IOREQ server creation to fail if there are no GFNs available, thus triggering the default IOREQ server fallback in QEMU.
3. Upstream a fix into QEMU to do a fallback at the point that it fails to get GFNs i.e. have it close its IOREQ server and then fall back to default.

The problem with 1 is that it breaks qemu trad. 2 is probably simplest, but if the emualator can do resource mapping it is unnecessary. 3 is probably best, but it's not our fix to deliver.

Thoughts?

Paul

Quoted 28 lines

Quoted 11 lines
xen/arch/x86/hvm/ioreq.c +5 -0
@@ -237,6 +237,26 @@ bool handle_hvm_io_completion(struct vcpu *v)
     return true;
 }
 
+static gfn_t hvm_alloc_legacy_ioreq_gfn(struct hvm_ioreq_server *s)
+{
+    struct domain *d = s->target;
+    unsigned int i;
+
xen/arch/x86/hvm/ioreq.c bool handle_hvm_io_completion(struct vcpu *v) · line 254
Quoted 10 lines
xen/arch/x86/hvm/ioreq.c +10 -0
+    BUILD_BUG_ON(HVM_PARAM_IOREQ_PFN >
+                 sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
+    BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN >
+                 sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
+    BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN != HVM_PARAM_IOREQ_PFN + 1);
+
+    for ( i = HVM_PARAM_IOREQ_PFN; i <= HVM_PARAM_BUFIOREQ_PFN; i++ )
+    {
+        if ( !test_and_set_bit(i, &d->arch.hvm.ioreq_gfn.legacy_mask) )
+            return _gfn(d->arch.hvm.params[i]);
Aren't you risking to use GFN 0 here, if the param was never set? Since in theory GFN 0 could be valid here, perhaps whether these MFNs may be used should be tracked by starting out legacy_mask such that allocations are impossible, while the setting of the params would then make the slots available for allocating from?

Quoted 2 lines

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Jan Beulich

2018-10-08 14:59 UTC #8 lore raw

Re: [PATCH 2/2] x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN

Quoted 28 lines

Quoted 28 lines
Quoted 1 line · On 08.10.18 at 16:38, <[email protected]> wrote:
-----Original Message-----
From: Jan Beulich [mailto:[email protected]]
Sent: 08 October 2018 14:29
To: Paul Durrant <[email protected]>
Cc: Andrew Cooper <[email protected]>; Wei Liu <[email protected]>; xen-devel <[email protected]>
Subject: Re: [PATCH 2/2] x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN
Quoted 4 lines
Quoted 1 line
Quoted 1 line · On 05.10.18 at 15:43, <[email protected]> wrote:
Since commit 2c257bd6 "x86/hvm: remove default ioreq server (again)" the GFNs allocated by the toolstack and set in HVM_PARAM_IOREQ_PFN and HVM_PARAM_BUFIOREQ_PFN have been unused. This patch allows them to be
used
Quoted 4 lines
by (non-default) ioreq servers.
NOTE: This fixes a compatibility issue. A guest created on a version of
Xen that pre-dates the initial ioreq server implementation and
then
Quoted 7 lines
migrated in will currently fail to resume because its migration stream will lack values for HVM_PARAM_IOREQ_SERVER_PFN and HVM_PARAM_NR_IOREQ_SERVER_PAGES *unless* the system has an emulator domain that uses direct resource mapping (which depends on the version of privcmd it happens to have) in which case it will not require use of GFNs for the ioreq server shared pages.

Quoted 5 lines

Quoted 2 lines
Meaning this wants to be backported till where?
This fix is 4.12 specific because it is predicated on removal of default ioreq server support.

Ah, good.

Quoted 23 lines

Quoted 5 lines
Quoted 2 lines
A similar compatibility issue with migrated-in VMs exists with Xen 4.11 because the upstream QEMU fall-back to use legacy ioreq server was
broken
Quoted 2 lines
when direct resource mapping was introduced.
This is because, prior to the resource mapping patches, it was the
Quoted 8 lines
creation
Quoted 2 lines
of the non-default ioreq server that failed if GFNs were not available whereas, as of 4.11, it is retrieval of the info that fails which does
not
Quoted 1 line
trigger the fall-back.
Are you working on a fix or workaround for this, too, then?
Not yet. I'm not sure how to approach this. There are a few options:
1. Backport default IOREQ server removal and this fix
2. Do a bespoke 4.11 fix that forces IOREQ server creation to fail if there are no GFNs available, thus triggering the default IOREQ server fallback in QEMU.
3. Upstream a fix into QEMU to do a fallback at the point that it fails to get GFNs i.e. have it close its IOREQ server and then fall back to default.

Quoted 5 lines

The problem with 1 is that it breaks qemu trad. 2 is probably simplest, but if the emualator can do resource mapping it is unnecessary. 3 is probably best, but it's not our fix to deliver.
Thoughts?

2 indeed looks best to me then. Though I'm not sure I understand what you say correctly: Would triggering the default IOREQ server fallback be a step backwards, if the emulator is capable and able to use resource mapping? If so, somehow avoiding this would of course be nice, and I'd then assume this isn't reasonable to achieve without a qemu side change, in which case the solution wouldn't be any better than 3 anymore.

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel

Paul Durrant

author

2018-10-08 15:05 UTC #9 lore raw

Re: [PATCH 2/2] x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN

Quoted 82 lines

-----Original Message-----
From: Jan Beulich [mailto:[email protected]]
Sent: 08 October 2018 15:59
To: Paul Durrant <[email protected]>
Cc: Andrew Cooper <[email protected]>; Wei Liu <[email protected]>; xen-devel <[email protected]>
Subject: RE: [PATCH 2/2] x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN
Quoted 10 lines
Quoted 10 lines
Quoted 1 line · On 08.10.18 at 16:38, <[email protected]> wrote:
-----Original Message-----
From: Jan Beulich [mailto:[email protected]]
Sent: 08 October 2018 14:29
To: Paul Durrant <[email protected]>
Cc: Andrew Cooper <[email protected]>; Wei Liu <[email protected]>; xen-devel <[email protected]>
Subject: Re: [PATCH 2/2] x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
Quoted 1 line · On 05.10.18 at 15:43, <[email protected]> wrote:
Since commit 2c257bd6 "x86/hvm: remove default ioreq server (again)"
the
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
GFNs allocated by the toolstack and set in HVM_PARAM_IOREQ_PFN and HVM_PARAM_BUFIOREQ_PFN have been unused. This patch allows them to be
used
Quoted 3 lines
by (non-default) ioreq servers.
NOTE: This fixes a compatibility issue. A guest created on a version
of
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Xen that pre-dates the initial ioreq server implementation and
then
Quoted 4 lines
migrated in will currently fail to resume because its migration stream will lack values for HVM_PARAM_IOREQ_SERVER_PFN and HVM_PARAM_NR_IOREQ_SERVER_PAGES *unless* the system has an emulator domain that uses direct resource mapping (which
depends
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
on the version of privcmd it happens to have) in which case it will not require use of GFNs for the ioreq server shared pages.
Meaning this wants to be backported till where?
This fix is 4.12 specific because it is predicated on removal of default ioreq server support.
Ah, good.
Quoted 1 line
Quoted 1 line
Quoted 1 line
A similar compatibility issue with migrated-in VMs exists with Xen
4.11
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
because the upstream QEMU fall-back to use legacy ioreq server was
broken
Quoted 2 lines
when direct resource mapping was introduced.
This is because, prior to the resource mapping patches, it was the
creation
Quoted 1 line
of the non-default ioreq server that failed if GFNs were not
available
Quoted 1 line
Quoted 1 line
Quoted 1 line
whereas, as of 4.11, it is retrieval of the info that fails which
does
Quoted 10 lines
Quoted 5 lines
not
Quoted 1 line
trigger the fall-back.
Are you working on a fix or workaround for this, too, then?
Not yet. I'm not sure how to approach this. There are a few options:
1. Backport default IOREQ server removal and this fix
2. Do a bespoke 4.11 fix that forces IOREQ server creation to fail if
there
Quoted 1 line
are no GFNs available, thus triggering the default IOREQ server fallback
in
Quoted 2 lines
QEMU.
3. Upstream a fix into QEMU to do a fallback at the point that it fails
to
Quoted 1 line
get GFNs i.e. have it close its IOREQ server and then fall back to
default.
Quoted 2 lines
The problem with 1 is that it breaks qemu trad. 2 is probably simplest,
but
Quoted 1 line
if the emualator can do resource mapping it is unnecessary. 3 is
probably

Quoted 8 lines

Quoted 3 lines
best, but it's not our fix to deliver.
Thoughts?
2 indeed looks best to me then. Though I'm not sure I understand what you say correctly: Would triggering the default IOREQ server fallback be a step backwards, if the emulator is capable and able to use resource mapping?

Yes. With resource mapping the emulator doesn't rely in pages on special GFNs and so it would indeed be a step backwards...

Quoted 5 lines

If so, somehow avoiding this would of
course be nice, and I'd then assume this isn't reasonable to achieve without a qemu side change, in which case the solution wouldn't be any better than 3 anymore.

...but avoiding would indeed mean a change in QEMU.

Given that the chances of having a VM migrated all the way in from some ancient Xen without a reboot along the way at any point is probably quite small, and that no-one is likely to notice a fall-back to default IOREQ server unless they are really looking for it, I'd say let's go with 2.

Paul

Quoted 2 lines

Jan

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel