On 30 March 2017, at 18:49, Stefano Stabellini <sstabell...@kernel.org> 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.durr...@citrix.com>
>> ---
>> Cc: Andrew Cooper <andrew.coop...@citrix.com>
>> Cc: George Dunlap <george.dun...@eu.citrix.com>
>> Cc: Ian Jackson <ian.jack...@eu.citrix.com>
>> Cc: Jan Beulich <jbeul...@suse.com>
>> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
>> Cc: Stefano Stabellini <sstabell...@kernel.org>
>> Cc: Tim Deegan <t...@xen.org>
>> Cc: Wei Liu <wei.l...@citrix.com>
>> ---
>> 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
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
