diff mbox series

libxl: Add suppress-vmdesc to QEMU -machine pc options

Message ID 20201019200050.103360-1-jandryuk@gmail.com (mailing list archive)
State New, archived
Headers show
Series libxl: Add suppress-vmdesc to QEMU -machine pc options | expand

Commit Message

Jason Andryuk Oct. 19, 2020, 8 p.m. UTC
The device model state saved by QMP xen-save-devices-state doesn't
include the vmdesc json.  When restoring an HVM, xen-load-devices-state
always triggers "Expected vmdescription section, but got 0".  This is
not a problem when restore comes from a file.  However, when QEMU runs
in a linux stubdom and comes over a console, EOF is not received.  This
causes a delay restoring - though it does restore.

Setting suppress-vmdesc skips looking for the vmdesc during restore and
avoids the wait.

This is a libxl change for the non-xenfv case to match the xenfv change
made in qemu

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
---

Should this also add suppress-vmdesc to xenfv for backwards
compatibility?  In that case, the change in QEMU is redundent.  Since
this only really matters for the stubdom case, it could be conditioned
on that.

 tools/libs/light/libxl_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Anthony PERARD Oct. 20, 2020, 3:39 p.m. UTC | #1
On Mon, Oct 19, 2020 at 04:00:50PM -0400, Jason Andryuk wrote:
> The device model state saved by QMP xen-save-devices-state doesn't
> include the vmdesc json.  When restoring an HVM, xen-load-devices-state
> always triggers "Expected vmdescription section, but got 0".  This is
> not a problem when restore comes from a file.  However, when QEMU runs
> in a linux stubdom and comes over a console, EOF is not received.  This
> causes a delay restoring - though it does restore.
> 
> Setting suppress-vmdesc skips looking for the vmdesc during restore and
> avoids the wait.
> 
> This is a libxl change for the non-xenfv case to match the xenfv change
> made in qemu
> 
> Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
> ---
> 
> Should this also add suppress-vmdesc to xenfv for backwards
> compatibility?  In that case, the change in QEMU is redundent.  Since
> this only really matters for the stubdom case, it could be conditioned
> on that.

QEMU doesn't complain about having suppress-vmdesc set on the command
line and as a default for the xenfv machine, so I don't mind adding it
to the xenfv machine in libxl, while keeping the change in QEMU.

The change is already applied to QEMU, so unless there's an issue, I
don't want to revert it. It might be useful for tool stacks that don't
use libxl.

Also, the change matters as well for non-stubdom cases as it removed a
cryptic error message from qemu-dm's logs :-).

Thanks,
Jason Andryuk Oct. 20, 2020, 3:45 p.m. UTC | #2
On Tue, Oct 20, 2020 at 11:40 AM Anthony PERARD
<anthony.perard@citrix.com> wrote:
>
> On Mon, Oct 19, 2020 at 04:00:50PM -0400, Jason Andryuk wrote:
> > The device model state saved by QMP xen-save-devices-state doesn't
> > include the vmdesc json.  When restoring an HVM, xen-load-devices-state
> > always triggers "Expected vmdescription section, but got 0".  This is
> > not a problem when restore comes from a file.  However, when QEMU runs
> > in a linux stubdom and comes over a console, EOF is not received.  This
> > causes a delay restoring - though it does restore.
> >
> > Setting suppress-vmdesc skips looking for the vmdesc during restore and
> > avoids the wait.
> >
> > This is a libxl change for the non-xenfv case to match the xenfv change
> > made in qemu
> >
> > Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
> > ---
> >
> > Should this also add suppress-vmdesc to xenfv for backwards
> > compatibility?  In that case, the change in QEMU is redundent.  Since
> > this only really matters for the stubdom case, it could be conditioned
> > on that.
>
> QEMU doesn't complain about having suppress-vmdesc set on the command
> line and as a default for the xenfv machine, so I don't mind adding it
> to the xenfv machine in libxl, while keeping the change in QEMU.

Okay.

> The change is already applied to QEMU, so unless there's an issue, I
> don't want to revert it. It might be useful for tool stacks that don't
> use libxl.

Good point about the alternative toolstacks.

> Also, the change matters as well for non-stubdom cases as it removed a
> cryptic error message from qemu-dm's logs :-).

:)

Yes, as I explained for the QEMU change it is the correct thing to do.
It's just kinda a shame that libxl will need a compatibility change
kept around indefinitely.

Regards,
Jason
diff mbox series

Patch

diff --git a/tools/libs/light/libxl_dm.c b/tools/libs/light/libxl_dm.c
index d1ff35dda3..7d735ffcd9 100644
--- a/tools/libs/light/libxl_dm.c
+++ b/tools/libs/light/libxl_dm.c
@@ -1778,7 +1778,7 @@  static int libxl__build_device_model_args_new(libxl__gc *gc,
             /* Switching here to the machine "pc" which does not add
              * the xen-platform device instead of the default "xenfv" machine.
              */
-            machinearg = libxl__strdup(gc, "pc,accel=xen");
+            machinearg = libxl__strdup(gc, "pc,accel=xen,suppress-vmdesc=on");
         } else {
             machinearg = libxl__strdup(gc, "xenfv");
         }