Messages in this thread |  | | Date | Tue, 18 May 2021 20:37:58 +0000 | | From | Sean Christopherson <> | | Subject | Re: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO |
| |
On Tue, May 18, 2021, Andi Kleen wrote: > > On 5/18/2021 11:22 AM, Sean Christopherson wrote: > > On Tue, May 18, 2021, Andi Kleen wrote: > > > > 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. > > > Yes but what's the point of all that? > > Patching IO_COND() is relatively low effort. With some clever refactoring, I > > suspect the net lines of code added would be less than 10. That seems like a > > worthwhile effort to avoid millions of faults over the lifetime of the guest. > > AFAIK IO_COND is only for iomap users. But most drivers don't even use > iomap. virtio doesn't for example, and that's really the only case we > currently care about.
virtio-pci, which is going to used by pretty much all traditional VMs, uses iomap. See vp_get(), vp_set(), and all the vp_io{read,write}*() wrappers.
|  |