linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Liju-clr Chen (陳麗如)" <Liju-clr.Chen@mediatek.com>
To: "corbet@lwn.net" <corbet@lwn.net>,
	"krzk@kernel.org" <krzk@kernel.org>,
	"mhiramat@kernel.org" <mhiramat@kernel.org>,
	"Yingshiuan Pan (潘穎軒)" <Yingshiuan.Pan@mediatek.com>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"robh@kernel.org" <robh@kernel.org>,
	"mathieu.desnoyers@efficios.com" <mathieu.desnoyers@efficios.com>,
	"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	"will@kernel.org" <will@kernel.org>,
	"richardcochran@gmail.com" <richardcochran@gmail.com>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"Ze-yu Wang (王澤宇)" <Ze-yu.Wang@mediatek.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>
Cc: "Kevenny Hsieh (謝宜芸)" <Kevenny.Hsieh@mediatek.com>,
	"Shawn Hsiao (蕭志祥)" <shawn.hsiao@mediatek.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"PeiLun Suei (隋培倫)" <PeiLun.Suei@mediatek.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-trace-kernel@vger.kernel.org"
	<linux-trace-kernel@vger.kernel.org>,
	"Chi-shen Yeh (葉奇軒)" <Chi-shen.Yeh@mediatek.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v13 04/25] virt: geniezone: Add GenieZone hypervisor driver
Date: Tue, 12 Aug 2025 07:04:51 +0000	[thread overview]
Message-ID: <cb84d8d87a67516f9b92a89f81fe4efc088f7617.camel@mediatek.com> (raw)
In-Reply-To: <7b79d4b5-ba91-41a0-90d1-c64bcab53cec@kernel.org>

On Wed, 2024-12-11 at 09:44 +0100, Krzysztof Kozlowski wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On 14/11/2024 11:07, Liju-clr Chen wrote:
> > +
> > +static int gzvm_dev_open(struct inode *inode, struct file *file)
> > +{
> > +     /*
> > +      * Reference count to prevent this module is unload without
> > destroying
> > +      * VM
> 
> So you re-implemented suppress-bind attrs... no, drop.
> 

Thanks, will fix in next version.

> > +      */
> > +     try_module_get(THIS_MODULE);
> > +     return 0;
> > +}
> > +
> > +static int gzvm_dev_release(struct inode *inode, struct file
> > *file)
> > +{
> > +     module_put(THIS_MODULE);
> > +     return 0;
> > +}
> > +
> > +static const struct file_operations gzvm_chardev_ops = {
> > +     .llseek         = noop_llseek,
> > +     .open           = gzvm_dev_open,
> > +     .release        = gzvm_dev_release,
> > +};
> > +
> > +static struct miscdevice gzvm_dev = {
> > +     .minor = MISC_DYNAMIC_MINOR,
> > +     .name = KBUILD_MODNAME,
> > +     .fops = &gzvm_chardev_ops,
> > +};
> > +
> > +static int gzvm_drv_probe(struct platform_device *pdev)
> > +{
> > +     if (gzvm_arch_probe(gzvm_drv.drv_version,
> > &gzvm_drv.hyp_version) != 0) {
> > +             dev_err(&pdev->dev, "Not found available conduit\n");
> 
> So you can autodetect your hypervisor? Why your soc info drivers
> cannot
> instantiate this device thus removing any need for fake DT node (fake
> because no resources and used only to satisfy Linux driver
> instantiation)?
> 
> 
Hi Krzysztof,

I'm following up regarding your recent feedback on the MTK SoC driver
instantiation, as well as your earlier concerns about probing for the
hypervisor on all systems.

To recap your previous comment [1]:

> So for every system and architecture you want to: probe, run some SMC
> and then print error that it is not othe system you wanted.
>
> I don't think this is what we want. You basically pollute all of
other
> users just to have your hypervisor guest additions...

We understand the concern about unnecessary probing and potential
impact on platforms that do not support the GenieZone hypervisor.
However, using a generic SoC info driver is not practical in our case,
as not all products based on the same SoC support the hypervisor or
require the gzvm driver.

Previously, we attempted a device tree solution, but as Rob and Conor
pointed out, introducing a DT node without hardware resources is not
acceptable for upstreaming.

Given these constraints, we are considering reverting to the original
approach, where the driver probes for the hypervisor's presence
directly via HVC. To address your concern about system-wide pollution,
we have guarded the gzvm driver with the CONFIG_MTK_GZVM Kconfig
option. This ensures the code is only compiled and active on selected
platforms, and will not affect other users or systems.

If you have any further suggestions or see a better
solution for this scenario, we would appreciate your advice.

Thanks for your time and feedback.

[1]
https://lore.kernel.org/all/2fe0c7f9-55fc-ae63-3631-8526a0212ccd@linaro.org/

> > +             return -ENODEV;
> > +     }
> > +
> > +     pr_debug("Found GenieZone hypervisor version %u.%u.%llu\n",
> > +              gzvm_drv.hyp_version.major,
> > gzvm_drv.hyp_version.minor,
> > +              gzvm_drv.hyp_version.sub);
> > +
> > +     return misc_register(&gzvm_dev);
> > +}
> > +
> > +static void gzvm_drv_remove(struct platform_device *pdev)
> > +{
> > +     misc_deregister(&gzvm_dev);
> > +}
> > +
> > +static const struct of_device_id gzvm_of_match[] = {
> > +     { .compatible = "mediatek,geniezone" },
> > +     {/* sentinel */},
> > +};
> > +
> > +static struct platform_driver gzvm_driver = {
> > +     .probe = gzvm_drv_probe,
> > +     .remove = gzvm_drv_remove,
> > +     .driver = {
> > +             .name = KBUILD_MODNAME,
> > +             .of_match_table = gzvm_of_match,
> > +     },
> > +};
> > +
> > +module_platform_driver(gzvm_driver);
> > +
> > +MODULE_DEVICE_TABLE(of, gzvm_of_match);
> 
> This is immediately after next to ID table. Never in different place,
> so
> I wonder from which obscure code did you copy it and what other
> issues
> like that we can find...
> 

