[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 27.03.14 at 16:48, <tim@xxxxxxx> wrote:
> 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.

Right - I didn't take non-present (but valid) leaf entries properly into
account here. Thanks for spotting this!

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.