xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH v5 01/14] libxc: Rework extra module initialisation
Date: Thu, 7 Jul 2016 15:55:23 +0100	[thread overview]
Message-ID: <20160707145523.GO416@citrix.com> (raw)
In-Reply-To: <20160622171545.5304-2-anthony.perard@citrix.com>

On Wed, Jun 22, 2016 at 06:15:32PM +0100, Anthony PERARD wrote:
> This patch use xc_dom_alloc_segment() to allocate the memory space for the
> ACPI modules and the SMBIOS modules. This is to replace the arbitrary
> placement of 1MB (+ extra for MB alignement) after the hvmloader image.
> 
> This patch can help if one add extra ACPI table and hvmloader contain
> OVMF (OVMF is a 2MB binary), as in that case the extra ACPI table could
> easily be loaded past the address 4MB, but hvmloader use a range of
> memory from 4MB to 10MB to perform tests and in the process, clears the
> memory, before loading the modules.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> Changes in V5:
> - rewrite patch description
> 
> Changes in V4:
> - check that guest_addr_out have a reasonable value.
> 
> New patch in V3.
> ---
>  tools/libxc/xc_dom_hvmloader.c | 131 ++++++++++++-----------------------------
>  1 file changed, 38 insertions(+), 93 deletions(-)
> 
> diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
> index 330d5e8..da8b995 100644
> --- a/tools/libxc/xc_dom_hvmloader.c
> +++ b/tools/libxc/xc_dom_hvmloader.c
> @@ -129,98 +129,52 @@ static elf_errorstatus xc_dom_parse_hvm_kernel(struct xc_dom_image *dom)
>      return rc;
>  }
>  
> -static int modules_init(struct xc_dom_image *dom,
> -                        uint64_t vend, struct elf_binary *elf,
> -                        uint64_t *mstart_out, uint64_t *mend_out)
> +static int module_init_one(struct xc_dom_image *dom,
> +                           struct xc_hvm_firmware_module *module,
> +                           char *name)
>  {
> -#define MODULE_ALIGN 1UL << 7
> -#define MB_ALIGN     1UL << 20
> -#define MKALIGN(x, a) (((uint64_t)(x) + (a) - 1) & ~(uint64_t)((a) - 1))
> -    uint64_t total_len = 0, offset1 = 0;
> +    struct xc_dom_seg seg;
> +    void *dest;
>  
> -    if ( dom->acpi_module.length == 0 && dom->smbios_module.length == 0 )
> -        return 0;
> -
> -    /* Find the total length for the firmware modules with a reasonable large
> -     * alignment size to align each the modules.
> -     */
> -    total_len = MKALIGN(dom->acpi_module.length, MODULE_ALIGN);
> -    offset1 = total_len;
> -    total_len += MKALIGN(dom->smbios_module.length, MODULE_ALIGN);
> -
> -    /* Want to place the modules 1Mb+change behind the loader image. */
> -    *mstart_out = MKALIGN(elf->pend, MB_ALIGN) + (MB_ALIGN);
> -    *mend_out = *mstart_out + total_len;
> -
> -    if ( *mend_out > vend )
> -        return -1;
> -
> -    if ( dom->acpi_module.length != 0 )
> -        dom->acpi_module.guest_addr_out = *mstart_out;
> -    if ( dom->smbios_module.length != 0 )
> -        dom->smbios_module.guest_addr_out = *mstart_out + offset1;
> +    if ( module->length )
> +    {
> +        if ( xc_dom_alloc_segment(dom, &seg, name, 0, module->length) )
> +            goto err;
> +        dest = xc_dom_seg_to_ptr(dom, &seg);
> +        if ( dest == NULL )
> +        {
> +            DOMPRINTF("%s: xc_dom_seg_to_ptr(dom, &seg) => NULL",
> +                      __FUNCTION__);
> +            goto err;
> +        }
> +        memcpy(dest, module->data, module->length);
> +        module->guest_addr_out = seg.vstart;
> +        if ( module->guest_addr_out > UINT32_MAX ||
> +             module->guest_addr_out + module->length > UINT32_MAX )
> +        {
> +            DOMPRINTF("%s: Module %s would be loaded abrove 4GB",
> +                      __FUNCTION__, name);
> +            goto err;
> +        }

One question:

Can this check also account for MMIO hole below 4G? Maybe use
dom->mmio_size?

Other than this, this patch looks good.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-07-07 14:55 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-22 17:15 [PATCH v5 00/14] Load BIOS via toolstack instead of been embedded in hvmloader Anthony PERARD
2016-06-22 17:15 ` [PATCH v5 01/14] libxc: Rework extra module initialisation Anthony PERARD
2016-07-07 14:55   ` Wei Liu [this message]
2016-07-08 10:52     ` Anthony PERARD
2016-07-08 11:29       ` Wei Liu
2016-07-08 13:26         ` Anthony PERARD
2016-06-22 17:15 ` [PATCH v5 02/14] libxc: Prepare a start info structure for hvmloader Anthony PERARD
2016-06-23 14:44   ` Boris Ostrovsky
2016-06-23 16:52     ` Anthony PERARD
2016-07-07 14:55   ` Wei Liu
2016-07-08 10:55     ` Anthony PERARD
2016-06-22 17:15 ` [PATCH v5 03/14] configure: #define SEABIOS_PATH and OVMF_PATH Anthony PERARD
2016-06-22 17:15 ` [PATCH v5 04/14] firmware/makefile: install BIOS blob Anthony PERARD
2016-07-07 14:55   ` Wei Liu
2016-06-22 17:15 ` [PATCH v5 05/14] libxl: Load guest BIOS from file Anthony PERARD
2016-06-24  7:23   ` Jan Beulich
2016-06-24 14:20     ` Anthony PERARD
2016-07-07 14:55   ` Wei Liu
2016-06-22 17:15 ` [PATCH v5 06/14] xen: Move the hvm_start_info C representation from libxc to public/xen.h Anthony PERARD
2016-07-07 14:55   ` Wei Liu
2016-07-07 15:07     ` Jan Beulich
2016-07-07 15:28       ` Wei Liu
2016-07-08  9:53         ` Julien Grall
2016-07-07 15:02   ` Andrew Cooper
2016-07-07 15:09     ` Jan Beulich
2016-07-07 15:12       ` Andrew Cooper
2016-06-22 17:15 ` [PATCH v5 07/14] hvmloader: Grab the hvm_start_info pointer Anthony PERARD
2016-06-22 17:15 ` [PATCH v5 08/14] hvmloader: Locate the BIOS blob Anthony PERARD
2016-06-24  7:33   ` Jan Beulich
2016-06-24 17:02     ` Anthony PERARD
2016-06-27  7:13       ` Jan Beulich
2016-06-30 15:04         ` Anthony PERARD
2016-07-01  6:40           ` Jan Beulich
2016-06-22 17:15 ` [PATCH v5 09/14] hvmloader: Check modules whereabouts in perform_tests Anthony PERARD
2016-06-24  7:44   ` Jan Beulich
2016-06-24 17:14     ` Anthony PERARD
2016-06-27  7:20       ` Jan Beulich
2016-06-22 17:15 ` [PATCH v5 10/14] hvmloader: Load SeaBIOS from hvm_start_info modules Anthony PERARD
2016-06-24  7:46   ` Jan Beulich
2016-06-22 17:15 ` [PATCH v5 11/14] hvmloader: Load OVMF from modules Anthony PERARD
2016-06-22 17:15 ` [PATCH v5 12/14] hvmloader: bios->bios_load() now needs to be defined Anthony PERARD
2016-06-22 17:15 ` [PATCH v5 13/14] hvmloader: Always build-in SeaBIOS and OVMF loader Anthony PERARD
2016-06-22 17:15 ` [PATCH v5 14/14] configure: do not depend on SEABIOS_PATH or OVMF_PATH Anthony PERARD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160707145523.GO416@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).