Depending on guest behavior it could look like things are working
even though they aren't (e.g. a guest just enables MSR[VEC] and uses
altivec instructions, not relying on exceptions). This really isn't
worth spending a lot of time debating... Once Altivec is fixed
properly (you said
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
5. [nested virt] L2 has NMI error when creating L1 with -cpu host
parameter
https://bugzilla.kernel.org/show_bug.cgi?id=58941
-- this may have some relationship with the above bug #58921.
I think someone also reported this issue in the mailing list weeks ago.
Jan, Can you reproduce this
Il 31/05/2013 06:36, Gleb Natapov ha scritto:
In my commit message there is two INITs in a row:
vpu0:vcpu1:
set INIT
test_and_clear_bit(KVM_APIC_INIT)
process INIT
set INIT
set SIPI
Luiz Capitulino reported that guest refused to boot and qemu
complained with:
kvm_set_phys_mem: error unregistering overlapping slot: Invalid argument
It is caused by commit 235e8982ad that did double free for the memslot
so that the second one raises the -EINVAL error
Fix it by reset memory
On Fri, May 31, 2013 at 10:48:32AM +0200, Paolo Bonzini wrote:
Il 31/05/2013 06:36, Gleb Natapov ha scritto:
In my commit message there is two INITs in a row:
vpu0:vcpu1:
set INIT
test_and_clear_bit(KVM_APIC_INIT)
Hi,
I guess -bios would load coreboot. Coreboot would siphon the data
necessary for ACPI table building through the current (same) fw_cfg
bottleneck, build the tables,
Yes.
load the boot firmware (SeaBIOS or OVMF or
something else -- not sure how to configure that),
The coreboot rom has
Il 31/05/2013 11:18, Gleb Natapov ha scritto:
On Fri, May 31, 2013 at 10:48:32AM +0200, Paolo Bonzini wrote:
Il 31/05/2013 06:36, Gleb Natapov ha scritto:
In my commit message there is two INITs in a row:
vpu0:vcpu1:
set INIT
Gerd Hoffmann wrote:
and pass down the
tables to the firmware (through a now unspecified interface -- perhaps
the tables could even be installed at this point).
As far I know coreboot can add more stuff such as acpi tables to cbfs at
runtime and seabios able to access cbfs too and pull
On 05/31/13 10:13, 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) and then load and run the
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
On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dw...@infradead.org
wrote:
On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
Where is CorebootPkg available from?
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
Is the
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
Il 31/05/2013 10:52, Xiao Guangrong ha scritto:
Luiz Capitulino reported that guest refused to boot and qemu
complained with:
kvm_set_phys_mem: error unregistering overlapping slot: Invalid argument
It is caused by commit 235e8982ad that did double free for the memslot
so that the second
On Fri, 31 May 2013 16:52:18 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
Luiz Capitulino reported that guest refused to boot and qemu
complained with:
kvm_set_phys_mem: error unregistering overlapping slot: Invalid argument
It is caused by commit 235e8982ad that did double
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
On 05/31/13 10:13, Peter Stuge wrote:
ACPI bytes are obviously a function of QEMU configuration.
Precisely!
When we evaluate that (mathematical-sense) function in boot firmware, we
need to retrieve the function's arguments. Those arguments are bits of
QEMU configuration, as you say, and fw_cfg
On Fri, 2013-05-31 at 07:58 -0500, Anthony Liguori wrote:
What about a small change to the SeaBIOS build system to allow ACPI
table generation to be done via a plugin.
SeaBIOS already accepts ACPI tables from Coreboot or UEFI, and queries
them to find things that it needs.
This could be as
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 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 single module. Which is actually included in
Hello,
I have an server with only one NIC, this NIC has a Public IP, this
server is locate in a data center, I can't have more than one, but I can
have many IP's, so I would like to know if I can redirect packages from
virtual interface for my VM's?
Examples:
eth0:1 xxx.xx.xxx.xxx redirec
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 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
1. s/These are devices are/These devices are
2. s/Thefirst/The first
3. s/, Guest should/. Guest should
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
virtio-spec.lyx | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/virtio-spec.lyx b/virtio-spec.lyx
index
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 you're right.
But we're talking here about
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
Laszlo Ersek ler...@redhat.com writes:
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
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
Am 31.05.2013 14:09, schrieb David Woodhouse:
On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dw...@infradead.org
wrote:
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
Is the license on this actually BSD as the License.txt indicates?
Jordan Justen jljus...@gmail.com writes:
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
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 1:27 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Jordan Justen jljus...@gmail.com writes:
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
On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
I guess -bios would load coreboot. Coreboot would siphon the data
necessary for ACPI table building through the current (same) fw_cfg
bottleneck, build the tables,
Yes.
So, this is really about making
On 05/31/13 23:03, Jordan Justen wrote:
Of course, the fact that the current FAT driver is exclusionary for
free software projects is a point that is not lost on me. I just don't
agree that the best response to this is a GPL'd FAT driver.
What would you suggest?
Thank you,
Laszlo
--
To
On Fri, May 31, 2013 at 07:58:36AM -0500, Anthony Liguori wrote:
Kevin O'Connor ke...@koconnor.net writes:
Given the objections to implementing ACPI directly in QEMU, one
possible way forward would be to split the current SeaBIOS rom into
two roms: qvmloader and seabios. The qvmloader
On Fri, May 31, 2013 at 5:01 PM, Laszlo Ersek ler...@redhat.com wrote:
On 05/31/13 23:03, Jordan Justen wrote:
Of course, the fact that the current FAT driver is exclusionary for
free software projects is a point that is not lost on me. I just don't
agree that the best response to this is a
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)
Depending on guest behavior it could look like things are working
even though they aren't (e.g. a guest just enables MSR[VEC] and uses
altivec instructions, not relying on exceptions). This really isn't
worth spending a lot of time debating... Once Altivec is fixed
properly (you said
46 matches
Mail list logo
