Re: [Xen-devel] [PATCH v1] x86/mm: Suppresses vm_events caused by page-walks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.08.18 at 15:47, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 8/27/18 4:17 PM, Jan Beulich wrote:
>>>>> On 27.08.18 at 15:02, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> This should be architecturally correct as it is exclusively derived from
>>> information provided by the VMExit, and won't cause dirty bits to be
>>> written in cases where the hardware wouldn't have written them
>>> (speculative or otherwise).  It does mean that an instruction which
>>> would need to set A and D bits in the walk will take two EPT violations
>>> to achieve the end result, but it probably is still quicker than sending
>>> the vm_event out.
>> 
>> I'm afraid this is going to be only mostly correct: Atomicity of the page
>> table write is going to be lost. This could become an actual problem if
>> the guest used racing PTE accesses. Such racing accesses might not
>> be a bug - simply consider the OS scanning for set A and/or D bits
>> (and clearing them when they're set). Or an entity temporarily clearing
>> (parts of) PTEs, with recovery logic in place to restore them when
>> needed for a synchronous access. At the very least there's then the
>> risk of a live lock within the guest.
> 
> But it's not clear to me why that can't already happen when just
> emulating the current instruction (as we do now), if emulating said
> instruction would set A or D?

Yes, good point - this is a problem not just to the new handling you
propose.

Jan



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