- Apr 09, 2018
-
-
Eric Blake authored
gcc 8 on rawhide is picky enough to complain: /home/dummy/qemu/dump.c: In function 'create_header32': /home/dummy/qemu/dump.c:817:5: error: 'strncpy' output truncated before terminating nul copying 8 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(dh->signature, KDUMP_SIGNATURE, strlen(KDUMP_SIGNATURE)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ But we already have SIG_LEN defined as the right length without needing to do a strlen(), and memcpy() is better than strncpy() when we know we do not want a trailing NUL byte. Signed-off-by:
Eric Blake <eblake@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Mar 21, 2018
-
-
Yasmin Beatriz authored
fd_write_vmcore can fail to execute for a lot of reasons that can be retrieved by errno, but it only returns -1. This makes difficult for the caller to know what happened and only a generic error message is propagated back to the user. This is an example using dump-guest-memory: (qemu) dump-guest-memory /home/yasmin/mnt/test.dump dump: failed to save memory All callers of fd_write_vmcore of dump.c does error handling via error_setg(), so at first it seems feasible to add the Error pointer as an argument of fd_write_vmcore. This proved to be more complex than it first looked. fd_write_vmcore is used by write_elf64_notes and write_elf32_notes as a WriteCoreDumpFunction prototype. WriteCoreDumpFunction is declared in include/qom/cpu.h and is used all around the code. This leaves us with few alternatives: - change the WriteCoreDumpFunction prototype to include an error pointer. This would require to change all functions that implements this prototype to also receive an Error pointer; - change both write_elf64_notes and write_elf32_notes to no use the WriteCoreDumpFunction. These functions use not only fd_write_vmcore but also buf_write_note, so this would require to change buf_write_note to handle an Error pointer. Considerable easier than the alternative above, but it's still a lot of code just for the benefit of the callers of fd_write_vmcore. This patch presents an easier solution that benefits all fd_write_vmcore callers: - instead of returning -1 on error, return -errno. All existing callers already checks for ret < 0 so there is no need to change the caller's logic too much. This also allows the retrieval of the errno. - all callers were updated to use error_setg_errno instead of just errno_setg. Now that fd_write_vmcore can return an errno, let's update all callers so they can benefit from a more detailed error message. This is the same dump-guest-memory example with this patch applied: (qemu) dump-guest-memory /home/yasmin/mnt/test.dump dump: failed to save memory: No space left on device (qemu) This example illustrates an error of fd_write_vmcore when called from write_data. All other callers will benefit from better error messages as well. Reported-by:
<yilzhang@redhat.com> Cc: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Signed-off-by:
Yasmin Beatriz <yasmins@linux.vnet.ibm.com> Signed-off-by:
Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Message-Id: <20180212142506.28445-2-danielhb@linux.vnet.ibm.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com>
-
- Mar 19, 2018
-
-
Wei Huang authored
For guest kernel that supports KASLR, the load address can change every time when guest VM runs. To find the physical base address correctly, current QEMU dump searches VMCOREINFO for the string "NUMBER(phys_base)=". However this string pattern is only available on x86_64. AArch64 uses a different field, called "NUMBER(PHYS_OFFSET)=". This patch makes sure QEMU dump uses the correct string on AArch64. Signed-off-by:
Wei Huang <wei@redhat.com> Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 1520615003-20869-1-git-send-email-wei@redhat.com Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Mar 02, 2018
-
-
Markus Armbruster authored
The previous commit improved compile time by including less of the generated QAPI headers. This is impossible for stuff defined directly in qapi-schema.json, because that ends up in headers that that pull in everything. Move everything but include directives from qapi-schema.json to new sub-module qapi/misc.json, then include just the "misc" shard where possible. It's possible everywhere, except: * monitor.c needs qmp-command.h to get qmp_init_marshal() * monitor.c, ui/vnc.c and the generated qapi-event-FOO.c need qapi-event.h to get enum QAPIEvent Perhaps we'll get rid of those some other day. Adding a type to qapi/migration.json now recompiles some 120 instead of 2300 out of 5100 objects. Signed-off-by:
Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-25-armbru@redhat.com> [eblake: rebase to master] Signed-off-by:
Eric Blake <eblake@redhat.com>
-
- Feb 09, 2018
-
-
Markus Armbruster authored
This cleanup makes the number of objects depending on qapi/error.h drop from 1910 (out of 4743) to 1612 in my "build everything" tree. While there, separate #include from file comment with a blank line, and drop a useless comment on why qemu/osdep.h is included first. Reviewed-by:
Eric Blake <eblake@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by:
Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-5-armbru@redhat.com> [Semantic conflict with commit 34e304e9 resolved, OSX breakage fixed]
-
- Jan 02, 2018
-
-
Marc-André Lureau authored
Use the function argument "name" instead of hardcoded "VMCOREINFO". All callers use "VMCOREINFO" as argument, so this isn't an exposed bug, thankfully. Simplify a little bit the code while touching this. Suggested-by:
Andrew Jones <drjones@redhat.com> Reported-by:
Laszlo Ersek <lersek@redhat.com> Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com>
-
- Oct 15, 2017
-
-
Marc-André Lureau authored
kdump header provides offset and size of the vmcoreinfo content, append it if available (skip the ELF note header). crash-7.1.9 was the first version that started looking in the vmcoreinfo data for phys_base instead of in the kdump_sub_header. Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
Marc-André Lureau authored
If the guest note is VMCOREINFO, try to get phys_base from it. Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
Marc-André Lureau authored
Read the guest ELF PT_NOTE from guest memory when fw_cfg etc/vmcoreinfo entry provides the location, and write it as an additional note in the dump. Signed-off-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com>
-
- Sep 19, 2017
-
-
David Hildenbrand authored
All but a handful of files include exec/cpu-all.h via cpu.h only. As these files already include cpu.h, let's just drop the additional include. Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-2-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
- Sep 14, 2017
-
-
Cornelia Huck authored
It does not really make sense to dump memory that is not there. Moreover, that fixes a segmentation fault when calling dump-guest-memory with no filter for a machine with no memory defined. New behaviour is: (qemu) dump-guest-memory /dev/null dump: no guest memory to dump (qemu) dump-guest-memory /dev/null 0 4096 dump: no guest memory to dump Signed-off-by:
Cornelia Huck <cohuck@redhat.com> Tested-by:
Laurent Vivier <lvivier@redhat.com> Reviewed-by:
Laurent Vivier <lvivier@redhat.com> Reviewed-by:
Greg Kurz <groug@kaod.org> Reviewed-by:
Peter Xu <peterx@redhat.com> Message-Id: <20170913142036.2469-4-lvivier@redhat.com> Signed-off-by:
Laurent Vivier <lvivier@redhat.com> Signed-off-by:
Dr. David Alan Gilbert <dgilbert@redhat.com>
-
- Aug 30, 2017
-
-
Alberto Garcia authored
There's a few cases which we're passing an Error pointer to a function only to discard it immediately afterwards without checking it. In these cases we can simply remove the variable and pass NULL instead. Signed-off-by:
Alberto Garcia <berto@igalia.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by:
Eric Blake <eblake@redhat.com> Message-id: 20170829120836.16091-1-berto@igalia.com Signed-off-by:
Stefan Hajnoczi <stefanha@redhat.com>
-
- May 05, 2017
-
-
Fam Zheng authored
This fixes an assertion failure in the following backtrace: __GI___assert_fail memory_region_transaction_commit memory_region_add_eventfd virtio_pci_ioeventfd_assign virtio_bus_set_host_notifier virtio_blk_data_plane_start virtio_bus_start_ioeventfd virtio_vmstate_change vm_state_notify vm_prepare_start vm_start dump_cleanup dump_process dump_thread start_thread clone vm_start need BQL, acquire it if doing cleaning up from main thread. Signed-off-by:
Fam Zheng <famz@redhat.com> Message-Id: <20170503072819.14462-1-famz@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Jun 20, 2016
-
-
Eduardo Habkost authored
error_propagate() already ignores local_err==NULL, so there's no need to check it before calling. Coccinelle patch used to perform the changes added to scripts/coccinelle/error_propagate_null.cocci. Reviewed-by:
Eric Blake <eblake@redhat.com> Acked-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by:
Markus Armbruster <armbru@redhat.com> Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com> Message-Id: <1465855078-19435-2-git-send-email-ehabkost@redhat.com> Signed-off-by:
Markus Armbruster <armbru@redhat.com>
-
- Mar 22, 2016
-
-
Veronia Bahaa authored
Move declarations out of qemu-common.h for functions declared in utils/ files: e.g. include/qemu/path.h for utils/path.c. Move inline functions out of qemu-common.h and into new files (e.g. include/qemu/bcd.h) Signed-off-by:
Veronia Bahaa <veroniabahaa@gmail.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Feb 22, 2016
-
-
Peter Xu authored
One new QMP event DUMP_COMPLETED is added. When a dump finishes, one DUMP_COMPLETED event will occur to notify the user. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-12-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
When dump-guest-memory is requested with detach flag, after its return, user could query its status using "query-dump" command (with no argument). The result contains: - status: current dump status - completed: bytes written in the latest dump - total: bytes to write in the latest dump From completed and total, we could know how much work finished by calculating: 100.0 * completed / total (%) Reviewed-by:
Fam Zheng <famz@redhat.com> Signed-off-by:
Peter Xu <peterx@redhat.com> Message-Id: <1455772616-8668-10-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
Here, total_size is the size in bytes to be dumped (raw data, which means before compression), while written_size are bytes handled (raw size too). Signed-off-by:
Peter Xu <peterx@redhat.com> Message-Id: <1455772616-8668-9-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
If "detach" is provided, one thread is created to do the dump work, while main thread will return immediately. For each GuestPhysBlock, adding one more field "mr" to points to MemoryRegion that it belongs, also ref the mr before use. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-8-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-7-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
No functional change. Cleanup only. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-6-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
For now, it has no effect. It will be used in dump detach support. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-5-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
Instead of malloc/free each time for DumpState, make it static. Added DumpStatus to show status for dump. This is to be used for detached dump. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-4-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
This patch only adds the interfaces, but does not implement them. "detach" parameter is made optional, to make sure that all the old dump-guest-memory requests will still be able to work. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-3-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Peter Xu authored
It might be a little bit confusing and error prone to do dump_cleanup() in these two functions. A better way is to do dump_cleanup() before dump finish, no matter whether dump has succeeded or not. Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Message-Id: <1455772616-8668-2-git-send-email-peterx@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Feb 04, 2016
-
-
Peter Maydell authored
Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by:
Peter Maydell <peter.maydell@linaro.org> Message-id: 1454089805-5470-16-git-send-email-peter.maydell@linaro.org
-
- Jan 15, 2016
-
-
Andrew Jones authored
crash assumes the physical base in the kdump subheader of makedumpfile formatted dumps is correct. Zero is not correct for all architectures, so allow it to be changed. (No functional change.) Signed-off-by:
Andrew Jones <drjones@redhat.com> Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Message-id: 1452542185-10914-5-git-send-email-drjones@redhat.com Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
Andrew Jones authored
This is necessary for targets that don't have TARGET_PAGE_SIZE == real-target-page-size. The target should set the page size to the correct one, if known, or, if not known, to the maximum page size it supports. (No functional change.) Signed-off-by:
Andrew Jones <drjones@redhat.com> Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Message-id: 1452542185-10914-4-git-send-email-drjones@redhat.com Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Jun 22, 2015
-
-
Markus Armbruster authored
In particular, don't include it into headers. Signed-off-by:
Markus Armbruster <armbru@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Reviewed-by:
Luiz Capitulino <lcapitulino@redhat.com>
-
Markus Armbruster authored
These macros expand into error class enumeration constant, comma, string. Unclean. Has been that way since commit 13f59ae8. The error class is always ERROR_CLASS_GENERIC_ERROR since the previous commit. Clean up as follows: * Prepend every use of a QERR_ macro by ERROR_CLASS_GENERIC_ERROR, and delete it from the QERR_ macro. No change after preprocessing. * Rewrite error_set(ERROR_CLASS_GENERIC_ERROR, ...) into error_setg(...). Again, no change after preprocessing. Signed-off-by:
Markus Armbruster <armbru@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Reviewed-by:
Luiz Capitulino <lcapitulino@redhat.com>
-
- Nov 02, 2014
-
-
Gonglei (Arei) authored
dump_iterate() dumps blocks in a loop. Eventually, get_next_block() returns "no more". We then call dump_completed(). But we neglect to break the loop! Broken in commit 4c7e251a. Because of that, we dump the last block again. This attempts to write to s->fd, which fails if we're lucky. The error makes dump_iterate() return failure. It's the only way it can ever return. Theoretical: if we're not so lucky, something else has opened something for writing and got the same fd. dump_iterate() then keeps looping, messing up the something else's output, until a write fails, or the process mercifully terminates. The obvious fix is to restore the return lost in commit 4c7e251a. But the root cause of the bug is needlessly opaque loop control. Replace it by a clean do ... while loop. This makes the badly chosen return values of get_next_block() more visible. Cleaning that up is outside the scope of this bug fix. Signed-off-by:
Gonglei <arei.gonglei@huawei.com> Signed-off-by:
Markus Armbruster <armbru@redhat.com> Signed-off-by:
Michael Tokarev <mjt@tls.msk.ru>
-
- Oct 23, 2014
-
-
Hailiang Zhang authored
Functions shouldn't return an error code and an Error object at the same time. Turn all these functions that returning Error object to void. We also judge if a function success or fail by reference to the local_err. Signed-off-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Signed-off-by:
Luiz Capitulino <lcapitulino@redhat.com>
-
Hailiang Zhang authored
The code calls dump_error() on error, and even passes it a suitable message. However, the message is thrown away, and its callers pass up only success/failure. All qmp_dump_guest_memory() can do is set a generic error. Propagate the errors properly, so qmp_dump_guest_memory() can return a more useful error. Signed-off-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Reviewed-by:
Eric Blake <eblake@redhat.com> Reviewed-by:
Markus Armbruster <armbru@redhat.com> Signed-off-by:
Luiz Capitulino <lcapitulino@redhat.com>
-
- Aug 18, 2014
-
-
Chen Gang authored
In dump_init(), when failure occurs, need notice about 'fd' and memory mapping. So call dump_cleanup() for it (need let all initializations at front). Also simplify dump_cleanup(): remove redundant 'ret' and redundant 'fd' checking. Signed-off-by:
Chen Gang <gang.chen.5i5j@gmail.com> Reviewed-by:
Laszlo Ersek <lersek@redhat.com> Signed-off-by:
Luiz Capitulino <lcapitulino@redhat.com>
-
- Jun 16, 2014
-
-
Bharata B Rao authored
Make DumpState and endian conversion routines available for arch-specific dump code by moving into dump.h. DumpState will be needed by arch-specific dump code to access target endian information from DumpState->ArchDumpInfo. Also break the dependency of dump.h from stubs/dump.c by creating a separate dump-arch.h. This patch doesn't change any functionality. Signed-off-by:
Bharata B Rao <bharata@linux.ibm.com> [ rebased on top of current master branch, renamed endian helpers to cpu_to_dump{16,32,64}, pass a DumpState * argument to endian helpers, Greg Kurz <gkurz@linux.vnet.ibm.com> ] Signed-off-by:
Greg Kurz <gkurz@linux.vnet.ibm.com> [agraf: fix to apply] Signed-off-by:
Alexander Graf <agraf@suse.de>
-
- Jun 11, 2014
-
-
Laszlo Ersek authored
We can (and should) rely on the fact that s->flag_compress is exactly one of DUMP_DH_COMPRESSED_ZLIB, DUMP_DH_COMPRESSED_LZO, and DUMP_DH_COMPRESSED_SNAPPY. This is ensured by the QMP schema and dump_init() in combination. Suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Laszlo Ersek <lersek@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Luiz Capitulino <lcapitulino@redhat.com>
-
Laszlo Ersek authored
qmp_dump_guest_memory() dump_init() lzo_init() <---------+ create_kdump_vmcore() | write_dump_pages() | get_len_buf_out() | lzo_init() ------+ This patch doesn't change the fact that lzo_init() is called for every LZO-compressed dump, but it makes get_len_buf_out() more focused (single responsibility). Suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Laszlo Ersek <lersek@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Luiz Capitulino <lcapitulino@redhat.com>
-
Laszlo Ersek authored
The specific ELF architecture (d_machine) carries Too Much Information (TM) for deciding between create_header32() and create_header64(), use "d_class" instead (ELFCLASS32 vs. ELFCLASS64). This change adapts write_dump_header() to write_elf_loads(), dump_begin() etc. that also rely on the ELF class of the target for bitness selection. Considering the current targets that support dumping, cpu_get_dump_info() works as follows: - target-s390x/arch_dump.c: (EM_S390, ELFCLASS64) only - target-ppc/arch_dump.c (EM_PPC64, ELFCLASS64) only - target-i386/arch_dump.c: sets (EM_X86_64, ELFCLASS64) vs. (EM_386, ELFCLASS32) keying off the same Long Mode Active flag. Hence no observable change. Approximately-suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Laszlo Ersek <lersek@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Luiz Capitulino <lcapitulino@redhat.com>
-
Laszlo Ersek authored
Use TARGET_PAGE_SIZE and ~TARGET_PAGE_MASK instead. "DumpState.page_size" has type "size_t", whereas TARGET_PAGE_SIZE has type "int". TARGET_PAGE_MASK is of type "int" and has negative value. The patch affects the implicit type conversions as follows: - create_header32() and create_header64(): assigned to "block_size", which has type "uint32_t". No change. - get_next_page(): "block->target_start", "block->target_end" and "addr" have type "hwaddr" (uint64_t). Before the patch, - if "size_t" was "uint64_t", then no additional conversion was done as part of the usual arithmetic conversions, - If "size_t" was "uint32_t", then it was widened to uint64_t as part of the usual arithmetic conversions, for the remainder and addition operators. After the patch, - "~TARGET_PAGE_MASK" expands to ~~((1 << TARGET_PAGE_BITS) - 1). It has type "int" and positive value (only least significant bits set). That's converted (widened) to "uint64_t" for the bit-ands. No visible change. - The same holds for the (addr + TARGET_PAGE_SIZE) addition. - write_dump_pages(): - TARGET_PAGE_SIZE passed as argument to a bunch of functions that all have prototypes. No change. - When incrementing "offset_data" (of type "off_t"): given that we never build for ILP32_OFF32 (see "-D_FILE_OFFSET_BITS=64" in configure), "off_t" is always "int64_t", and we only need to consider: - ILP32_OFFBIG: "size_t" is "uint32_t". - before: int64_t += uint32_t. Page size converted to int64_t for the addition. - after: int64_t += int32_t. No change. - LP64_OFF64: "size_t" is "uint64_t". - before: int64_t += uint64_t. Offset converted to uint64_t for the addition, then the uint64_t result is converted to int64_t for storage. - after: int64_t += int32_t. Same as the ILP32_OFFBIG/after case. No visible change. - (size_out < s->page_size) comparisons, and (size_out = s->page_size) assignment: - before: "size_out" is of type "size_t", no implicit conversion for either operator. - after: TARGET_PAGE_SIZE (of type "int" and positive value) is converted to "size_t" (for the relop because the latter is one of "uint32_t" and "uint64_t"). No visible change. - dump_init(): - DIV_ROUND_UP(DIV_ROUND_UP(s->max_mapnr, CHAR_BIT), s->page_size): The innermost "DumpState.max_mapnr" field has type uint64_t, which propagates through all implicit conversions at hand: #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) regardless of the page size macro argument's type. In the outer macro replacement, the page size is converted from uint32_t and int32_t alike to uint64_t. - (tmp * s->page_size) multiplication: "tmp" has size "uint64_t"; the RHS is converted to that type from uint32_t and int32_t just the same if it's not uint64_t to begin with. Signed-off-by:
Laszlo Ersek <lersek@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Luiz Capitulino <lcapitulino@redhat.com>
-
Laszlo Ersek authored
Just use TARGET_PAGE_BITS. "DumpState.page_shift" used to have type "uint32_t", while the replacement TARGET_PAGE_BITS has type "int". Since "DumpState.page_shift" was only used as bit shift counts in the paddr_to_pfn() and pfn_to_paddr() macros, this is safe. Suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Laszlo Ersek <lersek@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Luiz Capitulino <lcapitulino@redhat.com>
-