Re: [Xen-devel] [PATCH 01/10] VMX: Enable EPT A/D bit support

[Kai Huang <kai.huang@xxxxxxxxxxxxxxx>]

On 04/09/2015 07:21 PM, Tim Deegan wrote:
> At 10:35 +0800 on 27 Mar (1427452545), Kai Huang wrote:
> > @@ -233,6 +233,9 @@ static int ept_split_super_page(struct p2m_domain *p2m, 
> > ept_entry_t *ept_entry,
> >       if ( !ept_set_middle_entry(p2m, &new_ept) )
> >           return 0;
> >   
> > +    /* It's better to copy A bit of Middle entry from original entry */
> > +    new_ept.a = ept_entry->a;
> Shouldn't this A bit always be set to 1?  After all we're not using it
> for anything, and it doesn't mean the same thing as the A bit in the
> superpage entry did.
This is the statement in Intel's SDM:

"Whenever the processor uses an EPT paging-structure entry as part of 
guest-physical-address translation, it sets
the accessed flag in that entry (if it is not already set)".

In my understanding, once the guest-physical-address is used by 
processor, all EPT entries used for that translation will have their A 
bits set, from top level entry to leaf entry, therefore A bits of EPT 
entries for one translation should be consistent, in which case looks 
it's reasonable to inherit A bit from superpage's leaf entry to middle 
entry of new shattered 4K pages.
Do I have misunderstanding on this?

But this is really not an important issue, and we can safely set A bit 
of middle entry to 1. It is Yang's idea that it's better to inherit it.
Yang, would you comment here?

> In fact, thinking about that, we should probably be setting _all_ the
> A bits to 1, even in leaf entries, to avoid the overhead of the MMU
> having to write them later.
I suppose you mean A bits of leaf entries of new shattered 4K pages? Yes 
we can, but looks it's more reasonable to inherit according to original 
A bit of super page. But as I said, I don't think A bit matters a lot, 
so I am OK with both. Maybe others can provide some comments here?
Thanks,
-Kai
> Cheers,
>
> Tim.

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