[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 10/23] xen/arm: compile and run xenbus



On Wed, 8 Aug 2012, Daniel De Graaf wrote:
> On 08/08/2012 01:19 PM, Stefano Stabellini wrote:
> > On Wed, 8 Aug 2012, Daniel De Graaf wrote:
> >> On 08/08/2012 12:51 PM, Stefano Stabellini wrote:
> >>> On Tue, 7 Aug 2012, Daniel De Graaf wrote:
> >>>> On 08/07/2012 02:21 PM, Konrad Rzeszutek Wilk wrote:
> >>>>> On Mon, Aug 06, 2012 at 03:27:13PM +0100, Stefano Stabellini wrote:
> >>>>>> bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> >>>>>> an error.
> >>>>>>
> >>>>>> If Linux is running as an HVM domain and is running as Dom0, use
> >>>>>> xenstored_local_init to initialize the xenstore page and event channel.
> >>>>>>
> >>>>>> Changes in v2:
> >>>>>>
> >>>>>> - refactor xenbus_init.
> >>>>>
> >>>>> Thank you. Lets also CC our friend at NSA who has been doing some work
> >>>>> in that area. Daniel are you OK with this change - will it still make
> >>>>> PV initial domain with with the MiniOS XenBus driver?
> >>>>>
> >>>>> Thanks.
> >>>>
> >>>> That case will work, but what this will break is launching the initial 
> >>>> domain
> >>>> with a Xenstore stub domain already running (see below).
> >>>>
> >>>>>>
> >>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> >>>>>> ---
> >>>>>>  drivers/xen/xenbus/xenbus_comms.c |    2 +-
> >>>>>>  drivers/xen/xenbus/xenbus_probe.c |   62 
> >>>>>> +++++++++++++++++++++++++-----------
> >>>>>>  drivers/xen/xenbus/xenbus_xs.c    |    1 +
> >>>>>>  3 files changed, 45 insertions(+), 20 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/xen/xenbus/xenbus_comms.c 
> >>>>>> b/drivers/xen/xenbus/xenbus_comms.c
> >>>>>> index 52fe7ad..c5aa55c 100644
> >>>>>> --- a/drivers/xen/xenbus/xenbus_comms.c
> >>>>>> +++ b/drivers/xen/xenbus/xenbus_comms.c
> >>>>>> @@ -224,7 +224,7 @@ int xb_init_comms(void)
> >>>>>>                int err;
> >>>>>>                err = bind_evtchn_to_irqhandler(xen_store_evtchn, 
> >>>>>> wake_waiting,
> >>>>>>                                                0, "xenbus", &xb_waitq);
> >>>>>> -              if (err <= 0) {
> >>>>>> +              if (err < 0) {
> >>>>>>                        printk(KERN_ERR "XENBUS request irq failed 
> >>>>>> %i\n", err);
> >>>>>>                        return err;
> >>>>>>                }
> >>>>>
> >>>>>> diff --git a/drivers/xen/xenbus/xenbus_probe.c 
> >>>>>> b/drivers/xen/xenbus/xenbus_probe.c
> >>>>>> index b793723..a67ccc0 100644
> >>>>>> --- a/drivers/xen/xenbus/xenbus_probe.c
> >>>>>> +++ b/drivers/xen/xenbus/xenbus_probe.c
> >>>>>> @@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
> >>>>>>        return err;
> >>>>>>  }
> >>>>>>  
> >>>>>> +enum xenstore_init {
> >>>>>> +      UNKNOWN,
> >>>>>> +      PV,
> >>>>>> +      HVM,
> >>>>>> +      LOCAL,
> >>>>>> +};
> >>>>>>  static int __init xenbus_init(void)
> >>>>>>  {
> >>>>>>        int err = 0;
> >>>>>> +      enum xenstore_init usage = UNKNOWN;
> >>>>>> +      uint64_t v = 0;
> >>>>>>  
> >>>>>>        if (!xen_domain())
> >>>>>>                return -ENODEV;
> >>>>>>  
> >>>>>>        xenbus_ring_ops_init();
> >>>>>>  
> >>>>>> -      if (xen_hvm_domain()) {
> >>>>>> -              uint64_t v = 0;
> >>>>>> -              err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> >>>>>> -              if (err)
> >>>>>> -                      goto out_error;
> >>>>>> -              xen_store_evtchn = (int)v;
> >>>>>> -              err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> >>>>>> -              if (err)
> >>>>>> -                      goto out_error;
> >>>>>> -              xen_store_mfn = (unsigned long)v;
> >>>>>> -              xen_store_interface = ioremap(xen_store_mfn << 
> >>>>>> PAGE_SHIFT, PAGE_SIZE);
> >>>>>> -      } else {
> >>>>>> -              xen_store_evtchn = xen_start_info->store_evtchn;
> >>>>>> -              xen_store_mfn = xen_start_info->store_mfn;
> >>>>>> -              if (xen_store_evtchn)
> >>>>>> -                      xenstored_ready = 1;
> >>>>>> -              else {
> >>>>>> +      if (xen_pv_domain())
> >>>>>> +              usage = PV;
> >>>>>> +      if (xen_hvm_domain())
> >>>>>> +              usage = HVM;
> >>>>
> >>>> The above is correct for domUs, and is overridden for dom0s:
> >>>>
> >>>>>> +      if (xen_hvm_domain() && xen_initial_domain())
> >>>>>> +              usage = LOCAL;
> >>>>>> +      if (xen_pv_domain() && !xen_start_info->store_evtchn)
> >>>>>> +              usage = LOCAL;
> >>>>
> >>>> Instead of these checks, I think it should just be:
> >>>>
> >>>> if (!xen_start_info->store_evtchn)
> >>>>  usage = LOCAL;
> >>>>
> >>>> Any domain started after xenstore will have store_evtchn set, so if you 
> >>>> don't
> >>>> have this set, you are either going to be running xenstore locally, or 
> >>>> will
> >>>> use the ioctl to change it later (and so should still set up everything 
> >>>> as if
> >>>> it will be running locally).
> >>>
> >>> That would be wrong for an HVM dom0 domain (at least on ARM), because
> >>> we don't have a start_info page at all.
> >>>
> >>>
> >>>>>> +      if (xen_pv_domain() && xen_start_info->store_evtchn)
> >>>>>> +              xenstored_ready = 1;
> >>>>
> >>>> This part can now just be moved unconditionally into case PV.
> >>>
> >>> What about:
> >>>
> >>> if (xen_pv_domain())
> >>>     usage = PV;
> >>> if (xen_hvm_domain())
> >>>     usage = HVM;
> >>> if (!xen_store_evtchn)
> >>>     usage = LOCAL;
> >>>
> >>> and moving xenstored_ready in case PV, like you suggested.
> >>>
> >>
> >> That looks correct, but you'd need to split up the switch statement in
> >> order to populate xen_store_evtchn before that last condition, which
> >> ends up pretty much eliminating the usage variable.
> > 
> > Going back to what you wrote in the previous email, in what way this
> > patch breaks the case when an initial domain is started after a Xenstore
> > stub domain?
> > 
> > Assuming that we are talking about a PV initial domain on x86, the
> > following check
> > 
> > if (xen_pv_domain() && !xen_start_info->store_evtchn)
> >     usage = LOCAL;
> > 
> > will return false (because store_evtchn is set), therefore usage will
> > remain set to PV.
> > And the check:
> > 
> > if (xen_pv_domain() && xen_start_info->store_evtchn)
> >     xenstored_ready = 1;
> > 
> > will return true so xenstored_ready is going to be set to 1.
> > 
> 
> Right, the original patch didn't break anything with PV domains. The case
> it doesn't handle is an HVM initial domain with an already-running
> Xenstore domain; I think this applies both to ARM and hybrid/PVH on x86.
> In that case, usage would be set to LOCAL instead of HVM.


Right, however if I am not mistaken there is no such thing as an HVM
dom0 right now on x86 and hybrid/PVH is probably going to return true on
xen_pv_domain() and false on xen_hvm_domain().

In the ARM case, given that we don't have a start_info page, we would
need another way to figure out whether a xenstore stub domain is already
running, so I think we can just postpone the solution of that problem
for now.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.