From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F3F3C4346E for ; Sun, 27 Sep 2020 10:47:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4AA9722207 for ; Sun, 27 Sep 2020 10:47:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601203664; bh=cosG4DEjbjDD3MjF22culoVmEblNnFBmoEmuuf4xtLQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=cqcyeqBZ3OiIz9eUm7ezmteo2EwmE+I9sQmuhA7XmGcHOm9XMkvJlevgrMJOipULG BVNndAWU+YGrQrLbJbIiyTQrnTPlAQWg6+rcu8QMnvj5Ai5abUl+0ThI28dJvap2HB bnD5e/GkdI0pRyF7zfBovvPzZcJgSxLuENLIS1C0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726314AbgI0KoF (ORCPT ); Sun, 27 Sep 2020 06:44:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:58476 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726265AbgI0KoF (ORCPT ); Sun, 27 Sep 2020 06:44:05 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6A03F22207; Sun, 27 Sep 2020 10:44:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601203444; bh=cosG4DEjbjDD3MjF22culoVmEblNnFBmoEmuuf4xtLQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YKcHcC4PEUYBSA+yqdz0jodWBX6orSb2yYUl8hGPWnSBR321fJwy0PSOdiRCaQXU4 lhNTXbd1+Tuu4+2I1J/WuK/muQNiQQDi8r2RyOPl4dFHvboBxHU5pC5VA2x2TTfrct WgGY/BEXqYLBgyW9OjNFOjDRebYkMqm0jW9C85hU= Date: Sun, 27 Sep 2020 12:44:14 +0200 From: Greg Kroah-Hartman To: shuo.a.liu@intel.com Cc: linux-kernel@vger.kernel.org, x86@kernel.org, "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Sean Christopherson , Yu Wang , Reinette Chatre , Zhi Wang , Zhenyu Wang Subject: Re: [PATCH v4 17/17] virt: acrn: Introduce an interface for Service VM to control vCPU Message-ID: <20200927104414.GC88650@kroah.com> References: <20200922114311.38804-1-shuo.a.liu@intel.com> <20200922114311.38804-18-shuo.a.liu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200922114311.38804-18-shuo.a.liu@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 22, 2020 at 07:43:11PM +0800, shuo.a.liu@intel.com wrote: > From: Shuo Liu > > ACRN supports partition mode to achieve real-time requirements. In > partition mode, a CPU core can be dedicated to a vCPU of User VM. The > local APIC of the dedicated CPU core can be passthrough to the User VM. > The Service VM controls the assignment of the CPU cores. > > Introduce an interface for the Service VM to remove the control of CPU > core from hypervisor perspective so that the CPU core can be a dedicated > CPU core of User VM. > > Signed-off-by: Shuo Liu > Reviewed-by: Zhi Wang > Reviewed-by: Reinette Chatre > Cc: Zhi Wang > Cc: Zhenyu Wang > Cc: Yu Wang > Cc: Reinette Chatre > Cc: Greg Kroah-Hartman > --- > drivers/virt/acrn/hsm.c | 50 +++++++++++++++++++++++++++++++++++ > drivers/virt/acrn/hypercall.h | 14 ++++++++++ > 2 files changed, 64 insertions(+) > > diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c > index aaf4e76d27b4..ef5f77a38d1f 100644 > --- a/drivers/virt/acrn/hsm.c > +++ b/drivers/virt/acrn/hsm.c > @@ -9,6 +9,7 @@ > * Yakui Zhao > */ > > +#include > #include > #include > #include > @@ -354,6 +355,47 @@ struct miscdevice acrn_dev = { > .fops = &acrn_fops, > }; > > +static ssize_t remove_cpu_store(struct device *dev, > + struct device_attribute *attr, > + const char *buf, size_t count) > +{ > + u64 cpu, lapicid; > + int ret; > + > + if (kstrtoull(buf, 0, &cpu) < 0) > + return -EINVAL; > + > + if (cpu >= num_possible_cpus() || cpu == 0 || !cpu_is_hotpluggable(cpu)) > + return -EINVAL; > + > + if (cpu_online(cpu)) > + remove_cpu(cpu); > + > + lapicid = cpu_data(cpu).apicid; > + dev_dbg(dev, "Try to remove cpu %lld with lapicid %lld\n", cpu, lapicid); > + ret = hcall_sos_remove_cpu(lapicid); > + if (ret < 0) { > + dev_err(dev, "Failed to remove cpu %lld!\n", cpu); > + goto fail_remove; > + } > + > + return count; > + > +fail_remove: > + add_cpu(cpu); > + return ret; > +} > +static DEVICE_ATTR_WO(remove_cpu); > + > +static struct attribute *acrn_attrs[] = { > + &dev_attr_remove_cpu.attr, > + NULL > +}; > + > +static struct attribute_group acrn_attr_group = { > + .attrs = acrn_attrs, > +}; You create a sysfs attribute without any Documentation/ABI/ update as well? That's not good. And why are you trying to emulate CPU hotplug here and not using the existing CPU hotplug mechanism? > + > static int __init hsm_init(void) > { > int ret; > @@ -370,13 +412,21 @@ static int __init hsm_init(void) > return ret; > } > > + ret = sysfs_create_group(&acrn_dev.this_device->kobj, &acrn_attr_group); > + if (ret) { > + dev_warn(acrn_dev.this_device, "sysfs create failed\n"); > + misc_deregister(&acrn_dev); > + return ret; > + } You just raced with userspace and lost. If you want to add attribute files to a device, use the default attribute group list, and it will be managed properly for you by the driver core. Huge hint, if a driver every has to touch a kobject, or call sysfs_*, then it is probably doing something wrong. greg k-h