All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Sheng Yang <sheng@linux.intel.com>,
	Keir Fraser <Keir.Fraser@eu.citrix.com>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	Ian Pratt <Ian.Pratt@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/7] xen/hvm: Xen PV extension of  HVM initialization
Date: Wed, 3 Mar 2010 11:35:52 +0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1003031132550.4648@kaball-desktop> (raw)
In-Reply-To: <4B8D7248.5070807@goop.org>

On Tue, 2 Mar 2010, Jeremy Fitzhardinge wrote:
> On 03/02/2010 01:22 AM, Ian Campbell wrote:
> > On Tue, 2010-03-02 at 01:38 +0000, Sheng Yang wrote:
> >    
> >> A annoy thing in pv drivers is that it would test if the domain type
> >> is _NOT_ XEN_NATIVE. So set the domain to XEN_HVM_DOMAIN would result
> >> in PV driver initialization then probably panic.
> >>      
> > What _actually_ panics?
> >
> > Registration of the frontend devices should be completely harmless
> > (apart from a little wasted RAM) unless a xenbus driver manages to come
> > up and enumerate the xen bus and cause the ->probe function run.
> >
> > You should be gating the xenbus startup on the availability of PV
> > functionality not the individual driver registrations. This keeps the
> > test in a single easy to maintain place.
> >
> > Compare with pci_register_driver and all of the callers of that function
> > -- not a single one of them has an "is_pci_available" test anywhere.
> >    
> 
> The problem is that it currently assumes xenbus is initialized by the 
> time the PV drivers init, because in a PV boot xenbus gets initted very 
> early.  We need to change it so that it can cope with drivers being 
> initialized and registering with xenbus before it has been initialized.
> 
> We have the same problem with plain PV-on-HVM drivers as xenbus only 
> comes up as a result of probing the Xen PCI platform device, which may 
> be after the PV drivers' init functions have been called.

Give a look at the fourth patch of the series I just posted: it
introduces a simple driver for the Xen PCI platform device to initialize
xenbus and gran table later on when running in a HVM domain, at the same
time leaving the PV case as it is.



WARNING: multiple messages have this Message-ID (diff)
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>Jeremy,
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
	"linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>Stefano,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Ian Pratt <Ian.Pratt@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Keir Fraser <Keir.Fraser@eu.citrix.com>,
	Sheng Yang <sheng@linux.intel.com>
Subject: Re: [PATCH 3/7] xen/hvm: Xen PV extension of  HVM initialization
Date: Wed, 3 Mar 2010 11:35:52 +0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1003031132550.4648@kaball-desktop> (raw)
In-Reply-To: <4B8D7248.5070807@goop.org>

On Tue, 2 Mar 2010, Jeremy Fitzhardinge wrote:
> On 03/02/2010 01:22 AM, Ian Campbell wrote:
> > On Tue, 2010-03-02 at 01:38 +0000, Sheng Yang wrote:
> >    
> >> A annoy thing in pv drivers is that it would test if the domain type
> >> is _NOT_ XEN_NATIVE. So set the domain to XEN_HVM_DOMAIN would result
> >> in PV driver initialization then probably panic.
> >>      
> > What _actually_ panics?
> >
> > Registration of the frontend devices should be completely harmless
> > (apart from a little wasted RAM) unless a xenbus driver manages to come
> > up and enumerate the xen bus and cause the ->probe function run.
> >
> > You should be gating the xenbus startup on the availability of PV
> > functionality not the individual driver registrations. This keeps the
> > test in a single easy to maintain place.
> >
> > Compare with pci_register_driver and all of the callers of that function
> > -- not a single one of them has an "is_pci_available" test anywhere.
> >    
> 
> The problem is that it currently assumes xenbus is initialized by the 
> time the PV drivers init, because in a PV boot xenbus gets initted very 
> early.  We need to change it so that it can cope with drivers being 
> initialized and registering with xenbus before it has been initialized.
> 
> We have the same problem with plain PV-on-HVM drivers as xenbus only 
> comes up as a result of probing the Xen PCI platform device, which may 
> be after the PV drivers' init functions have been called.

