Re: [PATCH] tools: Remove support for qemu-trad's battery reporting

["Roger Pau Monné" <roger.pau@citrix.com>]

On Wed, Mar 26, 2025 at 03:44:05PM +0000, Alejandro Vallejo wrote:
> On Wed Mar 26, 2025 at 1:59 PM GMT, Marek Marczykowski-Górecki wrote:
> > On Tue, Mar 25, 2025 at 05:41:10PM +0000, Alejandro Vallejo wrote:
> > > The way this undocumented feature works is via qemu-trad (who nobody
> > > uses anymore), by intercepting 3 magic PIOs. 0x88 is one of them, and
> > > it's probed by hvmloader as a means of detecting support for this (so,
> > > on qemu-upstream this check always fails). If hvmloader detects the
> > > feature, it appends an SSDT with AML inherited from some laptop ~20y
> > > ago. QEMU then communicates with a userspace daemon (xenpmd) via an
> > > undocumented xenstore key ("refreshbatterystatus") in order to report
> > > battery levels.
> > > 
> > > Seeing how no one uses, mantains or cares about qemu-trad anymore, rip
> > > it all out. The hvmloader check, the SSDT generation logic and xenpmd.
> >
> > Oh, I didn't know something like this existed!
> 
> In retrospect, it might've been for the best. I really dislike the way it's put
> together. Using xenstore feels really pointless.
> 
> > We needed a feature like this, and solved it via extra kernel module +
> > PV-like interface to feed it with data from dom0:
> > https://github.com/QubesOS/qubes-dummy-psu/
> 
> I did wonder (after learning how this all works) how you guys did it without
> qemu-trad. I guess that explains it. FWIW, it's not hard to do this properly on
> QEMU upstream. We could create a new field under a BAR of the Xen platform
> device and instruct some (much, much, much simpler) AML to read the battery
> level from there. Then QEMU can ask the real system what the battery level is
> and Bob's your uncle.

I think some OSes (Linux? Possibly Windows?) like to use the xenpci
device BAR to put the grant table and as scratch space to map grants,
so we need to be careful with putting real registers there, as older
guests might not know about them.

Also that would mean adding QEMU (even if just for a limited usage) if
we want the feature for PVH guests.

It might be safer to place those registers in a physmap reserved
region, but not correlated with any device BAR.  Otherwise if the
guest decides to turn memory decoding off (which it shouldn't do in
the first place), the related AML will stop working properly.

I wonder if we could find a way to do this nicely from ACPI (so not
using a side band PV interface) and not have to involve QEMU.

Thanks, Roger.