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 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.
>
> We don't frequently add firmware or chipsets so it seems like we're
> optimizing for an uncommon scenario here.
>
> Regards,
>
> Anthony Liguori
By the way,
On Tue, May 14, 2013 at 08:34:43AM -0500, 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 BIO
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
"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
> functionality. It ended up in seabios for historical
> reasons.
>
> A nor
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 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
functionality. It ended up in seabios for historical
reasons.
A normal scenario for ACPI tables is that they ar
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
"Michael S. Tsirkin" writes:
> This patchset moves all generation of ACPI tables
> from guest BIOS to the hypervisor.
>
> Although ACPI tables come from a system BIOS on real hw,
> it makes sense that the ACPI tables are coupled with the
> virtual machine, since they have to abstract the x86 mach
This patchset moves all generation of ACPI tables
from guest BIOS to the hypervisor.
Although ACPI tables come from a system BIOS on real hw,
it makes sense that the ACPI tables are coupled with the
virtual machine, since they have to abstract the x86 machine to
the OS's.
Several future developme
14 matches
Mail list logo
