[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1349272482.650.151.camel@zakaz.uk.xensource.com>
Date: Wed, 3 Oct 2012 14:54:42 +0100
From: Ian Campbell <Ian.Campbell@...rix.com>
To: Stefano Stabellini <Stefano.Stabellini@...citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct
for PV on HVM guests
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?
>
>
> > Perhaps turn this into a static inline with a BUG_ON(!xen_start_info) to
> > make catching these cases easier?
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists