[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Problem with IOMEM and domain reboot

Hi, Wei!

On 02/06/2018 02:36 PM, Wei Liu wrote:
On Wed, Dec 20, 2017 at 06:27:02PM +0200, Oleksandr Andrushchenko wrote:
Hi, all!

While trying to reboot a domain which has iomem configured
(we are passing through some devices), I found an issue,
that after domain reboot those iomem's are incorrectly re-mapped,
e.g. for the configuration snippet below fe960 -> 0.

Part of the domain config I use:

During domain creation:
libxl_create.c:210:libxl__domain_build_info_setdefault: iomem gfn fd000
start fd010
libxl_create.c:210:libxl__domain_build_info_setdefault: iomem gfn
ffffffffffffffff start fe960

which means that for fe960 initial value was set to LIBXL_INVALID_GFN
and then on domain configuration,

     for (i = 0 ; i < b_info->num_iomem; i++)
         if (b_info->iomem[i].gfn == LIBXL_INVALID_GFN)
             b_info->iomem[i].gfn = b_info->iomem[i].start;

made that GFN for fe960 to be set to the correct value.

But during domain reboot I see that
tries to replicate configuration from the original domain config
being rebooted, but that leads to iomem's GFN to be set to 0 (if configured

iomem gfn fd000 start fd010
iomem gfn 0 start fe960

Thus, further domain restart procedure leads to invalid mapping, e.g. fe960
-> 0.

I created a patch which allowed me to reboot the domain, but I would love
to hear comments on what would be the proper fix.

Thank you,

 From aa1f20af73a5a3c8f2c904b857a79334d18d41ff Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
Date: Wed, 20 Dec 2017 17:51:18 +0200
Subject: [PATCH] [HACK] Reset iomem's gfn to LIBXL_INVALID_GFN on reboot

During domain reboot its configuration is partially reused
to re-create a new domain, but iomem's GFN field for the
iomem is only restored for those memory ranges, which are
configured in form of [IOMEM_START,NUM_PAGES[@GFN], but not for
those in form of [IOMEM_START,NUM_PAGES], e.g. without GFN.
For the latter GFN is reset to 0, but while mapping ranges
to a domain during reboot there is a check that GFN treated
as valid if it is not equal to LIBXL_INVALID_GFN, thus making
Xen to map IOMEM_START to address 0 in the guest's address space.

Workaround it by resseting GFN to LIBXL_INVALID_GFN, so xl
can set proper values for mapping on reboot.

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
  tools/libxl/libxl_domain.c | 9 +++++++++
  1 file changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index ef1a0927b00d..2678ad2ad54f 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1647,6 +1647,15 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, 
uint32_t domid,
+ /* reset IOMEM's GFN to initial value */
+    {
+        int i;
+        for (i = 0; i < d_config->b_info.num_iomem; i++)
+            if (d_config->b_info.iomem[i].gfn == 0)
+                d_config->b_info.iomem[i].gfn = LIBXL_INVALID_GFN;
+    }
I don't think this is necessary. Instead we should tell libxl to save
the generated value into the template. Add an update_config hook for the
iomem type should be better.
Agree, this is why I tagged the patch as [HACK]
Unfortunately, I have little knowledge of libxl and not sure
how to properly fix it. Can you tell a bit more on what
a proper fix could be?
Thank you,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.