lkml.org 
[lkml]   [2010]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Xen-devel] [PATCH 3/7] xen/hvm: Xen PV extension of HVM initialization
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.




\
 
 \ /
  Last update: 2010-03-03 12:35    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site