1. 27 7月, 2017 1 次提交
  2. 13 7月, 2017 1 次提交
    • C
      KVM: trigger uevents when creating or destroying a VM · 286de8f6
      Claudio Imbrenda 提交于
      This patch adds a few lines to the KVM common code to fire a
      KOBJ_CHANGE uevent whenever a KVM VM is created or destroyed. The event
      carries five environment variables:
      
      CREATED indicates how many times a new VM has been created. It is
      	useful for example to trigger specific actions when the first
      	VM is started
      COUNT indicates how many VMs are currently active. This can be used for
      	logging or monitoring purposes
      PID has the pid of the KVM process that has been started or stopped.
      	This can be used to perform process-specific tuning.
      STATS_PATH contains the path in debugfs to the directory with all the
      	runtime statistics for this VM. This is useful for performance
      	monitoring and profiling.
      EVENT described the type of event, its value can be either "create" or
      	"destroy"
      
      Specific udev rules can be then set up in userspace to deal with the
      creation or destruction of VMs as needed.
      Signed-off-by: NClaudio Imbrenda <imbrenda@linux.vnet.ibm.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      286de8f6
  3. 10 7月, 2017 1 次提交
  4. 07 7月, 2017 3 次提交
  5. 27 6月, 2017 2 次提交
  6. 09 5月, 2017 2 次提交
    • G
      KVM: set no_llseek in stat_fops_per_vm · 3bed8888
      Geliang Tang 提交于
      In vm_stat_get_per_vm_fops and vcpu_stat_get_per_vm_fops, since we
      use nonseekable_open() to open, we should use no_llseek() to seek,
      not generic_file_llseek().
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3bed8888
    • M
      mm: introduce kv[mz]alloc helpers · a7c3e901
      Michal Hocko 提交于
      Patch series "kvmalloc", v5.
      
      There are many open coded kmalloc with vmalloc fallback instances in the
      tree.  Most of them are not careful enough or simply do not care about
      the underlying semantic of the kmalloc/page allocator which means that
      a) some vmalloc fallbacks are basically unreachable because the kmalloc
      part will keep retrying until it succeeds b) the page allocator can
      invoke a really disruptive steps like the OOM killer to move forward
      which doesn't sound appropriate when we consider that the vmalloc
      fallback is available.
      
      As it can be seen implementing kvmalloc requires quite an intimate
      knowledge if the page allocator and the memory reclaim internals which
      strongly suggests that a helper should be implemented in the memory
      subsystem proper.
      
      Most callers, I could find, have been converted to use the helper
      instead.  This is patch 6.  There are some more relying on __GFP_REPEAT
      in the networking stack which I have converted as well and Eric Dumazet
      was not opposed [2] to convert them as well.
      
      [1] http://lkml.kernel.org/r/20170130094940.13546-1-mhocko@kernel.org
      [2] http://lkml.kernel.org/r/1485273626.16328.301.camel@edumazet-glaptop3.roam.corp.google.com
      
      This patch (of 9):
      
      Using kmalloc with the vmalloc fallback for larger allocations is a
      common pattern in the kernel code.  Yet we do not have any common helper
      for that and so users have invented their own helpers.  Some of them are
      really creative when doing so.  Let's just add kv[mz]alloc and make sure
      it is implemented properly.  This implementation makes sure to not make
      a large memory pressure for > PAGE_SZE requests (__GFP_NORETRY) and also
      to not warn about allocation failures.  This also rules out the OOM
      killer as the vmalloc is a more approapriate fallback than a disruptive
      user visible action.
      
      This patch also changes some existing users and removes helpers which
      are specific for them.  In some cases this is not possible (e.g.
      ext4_kvmalloc, libcfs_kvzalloc) because those seems to be broken and
      require GFP_NO{FS,IO} context which is not vmalloc compatible in general
      (note that the page table allocation is GFP_KERNEL).  Those need to be
      fixed separately.
      
      While we are at it, document that __vmalloc{_node} about unsupported gfp
      mask because there seems to be a lot of confusion out there.
      kvmalloc_node will warn about GFP_KERNEL incompatible (which are not
      superset) flags to catch new abusers.  Existing ones would have to die
      slowly.
      
      [sfr@canb.auug.org.au: f2fs fixup]
        Link: http://lkml.kernel.org/r/20170320163735.332e64b7@canb.auug.org.au
      Link: http://lkml.kernel.org/r/20170306103032.2540-2-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Reviewed-by: Andreas Dilger <adilger@dilger.ca>	[ext4 part]
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7c3e901
  7. 04 5月, 2017 1 次提交
  8. 03 5月, 2017 1 次提交
    • P
      Revert "KVM: Support vCPU-based gfn->hva cache" · 4e335d9e
      Paolo Bonzini 提交于
      This reverts commit bbd64115.
      
      I've been sitting on this revert for too long and it unfortunately
      missed 4.11.  It's also the reason why I haven't merged ring-based
      dirty tracking for 4.12.
      
      Using kvm_vcpu_memslots in kvm_gfn_to_hva_cache_init and
      kvm_vcpu_write_guest_offset_cached means that the MSR value can
      now be used to access SMRAM, simply by making it point to an SMRAM
      physical address.  This is problematic because it lets the guest
      OS overwrite memory that it shouldn't be able to touch.
      
      Cc: stable@vger.kernel.org
      Fixes: bbd64115Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4e335d9e
  9. 02 5月, 2017 1 次提交
  10. 27 4月, 2017 6 次提交
  11. 13 4月, 2017 1 次提交
  12. 07 4月, 2017 3 次提交
  13. 28 3月, 2017 1 次提交
  14. 24 3月, 2017 1 次提交
  15. 22 3月, 2017 1 次提交
  16. 02 3月, 2017 4 次提交
  17. 28 2月, 2017 1 次提交
  18. 25 2月, 2017 1 次提交
  19. 17 2月, 2017 6 次提交
  20. 25 12月, 2016 2 次提交