Attached is the initial battery management patch. This patch covers the virtual firmware and tool stack changes and will be followed by a qemu patch and a xen power management daemon patch. Signed-off-by: Kamala Narasimhan <kamala.narasimhan@citrix.com> Thanks, Kamala _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Kamala Narasimhan >Sent: Tuesday, October 14, 2008 9:37 AM > >Attached is the initial battery management patch. This patch >covers the >virtual firmware and tool stack changes and will be followed by a qemu >patch and a xen power management daemon patch. > >Signed-off-by: Kamala Narasimhan <kamala.narasimhan@citrix.com> >I''m not sure whether I fully understand "pass-through" mode and "non pass-through" mode. I guess "pass-through" mode means exposing real battery to HVM, while "non pass-through" mode contructs a virtual battery (as in your current patch) and then let another xen specific daemon to convert virtual battery ops into real ones. If I understand correctly, your current implementation only targets for "non pass-through" mode. Then do you plan to support the other, which is more difficult as you may need merge part of real ACPI table with virtual ones... Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sorry that I didn''t read your patch carefully which describes the purpose clearly. Just one question is, how confident are you for the commonality of ''underlying firmware'' you borrowed, regarding port address, and port funcion? If moving to a different battery sub-system, does it still appy to or you need hard-code new set of interface into vACPI? :-) Thanks, Kevin>From:Tian, Kevin >Sent: Tuesday, October 14, 2008 12:25 PM > >>From: Kamala Narasimhan >>Sent: Tuesday, October 14, 2008 9:37 AM >> >>Attached is the initial battery management patch. This patch >>covers the >>virtual firmware and tool stack changes and will be followed by a qemu >>patch and a xen power management daemon patch. >> >>Signed-off-by: Kamala Narasimhan <kamala.narasimhan@citrix.com> >> > >I''m not sure whether I fully understand "pass-through" mode and >"non pass-through" mode. I guess "pass-through" mode means >exposing real battery to HVM, while "non pass-through" mode >contructs a virtual battery (as in your current patch) and then let >another xen specific daemon to convert virtual battery ops into >real ones. If I understand correctly, your current implementation >only targets for "non pass-through" mode. Then do you plan to >support the other, which is more difficult as you may need merge >part of real ACPI table with virtual ones... > >Thanks, >Kevin > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Tian, Kevin > Sent: Tuesday, October 14, 2008 4:57 AM > To: Tian, Kevin; Kamala Narasimhan; xen-devel@lists.xensource.com > Subject: RE: [xen-devel][PATCH] Battery Management > > Sorry that I didn''t read your patch carefully which describes > the purpose clearly. Just one question is, how confident are > you for the commonality of ''underlying firmware'' you borrowed, > regarding port address, and port funcion? If moving to a > different battery sub-system, does it still appy to or you need > hard-code new set of interface into vACPI? :-) > > Thanks, > Kevin > > >From:Tian, Kevin > >Sent: Tuesday, October 14, 2008 12:25 PM > > > >>From: Kamala Narasimhan > >>Sent: Tuesday, October 14, 2008 9:37 AM > >> > >>Attached is the initial battery management patch. This patch > >>covers the > >>virtual firmware and tool stack changes and will be followed by aqemu> >>patch and a xen power management daemon patch. > >> > >>Signed-off-by: Kamala Narasimhan <kamala.narasimhan@citrix.com> > >> > > > >I''m not sure whether I fully understand "pass-through" mode and > >"non pass-through" mode. I guess "pass-through" mode means > >exposing real battery to HVM, while "non pass-through" mode > >contructs a virtual battery (as in your current patch) and then let > >another xen specific daemon to convert virtual battery ops into > >real ones. If I understand correctly, your current implementation > >only targets for "non pass-through" mode. Then do you plan to > >support the other, which is more difficult as you may need merge > >part of real ACPI table with virtual ones... > > > >Thanks, > >Kevin > > > >_______________________________________________ > >Xen-devel mailing list > >Xen-devel@lists.xensource.com > >http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kamala Narasimhan writes ("RE: [xen-devel][PATCH] Battery
Management"):> 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.
I''m obviously missing something obvious here. I wasn''t able
to easily
find out what `CMBattery'' is (perhaps I need to read a suitable volume
of ACPI spec) but laptops have been having ACPI-based battery
management for quite a while.
You mention a shortage of VT-x enabled laptops but a quick websearch
suggests there are plenty of AMD-V-capable laptops.
Dare I ask, what about PV guests ? Obviously access to the host
battery is not supported for right now but what is the plan ?
Sorry if these seem like stupid questions.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> You mention a shortage of VT-x enabled laptops but a quick websearch > suggests there are plenty of AMD-V-capable laptops.It is not so much a shortage of VT-x capable laptops in general but rather a shortage of ones available for us to test with. Thanks Ross -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ian Jackson Sent: Tuesday, October 14, 2008 11:05 AM To: Kamala Narasimhan Cc: Tian, Kevin; xen-devel@lists.xensource.com Subject: RE: [xen-devel][PATCH] Battery Management Kamala Narasimhan writes ("RE: [xen-devel][PATCH] Battery Management"):> 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 goalong> 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.I''m obviously missing something obvious here. I wasn''t able to easily find out what `CMBattery'' is (perhaps I need to read a suitable volume of ACPI spec) but laptops have been having ACPI-based battery management for quite a while. You mention a shortage of VT-x enabled laptops but a quick websearch suggests there are plenty of AMD-V-capable laptops. Dare I ask, what about PV guests ? Obviously access to the host battery is not supported for right now but what is the plan ? Sorry if these seem like stupid questions. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Kamala Narasimhan [mailto:Kamala.Narasimhan@citrix.com] >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@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Ian Jackson >Sent: Tuesday, October 14, 2008 11:05 PM > >Kamala Narasimhan writes ("RE: [xen-devel][PATCH] Battery Management"): >> 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. > >I''m obviously missing something obvious here. I wasn''t able to easily >find out what `CMBattery'' is (perhaps I need to read a suitable volume >of ACPI spec) but laptops have been having ACPI-based battery >management for quite a while.ACPI spec defines two types of batteriers: smart battery and control method battery. Smart battery is controlled by embedded controller, while the latter provides full ACPI control methods to OSPM.> >You mention a shortage of VT-x enabled laptops but a quick websearch >suggests there are plenty of AMD-V-capable laptops. > >Dare I ask, what about PV guests ? Obviously access to the host >battery is not supported for right now but what is the plan ?For PV guests it''s more tough question, as no ACPI is supported in PV guest by far. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Kamala Narasimhan writes ("RE: [xen-devel][PATCH] BatteryManagement"):> > There isn''t a whole range of VT-x enabled laptops I could get myhands> > on to better answer your question. However, given the currentbattery> > firmware implementation trend, the pass-through mode is likely towork> > on laptops that uses CMBattery interface. The goal was to attemptto> > put the base vACPI implementation that can be fine tuned as we goalong> > to better support a whole range of VT-x enabled laptops shipped in > > future. That said, I have tested pass-through mode on the hardwareI> > could get hold of (that uses CMBattery interface) and seen it work. > > I''m obviously missing something obvious here. I wasn''t able to easily > find out what `CMBattery'' is (perhaps I need to read a suitable volume > of ACPI spec) but laptops have been having ACPI-based battery > management for quite a while.Yes, ACPI-based battery management has been there for a while. Otherwise, it wouldn''t have been possible to study battery firmware implementation trend setting aside the virtualization factor.> > You mention a shortage of VT-x enabled laptops but a quick websearch > suggests there are plenty of AMD-V-capable laptops.Virtualization enabled laptops and virtualization enabled laptops that I could get my hands on are two different things :-) Anyway, only recently have I been focusing on battery/laptop specific implementation; so this shouldn''t be an issue in the long run.> > Dare I ask, what about PV guests ? Obviously access to the host > battery is not supported for right now but what is the plan ?I haven''t given it much thought but I would be happy to work with anyone keen to see this in PV guests although there is the ACPI support issue Kevin mentioned in his email.> Sorry if these seem like stupid questions.Not at all. Thanks, Kamala _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@intel.com] > Sent: Tuesday, October 14, 2008 11:26 AM > To: Kamala Narasimhan; xen-devel@lists.xensource.com > Subject: RE: [xen-devel][PATCH] Battery Management > > >From: Kamala Narasimhan [mailto:Kamala.Narasimhan@citrix.com] > >Sent: Tuesday, October 14, 2008 10:49 PM > > > >There isn''t a whole range of VT-x enabled laptops I could get myhands> >on to better answer your question. However, given the currentbattery> >firmware implementation trend, the pass-through mode is likely towork> >on laptops that uses CMBattery interface. The goal was to attempt to > >put the base vACPI implementation that can be fine tuned as we goalong> >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 bedifferent.> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@intel.com] >> Sent: Tuesday, October 14, 2008 11:26 AM >> To: Kamala Narasimhan; xen-devel@lists.xensource.com >> Subject: RE: [xen-devel][PATCH] Battery Management >> >> >From: Kamala Narasimhan [mailto:Kamala.Narasimhan@citrix.com] >> >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@lists.xensource.com >http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel