linux-kernel - Re: [PATCH v2 3/7] virt: geniezone: Introduce GenieZone hypervisor support

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]

Date:   Mon, 22 May 2023 04:29:36 +0000
From:   Yi-De Wu (吳一德) <Yi-De.Wu@...iatek.com>
To:     "maz@...nel.org" <maz@...nel.org>
CC:     "corbet@....net" <corbet@....net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        MY Chuang (莊明躍) <MY.Chuang@...iatek.com>,
        "quic_tsoni@...cinc.com" <quic_tsoni@...cinc.com>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Ivan Tseng (曾志軒) 
        <ivan.tseng@...iatek.com>,
        Ze-yu Wang (王澤宇) 
        <Ze-yu.Wang@...iatek.com>,
        PeiLun Suei (隋培倫) 
        <PeiLun.Suei@...iatek.com>,
        Liju-clr Chen (陳麗如) 
        <Liju-clr.Chen@...iatek.com>,
        "yi-de.wu@...iatek.corp-partner.google.com" 
        <yi-de.wu@...iatek.corp-partner.google.com>,
        Jades Shih (施向玨) 
        <jades.shih@...iatek.com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "dbrazdil@...gle.com" <dbrazdil@...gle.com>,
        "yipei.chang@...il.com" <yipei.chang@...il.com>,
        Shawn Hsiao (蕭志祥) 
        <shawn.hsiao@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Miles Chen (陳民樺) 
        <Miles.Chen@...iatek.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        Yingshiuan Pan (潘穎軒) 
        <Yingshiuan.Pan@...iatek.com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "will@...nel.org" <will@...nel.org>
Subject: Re: [PATCH v2 3/7] virt: geniezone: Introduce GenieZone hypervisor
 support

On Fri, 2023-05-12 at 10:59 +0100, Marc Zyngier wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On Fri, 12 May 2023 08:17:58 +0100,
> "Yi-De Wu (吳一德)" <Yi-De.Wu@...iatek.com> wrote:
> > 
> > On Fri, 2023-04-28 at 23:12 +0100, Marc Zyngier wrote:
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > > 
> > > 
> > > On 2023-04-28 11:36, Yi-De Wu wrote:
> > > > From: "Yingshiuan Pan" <yingshiuan.pan@...iatek.com>
> > > > 
> > > > +config MTK_GZVM
> > > > +     tristate "GenieZone Hypervisor driver for guest VM
> > > > operation"
> > > > +     depends on ARM64
> > > > +     depends on KVM
> > > 
> > > NAK.
> > > 
> > > Either this is KVM, and this code serves no purpose, or it is a
> > > standalone
> > > hypervisor, and it *cannot* have a dependency on KVM.
> > > 
> > > [...]
> > > 
> > 
> > In order to be self-contained and avoid dependency like with KVM,
> > may
> > we leverage KVM's symbol, macro e.g. VGIC_NR_SGIS,
> > VGIC_NR_PRIVATE_IRQS...etc, and copy or rename the related part to
> > */geniezone/?
> 
> Again, these are architected constants. You can have your own. You
> can
> already consider any use of a KVM structure or symbol as a bug.
> 
>         M.
> 
> --
> Without deviation from the norm, progress is not possible.

Noted, we've received clear messages and agreed the current usage on
KVM's data structure and function prototype should be treated as bugs.
We would provide our own implementation on v4 to solve this issue.