Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Date:   Mon, 18 Sep 2023 15:05:39 +0100
From:   David Woodhouse <dwmw2@infradead.org>
To:     paul@xen.org, Paul Durrant <xadimgnik@gmail.com>,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org
CC:     Paul Durrant <pdurrant@amazon.com>,
        Sean Christopherson <seanjc@google.com>,
        Paolo Bonzini <pbonzini@redhat.com>
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2_11/12=5D_KVM=3A_selftests_/_xen=3A?= =?US-ASCII?Q?_don=27t_explicitly_set_the_vcpu=5Finfo_address?=
User-Agent: K-9 Mail for Android
In-Reply-To: <f5eab713-fa74-2cbc-7df5-81d8d26fee0a@xen.org>
References: <20230918112148.28855-1-paul@xen.org> <20230918112148.28855-12-paul@xen.org> <f649285c0973ec59180ed51c4ee10cdc51279505.camel@infradead.org> <56dad458-8816-2de5-544e-a5e50c5ad2a2@xen.org> <c9a1961812b0cbb6e9f641dec5c6edcb21482161.camel@infradead.org> <f5eab713-fa74-2cbc-7df5-81d8d26fee0a@xen.org>
Message-ID: <425F7A5D-58D1-4D94-A88C-E7B1EAEAD084@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On 18 September 2023 14:41:08 BST, Paul Durrant <xadimgnik@gmail=2Ecom> wr=
ote:
>Well, if the VMM is using the default then it can't unmap it=2E But setti=
ng a vcpu_info *after* enabling any event channels would be a very odd thin=
g for a guest to do and IMO it gets to keep the pieces if it does so=2E


Hm, I suppose I'm OK with that approach=2E The fact that both VMM implemen=
tations using this KVM/Xen support let the guest keep precisely those piece=
s is a testament to that :)

But now we're hard-coding the behaviour in the kernel and declaring that n=
o VMM will be *able* to "fix" that case even if it does want to=2E So perha=
ps it wants a modicum more thought and at least some explicit documentation=
 to that effect?

And a hand-wavy plan at least for what we'd do if we suddenly did find a r=
eason to care?