On 06.03.2021 22:41, Julien Grall wrote:
> From: Julien Grall
>
> Compilers older than 4.8 have known codegen issues which can lead to
> silent miscompilation:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145
>
> Furthermore, pre-4.9 GCC have known bugs (including things like
> internal c
On 08.03.2021 08:00, Igor Druzhinin wrote:
> BIOS might pass control to Xen leaving QI and/or IR in enabled and/or
> partially configured state. In case of x2APIC code path where EIM is
> enabled early in boot - those are correctly disabled by Xen before any
> attempt to configure. But for xAPIC th
flight 159860 qemu-mainline real [real]
flight 159867 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159860/
http://logs.test-lab.xenproject.org/osstest/logs/159867/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Fri, Mar 05, 2021 at 10:50:34AM +0100, Jan Beulich wrote:
> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
> handler early enough to cover for example the rdmsrl_safe() of
> MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of the unguarded read
> of MSR_K7_HWCR later in the
While the first change is a possible 4.15 candidate, the second is pure
cleanup (but could, should patch 1 end up being controversial, also be
re-based ahead).
1: don't rebuild cpuid-autogen.h every time
2: move arch-specific include/xen/ population into arch-specific rule
Jan
The first thing the "xen-dir" rule does is delete the entire xen/
subtree. Obviously this includes deleting xen/lib/x86/*autogen.h. As a
result there's no original version for $(move-if-changed ...) to compare
against, and hence the file and all its consumers would get rebuilt
every time. Introduce
There's no need for the common "xen-dir" rule to have an arch-specific
part when there already is a arch-specific rule where this can be taken
care of.
Signed-off-by: Jan Beulich
---
I was tempted to also uniformly change the pattern from *autogen.h to
*-autogen.h right here - thoughts?
I was al
At 16:37 +0100 on 05 Mar (1614962224), Jan Beulich wrote:
> We can't make correctness of our own behavior dependent upon a
> hypervisor underneath us correctly telling us the true physical address
> with hardware uses. Without knowing this, we can't be certain reserved
> bit faults can actually be
On 08.03.2021 09:56, Roger Pau Monné wrote:
> On Fri, Mar 05, 2021 at 10:50:34AM +0100, Jan Beulich wrote:
>> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
>> handler early enough to cover for example the rdmsrl_safe() of
>> MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of
At 16:37 +0100 on 05 Mar (1614962265), Jan Beulich wrote:
> Since we don't need to encode all of the PTE flags, we have enough bits
> in the shadow entry to store the full GFN. Don't use literal numbers -
> instead derive the involved values. Or, where derivation would become
> too ugly, sanity-che
On 08.03.2021 10:25, Tim Deegan wrote:
> At 16:37 +0100 on 05 Mar (1614962224), Jan Beulich wrote:
>> We can't make correctness of our own behavior dependent upon a
>> hypervisor underneath us correctly telling us the true physical address
>> with hardware uses. Without knowing this, we can't be ce
Julien Grall writes ("Re: [PATCH for-4.15 2/2] tools/xenstore: Check the format
printf for xprintf() and barf{,_perror}()"):
> Would the following comment work for you?
>
> /* Function pointer as xprintf() can be configured at runtime. */
>
> I can fold it in my patch while committing.
Sure, th
flight 159861 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159861/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
All,
the release is overdue (my apologies). Please point out backports
you find missing from the respective staging branches, but which
you consider relevant.
Ones that I have queued already, but which hadn't passed the push
gate to master yet when doing a swipe late last week, are
c6ad5a701b9a
Julien Grall writes ("[PATCH for-4.15] xen: Bump the minimum version of GCC
supported to 4.9 (5.1 on arm64)"):
> From: Julien Grall
>
> Compilers older than 4.8 have known codegen issues which can lead to
> silent miscompilation:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145
>
> Furth
Currently in order to link existing DTB into Xen image
we need to either specify option CONFIG_DTB_FILE on the
command line or manually add it into .config.
Add Kconfig entries: CONFIG_LINK_DTB and CONFIG_DTB_FILE
to be able to select this option and provide the path to
DTB we want to embed into Xe
Jan Beulich writes ("[PATCH 1/2][4.15?] tools/x86: don't rebuild
cpuid-autogen.h every time"):
> The first thing the "xen-dir" rule does is delete the entire xen/
> subtree. Obviously this includes deleting xen/lib/x86/*autogen.h. As a
> result there's no original version for $(move-if-changed ...
On 08.03.2021 10:52, Michal Orzel wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -400,6 +400,20 @@ config DOM0_MEM
>
> Leave empty if you are not sure what to specify.
>
> +config LINK_DTB
> + bool "Link DTB into Xen image"
> + depends on ARM
> + default n
Jan Beulich writes ("[PATCH 2/2] tools/x86: move arch-specific include/xen/
population into arch-specific rule"):
> There's no need for the common "xen-dir" rule to have an arch-specific
> part when there already is a arch-specific rule where this can be taken
> care of.
I think the symlinks bein
On 08.03.2021 11:00, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH 2/2] tools/x86: move arch-specific include/xen/
> population into arch-specific rule"):
>> There's no need for the common "xen-dir" rule to have an arch-specific
>> part when there already is a arch-specific rule where this can
On 08.03.2021 10:59, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH 1/2][4.15?] tools/x86: don't rebuild
> cpuid-autogen.h every time"):
>> The first thing the "xen-dir" rule does is delete the entire xen/
>> subtree. Obviously this includes deleting xen/lib/x86/*autogen.h. As a
>> result there'
On 08/03/2021 08:09, Jan Beulich wrote:
On 06.03.2021 22:41, Julien Grall wrote:
From: Julien Grall
Compilers older than 4.8 have known codegen issues which can lead to
silent miscompilation:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145
Furthermore, pre-4.9 GCC have known bugs (incl
Hi Jan,
On 08.03.2021 11:00, Jan Beulich wrote:
> On 08.03.2021 10:52, Michal Orzel wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -400,6 +400,20 @@ config DOM0_MEM
>>
>>Leave empty if you are not sure what to specify.
>>
>> +config LINK_DTB
>> +bool "Link DTB
Jan Beulich writes ("Re: [PATCH 1/2][4.15?] tools/x86: don't rebuild
cpuid-autogen.h every time"):
> On 08.03.2021 10:59, Ian Jackson wrote:
> > Jan Beulich writes ("[PATCH 1/2][4.15?] tools/x86: don't rebuild
> > cpuid-autogen.h every time"):
> >> +# Arrange for preserving of auto-generated head
On 08.03.2021 11:51, Julien Grall wrote:
> On 08/03/2021 08:09, Jan Beulich wrote:
>> On 06.03.2021 22:41, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> Compilers older than 4.8 have known codegen issues which can lead to
>>> silent miscompilation:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bu
On 08.03.2021 12:02, Michal Orzel wrote:
> On 08.03.2021 11:00, Jan Beulich wrote:
>> On 08.03.2021 10:52, Michal Orzel wrote:
>>> +config DTB_FILE
>>> + string "Absolute path to device tree blob"
>>> + default ""
>>> + depends on LINK_DTB
>>> + ---help---
>>> + When using a bootloader
This patch prevents the dom0 to be loaded skipping its
building and going forward to build domUs when the dom0
kernel is not found and at least one domU is present.
Signed-off-by: Luca Fancellu
Change-Id: Ieb9630b80cc7be7688d7d5fff3f839958f142ac0
---
xen/arch/arm/setup.c | 83 +++
This patch prevents the dom0 to be loaded skipping its
building and going forward to build domUs when the dom0
kernel is not found and at least one domU is present.
Signed-off-by: Luca Fancellu
Change-Id: Ieb9630b80cc7be7688d7d5fff3f839958f142ac0
---
xen/arch/arm/setup.c | 83 +++
On 08.03.2021 12:08, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 1/2][4.15?] tools/x86: don't rebuild
> cpuid-autogen.h every time"):
>> On 08.03.2021 10:59, Ian Jackson wrote:
>>> Jan Beulich writes ("[PATCH 1/2][4.15?] tools/x86: don't rebuild
>>> cpuid-autogen.h every time"):
+#
On Fri, Mar 05, 2021 at 10:50:54AM +0100, Jan Beulich wrote:
> Linux has been warning ("firmware bug") about this bit being clear for a
> long time. While writable in older hardware it has been readonly on more
> than just most recent hardware. For simplicitly report it always set (if
> anything we
On 08.03.2021 12:37, Roger Pau Monné wrote:
> On Fri, Mar 05, 2021 at 10:50:54AM +0100, Jan Beulich wrote:
>> Linux has been warning ("firmware bug") about this bit being clear for a
>> long time. While writable in older hardware it has been readonly on more
>> than just most recent hardware. For s
This patch prevents the dom0 to be loaded skipping its
building and going forward to build domUs when the dom0
kernel is not found and at least one domU is present.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/setup.c | 83 +++-
1 file changed, 59 inserti
Hi Luca,
On 08/03/2021 11:56, Luca Fancellu wrote:
This patch prevents the dom0 to be loaded skipping its
building and going forward to build domUs when the dom0
kernel is not found and at least one domU is present.
Signed-off-by: Luca Fancellu
I have received 3 versions of this patch, can yo
flight 159871 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159871/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 08.03.2021 10:39, Tim Deegan wrote:
> At 16:37 +0100 on 05 Mar (1614962265), Jan Beulich wrote:
>> Since we don't need to encode all of the PTE flags, we have enough bits
>> in the shadow entry to store the full GFN. Don't use literal numbers -
>> instead derive the involved values. Or, where de
On Mon, Mar 08, 2021 at 10:33:12AM +0100, Jan Beulich wrote:
> On 08.03.2021 09:56, Roger Pau Monné wrote:
> > On Fri, Mar 05, 2021 at 10:50:34AM +0100, Jan Beulich wrote:
> >> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
> >> handler early enough to cover for example the rdm
Jan Beulich writes ("Re: [PATCH 1/2][4.15?] tools/x86: don't rebuild
cpuid-autogen.h every time"):
> Possibly, but it may end up being more complex: We want to only
> retain files of specific names from a single dir. I don't think
> this is as straightforward to express in a find rune. Of course
>
> On 8 Mar 2021, at 11:59, Julien Grall wrote:
>
> Hi Luca,
>
> On 08/03/2021 11:56, Luca Fancellu wrote:
>> This patch prevents the dom0 to be loaded skipping its
>> building and going forward to build domUs when the dom0
>> kernel is not found and at least one domU is present.
>> Signed-off
Add ALTERNATIVE_TERNARY support for replacing an initial instruction
with either of two instructions depending on a feature:
ALTERNATIVE_TERNARY "default_instr", FEATURE_NR,
"feature_on_instr", "feature_off_instr"
which will start with "default_instr" and at patch time wil
The macro ALTINSTR_REPLACEMENT() doesn't make use of the feature
parameter, so drop it.
Signed-off-by: Juergen Gross
---
V5:
- new patch
---
arch/x86/include/asm/alternative.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/alternative.h
b
Having the definition of static_call() in static_call_types.h makes
no sense as long struct static_call_key isn't defined there, as the
generic implementation of static_call() is referencing this structure.
So move the definition of struct static_call_key to static_call_types.h.
Signed-off-by: Ju
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this allows quite some simplification of the pvops implementation.
Signed-off-by: Juergen Gross
---
V4:
- drop p
Add support for alternative patching for the case a feature is not
present on the current cpu.
For this purpose add a flag byte to struct alt_instr adding the
information that the inverted feature should be used.
For users of ALTERNATIVE() and friends an inverted feature is specified
by negating
For being able to switch paravirt patching from special cased custom
code sequences to ALTERNATIVE handling some X86_FEATURE_* are needed
as new features. This enables to have the standard indirect pv call
as the default code and to patch that with the non-Xen custom code
sequence via ALTERNATIVE p
This is a major cleanup of the paravirt infrastructure aiming at
eliminating all custom code patching via paravirt patching.
This is achieved by using ALTERNATIVE instead, leading to the ability
to give objtool access to the patched in instructions.
In order to remove most of the 32-bit special h
The central pvops call macros PVOP_CALL() and PVOP_VCALL() are
looking very similar now.
The main differences are using PVOP_VCALL_ARGS or PVOP_CALL_ARGS, which
are identical, and the return value handling.
So drop PVOP_VCALL_ARGS and instead of PVOP_VCALL() just use
(void)PVOP_CA
PVOP_VCALL4() is only used for Xen PV, while PVOP_CALL4() isn't used
at all. Keep PVOP_CALL4() for 64 bits due to symmetry reasons.
This allows to remove the 32-bit definitions of those macros leading
to a substantial simplification of the paravirt macros, as those were
the only ones needing non-e
Instead of using paravirt patching for custom code sequences add
support for using ALTERNATIVE handling combined with paravirt call
patching.
Signed-off-by: Juergen Gross
---
V3:
- drop PVOP_ALT_VCALL() macro
---
arch/x86/include/asm/paravirt_types.h | 49 ++-
1 file
The iret paravirt op is rather special as it is using a jmp instead
of a call instruction. Switch it to ALTERNATIVE.
Signed-off-by: Juergen Gross
---
V3:
- use ALTERNATIVE_TERNARY
---
arch/x86/include/asm/paravirt.h | 6 +++---
arch/x86/include/asm/paravirt_types.h | 5 +
arch/x86/ke
There is no need any longer to have different paravirt patch functions
for native and Xen. Eliminate native_patch() and rename
paravirt_patch_default() to paravirt_patch().
Signed-off-by: Juergen Gross
---
V3:
- remove paravirt_patch_insns() (kernel test robot)
---
arch/x86/include/asm/paravirt_
Instead of using paravirt patching for custom code sequences use
ALTERNATIVE for the functions with custom code replacements.
Instead of patching an ud2 instruction for unpopulated vector entries
into the caller site, use a simple function just calling BUG() as a
replacement.
Simplify the registe
On Mon, Mar 08, 2021 at 12:47:44PM +0100, Jan Beulich wrote:
> On 08.03.2021 12:37, Roger Pau Monné wrote:
> > On Fri, Mar 05, 2021 at 10:50:54AM +0100, Jan Beulich wrote:
> >> Linux has been warning ("firmware bug") about this bit being clear for a
> >> long time. While writable in older hardware
On 05/03/2021 09:50, Jan Beulich wrote:
> Linux has been warning ("firmware bug") about this bit being clear for a
> long time. While writable in older hardware it has been readonly on more
> than just most recent hardware. For simplicitly report it always set (if
> anything we may want to log the
On 05.03.2021 17:32, Andrew Cooper wrote:
> On 05/03/2021 15:37, Jan Beulich wrote:
>> Since we don't need to encode all of the PTE flags, we have enough bits
>> in the shadow entry to store the full GFN. Don't use literal numbers -
>> instead derive the involved values. Or, where derivation would
flight 159866 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159866/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d28a68153492ce3e64fb0535674e11e7f46a88a8
baseline version:
ovmf b8a92fa2fea548dccacc2
On 08.03.2021 13:12, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 1/2][4.15?] tools/x86: don't rebuild
> cpuid-autogen.h every time"):
>> Possibly, but it may end up being more complex: We want to only
>> retain files of specific names from a single dir. I don't think
>> this is as straigh
On 08.03.2021 12:28, Jan Beulich wrote:
> On 08.03.2021 12:02, Michal Orzel wrote:
>> On 08.03.2021 11:00, Jan Beulich wrote:
>>> On 08.03.2021 10:52, Michal Orzel wrote:
+config DTB_FILE
+ string "Absolute path to device tree blob"
+ default ""
+ depends on LINK_DTB
On 08.03.2021 14:11, Michal Orzel wrote:
>
>
> On 08.03.2021 12:28, Jan Beulich wrote:
>> On 08.03.2021 12:02, Michal Orzel wrote:
>>> On 08.03.2021 11:00, Jan Beulich wrote:
On 08.03.2021 10:52, Michal Orzel wrote:
> +config DTB_FILE
> + string "Absolute path to device tree blob"
>>
On Mon, Mar 08, 2021 at 12:41:26PM +, Andrew Cooper wrote:
> On 05/03/2021 09:50, Jan Beulich wrote:
> > Linux has been warning ("firmware bug") about this bit being clear for a
> > long time. While writable in older hardware it has been readonly on more
> > than just most recent hardware. For
On 08.03.2021 13:41, Andrew Cooper wrote:
> On 05/03/2021 09:50, Jan Beulich wrote:
>> Linux has been warning ("firmware bug") about this bit being clear for a
>> long time. While writable in older hardware it has been readonly on more
>> than just most recent hardware. For simplicitly report it al
On 08.03.2021 13:29, Roger Pau Monné wrote:
> On Mon, Mar 08, 2021 at 12:47:44PM +0100, Jan Beulich wrote:
>> On 08.03.2021 12:37, Roger Pau Monné wrote:
>>> On Fri, Mar 05, 2021 at 10:50:54AM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -315,6 +315,
On 08.03.2021 14:13, Jan Beulich wrote:
> On 08.03.2021 14:11, Michal Orzel wrote:
>>
>>
>> On 08.03.2021 12:28, Jan Beulich wrote:
>>> On 08.03.2021 12:02, Michal Orzel wrote:
On 08.03.2021 11:00, Jan Beulich wrote:
> On 08.03.2021 10:52, Michal Orzel wrote:
>> +config DTB_FILE
>>>
On 08/03/2021 09:25, Tim Deegan wrote:
> At 16:37 +0100 on 05 Mar (1614962224), Jan Beulich wrote:
>> We can't make correctness of our own behavior dependent upon a
>> hypervisor underneath us correctly telling us the true physical address
>> with hardware uses. Without knowing this, we can't be ce
On 08.03.2021 13:11, Roger Pau Monné wrote:
> On Mon, Mar 08, 2021 at 10:33:12AM +0100, Jan Beulich wrote:
>> On 08.03.2021 09:56, Roger Pau Monné wrote:
>>> On Fri, Mar 05, 2021 at 10:50:34AM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-o
On 08.03.2021 14:47, Andrew Cooper wrote:
> On 08/03/2021 09:25, Tim Deegan wrote:
>> At 16:37 +0100 on 05 Mar (1614962224), Jan Beulich wrote:
>>> We can't make correctness of our own behavior dependent upon a
>>> hypervisor underneath us correctly telling us the true physical address
>>> with har
Currently in order to link existing DTB into Xen image
we need to either specify option CONFIG_DTB_FILE on the
command line or manually add it into .config.
Add Kconfig entry: CONFIG_DTB_FILE to be able to
provide the path to DTB we want to embed into Xen image.
If no path provided - the dtb will n
On 08/03/2021 13:51, Jan Beulich wrote:
> On 08.03.2021 14:47, Andrew Cooper wrote:
>> On 08/03/2021 09:25, Tim Deegan wrote:
>>> At 16:37 +0100 on 05 Mar (1614962224), Jan Beulich wrote:
We can't make correctness of our own behavior dependent upon a
hypervisor underneath us correctly tel
Hi Luca,
On 08/03/2021 11:56, Luca Fancellu wrote:
This patch prevents the dom0 to be loaded skipping its
building and going forward to build domUs when the dom0
kernel is not found and at least one domU is present.
As you are skipping dom0, the domid 0 will not be usable for another
domain.
On 08.03.2021 15:12, Julien Grall wrote:
> On 08/03/2021 11:56, Luca Fancellu wrote:
>> This patch prevents the dom0 to be loaded skipping its
>> building and going forward to build domUs when the dom0
>> kernel is not found and at least one domU is present.
>
> As you are skipping dom0, the domid
On 08.03.2021 14:59, Michal Orzel wrote:
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -68,7 +68,7 @@ extra-y += $(TARGET_SUBARCH)/head.o
>
> #obj-bin-y += o
>
> -ifdef CONFIG_DTB_FILE
> +ifneq ($(CONFIG_DTB_FILE),"")
> obj-y += dtb.o
> AFLAGS-y += -DCONFIG_DTB_FILE=\"
On 08.03.2021 14:59, Andrew Cooper wrote:
> On 08/03/2021 13:51, Jan Beulich wrote:
>> On 08.03.2021 14:47, Andrew Cooper wrote:
>>> On 08/03/2021 09:25, Tim Deegan wrote:
At 16:37 +0100 on 05 Mar (1614962224), Jan Beulich wrote:
> We can't make correctness of our own behavior dependent up
On Fri, Mar 05, 2021 at 11:56:33AM +0100, Jan Beulich wrote:
> On 04.03.2021 15:47, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -1795,6 +1795,7 @@ static int svm_msr_read_intercept(unsigned int msr,
> > uint64_t *msr_content)
> > con
Hi,
On 08/03/2021 13:59, Michal Orzel wrote:
Currently in order to link existing DTB into Xen image
we need to either specify option CONFIG_DTB_FILE on the
command line or manually add it into .config.
Add Kconfig entry: CONFIG_DTB_FILE to be able to
provide the path to DTB we want to embed into
From: Anthony PERARD
Whenever a Xen block device is detach via xenstore, the image
associated with it remained open by the backend QEMU and an error is
logged:
qemu-system-i386: failed to destroy drive: Node xvdz-qcow2 is in use
This happened since object_unparent() doesn't immediately frees
On 08/03/21 15:32, Anthony PERARD wrote:
From: Anthony PERARD
Whenever a Xen block device is detach via xenstore, the image
associated with it remained open by the backend QEMU and an error is
logged:
qemu-system-i386: failed to destroy drive: Node xvdz-qcow2 is in use
This happened since
Jan Beulich writes ("Re: [PATCH 1/2][4.15?] tools/x86: don't rebuild
cpuid-autogen.h every time"):
> On 08.03.2021 13:12, Ian Jackson wrote:
> > This will leave the entire directory structure but I think that is
> > fine. The xen-dir target uses mkdir -p and should there be any stale
> > director
On 08/03/2021 14:29, Jan Beulich wrote:
> On 08.03.2021 14:59, Andrew Cooper wrote:
>> On 08/03/2021 13:51, Jan Beulich wrote:
>>> On 08.03.2021 14:47, Andrew Cooper wrote:
On 08/03/2021 09:25, Tim Deegan wrote:
> At 16:37 +0100 on 05 Mar (1614962224), Jan Beulich wrote:
>> We can't ma
flight 159864 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159864/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 159858
test-amd64-amd64-qemuu-nested-amd 20
On 08/03/2021 08:18, Jan Beulich wrote:
On 08.03.2021 08:00, Igor Druzhinin wrote:
BIOS might pass control to Xen leaving QI and/or IR in enabled and/or
partially configured state. In case of x2APIC code path where EIM is
enabled early in boot - those are correctly disabled by Xen before any
att
On 08.03.2021 15:52, Igor Druzhinin wrote:
> On 08/03/2021 08:18, Jan Beulich wrote:
>> On 08.03.2021 08:00, Igor Druzhinin wrote:
>>> BIOS might pass control to Xen leaving QI and/or IR in enabled and/or
>>> partially configured state. In case of x2APIC code path where EIM is
>>> enabled early in
On Mon, Mar 08, 2021 at 01:28:33PM +0100, Juergen Gross wrote:
> Having the definition of static_call() in static_call_types.h makes
> no sense as long struct static_call_key isn't defined there, as the
> generic implementation of static_call() is referencing this structure.
>
> So move the defini
On Mon, Mar 08, 2021 at 01:28:32PM +0100, Juergen Gross wrote:
> This is a major cleanup of the paravirt infrastructure aiming at
> eliminating all custom code patching via paravirt patching.
>
> This is achieved by using ALTERNATIVE instead, leading to the ability
> to give objtool access to the
On 3/8/21 7:28 AM, Juergen Gross wrote:
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -379,11 +379,6 @@ void xen_timer_resume(void)
> }
> }
>
> -static const struct pv_time_ops xen_time_ops __initconst = {
> - .sched_clock = xen_sched_clock,
> - .steal_clock = xen_
All cpu identification registers that we store in the cpuinfo structure
are 64bit on arm64 and 32bit on arm32 so storing the values in 32bit on
arm64 is removing the higher bits which might contain information in the
future.
This patch is changing the types in cpuinfo to register_t (which is
32bit
On Mon, Mar 08, 2021 at 03:38:49PM +0100, Paolo Bonzini wrote:
> On 08/03/21 15:32, Anthony PERARD wrote:
> > From: Anthony PERARD
> >
> > Whenever a Xen block device is detach via xenstore, the image
> > associated with it remained open by the backend QEMU and an error is
> > logged:
> > qe
On 08/03/21 18:29, Anthony PERARD wrote:
If nothing else works then I guess it's okay, but why can't you do the
xen_block_drive_destroy from e.g. an unrealize callback?
I'm not sure if that's possible.
xen_block_device_create/xen_block_device_destroy() is supposed to be
equivalent to do those
On Mon, Mar 08, 2021 at 06:37:38PM +0100, Paolo Bonzini wrote:
> On 08/03/21 18:29, Anthony PERARD wrote:
> > > If nothing else works then I guess it's okay, but why can't you do the
> > > xen_block_drive_destroy from e.g. an unrealize callback?
> >
> > I'm not sure if that's possible.
> >
> > xe
On 08/03/21 19:14, Anthony PERARD wrote:
On Mon, Mar 08, 2021 at 06:37:38PM +0100, Paolo Bonzini wrote:
On 08/03/21 18:29, Anthony PERARD wrote:
If nothing else works then I guess it's okay, but why can't you do the
xen_block_drive_destroy from e.g. an unrealize callback?
I'm not sure if that
On Mon, Mar 08, 2021 at 01:28:43PM +0100, Juergen Gross wrote:
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index 36cd71fa097f..04b3067f31b5 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -137,7 +137,8 @@ static inli
Hi Bertrand,
On 08/03/2021 17:18, Bertrand Marquis wrote:
All cpu identification registers that we store in the cpuinfo structure
are 64bit on arm64 and 32bit on arm32 so storing the values in 32bit on
arm64 is removing the higher bits which might contain information in the
future.
This patch i
Hi Jan,
On 08/03/2021 11:20, Jan Beulich wrote:
On 08.03.2021 11:51, Julien Grall wrote:
On 08/03/2021 08:09, Jan Beulich wrote:
On 06.03.2021 22:41, Julien Grall wrote:
From: Julien Grall
Compilers older than 4.8 have known codegen issues which can lead to
silent miscompilation:
https://g
On 3/6/21 11:18 AM, Juergen Gross wrote:
> An event channel should be kept masked when an eoi is pending for it.
> When being migrated to another cpu it might be unmasked, though.
>
> In order to avoid this keep three different flags for each event channel
> to be able to distinguish "normal" mas
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 pushes the max freque
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
>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
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
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 318920166c..3b0ca62fc7 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl
1 - 100 of 121 matches
Mail list logo
