2018-03-27 03:49:19 -06:00
|
|
|
all:
|
|
|
|
|
|
2018-09-18 11:54:26 -06:00
|
|
|
top_srcdir = ../../../..
|
2018-12-12 20:25:14 -07:00
|
|
|
KSFT_KHDR_INSTALL := 1
|
2018-03-27 03:49:19 -06:00
|
|
|
UNAME_M := $(shell uname -m)
|
|
|
|
|
|
2018-09-18 11:54:25 -06:00
|
|
|
LIBKVM = lib/assert.c lib/elf.c lib/io.c lib/kvm_util.c lib/ucall.c lib/sparsebit.c
|
2018-09-18 11:54:26 -06:00
|
|
|
LIBKVM_x86_64 = lib/x86_64/processor.c lib/x86_64/vmx.c
|
2018-09-18 11:54:32 -06:00
|
|
|
LIBKVM_aarch64 = lib/aarch64/processor.c
|
2018-03-27 03:49:19 -06:00
|
|
|
|
2018-09-18 11:54:26 -06:00
|
|
|
TEST_GEN_PROGS_x86_64 = x86_64/platform_info_test
|
|
|
|
|
TEST_GEN_PROGS_x86_64 += x86_64/set_sregs_test
|
|
|
|
|
TEST_GEN_PROGS_x86_64 += x86_64/sync_regs_test
|
|
|
|
|
TEST_GEN_PROGS_x86_64 += x86_64/vmx_tsc_adjust_test
|
|
|
|
|
TEST_GEN_PROGS_x86_64 += x86_64/cr4_cpuid_sync_test
|
|
|
|
|
TEST_GEN_PROGS_x86_64 += x86_64/state_test
|
2018-10-16 10:50:11 -06:00
|
|
|
TEST_GEN_PROGS_x86_64 += x86_64/evmcs_test
|
2018-12-10 10:21:59 -07:00
|
|
|
TEST_GEN_PROGS_x86_64 += x86_64/hyperv_cpuid
|
2019-01-31 15:49:21 -07:00
|
|
|
TEST_GEN_PROGS_x86_64 += x86_64/vmx_close_while_nested_test
|
2018-09-18 11:54:32 -06:00
|
|
|
TEST_GEN_PROGS_x86_64 += dirty_log_test
|
kvm: introduce manual dirty log reprotect
There are two problems with KVM_GET_DIRTY_LOG. First, and less important,
it can take kvm->mmu_lock for an extended period of time. Second, its user
can actually see many false positives in some cases. The latter is due
to a benign race like this:
1. KVM_GET_DIRTY_LOG returns a set of dirty pages and write protects
them.
2. The guest modifies the pages, causing them to be marked ditry.
3. Userspace actually copies the pages.
4. KVM_GET_DIRTY_LOG returns those pages as dirty again, even though
they were not written to since (3).
This is especially a problem for large guests, where the time between
(1) and (3) can be substantial. This patch introduces a new
capability which, when enabled, makes KVM_GET_DIRTY_LOG not
write-protect the pages it returns. Instead, userspace has to
explicitly clear the dirty log bits just before using the content
of the page. The new KVM_CLEAR_DIRTY_LOG ioctl can also operate on a
64-page granularity rather than requiring to sync a full memslot;
this way, the mmu_lock is taken for small amounts of time, and
only a small amount of time will pass between write protection
of pages and the sending of their content.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-10-22 18:36:47 -06:00
|
|
|
TEST_GEN_PROGS_x86_64 += clear_dirty_log_test
|
2018-09-18 11:54:32 -06:00
|
|
|
|
|
|
|
|
TEST_GEN_PROGS_aarch64 += dirty_log_test
|
kvm: introduce manual dirty log reprotect
There are two problems with KVM_GET_DIRTY_LOG. First, and less important,
it can take kvm->mmu_lock for an extended period of time. Second, its user
can actually see many false positives in some cases. The latter is due
to a benign race like this:
1. KVM_GET_DIRTY_LOG returns a set of dirty pages and write protects
them.
2. The guest modifies the pages, causing them to be marked ditry.
3. Userspace actually copies the pages.
4. KVM_GET_DIRTY_LOG returns those pages as dirty again, even though
they were not written to since (3).
This is especially a problem for large guests, where the time between
(1) and (3) can be substantial. This patch introduces a new
capability which, when enabled, makes KVM_GET_DIRTY_LOG not
write-protect the pages it returns. Instead, userspace has to
explicitly clear the dirty log bits just before using the content
of the page. The new KVM_CLEAR_DIRTY_LOG ioctl can also operate on a
64-page granularity rather than requiring to sync a full memslot;
this way, the mmu_lock is taken for small amounts of time, and
only a small amount of time will pass between write protection
of pages and the sending of their content.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-10-22 18:36:47 -06:00
|
|
|
TEST_GEN_PROGS_aarch64 += clear_dirty_log_test
|
2018-03-27 03:49:19 -06:00
|
|
|
|
|
|
|
|
TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(UNAME_M))
|
|
|
|
|
LIBKVM += $(LIBKVM_$(UNAME_M))
|
|
|
|
|
|
|
|
|
|
INSTALL_HDR_PATH = $(top_srcdir)/usr
|
|
|
|
|
LINUX_HDR_PATH = $(INSTALL_HDR_PATH)/include/
|
2018-09-18 11:54:26 -06:00
|
|
|
LINUX_TOOL_INCLUDE = $(top_srcdir)/tools/include
|
|
|
|
|
CFLAGS += -O2 -g -std=gnu99 -I$(LINUX_TOOL_INCLUDE) -I$(LINUX_HDR_PATH) -Iinclude -I$(<D) -Iinclude/$(UNAME_M) -I..
|
2018-08-29 01:04:08 -06:00
|
|
|
LDFLAGS += -pthread
|
2018-03-27 03:49:19 -06:00
|
|
|
|
|
|
|
|
# After inclusion, $(OUTPUT) is defined and
|
|
|
|
|
# $(TEST_GEN_PROGS) starts with $(OUTPUT)/
|
|
|
|
|
include ../lib.mk
|
|
|
|
|
|
|
|
|
|
STATIC_LIBS := $(OUTPUT)/libkvm.a
|
|
|
|
|
LIBKVM_OBJ := $(patsubst %.c, $(OUTPUT)/%.o, $(LIBKVM))
|
2018-09-18 11:54:27 -06:00
|
|
|
EXTRA_CLEAN += $(LIBKVM_OBJ) $(STATIC_LIBS) cscope.*
|
2018-03-27 03:49:19 -06:00
|
|
|
|
|
|
|
|
x := $(shell mkdir -p $(sort $(dir $(LIBKVM_OBJ))))
|
|
|
|
|
$(LIBKVM_OBJ): $(OUTPUT)/%.o: %.c
|
|
|
|
|
$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< -o $@
|
|
|
|
|
|
|
|
|
|
$(OUTPUT)/libkvm.a: $(LIBKVM_OBJ)
|
|
|
|
|
$(AR) crs $@ $^
|
|
|
|
|
|
2018-09-04 04:47:21 -06:00
|
|
|
all: $(STATIC_LIBS)
|
2018-03-27 03:49:19 -06:00
|
|
|
$(TEST_GEN_PROGS): $(STATIC_LIBS)
|
2018-09-18 11:54:27 -06:00
|
|
|
|
|
|
|
|
cscope: include_paths = $(LINUX_TOOL_INCLUDE) $(LINUX_HDR_PATH) include lib ..
|
|
|
|
|
cscope:
|
|
|
|
|
$(RM) cscope.*
|
|
|
|
|
(find $(include_paths) -name '*.h' \
|
|
|
|
|
-exec realpath --relative-base=$(PWD) {} \;; \
|
|
|
|
|
find . -name '*.c' \
|
|
|
|
|
-exec realpath --relative-base=$(PWD) {} \;) | sort -u > cscope.files
|
|
|
|
|
cscope -b
|