diff options
| author | Anthony PERARD | 2017-07-26 18:53:26 +0200 |
|---|---|---|
| committer | Paolo Bonzini | 2017-08-01 17:27:33 +0200 |
| commit | f5aa69bdc3418773f26747ca282c291519626ece (patch) | |
| tree | 882af8630cc258868722ae867741ae5ea7ba9651 /include/exec | |
| parent | target-i386: kvm_get/put_vcpu_events don't handle sipi_vector (diff) | |
| download | qemu-f5aa69bdc3418773f26747ca282c291519626ece.tar.gz qemu-f5aa69bdc3418773f26747ca282c291519626ece.tar.xz qemu-f5aa69bdc3418773f26747ca282c291519626ece.zip | |
exec: Add lock parameter to qemu_ram_ptr_length
Commit 04bf2526ce87f21b32c9acba1c5518708c243ad0 (exec: use
qemu_ram_ptr_length to access guest ram) start using qemu_ram_ptr_length
instead of qemu_map_ram_ptr, but when used with Xen, the behavior of
both function is different. They both call xen_map_cache, but one with
"lock", meaning the mapping of guest memory is never released
implicitly, and the second one without, which means, mapping can be
release later, when needed.
In the context of address_space_{read,write}_continue, the ptr to those
mapping should not be locked because it is used immediatly and never
used again.
The lock parameter make it explicit in which context qemu_ram_ptr_length
is called.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20170726165326.10327-1-anthony.perard@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'include/exec')
0 files changed, 0 insertions, 0 deletions