- May 08, 2018
-
-
Paolo Bonzini authored
MemoryRegionCache was reverted to "normal" address_space_* operations for 2.9, due to lack of support for IOMMUs. Reinstate the optimizations, caching only the IOMMU translation at address_cache_init but not the IOMMU lookup and target AddressSpace translation are not cached; now that MemoryRegionCache supports IOMMUs, it becomes more widely applicable too. The inlined fast path is defined in memory_ldst_cached.inc.h, while the slow path uses memory_ldst.inc.c as before. The smaller fast path causes a little code size reduction in MemoryRegionCache users: hw/virtio/virtio.o text size before: 32373 hw/virtio/virtio.o text size after: 31941 Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
This will be used to process IOMMUs in a MemoryRegionCache. This includes a small bugfix, in that the returned page_mask is now correctly -1 if the IOMMU memory region maps the entire address space directly. Previously, address_space_get_iotlb_entry would return ~TARGET_PAGE_MASK. Reviewed-by:
Peter Xu <peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
Prepare for extracting the IOMMU part to a separate function. Mostly cosmetic; the only semantic change is that, if there is more than one cascaded IOMMU and the second one fails to translate, *plen_out is now adjusted according to the page mask of the first IOMMU. Reviewed-by:
Peter Xu <peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Apr 27, 2018
-
-
David Gibson authored
There are a couple places (one generic, one target specific) where we need to get the host page size associated with a particular memory backend. I have some upcoming code which will add another place which wants this. So, for convenience, add a helper function to calculate this. host_memory_backend_pagesize() returns the host pagesize for a given HostMemoryBackend object. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Reviewed-by:
Greg Kurz <groug@kaod.org> Acked-by:
Paolo Bonzini <pbonzini@redhat.com>
-
David Gibson authored
qemu_mempath_getpagesize() gets the effective (host side) page size for a block of memory backed by an mmap()ed file on the host. It requires the mem_path parameter to be non-NULL. This ends up meaning all the callers need a different case for handling anonymous memory (for memory-backend-ram or default memory with -mem-path is not specified). We can make all those callers a little simpler by having qemu_mempath_getpagesize() accept NULL, and treat that as the anonymous memory case. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Reviewed-by:
Greg Kurz <groug@kaod.org> Acked-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Apr 03, 2018
-
-
Greg Kurz authored
The string returned by object_property_get_str() is dynamically allocated. Signed-off-by:
Greg Kurz <groug@kaod.org> Message-Id: <152231458624.69730.1752893648612848392.stgit@bahia.lan> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com>
-
- Mar 20, 2018
-
-
Dr. David Alan Gilbert authored
Use a flag on the RAMBlock to state whether it has the UFFDIO_ZEROPAGE capability, use it when it's available. This allows the use of postcopy on tmpfs as well as hugepage backed files. Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
Dr. David Alan Gilbert authored
Utility to give the offset of a host pointer within a RAMBlock (assuming we already know it's in that RAMBlock) Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
Dr. David Alan Gilbert authored
The choice of call to discard a block is getting more complicated for other cases. We use fallocate PUNCH_HOLE in any file cases; it works for both hugepage and for tmpfs. We use the DONTNEED for non-hugepage cases either where they're anonymous or where they're private. Care should be taken when trying other backing files. Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
- Mar 19, 2018
-
-
Igor Mammedov authored
With all targets defining CPU_RESOLVING_TYPE, refactor cpu_parse_cpu_model(type, cpu_model) to parse_cpu_model(cpu_model) so that callers won't have to know internal resolving cpu type. Place it in exec.c so it could be called from both target independed vl.c and *-user/main.c. That allows us to stop abusing cpu type from MachineClass::default_cpu_type as resolver class in vl.c which were confusing part of cpu_parse_cpu_model(). Also with new parse_cpu_model(), the last users of cpu_init() in null-machine.c and bsd/linux-user targets could be switched to cpu_create() API and cpu_init() API will be removed by follow up patch. With no longer users left remove MachineState::cpu_model field, new code should use MachineState::cpu_type instead and leave cpu_model parsing to generic code in vl.c. Signed-off-by:
Igor Mammedov <imammedo@redhat.com> Reviewed-by:
Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1518000027-274608-5-git-send-email-imammedo@redhat.com> [ehabkost: Fix bsd-user build error] Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com>
-
- Mar 09, 2018
-
-
Paolo Bonzini authored
Fixes: 11e732a5 Reported-by:
Cornelia Huck <cohuck@redhat.com> Reported-by:
luigi burdo <intermediadc@hotmail.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Tested-by:
Cornelia Huck <cohuck@redhat.com> Tested-by:
Thomas Huth <thuth@redhat.com> Message-id: 20180307130238.19358-1-pbonzini@redhat.com Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Mar 06, 2018
-
-
Paolo Bonzini authored
address_space_rw is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, transform flatview_rw into address_space_rw, since flatview_rw is otherwise unused. Reviewed-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
address_space_map is calling address_space_to_flatview but it can be called outside the RCU lock. The function itself is calling rcu_read_lock/rcu_read_unlock, just in the wrong place, so the fix is easy. Reviewed-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
address_space_access_valid is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock pair up from flatview_access_valid to address_space_access_valid. Reviewed-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
address_space_read is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock pair up from flatview_read_full to address_space_read's constant size fast path and address_space_read_full. Reviewed-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
address_space_write is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock pair up from flatview_write to address_space_write. Reviewed-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Feb 19, 2018
-
-
Marcel Apfelbaum authored
Currently only file backed memory backend can be created with a "share" flag in order to allow sharing guest RAM with other processes in the host. Add the "share" flag also to RAM Memory Backend in order to allow remapping parts of the guest RAM to different host virtual addresses. This is needed by the RDMA devices in order to remap non-contiguous QEMU virtual addresses to a contiguous virtual address range. Moved the "share" flag to the Host Memory base class, modified phys_mem_alloc to include the new parameter and a new interface memory_region_init_ram_shared_nomigrate. There are no functional changes if the new flag is not used. Reviewed-by:
Eduardo Habkost <ehabkost@redhat.com> Signed-off-by:
Marcel Apfelbaum <marcel@redhat.com>
-
- Feb 06, 2018
-
-
Alistair Francis authored
Replace a large number of the fprintf(stderr, "*\n" calls with error_report(). The functions were renamed with these commands and then compiler issues where manually fixed. find ./* -type f -exec sed -i \ 'N;N;N;N;N;N;N;N;N;N;N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N;N;N;N;N;N;N;N;N;N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N;N;N;N;N;N;N;N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N;N;N;N;N;N;N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N;N;N;N;N;N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N;N;N;N;N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N;N;N;N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N;N;N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N;N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + find ./* -type f -exec sed -i \ 'N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \ {} + Signed-off-by:
Alistair Francis <alistair.francis@xilinx.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Stefan Weil <sw@weilnetz.de> Conversions that aren't followed by exit() dropped, because they might be inappropriate. Signed-off-by:
Markus Armbruster <armbru@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180203084315.20497-14-armbru@redhat.com> Reviewed-by:
Thomas Huth <thuth@redhat.com>
-
- Jan 19, 2018
-
-
Haozhong Zhang authored
When mmap(2) the backend files, QEMU uses the host page size (getpagesize(2)) by default as the alignment of mapping address. However, some backends may require alignments different than the page size. For example, mmap a device DAX (e.g., /dev/dax0.0) on Linux kernel 4.13 to an address, which is 4K-aligned but not 2M-aligned, fails with a kernel message like [617494.969768] dax dax0.0: qemu-system-x86: dax_mmap: fail, unaligned vma (0x7fa37c579000 - 0x7fa43c579000, 0x1fffff) Because there is no common approach to get such alignment requirement, we add the 'align' option to 'memory-backend-file', so that users or management utils, which have enough knowledge about the backend, can specify a proper alignment via this option. Signed-off-by:
Haozhong Zhang <haozhong.zhang@intel.com> Message-Id: <20171211072806.2812-2-haozhong.zhang@intel.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> [ehabkost: fixed typo, fixed error_setg() format string] Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com>
-
- Jan 16, 2018
-
-
Pavel Dovgaluk authored
Flushing TB cache is required because TBs key in the cache may match different code which existed in the previous state. Signed-off-by:
Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Signed-off-by:
Maria Klimushenkova <maria.klimushenkova@ispras.ru> Message-Id: <20180110134846.12940.99993.stgit@pasha-VirtualBox> [Add comment suggested by Peter Maydell. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
-
Dr. David Alan Gilbert authored
The dirty bitmaps are built from 'long's and there is fast-path code for synchronising the case where the RAMBlock is aligned to the start of a long boundary. Align the allocation to this boundary to cause the fast path to be used. Offsets before change: 11398@1515169675.018566:find_ram_offset size: 0x1e0000 @ 0x8000000 11398@1515169675.020064:find_ram_offset size: 0x20000 @ 0x81e0000 11398@1515169675.020244:find_ram_offset size: 0x20000 @ 0x8200000 11398@1515169675.024343:find_ram_offset size: 0x1000000 @ 0x8220000 11398@1515169675.025154:find_ram_offset size: 0x10000 @ 0x9220000 11398@1515169675.027682:find_ram_offset size: 0x40000 @ 0x9230000 11398@1515169675.032921:find_ram_offset size: 0x200000 @ 0x9270000 11398@1515169675.033307:find_ram_offset size: 0x1000 @ 0x9470000 11398@1515169675.033601:find_ram_offset size: 0x1000 @ 0x9471000 after change: 10923@1515169108.818245:find_ram_offset size: 0x1e0000 @ 0x8000000 10923@1515169108.819410:find_ram_offset size: 0x20000 @ 0x8200000 10923@1515169108.819587:find_ram_offset size: 0x20000 @ 0x8240000 10923@1515169108.823708:find_ram_offset size: 0x1000000 @ 0x8280000 10923@1515169108.824503:find_ram_offset size: 0x10000 @ 0x9280000 10923@1515169108.827093:find_ram_offset size: 0x40000 @ 0x92c0000 10923@1515169108.833045:find_ram_offset size: 0x200000 @ 0x9300000 10923@1515169108.833504:find_ram_offset size: 0x1000 @ 0x9500000 10923@1515169108.833787:find_ram_offset size: 0x1000 @ 0x9540000 Suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20180105170138.23357-3-dgilbert@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Dr. David Alan Gilbert authored
Add some comments so I can understand the various nested loops. Add some tracing so I can see what they're doing. Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20180105170138.23357-2-dgilbert@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Dec 21, 2017
-
-
Peter Maydell authored
We set up the io_mem_rom special memory region using the unassigned_mem_ops structure; this is then used when a guest tries to write to ROM. This is incorrect, because the behaviour of unassigned memory may be different from that of ROM for writes. In particular, on some architectures writing to unassigned memory generates a guest exception, whereas writing to ROM is generally ignored. Use a special readonly_mem_ops for this purpose instead, so writes to ROM are ignored for all guest CPUs. Signed-off-by:
Peter Maydell <peter.maydell@linaro.org> Message-Id: <1513187549-2435-2-git-send-email-peter.maydell@linaro.org> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
Renaming cpu address space names so that they won't be the same when there are more than one. Signed-off-by:
Peter Xu <peterx@redhat.com> Message-Id: <20171123092333.16085-4-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
Normally we create an address space for that CPU and pass that address space into the function. Let's just do it inside to unify address space creations. It'll simplify my next patch to rename those address spaces. Signed-off-by:
Peter Xu <peterx@redhat.com> Message-Id: <20171123092333.16085-3-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Dec 18, 2017
-
-
Philippe Mathieu-Daudé authored
exec: housekeeping (funny since 02d0e095) applied using ./scripts/clean-includes Signed-off-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Acked-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
Anthony PERARD <anthony.perard@citrix.com> Signed-off-by:
Michael Tokarev <mjt@tls.msk.ru>
-
- Nov 21, 2017
-
-
Peter Maydell authored
The function notdirty_mem_write() has a sequence of actions it has to do before and after the actual business of writing data to host RAM to ensure that dirty flags are correctly updated and we flush any TCG translations for the region. We need to do this also in other places that write directly to host RAM, most notably the TCG atomic helper functions. Pull out the before and after pieces into their own functions. We use an API where the prepare function stashes the various bits of information about the write into a struct for the complete function to use, because in the calls for the atomic helpers the place where the complete function will be called doesn't have the information to hand. Cc: qemu-stable@nongnu.org Signed-off-by:
Peter Maydell <peter.maydell@linaro.org> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Message-id: 1511201308-23580-2-git-send-email-peter.maydell@linaro.org
-
- Nov 15, 2017
-
-
Paolo Bonzini authored
This fixes a crash caused by picking the wrong memory region in address_space_lookup_region seen with client code accessing a device model that uses alias memory regions. The expensive part of address_space_lookup_region anyway is phys_page_find; performance-wise it is okay to repeat the subsequent subpage lookup. Signed-off-by:
BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20171114225941.072707456B5@zero.eik.bme.hu> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Nov 13, 2017
-
-
Emilio G. Cota authored
55c3ceef ("qom: Introduce CPUClass.tcg_initialize", 2017-10-24) introduces a per-CPUClass bool that we check so that the target CPU is initialized for TCG only once. This works well except when we end up creating more than one CPUClass, in which case we end up incorrectly initializing TCG more than once, i.e. once for each CPUClass. This can be replicated with: $ aarch64-softmmu/qemu-system-aarch64 -machine xlnx-zcu102 -smp 6 \ -global driver=xlnx,,zynqmp,property=has_rpu,value=on In this case the class name of the "RPUs" is prefixed by "cortex-r5-", whereas the "regular" CPUs are prefixed by "cortex-a53-". This results in two CPUClass instances being created. Fix it by introducing a static variable, so that only the first target CPU being initialized will initialize the target-dependent part of TCG, regardless of CPUClass instances. Fixes: 55c3ceef Signed-off-by:
Emilio G. Cota <cota@braap.org> Reviewed-by:
Eduardo Habkost <ehabkost@redhat.com> Reviewed-by:
Alistair Francis <alistair.francis@xilinx.com> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Tested-by:
Alistair Francis <alistair.francis@xilinx.com> Message-id: 1510343626-25861-2-git-send-email-cota@braap.org Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Oct 24, 2017
-
-
Richard Henderson authored
We were generating code during tb_invalidate_phys_page_range, check_watchpoint, cpu_io_recompile, and (seemingly) discarding the TB, assuming that it would magically be picked up during the next iteration through the cpu_exec loop. Instead, record the desired cflags in CPUState so that we request the proper TB so that there is no more magic. Reviewed-by:
Emilio G. Cota <cota@braap.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
Emilio G. Cota authored
This will enable us to decouple code translation from the value of parallel_cpus at any given time. It will also help us minimize TB flushes when generating code via EXCP_ATOMIC. Note that the declaration of parallel_cpus is brought to exec-all.h to be able to define there the "curr_cflags" inline. Signed-off-by:
Emilio G. Cota <cota@braap.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
Richard Henderson authored
Move target cpu tcg initialization to common code, called from cpu_exec_realizefn. Acked-by:
Andreas Färber <afaerber@suse.de> Reviewed-by:
Emilio G. Cota <cota@braap.org> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
- Oct 18, 2017
-
-
Paolo Bonzini authored
Aligned 8-byte memory writes by a 64-bit target on a 64-bit host should always turn into atomic 8-byte writes on the host, however a write write watchpoint would end up tearing the 8-byte write into two 4-byte writes in access_with_adjusted_size(). Reported-by:
Andrew Baumann <Andrew.Baumann@microsoft.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Andrew Baumann authored
Aligned 8-byte memory writes by a 64-bit target on a 64-bit host should always turn into atomic 8-byte writes on the host, however if we missed in the softmmu, and the TLB line was marked as not dirty, then we would end up tearing the 8-byte write into two 4-byte writes in access_with_adjusted_size(). Signed-off-by:
Andrew Baumann <Andrew.Baumann@microsoft.com> Message-Id: <20171013181913.7556-1-Andrew.Baumann@microsoft.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Oct 12, 2017
-
-
Peter Xu authored
This patch let address_space_get_iotlb_entry() to use the newly introduced page_mask parameter in flatview_do_translate(). Then we will be sure the IOTLB can be aligned to page mask, also we should nicely support huge pages now when introducing a764040c. Fixes: a764040c ("exec: abstract address_space_do_translate()") Signed-off-by:
Peter Xu <peterx@redhat.com> Signed-off-by:
Maxime Coquelin <maxime.coquelin@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Message-Id: <20171010094247.10173-3-maxime.coquelin@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
The function is originally used for flatview_space_translate() and what we care about most is (xlat, plen) range. However for iotlb requests, we don't really care about "plen", but the size of the page that "xlat" is located on. While, plen cannot really contain this information. A simple example to show why "plen" is not good for IOTLB translations: E.g., for huge pages, it is possible that guest mapped 1G huge page on device side that used this GPA range: 0x100000000 - 0x13fffffff Then let's say we want to translate one IOVA that finally mapped to GPA 0x13ffffe00 (which is located on this 1G huge page). Then here we'll get: (xlat, plen) = (0x13fffe00, 0x200) So the IOTLB would be only covering a very small range since from "plen" (which is 0x200 bytes) we cannot tell the size of the page. Actually we can really know that this is a huge page - we just throw the information away in flatview_do_translate(). This patch introduced "page_mask" optional parameter to capture that page mask info. Also, I made "plen" an optional parameter as well, with some comments for the whole function. No functional change yet. Signed-off-by:
Peter Xu <peterx@redhat.com> Signed-off-by:
Maxime Coquelin <maxime.coquelin@redhat.com> Message-Id: <20171010094247.10173-2-maxime.coquelin@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Oct 10, 2017
-
-
Emilio G. Cota authored
These only depend on the host and therefore belong in the common osdep, not in a target-dependent object. While at it, query the host during an init constructor, which guarantees the page size will be well-defined throughout the execution of the program. Suggested-by:
Richard Henderson <rth@twiddle.net> Reviewed-by:
Richard Henderson <rth@twiddle.net> Signed-off-by:
Emilio G. Cota <cota@braap.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
- Sep 21, 2017
-
-
Alexey Kardashevskiy authored
This adds a new "-d" switch to "info mtree" to print dispatch tree internals. This changes the way "-f" is handled - it prints now flat views and associated address spaces. Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-15-aik@ozlabs.ru> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Alexey Kardashevskiy authored
This renames some helpers to reflect better what they do. This should cause no behavioural change. Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-9-aik@ozlabs.ru> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Alexey Kardashevskiy authored
We store AddressSpaceDispatch* in FlatView anyway so there is no need to carry it from mem_add() to register_subpage/register_multipage. This should cause no behavioural change. Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-8-aik@ozlabs.ru> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-