Give a look at the fourth patch of the series I just posted: it
introduces a simple driver for the Xen PCI platform device to initialize
xenbus and gran table later on when running in a HVM domain, at the same
time leaving the PV case as it is.

  reply	other threads:[~2010-03-03 11:32 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-01  9:38 [PATCH 0/7][v4] PV extension of HVM (Hybrid) for Xen Sheng Yang
2010-03-01  9:38 ` [PATCH 1/7] xen: add support for hvm_op Sheng Yang
2010-03-01  9:38   ` Sheng Yang
2010-03-01  9:38 ` [PATCH 2/7] xen: Import cpuid.h from Xen Sheng Yang
2010-03-01  9:38 ` [PATCH 3/7] xen/hvm: Xen PV extension of HVM initialization Sheng Yang
2010-03-02  1:02   ` [Xen-devel] " Jeremy Fitzhardinge
2010-03-02  1:02     ` Jeremy Fitzhardinge
2010-03-02  1:38     ` [Xen-devel] " Sheng Yang
2010-03-02  1:38       ` Sheng Yang
2010-03-02  1:43       ` Jeremy Fitzhardinge
2010-03-02  9:22       ` Ian Campbell
2010-03-02 20:17         ` Jeremy Fitzhardinge
2010-03-02 20:17           ` Jeremy Fitzhardinge
2010-03-03 11:35           ` Stefano Stabellini [this message]
2010-03-03 11:35             ` Stefano Stabellini
2010-03-03 17:35             ` [Xen-devel] " Jeremy Fitzhardinge
2010-03-03 17:41               ` Stefano Stabellini
2010-03-03 17:41                 ` Stefano Stabellini
2010-03-04 10:18                 ` [Xen-devel] " Ian Campbell
2010-03-04 10:18                   ` Ian Campbell
2010-03-01  9:38 ` [PATCH 4/7] xen: The entrance for PV extension of HVM Sheng Yang
2010-03-02  1:05   ` [Xen-devel] " Jeremy Fitzhardinge
2010-03-02  1:41     ` Sheng Yang
2010-03-01  9:38 ` [PATCH 5/7] xen: Make event channel work with " Sheng Yang
2010-03-01  9:38   ` Sheng Yang
2010-03-02  1:38   ` [Xen-devel] " Jeremy Fitzhardinge
2010-03-02  5:48     ` Sheng Yang
2010-03-03 18:31       ` Jeremy Fitzhardinge
2010-03-04  5:37     ` Sheng Yang
2010-03-04  5:37       ` Sheng Yang
2010-03-04 11:58       ` [Xen-devel] " Stefano Stabellini
2010-03-04 11:58         ` Stefano Stabellini
2010-03-08 22:31         ` [Xen-devel] " Jeremy Fitzhardinge
2010-03-08 22:31           ` Jeremy Fitzhardinge
2010-03-01  9:38 ` [PATCH 6/7] xen: Unified checking for Xen of PV drivers to xenbus_register_frontend() Sheng Yang
2010-03-02  1:45   ` [Xen-devel] " Jeremy Fitzhardinge
2010-03-01  9:38 ` [PATCH 7/7] xen: Enable grant table and xenbus for PV extension of HVM Sheng Yang
2010-03-01 17:38   ` [LKML] " Konrad Rzeszutek Wilk
2010-03-01 17:38     ` Konrad Rzeszutek Wilk
2010-03-02  1:13     ` Sheng Yang
2010-03-02  1:13       ` Sheng Yang
2010-03-02  1:21     ` Sheng Yang
2010-03-02  1:21       ` Sheng Yang
2010-03-02 13:41       ` Konrad Rzeszutek Wilk
2010-03-02 14:09         ` Ian Campbell
2010-03-02 14:09           ` Ian Campbell
2010-03-02  0:42 ` [Xen-devel] [PATCH 0/7][v4] PV extension of HVM (Hybrid) for Xen Jeremy Fitzhardinge
2010-03-02  1:26   ` Sheng Yang
2010-03-02  1:32     ` Jeremy Fitzhardinge
2010-03-02  1:32       ` Jeremy Fitzhardinge
2010-03-02  1:34       ` [Xen-devel] " Sheng Yang
2010-03-02  3:20     ` Dong, Eddie
2010-03-02  3:20       ` Dong, Eddie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.1003031132550.4648@kaball-desktop \
    --to=stefano.stabellini@eu.citrix.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=Ian.Pratt@eu.citrix.com \
    --cc=Jeremy.Fitzhardinge@citrix.com \
    --cc=Keir.Fraser@eu.citrix.com \
    --cc=eddie.dong@intel.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sheng@linux.intel.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.