aboutsummaryrefslogtreecommitdiff
path: root/fs/fcntl.c
diff options
context:
space:
mode:
authorSean Christopherson2019-02-05 13:01:14 -0800
committerPaolo Bonzini2019-02-20 22:48:34 +0100
commit361209e054a2c9f34da090ee1ee4c1e8bfe76a64 (patch)
tree7ee55476bcecf76b5e4211c8ca80f538f31e336d /fs/fcntl.c
parentddfd1730fd829743e41213e32ccc8b4aa6dc8325 (diff)
KVM: Explicitly define the "memslot update in-progress" bit
KVM uses bit 0 of the memslots generation as an "update in-progress" flag, which is used by x86 to prevent caching MMIO access while the memslots are changing. Although the intended behavior is flag-like, e.g. MMIO sptes intentionally drop the in-progress bit so as to avoid caching data from in-flux memslots, the implementation oftentimes treats the bit as part of the generation number itself, e.g. incrementing the generation increments twice, once to set the flag and once to clear it. Prior to commit 4bd518f1598d ("KVM: use separate generations for each address space"), incorporating the "update in-progress" bit into the generation number largely made sense, e.g. "real" generations are even, "bogus" generations are odd, most code doesn't need to be aware of the bit, etc... Now that unique memslots generation numbers are assigned to each address space, stealthing the in-progress status into the generation number results in a wide variety of subtle code, e.g. kvm_create_vm() jumps over bit 0 when initializing the memslots generation without any hint as to why. Explicitly define the flag and convert as much code as possible (which isn't much) to actually treat it like a flag. This paves the way for eventually using a different bit for "update in-progress" so that it can be a flag in truth instead of a awkward extension to the generation number. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'fs/fcntl.c')
0 files changed, 0 insertions, 0 deletions