RE: [PATCH] kvm/ppc/booke64: fix build breakage from Altivec, and disable e6500
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 that'd be soon, right?), we can add e6500 back to the list. Am I going to see an Altivec patch soon, or should I ask Gleb to take this patch instead? Yes, I will add ONE_REG support today and send it on the list. -Mike -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 would be okay to use coreboot for both OVMF and SeaBIOS. The possibility was also raised of a rom that lives in the qemu repo, is run in the guest, and generates the tables (which is similar to the hvmloader approach that Xen uses). 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 the qemu specific platform init (pci init, smm init, mtrr init, bios tables) and then load and run the regular seabios rom. With this split, qvmloader could be committed into the QEMU repo and maintained there. This would be analogous to Xen's hvmloader with the seabios code used as a starting point to implement it. I think hvmloader is more closely tied to Xen, than the Xen firmware. I could be wrong, but thought it could do things like add memory to guest machine. ?? I don't think this model is analogous to Xen's model. I view the hvmloader as just a part of Xen. (Not part of the 'firmware' stack.) In adding this pre-firmware firmware, wouldn't Anthony's concern of iasl still be an issue? 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. :) On the flip side, why is moving the ACPI tables to QEMU such an issue? It seems like Xen and virtualbox both already do this. Why is running iasl not an issue for them? I think overall I prefer the tables being built in the firmware, despite the extra thrash. Some things, such as the addresses where devices are configured at are re-programmable in QEMU, so a firmware can decide to use a different address, and thus invalidate the address qvmloader had set in the tables. Maybe we are doing lots of things horribly wrong in our OVMF ACPI tables :), but I haven't seen it as much of a burden. (Of course, Laszlo has helped out with many of the ACPI changes in OVMF, so his opinion should be taken into consideration too. :) -Jordan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] KVM call agenda for 2013-05-28
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 lot like coreboot. qvmloader could be committed into the QEMU repo and maintained there. If QEMU really doesn't want anything besides quacking like a PC with BIOS or UEFI (such as quacking like a PC *without* a particular firmware) it makes perfect sense to me to put the complete firmware code into the QEMU repo and never reuse anything else. After all, that's how the proprietary firmware products are managed. Jordan Justen wrote: Why is updating the ACPI tables in seabios viewed as such a burden? I don't know about burden but to me it just doesn't make any sense to generate ACPI in one component (SeaBIOS) based on configuration for another component (QEMU). ACPI bytes are obviously a function of QEMU configuration. QEMU configuration can be changed through a great many channels, so it makes sense to me that QEMU itself would take care of generating correct ACPI, rather than exporting it's own data structures and pushing the ACPI problem onto the firmware, especially considering the desire for multiple independent firmware implementations. There's some code for dynamic ACPI generation in coreboot already, maybe that can be reused in QEMU to save some effort.. On the flip side, why is moving the ACPI tables to QEMU such an issue? Maybe because it is such a steaming pile that even the place where it belongs doesn't really want it.. I think overall I prefer the tables being built in the firmware, despite the extra thrash. That doesn't make sense to me. :\ Keep in mind: there is firmware and there is firmware.. Some things, such as the addresses where devices are configured at are re-programmable in QEMU, so a firmware can decide to use a different address, and thus invalidate the address qvmloader had set in the tables. ..there is now talk about a first-stage firmware (qvmloader) which does only hardware init, and then jumps into a second-stage firmware (SeaBIOS) which starts the operating system. I don't expect that anyone would argue for the second-stage firmware to generate ACPI tables if the first-stage firmware would be shared across different second-stage implementations. The above is by the way *exactly* the model coreboot uses since 14 years. Please make an ernest effort to *look into and try to reuse* what *is already there* .. The fear of coreboot is truly amazing. //Peter -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: KVM Test report, kernel e47a5f5f... qemu b5803aa3...
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 issue? or any idea to fix it?
I found your following commit is the first bad commit for this bug.
commit 3b656cf764cbc43d3efb9bf5f45c618d4cf0989f
Author: Jan Kiszka jan.kis...@siemens.com
Date: Sun Apr 14 12:12:45 2013 +0200
KVM: nVMX: Fix injection of PENDING_INTERRUPT and NMI_WINDOW exits to L1
Check if the interrupt or NMI window exit is for L1 by testing if it has
the corresponding controls enabled. This is required when we allow
direct injection from L0 to L2
Best Regards,
Yongjie (Jay)
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org]
On Behalf Of Ren, Yongjie
Sent: Wednesday, May 29, 2013 4:13 PM
To: kvm@vger.kernel.org
Subject: KVM Test report, kernel e47a5f5f... qemu b5803aa3...
Hi All,
This is KVM upstream test result against kvm.git next branch and
qemu-kvm.git uq/master branch.
kvm.git next branch:
e47a5f5fb715b90b40747e9e235de557c6abd56c based on kernel
3.10.0-rc1
qemu-kvm.git uq/master branch:
b5803aa3583e82e5133f7621121bc15ee694f4a1
We found 5 new bugs and verified 1 fixed bug this month.
We also closed a bug as invalid because it's a known issue that some
Windows version is not supported for I350 NIC.
New issues (5):
1. guest cannot boot up when Intel 82572 NIC assigned
https://bugs.launchpad.net/qemu/+bug/1182716
-- this may already been fixed in qemu.git tree but it still exists in
qemu-kvm.git uq/master branch.
2. with 'monitor pty', it needs to flush pts device after sending command to
it
https://bugs.launchpad.net/qemu/+bug/1185228
3. [nested virt] L2 Windows guest can't boot up ('-cpu host' to start L1)
https://bugzilla.kernel.org/show_bug.cgi?id=58921
4. SMP x64 Windows 2003 guest can't boot up
https://bugzilla.kernel.org/show_bug.cgi?id=58931
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.
Fixed issue (1):
1. [nested virt] L1 CPU Stuck when booting a L2 guest
https://bugzilla.kernel.org/show_bug.cgi?id=56971
Closed issue with invalid(1):
1. [SR-IOV] Intel I350 NIC VF cannot work in a Windows 2008 guest.
https://bugzilla.kernel.org/show_bug.cgi?id=56981
-- Intel driver team said I350 is supported in Win2k8 R2 version (not
supported Win2k8).
Old issues (6):
--
1. guest panic with parameter -cpu host in qemu command line (about
vPMU issue).
https://bugs.launchpad.net/qemu/+bug/994378
2. Can't install or boot up 32bit win8 guest.
https://bugs.launchpad.net/qemu/+bug/1007269
3. vCPU hot-add makes the guest abort.
https://bugs.launchpad.net/qemu/+bug/1019179
4. Nested Virt: VMX can't be initialized in L1 Xen (Xen on KVM)
https://bugzilla.kernel.org/show_bug.cgi?id=45931
5. Guest has no xsave feature with parameter -cpu qemu64,+xsave in
qemu command line.
https://bugs.launchpad.net/qemu/+bug/1042561
6. Guest hang when doing kernel build and writing data in guest.
https://bugs.launchpad.net/qemu/+bug/1096814
Test environment:
==
Platform IvyBridge-EPSandybridge-EP
CPU Cores 3232
Memory size 64GB 32GB
Regards
Yongjie Ren (Jay)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] KVM: Fix race in apic-pending_events processing
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 test_and_clear_bit(KVM_APIC_SIPI) process SIPI Two INITs before SIPI are essential to trigger the bug I see now. Let's draw pending_events as well: event sent event processedpending_events INITINIT INIT0 INITINIT SIPI INIT|SIPI SIPI INIT INIT 0 Events are reordered, there is indeed a bug if the second INIT comes at just the right time. With your patch: event sent event processedpending_events INITINIT INIT0 INITINIT SIPI INIT|SIPI SIPI, failed cmpxchg INIT|SIPI INIT SIPI SIPI SIPI The patch introduces a spurious SIPI, that's worse than coalescing. With my patch: event sent event processedpending_events INITINIT INIT0 INITINIT SIPI INIT|SIPI (failed cmpxchg) INIT|SIPI INIT SIPI SIPI0 My patch looks better to me for this scenario. and coincidentally this is what spec advices to do. The spec advises INIT-SIPI-SIPI, not INIT-INIT-SIPI. This is because the first INIT may have been processed late, and SIPIs are masked if not in wait-for-SIPI state. You need to send the second just in case. It is not needed in KVM because INITs effectively unmask the SIPI immediately, even though the INIT may take place a bit later. The INIT-SIPI-SIPI sequence is handled correctly by KVM thanks to the check on the mp-state. But your patch breaks another corner case: event sent event processedpending_events INITINIT INIT0 SIPISIPI SIPI0 SIPISIPI ignored SIPI SIPI set_mp_state(INIT_RECEIVED) SIPI SIPI0 With my patch, or no patch at all: event sent event processedpending_events INITINIT INIT0 SIPISIPI SIPI0 SIPISIPI ignored SIPI0 set_mp_state(INIT_RECEIVED) 0 Though perhaps the real bug here is in kvm_arch_vcpu_ioctl_setmp_state. Setting the mp_state to anything bug SIPI_RECEIVED should clear the SIPI event. Paolo event sent event processedpending_events INIT INIT SIPI INIT|SIPI INITSIPI SIPI 0 INIT INIT SIPI INIT|SIPI INITSIPI SIPI 0 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH uq/master] fix double free the memslot in kvm_set_phys_mem
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 only if it is needed
Reported-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 8e7bbf8..405480e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -206,7 +206,8 @@ static int kvm_set_user_memory_region(KVMState *s, KVMSlot
*slot)
if (s-migration_log) {
mem.flags |= KVM_MEM_LOG_DIRTY_PAGES;
}
-if (mem.flags KVM_MEM_READONLY) {
+
+if (slot-memory_size mem.flags KVM_MEM_READONLY) {
/* Set the slot size to 0 before setting the slot to the desired
* value. This is needed based on KVM commit 75d61fbc. */
mem.memory_size = 0;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] KVM: Fix race in apic-pending_events processing
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) process INIT set INIT set SIPI test_and_clear_bit(KVM_APIC_SIPI) process SIPI Two INITs before SIPI are essential to trigger the bug I see now. Let's draw pending_events as well: event sent event processedpending_events INITINIT INIT0 INITINIT SIPI INIT|SIPI SIPI INIT INIT 0 Events are reordered, there is indeed a bug if the second INIT comes at just the right time. With your patch: event sent event processedpending_events INITINIT INIT0 INITINIT SIPI INIT|SIPI SIPI, failed cmpxchg INIT|SIPI INIT SIPI SIPI SIPI This is incorrect. cmpxchg will fail only if another INIT cames after SIPI. Why would it fail? The patch introduces a spurious SIPI, that's worse than coalescing. With my patch: event sent event processedpending_events INITINIT INIT0 INITINIT SIPI INIT|SIPI (failed cmpxchg) INIT|SIPI INIT SIPI SIPI0 My patch looks better to me for this scenario. and coincidentally this is what spec advices to do. The spec advises INIT-SIPI-SIPI, not INIT-INIT-SIPI. This is because the first INIT may have been processed late, and SIPIs are masked if not in wait-for-SIPI state. You need to send the second just in case. It is not needed in KVM because INITs effectively unmask the SIPI immediately, even though the INIT may take place a bit later. OK, I said this from memory since I cannot check the spec now. In this case we need to fix unit test too. The INIT-SIPI-SIPI sequence is handled correctly by KVM thanks to the check on the mp-state. But your patch breaks another corner case: event sent event processedpending_events INITINIT INIT0 SIPISIPI SIPI0 SIPISIPI ignored SIPI SIPI set_mp_state(INIT_RECEIVED) SIPI SIPI0 With my patch, or no patch at all: event sent event processedpending_events INITINIT INIT0 SIPISIPI SIPI0 SIPISIPI ignored SIPI0 set_mp_state(INIT_RECEIVED) 0 Though perhaps the real bug here is in kvm_arch_vcpu_ioctl_setmp_state. Looks like it, also in my patch we can always call cmpxchg to clear SIPI. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
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 named sections (this is called cbfs which stands for coreboot filesystem IIRC): rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin0x0cmos_layout 1160 fallback/romstage 0x4c0 stage14419 fallback/coreboot_ram 0x3d80 stage37333 config 0xcfc0 raw 2493 fallback/payload 0xd9c0 payload 56969 vgabios/sgabios0x1b8c0raw 4096 (empty)0x1c900null 144216 where fallback/payload is seabios. 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 informations from coreboot that way. HTH, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] KVM: Fix race in apic-pending_events processing
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 test_and_clear_bit(KVM_APIC_INIT) process INIT set INIT set SIPI test_and_clear_bit(KVM_APIC_SIPI) process SIPI Two INITs before SIPI are essential to trigger the bug I see now. Let's draw pending_events as well: event sent event processedpending_events INITINIT INIT0 INITINIT SIPI INIT|SIPI SIPI INIT INIT 0 Events are reordered, there is indeed a bug if the second INIT comes at just the right time. With your patch: event sent event processedpending_events INITINIT INIT0 INITINIT SIPI INIT|SIPI SIPI, failed cmpxchg INIT|SIPI INIT SIPI SIPI SIPI This is incorrect. cmpxchg will fail only if another INIT cames after SIPI. Why would it fail? You're right. Can you show what is the case in my patch where you have coalescing? I still prefer it because it is a smaller change, it keeps the clear a bit before processing idea that you find almost everywhere. Changing it to clear a bit after processing is a bigger and more surprising change, though both are indeed tricky. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
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 informations from coreboot that way. Only a minor correction - cbfs is the flash image, which so far doesn't really change at runtime. Stuff added at runtime goes into coreboot tables which is a coreboot-specified data structure which SeaBIOS finds and uses to know things like the memory map. When using coreboot+SeaBIOS on real hardware, ACPI tables are built and put in place by coreboot, and never modified by SeaBIOS AFAIK. //Peter -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] KVM call agenda for 2013-05-28
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 regular seabios rom. qvmloader sounds a lot like coreboot. Indeed. ACPI bytes are obviously a function of QEMU configuration. QEMU configuration can be changed through a great many channels, so it makes sense to me that QEMU itself would take care of generating correct ACPI, rather than exporting it's own data structures and pushing the ACPI problem onto the firmware, especially considering the desire for multiple independent firmware implementations. Can't agree more. I still think the best solution is to have qemu generate the acpi tables and all firmware can just grab them. Second best option would be to have coreboot generate them and everything else go on top of coreboot then. Third best option is to duplicate the acpi generation code in all firmware variants (this is what we have today). IMO qvmloader would be even worse than these three. Writing a piece of firmware is alot more tricky than a linux userspace app, especially in x86 land with the funky mode switching and assembler modes. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 issue? It seems like Xen and virtualbox both already do this. Why is running iasl not an issue for them? I think something was mentioned about iasl having problems on BE machines? I could be easily wrong but I *guess* qemu's hosts x targets (emulate what on what) set is a proper superset of xen's and virtualbox's. Presumably if you want to run an x86 guest on a MIPS host, and also want to build qemu on the same MIPS (or SPARC) host, you'd have to run iasl there too. Maybe we are doing lots of things horribly wrong in our OVMF ACPI tables :) Impossible. :) In earnest, I think what we have now is (mostly) correct, just not extensive / flexible enough. No support for PCI hotplug or CPU hotplug, none for S3 (although all of these tie into UEFI deeply), no MTRR setup, no MPTABLE; let alone a non-PIIX chipset. (Well maybe I shouldn't lump these under the ACPI umbrella.) but I haven't seen it as much of a burden. (Of course, Laszlo has helped out with many of the ACPI changes in OVMF, so his opinion should be taken into consideration too. :) It hasn't been a burden in the sense of me not liking the activity; I actually like fiddling with knobs. It has certainly been extra work to bring OVMF's ACPI tables closer to SeaBIOS's functionality / flexibility (and we still lag behind it quite.). Due to licensing differences I can't just port code from SeaBIOS to OVMF (and I never have without explicit permission), so it's been a lot of back and forth with acpidump / iasl -d in guests (massage OVMF, boot guest, check guest dmesg / lspci, dump tables, compare, repeat), brain picking colleagues, the ACPI and PIIX specs and so on. I have a page on the RH intranet dedicated to this. When something around these parts is being changed (or looks like it could be changed) in SeaBIOS, or between qemu and SeaBIOS, I always must be alert and consider reimplementing it in, or porting it with permission to, OVMF. (Most recent example: pvpanic device -- currently only in SeaBIOS.) It worries me that if I slack off, or am busy with something else, or simply don't notice, then the gap will widen again. I appreciate learning a bunch about ACPI, and don't mind the days of work that went into some of my simple-looking ACPI patches for OVMF, but had the tables come from a common (programmatic) source, none of this would have been an issue, and I wouldn't have felt even occasionally that ACPI patches for OVMF were both duplicate work *and* futile (considering how much ahead SeaBIOS was). I don't mind reimplementing stuff, or porting it with permission, going forward, but the sophisticated parts in SeaBIOS are a hard nut. For example I'll never be able to auto-extract offsets from generated AML and patch the AML using those offsets; the edk2 build tools (a project separate from edk2) don't support this, and it takes several months to get a thing as simple as gcc-47 build flags into edk2-buildtools. Instead I have to write template ASL, compile it to AML, hexdump the result, verify it against the AML grammar in the ACPI spec (offsets aren't obvious, BytePrefix and friends are a joy), define initialize a packed struct or array in OVMF, and patch the template AML using fixed field names or array subscripts. Workable, but dog slow. If the ACPI payload came from up above, we might be as well provided with a list of (canonical name, offset, size) triplets, and could perhaps blindly patch the contents. (Not unlike Michael's linker code for connecting tables into a hierarchy.) AFAIK most recently iasl got built-in support for offset extraction (and in the process the current SeaBIOS build method was broken...), so that part might get easier in the future. Oh well it's Friday, sorry about this rant! :) I'll happily do what I can in the current status quo, but frequently, it won't amount to much. Thanks, Laszlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
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 license on this actually BSD as the License.txt indicates? Is this planned to be upstreamed? Does this support UEFI variables? Does this support UEFI IA32 / X64? Those are questions for Patrick. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [SeaBIOS] KVM call agenda for 2013-05-28
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 that the legacy interrupt can be changed by writing to the 0x60 address of the 1st pci device's config space? Does QOM state that the machine supports S3 sleep mode? Does QOM indicate that an IPMI device supports the 3rd version of the IPMI device specification? Does it indicate whether this particular version of qemu has correctly implemented the hard reset at 0xcf9? If so, we need to put that in as the ACPI RESET_REG. It seems that there's a *lot* which isn't fully described in the QOM tree. Do we really want to add it all, just so that ACPI tables can be reliably generated from it? As we add new types of hardware and even fix/adjust features like the examples above, we'll also have to implement the translation from QOM to ACPI tables. And we'll have to do so in more than one place, in projects with a completely different release cycle. This would be *so* much easier if the code which actually generates the ACPI tables was *in* the qemu tree along with the hardware that those tables describe. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH uq/master] fix double free the memslot in kvm_set_phys_mem
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 one raises the -EINVAL error
Fix it by reset memory size only if it is needed
Reported-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 8e7bbf8..405480e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -206,7 +206,8 @@ static int kvm_set_user_memory_region(KVMState *s,
KVMSlot *slot)
if (s-migration_log) {
mem.flags |= KVM_MEM_LOG_DIRTY_PAGES;
}
-if (mem.flags KVM_MEM_READONLY) {
+
+if (slot-memory_size mem.flags KVM_MEM_READONLY) {
/* Set the slot size to 0 before setting the slot to the desired
* value. This is needed based on KVM commit 75d61fbc. */
mem.memory_size = 0;
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH uq/master] fix double free the memslot in kvm_set_phys_mem
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 free for the memslot
so that the second one raises the -EINVAL error
Fix it by reset memory size only if it is needed
Reported-by: Luiz Capitulino lcapitul...@redhat.com
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
Tested-by: Luiz Capitulino lcapitul...@redhat.com
Thanks Xiao for the fix, and thanks everyone for debugging this issue!
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 8e7bbf8..405480e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -206,7 +206,8 @@ static int kvm_set_user_memory_region(KVMState *s,
KVMSlot *slot)
if (s-migration_log) {
mem.flags |= KVM_MEM_LOG_DIRTY_PAGES;
}
-if (mem.flags KVM_MEM_READONLY) {
+
+if (slot-memory_size mem.flags KVM_MEM_READONLY) {
/* Set the slot size to 0 before setting the slot to the desired
* value. This is needed based on KVM commit 75d61fbc. */
mem.memory_size = 0;
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 both OVMF and SeaBIOS. The possibility was also raised of a rom that lives in the qemu repo, is run in the guest, and generates the tables (which is similar to the hvmloader approach that Xen uses). 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 the qemu specific platform init (pci init, smm init, mtrr init, bios tables) and then load and run the regular seabios rom. With this split, qvmloader could be committed into the QEMU repo and maintained there. This would be analogous to Xen's hvmloader with the seabios code used as a starting point to implement it. What about a small change to the SeaBIOS build system to allow ACPI table generation to be done via a plugin. This could be as simple as moving acpi.c and *.dsl into the QEMU build tree and then having a way to point the SeaBIOS makefiles to our copy of it. Then the logic is maintained stays in firmware but the churn happens in the QEMU tree instead of the SeaBIOS tree. Regards, Anthony Liguori With both the hardware implementation and acpi descriptions for that hardware in the same source code repository, it would be possible to implement changes to both in a single patch series. The fwcfg entries used to pass data between qemu and qvmloader could also be changed in a single patch and thus those fwcfg entries would not need to be considered a stable interface. The qvmloader code also wouldn't need the 16bit handlers that seabios requires and thus wouldn't need the full complexity of the seabios build. Finally, it's possible that both ovmf and seabios could use a single qvmloader implementation. On the down side, reboots can be a bit goofy today in kvm, and that would need to be settled before something like qvmloader could be implemented. Also, it may be problematic to support passing of bios tables from qvmloader to seabios for guests with only 1 meg of ram. Thoughts? -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
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 is extremely inconvenient for fetching them. Whenever the domain or arity of said mathematical function changes (we need more arguments, or different kinds of arguments), we have to extend fw_cfg with yet another ad-hoc key or file entry. The set of arguments going into ACPI tables *is* ad-hoc and arbitrary, there's nothing to do about it. But at least we shouldn't impede the retrieval of said arguments with artificial obstacles, such as half-assedly serializing them over fw_cfg (and not documenting them, naturally). In qemu the entire pool of arguments, current and future, would be at just an arm's length, in immediately consumable form. I've said the same about the acpi_build_madt() prototype that was proposed for qemu: http://thread.gmane.org/gmane.comp.emulators.qemu/207171/focus=208719. Thanks, Laszlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 simple as moving acpi.c and *.dsl into the QEMU build tree and then having a way to point the SeaBIOS makefiles to our copy of it. Then the logic is maintained stays in firmware but the churn happens in the QEMU tree instead of the SeaBIOS tree. Even if you get this working such that SeaBIOS and OVMF can both be built with ACPI tables that match the last qemu you built, that doesn't solve the issue of running a firmware that *wasn't* built to precisely match the version of qemu you're running today. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: KVM call agenda for 2013-05-28
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 everything is silly. Every other vendor that uses TianoCore has a proprietary fork. Maintaining a GPL fork seems just as reasonable. /soapbox Regards, Anthony Liguori (and I never have without explicit permission), so it's been a lot of back and forth with acpidump / iasl -d in guests (massage OVMF, boot guest, check guest dmesg / lspci, dump tables, compare, repeat), brain picking colleagues, the ACPI and PIIX specs and so on. I have a page on the RH intranet dedicated to this. When something around these parts is being changed (or looks like it could be changed) in SeaBIOS, or between qemu and SeaBIOS, I always must be alert and consider reimplementing it in, or porting it with permission to, OVMF. (Most recent example: pvpanic device -- currently only in SeaBIOS.) It worries me that if I slack off, or am busy with something else, or simply don't notice, then the gap will widen again. I appreciate learning a bunch about ACPI, and don't mind the days of work that went into some of my simple-looking ACPI patches for OVMF, but had the tables come from a common (programmatic) source, none of this would have been an issue, and I wouldn't have felt even occasionally that ACPI patches for OVMF were both duplicate work *and* futile (considering how much ahead SeaBIOS was). I don't mind reimplementing stuff, or porting it with permission, going forward, but the sophisticated parts in SeaBIOS are a hard nut. For example I'll never be able to auto-extract offsets from generated AML and patch the AML using those offsets; the edk2 build tools (a project separate from edk2) don't support this, and it takes several months to get a thing as simple as gcc-47 build flags into edk2-buildtools. Instead I have to write template ASL, compile it to AML, hexdump the result, verify it against the AML grammar in the ACPI spec (offsets aren't obvious, BytePrefix and friends are a joy), define initialize a packed struct or array in OVMF, and patch the template AML using fixed field names or array subscripts. Workable, but dog slow. If the ACPI payload came from up above, we might be as well provided with a list of (canonical name, offset, size) triplets, and could perhaps blindly patch the contents. (Not unlike Michael's linker code for connecting tables into a hierarchy.) AFAIK most recently iasl got built-in support for offset extraction (and in the process the current SeaBIOS build method was broken...), so that part might get easier in the future. Oh well it's Friday, sorry about this rant! :) I'll happily do what I can in the current status quo, but frequently, it won't amount to much. Thanks, Laszlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 *binary* form in the EDK2 repository, I believe, and its source code is elsewhere. We could happily make a GPL¹ or LGPL implementation of a FAT module and build our OVMF with that instead, and we wouldn't need to fork OVMF at all. -- dwmw2 ¹ If it's GPL, of course, then we mustn't include any *other* binary blobs in our OVMF build. But the whole point in this conversation is that we don't *want* to do that. So that's fine. smime.p7s Description: S/MIME cryptographic signature
Redirections from virtual interfaces.
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 all trafic to 192.168.122.200 eth0:2 xxx.xx.xxx.xxy redirec all trafic to 192.168.122.150 eth0:3 xxx.xx.xxx.xxz redirec all trafic to 192.168.122.180 I'm using /etc/libvirt/hooks/qemu to write iptables rules. Regards, -- Atenciosamente, Targino Silveira targinosilveira.com m...@targinosilveira.com +55(85)8626-7297/8779-5115 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 single module. Which is actually included in *binary* form in the EDK2 repository, I believe, and its source code is elsewhere. Correct. We could happily make a GPL¹ or LGPL implementation of a FAT module and build our OVMF with that instead, and we wouldn't need to fork OVMF at all. Yes, that's one plan, *if* someone can sort out, or is willing to shoulder, the perhaps illogical but still worrisome surroundings of FatPkg / FatBinPkg. (I don't intend to spread FUD!) For example, if your employer authorizes you to implement GplFatPkg from scratch, and distribute it as an external module, I -- as someone without any education in law though -- will give you a standing ovation and buy you a case of beer at KVM Forum 2013. Deal? :) (You proved to have great leverage by getting the efi compat table extended, so... :)) ¹ If it's GPL, of course, then we mustn't include any *other* binary blobs in our OVMF build. But the whole point in this conversation is that we don't *want* to do that. So that's fine. Right. Eg. Shell1 is embedded as a pre-built binary, but that's just convenience, you can build the in-tree Shell2 from source afresh and embed that instead (and ship its source too). Laszlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 just add GPL code. It's an easily solvable problem. It's not optimal for the upstream first principle; still on soapbox OVMF is not Open Source so upstream first doesn't apply. At least, the FAT module is not Open Source. Bullet 8 from the Open Source Definition[1] 8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. License from OVMF FAT module[2]: Additional terms: In addition to the forgoing, redistribution and use of the code is conditioned upon the FAT 32 File System Driver and all derivative works thereof being used for and designed only to read and/or write to a file system that is directly managed by: Intel’s Extensible Firmware Initiative (EFI) Specification v. 1.0 and later and/or the Unified Extensible Firmware Interface (UEFI) Forum’s UEFI Specifications v.2.0 and later (together the “UEFI Specifications”); only as necessary to emulate an implementation of the UEFI Specifications; and to create firmware, applications, utilities and/or drivers. [1] http://opensource.org/osd-annotated [2] http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Edk2-fat-driver AFAIK, for the systems that we'd actually want to use OVMF for, a FAT module is a hard requirement. we'd have to backport upstream edk2 patches forever (there's a whole lot of edk2 modules outside of direct OvmfPkg that get built into OVMF.fd -- OvmfPkg only customizes / cherry-picks the full edk2 tree for virtual machines), or to periodically rebase an ever-increasing set of patches. Independently, we need *some* FAT driver (otherwise you can't even boot most installer media), which is where the already discussed worries lie. Whatever solves this aspect is independent of forking all of edk2. It's either Open Source or it's not. It's currently not. I have a hard time sympathesizing with trying to work with a proprietary upstream. Rewriting BSD implementations of everything is silly. Every other vendor that uses TianoCore has a proprietary fork. Correct, but they (presumably) keep rebasing their ever accumulating stuff at least on the periodically refreshed stable edk2 subset (UDK2010, which BTW doesn't include OvmfPkg). This must be horrible for them, but in exchange they get to remain proprietary (which may benefit them commercially). Maintaining a GPL fork seems just as reasonable. Perhaps; diverging from upstream first would hurt for certain. Well I'm suggesting creating a real upstream (that is actually Open Source). Then I'm all for upstream first. 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. If that's inevitable, then we're wasting effort by rewriting stuff under a BSD license. Regards, Anthony Liguori /soapbox Thanks for the suggestion :) Laszlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 single module. Which is actually included in *binary* form in the EDK2 repository, I believe, and its source code is elsewhere. We could happily make a GPL¹ or LGPL implementation of a FAT module and build our OVMF with that instead, and we wouldn't need to fork OVMF at all. So can't we have GPL virtio modules too? I don't think there's any problem there except for the FAT module. I would propose more of a virtual fork. It could consist of a git repo with the GPL modules + a submodule for edk2. Ideally, there would be no need to actually fork edk2. My assumption is that edk2 won't take GPL code. But does ovmf really need to live in the edk2 tree? If we're going to get serious about supporting OVMF, it we need something that isn't proprietary. -- dwmw2 ¹ If it's GPL, of course, then we mustn't include any *other* binary blobs in our OVMF build. But the whole point in this conversation is that we don't *want* to do that. So that's fine. It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source. Without even tackling the issue of GPL code sharing, that is a fundamental problem that needs to be solved if we're going to serious about making changes to QEMU to support it. I think solving the general problem will also enable GPL code sharing though. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH] virtio-spec: small English/punctuation corrections
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 6e188d0..7e4ce71 100644 --- a/virtio-spec.lyx +++ b/virtio-spec.lyx @@ -116,7 +116,7 @@ description Peripheral Component Interconnect; a common device bus. Seehtt \end_inset devices. - These are devices are found in + These devices are found in \emph on virtual \emph default @@ -1558,7 +1558,7 @@ name sub:Feature-Bits \end_layout \begin_layout Standard -Thefirst configuration field indicates the features that the device supports. +The first configuration field indicates the features that the device supports. The bits are allocated as follows: \end_layout @@ -2919,7 +2919,7 @@ For each ring, guest should then disable interrupts by writing VRING_AVAIL_F_NO_ INTERRUPT flag in avail structure, if required. It can then process used ring entries finally enabling interrupts by clearing the VRING_AVAIL_F_NO_INTERRUPT flag or updating the EVENT_IDX field in - the available structure, Guest should then execute a memory barrier, and + the available structure. Guest should then execute a memory barrier, and then recheck the ring empty condition. This is necessary to handle the case where, after the last check and before enabling interrupts, an interrupt has been suppressed by the device: -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository. So I think you're massively overstating the issue. OVMF/EDK2 *is* Open Source, and replacing the FAT module really isn't that hard. We can only bury our heads in the sand and ship qemu with non-EFI-capable firmware for so long... I *know* there's more work to be done. We have SeaBIOS-as-CSM, Jordan has mostly sorted out the NV variable storage, and now the FAT issue is coming up to the top of the pile. But we aren't far from the point where we can realistically say that we want the Open Source OVMF to be the default firmware shipped with qemu. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: KVM call agenda for 2013-05-28
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 time sympathesizing with trying to work with a proprietary upstream. My experience has been positive. First of all, whether UEFI is a good thing or not is controversial. I won't try to address that. However UEFI is here to stay, machines are being shipped with it, Linux and other OSen try to support it. Developing (or running) an OS in combination with a specific firmware is sometimes easier / more economic in a virtual environment, hence there should be support for qemu + UEFI. It is this mindset that I operate in. (Oh, I also forgot to mention that this task has been assigned to me by my superiors as well :)) Jordan, the OvmfPkg maintainer is responsive and progressive in the true FLOSS manner (*), which was a nice surprise for a project whose coding standards for example are made 100% after Windows source code, and whose mailing list is mostly subscribed to by proprietary vendors. Really when it comes to OvmfPkg patches the process follows the normal FLOSS development model. (*) Jordan, I hope this will prompt you to merge VirtioNetDxe v4 real soon now :) I personally think the 2-clause BSDL for 99% of the project was a very sane and practical one from Intel et al. FatPkg is a sad exception. One might even consider it a bad accident: http://thread.gmane.org/gmane.comp.bios.tianocore.devel/1861/focus=1878 I have no idea how that selection process went down, but I assume if FLOSS people had been screaming very loud at that time and had offered a *simple* (which ext2 is not, I gather), wide-spread and unencumbered filesystem, things would be different today. 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. If that's inevitable, then we're wasting effort by rewriting stuff under a BSD license. Please ask your employer if they'd be willing to put their name on an original, clean-room, GPL-licensed implementation of FAT32 for UEFI. Thus far we've been talking copyright rather than patents, but there's also this: http://en.wikipedia.org/wiki/FAT_filesystem#Challenge http://en.wikipedia.org/wiki/FAT_filesystem#Patent_infringement_lawsuits It almost doesn't matter who prevails in such a lawsuit; the *possibility* of such a lawsuit gives people cold feet. Blame the USPTO. Laszlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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. It's modular, and the FAT driver is just a single module. Which is actually included in *binary* form in the EDK2 repository, I believe, and its source code is elsewhere. We could happily make a GPL¹ or LGPL implementation of a FAT module and build our OVMF with that instead, and we wouldn't need to fork OVMF at all. So can't we have GPL virtio modules too? I don't think there's any problem there except for the FAT module. I share your assessment. I would propose more of a virtual fork. It could consist of a git repo with the GPL modules + a submodule for edk2. Ideally, there would be no need to actually fork edk2. Indeed. edk2 is extremely modular. But in order to get a useful firmware image ultimately, you need a FAT driver. My assumption is that edk2 won't take GPL code. Correct, see eg. OvmfPkg/Contributions.txt. Laszlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 you're right. But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository. Yes. *Some* FAT module is a hard requirement. So I think you're massively overstating the issue. OVMF/EDK2 *is* Open Source, Agreed, and replacing the FAT module really isn't that hard. technically it's not hard; for a seasoned file system developer (which I'm not, of course), even possibly missing UEFI bits, it should be children's play actually, considering the high quality of UEFI documentation and the responsiveness of edk2-devel. Considering US legal climate however, it appears *extremely* hard to replace the FAT module, in my unwashed personal opinion. Laszlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 sense you're right. But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository. So *if* we replace the FAT module *and* that replacement was GPL, would there be any objects to having more GPL modules for things like virtio, ACPI, etc? And would that be doable in the context of OVMF or would another project need to exist for this purpose? So I think you're massively overstating the issue. OVMF/EDK2 *is* Open Source, and replacing the FAT module really isn't that hard. We can only bury our heads in the sand and ship qemu with non-EFI-capable firmware for so long... Which is why I think we need to solve the real problem here. I *know* there's more work to be done. We have SeaBIOS-as-CSM, Jordan has mostly sorted out the NV variable storage, and now the FAT issue is coming up to the top of the pile. But we aren't far from the point where we can realistically say that we want the Open Source OVMF to be the default firmware shipped with qemu. Yes, that's why I'm raising this now. We all knew that we'd have to talk about this eventually. Regards, Anthony Liguori -- dwmw2 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 suggesting (from the soapbox :))? I have a hard time sympathesizing with trying to work with a proprietary upstream. My experience has been positive. First of all, whether UEFI is a good thing or not is controversial. I won't try to address that. However UEFI is here to stay, machines are being shipped with it, Linux and other OSen try to support it. Developing (or running) an OS in combination with a specific firmware is sometimes easier / more economic in a virtual environment, hence there should be support for qemu + UEFI. It is this mindset that I operate in. (Oh, I also forgot to mention that this task has been assigned to me by my superiors as well :)) Jordan, the OvmfPkg maintainer is responsive and progressive in the true FLOSS manner (*), which was a nice surprise for a project whose coding standards for example are made 100% after Windows source code, and whose mailing list is mostly subscribed to by proprietary vendors. Really when it comes to OvmfPkg patches the process follows the normal FLOSS development model. (*) Jordan, I hope this will prompt you to merge VirtioNetDxe v4 real soon now :) (Removing seabios from the CC as we've moved far away from seabios as a topic) Just so no one gets the wrong idea, the OVMF team is now a victim of their own success. I had hoped that no one would do the work necessary to get us to the point where we had to seriously think about UEFI support but that's where we are now :-) Thus far we've been talking copyright rather than patents, but there's also this: http://en.wikipedia.org/wiki/FAT_filesystem#Challenge http://en.wikipedia.org/wiki/FAT_filesystem#Patent_infringement_lawsuits It almost doesn't matter who prevails in such a lawsuit; the *possibility* of such a lawsuit gives people cold feet. Blame the USPTO. Just to say it once so I don't have to ever say it again. I'm not going to discuss anything relating to patents and FAT publicly. Everyone should consult with their respective lawyers on such issues. Copyright is straight forward. Patents are not. Regards, Anthony Liguori Laszlo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 usable, and yes, that's not Open Source. So in a sense you're right. But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository. So *if* we replace the FAT module *and* that replacement was GPL, would there be any objects to having more GPL modules for things like virtio, ACPI, etc? And would that be doable in the context of OVMF or would another project need to exist for this purpose? I don't think it would be doable in TianoCore. I think it would end up either in distros, or in QEMU. A separate question is whether OVMF makes more sense as part of TianoCore or rather as part of QEMU. With 75% of the free hypervisors now reunited under the same source repository, the balance is tilting... Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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. 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 *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository. So *if* we replace the FAT module *and* that replacement was GPL, would there be any objects to having more GPL modules for things like virtio, ACPI, etc? And would that be doable in the context of OVMF or would another project need to exist for this purpose? I don't think it would be doable in TianoCore. I think it would end up either in distros, or in QEMU. 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. But this can be quite simple using a combination of git-svn and a rewriting script. We did exactly this to pull out the VGABios from Bochs and remove the binaries associated with it. It's 100% automated and can be kept in sync via a script on qemu.org. A separate question is whether OVMF makes more sense as part of TianoCore or rather as part of QEMU. I'm not sure if qemu.git is the right location, but we can certainly host an ovmf.git on qemu.git that embeds the scrubbed version of edk2.git. Of course, this would enable us to add GPL code (including a FAT module) to ovmf.git without any impact on upstream edk2. With 75% of the free hypervisors now reunited under the same source repository, the balance is tilting... insert evil laugh :-) Regards, Anthony Liguori Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 be a potential source? http://www.openbsd.org/cgi-bin/cvsweb/src/sys/msdosfs/ We have a half-done ext2 fs from GSoC2011 that started with OpenBSD. https://github.com/the-ridikulus-rat/Tianocore_Ext2Pkg If that's inevitable, then we're wasting effort by rewriting stuff under a BSD license. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 BSD licensed alternative was available. :) But, in thinking about what might make sense for EDK II with git, one option that should be considered is breaking the top-level 'packages' into separate sub-modules. I had gone so far as to start pushing repos as sub-modules. But, as the effort to convert EDK II to git has stalled (actually never even thought about leaving the ground), I abandoned that approach and went back to just mirroring one EDK II. I could fairly easily re-enable mirror the sub-set of packages needed for OVMF. So, in that case, the FatBinPkg sub-module could easily be dropped from a tree. But this can be quite simple using a combination of git-svn and a rewriting script. We did exactly this to pull out the VGABios from Bochs and remove the binaries associated with it. It's 100% automated and can be kept in sync via a script on qemu.org. I would love to mirror the BaseTools as a sub-package without all the silly windows binaries... What script did you guys use? -Jordan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
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? Yes. All code is either Stefan's or my own work or taken from Tiano and adapted. We will probably import some libpayload code, but that is BSD-l, too. Is this planned to be upstreamed? Yes, once it's ready. Does this support UEFI variables? Not yet, planned. Does this support UEFI IA32 / X64? Both, no mixed mode. Those are questions for Patrick. HTH, Patrick -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 GPL'd uefi implementation. Why would OpenBSD not be a potential source? http://www.openbsd.org/cgi-bin/cvsweb/src/sys/msdosfs/ If someone is going to do it, that's fine. But if me, it's going to be a GPL base. Actually, enabling GPL contributions to OVMF is a major motivating factor for me in this whole discussion. Regards, Anthony Liguori We have a half-done ext2 fs from GSoC2011 that started with OpenBSD. https://github.com/the-ridikulus-rat/Tianocore_Ext2Pkg If that's inevitable, then we're wasting effort by rewriting stuff under a BSD license. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 remove the binaries. No, probably not unless a BSD licensed alternative was available. :) But, in thinking about what might make sense for EDK II with git, one option that should be considered is breaking the top-level 'packages' into separate sub-modules. I had gone so far as to start pushing repos as sub-modules. But, as the effort to convert EDK II to git has stalled (actually never even thought about leaving the ground), I abandoned that approach and went back to just mirroring one EDK II. I could fairly easily re-enable mirror the sub-set of packages needed for OVMF. So, in that case, the FatBinPkg sub-module could easily be dropped from a tree. But this can be quite simple using a combination of git-svn and a rewriting script. We did exactly this to pull out the VGABios from Bochs and remove the binaries associated with it. It's 100% automated and can be kept in sync via a script on qemu.org. I would love to mirror the BaseTools as a sub-package without all the silly windows binaries... What script did you guys use? We did this in git pre-history, now git has a fancy git-filter-branch command that makes it a breeze: http://git-scm.com/book/ch6-4.html Regards, Anthony Liguori -Jordan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 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 source? http://www.openbsd.org/cgi-bin/cvsweb/src/sys/msdosfs/ If someone is going to do it, that's fine. But if me, it's going to be a GPL base. Of potential modules for GPL, this wouldn't be my first choice. For EDK II it would be nice if all the core essential pieces were BSD licensed. This allows more flexibility for those that don't want to use GPL. 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. (But, it does seem fair. :) Actually, enabling GPL contributions to OVMF is a major motivating factor for me in this whole discussion. I wouldn't mind figuring out a way to allow GPL components for people that prefer that. EDK II has thus far not proved very welcoming on this front. I think the main repo will remain BSD though. I think that the sub-modules option is the best way to address this. But, I'm not going to bother with creating the sub-module repos if no one is going to use them. (As it was in the past.) -Jordan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
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 coreboot+seabios the default QEMU firmware, and making seabios depend on being a coreboot payload? load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), It wouldn't be loading OVMF. It would be loading CorebootPkg. OVMF is a better sample platform for EDK II since it shows a more realistic view of what an EDK II based platform looks like on real hardware. Thus, if the ACPI tables are just being added to a new coreboot layer with coreboot becoming the default QEMU firmware, then it doesn't help OVMF (or other non-coreboot payloads). Well, it could if the table code was BSD licensed, but only so we could then merge them into OVMF. Then again, why not just provide a set of suitably licensed ACPI source files within the QEMU tree that firmware projects could use? QEMU doesn't necessarily need to build/link them, or attempt to communicate them at runtime. -Jordan The coreboot rom has named sections (this is called cbfs which stands for coreboot filesystem IIRC): rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin0x0cmos_layout 1160 fallback/romstage 0x4c0 stage14419 fallback/coreboot_ram 0x3d80 stage37333 config 0xcfc0 raw 2493 fallback/payload 0xd9c0 payload 56969 vgabios/sgabios0x1b8c0raw 4096 (empty)0x1c900null 144216 where fallback/payload is seabios. 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 informations from coreboot that way. HTH, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 would do the qemu specific platform init (pci init, smm init, mtrr init, bios tables) and then load and run the regular seabios rom. What about a small change to the SeaBIOS build system to allow ACPI table generation to be done via a plugin. Using a runtime plugin (eg, qplugin) would require a more complex handoff then qvmloader. With qplugin, seabios would need to know what memory qplugin is compiled to run in and make sure it didn't allocate anything there. Similarly, qplugin would need to not stomp on seabios while it runs, and it would need to coordinate with seabios where to place the final tables. With qvmloader, there is no need to coordinate memory addresses, so it can run anywhere, deploy the tables in their final location, and then launch seabios. This could be as simple as moving acpi.c and *.dsl into the QEMU build tree and then having a way to point the SeaBIOS makefiles to our copy of it. I don't see how that would work. It would complicate the seabios build (as it would require a copy of qemu source to compile), and the resulting seabios binary would be strongly tied to the qemu version it was compiled with and vice-versa. This would break distro seabios rpms. It would also cause great pain when bisecting and would be confusing even during regular compile/debug cycles. Internal seabios calls (eg, memory allocations, pci config accesses) would need to be static interfaces, etc. -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2013-05-28
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 GPL'd FAT driver. What would you suggest? Wasn't that a few levels up in this thread? (And properly phased in the form of a question, no less! :) -Jordan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] KVM call agenda for 2013-05-28
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) and then load and run the regular seabios rom. qvmloader sounds a lot like coreboot. Agreed. I don't much like the qvmloader idea. I did want to open up discussion on the possibility, however. The only advantage it has over coreboot is that it could reasonably live in the qemu repo, and I do think that the hardware descriptions should like in the same code repo as the hardware implementation. -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] kvm/ppc/booke64: fix build breakage from Altivec, and disable e6500
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 that'd be soon, right?), we can add e6500 back to the list. Am I going to see an Altivec patch soon, or should I ask Gleb to take this patch instead? Yes, I will add ONE_REG support today and send it on the list. -Mike -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
