qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [SeaBIOS] seabios: acpi: add _RMV control method for PC


From: Avi Kivity
Subject: [Qemu-devel] Re: [SeaBIOS] seabios: acpi: add _RMV control method for PCI devices
Date: Mon, 13 Dec 2010 10:53:07 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

On 12/13/2010 10:49 AM, Gleb Natapov wrote:
On Mon, Dec 13, 2010 at 10:41:25AM +0200, Avi Kivity wrote:
>  On 12/13/2010 02:00 AM, Marcelo Tosatti wrote:
>  >On Sat, Dec 11, 2010 at 09:39:30AM +0200, Avi Kivity wrote:
>  >>   On 12/08/2010 07:08 PM, Marcelo Tosatti wrote:
>  >>   >Use _RMV method to indicate whether device can be removed.
>  >>   >
>  >>   >Data is retrieved from QEMU via I/O port 0xae0c.
>  >>   >
>  >>
>  >>   Where did this port come from?
>  >
>  >Its the next available address after "PCI EJ base", used
>  >for QEMU<->ACPI hotplug communication.
>  >
>  >>   What's the protocol?
>  >
>  >ACPI reads the 32-bit field indicating the return value of the _RMV
>  >method (which is used by Windows to decide removability). 1-bit per
>  >slot.
>  >
>  >More ports have to be registered if more buses are added.
>  >
>  >>   Maybe we should do this via fw_cfg.
>  >
>  >I don't see a need for it? (yes, it might be possible, but i'm not
>  >familiar enough with AML).
>
>  To avoid adding tons of undocumented I/O ports, and to allow
>  discoverability (what happens with a new seabios on old qemu)?
>
We already have out own mini pci hot-plug controller at io port 0xae00.
The patch just extends its functionality a bit. Logically this
functionality belongs there.

Well, at least it should be documented.

We could also deprecate the old port and use fwcfg for everything (try fwcfg, fall back to ae00).

>  We could do this in two ways: by adding a fwcfg client to the DSDT,
>  or by copying the information to system memory, and referencing
>  system memory from the DSDT.
>
This is even worse. It requires some fixed address to be shared between
DSDT and Seabios (or alternatively Seabios will have to generate this
part of DSDT dynamically).


Could easily be something in the F segment.

--
error compiling committee.c: too many arguments to function




reply via email to

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