I agree with you that non pass-through mode seems more applausive
here. One weak point then may be from dom0 Linux, but fortunately
upgrade to a newer base (Keir said about one month later) can make
things better.
For shared page stuff, as you said ACPI doesn't define it which just
cares the interfaces. How to implement ASL methods is platform/BIOS
specific. Here platform is constructed by Qemu and virtual BIOS is
cooperative to qemu. Thus you can define any short-circuit between
them, as long as not conflicting with others. :-)
Thanks,
Kevin
>From: Kamala Narasimhan
>Sent: Wednesday, October 15, 2008 12:40 AM
>
>Kevin,
>
>I understand your concerns. Pass-through battery management at its
>current state does have a narrow scope at the moment because of the
>nature of its implementation. A subset of CMBattery firmware
>implementation I studied does appear to use the command/data ports and
>battery commands as mimicked in our vACPI layer. But, if the trend
>doesn't continue, while we fine tune our vACPI layer to work with a
>broader range of laptops, we could use the non pass-through approach
>which is a sure bet approach on all laptops. I do expect non
>pass-through approach to be more widely used in the beginning before
>pass-through approach takes over.
>
>To answer your question pertaining to using shared page, though I like
>it, if feasible, we may be replacing one set of problem with another.
>Also, to my knowledge, ACPI or other relevant specification does not
>enforce any requirement on how/what shared pages or ports are used for
>battery management and is left to the discretion of the firmware
>implementor.
>
>Thanks,
>Kamala
>
>> -----Original Message-----
>> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
>> Sent: Tuesday, October 14, 2008 11:26 AM
>> To: Kamala Narasimhan; xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [xen-devel][PATCH] Battery Management
>>
>> >From: Kamala Narasimhan [mailto:Kamala.Narasimhan@xxxxxxxxxx]
>> >Sent: Tuesday, October 14, 2008 10:49 PM
>> >
>> >There isn't a whole range of VT-x enabled laptops I could get my
>hands
>> >on to better answer your question. However, given the current
>battery
>> >firmware implementation trend, the pass-through mode is likely to
>work
>> >on laptops that uses CMBattery interface. The goal was to
>attempt to
>> >put the base vACPI implementation that can be fine tuned as we go
>along
>> >to better support a whole range of VT-x enabled laptops shipped in
>> >future. That said, I have tested pass-through mode on the
>hardware I
>> >could get hold of (that uses CMBattery interface) and seen it work.
>> >
>> >Thanks,
>> >Kamala
>> >
>>
>> Yes, I can understand your point. It's natural to first have a simple
>> code to support basic functionality of most batteries, in
>pass-through
>> mode, and then later extend to more functions like _BTP. However
>> one point I'm not quite sure is about the port address. When _STA,
>> _BIF and _BST are enough which should be common interfaces for
>> all control method batteries, internal control interface may be
>different.
>> For example:
>> +// Battery command port - 0xb2
>> +// Batter data port - 0x86
>> +// Battery commands (written to port 0xb2) -
>> +// 0x7b - Battery operation init
>> +// 0x7c - Type of battery operation
>> +// 0x79 - Get battery data length
>> +// 0x7d - Get battery data
>>
>> Above internal logic may be specific to battery implementation:
>> - Port address may vary for different batteries, or
>> - Even worse, different command type is defined, or even different
>> interface (not a cmd/data pair) is developed
>>
>> For the first variation, maybe it's better to let Qemu pass actual
>> port being used, by either a dumb port or shared page instead of
>> hardcode. However I didn't see clean way for 2nd case. Per your
>> knowledge, is 2nd case possible? Is there any formal spec defining
>> such interface for all CMBatteries?
>>
>> Thanks,
>> Kevin
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home