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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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