Re: AD bits in traditional PV mode

[Andres Lagar Cavilla <andres@lagarcavilla.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2457 bytes --]

Thanks for the clarification, Andrew.

On Tue, Feb 20, 2018 at 5:20 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 21/02/2018 00:42, Andres Lagar Cavilla wrote:
> > Hello everyone,
> >
> > I was thinking of the traditional Xen PV mode in which page table
> > pages are write protected from guest meddling and PTE
> > modifications are audited by the hypervisor (ptwr_emulated_update()
> > these days, still?).
>
> Something like that, yes.  Alternatively, via explicit hypercall which
> is faster than the trap&emulate path.
>
> > Without software shadows or paging to e.g. an EPT, native PV loads the
> > actual CR3 pointing to a write protected page table tree.
>
> Unfortunately, I've lost you here.  There is no such thing as a
> write-protected pagetable tree in the traditional PV sense.
>
> > When the cr3 is loaded, the hardware walker will want to set A and D
> > bits in PTEs -- is this action immune to the write protection in the
> > page table pages themselves? Or do we take emulation faults on these
> > updates as well?
>
> The protection that Xen enforces on PV guests is that an L1 PTE mapping
> a pagetable frame must never be writeable.  This protection happens at
> the linear address level.  When the CPU pagewalker tries to set A/D
> bits, it issues an atomic update to the physical address of the
> pagetable entry which needs updating.
>
> As with everything, there are complicating factors.  With EPT/NPT for
> HVM guests these days, the hypervisor can also apply permissions to
> guest physical addresses, as part of their translation to host physical
> addresses.  The hardware pagewalker, when attempting to set an A/D bit
> of the HVM guests regular pagetables, issues an EPT/NPT write (well -
> RMW strictly) to set the bits.
>
> Therefore, if the hypervisor marks an HVM guest's pagetable as
> read-only, then the hardware pagewalker trying to set A/D bits will
> vmexit with an EPT/NPT permissions violation.  This is one major
> performance limiting factor of introspection technology at the moment.
>

Indeed, this is what I was coming at. In my experience guests will be very
adversely affected if we just latch the D bits to 1 unilaterally (it's
legal to do so by the "hardware"), as they will be led to believe file
cache pages are in constant need of writeback. (and A bits latched to 1
turn e.g. Linux's vmscan.c into a crapshoot)

So this is currently not too hopeful

Thanks again
Andres

>
> ~Andrew
>

[-- Attachment #1.2: Type: text/html, Size: 3279 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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