Re: [Xen-devel] [PATCH] [qemu] xen_be_init under stubdom

[Kamala Narasimhan <kamala.narasimhan@xxxxxxxxx>]

> I think it would be better if we actually return an error from
> xen_be_init and we just print a warning in hw/xen_machine_fv.c if the
> backends fail to initialize instead of exit.
> It is OK to just call exit in hw/xen_machine_pv.c, because nothing is
> running in qemu apart from backends in that case.
>

I did give it some thought and my rationale for returning success was
that we shouldn't be calling it in the first place if that code is not
configured to run in stubdom mode and if we do chose to go with the
call we should do nothing and return success.  But I didn't feel
strongly either way and I don't know much about pv/fv code in that
area and you know all about it.  So, I will go with your choice and
send a revised patch momentarily.

> Also having another #ifdef CONFIG_STUBDOM might be OK in qemu-xen, but
> in qemu upstream we can get away without it implementing a function
> like:
>
> int xen_qemu_is_a_stubdom();
>
> that returns 1 in case qemu is running in a stubdom and 0 otherwise.
> I would make domid_s a global int variable (see vl.c:5827) so that
> xen_qemu_is_a_stubdom can be implemented like this:
>
> return domid_s;
>

Definitely.  This patch is specific to qemu unstable and I should have
been specific.  If we didn't fail the way we do (in an irrelevant
place by corrupting something which was hard to debug) I wouldn't even
have bothered with this patch.  I will go per your suggestion for
upstream qemu.

Kamala

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