On 30 March 2017, at 18:49, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
>
>
>On Thu, 30 Mar 2017, Paul Durrant wrote:
>> Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
>> added code to provide an 'laptop/slate mode' ACPI device to guests.
>>
>> When present this device is used by Microsoft Windows to bind a HID
>> driver which controls whether the Windows desktop appearance is optimized
>> for laptop/desktop or slate/tablet PCs. The mechanism for switching
>> between modes is to open a handle to this driver and write a byte of
>> arbitrary data.
>>
>> This patch documents xenstore keys such that a PV agent running in a
>> Windows guest can advertise the capability to, and receive instruction
>> from, a toolstack to cause such a mode switch.
>>
>> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
>> ---
>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
>> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>> Cc: Jan Beulich <jbeulich@xxxxxxxx>
>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>> Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>> Cc: Tim Deegan <tim@xxxxxxx>
>> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
>> ---
>> docs/misc/xenstore-paths.markdown | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown
>> index 5d89ed8..6c80a9e 100644
>> --- a/docs/misc/xenstore-paths.markdown
>> +++ b/docs/misc/xenstore-paths.markdown
>> @@ -435,6 +435,21 @@ XS_RESET_WATCHES xenstore message. See
>> [xen/include/public/io/xs\_wire.h][XSWIRE] for the XenStore wire
>> protocol definition.
>>
>> +#### ~/control/laptop-slate-mode = (""|"laptop"|"slate") [w]
>> +
>> +This is the PV laptop/slate mode control node. If the toolstack has
>> +provisioned a guest with the ACPI laptop/slate mode device then it
>> +can write the desired mode here to cause the guest to switch modes if
>> +necessary. The guest acknowledges a request by writing the empty
>> +string back to the control node.
>> +
>> +#### ~/control/feature-laptop-slate-mode = (""|"0"|"1") [w]
>> +
>> +This may be initialized to "" by the toolstack and may then be set
>> +to 0 or 1 by a guest to indicate whether it is capable or incapable,
>> +respectively, of responding to a mode value written to
>> +~/control/laptop-slate-mode.
>Usually, this is done by having the guest drivers write something like:
>feature-laptop-slate-mode
>to xenstore. The lack of the feature-* means no support is available.
>In fact, how is this supposed to work with old guest PV drivers that
>don't know about ~/control/feature-laptop-slate-mode? There won't be
>anybody to write "0" there, right?
The
toolstack
has
to write
this
first because
the
parent
control
key is
read
only to
the
guest.
Old guests
will
not write 0
so
the toolstack
does
not know
whether
the
guest can
handle
a command
written
to
control/laptop-slate-mode.
It
has to
apply
some form
of
timeout
in that
case.
This is
exactly
the
same as
with
any of
the
shutdown
features.
Paul
>> ### Domain Controlled Paths
>>
>> #### ~/data/* [w]
>> --
>> 2.1.4
>>
>
