On Thu, Apr 29, 2021 at 04:53:07PM +0200, Jan Beulich wrote:
> On 20.04.2021 16:07, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/rtc.c
> > +++ b/xen/arch/x86/hvm/rtc.c
> > @@ -46,15 +46,6 @@
> > #define epoch_year 1900
> > #define get_year(x)(x + epoch_year)
> >
> > -enum rtc_mode
On 30.04.2021 17:52, Roger Pau Monne wrote:
> Introduce an interface that returns a specific MSR entry from a cpu
> policy in xen_msr_entry_t format. Provide a helper to perform a binary
> search against an array of MSR entries.
>
> This is useful to callers can peek data from the opaque
> xc_cpu_
On 30.04.2021 17:52, Roger Pau Monne wrote:
> Introduce a helper to obtain a compatible cpu policy based on two
> input cpu policies. Currently this is done by and'ing all CPUID
> feature leaves and MSR entries, except for MSR_ARCH_CAPABILITIES which
> has the RSBA bit or'ed.
>
> The _AC macro is
flight 161609 xen-4.12-testing real [real]
flight 161619 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161609/
http://logs.test-lab.xenproject.org/osstest/logs/161619/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On 30.04.2021 17:52, Roger Pau Monne wrote:
> @@ -1086,3 +1075,42 @@ int xc_cpu_policy_calc_compatible(xc_interface *xch,
>
> return rc;
> }
> +
> +int xc_cpu_policy_make_compatible(xc_interface *xch, xc_cpu_policy_t policy,
> + bool hvm)
I'm concerned of t
On Thu, Apr 22, 2021 at 04:43:39PM +0200, Jan Beulich wrote:
> All of the array allocations in grant_table_init() can exceed a page's
> worth of memory, which xmalloc()-based interfaces aren't really suitable
> for after boot. We also don't need any of these allocations to be
> physically contiguou
On 22/04/2021 15:45, Jan Beulich wrote:
> Instead of (just partially) open-coding it, re-use the function after
> suitably moving it up.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 03.05.2021 11:28, Roger Pau Monné wrote:
> On Thu, Apr 29, 2021 at 04:53:07PM +0200, Jan Beulich wrote:
>> On 20.04.2021 16:07, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/rtc.c
>>> +++ b/xen/arch/x86/hvm/rtc.c
>>> @@ -46,15 +46,6 @@
>>> #define epoch_year 1900
>>> #define get_year(x
flight 161610 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
On 30.04.2021 00:12, Andrew Cooper wrote:
> The sole user of read_pkru() is the emulated pagewalk, and guarded behind
> guest_pku_enabled() which restricts the path to HVM (hap, even) context only.
>
> The commentary in read_pkru() concerning _PAGE_GNTTAB overlapping with
> _PAGE_PKEY_BITS is only
On 03/05/2021 13:42, Jan Beulich wrote:
> On 30.04.2021 00:12, Andrew Cooper wrote:
>> The sole user of read_pkru() is the emulated pagewalk, and guarded behind
>> guest_pku_enabled() which restricts the path to HVM (hap, even) context only.
>>
>> The commentary in read_pkru() concerning _PAGE_GNTT
On Fri, Apr 23, 2021 at 12:16 PM Anthony PERARD
wrote:
>
> The command "cpu-add" for CPU hotplug is deprecated and has been
> removed from QEMU 6.0 (April 2021). We need to add cpus with the
> command "device_add" now.
>
> In order to find out which parameters to pass to "device_add" we first
> ma
On 03.05.2021 13:31, Roger Pau Monné wrote:
> On Thu, Apr 22, 2021 at 04:43:39PM +0200, Jan Beulich wrote:
>> All of the array allocations in grant_table_init() can exceed a page's
>> worth of memory, which xmalloc()-based interfaces aren't really suitable
>> for after boot. We also don't need any
Volodymyr,
On 21.04.2021 16:59, Jan Beulich wrote:
> The current use of xzalloc_bytes() in optee is nearly an open-coded
> version of xzalloc_flex_struct(), which was introduced after the driver
> was merged.
>
> The main difference is xzalloc_bytes() will also force the allocation to
> be SMP_C
On 22/04/2021 15:44, Jan Beulich wrote:
> vCPU-s get maximum size areas allocated initially. Hidden (and in
> particular default-off) features may allow for a smaller size area to
> suffice.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
> ---
> v2: Use 1ul instead of 1ull. Re-base.
On Fri, Apr 23, 2021 at 12:16 PM Anthony PERARD
wrote:
>
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.deprecated-qemu-qmp-and-cmd-v1
>
> The Xen 4.15 release that went out just before QEMU 6.0 won't be compaptible
> with the
On 03.05.2021 15:57, Andrew Cooper wrote:
> On 22/04/2021 15:44, Jan Beulich wrote:
>> vCPU-s get maximum size areas allocated initially. Hidden (and in
>> particular default-off) features may allow for a smaller size area to
>> suffice.
>>
>> Suggested-by: Andrew Cooper
>> Signed-off-by: Jan Beul
On Fri, Apr 23, 2021 at 9:46 PM Robin Murphy wrote:
>
> On 2021-04-22 09:15, Claire Chang wrote:
> > The restricted DMA pool is preferred if available.
> >
> > The restricted DMA pools provide a basic level of protection against the
> > DMA overwriting buffer contents at unexpected times. However,
On 29.04.2021 16:46, Rahul Singh wrote:
> --- /dev/null
> +++ b/xen/drivers/passthrough/msi-intercept.c
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright (C) 2008, Netronome Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and condition
On 29.04.2021 16:46, Rahul Singh wrote:
> MSI code that implements MSI functionality to support MSI within XEN is
> not usable on ARM. Move the code under CONFIG_HAS_PCI_MSI_INTERCEPT flag
> to gate the code for ARM.
>
> Currently, we have no idea how MSI functionality will be supported for
> othe
On Mon, May 03, 2021 at 02:26:51PM +0200, Jan Beulich wrote:
> On 03.05.2021 11:28, Roger Pau Monné wrote:
> > On Thu, Apr 29, 2021 at 04:53:07PM +0200, Jan Beulich wrote:
> >> On 20.04.2021 16:07, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/hvm/rtc.c
> >>> +++ b/xen/arch/x86/hvm/rtc.c
> >>> @@
On Mon, May 03, 2021 at 03:50:48PM +0200, Jan Beulich wrote:
> On 03.05.2021 13:31, Roger Pau Monné wrote:
> > On Thu, Apr 22, 2021 at 04:43:39PM +0200, Jan Beulich wrote:
> >> All of the array allocations in grant_table_init() can exceed a page's
> >> worth of memory, which xmalloc()-based interfa
On 03.05.2021 16:47, Roger Pau Monné wrote:
> On Mon, May 03, 2021 at 02:26:51PM +0200, Jan Beulich wrote:
>> On 03.05.2021 11:28, Roger Pau Monné wrote:
>>> On Thu, Apr 29, 2021 at 04:53:07PM +0200, Jan Beulich wrote:
On 20.04.2021 16:07, Roger Pau Monne wrote:
>> (I've also not seen the
>> f
On 03.05.2021 16:54, Roger Pau Monné wrote:
> On Mon, May 03, 2021 at 03:50:48PM +0200, Jan Beulich wrote:
>> On 03.05.2021 13:31, Roger Pau Monné wrote:
>>> On Thu, Apr 22, 2021 at 04:43:39PM +0200, Jan Beulich wrote:
All of the array allocations in grant_table_init() can exceed a page's
On Mon, May 03, 2021 at 04:58:07PM +0200, Jan Beulich wrote:
> On 03.05.2021 16:47, Roger Pau Monné wrote:
> > On Mon, May 03, 2021 at 02:26:51PM +0200, Jan Beulich wrote:
> >> On 03.05.2021 11:28, Roger Pau Monné wrote:
> >>> On Thu, Apr 29, 2021 at 04:53:07PM +0200, Jan Beulich wrote:
> On 2
XSETBV is an expensive instruction as, amongst other things, it involves
reconfiguring the instruction decode at the frontend of the pipeline.
We have several paths which reconfigure %xcr0 in quick succession (the context
switch path has 5, including the fpu save/restore helpers), and only a singl
If max leaf is greater than 0xd but xsave not available to the guest, then the
current XSAVE size should not be filled in. This is a latent bug for now as
the guest max leaf is 0xd, but will become problematic in the future.
The comment concerning XSS state is wrong. VT-x doesn't manage host/gue
Make use of the new xstate_uncompressed_size() helper rather than maintaining
the running calculation while accumulating feature components.
The rest of the CPUID data can come direct from the raw cpuid policy. All
per-component data forms an ABI through the behaviour of the X{SAVE,RSTOR}*
instru
Various fixes and improvements to xsave image size calculations.
* Skip redundant xcr0 writes
* Don't reconfigure xcr0 to query hardware when we can trivially calculate
the answer ourselves.
* Fix latent bug with CPUID.0xD[0].ebx.
* Rework CPUID.0xD[1].ebx to behave correctly when superviso
The latter is a more descriptive name, as it explicitly highlights the query
from hardware.
Simplify the internal logic using cpuid_count_ebx(), and drop the curr/max
assertion as this property is guaranteed by the x86 ISA.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
C
We're soon going to need a compressed helper of the same form.
The size of the uncompressed image is a strictly a property of the highest
user state. This can be calculated trivially with xstate_offsets/sizes, and
is much faster than a CPUID instruction in the first place, let alone the two
XCR0
According to syslog(3) the fmt string does not need a newline.
The mini-os implementation of syslog requires the trailing newline.
Other calls to syslog do include the newline already, add it also to WRL_LOG.
Signed-off-by: Olaf Hering
---
tools/xenstore/xenstored_domain.c | 6 +++---
1 file cha
On 20.04.2021 16:07, Roger Pau Monne wrote:
> Such callbacks will be executed once a EOI is performed by the guest,
> regardless of whether the interrupts are injected from the vIO-APIC or
> the vPIC, as ISA IRQs are translated to GSIs and then the
> corresponding callback is executed at EOI.
>
>
On 03.05.2021 17:28, Roger Pau Monné wrote:
> On Mon, May 03, 2021 at 04:58:07PM +0200, Jan Beulich wrote:
>> On 03.05.2021 16:47, Roger Pau Monné wrote:
>>> On Mon, May 03, 2021 at 02:26:51PM +0200, Jan Beulich wrote:
On 03.05.2021 11:28, Roger Pau Monné wrote:
> On Thu, Apr 29, 2021 at 0
flight 161625 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161625/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 22/04/2021 15:45, Jan Beulich wrote:
> They're redundant with respective fields from the raw CPUID policy; no
> need to keep two copies of the same data.
So before I read this patch of yours, I had a separate cleanup patch
turning the two arrays into static const.
> This also breaks
> recalcul
On Mon, May 03, 2021 at 05:21:37PM +0200, Jan Beulich wrote:
> On 03.05.2021 16:54, Roger Pau Monné wrote:
> > On Mon, May 03, 2021 at 03:50:48PM +0200, Jan Beulich wrote:
> >> On 03.05.2021 13:31, Roger Pau Monné wrote:
> >>> On Thu, Apr 22, 2021 at 04:43:39PM +0200, Jan Beulich wrote:
> All
flight 161613 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161613/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 161584
test-amd64-amd64-xl-qemut-win7-amd64
On 03/05/2021 16:39, Andrew Cooper wrote:
> We're soon going to need a compressed helper of the same form.
>
> The size of the uncompressed image is a strictly a property of the highest
> user state. This can be calculated trivially with xstate_offsets/sizes, and
> is much faster than a CPUID inst
On Tue, Apr 27 2021 at 07:09, Lai Jiangshan wrote:
> From: Lai Jiangshan
>
> There is no any functionality change intended. Just rename it and
> move it to arch/x86/kernel/nmi.c so that we can resue it later in
> next patch for early NMI and kvm.
'Reuse it later' is not really a proper explanati
For hwp, the standard governors are not usable, and only the internal
one is applicable. Add the cpufreq_governor_internal boolean to
indicate when an internal governor, like hwp-internal, will be used.
This is set during presmp_initcall, so that it can suppress governor
registration during initca
acpi-cpufreq scales the aperf/mperf measurements by max_freq, but HWP
needs to scale by base frequency. Settings max_freq to base_freq
"works" but the code is not obvious, and returning values to userspace
is tricky. Add an additonal perf_freq member which is used for scaling
aperf/mperf measurem
Export feature_detect as intel_feature_detect so it can be re-used by
HWP.
Signed-off-by: Jason Andryuk
---
xen/arch/x86/acpi/cpufreq/cpufreq.c | 4 ++--
xen/include/acpi/cpufreq/processor_perf.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/acpi/cpufr
Hi,
This patch series adds Hardware-Controlled Performance States (HWP) for
Intel processors to Xen.
With HWP, the processor makes its own determinations for frequency
selection depending, though users can set some parameters and
preferences. There is also Turbo Boost which dynamically pushes th
When using HWP, some of the returned data is not applicable. In that
case, we should just omit it to avoid confusing the user. So switch to
printing the base and turbo frequencies since those are relevant to HWP.
Similarly, stop printing the CPU frequencies since those do not apply.
Signed-off-b
>From the Intel SDM: "Hardware-Controlled Performance States (HWP), which
autonomously selects performance states while utilizing OS supplied
performance guidance hints."
Enable HWP to run in autonomous mode by poking the correct MSRs.
There is no interface to configure - it hardcodes the default
Extend xen_get_cpufreq_para to return hwp parameters. These match the
hardware rather closely.
We need the hw_features bitmask to indicated fields supported by the
actual hardware.
The use of uint8_t parameters matches the hardware size. uint32_t
entries grows the sysctl_t past the build assert
Expose the hwp_para fields through libxc.
Signed-off-by: Jason Andryuk
---
tools/include/xenctrl.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 27cec1b93f..82dfa1613a 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl
Print HWP-specific parameters. Some are always present, but others
depend on hardware support.
Signed-off-by: Jason Andryuk
---
tools/misc/xenpm.c | 71 ++
1 file changed, 71 insertions(+)
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 56
Add xc_set_cpufreq_hwp to allow calling xen_systctl_pm_op
SET_CPUFREQ_HWP.
Signed-off-by: Jason Andryuk
---
Am I allowed to do set_hwp = *set_hwp struct assignment?
---
tools/include/xenctrl.h | 4
tools/libs/ctrl/xc_pm.c | 18 ++
2 files changed, 22 insertions(+)
diff --
set-cpufreq-hwp allows setting the Hardware P-State (HWP) parameters.
It can be run on all or just a single cpu. There are presets of
balance, powersave & performance. Those can be further tweaked by
param:val arguments as explained in the usage description.
Parameter names are just checked to
Add SET_CPUFREQ_HWP xen_sysctl_pm_op to set HWP parameters. The sysctl
supports setting multiple values simultaneously as indicated by the
set_params bits. This allows atomically applying new HWP configuration
via a single wrmsr.
XEN_SYSCTL_HWP_SET_PRESET_BALANCE/PERFORMANCE/POWERSAVE provide th
Allow cpuid_prase to be re-used without terminating xenpm. HWP
will re-use it to optionally parse a cpuid.
Signed-off-by: Jason Andryuk
---
tools/misc/xenpm.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 9
Signed-off-by: Jason Andryuk
---
CHANGELOG.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 0106fccec1..bbca67bc0b 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -5,6 +5,8 @@ Notable changes to Xen will be documented in this file.
The format is based on
On Mon, May 03 2021 at 21:05, Thomas Gleixner wrote:
> On Tue, Apr 27 2021 at 07:09, Lai Jiangshan wrote:
>> From: Lai Jiangshan
>>
>> There is no any functionality change intended. Just rename it and
>> move it to arch/x86/kernel/nmi.c so that we can resue it later in
>> next patch for early NM
flight 161616 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
flight 161621 xen-4.12-testing real [real]
flight 161632 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161621/
http://logs.test-lab.xenproject.org/osstest/logs/161632/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 161623 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161623/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 161661 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161661/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 159418
build-amd64
flight 161629 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161629/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8c8f49f0dc86e3c58d94766e6b194b83c1bef5c9
baseline version:
ovmf 1e6b0394d6c001802dc45
60 matches
Mail list logo
