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, bio
On Fri, May 31, 2013 at 5:01 PM, Laszlo Ersek 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 GPL'd FAT d
On Fri, May 31, 2013 at 07:58:36AM -0500, Anthony Liguori wrote:
> Kevin O'Connor 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" would do t
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 un
On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann 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 coreboot+seabios th
On Fri, May 31, 2013 at 1:27 PM, Anthony Liguori wrote:
> Jordan Justen writes:
>
>> On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori
>> 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
>>
Jordan Justen writes:
> On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori
> 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, probab
Jordan Justen writes:
> On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori
> 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 w
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
>> wrote:
>>> https://github.com/pgeorgi/edk2/tree/coreboot-pkg
>> Is the license on this actually BSD as the License.txt indicates?
Yes. All
On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori 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 BSD licensed altern
On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori 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 be a potential sou
Paolo Bonzini writes:
> Il 31/05/2013 19:06, Anthony Liguori ha scritto:
>> David Woodhouse 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
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
> David Woodhouse 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,
Laszlo Ersek 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
> suggesting (from t
David Woodhouse 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 sense you're ri
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
On 05/31/13 17:43, Anthony Liguori wrote:
> David Woodhouse writes:
>
>> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>>
>>>
>>>
>>> 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 m
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 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
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
---
virtio-spec.lyx | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/virtio-spec.lyx b/virtio-spec.lyx
index 6e188d0..7e4ce71 100644
---
David Woodhouse writes:
> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>
>>
>>
>> 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
Laszlo Ersek writes:
> On 05/31/13 15:04, Anthony Liguori wrote:
>> Laszlo Ersek writes:
>>
>>> On 05/31/13 09:09, Jordan Justen wrote:
>>>
>>> Due to licensing differences I can't just port code from SeaBIOS to
>>> OVMF
>>
>>
>
> :)
>
>> Fork OVMF, drop the fat module, and just add GPL code.
On 05/31/13 16:08, David Woodhouse wrote:
> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>
>>
>>
>> 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
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 a
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>
>
>
> 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 *binar
Laszlo Ersek writes:
> On 05/31/13 09:09, Jordan Justen wrote:
>
> Due to licensing differences I can't just port code from SeaBIOS to
> OVMF
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Rewriting BSD implementations of everything is silly. Every o
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 a
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
Kevin O'Connor 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 both OVMF an
On Fri, 31 May 2013 16:52:18 +0800
Xiao Guangrong 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 free for the memslot
> so th
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 seco
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, a
On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
> On Thu, May 30, 2013 at 5:19 AM, David Woodhouse
> 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 license on
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 is
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
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 an
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
>>>
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
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)
> >
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 size
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
>
> 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
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
On Thu, May 30, 2013 at 7:34 PM, 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 okay t
44 matches
Mail list logo
