Re: MTRR setup in OVMF [was: PATCH v3 01/10 KVM: MMU: fix decoding cache type from MTRR]
On 2015-07-14 14:29:11, Laszlo Ersek wrote: On 07/14/15 23:15, Paolo Bonzini wrote: The long delay that Alex reported (for the case when all guest memory was set to UC up-front) is due to the fact that the SEC phase of OVMF decompresses an approximately 1712 KB sized, LZMA-compressed blob, to approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI drivers -- and this decompression is extremely memory-intensive. (When Jordan implemented that reset vector first, we saw similar performance degradation on AMD hosts (albeit not due to MTRR but due to page attributes). See https://github.com/tianocore/edk2/commit/98f378a7. I'm only mentioning it here because it makes me appreciate the current problem report.) Anyway, the reset vector's page table building is implemented in OvmfPkg/ResetVector/Ia32/PageTables64.asm. The decompression in SEC can be found in OvmfPkg/Sec/SecMain.c, function DecompressMemFvs(). Perhaps the OVMF reset vector should initialize the MTRRs for the BSP? That's an idea, yes, if someone feels sufficiently drawn to writing assembly. Maybe we can use MtrrLib in the SEC C code? -Jordan Complications: - the reset vector is specific to OvmfPkg only in the OvmfPkgX64.dsc build - it needs to be determined what memory to cover. I think SEC doesn't do any MMIO, so it should be enough to enable MTRRs and set the default type to writeback. Seems safe to me, off the top of my head (and testing could confirm / disprove quickly). In any case we're going to have to quirk it, because of the broken guests in the wild. 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 Sun, Jun 2, 2013 at 2:43 AM, Michael S. Tsirkin m...@redhat.com wrote: On Fri, May 31, 2013 at 01:45:55PM +0200, Laszlo Ersek wrote: On 05/31/13 09:09, Jordan Justen wrote: Why is updating the ACPI tables in seabios viewed as such a burden? Either qemu does it, or seabios... (And, OVMF 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. You guys should take a look at the patch series I posted. That's solved there by the means of keeping iasl output in qemu git tree. configure checks for a working iasl and enables/disables using this pre-processed output accordingly. Everyone developing ASL code would still need working iasl but that's already the case today. I'm sorry the I haven't had time to review your series yet. But, from what you saying about it in this thread, it sounds like a good plan. -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: [PATCH uq/master] fix double free the memslot in kvm_set_phys_mem
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On Fri, May 31, 2013 at 1:52 AM, 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
---
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: 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: 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: 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 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: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
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? And it helps to dispel the stupid misconception in some quarters that Coreboot *competes* with UEFI and thus cannot possibly be supported because helping something that competes with UEFI would be bad. Coreboot and EDK II both provide a good infrastructure for initializing hardware. So, they compete on that point. Coreboot then focuses on booting coreboot payloads, while EDK II focuses on UEFI support. On that point they don't compete, but the focus is different. Of course, you can build a layer of EDK II = Coreboot payload support, or Coreboot = EDK II (CorebootPkg, I guess?), but the match will not be perfect. (That is not to say it can't work.) I'm not sure who do you mean by some quarters, but for some distributions Coreboot would be yet another component (package) to support, for no obvious benefit. (Gerd said it better than I possibly could: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705.) Yeah, but if we're shoving a lot of hardware-specific ACPI table generation into the guest's firmware, instead of just doing it on the qemu side where a number of us seem to think it belongs, then there *is* a benefit to using Coreboot. When stuff changes on the qemu side and we have to update the table generation to match, you end up having to update just the Coreboot package, and *not* having to patch both SeaBIOS and OVMF. I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? -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 Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek ler...@redhat.com wrote: On 05/30/13 18:20, Jordan Justen wrote: I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? 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, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project. I guess. For reference, I believe that both Xen and virtualbox build ACPI table in the VMM rather than firmware. They both dump the tables into the 0xe000 segment (yuck) where firmware finds and publishes it to the OS. I think fw-cfg would be a reasonable alternative to this for communicating the tables. -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
[PATCH] kvm: always define KVM_CAP_READONLY_MEM
Don't use #ifdef __KVM_HAVE_READONLY_MEM when defining
KVM_CAP_READONLY_MEM.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Cc: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
Cc: Jan Kiszka jan.kis...@siemens.com
---
include/uapi/linux/kvm.h |2 --
1 file changed, 2 deletions(-)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 3c56ba3..26a04e5 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -655,9 +655,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_PPC_GET_SMMU_INFO 78
#define KVM_CAP_S390_COW 79
#define KVM_CAP_PPC_ALLOC_HTAB 80
-#ifdef __KVM_HAVE_READONLY_MEM
#define KVM_CAP_READONLY_MEM 81
-#endif
#define KVM_CAP_IRQFD_RESAMPLE 82
#define KVM_CAP_PPC_BOOKE_WATCHDOG 83
#define KVM_CAP_PPC_HTAB_FD 84
--
1.7.10.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: [Qemu-devel] KVM/QEMU: Support executing from flash device
On Sun, Mar 4, 2012 at 02:46, Avi Kivity a...@redhat.com wrote: On 03/04/2012 12:38 PM, Gleb Natapov wrote: On Sun, Mar 04, 2012 at 12:36:20PM +0200, Avi Kivity wrote: On 03/04/2012 10:12 AM, Gleb Natapov wrote: On Sat, Mar 03, 2012 at 10:56:02PM -0800, Jordan Justen wrote: On Tue, Oct 25, 2011 at 00:47, Avi Kivity a...@redhat.com wrote: The core issue that kvm (the kernel part) supports two styles of memory: read/write RAM, and read/write MMIO. ROM wants writes to be ignored, and rom/device wants reads serviced from memory and writes serviced by userspace (as MMIO). It should not be too hard to patch kvm to support these additional two styles. The entry point is the KVM_SET_USER_MEMORY_REGION ioctl to define the new attributes for the region, and kvm_mmu_page_fault() to map these pages as read-only and emulate writes (for ROM/device regions). Additional context for CC'd kvm-devel: I would like to support executing from an emulated flash memory on kvm. The flash memory would be a CFI (Firmware Hub-like) device which is programmed via MMIO at the same addresses in memory where the execution would occur. What is needed is: 1. The ability to set a region to allow read/exec, but trap to qemu on writes. 2. qemu should then be able to set the region to trap on reads/exec/writes. Do you want to execute code from a flash while it traps on read/exec? KVM emulator can't do that. No, he wants read/exec to go to RAM, and writes to be handled as mmio. This should work. That's mode 1 from above and will obviously work. I am asking about mode 2 from above. Mode 2 is pure mmio. You're right that kvm won't run code from that. Jordan, what's the use for mode 2? Is it just used during programming? Yes. It is the programming state for the flash, and no execution would occur from the region while it is in that state. At least for the flash that I'm interested in supporting (qemu:hw/pflash_cfi01.c), it would not be possible to execute from the flash in this mode because the entire region will no longer read-back the flash contents. -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
KVM/QEMU: Support executing from flash device
On Tue, Oct 25, 2011 at 00:47, Avi Kivity a...@redhat.com wrote: The core issue that kvm (the kernel part) supports two styles of memory: read/write RAM, and read/write MMIO. ROM wants writes to be ignored, and rom/device wants reads serviced from memory and writes serviced by userspace (as MMIO). It should not be too hard to patch kvm to support these additional two styles. The entry point is the KVM_SET_USER_MEMORY_REGION ioctl to define the new attributes for the region, and kvm_mmu_page_fault() to map these pages as read-only and emulate writes (for ROM/device regions). Additional context for CC'd kvm-devel: I would like to support executing from an emulated flash memory on kvm. The flash memory would be a CFI (Firmware Hub-like) device which is programmed via MMIO at the same addresses in memory where the execution would occur. What is needed is: 1. The ability to set a region to allow read/exec, but trap to qemu on writes. 2. qemu should then be able to set the region to trap on reads/exec/writes. 3. qemu should be able to then restore the region to the initial state. Here is my plan: 1. Add KVM_CAP_REGION_WRITE_TRAP 2. Add kvm_memory_region::flags KVM_MEMSLOT_TRAP_WRITES 3. Update page table creation to trap on writes when KVM_MEMSLOT_TRAP_WRITES is set Is this plan heading in the right direction? Regarding emulating ROM (as you mentioned above): I think that it can trap to qemu and QEMU can ignore it. This would be a performance hit, but I don't think it is expected that lots of writes to a ROM will occur. Do you agree? -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] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 7, 2011 at 11:44, Gleb Natapov g...@redhat.com wrote:
On Thu, Apr 07, 2011 at 01:37:14PM -0500, Anthony Liguori wrote:
The CS base starts out at 0xf and IP is 0xfff0. That gives a
real address of 0x0. This is usually a trampoline to somewhere
else in the space.
CS descriptor and CS selector don't have to be in sync (big real mode).
Indeed.
Another place this will often be seen is SMM, as the SMBASE can easily
be 1MB, but the SMM entry is in 16 bit mode.
KVM doesn't support SMM although that's not because of this. KVM
doesn't allow execution of ROM memory which makes it difficult to
implement PAM in the way it's intended to be implemented. This
makes SMM a bit tricky to make work. Since there's never really
been a pressing need to support SMM, to my knowledge, noone has even
tried.
KVM allows to execute ROM memory (BIOS and option roms run this way). It
just makes it indistinguishable from RAM, but read only memory slot
support shouldn't be too hard. Why ability to execute ROM memory is
needed to support SMM though?
True.
The only possible requirement is to 'hide SMRAM' when not in SMM mode.
Even this is chipset specific, and arguable depending on the goals of
SMM support in that system. (Although, generally, hiding SMRAM is a
requirement. :)
But, Anthony's point ('there's never really been a pressing need to
support SMM') is probably the most important here, as I can't see a
compelling use for SMM in QEMU.
-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] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 7, 2011 at 12:21, Anthony Liguori anth...@codemonkey.ws wrote: QEMU does the leg work already to support SMM. It doesn't work with KVM because we treat SMM as ROM memory and trap read/write access. To make it work with KVM, you'd have to hack things around to switch the VGA space to RAM in order to the let the SMM code run. It's not impossible, but that's the main reason it doesn't Just Work. Ah, SMM ASEG/BSEG? I think most recent firmware ignore that, use TSEG (some higher up memory) and run in protected mode. But, based on Gleb's other response, there are other, bigger issues as well... -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] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
On Thu, Apr 7, 2011 at 12:24, Olivier Galibert galib...@pobox.com wrote:
On Thu, Apr 07, 2011 at 12:03:41PM -0700, Jordan Justen wrote:
But, Anthony's point ('there's never really been a pressing need to
support SMM') is probably the most important here, as I can't see a
compelling use for SMM in QEMU.
Running real biosen instead of seabios? Of course that's mostly
useful when reverse-engineering devices, which is a borderline use of
kvm.
:)
Regarding QEMU, the only thing I can thing of (and this is a stretch)
is USB legacy support. In other words, being able to drop PS2
keyboard/mouse for USB, but still supporting legacy software via SMM.
This doesn't seem worth the effort by a long shot.
Another take on removing PS2 sounds more interesting to me: a
legacy-free PC qemu hardware skew, with a legacy-free firmware (OVMF
:) and only supporting legacy-free compatible OS's.
-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] Re: [PATCH 2/2] Make sure to enable dirty log tracking for VMware VGA
On Mon, Jun 8, 2009 at 2:53 PM, Anthony Liguorialigu...@us.ibm.com wrote: Anthony Liguori wrote: This is needed for VMware VGA to work properly under KVM. Signed-off-by: Anthony Liguori aligu...@us.ibm.com --- hw/vmware_vga.c | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c index bb17698..246011b 100644 --- a/hw/vmware_vga.c +++ b/hw/vmware_vga.c @@ -1203,6 +1203,10 @@ static void pci_vmsvga_map_mem(PCIDevice *pci_dev, int region_num, #endif cpu_register_physical_memory(s-vram_base, s-vga.vram_size, iomemtype); + + s-vga.map_addr = addr; + s-vga.map_end = addr + s-vga.vram_size; + vga_dirty_log_start(s-vga); } void pci_vmsvga_init(PCIBus *bus) N.B. depth is still screwed up with VMware vga but the fix for that looks a bit more non-obvious. This VBE issue has been a long standing problem though and I suspect it effects other guests though. I've tried booting Ubuntu 8.10/9.04 using '-vga vmware' on various versions of kvm and qemu. The result is always ok video during BIOS post, but garbage during pre and post X. Would this be a symptom of the 'VBE' issue that you mentioned? -- 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: [Qemu-devel] Re: [PATCH 2/2] Make sure to enable dirty log tracking for VMware VGA
On Wed, Jul 29, 2009 at 10:15 AM, Anthony Liguorianth...@codemonkey.ws wrote: Jordan Justen wrote: On Mon, Jun 8, 2009 at 2:53 PM, Anthony Liguorialigu...@us.ibm.com wrote: Anthony Liguori wrote: This is needed for VMware VGA to work properly under KVM. Signed-off-by: Anthony Liguori aligu...@us.ibm.com --- hw/vmware_vga.c | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c index bb17698..246011b 100644 --- a/hw/vmware_vga.c +++ b/hw/vmware_vga.c @@ -1203,6 +1203,10 @@ static void pci_vmsvga_map_mem(PCIDevice *pci_dev, int region_num, #endif cpu_register_physical_memory(s-vram_base, s-vga.vram_size, iomemtype); + + s-vga.map_addr = addr; + s-vga.map_end = addr + s-vga.vram_size; + vga_dirty_log_start(s-vga); } void pci_vmsvga_init(PCIBus *bus) N.B. depth is still screwed up with VMware vga but the fix for that looks a bit more non-obvious. This VBE issue has been a long standing problem though and I suspect it effects other guests though. I've tried booting Ubuntu 8.10/9.04 using '-vga vmware' on various versions of kvm and qemu. The result is always ok video during BIOS post, but garbage during pre and post X. Would this be a symptom of the 'VBE' issue that you mentioned? Try the latest qemu git. vmware vga should work there. I'm not sure about qemu-kvm. It depends on whether the changes survived the merge. Yes, this is one of the combinations I tried. Latest qemu from git with your two patches applied. Do you have another distro which you might recommend trying? (Although, I'm not too confident this would be the problem.) 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: [PATCH 1/3] Update BIOS INT15-E820 to allow a larger BIOS image
On Tue, Jul 28, 2009 at 7:40 AM, Marcelo Tosattimtosa...@redhat.com wrote: On Sun, Jul 26, 2009 at 05:23:51PM -0700, Jordan Justen wrote: The bios will now reserve more memory via the E820 functions. Note that the standard KVM BIOS will most likely not make use of this expanded BIOS region. This change will synchronize the BIOS INT15-E820 reservations to match other changes that will allow alternate BIOS images to be larger in size. Previously the BIOS reserved: 0xfffbc000-0xfffbcfff - 4KB - EPT identity mapping pages 0xfffbd000-0xfffb - 12KB - TSS pages 0xfffc-0x - 256KB - Max bios.bin (usually top 128KB is used) Now the BIOS will reserve: 0xfeffc000-0xfeffcfff - 4KB - EPT identity mapping pages 0xfeffd000-0xfeff - 12KB - TSS Pages 0xff00-0x - 16MB - Max bios.bin Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- kvm/bios/rombios.c | 8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c index 6186199..2d0c153 100644 --- a/kvm/bios/rombios.c +++ b/kvm/bios/rombios.c @@ -4596,14 +4596,14 @@ ASM_END case 5: /* 4 pages before the bios, 3 pages for vmx tss pages, * the other page for EPT real mode pagetable */ - set_e820_range(ES, regs.u.r16.di, 0xfffbc000L, - 0xfffcL, 0, 0, 2); + set_e820_range(ES, regs.u.r16.di, 0xfeffc000L, + 0xff00L, 0, 0, 2); regs.u.r32.ebx = 6; So if you use an older kernel, and the kvm_set_identity_map_addr fails, you get the e820 entry wrong right? Perhaps you should use the hw/fw_cfg.c interface to communicate with the BIOS. If you use this newer BIOS code with the older kernel code, the expanded E820 BIOS region of the will cover the older region where the EPT page tables are at. So, the OS will still know to keep away from this region. There should be no impact if someone uses a newer qemu-kvm with and older kvm module. Since the normal legacy kvm BIOS is only 128KB, it will be able to boot fine. (There will be no conflict with reserving the memory region for the small BIOS.) If a bios.bin is used that is larger than 256KB, then it will fail in the same way as today, since there will be a conflict while trying to reserve the 0xfffbc000 - 0xfffbcfff region. The only difference in this case would be that E820 reserves a larger chunk of memory space, but I can't see how this could cause a problem. (Previously kvm-bios would reserve 256KB while the BIOS was normally only 128KB in size.) break; case 6: - /* 256KB BIOS area at the end of 4 GB */ + /* 16MB BIOS area at the end of 4 GB */ set_e820_range(ES, regs.u.r16.di, - 0xfffcL, 0xL ,0, 0, 2); + 0xff00L, 0xL ,0, 0, 2); if (extra_highbits_memory_size || extra_lowbits_memory_size) regs.u.r32.ebx = 7; else -- 1.6.0.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 -- 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
[PATCH 0/3] Allow larger BIOS image
From: Jordan Justen jljus...@gmail.com These changes are similar to my patches sent July 16, except they now are based on Yang Sheng's recent changes to enable a new ioctl for controlling the EPT identity mapping page location. -Jordan Jordan Justen (3): Update BIOS INT15-E820 to allow a larger BIOS image Move TSS pages to allow a larger BIOS image Move EPT identity mapping pages to allow a larger BIOS image kvm/bios/rombios.c |8 qemu-kvm-x86.c |4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) -- 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 1/3] Update BIOS INT15-E820 to allow a larger BIOS image
The bios will now reserve more memory via the E820 functions. Note that the standard KVM BIOS will most likely not make use of this expanded BIOS region. This change will synchronize the BIOS INT15-E820 reservations to match other changes that will allow alternate BIOS images to be larger in size. Previously the BIOS reserved: 0xfffbc000-0xfffbcfff - 4KB - EPT identity mapping pages 0xfffbd000-0xfffb - 12KB - TSS pages 0xfffc-0x - 256KB - Max bios.bin (usually top 128KB is used) Now the BIOS will reserve: 0xfeffc000-0xfeffcfff - 4KB - EPT identity mapping pages 0xfeffd000-0xfeff - 12KB - TSS Pages 0xff00-0x - 16MB - Max bios.bin Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- kvm/bios/rombios.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c index 6186199..2d0c153 100644 --- a/kvm/bios/rombios.c +++ b/kvm/bios/rombios.c @@ -4596,14 +4596,14 @@ ASM_END case 5: /* 4 pages before the bios, 3 pages for vmx tss pages, * the other page for EPT real mode pagetable */ -set_e820_range(ES, regs.u.r16.di, 0xfffbc000L, - 0xfffcL, 0, 0, 2); +set_e820_range(ES, regs.u.r16.di, 0xfeffc000L, + 0xff00L, 0, 0, 2); regs.u.r32.ebx = 6; break; case 6: -/* 256KB BIOS area at the end of 4 GB */ +/* 16MB BIOS area at the end of 4 GB */ set_e820_range(ES, regs.u.r16.di, - 0xfffcL, 0xL ,0, 0, 2); + 0xff00L, 0xL ,0, 0, 2); if (extra_highbits_memory_size || extra_lowbits_memory_size) regs.u.r32.ebx = 7; else -- 1.6.0.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
[PATCH 2/3] Move TSS pages to allow a larger BIOS image
Move from:
0xfffbd000-0xfffb
to:
0xfeffd000-0xfeff
This step is required to free up the 0xff00-0x (16MB) range
for use with bios.bin.
This change depends upon a change to kvm/bios/rombios.c so the bios
INT15-E820 function will properly reserve the new location.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
qemu-kvm-x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 492dbc5..0b47b57 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -62,7 +62,7 @@ static int kvm_init_tss(kvm_context_t kvm)
* this address is 3 pages before the bios, and the bios should
present
* as unavaible memory
*/
- r = kvm_set_tss_addr(kvm, 0xfffbd000);
+ r = kvm_set_tss_addr(kvm, 0xfeffd000);
if (r 0) {
fprintf(stderr, kvm_init_tss: unable to set tss
addr\n);
return r;
--
1.6.0.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
[PATCH 3/3] Move EPT identity mapping pages to allow a larger BIOS image
Move from:
0xfffbc000-0xfffbcfff
to:
0xfeffc000-0xfeffcfff
This step is required to free up the 0xff00-0x (16MB) range
for use with bios.bin.
The KVM kernel change depends upon a change to kvm/bios/rombios.c so the bios
INT15-E820 function will properly reserve the new location.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
qemu-kvm-x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 0b47b57..65ba470 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -102,7 +102,7 @@ static int kvm_init_identity_map_page(kvm_context_t kvm)
* this address is 4 pages before the bios, and the bios should
present
* as unavaible memory
*/
- r = kvm_set_identity_map_addr(kvm, 0xfffbc000);
+ r = kvm_set_identity_map_addr(kvm, 0xfeffc000);
if (r 0) {
fprintf(stderr, kvm_init_identity_map_page:
unable to set identity mapping addr\n);
--
1.6.0.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: [PATCH] Update qemu-kvm to allow a larger BIOS image.
On Wed, Jul 15, 2009 at 10:37 PM, Sheng Yangsh...@linux.intel.com wrote: Make sense to me. So what's mattered here is not bios, but qemu-kvm and kvm code. The user can replace bios binary by UEFI binary easily, but not with kvm related part. I realized you still need separate the qemu-kvm patch into two: one for bios and another for qemu. Okay, I will split this change apart. And I just hope this modification won't break some old OS(any OS got assumption about bios size? I think Tiano team should have idea on it)... I don't think the OS should care about the bios size, but it is important to update the INT15-E820 memory ranges to help make sure the OS knows which regions are in use. Even without the E820 change, I think it would be unlikely for an OS to try utilize these memory regions, but it is definitely better to properly describe it. -- 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 2/3] Move qemu-kvm 'VMC TSS Pages' to allow a larger BIOS image.
Move qemu-kvm 'VMC TSS Pages' from:
0xfffbd000-0xfffb
to:
0xfeffd000-0xfeff
The step is required to free up the 0xff00-0x (16MB) range
for use with bios.bin.
This change depends upon a change to kvm/bios/rombios.c so the bios
INT15-E820 function will properly reserve the new location.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
qemu-kvm-x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index daf60b6..b5306aa 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -63,7 +63,7 @@ static int kvm_init_tss(kvm_context_t kvm)
* this address is 3 pages before the bios, and the bios should
present
* as unavaible memory
*/
- r = kvm_set_tss_addr(kvm, 0xfffbd000);
+ r = kvm_set_tss_addr(kvm, 0xfeffd000);
if (r 0) {
fprintf(stderr, kvm_init_tss: unable to set tss
addr\n);
return r;
--
1.6.0.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
[PATCH 1/3] Update qemu-kvm bios to allow for a larger bios image.
The bios will now reserve more memory via the E820 functions. Previously we reserved: 0xfffbc000-0xfffbcfff - 4KB - KVM kernel module, EPT identity pages tables 0xfffbd000-0xfffb - 12KB - KVM bios, VMC TSS Pages 0xfffc-0x - 256KB - Max KVM bios.bin (usually top 128KB is used) Now we will reserve: 0xfeffc000-0xfeffcfff - 4KB - KVM kernel module, EPT identity pages tables 0xfeffd000-0xfeff - 12KB - KVM bios, VMC TSS Pages 0xff00-0x - 16MB - Max KVM bios.bin Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- kvm/bios/rombios.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c index 6186199..2d0c153 100644 --- a/kvm/bios/rombios.c +++ b/kvm/bios/rombios.c @@ -4596,14 +4596,14 @@ ASM_END case 5: /* 4 pages before the bios, 3 pages for vmx tss pages, * the other page for EPT real mode pagetable */ -set_e820_range(ES, regs.u.r16.di, 0xfffbc000L, - 0xfffcL, 0, 0, 2); +set_e820_range(ES, regs.u.r16.di, 0xfeffc000L, + 0xff00L, 0, 0, 2); regs.u.r32.ebx = 6; break; case 6: -/* 256KB BIOS area at the end of 4 GB */ +/* 16MB BIOS area at the end of 4 GB */ set_e820_range(ES, regs.u.r16.di, - 0xfffcL, 0xL ,0, 0, 2); + 0xff00L, 0xL ,0, 0, 2); if (extra_highbits_memory_size || extra_lowbits_memory_size) regs.u.r32.ebx = 7; else -- 1.6.0.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
[PATCH 3/3] Update VMX_EPT_IDENTITY_PAGETABLE_ADDR to synchronize with kernel code.
Although VMX_EPT_IDENTITY_PAGETABLE_ADDR does not appear to be used within
qemu-kvm, this change mirrors a similar change in the kernel kvm code.
The purpose is to move the KVM 'EPT Identity Pages' from:
0xfffbc000-0xfffbcfff
to:
0xfeffc000-0xfeffcfff
The step is required to free up the 0xff00-0x (16MB) range
for use with bios.bin.
The KVM kernel change depends upon a change to kvm/bios/rombios.c so the bios
INT15-E820 function will properly reserve the new location.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
kvm/include/x86/asm/vmx.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
index df8d4f9..99e2bb9 100644
--- a/kvm/include/x86/asm/vmx.h
+++ b/kvm/include/x86/asm/vmx.h
@@ -403,7 +403,7 @@ enum vmcs_field {
#define VMX_EPT_EXECUTABLE_MASK0x4ull
#define VMX_EPT_IGMT_BIT (1ull 6)
-#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfffbc000ul
+#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfeffc000ul
#define ASM_VMX_VMCLEAR_RAX .byte 0x66, 0x0f, 0xc7, 0x30
--
1.6.0.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: [PATCH 3/3] Update VMX_EPT_IDENTITY_PAGETABLE_ADDR to synchronize with kernel code.
On Thu, 2009-07-16 at 11:18 -0700, Marcelo Tosatti wrote:
On Thu, Jul 16, 2009 at 11:02:22AM -0700, Jordan Justen wrote:
Although VMX_EPT_IDENTITY_PAGETABLE_ADDR does not appear to be used within
qemu-kvm, this change mirrors a similar change in the kernel kvm code.
The purpose is to move the KVM 'EPT Identity Pages' from:
0xfffbc000-0xfffbcfff
to:
0xfeffc000-0xfeffcfff
The step is required to free up the 0xff00-0x (16MB) range
for use with bios.bin.
The KVM kernel change depends upon a change to kvm/bios/rombios.c so the
bios
INT15-E820 function will properly reserve the new location.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
kvm/include/x86/asm/vmx.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
index df8d4f9..99e2bb9 100644
--- a/kvm/include/x86/asm/vmx.h
+++ b/kvm/include/x86/asm/vmx.h
@@ -403,7 +403,7 @@ enum vmcs_field {
#define VMX_EPT_EXECUTABLE_MASK0x4ull
#define VMX_EPT_IGMT_BIT (1ull 6)
-#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfffbc000ul
+#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfeffc000ul
Won't this conflict with an older BIOS? (the e820 reserved entry on
older qemu-kvm+bios will not cover the EPT identity table on kernels
with this patch).
Perhaps add a new ioctl (similar to the tss one) to so userspace can set
the address?
I am not very familiar with the reasons why the EPT identity
page-table setup is happening within the kernel.
As it stands, there is the shared knowledge that the qemu-kvm bios
just happens to know that the kvm kernel code has reserved a
particular page of the address space.
It would be much easier to coordinate all the pieces if it were
all setup on the qemu-kvm side.
Is this possible?
#define ASM_VMX_VMCLEAR_RAX .byte 0x66, 0x0f, 0xc7, 0x30
--
1.6.0.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
--
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] Update KVM kernel module to allow a larger BIOS image.
Previously the KVM kernel module would allocate the address range
of 0xfffbc000-0xfffbcfff for the EPT Indentity Page Tables.
This change moves that to 0xfeffc000-0xfeffcfff.
Another issue related to this change is the VMC TSS Pages were
located at 0xfffbd000-0xfffb. This is controlled by the
qemu-kvm code. A separate change will move them to
0xfeffd000-0xfeff.
From a high level, these are the effects of these two changes:
Previously, the KVM would only accommodate a 256KB BIOS image. With
these changes, the BIOS image may now grow to 16MB.
Motivation for making these changes:
A larger firmware image size allows alternative BIOS images to be
used with KVM. Some possible uses are to enable UEFI firmware
or coreboot firmware. Additionally, an alternative firmware might
include a linux kernel+initrd payload, which would require several
megabytes.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
arch/x86/include/asm/vmx.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 272514c..0086332 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -372,7 +372,7 @@ enum vmcs_field {
#define VMX_EPT_EXECUTABLE_MASK0x4ull
#define VMX_EPT_IGMT_BIT (1ull 6)
-#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfffbc000ul
+#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfeffc000ul
#define ASM_VMX_VMCLEAR_RAX .byte 0x66, 0x0f, 0xc7, 0x30
--
1.6.0.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
[PATCH] Update qemu-kvm to allow a larger BIOS image.
Previously the KVM kernel module would allocate the address range
of 0xfffbc000-0xfffbcfff for the EPT Indentity Page Tables.
A separate patch is moving that to 0xfeffc000-0xfeffcfff.
This patch updates qemu-kvm to move the VMX TSS Pages update the
KVM BIOS code to update the E820 BIOS call memory reservations.
Previously, the VMC TSS Pages were located at 0xfffbd000-0xfffb.
This change moved them to 0xfeffd000-0xfeff.
This change also updates the KVM bios such that the E820 locations
are returned properly for these two changes.
From a high level, these are the effects of these two changes:
Previously, the KVM would only accommodate a 256KB BIOS image. With
these changes, the BIOS image may now grow to 16MB.
Motivation for making these changes:
A larger firmware image size allows alternative BIOS images to be
used with KVM. Some possible uses are to enable UEFI firmware
or coreboot firmware. Additionally, an alternative firmware might
include a linux kernel+initrd payload, which would require several
megabytes.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
kvm/bios/rombios.c|8
kvm/include/x86/asm/vmx.h |2 +-
qemu-kvm-x86.c|2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c
index 6186199..2d0c153 100644
--- a/kvm/bios/rombios.c
+++ b/kvm/bios/rombios.c
@@ -4596,14 +4596,14 @@ ASM_END
case 5:
/* 4 pages before the bios, 3 pages for vmx tss pages,
* the other page for EPT real mode pagetable */
-set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
- 0xfffcL, 0, 0, 2);
+set_e820_range(ES, regs.u.r16.di, 0xfeffc000L,
+ 0xff00L, 0, 0, 2);
regs.u.r32.ebx = 6;
break;
case 6:
-/* 256KB BIOS area at the end of 4 GB */
+/* 16MB BIOS area at the end of 4 GB */
set_e820_range(ES, regs.u.r16.di,
- 0xfffcL, 0xL ,0, 0, 2);
+ 0xff00L, 0xL ,0, 0, 2);
if (extra_highbits_memory_size ||
extra_lowbits_memory_size)
regs.u.r32.ebx = 7;
else
diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
index df8d4f9..99e2bb9 100644
--- a/kvm/include/x86/asm/vmx.h
+++ b/kvm/include/x86/asm/vmx.h
@@ -403,7 +403,7 @@ enum vmcs_field {
#define VMX_EPT_EXECUTABLE_MASK0x4ull
#define VMX_EPT_IGMT_BIT (1ull 6)
-#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfffbc000ul
+#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfeffc000ul
#define ASM_VMX_VMCLEAR_RAX .byte 0x66, 0x0f, 0xc7, 0x30
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index daf60b6..b5306aa 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -63,7 +63,7 @@ static int kvm_init_tss(kvm_context_t kvm)
* this address is 3 pages before the bios, and the bios should
present
* as unavaible memory
*/
- r = kvm_set_tss_addr(kvm, 0xfffbd000);
+ r = kvm_set_tss_addr(kvm, 0xfeffd000);
if (r 0) {
fprintf(stderr, kvm_init_tss: unable to set tss
addr\n);
return r;
--
1.6.0.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: [PATCH] Update qemu-kvm to allow a larger BIOS image.
On Wed, Jul 15, 2009 at 6:34 PM, Sheng Yang sh...@linux.intel.com wrote:
On Thursday 16 July 2009 08:12:15 Jordan Justen wrote:
Previously the KVM kernel module would allocate the address range
of 0xfffbc000-0xfffbcfff for the EPT Indentity Page Tables.
A separate patch is moving that to 0xfeffc000-0xfeffcfff.
Hi Jordan
You need one more patch for upstream kvm, to include the modification of
vmx.h.
I sent a separate patch for vmx.h for the
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tree. Do I
need a patch for another copy of vmx.h?
This patch updates qemu-kvm to move the VMX TSS Pages update the
KVM BIOS code to update the E820 BIOS call memory reservations.
Previously, the VMC TSS Pages were located at 0xfffbd000-0xfffb.
This change moved them to 0xfeffd000-0xfeff.
This change also updates the KVM bios such that the E820 locations
are returned properly for these two changes.
From a high level, these are the effects of these two changes:
Previously, the KVM would only accommodate a 256KB BIOS image. With
these changes, the BIOS image may now grow to 16MB.
Motivation for making these changes:
A larger firmware image size allows alternative BIOS images to be
used with KVM. Some possible uses are to enable UEFI firmware
or coreboot firmware. Additionally, an alternative firmware might
include a linux kernel+initrd payload, which would require several
megabytes.
I think if you update bios to UEFI, the E820 should be represented by UEFI
rather than current bios?
Yeah, that is true. But, that firmware would be separate from the qemu-kvm
tree at this time, right?
But, in this patch it is critical that the 'VMX TSS Pages' are moved within
qemu-kvm so the conflict with the larger bios.bin is removed.
--
regards
Yang, Sheng
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
kvm/bios/rombios.c | 8
kvm/include/x86/asm/vmx.h | 2 +-
qemu-kvm-x86.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c
index 6186199..2d0c153 100644
--- a/kvm/bios/rombios.c
+++ b/kvm/bios/rombios.c
@@ -4596,14 +4596,14 @@ ASM_END
case 5:
/* 4 pages before the bios, 3 pages for vmx tss
pages, * the other page for EPT real mode pagetable */
- set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
- 0xfffcL, 0, 0, 2);
+ set_e820_range(ES, regs.u.r16.di, 0xfeffc000L,
+ 0xff00L, 0, 0, 2);
regs.u.r32.ebx = 6;
break;
case 6:
- /* 256KB BIOS area at the end of 4 GB */
+ /* 16MB BIOS area at the end of 4 GB */
set_e820_range(ES, regs.u.r16.di,
- 0xfffcL, 0xL ,0, 0, 2);
+ 0xff00L, 0xL ,0, 0, 2);
if (extra_highbits_memory_size ||
extra_lowbits_memory_size) regs.u.r32.ebx = 7;
else
diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
index df8d4f9..99e2bb9 100644
--- a/kvm/include/x86/asm/vmx.h
+++ b/kvm/include/x86/asm/vmx.h
@@ -403,7 +403,7 @@ enum vmcs_field {
#define VMX_EPT_EXECUTABLE_MASK 0x4ull
#define VMX_EPT_IGMT_BIT (1ull 6)
-#define VMX_EPT_IDENTITY_PAGETABLE_ADDR 0xfffbc000ul
+#define VMX_EPT_IDENTITY_PAGETABLE_ADDR 0xfeffc000ul
#define ASM_VMX_VMCLEAR_RAX .byte 0x66, 0x0f, 0xc7, 0x30
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index daf60b6..b5306aa 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -63,7 +63,7 @@ static int kvm_init_tss(kvm_context_t kvm)
* this address is 3 pages before the bios, and the bios
should present
* as unavaible memory
*/
- r = kvm_set_tss_addr(kvm, 0xfffbd000);
+ r = kvm_set_tss_addr(kvm, 0xfeffd000);
if (r 0) {
fprintf(stderr, kvm_init_tss: unable to set tss
addr\n);
return r;
--
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] Update qemu-kvm to allow a larger BIOS image.
On Wed, Jul 15, 2009 at 8:08 PM, Sheng Yangsh...@linux.intel.com wrote:
On Thursday 16 July 2009 10:58:53 Jordan Justen wrote:
On Wed, Jul 15, 2009 at 6:34 PM, Sheng Yang sh...@linux.intel.com wrote:
On Thursday 16 July 2009 08:12:15 Jordan Justen wrote:
Motivation for making these changes:
A larger firmware image size allows alternative BIOS images to be
used with KVM. Some possible uses are to enable UEFI firmware
or coreboot firmware. Additionally, an alternative firmware might
include a linux kernel+initrd payload, which would require several
megabytes.
I think if you update bios to UEFI, the E820 should be represented by
UEFI rather than current bios?
Yeah, that is true. But, that firmware would be separate from the qemu-kvm
tree at this time, right?
Yes, so currently from QEmu-kvm side, I think it may not necessary to update,
for the patches haven't followed up yet...
Of the two patches (1. kvm kernel module, 2. qemu-kvm), I think it
is best if the qemu-kvm change happens first. Since the qemu-kvm
patch will cause the qemu-kvm bios to add more memory regions
as reserved, the new change to qemu-kvm will be compatible with
both the old and new versions of the kvm kernel module.
But, in this patch it is critical that the 'VMX TSS Pages' are moved within
qemu-kvm so the conflict with the larger bios.bin is removed.
Well, for we are using a small size bios now, and larger bios would be totally
another story, I don't think push the modification now to the upstream make
sense. These modification can go with further patches with UEFI at any time in
the future.
I am working on this UEFI firmware project which currently supports QEMU:
https://edk2.tianocore.org/OVMF.html
I would like it to also support KVM, and I found that it can already boot the
UEFI shell on KVM if these two patches are applied.
If these patches make some progress, I will update OVMF to reserve the
appropriate memory regions.
--
regards
Yang, Sheng
--
regards
Yang, Sheng
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
kvm/bios/rombios.c | 8
kvm/include/x86/asm/vmx.h | 2 +-
qemu-kvm-x86.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c
index 6186199..2d0c153 100644
--- a/kvm/bios/rombios.c
+++ b/kvm/bios/rombios.c
@@ -4596,14 +4596,14 @@ ASM_END
case 5:
/* 4 pages before the bios, 3 pages for vmx
tss pages, * the other page for EPT real mode pagetable */
- set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
- 0xfffcL, 0, 0, 2);
+ set_e820_range(ES, regs.u.r16.di, 0xfeffc000L,
+ 0xff00L, 0, 0, 2);
regs.u.r32.ebx = 6;
break;
case 6:
- /* 256KB BIOS area at the end of 4 GB */
+ /* 16MB BIOS area at the end of 4 GB */
set_e820_range(ES, regs.u.r16.di,
- 0xfffcL, 0xL ,0, 0,
2); + 0xff00L, 0xL
,0, 0, 2); if (extra_highbits_memory_size ||
extra_lowbits_memory_size) regs.u.r32.ebx = 7;
else
diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
index df8d4f9..99e2bb9 100644
--- a/kvm/include/x86/asm/vmx.h
+++ b/kvm/include/x86/asm/vmx.h
@@ -403,7 +403,7 @@ enum vmcs_field {
#define VMX_EPT_EXECUTABLE_MASK 0x4ull
#define VMX_EPT_IGMT_BIT (1ull 6)
-#define VMX_EPT_IDENTITY_PAGETABLE_ADDR 0xfffbc000ul
+#define VMX_EPT_IDENTITY_PAGETABLE_ADDR 0xfeffc000ul
#define ASM_VMX_VMCLEAR_RAX .byte 0x66, 0x0f, 0xc7, 0x30
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index daf60b6..b5306aa 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -63,7 +63,7 @@ static int kvm_init_tss(kvm_context_t kvm)
* this address is 3 pages before the bios, and the bios
should present * as unavaible memory
*/
- r = kvm_set_tss_addr(kvm, 0xfffbd000);
+ r = kvm_set_tss_addr(kvm, 0xfeffd000);
if (r 0) {
fprintf(stderr, kvm_init_tss: unable to set tss
addr\n); return r;
--
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