Thanks, will fix in next version.

> > +MODULE_AUTHOR("MediaTek");
> > +MODULE_DESCRIPTION("GenieZone interface for VMM");
> > +MODULE_LICENSE("GPL");
> Best regards,
> Krzysztof


  reply	other threads:[~2025-08-12  7:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-14 10:07 [PATCH v13 00/25] GenieZone hypervisor drivers Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 01/25] virt: geniezone: enable gzvm-ko in defconfig Liju-clr Chen
2024-12-11  8:38   ` Krzysztof Kozlowski
2024-12-13  5:57     ` Liju-clr Chen (陳麗如)
2024-11-14 10:07 ` [PATCH v13 02/25] docs: geniezone: Introduce GenieZone hypervisor Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 03/25] dt-bindings: hypervisor: Add MediaTek " Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 04/25] virt: geniezone: Add GenieZone hypervisor driver Liju-clr Chen
2024-12-11  8:44   ` Krzysztof Kozlowski
2025-08-12  7:04     ` Liju-clr Chen (陳麗如) [this message]
2025-08-12  7:23       ` Krzysztof Kozlowski
2025-08-12  8:39         ` Liju-clr Chen (陳麗如)
2025-08-12  7:32       ` Krzysztof Kozlowski
2025-08-14  3:27         ` Liju-clr Chen (陳麗如)
2024-11-14 10:07 ` [PATCH v13 05/25] virt: geniezone: Add vm support Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 06/25] virt: geniezone: Add set_user_memory_region for vm Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 07/25] virt: geniezone: Add vm capability check Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 08/25] virt: geniezone: Add vcpu support Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 09/25] virt: geniezone: Add irqchip support for virtual interrupt injection Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 10/25] virt: geniezone: Add irqfd support Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 11/25] virt: geniezone: Add ioeventfd support Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 12/25] virt: geniezone: Add memory region purpose for hypervisor Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 13/25] virt: geniezone: Add dtb config support Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 14/25] virt: geniezone: Optimize performance of protected VM memory Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 15/25] virt: geniezone: Add memory pin/unpin support Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 16/25] virt: geniezone: Add demand paging support Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 17/25] virt: geniezone: Add block-based " Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 18/25] virt: geniezone: Add memory relinquish support Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 19/25] virt: geniezone: Provide individual VM memory statistics within debugfs Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 20/25] virt: geniezone: Add tracing support for hyp call and vcpu exit_reason Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 21/25] virt: geniezone: Enable PTP for synchronizing time between host and guest VMs Liju-clr Chen
2024-11-14 10:07 ` [PATCH v13 22/25] virt: geniezone: Add support for virtual timer migration Liju-clr Chen
2024-11-14 10:08 ` [PATCH v13 23/25] virt: geniezone: Add support for guest VM CPU idle Liju-clr Chen
2024-11-14 10:08 ` [PATCH v13 24/25] virt: geniezone: Emulate IPI for guest VM Liju-clr Chen
2024-11-14 10:08 ` [PATCH v13 25/25] virt: geniezone: Reduce blocked duration in hypervisor when destroying a VM Liju-clr Chen

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=cb84d8d87a67516f9b92a89f81fe4efc088f7617.camel@mediatek.com \
    --to=liju-clr.chen@mediatek.com \
    --cc=Chi-shen.Yeh@mediatek.com \
    --cc=Kevenny.Hsieh@mediatek.com \
    --cc=PeiLun.Suei@mediatek.com \
    --cc=Yingshiuan.Pan@mediatek.com \
    --cc=Ze-yu.Wang@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mhiramat@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=robh@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=shawn.hsiao@mediatek.com \
    --cc=will@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).