On Mon, Jun 3, 2013 at 4:12 PM, Anthony Liguori wrote:
> Jordan Justen writes:
>> I mentioned in the other thread that perhaps QEMU could also consider
>> making the ACPI code available under some 'appropriate' license, which
>> would allow firmware writers to leverage the code directly if desire
Jordan Justen writes:
> On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori
> wrote:
>> "Michael S. Tsirkin" writes:
>>
>>> On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote:
I don't think it's a good idea to move BIOS functionality in QEMU.
>>>
>>> Just to clarify: generating
On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
>> On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote:
>>> I don't think it's a good idea to move BIOS functionality in QEMU.
>>
>> Just to clarify: generating ACPI tables is not BIOS
>> function
On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote:
>
> It depends. For ARM we insist that the user provides the
> device tree that corresponds to the kernel they're going to
> run, and then we just tweak it a bit.
Um... device trees describe hardware, and should not be at all
kernel-specific
On 14 May 2013 15:29, David Woodhouse wrote:
> On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote:
>> It depends. For ARM we insist that the user provides the
>> device tree that corresponds to the kernel they're going to
>> run, and then we just tweak it a bit.
>
> Um... device trees describe
Gerd Hoffmann writes:
> Hi,
>
and is also a good
reason why exposing this information via a common interface (fw_cfg)
would be a good idea.
>>>
>>> Huh? As far I know we generate device trees in qemu instead of
>>> expecting pseries firmware compile them from fw_cfg information.
Hi,
>>> and is also a good
>>> reason why exposing this information via a common interface (fw_cfg)
>>> would be a good idea.
>>
>> Huh? As far I know we generate device trees in qemu instead of
>> expecting pseries firmware compile them from fw_cfg information.
>
> It depends on what firmware
Gerd Hoffmann writes:
> Hi,
>
>>> Several future developments that this will enable:
>>> - make it easier to use alternative firmware:
>>> any firmware can just load the ACPI tables from QEMU.
>>> case in point OVMF.
>>
>> UEFI obviously can create ACPI tables already so I don't think this
On 14 May 2013 10:29, Gerd Hoffmann wrote:
> Anthony wrote:
>> and is also a good
>> reason why exposing this information via a common interface (fw_cfg)
>> would be a good idea.
>
> Huh? As far I know we generate device trees in qemu
It depends. For ARM we insist that the user provides the
devi
Hi,
>> Several future developments that this will enable:
>> - make it easier to use alternative firmware:
>> any firmware can just load the ACPI tables from QEMU.
>> case in point OVMF.
>
> UEFI obviously can create ACPI tables already so I don't think this is a
> valid advantage.
Yea, bu
10 matches
Mail list logo
