[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v3 1/8] hw/arm/virt: Add a GPIO controller

From: Wei Huang
Subject: Re: [Qemu-devel] [PATCH v3 1/8] hw/arm/virt: Add a GPIO controller
Date: Tue, 1 Dec 2015 09:29:19 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

On 12/01/2015 08:48 AM, Pavel Fedin wrote:
>  Hello!
>>>> ACPI 5.0 supports GPIO-signaled ACPI Events. This can be used for
>>>> powerdown, hotplug evnets. Add a GPIO controller in machine virt,
>>> s/evnets/events/
>>>> to support powerdown, maybe can be used for cpu hotplug. And
>>>> here we use pl061.
>  Sorry for late jumping in, but this was the first message Cc'ed to me.
>  With these devices virt machine IMHO goes farther and farther away from its 
> initial goal: be a minimalistic virtual box, which ensures maximum possible 
> compatibility and portability.
>  virt machine already supports poweroff using PSCI interface. Why we need to 
> add more hardware? Can't ACPI deal with PSCI?

PSCI handles the actions initiated from the inside of OS. Examples
include system shutdown and hotplug (still inside OS). From this
perspective PSCI works well. However this communication is
one-direction: there isn't a way to communicate from the outside (e.g.
libvirt) to the guest OS. For instance, "system_powerdown" qmp command
won't work because guest OS can't receive the notification.

>  To tell the truth, i dislike ACPI + EFI thing at all. It looks like cramming 
> PC-oriented firmware into architecture for which it was never meant to be 
> written. Too much overcomplications, we drop already established things and 
> reinvent a (triangular) wheel, but what's the purpose? Is it being done only 
> because vendors want obscure proprietary firmware instead of old good u-boot?
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia

reply via email to

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