Re: [PATCH RFC v2 04/12] xen/mem_event: Abstract architecture specific sanity checks

[Tamas K Lengyel <tamas.lengyel@zentific.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1651 bytes --]

On Thu, Aug 28, 2014 at 8:38 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 27.08.14 at 23:54, <tamas.lengyel@zentific.com> wrote:
> >>  On Wed, Aug 27, 2014 at 5:19 PM, Jan Beulich <JBeulich@suse.com>
> wrote:
> >>
> >>> >>> On 27.08.14 at 16:06, <tklengyel@sec.in.tum.de> wrote:
> >>> > --- a/xen/common/mem_event.c
> >>> > +++ b/xen/common/mem_event.c
> >>> > @@ -424,6 +424,19 @@ int __mem_event_claim_slot(struct domain *d,
> >>> struct mem_event_domain *med,
> >>> >          return mem_event_grab_slot(med, (current->domain != d));
> >>> >  }
> >>> >
> >>> > +static inline bool_t mem_event_sanity_check(struct domain *d)
> >>> > +{
> >>> > +    /* Only HAP is supported */
> >>> > +    if ( !hap_enabled(d) )
> >>> > +        return 0;
> >>> > +
> >>> > +    /* Currently only EPT is supported */
> >>> > +    if ( !cpu_has_vmx )
> >>> > +        return 0;
> >>> > +
> >>> > +    return 1;
> >>> > +}
> >>>
> >>> So what does it buy us to have this in a separate function, but
> >>> still in the same common file?
> >>>
> >>
> >> This patch really just sets up the ground for ARM where these checks are
> >> not required and will just return 1.
> >>
> >
> > In the next series I'll actually relocate this function into architecture
> > specific p2m.h and rename it p2m_mem_event_sanity_check. Same for the
> > mem_access sanity check function.
>
> Sounds like suboptimal patch splitting then...
>
> Jan
>

Suboptimal in what sense? From a performance perspective it has no impact
as it is static inline. I could add the ARM side here as well, but the
compilation of this code is not turned on for ARM until the end of the
series.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 2715 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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