Re: [Xen-devel] L1TF, and future work

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.08.18 at 15:17, <andrew.cooper3@xxxxxxxxxx> wrote:
> 2) 32bit PV guests which use writeable pagetable support will
> automatically get shadowed when the clear the lower half.

... of a page table entry.

>  Ideally, such
> guests should be modified to use hypercalls rather than the ptwr
> infrastructure (as its more efficient to begin with), but we can
> probably work around this in Xen by emulating the next few instructions
> until we have a complete PTE (same as the shadow code).

Provided the intervening insns are simple enough. I've looked into
current Linux pv-ops code the other day, and afaict it's already
using mmu-op or cmpxchg8b, but not two separate mov-s. But
of course I've looked at the general routines only, not at things
perhaps hidden in special cases, or in init-only code.

> 4) The shadow MMIO fastpath truncates the MMIO gfn at 2^28 without any
> indication of failure.  The most compatible bugfix AFACIT would be to
> add an extra nibble's worth of gfn space which gets us to 2^32, and
> clamp the guest maxphysaddr calculation at 44 bits.  The alternative is
> to clamp maxphysaddr to 40 bits, but that will break incoming migrate of
> very large shadow guests.

Urgh.

> 4a) The shadow MMIO fastpath needs a runtime clobber, because it will
> not function at all on Icelake hardware with a 52-bit physical address
> width.  Also, it turns out there is an architectural corner case when
> levelling maxphysaddr, where some bits which (v)maxphysaddr says should
> elicit #PF[RSVD], don't because the actual pipeline address width is larger.

By "runtime clobber" you mean something to disable that path at
runtime, rather than at build time?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel