lkml.org 
[lkml]   [2021]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO
    On Tue, May 18, 2021, Andi Kleen wrote:
    > On 5/18/2021 8:00 AM, Dave Hansen wrote:
    > > That sounds like something objective we can measure. Does this cost 1
    > > byte of extra text per readl/writel? 10? 100?
    >
    > Alternatives are at least a pointer, but also the extra alternative code.
    > It's definitely more than 10, I would guess 40+

    The extra bytes for .altinstructions is very different than the extra bytes for
    the code itself. The .altinstructions section is freed after init, so yes it
    bloats the kernel size a bit, but the runtime footprint is unaffected by the
    patching metadata.

    IIRC, patching read/write{b,w,l,q}() can be done with 3 bytes of .text overhead.

    The other option to explore is to hook/patch IO_COND(), which can be done with
    neglible overhead because the helpers that use IO_COND() are not inlined. In a
    TDX guest, redirecting IO_COND() to a paravirt helper would likely cover the
    majority of IO/MMIO since virtio-pci exclusively uses the IO_COND() wrappers.
    And if there are TDX VMMs that want to deploy virtio-mmio, hooking
    drivers/virtio/virtio_mmio.c directly would be a viable option.

    \
     
     \ /
      Last update: 2021-05-18 19:13    [W:6.990 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site