Re: [PATCH v5 05/14] libxl: Load guest BIOS from file

[Anthony PERARD <anthony.perard@citrix.com>]

On Fri, Jun 24, 2016 at 01:23:19AM -0600, Jan Beulich wrote:
> >>> On 22.06.16 at 19:15, <anthony.perard@citrix.com> wrote:
> > --- a/tools/libxl/libxl_paths.c
> > +++ b/tools/libxl/libxl_paths.c
> > @@ -35,6 +35,16 @@ const char *libxl__run_dir_path(void)
> >      return XEN_RUN_DIR;
> >  }
> >  
> > +const char *libxl__seabios_path(void)
> > +{
> > +    return SEABIOS_PATH;
> > +}
> > +
> > +const char *libxl__ovmf_path(void)
> > +{
> > +    return OVMF_PATH;
> > +}
> 
> With an earlier version of this series pulled into one of our branches,
> I've run into a problem with this: The paths you return here are the
> configured paths, and that's intended. Yet it breaks running the
> tools out of the build area (i.e. without any "make install"), which so
> far has been working fine (as apparently in all other relevant cases
> where paths are needed, relative ones are being used), and which

I'm not sure that true about the relative paths, I think most, if not
all are full path and happen to match what is already install on the
system. I've tried to run xl from the build dir (and also dist dir) and
with a different --prefix, xl can not find qemu and if I run xl, this
time configure with the same --prefix and I remove hvmloader from my
system, xl can not find hvmloader.

You could copy both firmware manually to be in the same directory as
hvmloader. A better solution would be to use all the _override xl
config, I've added `bios_path_override' so one can supply a different
bios/firmware to libxl.

To be honest, I don't know which relative path to use since it depend on
where is xl executed from. And I don't think the path to the firmwares
(like hvmloader) can be change at execution time unless change for each
of them.

Is that answer your question?

> I much prefer over the hassle of scattering around half a dozen of
> different Xen tools versions in custom directories under, say,
> /usr/local. I guess if I'm the only one using this, I'll have to find my
> own local solution for this, but of course I'd prefer for this currently
> working case not to get broken.
> 
> Jan
> 

-- 
Anthony PERARD

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