From: Andrew Cooper <andrew.cooper3@citrix.com>
To: dongxiao.xu@intel.com
Cc: keir@xen.org, Ian.Campbell@citrix.com,
stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, JBeulich@suse.com,
dgdegra@tycho.nsa.gov
Subject: Re: [PATCH v3 2/7] x86: handle CQM resource when creating/destroying guests
Date: Fri, 29 Nov 2013 14:18:06 +0000 [thread overview]
Message-ID: <5298A21E.3070603@citrix.com> (raw)
In-Reply-To: <1385704092-89546-3-git-send-email-dongxiao.xu@intel.com>
On 29/11/13 05:48, dongxiao.xu@intel.com wrote:
> From: Dongxiao Xu <dongxiao.xu@intel.com>
>
> Allocate an RMID for a guest when it is created. This per-guest
> RMID will be used to monitor Cache QoS related data. The RMID will
> be relinquished when guest is destroyed.
>
> Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> ---
> xen/arch/x86/domain.c | 8 ++++++
> xen/arch/x86/pqos.c | 55 ++++++++++++++++++++++++++++++++++++++++++
> xen/common/domctl.c | 5 +++-
> xen/include/asm-x86/domain.h | 2 ++
> xen/include/asm-x86/pqos.h | 5 ++++
> xen/include/public/domctl.h | 3 +++
> xen/include/xen/sched.h | 3 +++
> 7 files changed, 80 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index a3868f9..41e1fc6 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -60,6 +60,7 @@
> #include <xen/numa.h>
> #include <xen/iommu.h>
> #include <compat/vcpu.h>
> +#include <asm/pqos.h>
>
> DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
> DEFINE_PER_CPU(unsigned long, cr4);
> @@ -579,6 +580,11 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
> tsc_set_info(d, TSC_MODE_DEFAULT, 0UL, 0, 0);
> spin_lock_init(&d->arch.vtsc_lock);
>
> + /* Allocate CQM RMID for guest */
> + d->arch.pqos_cqm_rmid = 0;
> + if ( system_supports_cqm() && (domcr_flags & DOMCRF_pqos_cqm) )
> + alloc_cqm_rmid(d);
> +
Should we fail domain creation if an rmid cannot be allocated? I really
cant decide which would be better.
In other words, if the toolstack issues a build with DOMCRF_pqos_cqm,
and the build hypercall returns success, should the toolstack reasonably
expect everything to be set up? I would think so.
If others agree wrt this expectation, then domain creation needs to fail
also if "(domcr_flags & DOMCRF_pqos_cqm) && !system_supports_cqm()"
> return 0;
>
> fail:
> @@ -612,6 +618,8 @@ void arch_domain_destroy(struct domain *d)
>
> free_xenheap_page(d->shared_info);
> cleanup_domain_irq_mapping(d);
> +
> + free_cqm_rmid(d);
> }
>
> unsigned long pv_guest_cr4_fixup(const struct vcpu *v, unsigned long guest_cr4)
> diff --git a/xen/arch/x86/pqos.c b/xen/arch/x86/pqos.c
> index e2172c4..1148f3b 100644
> --- a/xen/arch/x86/pqos.c
> +++ b/xen/arch/x86/pqos.c
> @@ -20,6 +20,7 @@
> */
> #include <asm/processor.h>
> #include <xen/init.h>
> +#include <xen/spinlock.h>
> #include <asm/pqos.h>
>
> static bool_t __initdata pqos_enabled = 1;
> @@ -31,6 +32,7 @@ integer_param("cqm_rmid_count", cqm_rmid_count);
> unsigned int cqm_upscaling_factor = 0;
> bool_t cqm_enabled = 0;
> domid_t *cqm_rmid_array = NULL;
> +static DEFINE_SPINLOCK(cqm_lock);
>
> static void __init init_cqm(void)
> {
> @@ -84,6 +86,59 @@ void __init init_platform_qos(void)
> init_qos_monitor();
> }
>
> +bool_t system_supports_cqm(void)
> +{
> + return cqm_enabled;
> +}
> +
> +int alloc_cqm_rmid(struct domain *d)
> +{
> + int rc = 0;
> + unsigned int rmid;
> + unsigned long flags;
> +
> + ASSERT(system_supports_cqm());
> +
> + spin_lock_irqsave(&cqm_lock, flags);
> + /* RMID=0 is reserved, enumerate from 1 */
> + for ( rmid = 1; rmid < cqm_rmid_count; rmid++ )
> + {
> + if ( cqm_rmid_array[rmid] != DOMID_INVALID)
> + continue;
> +
> + cqm_rmid_array[rmid] = d->domain_id;
> + break;
> + }
> + spin_unlock_irqrestore(&cqm_lock, flags);
> +
> + /* No CQM RMID available, assign RMID=0 by default */
> + if ( rmid == cqm_rmid_count )
> + {
> + rmid = 0;
> + rc = -1;
> + }
> +
> + d->arch.pqos_cqm_rmid = rmid;
> +
> + return rc;
> +}
> +
> +void free_cqm_rmid(struct domain *d)
> +{
> + unsigned int rmid = d->arch.pqos_cqm_rmid;
> + unsigned long flags;
> +
> + /* We do not free system reserved "RMID=0" */
> + if ( rmid == 0 )
> + return;
> +
> + spin_lock_irqsave(&cqm_lock, flags);
> + cqm_rmid_array[rmid] = DOMID_INVALID;
> + spin_unlock_irqrestore(&cqm_lock, flags);
Does this need the spinlock? given rmid in the range 1 to max_rmids,
there can't be any competition over who owns the entry, and setting it
back to DOMID_INVALID wont race with the allocation loop.
> +
> + d->arch.pqos_cqm_rmid = 0;
> +}
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 904d27b..1c2e320 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -425,7 +425,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> | XEN_DOMCTL_CDF_pvh_guest
> | XEN_DOMCTL_CDF_hap
> | XEN_DOMCTL_CDF_s3_integrity
> - | XEN_DOMCTL_CDF_oos_off)) )
> + | XEN_DOMCTL_CDF_oos_off
> + | XEN_DOMCTL_CDF_pqos_cqm)) )
If you move the final bracket onto a new line now, future additions will
be a single line addition rather than one removal and two additions.
I am not sure what the prerogative is with that in terms of the Xen
coding style.
~Andrew
> break;
>
> dom = op->domain;
> @@ -467,6 +468,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> domcr_flags |= DOMCRF_s3_integrity;
> if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
> domcr_flags |= DOMCRF_oos_off;
> + if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_pqos_cqm )
> + domcr_flags |= DOMCRF_pqos_cqm;
>
> d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
> if ( IS_ERR(d) )
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 9d39061..9487251 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -313,6 +313,8 @@ struct arch_domain
> spinlock_t e820_lock;
> struct e820entry *e820;
> unsigned int nr_e820;
> +
> + unsigned int pqos_cqm_rmid; /* CQM RMID assigned to the domain */
> } __cacheline_aligned;
>
> #define has_arch_pdevs(d) (!list_empty(&(d)->arch.pdev_list))
> diff --git a/xen/include/asm-x86/pqos.h b/xen/include/asm-x86/pqos.h
> index e8caca2..c54905b 100644
> --- a/xen/include/asm-x86/pqos.h
> +++ b/xen/include/asm-x86/pqos.h
> @@ -20,6 +20,7 @@
> */
> #ifndef ASM_PQOS_H
> #define ASM_PQOS_H
> +#include <xen/sched.h>
>
> /* QoS Resource Type Enumeration */
> #define QOS_MONITOR_TYPE_L3 0x2
> @@ -29,4 +30,8 @@
>
> void init_platform_qos(void);
>
> +bool_t system_supports_cqm(void);
> +int alloc_cqm_rmid(struct domain *d);
> +void free_cqm_rmid(struct domain *d);
> +
> #endif
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 01a3652..47a850a 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -62,6 +62,9 @@ struct xen_domctl_createdomain {
> /* Is this a PVH guest (as opposed to an HVM or PV guest)? */
> #define _XEN_DOMCTL_CDF_pvh_guest 4
> #define XEN_DOMCTL_CDF_pvh_guest (1U<<_XEN_DOMCTL_CDF_pvh_guest)
> + /* Enable pqos-cqm? */
> +#define _XEN_DOMCTL_CDF_pqos_cqm 5
> +#define XEN_DOMCTL_CDF_pqos_cqm (1U<<_XEN_DOMCTL_CDF_pqos_cqm)
> uint32_t flags;
> };
> typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index cbdf377..3a42656 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -507,6 +507,9 @@ struct domain *domain_create(
> /* DOMCRF_pvh: Create PV domain in HVM container. */
> #define _DOMCRF_pvh 5
> #define DOMCRF_pvh (1U<<_DOMCRF_pvh)
> + /* DOMCRF_pqos_cqm: Create a domain with CQM support */
> +#define _DOMCRF_pqos_cqm 6
> +#define DOMCRF_pqos_cqm (1U<<_DOMCRF_pqos_cqm)
>
> /*
> * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
next prev parent reply other threads:[~2013-11-29 14:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-29 5:48 [PATCH v3 0/7] enable Cache QoS Monitoring (CQM) feature dongxiao.xu
2013-11-29 5:48 ` [PATCH v3 1/7] x86: detect and initialize Cache QoS Monitoring feature dongxiao.xu
2013-11-29 13:54 ` Andrew Cooper
2013-11-29 15:05 ` Jan Beulich
2013-11-30 0:41 ` Xu, Dongxiao
2013-12-02 2:17 ` Xu, Dongxiao
2013-12-02 9:22 ` Xu, Dongxiao
2013-11-29 13:59 ` Andrew Cooper
2013-11-30 0:42 ` Xu, Dongxiao
2013-11-29 5:48 ` [PATCH v3 2/7] x86: handle CQM resource when creating/destroying guests dongxiao.xu
2013-11-29 14:18 ` Andrew Cooper [this message]
2013-11-29 15:01 ` Andrew Cooper
2013-11-29 15:07 ` Jan Beulich
2013-11-29 5:48 ` [PATCH v3 3/7] x86: dynamically attach/detach CQM service for a guest dongxiao.xu
2013-11-29 14:22 ` Andrew Cooper
2013-11-29 5:48 ` [PATCH v3 4/7] x86: collect CQM information from all sockets dongxiao.xu
2013-11-29 14:53 ` Andrew Cooper
2013-11-30 1:27 ` Xu, Dongxiao
2013-11-29 5:48 ` [PATCH v3 5/7] x86: enable CQM monitoring for each domain RMID dongxiao.xu
2013-11-29 14:56 ` Andrew Cooper
2013-11-30 1:27 ` Xu, Dongxiao
2013-11-29 5:48 ` [PATCH v3 6/7] xsm: add platform QoS related xsm policies dongxiao.xu
2013-11-29 15:50 ` Daniel De Graaf
2013-11-29 5:48 ` [PATCH v3 7/7] tools: enable Cache QoS Monitoring feature for libxl/libxc dongxiao.xu
2013-11-29 15:29 ` [PATCH v3 0/7] enable Cache QoS Monitoring (CQM) feature Ian Campbell
2013-11-29 15:36 ` Jan Beulich
2013-11-29 15:41 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5298A21E.3070603@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=dongxiao.xu@intel.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.