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

[Yi-De Wu (吳一德)]

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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> > > > 
> > > > +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.