On Thu, Sep 24, 2015 at 03:33:18AM -0600, Jan Beulich wrote: > >>> On 24.09.15 at 11:10, <t...@xen.org> wrote: > > At 01:02 -0600 on 24 Sep (1443056566), Jan Beulich wrote: > >> --- a/xen/arch/x86/mm/p2m-ept.c > >> +++ b/xen/arch/x86/mm/p2m-ept.c > >> @@ -130,14 +130,18 @@ static void ept_p2m_type_to_flags(struct p2m_domain > >> *p2m, ept_entry_t *entry, > >> break; > >> case p2m_ram_rw: > >> entry->r = entry->w = entry->x = 1; > >> - entry->a = entry->d = 1; > >> + entry->a = entry->d = cpu_has_ept_ad; > >> break; > >> case p2m_mmio_direct: > >> entry->r = entry->x = 1; > >> entry->w = !rangeset_contains_singleton(mmio_ro_ranges, > >> entry->mfn); > >> - entry->a = 1; > >> - entry->d = entry->w; > >> + entry->a = cpu_has_ept_ad; > >> + entry->d = entry->w && cpu_has_ept_ad; > >> break; > >> case p2m_ram_logdirty: > >> entry->r = entry->x = 1; > >> > > > > Sure, that works. I still prefer putting the workaround on the CR3 > > operation, so all the cost happens on the broken chip, but I'll shut > > up about that now. :) > > And I agree to that for post-4.6. For 4.6 the easier to validate > fix still would seem to be a variation of what Ross posted. >
I just finished this thread. Looks like HV maintainers have devised a plan for this issue. Thank you all. Wei. > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel