Re: [Xen-devel] [PATCH 3/7] xen/hvm: Xen PV extension of HVMinitialization

From: Stefano Stabellini
Date: Wed Mar 03 2010 - 06:32:13 EST

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at