[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e4934a021c17dc8bfd8b2bdd8a4543e9ffe09e58.camel@infradead.org>
Date: Mon, 18 Sep 2023 13:26:26 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: paul@....org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: Paul Durrant <pdurrant@...zon.com>,
Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH v2 09/12] KVM: selftests / xen: set
KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID
On Mon, 2023-09-18 at 13:18 +0100, Paul Durrant wrote:
> On 18/09/2023 12:59, David Woodhouse wrote:
> > On Mon, 2023-09-18 at 11:21 +0000, Paul Durrant wrote:
> > > From: Paul Durrant <pdurrant@...zon.com>
> > >
> > > If the capability (KVM_XEN_HVM_CONFIG_EVTCHN_SEND) is present then set
> > > the guest's vCPU id to match the chosen vcpu_info offset.
> >
> > I think from KVM's point of view, the vcpu_id is still zero. As is the
> > vcpu_idx. What you're setting is the *Xen* vcpu_id.
>
> Ok. I'll clarify the terminology; and I'll need to set it before the
> shinfo as noted on another thread.
>
> >
> > I like that it's *different* to the vcpu_id; we should definitely be
> > testing that case.
>
> How so?
>
Well, imagine you'd not got the kernel's get_vcpu_info_cache() right,
and you accidentally used v->vcpu_id instead of v->arch.xen.vcpu_id. An
easy mistake to make, right?
If you had made that mistake (you didn't; I checked), and if those
numbers had happened to be equal in this test... then this test
wouldn't have shown it.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)
Powered by blists - more mailing lists