mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>, kvm@vger.kernel.org
Cc: borntraeger@de.ibm.com, pbonzini@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/1] KVM: trigger uevents when starting or stopping a VM
Date: Mon, 10 Jul 2017 11:40:55 +0200	[thread overview]
Message-ID: <852e01e7-81f4-7fcb-dc55-80f4aed029c0@redhat.com> (raw)
In-Reply-To: <1499678444-21879-2-git-send-email-imbrenda@linux.vnet.ibm.com>

On 10.07.2017 11:20, Claudio Imbrenda wrote:

Minor minor nit:

The subject should state "creating or destroying a VM"

> 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: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
> ---
>  virt/kvm/kvm_main.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 59 insertions(+)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index f0fe9d0..7c39783 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -130,6 +130,12 @@ EXPORT_SYMBOL_GPL(kvm_rebooting);
>  
>  static bool largepages_enabled = true;
>  
> +#define KVM_EVENT_CREATE_VM 0
> +#define KVM_EVENT_DESTROY_VM 1
> +static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm);
> +static unsigned long long kvm_createvm_count;
> +static unsigned long long kvm_active_vms;
> +
>  bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
>  {
>  	if (pfn_valid(pfn))
> @@ -728,6 +734,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
>  	int i;
>  	struct mm_struct *mm = kvm->mm;
>  
> +	kvm_uevent_notify_change(KVM_EVENT_DESTROY_VM, kvm);
>  	kvm_destroy_vm_debugfs(kvm);
>  	kvm_arch_sync_events(kvm);
>  	spin_lock(&kvm_lock);
> @@ -3196,6 +3203,7 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
>  		fput(file);
>  		return -ENOMEM;
>  	}
> +	kvm_uevent_notify_change(KVM_EVENT_CREATE_VM, kvm);
>  
>  	fd_install(r, file);
>  	return r;
> @@ -3848,6 +3856,57 @@ static const struct file_operations *stat_fops[] = {
>  	[KVM_STAT_VM]   = &vm_stat_fops,
>  };
>  
> +static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm)
> +{
> +	char cbuf[32], abuf[32], pidbuf[32], evbuf[16];

do we really need that much space for a pid?

> +	const char pathvar[11] = "STATS_PATH=";
> +	char *ptr[6] = {cbuf, abuf, pidbuf, NULL, NULL, NULL};
> +	char *tmp, *pathbuf;
> +	unsigned long long created, active;
> +	int idx = 3;
> +
> +	if (!kvm_dev.this_device || !kvm || !kvm->debugfs_dentry)
> +		return;
> +
> +	spin_lock(&kvm_lock);
> +	if (type == KVM_EVENT_CREATE_VM) {
> +		kvm_createvm_count++;
> +		kvm_active_vms++;
> +	} else if (type == KVM_EVENT_DESTROY_VM) {
> +		kvm_active_vms--;
> +	}
> +	created = kvm_createvm_count;
> +	active = kvm_active_vms;
> +	spin_unlock(&kvm_lock);
> +
> +	pathbuf = kmalloc(PATH_MAX, GFP_KERNEL);
> +	if (pathbuf) {
> +		tmp = dentry_path_raw(kvm->debugfs_dentry,
> +				      pathbuf + sizeof(pathvar),
> +				      PATH_MAX - sizeof(pathvar));
> +		if (!IS_ERR(tmp)) {
> +			memcpy(tmp - sizeof(pathvar), pathvar, sizeof(pathvar));
> +			ptr[idx++] = tmp - sizeof(pathvar);
> +		}
> +	}
> +	snprintf(cbuf, sizeof(cbuf), "CREATED=%llu", created);

Did you think about using struct kobj_uevent_env / add_uevent_var()?

But most probably the problem here is special handling for
dentry_path_raw().


-- 

Thanks,

David

  reply	other threads:[~2017-07-10  9:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10  9:20 [PATCH v3 0/1] Claudio Imbrenda
2017-07-10  9:20 ` [PATCH v3 1/1] KVM: trigger uevents when starting or stopping a VM Claudio Imbrenda
2017-07-10  9:40   ` David Hildenbrand [this message]
2017-07-10 11:53     ` Claudio Imbrenda
2017-07-10 11:54       ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=852e01e7-81f4-7fcb-dc55-80f4aed029c0@redhat.com \
    --to=david@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=imbrenda@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®