Re: [Qemu-devel] [PATCH][RFC v2 3/7] vl: create power chip device

[guang li]

Yes, you're right.

The motivation is I want to implement a device

called EC which is a notion from laptop for QEMU,

EC has some main functions, like keyboard, mouse,

low-speed device control(I2C), special ACPI space,

 i8042 and ps2 mouse has been done,  power control

was left, so I tried to add this.

so, Andreas,

do you know this  chip for laptop?

any suggestions for this?

Thanks!

2013/4/10 Andreas Färber <address@hidden>

Am 10.04.2013 02:09, schrieb li guang:

> 在 2013-04-09二的 13:06 +0200，Paolo Bonzini写道：
>> Il 09/04/2013 10:26, li guang ha scritto:
>>>> qemu_system_suspend_request, qemu_register_suspend_notifier
>>>>    for S0->S3
>>>>
>>>> qemu_system_wakeup_request, qemu_register_wakeup_notifier
>>>>    for S3->S0
>>>>
>>>> qemu_system_powerdown_request, qemu_register_powerdown_notifier
>>>>    for Sx->S5
>>>>
>>>> and the reset mechanism for S5->S0.
>>>
>>> Yep, I'm trying to supersede these functions
>>> by my power chip emulation.
>>
>> Then I explained in my other message why this is wrong.  The API may
>> well be "bad" (if so, please explain why), but at least it is the right
>> tool to model this.  QEMU models abstract concepts (memory, timers,
>> powerdown) with APIs, not with devices.
>>
>
> It's probably not 'bad', just only not native, because real hardware
> does not do thing that way, and also, this power chip is not purely
> conceptual, it just try to integrate jobs of power control from
> different platform.
> of course, I can model this power chip as real hardware which exists
> in specific platform.

Li Guang, I think your problem is a conceptual one: QEMU does not do a
system simulation, it does a system emulation. Thus if a chip is hidden
from software and not directly accessed in terms of registers from guest
software, then we don't model it as a device but call some API functions
from where it is supposed to show effects (keyboard controller device
MemoryRegionOps, TCG instruction, monitor command, ...).

Thus we are reluctant to accept a QOM Device that is neither exposed to
the guest nor uses any QOM concepts like inheritance AFAICS. Especially
when the advantage of doing so is not well explained.

Andreas

> can we just feel happy with current implementation and don't want
> to try other things?  :-)
> or do you consider this totally wrong for direction?

--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

--

Sidere mens eadem mutato