Re: [Xen-devel] [PATCH 6/8] x86/EPT: force re???evaluation of memory type as necessary

[Tim Deegan <tim@xxxxxxx>]

At 15:23 +0000 on 27 Mar (1395930232), Jan Beulich wrote:
> > 
> > Do you need to also set ept_spurious_misconfig flags here?  At the
> > moment you set them when a present entry gets reset, but what about a
> > walk that hits a not-present entry (e.g. mmio_dm)?  There, the first
> > CPU to take a fault will clear up the intermediate nodes, but not
> > make any chaneg at level 0 or set the ept_spurious_misconfig flags.
> 
> Actually I think I need to swap the order of operations instead:
> first invalidate the next level, then clear .emt.

Oh yes, good point.

> Then the current
> model of needing to set the flag only when making an entry valid
> will be correct/consistent afaict.

Let me work through an example: in a 2-level EPT table (for clarity),
the guest has an mmio-dm entry (or a log-dirty, or otherwise not
present).  The EPTEs look like this:

L1: present
L0: not present, type mmio_dm

after an MTRR change it look like this:

L1: present, bad EMT
L0: not present, type mmio_dm

Two CPUs fault on it at the same time.  The first one to the p2m lock
goes through this walk, clears the bad EMT on the L1 and
ept_invalidate_emt()s the whole L0 page.  That _doesn't_ set bad EMT 
on the L0 entry because the L0 entry is not present.

L1: present
L0: not present, type mmio_dm

The other CPU then takes the p2m lock, sees a perfectly good walk and
hasn't been told to expect a spurious fault --> crash. 

So if we clear any intermediate EMTs we need to warn the other CPUs
to expect spurious faults.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel