From: Andrew Cooper <andrew.cooper3@citrix.com>
To: dongxiao.xu@intel.com
Cc: xen-devel@lists.xen.org
Subject: Re: [PATCH v2 8/8] x86: enable CQM monitoring for each domain RMID
Date: Thu, 21 Nov 2013 14:19:21 +0000 [thread overview]
Message-ID: <528E1669.5050005@citrix.com> (raw)
In-Reply-To: <1385018444-104477-9-git-send-email-dongxiao.xu@intel.com>
On 21/11/13 07:20, dongxiao.xu@intel.com wrote:
> From: Dongxiao Xu <dongxiao.xu@intel.com>
>
> If the CQM service is attached to a domain, its related RMID will be set
> to hardware for monitoring when the domain's vcpu is scheduled in. When
> the domain's vcpu is scheduled out, RMID 0 (system reserved) will be set
> for monitoring.
>
> Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> ---
> xen/arch/x86/domain.c | 5 +++++
> xen/arch/x86/pqos.c | 21 ++++++++++++++++++++-
> xen/include/asm-x86/msr-index.h | 1 +
> xen/include/asm-x86/pqos.h | 1 +
> 4 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 9725649..1eda0ab 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1372,6 +1372,8 @@ static void __context_switch(void)
> {
> memcpy(&p->arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
> vcpu_save_fpu(p);
> + if ( system_supports_cqm() )
> + cqm_assoc_rmid(0);
So actions from the idle domain are accounted against the previously
scheduled vcpu?
> p->arch.ctxt_switch_from(p);
> }
>
> @@ -1396,6 +1398,9 @@ static void __context_switch(void)
> }
> vcpu_restore_fpu_eager(n);
> n->arch.ctxt_switch_to(n);
> +
> + if ( system_supports_cqm() && n->domain->arch.pqos_cqm_rmid > 0 )
n->domain->arch.pqos_cqm_rmid can only be greater than 0 if the system
already supports cqm()
> + cqm_assoc_rmid(n->domain->arch.pqos_cqm_rmid);
What happens to subsequent Xen accesses before returning to the guest?
What happens for Xen accesses in interrupt handlers?
> }
>
> gdt = !is_pv_32on64_vcpu(n) ? per_cpu(gdt_table, cpu) :
> diff --git a/xen/arch/x86/pqos.c b/xen/arch/x86/pqos.c
> index d95784c..0cec172 100644
> --- a/xen/arch/x86/pqos.c
> +++ b/xen/arch/x86/pqos.c
> @@ -27,6 +27,7 @@
> #include <asm/pqos.h>
>
> static bool_t pqos_enabled = 1;
> +static unsigned int rmid_bitwidth;
> boolean_param("pqos", pqos_enabled);
>
> static void read_qm_data(void *arg)
> @@ -43,6 +44,14 @@ static void get_generic_qm_info(struct qm_element *qm_element)
> on_selected_cpus(cpumask_of(cpu), read_qm_data, qm_element, 1);
> }
>
> +void cqm_assoc_rmid(uint16_t rmid)
> +{
> + uint64_t val;
> + uint64_t rmid_mask = ~(~0ull << rmid_bitwidth);
> + rdmsrl(MSR_IA32_PQR_ASSOC, val);
> + wrmsrl(MSR_IA32_PQR_ASSOC, (val & ~(rmid_mask)) | (rmid & rmid_mask));
> +}
> +
> unsigned int cqm_res_count = 0;
> unsigned int cqm_upscaling_factor = 0;
> bool_t cqm_enabled = 0;
> @@ -78,13 +87,23 @@ static void __init init_cqm(void)
> static void __init init_qos_monitor(void)
> {
> unsigned int qm_features;
> - unsigned int eax, ebx, ecx;
> + unsigned int eax, ebx, ecx, i = 0;
>
> if ( !(boot_cpu_has(X86_FEATURE_QOSM)) )
> return;
>
> cpuid_count(0xf, 0, &eax, &ebx, &ecx, &qm_features);
>
> + while (1)
> + {
> + if ( (1 << i) - 1 >= ebx )
> + {
> + rmid_bitwidth = i;
> + break;
> + }
> + i++;
> + }
Is this some approximation a logarithm ?
Would it not be better to store rmid_mask (which would appear to be ebx)
rather than recalculate it from the constant rmid_bitwidth every time
cqm_assoc_rmid() is called ?
> +
> if ( qm_features & QOS_MONITOR_TYPE_L3 )
> init_cqm();
> }
> diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
> index 46ef165..45f4918 100644
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -491,5 +491,6 @@
> /* Platform QoS register */
> #define MSR_IA32_QOSEVTSEL 0x00000c8d
> #define MSR_IA32_QMC 0x00000c8e
> +#define MSR_IA32_PQR_ASSOC 0x00000c8f
>
> #endif /* __ASM_MSR_INDEX_H */
> diff --git a/xen/include/asm-x86/pqos.h b/xen/include/asm-x86/pqos.h
> index 5c86c5d..2bb983b 100644
> --- a/xen/include/asm-x86/pqos.h
> +++ b/xen/include/asm-x86/pqos.h
> @@ -51,5 +51,6 @@ unsigned int get_cqm_count(void);
> unsigned int get_cqm_avail(void);
> void get_cqm_info(uint32_t rmid, cpumask_t cpu_cqmdata_map,
> struct xen_domctl_getdomcqminfo *info);
> +void cqm_assoc_rmid(uint16_t rmid);
rmid is inconsistently an int, u32 and u16 across this patch series.
Can this be cleaned up.
~Andrew
>
> #endif
next prev parent reply other threads:[~2013-11-21 14:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 7:20 [PATCH v2 0/8] enable Cache QoS Monitoring (CQM) feature dongxiao.xu
2013-11-21 7:20 ` [PATCH v2 1/8] x86: detect and initialize Cache QoS Monitoring feature dongxiao.xu
2013-11-21 12:14 ` Andrew Cooper
2013-11-21 12:19 ` Andrew Cooper
2013-11-25 3:06 ` Xu, Dongxiao
2013-11-25 15:40 ` Andrew Cooper
2013-11-25 8:57 ` Xu, Dongxiao
2013-11-25 15:58 ` Andrew Cooper
2013-11-21 7:20 ` [PATCH v2 2/8] x86: handle CQM resource when creating/destroying guests dongxiao.xu
2013-11-21 12:33 ` Andrew Cooper
2013-11-25 3:21 ` Xu, Dongxiao
2013-11-25 16:02 ` Andrew Cooper
2013-11-21 7:20 ` [PATCH v2 3/8] tools: " dongxiao.xu
2013-11-21 7:20 ` [PATCH v2 4/8] x86: dynamically attach/detach CQM service for a guest dongxiao.xu
2013-11-21 12:50 ` Andrew Cooper
2013-11-25 3:26 ` Xu, Dongxiao
2013-11-25 16:05 ` Andrew Cooper
2013-11-25 21:06 ` Konrad Rzeszutek Wilk
2013-11-21 7:20 ` [PATCH v2 5/8] tools: " dongxiao.xu
2013-11-25 21:00 ` Konrad Rzeszutek Wilk
2013-11-25 21:01 ` Konrad Rzeszutek Wilk
2013-11-21 7:20 ` [PATCH v2 6/8] x86: get per domain CQM information dongxiao.xu
2013-11-21 14:09 ` Andrew Cooper
2013-11-25 6:20 ` Xu, Dongxiao
2013-11-25 16:28 ` Andrew Cooper
2013-11-21 7:20 ` [PATCH v2 7/8] tools: " dongxiao.xu
2013-11-21 7:20 ` [PATCH v2 8/8] x86: enable CQM monitoring for each domain RMID dongxiao.xu
2013-11-21 14:19 ` Andrew Cooper [this message]
2013-11-25 7:22 ` Xu, Dongxiao
2013-11-25 16:32 ` Andrew Cooper
2013-11-21 14:36 ` [PATCH v2 0/8] enable Cache QoS Monitoring (CQM) feature Andrew Cooper
2013-11-25 7:24 ` Xu, Dongxiao
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=528E1669.5050005@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=dongxiao.xu@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).