Hi,
At 22:42 +0100 on 02 Jul (1246574577), Gianluca Guida wrote:
> CPU0 doesn't resync a whole L1 page because it's accessing it. There
> are other reasons for a resync here (especially if the guest is 64
> bit), but most probably the resync happen because CPU0 is unsyncing
> another page. Anyway yes, it's highly unlikely but this race can
> definitely happen. I think I never saw it.
Yes. The fast-not-present path is safe without OOS because the changing
L1 would have to be as a result of the guest writing it, which is a race
on real hardware. The fast-MMIO path is OK even with OOS because it
only caches present entries, but for proper safety we might want to
avoid using fast-path MMIO if the guest maps MMIO space read-only (does
anyone actually do that?)
> > I haven't checked the fast emulation path, but similar problems might be
> > lurking there in combination with OOS.
>
> I think that it should be safe enough, but yes another look at it
> should be worth it.
I think you might as well kill the fast emulation path too, while you're
in there. :) The OOS optimization makes it mostly redundant, and it
just adds complexity now.
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel