> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the dquota-cache 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 ubifs-slab 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 rcu-lazy shrinker.
>
> Signed-off-by: Qi Zheng
> ---
> kernel/rcu/tree_nocb.h | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/rcu/tree_nocb.h b/kerne
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the rcu-kfree shrinker.
>
> Signed-off-by: Qi Zheng
> ---
> kernel/rcu/tree.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/t
On 2023/7/24 17:43, Qi Zheng wrote:
Use new APIs to dynamically allocate the thp-zero and thp-deferred_split
shrinkers.
Signed-off-by: Qi Zheng
---
mm/huge_memory.c | 69 +++-
1 file changed, 45 insertions(+), 24 deletions(-)
diff --git a/mm/hu
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Use new APIs to dynamically allocate the sunrpc_cred 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 mm-shadow shrinker.
>
> Signed-off-by: Qi Zheng
> ---
> mm/workingset.c | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/mm/workingset.c b/mm/working
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the i915_gem_mm shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section
Make function declaration and definition consistent using the same
parameter name ('mcs' do denote a pointer to an 'mc_state').
This addresses a violation of MISRA C:2012 Rule 8.3: "All declarations of an
object or function shall use the same names and type qualifiers".
Signed-off-by: Federico Ser
On 2023/7/24 17:43, Qi Zheng wrote:
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the drm-msm_gem shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the dm-bufio shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section whe
On Mon, Jul 24, 2023 at 05:43:10PM +0800, 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 instance statically defi
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the dm-zoned-meta shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical sectio
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the md-raid5 shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section whe
On 2023/7/24 17:43, Qi Zheng wrote:
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the md-bcache shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the st
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the vmw-balloon shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the virtio-balloon shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical secti
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the mbcache shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section when
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the ext4-es shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section when
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the jbd2-journal shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the xfs-buf shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section when
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the xfs-inodegc shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the xfs-qm shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section when
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> In preparation for implementing lockless slab shrink, use new APIs to
> dynamically allocate the mm-zspool shrinker, so that it can be freed
> asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
> read-side critical section wh
On 2023/7/24 17:43, Qi Zheng wrote:
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the s_shrink, so that it can be freed asynchronously
using kfree_rcu(). Then it doesn't need to wait for RCU read-side critical
section when releasing the struct super
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Now no users are using the old APIs, just remove them.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
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
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Currently, the synchronize_shrinkers() is only used by TTM pool. It only
> requires that no shrinkers run in parallel.
>
> After we use RCU+refcount method to implement the lockless slab shrink,
> we can not use shrinker_rwsem or synchronize_rc
On Tue, 2023-07-25 at 19:20 +0100, 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,
On Mon, Jul 24, 2023 at 05:43:51PM +0800, Qi Zheng wrote:
> The shrinker_rwsem is a global read-write lock in shrinkers subsystem,
> which protects most operations such as slab shrink, registration and
> unregistration of shrinkers, etc. This can easily cause problems in the
> following cases.
>
>
Hi Juergen,
On 26/07/2023 07:19, Juergen Gross wrote:
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
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
On Wed, Jul 26, 2023 at 01:38:30AM +, Volodymyr Babchuk wrote:
>
> Hi Roger,
>
> Roger Pau Monné writes:
>
> > On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
> >> From: Oleksandr Andrushchenko
> >> @@ -1509,6 +1517,19 @@ static int assign_device(struct domain *d, u16 se
On 26.07.23 10:20, Julien Grall wrote:
Hi Juergen,
On 26/07/2023 07:19, Juergen Gross wrote:
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...
On 26.07.2023 09:22, Federico Serafini wrote:
> Make function declaration and definition consistent using the same
> parameter name ('mcs' do denote a pointer to an 'mc_state').
> This addresses a violation of MISRA C:2012 Rule 8.3: "All declarations of an
> object or function shall use the same na
On 26.07.2023 10:27, 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
Hi Dave,
On 2023/7/26 16:08, Dave Chinner wrote:
On Mon, Jul 24, 2023 at 05:43:51PM +0800, Qi Zheng wrote:
The shrinker_rwsem is a global read-write lock in shrinkers subsystem,
which protects most operations such as slab shrink, registration and
unregistration of shrinkers, etc. This can easil
Hi Dave,
On 2023/7/26 15:26, Dave Chinner wrote:
On Mon, Jul 24, 2023 at 05:43:10PM +0800, 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)
On 2023/7/26 14:49, Muchun Song wrote:
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, 2
On 20/06/2023 18:58, David Woodhouse wrote:
From: David Woodhouse
Coverity was unhappy (CID 1508359) because we didn't check the return of
init_walk_op() in transaction_commit(), despite doing so at every other
call site.
Strictly speaking, this is a false positive since it can never fail. It
On 2023/7/26 15:04, Muchun Song wrote:
On Jul 24, 2023, at 17:43, Qi Zheng wrote:
Use new APIs to dynamically allocate the rcu-lazy shrinker.
Signed-off-by: Qi Zheng
---
kernel/rcu/tree_nocb.h | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/kernel
On 2023/7/26 15:10, Muchun Song wrote:
On 2023/7/24 17:43, Qi Zheng wrote:
Use new APIs to dynamically allocate the thp-zero and thp-deferred_split
shrinkers.
Signed-off-by: Qi Zheng
---
mm/huge_memory.c | 69 +++-
1 file changed, 45 insertio
On 2023/7/26 15:13, Muchun Song wrote:
On Jul 24, 2023, at 17:43, Qi Zheng wrote:
Use new APIs to dynamically allocate the mm-shadow shrinker.
Signed-off-by: Qi Zheng
---
mm/workingset.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/mm/w
Hi,
On 26/07/2023 09:44, Juergen Gross wrote:
On 26.07.23 10:20, Julien Grall wrote:
To give a concrete example, with the current interface we are telling
the user that what they store in the hashtable can be modified at some
point. By adding 'const' for the value in hashtable_add(), we can
m
On 2023/7/26 15:24, Muchun Song wrote:
On 2023/7/24 17:43, Qi Zheng wrote:
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the drm-msm_gem shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read
> On Jul 24, 2023, at 17:43, Qi Zheng wrote:
>
> Currently, we maintain two linear arrays per node per memcg, which are
> shrinker_info::map and shrinker_info::nr_deferred. And we need to resize
> them when the shrinker_nr_max is exceeded, that is, allocate a new array,
> and then copy the old
On 2023/7/26 15:32, Muchun Song wrote:
On 2023/7/24 17:43, Qi Zheng wrote:
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the md-bcache shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-s
Make function declaration and definition consistent using the same
parameter name ('mcs' do denote a pointer to an 'mc_state').
This addresses a violation of MISRA C:2012 Rule 8.3: "All declarations
of an object or function shall use the same names and type qualifiers".
Signed-off-by: Federico Ser
On Wed, Jul 26, 2023 at 01:17:58AM +, Volodymyr Babchuk wrote:
>
> Hi Roger,
>
> Roger Pau Monné writes:
>
> > On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
> >> From: Oleksandr Andrushchenko
> >> @@ -498,6 +537,7 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg,
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 26.07.2023 11:34, Federico Serafini wrote:
> Make function declaration and definition consistent using the same
> parameter name ('mcs' do denote a pointer to an 'mc_state').
> This addresses a violation of MISRA C:2012 Rule 8.3: "All declarations
> of an object or function shall use the same na
On Wed, Jul 19, 2023 at 12:37:47PM +0200, Jan Beulich wrote:
> On 18.07.2023 14:43, Roger Pau Monne wrote:
> > @@ -439,36 +427,47 @@ unsigned int cf_check io_apic_read_remap_rte(
> > }
> >
> > void cf_check io_apic_write_remap_rte(
> > -unsigned int apic, unsigned int reg, unsigned int valu
On 2023/7/12 18:29, 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
in such use cases.
Add --e
flight 182004 libvirt real [real]
flight 182020 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182004/
http://logs.test-lab.xenproject.org/osstest/logs/182020/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-li
As discussed in Prague, with some minor add-ons (patch 2 replacing a much
older patch under the same title).
v3 addresses issues found as well as review feedback; see individual
patches for details. Patch 3 in particular continues to raises several
questions as well, though.
1: build: make cc-opt
In options like -march=, it may be only the sub-option which is
unrecognized by the compiler. In such an event the error message often
splits option and argument, typically saying something like "bad value
'' for ''. Extend the grep invocation accordingly,
also accounting for Clang to not mention e
Some options we allow the build admin to select may require new enough
tool chain components to fulfill (partly or entirely). Provide yet
another control to pick what action to take at the end of the build
process - be silent about this, warn, or fail the build.
Signed-off-by: Jan Beulich
---
Thi
Newer hardware offers more efficient and/or flexible and/or capable
instructions, some of which we can make good use of in the hypervisor
as well. Allow a basic way (no alternatives patching) of enabling their
use. Of course this means that hypervisors thus built won't work
anymore on older, less c
This is faster than using the software implementation, and the insn is
available on all half-way recent hardware. Use the respective compiler
builtins when available.
Signed-off-by: Jan Beulich
Reviewed-by: Jason Andryuk
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bit
Certain fallback code can be made subject to DCE this way. Note that
CX16 has no compiler provided manifest constant, so CONFIG_* are used
there instead. Note also that we don't have cpu_has_movbe nor
cpu_has_lzcnt (aka cpu_has_abm).
Signed-off-by: Jan Beulich
---
Of course we could use IS_ENABLE
While what "tmp" points to has been cleared at the end of the first
iteration of parseNetDevLine()'s main loop, this is too late for the
first iteration's invocation of strpbrk() (copying the interface name).
Properly nul-terminate the string at population time instead, removing
the late clearing.
From: Gianluca Luparini
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type.
For the sake of unifo
From: Gianluca Luparini
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
liter
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose headline
states:
"A 'u' or 'U' suffix shall be applied to all integer constants that are
represented in an unsigned type".
These violations are caused by the missing "u" or "U" suffix in unsigned
integer constants, such as:
xen/ar
From: Gianluca Luparini
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
liter
From: Gianluca Luparini
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type.
Use _AC() for macro co
On 26.07.23 11:29, Julien Grall wrote:
Hi,
On 26/07/2023 09:44, Juergen Gross wrote:
On 26.07.23 10:20, Julien Grall wrote:
To give a concrete example, with the current interface we are telling the
user that what they store in the hashtable can be modified at some point. By
adding 'const' for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2023-20593 / XSA-433
version 2
x86/AMD: Zenbleed
UPDATES IN VERSION 2
Include the CVE, which was missed accidentally in the rush of
Hi all,
I would like to ask for advice on whether it would be easier, less bug-
provoking ( during identity mapping to remove of whole Xen ) to have a
separate identity section that won't be more than PAGE_SIZE.
Please take a look at the changes below. Comments are welcome.
diff --git a/xen/arch
flight 182016 xen-4.17-testing real [real]
flight 182022 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182016/
http://logs.test-lab.xenproject.org/osstest/logs/182022/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 26.07.2023 13:23, Oleksii wrote:
> I would like to ask for advice on whether it would be easier, less bug-
> provoking ( during identity mapping to remove of whole Xen ) to have a
> separate identity section that won't be more than PAGE_SIZE.
I'm afraid you can't safely do this in C, or at leas
On 26.07.2023 13:03, Simone Ballarin wrote:
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose headline
> states:
> "A 'u' or 'U' suffix shall be applied to all integer constants that are
> represented in an unsigned type".
>
> These violations are caused by the missing "u" or "U
Il giorno mer 26 lug 2023 alle ore 14:02 Jan Beulich ha
scritto:
> On 26.07.2023 13:03, Simone Ballarin wrote:
> > The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline
> > states:
> > "A 'u' or 'U' suffix shall be applied to all integer constants that are
> > represented
On 24.07.2023 17:37, Roger Pau Monne wrote:
> @@ -1184,6 +1177,20 @@ int __init dom0_construct_pvh(struct domain *d, const
> module_t *image,
>
> printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id);
>
> +if ( is_hardware_domain(d) )
> +{
> +/*
> + *
Further changes will require access to the full RTE as a single value
in order to pass it to IOMMU interrupt remapping handlers.
No functional change intended.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
---
Changes since v1:
- Fix initializers.
---
Tested on gitlab CI, builds on all
Hello,
Following series attempts to solve the issue with IO-APIC edge triggered
interrupts seeing an inconsistent IRTE when injected while being
migrated.
It's been simplified a bit from the original RFC, and does make the
logic in the IOMMU RTE update handlers cleaner, as those get passed the
fu
Do not allow to write to RTE registers using io_apic_write and instead
require changes to RTE to be performed using ioapic_write_entry.
This is in preparation for passing the full contents of the RTE to the
IOMMU interrupt remapping handlers, so remapping entries for IO-APIC
RTEs can be updated at
So that the remapping entry can be updated atomically when possible.
Doing such update atomically will avoid Xen having to mask the IO-APIC
pin prior to performing any interrupt movements (ie: changing the
destination and vector fields), as the interrupt remapping entry is
always consistent.
This
Preparatory change to unify the IO-APIC pin variable name between
io_apic_read_remap_rte() and amd_iommu_ioapic_update_ire(), so that
the local variable can be made a function parameter with the same name
across vendors.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
flight 182006 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182006/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 181952
test-armhf-armhf-libvirt-qcow2 15 s
On Wed, 2023-07-26 at 13:58 +0200, Jan Beulich wrote:
> On 26.07.2023 13:23, Oleksii wrote:
> > I would like to ask for advice on whether it would be easier, less
> > bug-
> > provoking ( during identity mapping to remove of whole Xen ) to
> > have a
> > separate identity section that won't be more
On Wed, Jul 26, 2023 at 02:36:17PM +0200, Jan Beulich wrote:
> On 24.07.2023 17:37, Roger Pau Monne wrote:
> > @@ -1184,6 +1177,20 @@ int __init dom0_construct_pvh(struct domain *d,
> > const module_t *image,
> >
> > printk(XENLOG_INFO "*** Building a PVH Dom%d ***\n", d->domain_id);
> >
Change parameter name from 'flag' to 'taint' for consistency with
the corresponding declaration.
This addresses 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: Federico Serafini
Just like it's done for the XEN_DOMCTL_memory_mapping hypercall, add
the permissions checks to vPCI map_range(), which is used to map the
BARs into the domain p2m.
Adding those checks requires that for x86 PVH hardware domain builder
the permissions are set before initializing the IOMMU, or else
a
On 26.07.2023 15:37, Roger Pau Monné wrote:
> On Wed, Jul 26, 2023 at 02:36:17PM +0200, Jan Beulich wrote:
>> Another Dom0 related concern can probably be put off until we actually
>> get a report of this failing (which may be more likely because of the
>> XSM check below): The function being used
From: Oleksandr Tyshchenko
Without it being present it won't be possible to use some
libxl__device_type's callbacks for virtio devices as the common code
can only invoke these callbacks (by dereferencing a pointer) for valid
libxl__device_type's elements when iterating over device_type_tbl[].
Si
On Mon, Jul 24, 2023 at 09:41:36PM -0700, Hugh Dickins wrote:
> On Mon, 24 Jul 2023, Vishal Moola (Oracle) wrote:
>
> > The MM subsystem is trying to shrink struct page. This patchset
> > introduces a memory descriptor for page table tracking - struct ptdesc.
> >
> > This patchset introduces ptde
On 26.07.2023 16:14, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Without it being present it won't be possible to use some
> libxl__device_type's callbacks for virtio devices as the common code
> can only invoke these callbacks (by dereferencing a pointer) for valid
> libxl__devi
On 26.07.2023 15:58, Federico Serafini wrote:
> Change parameter name from 'flag' to 'taint' for consistency with
> the corresponding declaration.
> This addresses a violation of MISRA C:2012 Rule 8.3: "All declarations
> of an object or function shall use the same names and type qualifiers".
>
>
On 26.07.2023 16:01, Roger Pau Monne wrote:
> Just like it's done for the XEN_DOMCTL_memory_mapping hypercall, add
> the permissions checks to vPCI map_range(), which is used to map the
> BARs into the domain p2m.
>
> Adding those checks requires that for x86 PVH hardware domain builder
> the perm
On 26.07.2023 15:12, Oleksii wrote:
> On Wed, 2023-07-26 at 13:58 +0200, Jan Beulich wrote:
>> On 26.07.2023 13:23, Oleksii wrote:
>>> I would like to ask for advice on whether it would be easier, less
>>> bug-
>>> provoking ( during identity mapping to remove of whole Xen ) to
>>> have a
>>> separ
On 26.07.23 17:50, Jan Beulich wrote:
Hello Jan
> On 26.07.2023 16:14, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Without it being present it won't be possible to use some
>> libxl__device_type's callbacks for virtio devices as the common code
>> can only invoke these cal
flight 182024 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182024/
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 Mon, 2023-07-10 at 10:58 +0200, Jan Beulich wrote:
> On 10.07.2023 10:56, Jan Beulich wrote:
> > Use the generic framework in xen/linkage.h. No change in generated
> > code
> > except of course the converted symbols change to be hidden ones and
> > gain
> > a valid size.
> >
> > Signed-off-by:
On 24.07.2023 17:06, Shawn Anastasio wrote:
> On 7/24/23 7:40 AM, Jan Beulich wrote:
>> On 21.07.2023 19:02, Shawn Anastasio wrote:
>>> On typical Power VMs (e.g. QEMU's -M pseries), a variety of services
>>> including an early serial console are provided by Open Firmware.
>>> Implement the require
Hi Roger,
> On 26 Jul 2023, at 3:01 pm, Roger Pau Monne wrote:
>
> Just like it's done for the XEN_DOMCTL_memory_mapping hypercall, add
> the permissions checks to vPCI map_range(), which is used to map the
> BARs into the domain p2m.
>
> Adding those checks requires that for x86 PVH hardware d
On 7/26/23 10:32 AM, Jan Beulich wrote:
> On 24.07.2023 17:06, Shawn Anastasio wrote:
>> On 7/24/23 7:40 AM, Jan Beulich wrote:
>>> On 21.07.2023 19:02, Shawn Anastasio wrote:
On typical Power VMs (e.g. QEMU's -M pseries), a variety of services
including an early serial console are provid
On 26.07.2023 17:28, Oleksii wrote:
> On Mon, 2023-07-10 at 10:58 +0200, Jan Beulich wrote:
>> On 10.07.2023 10:56, Jan Beulich wrote:
>>> Use the generic framework in xen/linkage.h. No change in generated
>>> code
>>> except of course the converted symbols change to be hidden ones and
>>> gain
>>>
On 26.07.2023 17:42, Shawn Anastasio wrote:
> On 7/26/23 10:32 AM, Jan Beulich wrote:
>> On 24.07.2023 17:06, Shawn Anastasio wrote:
>>> On 7/24/23 7:40 AM, Jan Beulich wrote:
On 21.07.2023 19:02, Shawn Anastasio wrote:
> On typical Power VMs (e.g. QEMU's -M pseries), a variety of services
On 7/26/23 10:45 AM, Jan Beulich wrote:
> On 26.07.2023 17:42, Shawn Anastasio wrote:
>> On 7/26/23 10:32 AM, Jan Beulich wrote:
>>> On 24.07.2023 17:06, Shawn Anastasio wrote:
On 7/24/23 7:40 AM, Jan Beulich wrote:
> On 21.07.2023 19:02, Shawn Anastasio wrote:
>> On typical Power VMs
1 - 100 of 143 matches
Mail list logo
