Hi Juergen,
On 2023/8/24 14:00, Juergen Gross wrote:
On 24.08.23 05:42, Qi Zheng wrote:
Use new APIs to dynamically allocate the xen-backend shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
CC: Juergen Gross
CC: Stefano Stabellini
CC: Oleksandr Tyshchenko
CC: xen-devel@lists.xen
On 24.08.23 05:42, Qi Zheng wrote:
Use new APIs to dynamically allocate the xen-backend shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
CC: Juergen Gross
CC: Stefano Stabellini
CC: Oleksandr Tyshchenko
CC: xen-devel@lists.xenproject.org
Acked-by: Juergen Gross
Just one note:
On 23.08.2023 22:07, Shawn Anastasio wrote:
> A few files treewide depend on defininitions in headers that they
> don't include. This works when arch headers end up including the
> required headers by chance, but broke on ppc64 with only minimal/stub
> arch headers.
>
> Signed-off-by: Shawn Anasta
flight 182452 linux-linus real [real]
flight 182496 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182452/
http://logs.test-lab.xenproject.org/osstest/logs/182496/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 182497 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182497/
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
> From: Andrew Cooper
> Sent: Thursday, April 6, 2023 5:53 AM
>
> At the time of XSA-170, the x86 instruction emulator was genuinely broken.
> It
> would load arbitrary values into %rip and putting a check here probably was
> the best stopgap security fix. It should have been reverted following
Use new APIs to dynamically allocate the xen-backend shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
CC: Juergen Gross
CC: Stefano Stabellini
CC: Oleksandr Tyshchenko
CC: xen-devel@lists.xenproject.org
---
drivers/xen/xenbus/xenbus_probe_backend.c | 18 +++---
1 file c
flight 182426 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182426/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 182416
test-armhf-armhf-libvirt-qcow2 15 saveres
flight 182427 xen-4.17-testing real [real]
flight 182494 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182427/
http://logs.test-lab.xenproject.org/osstest/logs/182494/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 182490 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182490/
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
From: Stefano Stabellini
10.1 with several caveats, described in the notes.
10.3 and 10.4 as "aspirational" guidelines, as clarified in the notes.
Signed-off-by: Stefano Stabellini
---
docs/misra/rules.rst | 52
1 file changed, 52 insertions(+)
dif
From: Stefano Stabellini
During the discussions that led to the acceptance of Rule 2.1, we
decided on a few exceptions that were not properly recorded in
rules.rst. Add them now.
Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
---
Note that safe.json and the codebase are not yet update
On Wed, 23 Aug 2023, Jan Beulich wrote:
> On 23.08.2023 02:24, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > During the discussions that led to the acceptable of Rule 2.1, we
>
> Nit (as before): "acceptance"?
>
> > decided on a few exceptions that were not properly recorded in
On Wed, 23 Aug 2023, Julien Grall wrote:
> Hi Stefano,
>
> On 23/08/2023 01:24, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > During the discussions that led to the acceptable of Rule 2.1, we
> > decided on a few exceptions that were not properly recorded in
> > rules.rst. Add t
On 19/08/2023 01:28, Vikram Garhwal wrote:
Hi,
Hi Vikram,
This patch series is for introducing dynamic programming i.e. add/remove the
devices during run time. Using "xl dt_overlay" a device can be added/removed
with dtbo.
Do you have any pointer where one can find more details about the dt
Hi Vikram,
On 19/08/2023 01:28, Vikram Garhwal wrote:
Dynamic programming ops will modify the dt_host and there might be other
function which are browsing the dt_host at the same time. To avoid the race
Typo: I think you want to write 'functions'
conditions, adding rwlock for browsing
Hi,
On 19/08/2023 01:28, Vikram Garhwal wrote:
Dynamic programming ops will modify the dt_host and there might be other
function which are browsing the dt_host at the same time. To avoid the race
conditions, we will need to add a rwlock to protect access to the dt_host.
However, adding rwlock in
On 23/08/2023 04:47, Penny Zheng wrote:
Hi Julien
Hi Penny,
On 2023/8/23 02:01, Julien Grall wrote:
Hi Henry,
On 14/08/2023 05:25, Henry Wang wrote:
From: Penny Zheng
Current P2M implementation is designed for MMU system only.
We move the MMU-specific codes into mmu/p2m.c, and only ke
Hi,
On 23/08/2023 19:08, Julien Grall wrote:
With the code movement, global variable max_vmid is used in multiple
files instead of a single file (and will be used in MPU P2M
implementation), declare it in the header and remove the "static" of
this variable.
Add #ifdef CONFIG_HAS_MMU to p2m_write
On Wed, 23 Aug 2023, Julien Grall wrote:
> Hi Nicola,
>
> On 23/08/2023 17:09, Nicola Vetrini wrote:
> > On 23/08/2023 16:59, Julien Grall wrote:
> > > Hi,
> > >
> > > On 23/08/2023 15:27, Nicola Vetrini wrote:
> > > > Directive 4.3 prescribes the following:
> > > > "Assembly language shall be en
Add stub function and symbol definitions required by common code. If the
file that the definition is supposed to be located in doesn't already
exist yet, temporarily place its definition in the new stubs.c
Signed-off-by: Shawn Anastasio
---
v2:
- Use BUG_ON("unimplemented") instead of BUG() for
Implement bitops.h, based on Linux's implementation as of commit
5321d1b1afb9a17302c6cec79f0cbf823eb0d3fc. Though it is based off of
Linux's implementation, this code diverges significantly in a number of
ways:
- Bitmap entries changed to 32-bit words to match X86 and Arm on Xen
- PPC32-specifi
Additionally, change inclusion of asm/ headers to corresponding xen/ ones
throughout arch/ppc now that they work.
Signed-off-by: Shawn Anastasio
---
v2:
- Use BUG_ON("unimplemented") instead of BUG() for unimplemented functions
to make searching easier.
- (altp2m.h) Drop Intel license in
Bring ppc's Makefile and arch.mk in line with arm and x86 to disable the
build overrides and enable the full Xen build.
Signed-off-by: Shawn Anastasio
Reviewed-by: Jan Beulich
---
xen/arch/ppc/Makefile | 16 +++-
xen/arch/ppc/arch.mk | 3 ---
2 files changed, 15 insertions(+), 4 d
Signed-off-by: Shawn Anastasio
---
v2:
- Drop full license text in favor of SPDX header
- Fix include guard naming (s/PPC64/PPC/g)
- Use __aligned__ instead of aligned keyword
- Fix macro naming conventions (use trailing underscore)
- Drop unused MEMORY_PADDING, TRAP_INSTR definitions
Hello all,
This patch series performs all of the additions necessary to drop the
build overrides for PPC and enable the full Xen build. Except in cases
where compatibile implementations already exist (e.g. atomic.h and
bitops.h), the newly added definitions are simple, unimplemented stubs
that jus
Define the bug frames table in ppc's linker script as is done by other
architectures.
Signed-off-by: Shawn Anastasio
Acked-by: Jan Beulich
---
v2: Add extra space to fix alignment of newly added lines
xen/arch/ppc/xen.lds.S | 10 ++
1 file changed, 10 insertions(+)
diff --git a/xen/arc
Implement atomic.h for PPC, based off of the original Xen 3.2
implementation.
Signed-off-by: Shawn Anastasio
---
v2:
- Fix style of asm block constraints to include required spaces
- Fix macro local variable naming (use trailing underscore instead of
leading)
- Drop unnecessary parens i
A few files treewide depend on defininitions in headers that they
don't include. This works when arch headers end up including the
required headers by chance, but broke on ppc64 with only minimal/stub
arch headers.
Signed-off-by: Shawn Anastasio
---
v2:
- (xen/domain.h) Drop include in favor o
flight 182488 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182488/
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 8/8/23 5:27 AM, Jan Beulich wrote:
> On 03.08.2023 01:03, Shawn Anastasio wrote:
>> --- a/xen/arch/ppc/mm-radix.c
>> +++ b/xen/arch/ppc/mm-radix.c
>> @@ -266,3 +266,47 @@ void __init setup_initial_pagetables(void)
>> /* Turn on the MMU */
>> enable_mmu();
>> }
>> +
>> +
>
> Nit: No d
On 23/08/2023 02:41, Henry Wang wrote:
Hi Julien,
Hi Henry,
On Aug 23, 2023, at 02:01, Julien Grall wrote:
Hi Henry,
On 14/08/2023 05:25, Henry Wang wrote:
From: Penny Zheng
Current P2M implementation is designed for MMU system only.
We move the MMU-specific codes into mmu/p2m.c, and
On 23/08/2023 4:23 pm, Anthony PERARD wrote:
> On failure of "build"-each-commit script, the next command that move
> the log back into the build directory isn't executed. Fix that by
> using "after_script" which is always executed even if the main
> "script" fails. (We would still miss the log whe
Hi Stefano,
On 23/08/2023 01:10, Stefano Stabellini wrote:
On Tue, 22 Aug 2023, Julien Grall wrote:
I also don't like the idea of having again a massive mm.c files. So maybe
we need a split like:
* File 1: Boot CPU0 MM bringup (mmu/setup.c)
* File 2: Secondary CPUs MM bringup (mmu/smpboot
On 8/23/23 9:04 AM, Jan Beulich wrote:
> On 23.08.2023 01:03, Shawn Anastasio wrote:
>> Add code to construct early identity-mapped page tables as well as the
>> required process and partition tables to enable the MMU.
>>
>> Signed-off-by: Shawn Anastasio
>
> Acked-by: Jan Beulich
> with two nit
Hi Nicola,
On 23/08/2023 17:09, Nicola Vetrini wrote:
On 23/08/2023 16:59, Julien Grall wrote:
Hi,
On 23/08/2023 15:27, Nicola Vetrini wrote:
Directive 4.3 prescribes the following:
"Assembly language shall be encapsulated and isolated",
on the grounds of improved readability and ease of main
flight 182461 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182461/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 182436
Tests which
On 23/08/2023 16:59, Julien Grall wrote:
Hi,
On 23/08/2023 15:27, Nicola Vetrini wrote:
Directive 4.3 prescribes the following:
"Assembly language shall be encapsulated and isolated",
on the grounds of improved readability and ease of maintenance.
The Directive is violated in this case by asm c
flight 182425 xen-unstable real [real]
flight 182471 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182425/
http://logs.test-lab.xenproject.org/osstest/logs/182471/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On failure of "build"-each-commit script, the next command that move
the log back into the build directory isn't executed. Fix that by
using "after_script" which is always executed even if the main
"script" fails. (We would still miss the log when the jobs times out.)
Signed-off-by: Anthony PERARD
On 23/08/2023 16:59, Julien Grall wrote:
Hi,
On 23/08/2023 15:27, Nicola Vetrini wrote:
Directive 4.3 prescribes the following:
"Assembly language shall be encapsulated and isolated",
on the grounds of improved readability and ease of maintenance.
The Directive is violated in this case by asm c
Hi,
On 23/08/2023 15:27, Nicola Vetrini wrote:
Directive 4.3 prescribes the following:
"Assembly language shall be encapsulated and isolated",
on the grounds of improved readability and ease of maintenance.
The Directive is violated in this case by asm code in between C code.
A macro is the cho
Directive 4.3 prescribes the following:
"Assembly language shall be encapsulated and isolated",
on the grounds of improved readability and ease of maintenance.
The Directive is violated in this case by asm code in between C code.
A macro is the chosen encapsulation mechanism.
No functional change
On Thu, Aug 17, 2023 at 02:39:27PM +0200, Nicola Vetrini wrote:
> The function can become static since it's used only within this file.
> This also resolves a violation of MISRA C:2012 Rule 8.4 due to the absence
> of a declaration before the function definition.
>
> Fixes: b177892d2d0e ("vpci/msi
On 23/08/2023 2:31 pm, Roger Pau Monné wrote:
> On Wed, Aug 23, 2023 at 12:56:48PM +0100, Andrew Cooper wrote:
>> On 23/08/2023 12:15 pm, Roger Pau Monné wrote:
>>> On Wed, Apr 05, 2023 at 10:52:45PM +0100, Andrew Cooper wrote:
At the time of XSA-170, the x86 instruction emulator was genuinely
On 17/08/2023 14:39, Nicola Vetrini wrote:
The function can become static since it's used only within this file.
This also resolves a violation of MISRA C:2012 Rule 8.4 due to the
absence
of a declaration before the function definition.
Fixes: b177892d2d0e ("vpci/msix: handle accesses adjacent
On 23.08.23 16:07, Jan Beulich wrote:
On 23.08.2023 15:57, Jason Andryuk wrote:
On Wed, Aug 23, 2023 at 9:47 AM Jan Beulich wrote:
@@ -316,6 +277,22 @@ int xc_get_cpufreq_para(xc_interface *xc
BUILD_BUG_ON(sizeof(((struct xc_get_cpufreq_para *)0)->u) !=
sizeof((
On 23.08.2023 15:57, Jason Andryuk wrote:
> On Wed, Aug 23, 2023 at 9:47 AM Jan Beulich wrote:
>> @@ -316,6 +277,22 @@ int xc_get_cpufreq_para(xc_interface *xc
>> BUILD_BUG_ON(sizeof(((struct xc_get_cpufreq_para *)0)->u) !=
>> sizeof(((struct xen_get_cpufreq_para *)0)
On 23.08.2023 01:03, Shawn Anastasio wrote:
> Add code to construct early identity-mapped page tables as well as the
> required process and partition tables to enable the MMU.
>
> Signed-off-by: Shawn Anastasio
Acked-by: Jan Beulich
with two nits, which I'll be happy to take care of while commi
On Wed, Aug 23, 2023 at 9:47 AM Jan Beulich wrote:
>
> The full structures cannot match in layout, as soon as a 32-bit tool
> stack build comes into play. But it also doesn't need to; the part of
> the layouts that needs to match is merely the union that we memcpy()
> from the sysctl structure to
On 23.08.2023 15:45, Anthony PERARD wrote:
> On Wed, Aug 23, 2023 at 09:21:26AM +0200, Jan Beulich wrote:
>> Two entries were left in place by d638fe233cb3 ("libxl: use the cpuid
>> feature names from cpufeatureset.h"), despite matching the generated
>> names.
>>
>> Signed-off-by: Jan Beulich
>
>
On 23.08.23 15:47, Jan Beulich wrote:
The full structures cannot match in layout, as soon as a 32-bit tool
stack build comes into play. But it also doesn't need to; the part of
the layouts that needs to match is merely the union that we memcpy()
from the sysctl structure to the xc one. Keep (in a
The full structures cannot match in layout, as soon as a 32-bit tool
stack build comes into play. But it also doesn't need to; the part of
the layouts that needs to match is merely the union that we memcpy()
from the sysctl structure to the xc one. Keep (in adjusted form) only
the relevant ones.
S
On Wed, Aug 23, 2023 at 10:32:19AM +0200, Juergen Gross wrote:
> When introducing polarssl into stubdom building the clean targets of
> stubdom/Makefile gained actions for removing openssl directories and
> files additional to polarssl ones.
>
> As those openssl files are never downloaded or creat
On Wed, Aug 23, 2023 at 09:21:26AM +0200, Jan Beulich wrote:
> Two entries were left in place by d638fe233cb3 ("libxl: use the cpuid
> feature names from cpufeatureset.h"), despite matching the generated
> names.
>
> Signed-off-by: Jan Beulich
Acked-by: Anthony PERARD
> ---
> Permitting "psn",
On Wed, Aug 23, 2023 at 12:56:48PM +0100, Andrew Cooper wrote:
> On 23/08/2023 12:15 pm, Roger Pau Monné wrote:
> > On Wed, Apr 05, 2023 at 10:52:45PM +0100, Andrew Cooper wrote:
> >> At the time of XSA-170, the x86 instruction emulator was genuinely broken.
> >> It
> >> would load arbitrary valu
On 07.08.2023 20:51, Jason Andryuk wrote:
> --- a/tools/libs/ctrl/xc_pm.c
> +++ b/tools/libs/ctrl/xc_pm.c
> @@ -245,6 +245,45 @@ int xc_get_cpufreq_para(xc_interface *xch, int cpuid,
> sys_para->freq_num = user_para->freq_num;
> sys_para->gov_num = user_para->gov_num;
>
> +/* Sanit
On 23.08.2023 11:21, Andrew Cooper wrote:
> On 07/08/2023 3:18 pm, Jan Beulich wrote:
>> On 07.08.2023 16:04, Andrew Cooper wrote:
>>> On 07/08/2023 2:17 pm, Jan Beulich wrote:
On 07.08.2023 14:55, Simon Gaiser wrote:
> Jan Beulich:
>> On 07.08.2023 11:38, Simon Gaiser wrote:
>>> I
flight 182455 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182455/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 182436
Tests which
On 23/08/2023 12:15 pm, Roger Pau Monné wrote:
> On Wed, Apr 05, 2023 at 10:52:45PM +0100, Andrew Cooper wrote:
>> At the time of XSA-170, the x86 instruction emulator was genuinely broken.
>> It
>> would load arbitrary values into %rip and putting a check here probably was
>> the best stopgap se
On Wed, Aug 23, 2023 at 8:05 AM Jan Beulich wrote:
>
> On 23.08.2023 06:32, osstest service owner wrote:
> > flight 182423 xen-4.17-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/182423/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > inc
On Wed, Apr 05, 2023 at 10:52:45PM +0100, Andrew Cooper wrote:
> At the time of XSA-170, the x86 instruction emulator was genuinely broken. It
> would load arbitrary values into %rip and putting a check here probably was
> the best stopgap security fix. It should have been reverted following c/s
Hello,
this is a v3 of the patch series which implements the idea of blkdev_get_by_*()
calls returning bdev_handle which is then passed to blkdev_put() [1]. This
makes the get and put calls for bdevs more obviously matching and allows us to
propagate context from get to put without having to modif
Convert xen/blkback to use bdev_open_by_dev() and pass the
handle around.
CC: xen-devel@lists.xenproject.org
Acked-by: Christoph Hellwig
Signed-off-by: Jan Kara
---
drivers/block/xen-blkback/blkback.c | 4 +--
drivers/block/xen-blkback/common.h | 4 +--
drivers/block/xen-blkback/xenbus.c |
flight 182436 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182436/
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
flight 182424 linux-linus real [real]
flight 182442 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182424/
http://logs.test-lab.xenproject.org/osstest/logs/182442/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On 07/08/2023 3:45 pm, Simon Gaiser wrote:
> Andrew Cooper:
>> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>> 0xff. Linux already has code to handle
On 07/08/2023 3:18 pm, Jan Beulich wrote:
> On 07.08.2023 16:04, Andrew Cooper wrote:
>> On 07/08/2023 2:17 pm, Jan Beulich wrote:
>>> On 07.08.2023 14:55, Simon Gaiser wrote:
Jan Beulich:
> On 07.08.2023 11:38, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the AC
On Mon, Aug 07, 2023 at 03:17:18PM +0200, Jan Beulich wrote:
> On 07.08.2023 14:55, Simon Gaiser wrote:
> > Jan Beulich:
> >> On 07.08.2023 11:38, Simon Gaiser wrote:
> >>> It seems some firmwares put dummy entries in the ACPI MADT table for non
> >>> existing processors. On my NUC11TNHi5 those hav
Hi Stefano,
On 23/08/2023 01:24, Stefano Stabellini wrote:
From: Stefano Stabellini
During the discussions that led to the acceptable of Rule 2.1, we
decided on a few exceptions that were not properly recorded in
rules.rst. Add them now.
Signed-off-by: Stefano Stabellini
---
docs/misra/rul
On Mon, Jul 31, 2023 at 04:40:35PM +, Chen, Jiqian wrote:
> Hi,
>
> On 2023/3/18 04:55, Stefano Stabellini wrote:
> > On Fri, 17 Mar 2023, Roger Pau Monné wrote:
> >> On Fri, Mar 17, 2023 at 11:15:37AM -0700, Stefano Stabellini wrote:
> >>> On Fri, 17 Mar 2023, Roger Pau Monné wrote:
> On
The extras directory is used only as a download target for Mini-OS
sources. Instead of special handling extras/mini-os* in .gitignore and
the clean targets, just use extras for that purpose.
So add "extras" to .gitignore and remove it when doing a
"make distclean".
Signed-off-by: Juergen Gross
-
When introducing polarssl into stubdom building the clean targets of
stubdom/Makefile gained actions for removing openssl directories and
files additional to polarssl ones.
As those openssl files are never downloaded or created during build,
the related actions can be dropped.
Fixes: bdd516dc6b2f
On 03.08.2023 12:22, Simone Ballarin wrote:
> This series aims to address some violations ofMISRA C:2012 Rule 7.3:
> "The lowercase character 'l' shall not be used in a literal suffix".
>
> This patch replaces "l" suffixes with "L", to comply with the rule.
> If the "u" suffix is used near "L", us
On 23.08.2023 09:28, Andrew Cooper wrote:
> On 23/08/2023 8:04 am, Federico Serafini wrote:
>> Make function declarations and definitions consistent to address
>> violations of MISRA C:2012 Rule 8.3 ("All declarations of an object or
>> function shall use the same names and type qualifiers").
>>
>>
On 23/08/2023 8:04 am, Federico Serafini wrote:
> Make function declarations and definitions consistent to address
> violations of MISRA C:2012 Rule 8.3 ("All declarations of an object or
> function shall use the same names and type qualifiers").
>
> No functional change.
>
> Signed-off-by: Federic
Two entries were left in place by d638fe233cb3 ("libxl: use the cpuid
feature names from cpufeatureset.h"), despite matching the generated
names.
Signed-off-by: Jan Beulich
---
Permitting "psn", "ia64, "cntxid", and "perfctr_*" when the hypervisor
doesn't even know of the bits (perhaps wrongly so
On 23.08.2023 09:04, Federico Serafini wrote:
> Make function declarations and definitions consistent to address
> violations of MISRA C:2012 Rule 8.3 ("All declarations of an object or
> function shall use the same names and type qualifiers").
>
> No functional change.
>
> Signed-off-by: Federic
On 23.08.2023 06:32, osstest service owner wrote:
> flight 182423 xen-4.17-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/182423/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-xsm
Make function declarations and definitions consistent to address
violations of MISRA C:2012 Rule 8.3 ("All declarations of an object or
function shall use the same names and type qualifiers").
No functional change.
Signed-off-by: Federico Serafini
---
Changes in v2:
- change compat_grant_table_o
80 matches
Mail list logo