-
Notifications
You must be signed in to change notification settings - Fork 891
Create LICENSE #2
Conversation
Add a top-level license file detectable by GitHub. It is created using GitHub's standard BSD 3-clause license template.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The license fits to the announcement at http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg02504.html.
It turns out one of the source files (core/page_walker.c) has a different license (Apache 2.0) due to historical reasons, so we have to find another LICENSE file template. My colleague is working on that. |
Is it possible to add the BSD 3-clause license to |
Makes sense. I believe the only license holder is Intel, since I was told the code was taken from another Intel software project. I'll check with my colleague to see if we can just replace the license for this file. Speaking of licenses, include/hax_interface.h and include/vcpu_state.h are basically the same code as target/i386/hax-interface.h in the QEMU tree, but the QEMU file has a GPLv2 license. I'm not sure if this inconsistency is an issue. Should we add the BSD license to the QEMU file, and perhaps remove the GPLv2 license? |
Adding the BSD license looks logical for me. I suggest to send a git patch for |
Glad to see this is happening, I was going to file an issue about this :) |
Thanks, I'll make the patch and send it to qemu-devel. As for |
|
Android Emulator may dynamically create and destroy temporary memory mappings at guest runtime for certain rendering tasks via hax_user_backed_ram_map() and hax_user_backed_ram_unmap() ($AOSP/external/qemu/target/i386/hax-mem.c), e.g.: hax_user_backed_ram_map() #1 1.1) ADD_RAMBLOCK (#1): HVA 0x14e070000..0x16e070000 1.2) SET_RAM2 (map #1): GPA 0x7dffff000..0x7fffff000 => HVA 0x14e070000..0x16e070000 hax_user_backed_ram_unmap() #1 1.3) SET_RAM2 (unmap #1): GPA 0x7dffff000..0x7fffff000 hax_user_backed_ram_map() #2 2.1) ADD_RAMBLOCK: (#2): HVA 0x14de70000..0x16de70000 The second ADD_RAMBLOCK call fails, because its HVA range overlaps with that of the first ADD_RAMBLOCK call. The problem is that the "map" step creates a RAM block, but the "unmap" step doesn't destroy it. Instead of adding a DEL_RAMBLOCK ioctl, simply exempt the caller from calling ADD_RAMBLOCK in the first place: - Introduce a new hax_memslot flag for "stand-alone" mappings. - Remove the ADD_RAMBLOCK call from hax_user_backed_ram_map(). Instead, call SET_RAM2 with the new flag. (This will be done on the Android Emulator side.) - Internally, SET_RAM2 creates a stand-alone RAM block for each stand-alone mapping. - When the stand-alone mapping is unmapped, the reference count of the corresponding stand-alone RAM block will hit 0, which allows SET_RAM2 to destroy this temporary RAM block. Signed-off-by: Yu Ning <yu.ning@intel.com>
Android Emulator may dynamically create and destroy temporary memory mappings at guest runtime for certain rendering tasks via hax_user_backed_ram_map() and hax_user_backed_ram_unmap() ($AOSP/external/qemu/target/i386/hax-mem.c), e.g.: hax_user_backed_ram_map() <1> 1.1) ADD_RAMBLOCK (#1): HVA 0x14e070000..0x16e070000 1.2) SET_RAM2 (map #1): GPA 0x7dffff000..0x7fffff000 => HVA 0x14e070000..0x16e070000 hax_user_backed_ram_unmap() <1> 1.3) SET_RAM2 (unmap #1): GPA 0x7dffff000..0x7fffff000 hax_user_backed_ram_map() <2> 2.1) ADD_RAMBLOCK: (#2): HVA 0x14de70000..0x16de70000 The second ADD_RAMBLOCK call fails, because its HVA range overlaps with that of the first ADD_RAMBLOCK call. The problem is that the "map" step creates a RAM block, but the "unmap" step doesn't destroy it. Instead of adding a DEL_RAMBLOCK ioctl, simply exempt the caller from calling ADD_RAMBLOCK in the first place: - Introduce a new hax_memslot flag for "stand-alone" mappings, along with a new capability flag for this API change. - Remove the ADD_RAMBLOCK call from hax_user_backed_ram_map(). Instead, call SET_RAM2 with the new flag. (This will be done on the Android Emulator side.) - Internally, SET_RAM2 creates a stand-alone RAM block for each stand-alone mapping. - When the stand-alone mapping is unmapped, the reference count of the corresponding stand-alone RAM block will hit 0, which allows SET_RAM2 to destroy this temporary RAM block. + Replace HAX_RAM_INFO_xxx with HAX_MEMSLOT_xxx in code that is not directly in touch with user space. Signed-off-by: Yu Ning <yu.ning@intel.com>
Add a top-level license file detectable by GitHub. It is created
using GitHub's standard BSD 3-clause license template.