qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI


From: Al Stone
Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation
Date: Thu, 13 Nov 2014 11:16:48 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 11/13/2014 01:10 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>> My understanding from an IRC conversation yesterday was that at
>> least some of these ACPI blobs contain data which has to be constructed
>> at the point it is requested (ie is not fixed at the point when
>> QEMU starts up), because OVMF will do:
>>  * startup
>>  * prod some parts of the hardware to configure it
>>  * request ACPI tables via fw_cfg
>> and the ACPI tables have to reflect the statu of the hardware
>> after OVMF's poking, not before.
> 
> It is this:
> 
> address@hidden ~]# cat /proc/ioports 
> [ ... ]
>   0600-063f : 0000:00:01.3
>     0600-0603 : ACPI PM1a_EVT_BLK
>     0604-0605 : ACPI PM1a_CNT_BLK
>     0608-060b : ACPI PM_TMR
>   0700-070f : 0000:00:01.3
>     0700-0707 : piix4_smbus
> [ ... ]

So this is problematic: the PM1a_EVT_BLK and PM1a_CNT_BLK should not
exist if hardware reduced mode ACPI is being used; the values in the
FADT should be zero so there should be no ioports (see section 5.2.9
of the ACPI spec).  If this is from an ARM platform, it _should_ be in
hardware reduced mode.  QEMU will have to take that into account.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
address@hidden
-----------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]