Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 3 Oct 2012, Ian Campbell wrote:
> On Wed, 2012-10-03 at 17:13 +0100, Ian Campbell wrote:
> > On Wed, 2012-10-03 at 17:05 +0100, Stefano Stabellini wrote:
> > > On Wed, 3 Oct 2012, Ian Campbell wrote:
> > > > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote:
> > > > > On Wed, 3 Oct 2012, Ian Campbell wrote:
> > > > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote:
> > > > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote:
> > > > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote:
> > > > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote:
> > > > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote:
> > > > > > > > > > > PV on HVM guests don't have a start_info page mapped by 
> > > > > > > > > > > Xen, so
> > > > > > > > > > > xen_start_info is just NULL for them.
> > > > > > > > > > > That is problem because other parts of the code expect 
> > > > > > > > > > > xen_start_info to
> > > > > > > > > > > point to something valid, for example 
> > > > > > > > > > > xen_initial_domain() is defined as
> > > > > > > > > > > follow:
> > > > > > > > > > > 
> > > > > > > > > > > #define xen_initial_domain()    (xen_domain() && \
> > > > > > > > > > >                  xen_start_info->flags & SIF_INITDOMAIN)
> > > > > > > > > > 
> > > > > > > > > > But anyone who calls this before xen_start_info is setup is 
> > > > > > > > > > going to get
> > > > > > > > > > a bogus result, specifically in this case they will think 
> > > > > > > > > > they are domU
> > > > > > > > > > when in reality they are dom0 -- wouldn't it be better to 
> > > > > > > > > > fix those
> > > > > > > > > > callsites?
> > > > > > > > > 
> > > > > > > > > That cannot be the case because setting up xen_start_info is 
> > > > > > > > > the very
> > > > > > > > > first thing that is done, before even calling to C.
> > > > > > > > 
> > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no?
> > > > > > > > 
> > > > > > > > Otherwise if this is always set before calling into C then what 
> > > > > > > > is the
> > > > > > > > purpose of this patch?
> > > > > > > 
> > > > > > > to fix this - as PVHVM has it set to NULL and we end up 
> > > > > > > de-referencing
> > > > > > > the xen_start_info and crashing. As so::
> > > > > > > 
> > > > > > 
> > > > > > Right, so returning to my original point: The caller here is calling
> > > > > > xen_initial_domain() *before* start info is setup. This is bogus 
> > > > > > and is
> > > > > > your actual bug, all this patch does is hide that real issue.
> > > > > 
> > > > > That is because xen_start_info wasn't setup at all for PV on HVM 
> > > > > guests.
> > > > > 
> > > > > The real reason is that PV on HVM guests don't have one, but that is
> > > > > another matter. Until we get rid of all the references to 
> > > > > xen_start_info
> > > > > outside of PV specific code, we should just assume that there is one,
> > > > > and that is already setup.
> > > > > 
> > > > > One day not too far from now, we might refactor the code to never
> > > > > reference xen_start_info directly, but I don't think that now is the
> > > > > time for that. Also consider that this is the same thing we do on ARM.
> > > > 
> > > > We actual fill in the dummy start info with valid information on ARM
> > > > though, we don't just leave it full of zeroes.
> > > > 
> > > > If we do start out with start_info pointing to an uninitialised
> > > > start_info on ARM too then I would argue that this is also a mistake.
> > > 
> > > Yes, we do point xen_start_info to an uninitialised start_info on ARM
> > > too (I don't think is a mistake). Then when and if we have more
> > > information we write them to start_info.
> > 
> > So callers of xen_initial_domain in dom0 before xen_guest_init is called
> > get the wrong result?
> > 
> > That sounds like a mistake to me.
> 
> How about (modulo my not having looked up the actual names of the
> constants etc):
> 
>       #define xen_initial_domain() (xen_domain() && arch_is_initial_domain())
> 
> on x86:
>       int arch_is_initial_domain(void)
>       {
>               /* The initial domain is always PV and
>                * therefore start_info is always set for it.
>                */
>               return start_info && start_info->flags & SIF_INITDOMAIN;
>       }
> on ARM:
>       int arch_is_initial_domain(void)
>       {
>               static is_initial = -1;
>               if (is_initial == -1)
>                       is_initial = HVM_param_get(HVMPARAM_DOM0)
>               return is_initial;
>       }

What about the appended patch as a fix for the moment, then we can do
the refactoring that you are suggesting, that is very similar to what I
had in mind when I said that we shouldn't access xen_start_info
directly.

---

xen/xen_initial_domain: check that xen_start_info is initialized

Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm:
initial Xen support") PV on HVM guests can be xen_initial_domain.
However PV on HVM guests might have an unitialized xen_start_info, so
check before accessing its fields.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

diff --git a/include/xen/xen.h b/include/xen/xen.h
index 9a39ca5..e7101bb 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type;
 #include <asm/xen/hypervisor.h>
 
 #define xen_initial_domain()   (xen_domain() && \
-                                xen_start_info->flags & SIF_INITDOMAIN)
+                                xen_start_info && xen_start_info->flags & 
SIF_INITDOMAIN)
 #else  /* !CONFIG_XEN_DOM0 */
 #define xen_initial_domain()   (0)
 #endif /* CONFIG_XEN_DOM0 */

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