Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 26 Apr 2022 10:41:09 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     Juergen Gross <jgross@suse.com>
Cc:     Oleksandr <olekstysh@gmail.com>,
        Christoph Hellwig <hch@infradead.org>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        xen-devel@lists.xenproject.org, x86@kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Julien Grall <julien@xen.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access
 under Xen
Message-ID: <YmewJaxWS1KGVkTf@zn.tnic>
References: <1650646263-22047-1-git-send-email-olekstysh@gmail.com>
 <1650646263-22047-4-git-send-email-olekstysh@gmail.com>
 <YmQsFb36UEH9BUnN@infradead.org>
 <6c5042fe-dafc-eb4f-c1fa-03b0faf252de@gmail.com>
 <abc5d23d-3d38-d198-4646-e886df2e83d4@suse.com>
 <YmZUpua3hkCPdbfx@infradead.org>
 <147f68f6-7d67-1884-bd14-5040639b3396@suse.com>
 <67c7460a-3001-35a6-8e5b-f367270b257a@gmail.com>
 <YmcR5bfaYh1z7VUq@zn.tnic>
 <7d89848a-3a1c-415d-957a-564ffdd3712d@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <7d89848a-3a1c-415d-957a-564ffdd3712d@suse.com>
Precedence: bulk

On Tue, Apr 26, 2022 at 07:16:16AM +0200, Juergen Gross wrote:
> Christoph suggested (rather firmly) this would be the way to go.

Yeah, I saw it but I don't think it is the right way to go.

What happens the next time a guest needs to query the platform
underneath? Misuse these interfaces again?

Because people will see the Xen use and say, hey, look, I will use this
for my funky HV too.

Even worse: what happens if Xen decides to implement SEV/TDX? Then
you're in for a world of fun.

Now, if we want to *extend* the interfaces to have something as generic
as, say, platform_has() and that should be the way for generic kernel
code running in the guest to query the platform capabilities, then sure,
by all means.

> This is needed on guest side at a rather hypervisor independent place.
> 
> So a capability of some sort seems appropriate.
> 
> Another suggestion of mine was to have a callback (or flag) in
> struct x86_hyper_runtime for that purpose.

This becomes an issue if the HV is not x86 - then you need a different
method of querying it, which then underneath will call the arch-specific
interface.

I don't know how much of querying guests need to do and how they've been
doing that so far. Depending on the requirements, we probably should
think about a clean design from the get-go instead of homegrown things.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette