linux-kernel - RE: [PATCH v2] x86/hyperv: make vapic support x2apic mode

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:   Fri, 4 Oct 2019 22:33:29 +0000
From:   Michael Kelley <mikelley@...rosoft.com>
To:     Roman Kagan <rkagan@...tuozzo.com>
CC:     vkuznets <vkuznets@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        Tianyu Lan <Tianyu.Lan@...rosoft.com>,
        Joerg Roedel <jroedel@...e.de>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Sasha Levin <sashal@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] x86/hyperv: make vapic support x2apic mode

From: Roman Kagan <rkagan@...tuozzo.com> Sent: Friday, October 4, 2019 2:19 AM
> 
> On Fri, Oct 04, 2019 at 03:01:51AM +0000, Michael Kelley wrote:
> > From: Roman Kagan <rkagan@...tuozzo.com> Sent: Thursday, October 3, 2019 5:53 AM
> > > >
> > > > AFAIU you're trying to mirror native_x2apic_icr_write() here but this is
> > > > different from what hv_apic_icr_write() does
> > > > (SET_APIC_DEST_FIELD(id)).
> > >
> > > Right.  In xapic mode the ICR2 aka the high 4 bytes of ICR is programmed
> > > with the destination id in the highest byte; in x2apic mode the whole
> > > ICR2 is set to the 32bit destination id.
> > >
> > > > Is it actually correct? (I think you've tested this and it is but)
> > >
> > > As I wrote in the commit log, I haven't tested it in the sense that I
> > > ran a Linux guest in a Hyper-V VM exposing x2apic to the guest, because
> > > I didn't manage to configure it to do so.  OTOH I did run a Windows
> > > guest in QEMU/KVM with hv_apic and x2apic enabled and saw it write
> > > destination ids unshifted to the ICR2 part of ICR, so I assume it's
> > > correct.
> > >
> > > > Michael, could you please shed some light here?
> > >
> > > Would be appreciated, indeed.
> > >
> >
> > The newest version of Hyper-V provides an x2apic in a guest VM when the
> > number of vCPUs in the VM is > 240.  This version of Hyper-V is beginning
> > to be deployed in Azure to enable the M416v2 VM size, but the functionality
> > is not yet available for the on-premises version of Hyper-V.  However, I can
> > test this configuration internally with the above patch -- give me a few days.
> >
> > An additional complication is that when running on Intel processors that offer
> > vAPIC functionality, the Hyper-V "hints" value does *not* recommend using the
> > MSR-based APIC accesses.  In this case, memory-mapped access to the x2apic
> > registers is faster than the synthetic MSRs.
> 
> I guess you mean "using regular x2apic MSRs compared to the synthetic
> MSRs".  

Yes, of course you are correct.

> Indeed they do essentially the same thing, and there's no reason
> for one set of MSRs to be significantly faster than the other.  However,
> hv_apic_eoi_write makes use of "apic assists" aka lazy EOI which is
> certainly a win, and I'm not sure if it works without hv_apic.
> 

I've checked with the Hyper-V people and the presence of vAPIC makes
a difference.  If vAPIC is present in the hardware:
1) Hyper-V does not set the HV_X64_APIC_ACCESS_RECOMMENDED flag
2) The architectural MSRs should be used instead of the Hyper-V
    synthetic MSRs, as they are significantly faster.  The architectural
    MSRs do not cause a VMEXIT because they are handled entirely by
    the vAPIC microcode in the CPU.  The synthetic MSRs do cause a VMEXIT.
3) The lazy EOI functionality should not be used

If vAPIC is not present in the hardware:
1) Hyper-V will set HV_X64_APIC_ACCESS_RECOMMENDED
2) Either set of MSRs has about the same performance, but we
    should use the synthetic MSRs.
3) The lazy EOI functionality has some value and should be used

The same will apply to the AMD AVIC in some Hyper-V updates that
are coming soon.

So I think your code makes sense given the above information.  By
Monday I'll try to test it on a Hyper-V guest VM with x2APIC.

Michael