> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 09 November 2015 10:50 > To: Andrew Cooper; Paul Durrant; xen-de...@lists.xenproject.org > 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.durr...@citrix.com> wrote: > >> -----Original Message----- > >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > >> Sent: 06 November 2015 18:08 > >> To: Paul Durrant; xen-de...@lists.xenproject.org > >> 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.durr...@citrix.com> > >> > Cc: Ian Campbell <ian.campb...@citrix.com> > >> > Cc: Ian Jackson <ian.jack...@eu.citrix.com> > >> > Cc: Jan Beulich <jbeul...@suse.com> > >> > Cc: Keir Fraser <k...@xen.org> > >> > Cc: Tim Deegan <t...@xen.org> > >> > --- > >> > 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@lists.xen.org http://lists.xen.org/xen-devel
