Il 02/06/2013 17:05, Gleb Natapov ha scritto:
Anthony requested that patches be made that generate the ACPI tables
in QEMU for the upcoming hotplug work, so that they could be evaluated
to see if they truly do need to live in QEMU or if the code could live
in the firmware. There were no
On Sun, Jun 2, 2013 at 2:43 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Fri, May 31, 2013 at 01:45:55PM +0200, Laszlo Ersek wrote:
On 05/31/13 09:09, Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden?
Either qemu does it, or seabios... (And, OVMF
On Fri, May 31, 2013 at 01:45:55PM +0200, Laszlo Ersek wrote:
On 05/31/13 09:09, Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden?
Either qemu does it, or seabios... (And, OVMF too, but I don't think
you guys are concerned with that. :)
I am :)
On Thu, May 30, 2013 at 10:34:26PM -0400, Kevin O'Connor wrote:
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
There were discussions on potentially introducing a middle component
to generate the tables. Coreboot was raised as a possibility, and
David thought it would be
On Wed, May 29, 2013 at 11:45:44AM +0300, Michael S. Tsirkin wrote:
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here
On Sun, Jun 02, 2013 at 06:05:42PM +0300, Gleb Natapov wrote:
On Wed, May 29, 2013 at 11:45:44AM +0300, Michael S. Tsirkin wrote:
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now,
On Sun, Jun 02, 2013 at 06:09:50PM +0300, Michael S. Tsirkin wrote:
On Sun, Jun 02, 2013 at 06:05:42PM +0300, Gleb Natapov wrote:
On Wed, May 29, 2013 at 11:45:44AM +0300, Michael S. Tsirkin wrote:
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
On Thu, May 23, 2013 at
On Sun, Jun 02, 2013 at 06:40:43PM +0300, Gleb Natapov wrote:
On Sun, Jun 02, 2013 at 06:09:50PM +0300, Michael S. Tsirkin wrote:
On Sun, Jun 02, 2013 at 06:05:42PM +0300, Gleb Natapov wrote:
On Wed, May 29, 2013 at 11:45:44AM +0300, Michael S. Tsirkin wrote:
On Tue, May 28, 2013 at
On Thu, May 30, 2013 at 7:34 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
There were discussions on potentially introducing a middle component
to generate the tables. Coreboot was raised as a possibility, and
David thought it
Kevin O'Connor wrote:
one possible way forward would be to split the current SeaBIOS rom
into two roms: qvmloader and seabios. The qvmloader would do
the qemu specific platform init (pci init, smm init, mtrr init, bios
tables) and then load and run the regular seabios rom.
qvmloader sounds a
On 05/31/13 09:09, Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden?
Either qemu does it, or seabios... (And, OVMF too, but I don't think
you guys are concerned with that. :)
I am :)
On the flip side, why is moving the ACPI tables to QEMU such an
Kevin O'Connor ke...@koconnor.net writes:
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
There were discussions on potentially introducing a middle component
to generate the tables. Coreboot was raised as a possibility, and
David thought it would be okay to use coreboot for
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 15:04, Anthony Liguori wrote:
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to
OVMF
soapbox
:)
Fork OVMF, drop the fat module, and
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
driver is just a
On 05/31/13 15:04, Anthony Liguori wrote:
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to
OVMF
soapbox
:)
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable
On 05/31/13 16:08, David Woodhouse wrote:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
driver is just a
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to
OVMF
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Rewriting BSD implementations of
On Wed, 2013-05-29 at 21:12 -0400, Kevin O'Connor wrote:
I remain doubtful that QOM has all the info needed to generate the
BIOS tables. Does QOM describe how the 5th pci device uses global
interrupt 11 when using global interrupts, legacy interrupt 5 when not
using global interrupts, and
On 05/31/13 16:38, Anthony Liguori wrote:
It's either Open Source or it's not. It's currently not.
I disagree with this binary representation of Open Source or Not. If it
weren't (mostly) Open Source, how could we fork (most of) it as you're
suggesting (from the soapbox :))?
I have a hard
On 05/31/13 17:43, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork.
On 05/31/13 18:33, David Woodhouse wrote:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open
Source. So in a sense
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open
Source. So in a
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
The FAT module is required to make EDK2
Paolo Bonzini pbonz...@redhat.com writes:
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori anth...@codemonkey.ws wrote:
In terms of creating a FAT module, the most likely source would seem to
be the kernel code and since that's GPL, I don't think it's terribly
avoidable to end up with a GPL'd uefi implementation.
Why would OpenBSD not
On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori anth...@codemonkey.ws wrote:
As I think more about it, I think forking edk2 is inevitable. We need a
clean repo that doesn't include the proprietary binaries. I doubt
upstream edk2 is willing to remove the binaries.
No, probably not unless a
Jordan Justen jljus...@gmail.com writes:
On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori anth...@codemonkey.ws
wrote:
As I think more about it, I think forking edk2 is inevitable. We need a
clean repo that doesn't include the proprietary binaries. I doubt
upstream edk2 is willing to
On Fri, May 31, 2013 at 10:13:34AM +0200, Peter Stuge wrote:
Kevin O'Connor wrote:
one possible way forward would be to split the current SeaBIOS rom
into two roms: qvmloader and seabios. The qvmloader would do
the qemu specific platform init (pci init, smm init, mtrr init, bios
tables)
Hi,
Raised
that QOM interface should be sufficient.
Agree on this one. Ideally the acpi table generation code should be
able to gather all information it needs from the qom tree, so it can be
a standalone C file instead of being scattered over all qemu.
Ack. So my basic argument is
On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
Certainly an option, but that is a long-term project.
Out of curiousity, are there other benefits to using coreboot as a core
firmware in QEMU?
Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
I like the
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
There were discussions on potentially introducing a middle component
to generate the tables. Coreboot was raised as a possibility, and
David thought it would be okay to use coreboot for both OVMF and
SeaBIOS. The possibility was
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:
Agenda for the meeting Tue, May 28:
- Generating acpi tables
On 05/29/13 01:53, Kevin O'Connor wrote:
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:
Agenda for the meeting Tue, May 28:
- Generating acpi tables
I didn't see any meeting
On Wed, May 29, 2013 at 10:49:27AM +0200, Gerd Hoffmann wrote:
On 05/29/13 01:53, Kevin O'Connor wrote:
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:
Agenda for the meeting
Hi,
possible complexity of having to regenerate
tables on a vm reboot,
Why tables should be regenerated at reboot? I remember hotplug being
mentioned in the call. Hmm? Which hotplugged component needs acpi
table updates to work properly? And what is the point of hotplugging if
you
On Wed, May 29, 2013 at 11:42:34AM +0200, Gerd Hoffmann wrote:
Hi,
possible complexity of having to regenerate
tables on a vm reboot,
Why tables should be regenerated at reboot? I remember hotplug being
mentioned in the call. Hmm? Which hotplugged component needs acpi
table
Gerd Hoffmann kra...@redhat.com writes:
On 05/29/13 01:53, Kevin O'Connor wrote:
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:
Agenda for the meeting Tue, May 28:
- Generating
On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote:
Gerd Hoffmann kra...@redhat.com writes:
On 05/29/13 01:53, Kevin O'Connor wrote:
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now, and Anthony asked for
agenda to be sent early.
Anthony Liguori anth...@codemonkey.ws writes:
Gerd Hoffmann kra...@redhat.com writes:
On 05/29/13 01:53, Kevin O'Connor wrote:
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:
On Wed, May 29, 2013 at 07:28:05PM +0300, Michael S. Tsirkin wrote:
Because that's just insanely rick interface
s/rick/rich/. Sorry about the typo.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
On Wed, May 29, 2013 at 11:18:03AM -0500, Anthony Liguori wrote:
Gerd Hoffmann kra...@redhat.com writes:
On 05/29/13 01:53, Kevin O'Connor wrote:
Raised
that QOM interface should be sufficient.
Agree on this one. Ideally the acpi table generation code should be
able to gather all
On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
Juan is not available now, and Anthony asked for
agenda to be sent early.
So here comes:
Agenda for the meeting Tue, May 28:
- Generating acpi tables
I didn't see any meeting notes, but I thought it would be worthwhile
42 matches
Mail list logo
