lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <23b7cc9681b69946562be50079ece0c6bd6308ff.camel@mediatek.com>
Date: Tue, 1 Jul 2025 05:50:46 +0000
From: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>
To: "chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>, "AngeloGioacchino Del
 Regno" <angelogioacchino.delregno@...labora.com>, "robh@...nel.org"
	<robh@...nel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"jassisinghbrar@...il.com" <jassisinghbrar@...il.com>, "mchehab@...nel.org"
	<mchehab@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	CK Hu (胡俊光) <ck.hu@...iatek.com>
CC: "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	Sirius Wang (王皓昱) <Sirius.Wang@...iatek.com>,
	Moudy Ho (何宗原) <Moudy.Ho@...iatek.com>,
	Nancy Lin (林欣螢) <Nancy.Lin@...iatek.com>,
	Xiandong Wang (王先冬)
	<Xiandong.Wang@...iatek.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@...iatek.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Paul-pl Chen (陳柏霖) <Paul-pl.Chen@...iatek.com>,
	"fshao@...omium.org" <fshao@...omium.org>,
	Singo Chang (張興國) <Singo.Chang@...iatek.com>,
	"wenst@...omium.org" <wenst@...omium.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>, Xavier Chang (張獻文)
	<Xavier.Chang@...iatek.com>
Subject: Re: [PATCH v6 06/20] mailbox: mtk-cmdq: Add GCE hardware
 virtualization configuration

On Fri, 2025-06-27 at 08:41 +0000, CK Hu (胡俊光) wrote:
> On Mon, 2025-06-02 at 01:31 +0800, Jason-JH Lin wrote:
> > The GCE hardware virtualization configuration supports the
> > isolation of
> > GCE hardware resources across different OS environments. Each OS is
> > treated as a virtual machine (VM) for GCE purposes.
> > There are 6 VMs and 1 host VM. The host VM has main control over
> > the
> > GCE virtualization settings for all VMs.
> > 
> > To properly access the GCE thread registers, it is necessary to
> > configure access permissions for specific GCE threads assigned to
> > different VMs.
> > Currently, since only the host VM is being used, it is required to
> > enable access permissions for all GCE threads for the host VM.
> > 
> > There are 2 VM configurations:
> > 1. VM_ID_MAP
> > There are 4 registers to allocate 32 GCE threads across different
> > VMs:
> > VM_ID_MAP0 for threads 0-9, VM_ID_MAP1 for threads 10-19,
> > VM_ID_MAP2 for threads 20-29, and VM_ID_MAP3 for threads 30-31.
> > Each thread has a 3-bit configuration, where setting all bits to 1
> > configures the thread for the host VM.
> > 
> > 2. VM_CPR_GSIZE
> > It is used to allocate the CPR SRAM size to each VM. Each VM has 4-
> > bit
> > configuration, where setting bit 0-3 to configures the size of host
> > VM.
> > This setting must be configured before the VM configuration to
> > prevent
> > resource leakage.
> > 
> > Signed-off-by: Jason-JH Lin <jason-jh.lin@...iatek.com>
> > ---
> 
> [snip]
> 
> > +
> >  static void cmdq_gctl_value_toggle(struct cmdq *cmdq, bool
> > ddr_enable)
> >  {
> >  	u32 val = cmdq->pdata->control_by_sw ? GCE_CTRL_BY_SW : 0;
> > @@ -162,6 +211,7 @@ static void cmdq_init(struct cmdq *cmdq)
> >  
> >  	WARN_ON(clk_bulk_enable(cmdq->pdata->gce_num, cmdq-
> > >clocks));
> >  
> > +	cmdq_vm_toggle(cmdq, true);
> >  	cmdq_gctl_value_toggle(cmdq, true);
> >  
> >  	writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base +
> > CMDQ_THR_SLOT_CYCLES);
> > @@ -335,6 +385,7 @@ static int cmdq_runtime_resume(struct device
> > *dev)
> >  	if (ret)
> >  		return ret;
> >  
> > +	cmdq_vm_toggle(cmdq, true);
> >  	cmdq_gctl_value_toggle(cmdq, true);
> >  	return 0;
> >  }
> > @@ -344,6 +395,7 @@ static int cmdq_runtime_suspend(struct device
> > *dev)
> >  	struct cmdq *cmdq = dev_get_drvdata(dev);
> >  
> >  	cmdq_gctl_value_toggle(cmdq, false);
> > +	cmdq_vm_toggle(cmdq, false);
> 
> Why turn off permission when suspend?
> Why not always turn on permission?
> 

Yes, you're right!

VM permission settings should not be disabled or reset after boot up.
But we don't have the Hypervisor to keep the GCE HOST VM settings,
so we need to configure the VM setting again after cmdq_resume() to
avoid the GCE VM settings being cleared after cmdq_suspend().

I'll drop this VM setting here and rename the API as cmdq_vm_init()
without the disable VM settings flow.

Regards,
Jason-JH Lin

> Regards,
> CK
> 
> >  	clk_bulk_disable(cmdq->pdata->gce_num, cmdq->clocks);
> >  	return 0;
> >  }
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