linux-kernel - Re: [PATCH v2 08/12] KVM: xen: automatically use the vcpu_info embedded in shared

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, 18 Sep 2023 12:49:42 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     Paul Durrant <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>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH v2 08/12] KVM: xen: automatically use the vcpu_info
 embedded in shared_info

On Mon, 2023-09-18 at 11:21 +0000, Paul Durrant wrote:
> -                                              This is because KVM may
> -  not be aware of the Xen CPU id which is used as the index into the
> -  vcpu_info[] array, so may know the correct default location.

Hm, that *was* true at the time of writing, but we did end up teaching
KVM about the Xen vcpu_id so that we can handle timers. (We required
userspace to provide the APIC ID for all the other event channel stuff,
but timer hypercalls come straight from the guest).

But I think the *only* thing we use vcpu->arch.xen.vcpu_id for right
now is acceleration of the timer hypercalls that are restricted to the
vCPU that they're called from, e.g.:

	case VCPUOP_set_singleshot_timer:
		if (vcpu->arch.xen.vcpu_id != vcpu_id) {
			*r = -EINVAL;

So it's never mattered much before now if the Xen vcpu_id changes at
runtime.

Maybe you now want to invalidate the vcpu_info pfncache for a vCPU if
its Xen vcpu_id changes? Or just *forbid* such a change after the
shinfo page has been set up? What locking prevents the xen.vcpu_id
changing in the middle of your new get_vcpu_info_cache() function?

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)