> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the nfsd-filecache shrinker.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
On 25.07.2023 23:36, Andrew Cooper wrote:
> With xl/libxl now able to control the policy bits for MSR_ARCH_CAPS, it is
> safe to advertise to guests by default. In turn, we don't need the special
> case to expose details to dom0.
>
> This advertises MSR_ARCH_CAPS to guests on *all* Intel hardware
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the nfs-acl shrinker.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the nfs-xattr shrinkers.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
On 2023/7/24 17:43, Qi Zheng wrote:
Use new APIs to dynamically allocate the gfs2-qd shrinker.
Signed-off-by: Qi Zheng
---
fs/gfs2/main.c | 6 +++---
fs/gfs2/quota.c | 26 --
fs/gfs2/quota.h | 3 ++-
3 files changed, 25 insertions(+), 10 deletions(-)
diff --g
On 26.07.2023 08:42, Nicola Vetrini wrote:
> On 26/07/23 08:34, Jan Beulich wrote:
>> On 25.07.2023 22:45, Nicola Vetrini wrote:
>>> Rule 5.3 has the following headline:
>>> "An identifier declared in an inner scope shall not hide an
>>> identifier declared in an outer scope"
>>>
>>> To avoid any c
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the gfs2-glock shrinker.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
Thanks.
On 26/07/23 08:34, Jan Beulich wrote:
On 25.07.2023 22:45, Nicola Vetrini wrote:
Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"
To avoid any confusion resulting from the parameter 'debug'
hiding the homo
On 26.07.2023 03:17, Volodymyr Babchuk wrote:
> Roger Pau Monné writes:
>> On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
>>> --- a/xen/arch/x86/hvm/vmsi.c
>>> +++ b/xen/arch/x86/hvm/vmsi.c
>>> @@ -895,6 +895,8 @@ int vpci_msix_arch_print(const struct vpci_msix *msix)
>>> {
>>
On 25.07.2023 22:45, Nicola Vetrini wrote:
> Rule 5.3 has the following headline:
> "An identifier declared in an inner scope shall not hide an
> identifier declared in an outer scope"
>
> To avoid any confusion resulting from the parameter 'debug'
> hiding the homonymous function declared at
> 'x
On 17.07.2023 17:24, Jan Beulich wrote:
> On 14.07.2023 11:28, Julien Grall wrote:
>> On 11/07/2023 13:29, Jan Beulich wrote:
>>> On 10.07.2023 22:59, Julien Grall wrote:
> ---
> I'm not really certain about XEN_DOMCTL_irq_permission: With pIRQ-s not
> used, the prior pIRQ -> IRQ transl
On 25.07.23 18:08, Julien Grall wrote:
Hi,
On 24/07/2023 12:02, Juergen Gross wrote:
The key and value are never modified by hashtable code, so they should
be marked as const.
You wrote this but...
Signed-off-by: Juergen Gross
---
V3:
- make value const, too.
---
tools/xenstore/hashtabl
flight 182001 linux-5.4 real [real]
flight 182019 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182001/
http://logs.test-lab.xenproject.org/osstest/logs/182019/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armh
On 25.07.2023 18:59, Andrew Cooper wrote:
> On 25/07/2023 5:16 pm, Jan Beulich wrote:
>> On 25.07.2023 15:55, Juergen Gross wrote:
>>> Flexible arrays in public headers can be problematic with some
>>> compilers.
>>>
>>> Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
>>> er
On 25.07.2023 22:28, Nicola Vetrini wrote:
>
>
> On 25/07/23 21:37, Stefano Stabellini wrote:
>> On Tue, 25 Jul 2023, Jan Beulich wrote:
>>> On 25.07.2023 11:17, Nicola Vetrini wrote:
Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
i
flight 182018 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182018/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 25a6745fe886e88fe175a50dcab4562c65b7cea3
baseline version:
ovmf dcf05f958eb409095bf33
On Tue, Jul 25, 2023 at 03:34:26PM +0200, Juergen Gross wrote:
> On 25.07.23 15:24, Juergen Gross wrote:
> > On 23.07.23 02:06, Nathan Chancellor wrote:
> > > On Sat, Jul 22, 2023 at 07:21:05AM +0700, Bagas Sanjaya wrote:
> > > > Hi,
> > > >
> > > > I notice a regression report on Bugzilla [1]. Qu
flight 181998 xen-4.16-testing real [real]
flight 182017 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181998/
http://logs.test-lab.xenproject.org/osstest/logs/182017/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
Hi Roger,
Roger Pau Monné writes:
> On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
>> From: Oleksandr Andrushchenko
>>
>> When a PCI device gets assigned/de-assigned some work on vPCI side needs
>> to be done for that device. Introduce a pair of hooks so vPCI can handle
>>
Hi Roger,
Roger Pau Monné writes:
> On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
>> From: Oleksandr Andrushchenko
>>
>> Use a previously introduced per-domain read/write lock to check
>> whether vpci is present, so we are sure there are no accesses to the
>> contents of
flight 182015 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182015/
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
Il giorno mar 25 lug 2023 alle ore 22:04 Stefano Stabellini <
sstabell...@kernel.org> ha scritto:
> How do I access "gl-code-quality-report.json" or otherwise any other
> meaningful ECLAIR output? If I browse the job artifacts I see all the
> various logs but no gl-code-quality-report.json.
>
gl-
Hi Vishal,
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on next-20230725]
[cannot apply to powerpc/next powerpc/fixes s390/features geert-m68k/for-next
geert-m68k/for-linus linus/master v6.5-rc3]
[If your patch is
flight 181997 xen-4.17-testing real [real]
flight 182014 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181997/
http://logs.test-lab.xenproject.org/osstest/logs/182014/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
With xl/libxl now able to control the policy bits for MSR_ARCH_CAPS, it is
safe to advertise to guests by default. In turn, we don't need the special
case to expose details to dom0.
This advertises MSR_ARCH_CAPS to guests on *all* Intel hardware, even if the
register content ends up being empty.
On Tue, 25 Jul 2023, Nicola Vetrini wrote:
> Rule 5.3 has the following headline:
> "An identifier declared in an inner scope shall not hide an
> identifier declared in an outer scope"
>
> To avoid any confusion resulting from the parameter 'debug'
> hiding the homonymous function declared at
> 'x
Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"
To avoid any confusion resulting from the parameter 'debug'
hiding the homonymous function declared at
'xen/arch/x86/include/asm/processor.h:428'
the rename of pa
On Tue, 25 Jul 2023, Nicola Vetrini wrote:
> On 25/07/23 21:37, Stefano Stabellini wrote:
> > On Tue, 25 Jul 2023, Jan Beulich wrote:
> > > On 25.07.2023 11:17, Nicola Vetrini wrote:
> > > > Rule 5.3 has the following headline:
> > > > "An identifier declared in an inner scope shall not hide an
> >
On 25/07/23 21:37, Stefano Stabellini wrote:
On Tue, 25 Jul 2023, Jan Beulich wrote:
On 25.07.2023 11:17, Nicola Vetrini wrote:
Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"
To avoid any confusion resu
For the record, as I mentioned during the call today, I asked to
postpone the 9.1 work for later, because it is going to take a lot of
work and discussions to figure out a good way forward for all these
cases. There are at least 3-5 different sub-classes for this issues. So
I think it would be bett
On Tue, 25 Jul 2023, Simone Ballarin wrote:
> Signed-off-by: Simone Ballarin
>
> --
> Changes in v3:
> - split maintainer add in a separate patch;
> - substitute blanks with tabs;
> - fix file paths;
> - change role from maintainer to reviewer.
>
> Changes in v2:
> - add ECLAIR configuration fil
On Tue, 25 Jul 2023, Simone Ballarin wrote:
> Add two pipelines that analyze an ARM64 and a X86_64 build with the
> ECLAIR static analyzer on the guidelines contained in Set1.
>
> The analysis configuration is stored in automation/eclair_analysis.
>
> All commits on the xen-project/xen:staging br
On Tue, 25 Jul 2023, Simone Ballarin wrote:
> This patch defines an ARM64 and a X86_64 build for the
> ECLAIR pipelines.
>
> These files are used by the analyze.sh script in
> automation/eclair_analysis: it initially calls prepare.sh,
> then runs into an ECLAIR environment build.sh.
>
> Only the
On Tue, 25 Jul 2023, Simone Ballarin wrote:
> The files with extension ecl are ECLAIR configurations that
> are loaded during the analysis phase or during the report
> generation phase: analysis.ecl is the main file for the analysis
> phase, while reports.ecl is the one for the report phase.
> All
On Tue, 25 Jul 2023, Andrew Cooper wrote:
> This global variable is shadowed by plenty local variables, violating MISRA
> rule 5.3. Some architectures happen to have a symbol by the name of start in
> their head.S's, but it's not a useful symbol to reference from C.
>
> In fact, the single use of
On Tue, 25 Jul 2023, Jan Beulich wrote:
> On 25.07.2023 11:17, Nicola Vetrini wrote:
> > Rule 5.3 has the following headline:
> > "An identifier declared in an inner scope shall not hide an
> > identifier declared in an outer scope"
> >
> > To avoid any confusion resulting from the parameter 'debu
Hello Stefano,
On 25/07/23 00:55, Stefano Stabellini wrote:
int request_irq(unsigned int irq, unsigned int irqflags,
-void (*handler)(int, void *, struct cpu_user_regs *),
+void (*handler)(int irq, void *dev_id,
+struct cpu_user_r
On Tue, 25 Jul 2023, Jan Beulich wrote:
> On 24.07.2023 19:50, Federico Serafini wrote:
> > @@ -182,7 +182,8 @@ void irq_set_affinity(struct irq_desc *desc, const
> > cpumask_t *cpu_mask)
> > }
> >
> > int request_irq(unsigned int irq, unsigned int irqflags,
> > -void (*handler
On Tue, 25 Jul 2023, Federico Serafini wrote:
> Give a name to unnamed parameters thus addressing violations of
> MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
> named parameters").
> Keep consistency between parameter names and types used in function
> declarations and the
flight 182000 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182000/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 181987
Tests which did no
This global variable is shadowed by plenty local variables, violating MISRA
rule 5.3. Some architectures happen to have a symbol by the name of start in
their head.S's, but it's not a useful symbol to reference from C.
In fact, the single use of the global start[] in RISC-V is wrong and means to
Normal behavior is to be silent. Generating a message for the preferred
input can be mistaken for an error. As such remove this message to match
other conditions.
Signed-off-by: Elliott Mitchell
---
This looks like a bit of printf()-debugging which never got removed. The
message serves to disc
On 25/07/2023 5:16 pm, Jan Beulich wrote:
> On 25.07.2023 15:55, Juergen Gross wrote:
>> Flexible arrays in public headers can be problematic with some
>> compilers.
>>
>> Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
>> errors.
>>
>> This includes arrays defined as "arr[1
flight 181996 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181996/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 180425
test-amd64-i386-xl-qemut-win7-am
On 25/07/23 16:52, Jan Beulich wrote:
On 25.07.2023 11:08, Nicola Vetrini wrote:
@@ -99,14 +99,15 @@ static void sched_set_affinity(
struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft);
static struct sched_resource *cf_check
-sched_idle_res_pick(const struct sch
On 25.07.2023 15:55, Juergen Gross wrote:
> Flexible arrays in public headers can be problematic with some
> compilers.
>
> Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
> errors.
>
> This includes arrays defined as "arr[1]", as seen with a recent Linux
> kernel [1].
>
Hi,
On 24/07/2023 12:02, Juergen Gross wrote:
The key and value are never modified by hashtable code, so they should
be marked as const.
You wrote this but...
Signed-off-by: Juergen Gross
---
V3:
- make value const, too.
---
tools/xenstore/hashtable.c | 7 ---
tools/xenstore/hashtab
On Tue, Jul 25, 2023 at 03:44:29PM +0100, Anthony PERARD wrote:
> On Tue, Jul 25, 2023 at 03:05:55PM +0200, Roger Pau Monne wrote:
> > diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
> > index 3c8b2a72c0b8..dd97699bbde7 100644
> > --- a/tools/libs/light/libxl_cpuid.c
>
On 25/07/2023 2:55 pm, Juergen Gross wrote:
> Flexible arrays in public headers can be problematic with some
> compilers.
>
> Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
> errors.
>
> This includes arrays defined as "arr[1]", as seen with a recent Linux
> kernel [1].
>
>
Hi Juergen,
On 24/07/2023 12:02, Juergen Gross wrote:
Instead of using TDB_REPLACE for either creating or modifying a TDB
entry, use either TDB_INSERT or TDB_MODIFY when calling tdb_store().
At higher function levels use the abstract mode values NODE_CREATE
and NODE_MODIFY.
This is for prepari
Hi Juergen,
On 24/07/2023 11:33, Juergen Gross wrote:
The return type of canonicalize() can be modified to const char *.
This avoids the need to cast the const away from the input parameter.
There need to be quite some other functions modified to take const
parameters in order to avoid further
On Wed, Jul 12, 2023 at 11:29:17AM +0100, Peter Hoyes wrote:
> @@ -1968,9 +1979,12 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid,
> int cons_num,
> * guests using pygrub.
> * If notify_fd is not -1, xenconsole will write 0x00 to it to nofity
> * the caller that it has connected to
Hi Bertrand,
On 25/07/2023 16:42, Bertrand Marquis wrote:
Rework TEE mediators to put them under a submenu in Kconfig.
The submenu is only visible if UNSUPPORTED is activated as all currently
existing mediators are UNSUPPORTED.
While there rework a bit the configuration so that OP-TEE and FF-A
Rework TEE mediators to put them under a submenu in Kconfig.
The submenu is only visible if UNSUPPORTED is activated as all currently
existing mediators are UNSUPPORTED.
While there rework a bit the configuration so that OP-TEE and FF-A
mediators are selecting the generic TEE interface instead of
On Wed, Jul 12, 2023 at 11:29:16AM +0100, Peter Hoyes wrote:
> From: Peter Hoyes
>
> Dom0 may be accessed via telnet, meaning the default escape character
> (which is the same as telnet's) cannot be directly used to exit the
> console. It would be helpful to make the escape character customizable
Signed-off-by: Simone Ballarin
--
Changes in v3:
- split maintainer add in a separate patch;
- substitute blanks with tabs;
- fix file paths;
- change role from maintainer to reviewer.
Changes in v2:
- add ECLAIR configuration files (before they were fetched from a separate
repository);
- now
Add two pipelines that analyze an ARM64 and a X86_64 build with the
ECLAIR static analyzer on the guidelines contained in Set1.
The analysis configuration is stored in automation/eclair_analysis.
All commits on the xen-project/xen:staging branch will be analyzed
and their artifacts will be stored
This patch defines an ARM64 and a X86_64 build for the
ECLAIR pipelines.
These files are used by the analyze.sh script in
automation/eclair_analysis: it initially calls prepare.sh,
then runs into an ECLAIR environment build.sh.
Only the toolchain invocations triggered by build.sh
are analyzed; th
The files with extension ecl are ECLAIR configurations that
are loaded during the analysis phase or during the report
generation phase: analysis.ecl is the main file for the analysis
phase, while reports.ecl is the one for the report phase.
All other ecl files are included by one of the two main on
This patch series adds two pipelines that analyze an ARM64 and a X86_64
build with the ECLAIR static analyzer on the guidelines contained in Set1.
The builds analyzed are the ones triggered by
automation/eclair_analysis/build.sh.
automation/eclair_analysis/ECLAIR contains the ECLAIR configuration
On 25.07.2023 16:43, Federico Serafini wrote:
> Change parameter name from 'cpunum' to 'cpu' to keep consistency with
> the name used in the corresponding definitions thus addressing a
> violation of MISRA C:2012 Rule 8.3: "All declarations of an object or
> function shall use the same names and ty
On 25.07.2023 11:17, Nicola Vetrini wrote:
> Rule 5.3 has the following headline:
> "An identifier declared in an inner scope shall not hide an
> identifier declared in an outer scope"
>
> To avoid any confusion resulting from the parameter 'debug'
> hiding the homonymous function declared at
> 'x
On 25.07.2023 11:08, Nicola Vetrini wrote:
> @@ -99,14 +99,15 @@ static void sched_set_affinity(
> struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft);
>
> static struct sched_resource *cf_check
> -sched_idle_res_pick(const struct scheduler *ops, const struct sched_unit
On 24.07.2023 14:58, Jason Andryuk wrote:
> 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_H
On Tue, Jul 25, 2023 at 03:05:55PM +0200, Roger Pau Monne wrote:
> diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
> index 3c8b2a72c0b8..dd97699bbde7 100644
> --- a/tools/libs/light/libxl_cpuid.c
> +++ b/tools/libs/light/libxl_cpuid.c
> @@ -592,17 +641,32 @@ int libxl__
Change parameter name from 'cpunum' to 'cpu' to keep consistency with
the name used in the corresponding definitions thus addressing a
violation of MISRA C:2012 Rule 8.3: "All declarations of an object or
function shall use the same names and type qualifiers".
No functional changes.
Signed-off-by
On 25.07.2023 15:30, Roger Pau Monné wrote:
> On Tue, Jul 18, 2023 at 05:40:18PM +0200, Jan Beulich wrote:
>> On 18.07.2023 14:43, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/io_apic.c
>>> +++ b/xen/arch/x86/io_apic.c
>>> @@ -584,16 +585,16 @@ set_ioapic_affinity_irq(struct irq_desc *desc, const
On 25.07.2023 15:26, Jason Andryuk wrote:
> On Tue, Jul 25, 2023 at 2:27 AM Jan Beulich wrote:
>>
>> On 24.07.2023 21:49, Jason Andryuk wrote:
>>> On Mon, Jul 24, 2023 at 12:15 PM Jan Beulich wrote:
On 24.07.2023 14:58, Jason Andryuk wrote:
> --- /dev/null
> +++ b/xen/arch/x86/acpi/c
On 25.07.2023 16:27, Julien Grall wrote:
> Hi,
>
> On 25/07/2023 07:51, Jan Beulich wrote:
>> On 24.07.2023 20:20, Julien Grall wrote:
>>> On 24/07/2023 13:18, Alejandro Vallejo wrote:
On Fri, Jul 21, 2023 at 06:05:51PM +0100, Julien Grall wrote:
> Hi Alejandro,
>
> On 17/07/2023
Hi,
On 21/07/2023 15:34, Bertrand Marquis wrote:
On 21 Jul 2023, at 16:24, Jan Beulich wrote:
On 21.07.2023 16:07, Bertrand Marquis wrote:
On 21 Jul 2023, at 15:08, Jan Beulich wrote:
On 21.07.2023 14:27, Bertrand Marquis wrote:
So what should i keep or remove here ?
My understanding so f
Hi,
On 25/07/2023 07:51, Jan Beulich wrote:
On 24.07.2023 20:20, Julien Grall wrote:
On 24/07/2023 13:18, Alejandro Vallejo wrote:
On Fri, Jul 21, 2023 at 06:05:51PM +0100, Julien Grall wrote:
Hi Alejandro,
On 17/07/2023 17:03, Alejandro Vallejo wrote:
+bool pdx_is_region_compressible(unsig
Give a name to unnamed parameters thus addressing violations of
MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
named parameters").
Keep consistency between parameter names and types used in function
declarations and the ones used in the corresponding function
definitions, th
Flexible arrays in public headers can be problematic with some
compilers.
Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
errors.
This includes arrays defined as "arr[1]", as seen with a recent Linux
kernel [1].
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217693
Sig
flight 181995 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181995/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 180426
test-amd64-amd64-xl-qemuu-win7-a
On 25.07.23 15:24, Juergen Gross wrote:
On 23.07.23 02:06, Nathan Chancellor wrote:
On Sat, Jul 22, 2023 at 07:21:05AM +0700, Bagas Sanjaya wrote:
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
Hi Kernel Team,
I rebuild today latest version from mainline repo.
And i noti
On Tue, Jul 18, 2023 at 05:40:18PM +0200, Jan Beulich wrote:
> On 18.07.2023 14:43, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/io_apic.c
> > +++ b/xen/arch/x86/io_apic.c
> > @@ -584,16 +585,16 @@ set_ioapic_affinity_irq(struct irq_desc *desc, const
> > cpumask_t *mask)
> > dest = S
On Tue, Jul 25, 2023 at 2:27 AM Jan Beulich wrote:
>
> On 24.07.2023 21:49, Jason Andryuk wrote:
> > On Mon, Jul 24, 2023 at 12:15 PM Jan Beulich wrote:
> >> On 24.07.2023 14:58, Jason Andryuk wrote:
> >>> --- /dev/null
> >>> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c
> >>> +#define hwp_err(cpu, fmt,
On 23.07.23 02:06, Nathan Chancellor wrote:
On Sat, Jul 22, 2023 at 07:21:05AM +0700, Bagas Sanjaya wrote:
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
Hi Kernel Team,
I rebuild today latest version from mainline repo.
And i notice issue regarding xen-netfront.c.
Error
Hello Julien,
On 25/07/23 12:02, Julien Grall wrote:
-unsigned int dt_number_of_address(const struct dt_device_node *dev)
+unsigned int dt_number_of_address(const struct dt_device_node *device)
We have a structure called 'device', so wouldn't this result to violate
another MISRA rule because id
Introduce support for handling MSR features in
libxl_cpuid_parse_config(). The MSR policies are added to the
libxl_cpuid_policy like the CPUID one, which gets passed to
xc_cpuid_apply_policy().
This allows existing users of libxl to provide MSR related features as
key=value pairs to libxl_cpuid_p
The current implementation in libxl_cpuid_parse_config() requires
keeping a list of cpuid feature bits that should be mostly in sync
with the contents of cpufeatureset.h.
Avoid such duplication by using the automatically generated list of
cpuid features in INIT_FEATURE_NAMES in order to map featur
Currently libxl_cpuid_policy_list is an opaque type to the users of
libxl, and internally it's an array of xc_xend_cpuid objects.
Change the type to instead be a structure that contains one array for
CPUID policies, in preparation for it also holding another array for
MSR policies.
Signed-off-by:
Like it's done with CPUID, introduce support for passing MSR values to
xc_cpuid_apply_policy(). The chosen format for expressing MSR policy
data matches the current one used for CPUID. Note that existing
callers of xc_cpuid_apply_policy() can pass NULL as the value for the
newly introduced 'msr'
Add a new array field to libxl_cpuid_policy in order to store the MSR
policies.
Adding the MSR data in the libxl_cpuid_policy_list type is done so
that existing users can seamlessly pass MSR features as part of the
CPUID data, without requiring the introduction of a separate
domain_build_info fiel
Move the CPUID value parsers out of libxl_cpuid_parse_config() into a
newly created cpuid_add() local helper. This is in preparation for
also adding MSR feature parsing support.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Anthony PERARD
---
Changes since v3:
- F
Hello,
The following series adds support for handling guest MSR features as
defined in arch-x86/cpufeatureset.h.
The end result is the user being able to use such features with the
xl.cfg(5) cpuid option. This also involves adding support to all the
underlying layers, so both libxl and libxc als
On Tue, Jul 25, 2023 at 08:40:31AM +0200, Jan Beulich wrote:
> On 24.07.2023 18:52, Alejandro Vallejo wrote:
> > Some hypervisors report ~0 as the microcode revision to mean "don't issue
> > microcode updates". Ignore the microcode loading interface in that case.
> >
> > Signed-off-by: Alejandro V
On Tue, 2023-07-25 at 10:16 +0200, Jan Beulich wrote:
> On 24.07.2023 18:00, Oleksii wrote:
> > On Mon, 2023-07-24 at 16:11 +0200, Jan Beulich wrote:
> > > On 24.07.2023 11:42, Oleksii Kurochko wrote:
> > > > +void __init remove_identity_mapping(void)
> > > > +{
> > > > + static pte_t *pgtbl = s
Xen provides support for injecting interrupts to the guests via the
HYPERVISOR_dm_op() hypercall. The same is used by the Virtio based
device backend implementations, in an inefficient manner currently.
Generally, the Virtio backends are implemented to work with the Eventfd
based mechanism. In ord
flight 182009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182009/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl 8 xen-boot fail in 182002 pass in 182009
test-amd64-amd64-xl-qemuu-
flight 181994 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181994/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278
test-arm64-arm64-li
Hi Federico,
On 24/07/2023 09:40, Federico Serafini wrote:
Give a name to unnamed parameters thus addressing violations of
MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
named parameters").
Keep consistency between parameter names and types used in function
declarations a
Hi Muchun,
On 2023/7/25 17:02, Muchun Song wrote:
On 2023/7/24 17:43, Qi Zheng wrote:
Currently, the shrinker instances can be divided into the following three
types:
a) global shrinker instance statically defined in the kernel, such as
workingset_shadow_shrinker.
b) global shrinker ins
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the f2fs-shrinker.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
Thanks.
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the erofs-shrinker.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
Thanks.
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the xen-backend shrinker.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
Thanks.
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the drm-ttm_pool shrinker.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
Thanks.
Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"
To avoid any confusion resulting from the parameter 'debug'
hiding the homonymous function declared at
'xen/arch/x86/include/asm/processor.h:428'
the rename of pa
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the x86-mmu shrinker.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
Thanks.
Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"
The renaming s/sched_id/scheduler_id/ of the function defined in
'xen/common/sched/core.c' prevents any hiding of that function
by the instances of homonymous fun
1 - 100 of 117 matches
Mail list logo
