Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for domain hotplug features

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 09 November 2015 10:50
> To: Andrew Cooper; Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Ian Campbell; Ian Jackson; Keir (Xen.org); Tim (Xen.org)
> Subject: RE: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for
> domain hotplug features
> 
> >>> On 09.11.15 at 10:51, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----Original Message-----
> >> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> >> Sent: 06 November 2015 18:08
> >> To: Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxxx
> >> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan Beulich
> >> Subject: Re: [Xen-devel] [PATCH 3/4] docs: Document xenstore paths for
> >> domain hotplug features
> >>
> >> On 06/11/15 17:21, Paul Durrant wrote:
> >> > Without some indication from an HVM domain it is not possible for a
> >> > toolstack to know whether instantiation of a new vbd or vif should
> >> > result in a new PV device of the appropriate type being instantiated
> >> > in a guest. (In other words whether PV drivers are present and
> >> > functioning).
> >> >
> >> > This patch document two paths which vif and vbd frontend drivers can
> >> > use to advertise their ability to respond to new vif or vbd
> >> > instantiations.
> >> >
> >> > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> >> > Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >> > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> >> > Cc: Jan Beulich <jbeulich@xxxxxxxx>
> >> > Cc: Keir Fraser <keir@xxxxxxx>
> >> > Cc: Tim Deegan <tim@xxxxxxx>
> >> > ---
> >> >  docs/misc/xenstore-paths.markdown | 12 ++++++++++++
> >> >  1 file changed, 12 insertions(+)
> >> >
> >> > diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-
> >> paths.markdown
> >> > index 7701632..9e98d6f 100644
> >> > --- a/docs/misc/xenstore-paths.markdown
> >> > +++ b/docs/misc/xenstore-paths.markdown
> >> > @@ -387,6 +387,18 @@ A domain writable path. Available for arbitrary
> >> domain use.
> >> >  A domain may write version information for PV driver $NAME using
> >> >  this path.
> >> >
> >> > +#### ~/feature/hotplug/vif = ("0"|"1") [w,HVM]
> >> > +
> >> > +An HVM domain can indicate to a toolstack that it is capable
> >> > +of responding to instantiation of a new vif by bringing online a
> >> > +new PV network device without the need for a reboot.
> >> > +
> >> > +#### ~/feature/hotplug/vbd = ("0"|"1") [w,HVM]
> >> > +
> >> > +An HVM domain can indicate to a toolstack that it is capable
> >> > +of responding to instantiation of a new vbd by bringing online a
> >> > +new PV block device without the need for a reboot.
> >>
> >> These flags are not inherently restricted to HVM guests.  Therefore, I
> >> would avoid specifying them as such.  (It is quite possible for a PV
> >> guest not to be able to hotplug a vbd for example.)
> >
> > I wasn't sure that was true. My belief was that all pure PV guests would
> > have frontends handling hot attach. I'm happy to drop the HVM tag in v2
> > though.
> 
> With intermediate steps between HVM and PVH planned to become
> possible, I think not overly limiting the scope of such entries would
> indeed desirable.
> 

Ok.

  Paul

> Jan


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