Re: [Qemu-devel] [PATCH 2/2] Get system state configuration from QEMU and patcth DSDT with it.

[Gleb Natapov <gleb@redhat.com>]

On Mon, May 14, 2012 at 09:43:19PM -0400, Kevin O'Connor wrote:
> On Mon, May 14, 2012 at 03:35:23PM +0300, Gleb Natapov wrote:
> > QEMU may want to disable guest's S3/S4 support and it wants to distinguish
> > between regular powerdown and S4 powerdown. To support that new fw_cfg
> > option was added that passes supported system states and what value should
> > guest use to enter each state. States are passed in 6 byte array. Each
> > byte represents one system state. If byte at offset X has its MSB set
> > it means that system state X is supported and to enter it guest should
> > use the value from lowest 7 bits. Patch also detects old QEMU and uses
> > values that work in backwards compatible way there.
> 
> A couple of comments - see below.
> 
> [...]
> > --- a/src/acpi-dsdt.dsl
> > +++ b/src/acpi-dsdt.dsl
> > @@ -613,6 +613,7 @@ DefinitionBlock (
> >       * S3 (suspend-to-ram), S4 (suspend-to-disk) and S5 (power-off) type codes:
> >       * must match piix4 emulation.
> >       */
> > +    ACPI_EXTRACT_NAME_STRING acpi_s3_name
> >      Name (\_S3, Package (0x04)
> >      {
> >          0x01,  /* PM1a_CNT.SLP_TYP */
> > @@ -620,10 +621,12 @@ DefinitionBlock (
> >          Zero,  /* reserved */
> >          Zero   /* reserved */
> >      })
> > +    ACPI_EXTRACT_NAME_STRING acpi_s4_name
> > +    ACPI_EXTRACT_PKG_START acpi_s4_pkg
> 
> The DSDT is quite complex and has a diverse usage.  I'd feel more
> comfortable leaving it as static and doing any dynamic work in an
> SSDT.  In this particular case, can't the objects be turned into
> methods which calculate the associated values and return the correct
> results?
Checked with WindowsXP and Linux and they work if I make _S3 to be a
method that returns package, so we can drop ACPI_EXTRACT_PKG_START and
do runtime calculation, but what this calculation will be based on? We
will have to pass QEMU S4 value to AML somehow and this will involve
patching of something eventually. And of course we will still have to
patch out _S3/_S4 names in case qemu want to disable them. I do not see
how we can disable them in any other way.

I think the use of patching will only increase now after we let that
genie out of the bottle, so moving each part that we want to patch in
separate SSDT will not scale. Here the patching is minimal, moving only
_Sx to a separate SSDT feels unnecessary. Of course we can do it later
if thing will become more complex. We are not creating any ABIs here
that we cannot redo, just small implementation detail.

> 
> [...]
> > --- a/src/paravirt.c
> > +++ b/src/paravirt.c
> > @@ -92,6 +92,22 @@ int qemu_cfg_irq0_override(void)
> >      return v;
> >  }
> >  
> > +int qemu_cfg_system_states(char *states)
> > +{
> 
> I'd prefer to see any new fw_cfg entries use the QEMU_CFG_FILE_DIR
> mechanism so that seabios can use romfile_loadfile (or similar).
> 
The number of files you can pass over fw_cfg interface is limited due to
implementation details. I think we should continue using regular
fw_cfg entries for code that is QEMU specific and files for code that is
shared with coreboot.

--
			Gleb.