Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
However long term I think it might make sense to try and reuse one of the existing libxl__arch hooks, i.e. libxl__arch_domain_init_hw_description or libxl__arch_domain_finalise_hw_description. On ARM these are to do with setting the Device Tree Blob, which included the memory map, so it is somewhat morally equivalent to configuring the e820 on x86, I think. Those hooks are only called from libxl__build_pv today, but calling them from libxl__build_hvm seems like it would be good too. But seems this is raising some potential risks, isn't this? Although libxl__arch_domain_init_hw_description() and libxl__arch_domain_finalise_hw_description() are NOP to x86, they're really working on ARM side. So if we call them inside libxl__build_hvm(), any affects to ARM? I'm not very sure at this point unless anyone can validate this change on ARM, or you really ensure my concerns is unnecessary. All ARM guests use the PV code path so there is no risk. Okay but please take a close look at this, libxl__build_pv(gc, domid, info, state) | + libxl__arch_domain_finalise_hw_description(libxl__gc *gc, libxl_domain_build_info *info, struct xc_dom_image *dom) But in our case we need this parameter, struct xc_hvm_build_args *args, so how can we handle this conflict? Its not easy to add this, and it doesn't make sense as well in pv case. This is an internal API, you can feel free to modify it as necessary. I mean struct xc_hvm_build_args[] is a parameter specific to hvm so its wired to pass this in the case of hv. If we wrapper this again its not worth going this way. Please note that I started this subthread with "However long term I think it might make sense ...", This was not a request to redo this patch now. Okay lets record this and now just keep moving forward with the original. Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
On Tue, 2015-07-14 at 13:44 +0800, Chen, Tiejun wrote: > On 2015/7/13 18:15, Ian Campbell wrote: > > On Mon, 2015-07-13 at 17:47 +0800, Chen, Tiejun wrote: > >>> This approach looks like it should work, and I think given the point in > >>> the release it would be acceptable for 4.6. > >>> > >>> However long term I think it might make sense to try and reuse one of > >>> the existing libxl__arch hooks, i.e. > >>> libxl__arch_domain_init_hw_description or > >>> libxl__arch_domain_finalise_hw_description. On ARM these are to do with > >>> setting the Device Tree Blob, which included the memory map, so it is > >>> somewhat morally equivalent to configuring the e820 on x86, I think. > >>> > >>> Those hooks are only called from libxl__build_pv today, but calling them > >>> from libxl__build_hvm seems like it would be good too. > >> > >> But seems this is raising some potential risks, isn't this? Although > >> libxl__arch_domain_init_hw_description() and > >> libxl__arch_domain_finalise_hw_description() are NOP to x86, they're > >> really working on ARM side. So if we call them inside > >> libxl__build_hvm(), any affects to ARM? I'm not very sure at this point > >> unless anyone can validate this change on ARM, or you really ensure my > >> concerns is unnecessary. > > > > All ARM guests use the PV code path so there is no risk. > > Okay but please take a close look at this, > > libxl__build_pv(gc, domid, info, state) > | > + libxl__arch_domain_finalise_hw_description(libxl__gc *gc, >libxl_domain_build_info *info, >struct xc_dom_image *dom) > > But in our case we need this parameter, struct xc_hvm_build_args *args, > so how can we handle this conflict? Its not easy to add this, and it > doesn't make sense as well in pv case. This is an internal API, you can feel free to modify it as necessary. Please note that I started this subthread with "However long term I think it might make sense ...", This was not a request to redo this patch now. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
On 2015/7/13 18:15, Ian Campbell wrote: On Mon, 2015-07-13 at 17:47 +0800, Chen, Tiejun wrote: This approach looks like it should work, and I think given the point in the release it would be acceptable for 4.6. However long term I think it might make sense to try and reuse one of the existing libxl__arch hooks, i.e. libxl__arch_domain_init_hw_description or libxl__arch_domain_finalise_hw_description. On ARM these are to do with setting the Device Tree Blob, which included the memory map, so it is somewhat morally equivalent to configuring the e820 on x86, I think. Those hooks are only called from libxl__build_pv today, but calling them from libxl__build_hvm seems like it would be good too. But seems this is raising some potential risks, isn't this? Although libxl__arch_domain_init_hw_description() and libxl__arch_domain_finalise_hw_description() are NOP to x86, they're really working on ARM side. So if we call them inside libxl__build_hvm(), any affects to ARM? I'm not very sure at this point unless anyone can validate this change on ARM, or you really ensure my concerns is unnecessary. All ARM guests use the PV code path so there is no risk. Okay but please take a close look at this, libxl__build_pv(gc, domid, info, state) | + libxl__arch_domain_finalise_hw_description(libxl__gc *gc, libxl_domain_build_info *info, struct xc_dom_image *dom) But in our case we need this parameter, struct xc_hvm_build_args *args, so how can we handle this conflict? Its not easy to add this, and it doesn't make sense as well in pv case. Thanks Tiejun If there was some change to ARM to introduce an HVM style guest then it would want those hooks called in this place too (and they would need fixing as part of implementing such a thing). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
On Mon, 2015-07-13 at 17:47 +0800, Chen, Tiejun wrote: > > This approach looks like it should work, and I think given the point in > > the release it would be acceptable for 4.6. > > > > However long term I think it might make sense to try and reuse one of > > the existing libxl__arch hooks, i.e. > > libxl__arch_domain_init_hw_description or > > libxl__arch_domain_finalise_hw_description. On ARM these are to do with > > setting the Device Tree Blob, which included the memory map, so it is > > somewhat morally equivalent to configuring the e820 on x86, I think. > > > > Those hooks are only called from libxl__build_pv today, but calling them > > from libxl__build_hvm seems like it would be good too. > > But seems this is raising some potential risks, isn't this? Although > libxl__arch_domain_init_hw_description() and > libxl__arch_domain_finalise_hw_description() are NOP to x86, they're > really working on ARM side. So if we call them inside > libxl__build_hvm(), any affects to ARM? I'm not very sure at this point > unless anyone can validate this change on ARM, or you really ensure my > concerns is unnecessary. All ARM guests use the PV code path so there is no risk. If there was some change to ARM to introduce an HVM style guest then it would want those hooks called in this place too (and they would need fixing as part of implementing such a thing). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
This approach looks like it should work, and I think given the point in the release it would be acceptable for 4.6. However long term I think it might make sense to try and reuse one of the existing libxl__arch hooks, i.e. libxl__arch_domain_init_hw_description or libxl__arch_domain_finalise_hw_description. On ARM these are to do with setting the Device Tree Blob, which included the memory map, so it is somewhat morally equivalent to configuring the e820 on x86, I think. Those hooks are only called from libxl__build_pv today, but calling them from libxl__build_hvm seems like it would be good too. But seems this is raising some potential risks, isn't this? Although libxl__arch_domain_init_hw_description() and libxl__arch_domain_finalise_hw_description() are NOP to x86, they're really working on ARM side. So if we call them inside libxl__build_hvm(), any affects to ARM? I'm not very sure at this point unless anyone can validate this change on ARM, or you really ensure my concerns is unnecessary. In particular I think a call to libxl__arch_domain_finalise_hw_description could be inserted just before xc_hvm_build, which is similar to PV where it precedes xc_dom_build_image, and is where you would want to setup the e820. libxl__arch_domain_init_hw_description I think would still be a NOP on x86, but it should probably go either just after the call to libxl__domain_firmware. Tiejun, would you be willing to commit to refactoring this and the issues which Ian raised in response to #11 and #16 a subsequent clean up series? I don't think it would even need to wait for the freeze to be over to be posted (although it may need to wait to be applied). Yes, I'd like to follow this once my concerns above can be eliminated. Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
Chen, Tiejun writes ("Re: [v7][PATCH 13/16] libxl: construct e820 map with RDM
information for HVM guest"):
> I think you're right. I should make this specific to arch since here
> we're talking e820.
>
> So I tried to refactor this patch,
That looks good to me.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
On Fri, 2015-07-10 at 13:40 +0800, Chen, Tiejun wrote:
> >> tools/libxl/libxl_dom.c | 5 +++
> >> tools/libxl/libxl_internal.h | 24 +
> >> tools/libxl/libxl_x86.c | 83
> >>
> > ...
> >> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> >> index 62ef120..41da479 100644
> >> --- a/tools/libxl/libxl_dom.c
> >> +++ b/tools/libxl/libxl_dom.c
> >> @@ -1004,6 +1004,11 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> >> goto out;
> >> }
> >>
> >> +if (libxl__domain_construct_e820(gc, d_config, domid, &args)) {
> >> +LOG(ERROR, "setting domain memory map failed");
> >> +goto out;
> >> +}
> >
> > This is platform-independent code, isn't it ? In which case this will
> > break the build on ARM, I think.
> >
> > Would an ARM maintainer please confirm.
> >
>
> I think you're right. I should make this specific to arch since here
> we're talking e820.
>
> So I tried to refactor this patch,
This approach looks like it should work, and I think given the point in
the release it would be acceptable for 4.6.
However long term I think it might make sense to try and reuse one of
the existing libxl__arch hooks, i.e.
libxl__arch_domain_init_hw_description or
libxl__arch_domain_finalise_hw_description. On ARM these are to do with
setting the Device Tree Blob, which included the memory map, so it is
somewhat morally equivalent to configuring the e820 on x86, I think.
Those hooks are only called from libxl__build_pv today, but calling them
from libxl__build_hvm seems like it would be good too.
In particular I think a call to
libxl__arch_domain_finalise_hw_description could be inserted just before
xc_hvm_build, which is similar to PV where it precedes
xc_dom_build_image, and is where you would want to setup the e820.
libxl__arch_domain_init_hw_description I think would still be a NOP on
x86, but it should probably go either just after the call to
libxl__domain_firmware.
Tiejun, would you be willing to commit to refactoring this and the
issues which Ian raised in response to #11 and #16 a subsequent clean up
series? I don't think it would even need to wait for the freeze to be
over to be posted (although it may need to wait to be applied).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
tools/libxl/libxl_dom.c | 5 +++
tools/libxl/libxl_internal.h | 24 +
tools/libxl/libxl_x86.c | 83
...
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 62ef120..41da479 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1004,6 +1004,11 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
goto out;
}
+if (libxl__domain_construct_e820(gc, d_config, domid, &args)) {
+LOG(ERROR, "setting domain memory map failed");
+goto out;
+}
This is platform-independent code, isn't it ? In which case this will
break the build on ARM, I think.
Would an ARM maintainer please confirm.
I think you're right. I should make this specific to arch since here
we're talking e820.
So I tried to refactor this patch,
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index d04871c..939178a 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -49,4 +49,11 @@ int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,
_hidden
int libxl__arch_domain_map_irq(libxl__gc *gc, uint32_t domid, int irq);
+/* arch specific to construct memory mapping function */
+_hidden
+int libxl__arch_domain_construct_memmap(libxl__gc *gc,
+libxl_domain_config *d_config,
+uint32_t domid,
+struct xc_hvm_build_args *args);
+
#endif
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index f09c860..1526467 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -926,6 +926,14 @@ int libxl__arch_domain_map_irq(libxl__gc *gc,
uint32_t domid, int irq)
return xc_domain_bind_pt_spi_irq(CTX->xch, domid, irq, irq);
}
+int libxl__arch_domain_construct_memmap(libxl__gc *gc,
+libxl_domain_config *d_config,
+uint32_t domid,
+struct xc_hvm_build_args *args)
+{
+return 0;
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 62ef120..691c1f6 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1004,6 +1004,11 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
goto out;
}
+if (libxl__arch_domain_construct_memmap(gc, d_config, domid, &args)) {
+LOG(ERROR, "setting domain memory map failed");
+goto out;
+}
+
ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
&state->store_mfn, state->console_port,
&state->console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index ed2bd38..66b3d7f 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -438,6 +438,89 @@ int libxl__arch_domain_map_irq(libxl__gc *gc,
uint32_t domid, int irq)
}
/*
+ * Here we're just trying to set these kinds of e820 mappings:
+ *
+ * #1. Low memory region
+ *
+ * Low RAM starts at least from 1M to make sure all standard regions
+ * of the PC memory map, like BIOS, VGA memory-mapped I/O and vgabios,
+ * have enough space.
+ * Note: Those stuffs below 1M are still constructed with multiple
+ * e820 entries by hvmloader. At this point we don't change anything.
+ *
+ * #2. RDM region if it exists
+ *
+ * #3. High memory region if it exists
+ *
+ * Note: these regions are not overlapping since we already check
+ * to adjust them. Please refer to libxl__domain_device_construct_rdm().
+ */
+#define GUEST_LOW_MEM_START_DEFAULT 0x10
+int libxl__arch_domain_construct_memmap(libxl__gc *gc,
+libxl_domain_config *d_config,
+uint32_t domid,
+struct xc_hvm_build_args *args)
+{
...
Aside from that I have no issues with this patch.
But if you think I should resend this let me know.
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
Tiejun Chen writes ("[v7][PATCH 13/16] libxl: construct e820 map with RDM
information for HVM guest"):
> Here we'll construct a basic guest e820 table via
> XENMEM_set_memory_map. This table includes lowmem, highmem
> and RDMs if they exist, and hvmloader would need this info
> later.
>
> Note this guest e820 table would be same as before if the
> platform has no any RDM or we disable RDM (by default).
...
> tools/libxl/libxl_dom.c | 5 +++
> tools/libxl/libxl_internal.h | 24 +
> tools/libxl/libxl_x86.c | 83
>
...
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 62ef120..41da479 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -1004,6 +1004,11 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> goto out;
> }
>
> +if (libxl__domain_construct_e820(gc, d_config, domid, &args)) {
> +LOG(ERROR, "setting domain memory map failed");
> +goto out;
> +}
This is platform-independent code, isn't it ? In which case this will
break the build on ARM, I think.
Would an ARM maintainer please confirm.
Aside from that I have no issues with this patch.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
Here we'll construct a basic guest e820 table via
XENMEM_set_memory_map. This table includes lowmem, highmem
and RDMs if they exist, and hvmloader would need this info
later.
Note this guest e820 table would be same as before if the
platform has no any RDM or we disable RDM (by default).
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Acked-by: Wei Liu
Signed-off-by: Tiejun Chen
---
v7:
* Just sync with the fallout of renaming parameters from patch #10.
v6:
* Nothing is changed.
v5:
* Rephrase patch's short log
* Make libxl__domain_construct_e820() hidden
v4:
* Use goto style error handling.
* Instead of NOGC, we shoud use libxl__malloc(gc,XXX) to allocate local e820.
tools/libxl/libxl_dom.c | 5 +++
tools/libxl/libxl_internal.h | 24 +
tools/libxl/libxl_x86.c | 83
3 files changed, 112 insertions(+)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 62ef120..41da479 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1004,6 +1004,11 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
goto out;
}
+if (libxl__domain_construct_e820(gc, d_config, domid, &args)) {
+LOG(ERROR, "setting domain memory map failed");
+goto out;
+}
+
ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
&state->store_mfn, state->console_port,
&state->console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b4d8419..a50449a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3794,6 +3794,30 @@ static inline void libxl__update_config_vtpm(libxl__gc
*gc,
*/
void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
const libxl_bitmap *sptr);
+
+/*
+ * Here we're just trying to set these kinds of e820 mappings:
+ *
+ * #1. Low memory region
+ *
+ * Low RAM starts at least from 1M to make sure all standard regions
+ * of the PC memory map, like BIOS, VGA memory-mapped I/O and vgabios,
+ * have enough space.
+ * Note: Those stuffs below 1M are still constructed with multiple
+ * e820 entries by hvmloader. At this point we don't change anything.
+ *
+ * #2. RDM region if it exists
+ *
+ * #3. High memory region if it exists
+ *
+ * Note: these regions are not overlapping since we already check
+ * to adjust them. Please refer to libxl__domain_device_construct_rdm().
+ */
+_hidden int libxl__domain_construct_e820(libxl__gc *gc,
+ libxl_domain_config *d_config,
+ uint32_t domid,
+ struct xc_hvm_build_args *args);
+
#endif
/*
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index ed2bd38..68bd1d2 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -438,6 +438,89 @@ int libxl__arch_domain_map_irq(libxl__gc *gc, uint32_t
domid, int irq)
}
/*
+ * Here we're just trying to set these kinds of e820 mappings:
+ *
+ * #1. Low memory region
+ *
+ * Low RAM starts at least from 1M to make sure all standard regions
+ * of the PC memory map, like BIOS, VGA memory-mapped I/O and vgabios,
+ * have enough space.
+ * Note: Those stuffs below 1M are still constructed with multiple
+ * e820 entries by hvmloader. At this point we don't change anything.
+ *
+ * #2. RDM region if it exists
+ *
+ * #3. High memory region if it exists
+ *
+ * Note: these regions are not overlapping since we already check
+ * to adjust them. Please refer to libxl__domain_device_construct_rdm().
+ */
+#define GUEST_LOW_MEM_START_DEFAULT 0x10
+int libxl__domain_construct_e820(libxl__gc *gc,
+ libxl_domain_config *d_config,
+ uint32_t domid,
+ struct xc_hvm_build_args *args)
+{
+int rc = 0;
+unsigned int nr = 0, i;
+/* We always own at least one lowmem entry. */
+unsigned int e820_entries = 1;
+struct e820entry *e820 = NULL;
+uint64_t highmem_size =
+args->highmem_end ? args->highmem_end - (1ull << 32) : 0;
+
+/* Add all rdm entries. */
+for (i = 0; i < d_config->num_rdms; i++)
+if (d_config->rdms[i].policy != LIBXL_RDM_RESERVE_POLICY_INVALID)
+e820_entries++;
+
+
+/* If we should have a highmem range. */
+if (highmem_size)
+e820_entries++;
+
+if (e820_entries >= E820MAX) {
+LOG(ERROR, "Ooops! Too many entries in the memory map!\n");
+rc = ERROR_INVAL;
+goto out;
+}
+
+e820 = libxl__malloc(gc, sizeof(struct e820entry) * e820_entries);
+
+/* Low memory */
+e820[nr].addr = GUEST_LOW_MEM_START_DEFAULT;
+e820[nr].size = args->lowmem_end - GUEST_LOW_MEM_START_DEFAULT;
+e820[nr].type = E820_RAM;
+nr++;
+
+/* RDM ma
