lkml.org 
[lkml]   [2021]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v3 00/17] KVM: x86/pmu: Add support to enable Guest PEBS via DS
    From
    Date
    Hi Sean,

    Thanks for your comments !

    On 2021/1/15 3:10, Sean Christopherson wrote:
    > On Mon, Jan 04, 2021, Like Xu wrote:
    >> 2) Slow path (part 3, patch 0012-0017)
    >>
    >> This is when the host assigned physical PMC has a different index
    >> from the virtual PMC (e.g. using physical PMC1 to emulate virtual PMC0)
    >> In this case, KVM needs to rewrite the PEBS records to change the
    >> applicable counter indexes to the virtual PMC indexes, which would
    >> otherwise contain the physical counter index written by PEBS facility,
    >> and switch the counter reset values to the offset corresponding to
    >> the physical counter indexes in the DS data structure.
    >>
    >> Large PEBS needs to be disabled by KVM rewriting the
    >> pebs_interrupt_threshold filed in DS to only one record in
    >> the slow path. This is because a guest may implicitly drain PEBS buffer,
    >> e.g., context switch. KVM doesn't get a chance to update the PEBS buffer.
    > Are the PEBS record write, PEBS index update, and subsequent PMI atomic with
    > respect to instruction execution? If not, doesn't this approach still leave a
    > window where the guest could see the wrong counter?

    First, KVM would limit/rewrite guest DS pebs_interrupt_threshold to one
    record before vm-entry,
    (see patch [PATCH v3 14/17] KVM: vmx/pmu: Limit pebs_interrupt_threshold in
    the guest DS area)
    which means once a PEBS record is written into the guest pebs buffer,
    a PEBS PMI will be generated immediately and thus vm-exit.

    Second, KVM would complete the PEBS record rewriting, PEBS index update,
    and inject vPMI
    before the next vm-entry (we deal with these separately in patches 15-17
    for easy review).

    After the updated PEBS record(s) are (atomically?) prepared, guests will be
    notified via PMI
    and there is no window for vcpu to check whether there is a PEBS record due
    to vm-exit.

    > The virtualization hole is also visible if the guest is reading the PEBS records
    > from a different vCPU, though I assume no sane kernel does that?

    I have checked the guest PEBS driver behavior for Linux and Windows, and
    they're sane.

    Theoretically, it's true for busy-poll PBES buffer readers from other vCPUs
    and to fix it, making all vCPUs vm-exit is onerous for a large-size guest
    and I don't think you would accept this or do we have a better idea ?

    In fact, we don't think it's a hole or vulnerability because the motivation for
    correcting the counter index(s) is to help guest PEBS reader understand their
    PEBS records correctly and provide the same sampling accuracy as the non-cross
    mapped case, instead of providing a new attack interface from guest to host.

    PeterZ commented on the V1 version and insisted that the host perf allows
    the guest
    counter to be assigned a cross-mapped back-end counter. In this case, the
    slow path
    patches (13-17) are introduced to ensure that from the guest counter
    perspective,
    the PEBS records are also correct. We do not want these records to be
    invalid and
    ignored, which would undermine the accuracy of PEBS.

    In the practical use, the slow patch rarely happens and
    we're glad to see if the fast patch could be upstream
    and the cross-mapped case is teamprily disabled
    until we're on the same page for the cross mapped case.

    In actual use, slow path rarely occur. As a first step,
    we propose to upstream the quick patches (patch 01-12) with your help.
    The guest PEBS would been disabled temporarily when guest PEBS counters
    are cross-mapped until we figure out a satisfactory cross-mapping solution.

    ---
    thx,likexu

    >
    >> The physical PMC index will confuse the guest. The difficulty comes
    >> when multiple events get rescheduled inside the guest. Hence disabling
    >> large PEBS in this case might be an easy and safe way to keep it corrects
    >> as an initial step here.

    \
     
     \ /
      Last update: 2021-01-15 03:04    [W:4.257 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site