Mailing List Archive

> +static int arch_setup_middle(struct xc_dom_image *dom)
> +{
> DECLARE_DOMCTL;
> int rc;
>
> @@ -268,16 +280,35 @@ static int arch_setup_early(struct xc_do
> domctl.cmd = XEN_DOMCTL_arch_setup;
> domctl.domain = dom->guest_domid;
> domctl.u.arch_setup.flags = 0;
> +
> + /* dom->start_info_pfn should be initialized by alloc_magic_pages().
> + * However it is called later. So we initialize here.
> + */
> + dom->start_info_pfn = dom->total_pages - 3;

Is it an option to call arch_setup_middle as one of the first things in
xc_dom_boot_image()? That would avoid the start_info_pfn trickery ...

The only thing which happens between the current and the suggested place
is that domU pages are mapped and data is copyed to them. No other
hypercalls.

If that works out we might consider giving some more desciptive names to
the arch hooks, such as "arch_setup_{meminit,bootearly,bootlate}" or so.

cheers,
Gerd

--
Gerd Hoffmann <kraxel@suse.de>

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

On Tue, Jan 30, 2007 at 03:06:36PM +0100, Gerd Hoffmann wrote:
> > +static int arch_setup_middle(struct xc_dom_image *dom)
> > +{
> > DECLARE_DOMCTL;
> > int rc;
> >
> > @@ -268,16 +280,35 @@ static int arch_setup_early(struct xc_do
> > domctl.cmd = XEN_DOMCTL_arch_setup;
> > domctl.domain = dom->guest_domid;
> > domctl.u.arch_setup.flags = 0;
> > +
> > + /* dom->start_info_pfn should be initialized by alloc_magic_pages().
> > + * However it is called later. So we initialize here.
> > + */
> > + dom->start_info_pfn = dom->total_pages - 3;
>
> Is it an option to call arch_setup_middle as one of the first things in
> xc_dom_boot_image()? That would avoid the start_info_pfn trickery ...
>
> The only thing which happens between the current and the suggested place
> is that domU pages are mapped and data is copyed to them. No other
> hypercalls.
>
> If that works out we might consider giving some more desciptive names to
> the arch hooks, such as "arch_setup_{meminit,bootearly,bootlate}" or so.

XEN_DOMCTL_arch_setup hypercall sets up EFI memory map,
xen-faked EFI firmware and etc. So it should be called before
loading kernel/initrd images.
Presumably such setting should be loader specific.
How about adding new methods like setup_meminit, setup_firmware, setup_boot
(Or please suggest better names.) to struct xc_dom_loader?
And call setup_meminit at xc_dom_boot_mem_init(),
setup_firmware at the beginning of xc_dom_build_image(),
setup_boot at xc_dom_boot_image().

--
yamahata

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

Isaku Yamahata wrote:
> XEN_DOMCTL_arch_setup hypercall sets up EFI memory map,
> xen-faked EFI firmware and etc. So it should be called before
> loading kernel/initrd images.

Why is this order important?

> How about adding new methods like setup_meminit, setup_firmware, setup_boot
> (Or please suggest better names.) to struct xc_dom_loader?

Certainly not to "struct xc_dom_loader", that one is for binary formats
such as ELF and thus architecture-independant.

Maybe we could put that into "struct xc_dom_arch". I've intentionally
tried to keep the code which does hypercalls separately though.

> And call setup_meminit at xc_dom_boot_mem_init(),
> setup_firmware at the beginning of xc_dom_build_image(),
> setup_boot at xc_dom_boot_image().

Only the xc_dom_boot_*() functions are supposed to invoke hypercalls.
Thus the firmware setup can happen either at the end of
xc_dom_boot_mem_init or at the start of xc_dom_boot_image.

cheers,

Gerd

--
Gerd Hoffmann <kraxel@suse.de>

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