The added calculation related functions will be used in the intel_pstate.c.
Signed-off-by: Wei Wang
---
xen/include/asm-x86/div64.h | 68 +
xen/include/xen/kernel.h| 30
2 files changed, 98 insertions(+)
diff --git a/xen/inclu
In order to better support future Intel processors, intel_pstate
changes to use percentage values to tune P-states. The intel_pstate
driver uses its own internal governor, and it is recorded in the
"policy->policy" field. The setpolicy driver interface is used to
configure the intel_pstate internal
The intel_pstate driver is ported following its kernel code logic
(commit: 93f0822d).
In the kernel, a user can adjust the limits via sysfs
(limits.min_sysfs_pct/max_sysfs_pct). In Xen, the
policy->min_perf_pct/max_perf_pct acts as the transit station.
A user interacts with it via xenpm.
Signed-o
On 23/04/15 14:43, David Vrabel wrote:
> On 23/04/15 13:03, Tim Deegan wrote:
>> Hi,
>>
>> At 11:11 +0100 on 21 Apr (1429614687), David Vrabel wrote:
>>> void _spin_lock(spinlock_t *lock)
>>> {
>>> +spinlock_tickets_t tickets = { .tail = 1, };
>>> LOCK_PROFILE_VAR;
>>>
>>> check_l
By default, the intel_pstate driver is loaded.a If
"intel_pstate=disable" is added to the Xen booting param list,
the old pstate driver will be loaded.
Signed-off-by: Wei Wang
---
xen/arch/x86/acpi/cpufreq/cpufreq.c | 9 ++---
xen/arch/x86/acpi/cpufreq/intel_pstate.c | 16 +++
Add support in the pmstat.c so that the xenpm tool can request to
access the intel_pstate driver.
Signed-off-by: Wei Wang
---
tools/libxc/xc_pm.c | 8 +++
xen/drivers/acpi/pmstat.c | 57 +++--
xen/include/public/sysctl.h | 22 ++-
The unregister notifier function is needed to support cpu hotplug.
Signed-off-by: Wei Wang
---
xen/common/cpu.c | 7 +++
xen/include/xen/cpu.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 47e8b5b..508cee5 100644
--- a/xen/common/cpu.c
+
The intel_pstate driver receives percentage values to set the
performance limits. This patch adds interfaces to support the
input of percentage values to control the intel_pstate driver.
Also, the "get-cpufreq-para" is modified to show percentage
based feedback info.
Signed-off-by: Wei Wang
---
>>> On 23.04.15 at 14:32, wrote:
> On 2015/4/16 23:40, Tim Deegan wrote:
>> At 17:21 +0800 on 10 Apr (1428686518), Tiejun Chen wrote:
>>> @@ -1851,7 +1857,14 @@ static int rmrr_identity_mapping(struct domain *d,
>>> bool_t map,
>>> if ( !is_hardware_domain(d) )
>>> {
>>>
On Thu, Apr 23, 2015 at 10:24:04AM +0100, Andrew Cooper wrote:
> On 23/04/15 03:49, Boris Ostrovsky wrote:
> > When resuming, the guest needs to check whether the port has changed. HVM
> > guests use this parameter to get the port number.
> >
> > (We can't always use xenstore where this value is al
>>> On 23.04.16 at 15:31, wrote:
> The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all
> the logic for selecting the current P-state. It follows its
> implementation in the kernel. Instead of using the traditional cpufreq
> governors, intel_pstate implements its internal govern
At 14:43 +0100 on 23 Apr (1429800229), David Vrabel wrote:
> On 23/04/15 13:03, Tim Deegan wrote:
> > Hi,
> >
> > At 11:11 +0100 on 21 Apr (1429614687), David Vrabel wrote:
> >> void _spin_lock(spinlock_t *lock)
> >> {
> >> +spinlock_tickets_t tickets = { .tail = 1, };
> >> LOCK_PROFILE
At 14:59 +0100 on 23 Apr (1429801184), Jan Beulich wrote:
> >>> On 23.04.15 at 14:32, wrote:
> > On 2015/4/16 23:40, Tim Deegan wrote:
> >> At 17:21 +0800 on 10 Apr (1428686518), Tiejun Chen wrote:
> >>> @@ -1851,7 +1857,14 @@ static int rmrr_identity_mapping(struct domain *d,
> >>> bool_t map,
>
On Thu, 23 Apr 2015, Jan Beulich wrote:
> Stefano,
>
> while I'm not really convinced of the change, commit 14655e9a18
> ("glib-compat: fix problems with not-quite glib 2.22") at least helps
> with building on SLE11 SP3. My concern is that the fallback seems
> worse than using the backported inter
At 14:54 +0100 on 23 Apr (1429800874), Jan Beulich wrote:
> >>> On 23.04.15 at 14:03, wrote:
> > At 11:11 +0100 on 21 Apr (1429614687), David Vrabel wrote:
> >> void _spin_unlock(spinlock_t *lock)
> >> {
> >> +smp_mb();
> >> preempt_enable();
> >> LOCK_PROFILE_REL;
> >> -_raw_s
On Wed, Apr 22, 2015 at 10:49:18PM -0400, Boris Ostrovsky wrote:
> When resuming, the guest needs to check whether the port has changed. HVM
> guests use this parameter to get the port number.
>
> (We can't always use xenstore where this value is also written: for example
> on Linux the console is
At 15:24 +0100 on 23 Apr (1429802696), Tim Deegan wrote:
> At 14:43 +0100 on 23 Apr (1429800229), David Vrabel wrote:
> > On 23/04/15 13:03, Tim Deegan wrote:
> > > Hi,
> > >
> > > At 11:11 +0100 on 21 Apr (1429614687), David Vrabel wrote:
> > >> void _spin_lock(spinlock_t *lock)
> > >> {
> > >>
>>> On 23.04.15 at 16:13, wrote:
> On Thu, 23 Apr 2015, Jan Beulich wrote:
>> while I'm not really convinced of the change, commit 14655e9a18
>> ("glib-compat: fix problems with not-quite glib 2.22") at least helps
>> with building on SLE11 SP3. My concern is that the fallback seems
>> worse than
At 14:45 +0100 on 23 Apr (1429800338), Andrew Cooper wrote:
> On 23/04/15 14:43, David Vrabel wrote:
> > On 23/04/15 13:03, Tim Deegan wrote:
> >> Hi,
> >>
> >> At 11:11 +0100 on 21 Apr (1429614687), David Vrabel wrote:
> >>> void _spin_lock(spinlock_t *lock)
> >>> {
> >>> +spinlock_tickets_t
>>> On 23.04.15 at 16:43, wrote:
> At 14:54 +0100 on 23 Apr (1429800874), Jan Beulich wrote:
>> >>> On 23.04.15 at 14:03, wrote:
>> > At 11:11 +0100 on 21 Apr (1429614687), David Vrabel wrote:
>> >> void _spin_unlock(spinlock_t *lock)
>> >> {
>> >> +smp_mb();
>> >> preempt_enable();
>>
>>> On 22.04.15 at 18:00, wrote:
> Subsequent changes make both these locks uncontented. Is this patch
> really necessary? -- dvrabel
Yeah, particularly if this ...
> @@ -540,6 +550,16 @@ static void mapcount(
>
> *wrc = *rdc = 0;
>
> +/*
> + * While taking the local maptrack
>>> On 22.04.15 at 18:00, wrote:
> This is safe because: a) the grant table version only changes once
> from 0 to 1 or 2;
gnttab_set_version() also allows it to transition between 1 and 2
afaics.
> @@ -919,18 +914,15 @@ __gnttab_unmap_common(
> }
>
> op->map = &maptrack_entry(lgt, op
Hi Jan,
2015-04-23 4:14 GMT-04:00 Jan Beulich :
>
> >>> On 23.04.15 at 06:03, wrote:
> > The first question is:
> > Why should we use "foreigndom >> 16" instead of "foreigndom" to get the
> > pt_dom?
>
> Because there are possibly three domains involved here: The current
> one (issuing the hyperc
>>> On 22.04.15 at 18:00, wrote:
> static inline int
> get_maptrack_handle(
> struct grant_table *lgt)
> {
> +struct vcpu *v = current;
> int i;
> grant_handle_thandle;
> struct grant_mapping *new_mt;
> unsigned int new_mt
>>> On 23.04.15 at 17:54, wrote:
> Right now, `xen-hptool mem-offline ` does not take the ,
> to which the belongs. I think this tool should take the
> as an extra parameter just as `xen-mfndump lookup-pte `
> does. When the tool construct the foreigndom for mmu, it should make
> the foreigndom
On 23/04/15 17:11, Jan Beulich wrote:
On 22.04.15 at 18:00, wrote:
>>
>> +v->maptrack_head = lgt->maptrack_pages * MAPTRACK_PER_PAGE;
>> +if (v->maptrack_tail == MAPTRACK_TAIL)
>> +{
>> +v->maptrack_tail = (lgt->maptrack_pages * MAPTRACK_PER_PAGE)
>> ++ MAPTR
Due to the Hackathon next week, our normal April Document Day is
taking a one week bump to May 6. If anyone objects to this date,
please let me know. Otherwise, we'll allow those attending the
Hackathon to participate in Document Day upon their return.
All the information you need to participate
On Wed, 2015-03-25 at 23:48 -1000, Justin T. Weaver wrote:
> Move affinity balancing related functions and defines from sched_credit.c to
> sched-if.h so other schedulers can use them. Change name prefixes from csched
> to sched since they are no longer specific to the credit scheduler.
>
It's pro
On Wed, 2015-03-25 at 23:48 -1000, Justin T. Weaver wrote:
> Functions runq_tickle and choose_cpu both have code sections that get turned
> into loops in patch 4 v3, soft affinity. Do the indenting here to make the
> patch 4 diff section easier to read.
>
Yeah, I know what you mean, an thanks for
The following two patches fix a bug in the ioreq server gmfn release
code and also make the semantics of server destruction more intuitive.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
hvm_free_ioreq_gmfn has the sense of the ioreq_gmfn mask inverted; it
needs to set a bit to release the gmfn, not clear it.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Currently, unless a (non-default) ioreq server is explicitly disabled before
being destroyed, its gmfns will not be placed back into the p2m but still
released back into the ioreq_gmfn mask. This is somewhat counter-intuitive
and easily remedied by this small patch.
Signed-off-by: Paul Durrant
Cc
On 23/04/15 16:46, Paul Durrant wrote:
> hvm_free_ioreq_gmfn has the sense of the ioreq_gmfn mask inverted; it
> needs to set a bit to release the gmfn, not clear it.
>
> Signed-off-by: Paul Durrant
> Cc: Keir Fraser
> Cc: Jan Beulich
> Cc: Andrew Cooper
s/mask/free_mask/ ?
For the change its
On 23/04/15 16:46, Paul Durrant wrote:
> Currently, unless a (non-default) ioreq server is explicitly disabled before
> being destroyed, its gmfns will not be placed back into the p2m but still
> released back into the ioreq_gmfn mask. This is somewhat counter-intuitive
> and easily remedied by thi
On Tue, 2015-03-31 at 15:37 +0100, George Dunlap wrote:
> On 03/26/2015 09:48 AM, Justin T. Weaver wrote:
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @@ -194,6 +195,12 @@ int opt_overload_balance_tolerance=-3;
> > integer_param("credit2_balance_over", opt_overlo
On 4/23/15, 08:47, "Jan Beulich" wrote:
On 23.04.15 at 15:31, wrote:
>
>>
>> On 4/17/15, 10:27, "Jan Beulich" wrote:
>>
>>>1aeb1156fa ("x86 don't change affinity with interrupt unmasked")
>>>introducing RTE reads prior to the respective interrupt having got
>>>enabled for the first tim
> On 4/23/15, 08:47, "Jan Beulich" wrote:
> On 23.04.15 at 15:31, wrote:
>>
>>>
>>> On 4/17/15, 10:27, "Jan Beulich" wrote:
>>>
1aeb1156fa ("x86 don't change affinity with interrupt unmasked")
introducing RTE reads prior to the respective interrupt having got
enabled for the
On Thu, Apr 23, 2015 at 05:51:05PM +, Suthikulpanit, Suravee wrote:
>
>
> On 4/23/15, 08:47, "Jan Beulich" wrote:
>
> On 23.04.15 at 15:31, wrote:
> >
> >>
> >> On 4/17/15, 10:27, "Jan Beulich" wrote:
> >>
> >>>1aeb1156fa ("x86 don't change affinity with interrupt unmasked")
> >>>i
Hi Dario,
2015-04-23 8:48 GMT-04:00 Dario Faggioli :
> Hey, guys,
>
> I know, I know, I'm s much late to the party! Sorry, I got trapped
> into a thing that I really needed to finish... :-/
>
> I've got no intention to resurrect this old thread, just wanted to
> pointed out a few things.
What
On 4/23/15, 12:59, "Sander Eikelenboom" wrote:
>
>> On 4/23/15, 08:47, "Jan Beulich" wrote:
>
>> On 23.04.15 at 15:31, wrote:
>>>
On 4/17/15, 10:27, "Jan Beulich" wrote:
>1aeb1156fa ("x86 don't change affinity with interrupt unmasked")
>introducing RTE reads prio
On 4/23/15, 13:06, "Konrad Rzeszutek Wilk" wrote:
>>I have tested this patch w/ staging branch booting Dom0, and this patch
>>got rid of the following error from xl dmesg:
>>(XEN) APIC error on CPU0: 00(40)
>>(XEN) APIC error on CPU2: 00(40)
>>However, when I tried starting a guest w/ PCI devic
On 4/23/15, 04:25, "Tim Deegan" wrote:
>At 17:44 +0100 on 16 Apr (1429206250), Tim Deegan wrote:
>> update_intremap_entry_from_msi() doesn't write to its data pointer on
>> some error paths, so we copying that variable into the msg would count
>> as undefined behaviour.
>>
>> Signed-off-by: Tim
On 04/21/2015 03:01 AM, Jan Beulich wrote:
+ ((++dev_cnt > 0x3f) && hypercall_preempt_check()) )
+break;
+}
+
+if ( (!ret || (ret == -ENODEV)) &&
+ __copy_field_to_guest(u_sysctl, op, u.pcitopoinfo.first_dev) )
+ret = -EFAU
On 2015/4/23 20:59, Jan Beulich wrote:
On 23.04.15 at 14:32, wrote:
But if you already have one just please ignore this and tell me
Here's what I currently have:
Could you resend me this as an attached file? Then I can apply that
properly without any miss?
Thanks
Tiejun
introduce XENM
On 23/04/2015 22:09, Jan Beulich wrote:
> >>> On 23.04.16 at 15:31, wrote:
> > The intel_pstate.c file under xen/arch/x86/acpi/cpufreq/ contains all
> > the logic for selecting the current P-state. It follows its
> > implementation in the kernel. Instead of using the traditional cpufreq
> > govern
On Thu, 2015-04-23 at 12:05 +0100, Ian Jackson wrote:
> Pang, LongtaoX writes ("RE: [Xen-devel] [OSSTEST Nested PATCH v8 6/7] Compose
> the main recipe of nested test job"):
> > Ian Campbell [mailto:ian.campb...@citrix.com]:
> > > The arguments passed to ts-* in sg-run-job should _always_ be just
On 04/17/2015 03:37 PM, Jan Beulich wrote:
On 17.04.15 at 09:23, wrote:
On 04/17/2015 02:58 PM, Jan Beulich wrote:
On 17.04.15 at 08:51, wrote:
On 04/17/2015 02:23 PM, Jan Beulich wrote:
On 17.04.15 at 05:10, wrote:
On 04/16/2015 11:42 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, wrot
>>> On 23.04.15 at 18:29, wrote:
> On 23/04/15 17:11, Jan Beulich wrote:
> On 22.04.15 at 18:00, wrote:
>>> -return handle;
>>> +v->maptrack_limit = new_mt_limit;
>>> +
>>> +return __get_maptrack_handle(lgt, v);
>>
>> With the lock dropped, nothing guarantees this to succeed, whi
101 - 148 of 148 matches
Mail list logo
