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
| ||
|
Date: Thu, 18 Feb 2016 09:25:04 +0700 From: Suravee Suthikulpanit <Suravee.Suthikulpanit@....com> To: Radim Krčmář <rkrcmar@...hat.com>, Paolo Bonzini <pbonzini@...hat.com> CC: <joro@...tes.org>, <alex.williamson@...hat.com>, <gleb@...nel.org>, <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <wei@...hat.com>, <sherry.hurwitz@....com> Subject: Re: [PART1 RFC 5/9] svm: Add VMEXIT handlers for AVIC Hi On 2/17/16 01:06, Radim Krčmář wrote: > 2016-02-16 17:56+0100, Paolo Bonzini: >> >On 16/02/2016 15:13, Radim Krčmář wrote: >>> >>Yeah, I think atomic there means that it won't race with other writes to >>> >>the same byte in IRR. We're fine as long as AVIC writes IRR before >>> >>checking IsRunning on every destination, which it seems to be. >> > >> >More precisely, if AVIC writes all IRRs (5.1) and ANDs all IsRunning >> >flags before checking the result of the AND (6). >> > >>> >>(It would, but I believe that AVIC designers made it sane and the spec >>> >> doesn't let me read it in a way that supports your theories.) >> > >> >I hope so as well, and you've probably convinced me. But I still think >> >the code is wrong in this patch. Let's look at the spec that you pasted: > The code definitely is wrong. I'll be more specific when disagreeing, > sorry. > Would you please be a bit more specific on what you think I am not doing correctly to handle the #VMEXIT in the case of target not running below. + case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN: + kvm_lapic_reg_write(apic, APIC_ICR2, icrh); + kvm_lapic_reg_write(apic, APIC_ICR, icrl); This is actually not just writing to the register. Please note that writing to APIC_ICR register would also be calling apic_send_ipi(), which results in injecting interrupts to the target core: From: arch/x86/kvm/lapic.c: kvm_lapic_write_reg() [....] case APIC_ICR: /* No delay here, so we always clear the pending bit */ apic_set_reg(apic, APIC_ICR, val & ~(1 << 12)); apic_send_ipi(apic); break; case APIC_ICR2: if (!apic_x2apic_mode(apic)) val &= 0xff000000; apic_set_reg(apic, APIC_ICR2, val); break; Am I missing something? Thanks, Suravee
Powered by blists - more mailing lists