On Mon, Dec 11, 2023 at 12:15:17AM +0800, Jiqian Chen wrote:
> When device on dom0 side has been reset, the vpci on Xen side
> won't get notification, so that the cached state in vpci is
> all out of date with the real device state.
> To solve that problem, add a new function to clear all vpci
> de
On 11.12.2023 20:40, Oleksii wrote:
> On Mon, 2023-12-11 at 18:49 +0100, Jan Beulich wrote:
>> On 11.12.2023 18:37, Oleksii wrote:
>>> On Mon, 2023-12-11 at 17:02 +0100, Jan Beulich wrote:
In which case the approach taken here may be fine, but
it still wouldn't be what I suggested. It ma
On Fri, Dec 08, 2023 at 04:02:25PM +, Anthony PERARD wrote:
> This is following a failure to build "arch/x86/xen/enlighten.c" in
> build-i386-pvops jobs with linux 968f35f4ab1c ("Merge tag
> 'v6.7-rc3-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6")
> in linux-linus branch.
Could w
On 12.12.23 09:38, Roger Pau Monné wrote:
On Fri, Dec 08, 2023 at 04:02:25PM +, Anthony PERARD wrote:
This is following a failure to build "arch/x86/xen/enlighten.c" in
build-i386-pvops jobs with linux 968f35f4ab1c ("Merge tag
'v6.7-rc3-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-
On Tue, Dec 12, 2023 at 06:16:43AM +, Chen, Jiqian wrote:
> On 2023/12/11 23:45, Roger Pau Monné wrote:
> > On Wed, Dec 06, 2023 at 06:07:26AM +, Chen, Jiqian wrote:
> >>
> >> When PVH dom0 enable a device, it will get trigger and polarity from ACPI
> >> (see acpi_pci_irq_enable)
> >> I ha
On 2023-12-12 02:42, Stefano Stabellini wrote:
On Mon, 11 Dec 2023, Nicola Vetrini wrote:
The "return 0" after the swich statement in 'xen/arch/x86/mm.c'
is unreachable because all switch clauses end with returns.
However, some of them can be substituted with "break"s to allow
the "return 0" out
On Tue, Dec 12, 2023 at 06:34:27AM +, Chen, Jiqian wrote:
>
> On 2023/12/12 01:57, Roger Pau Monné wrote:
> > On Mon, Dec 11, 2023 at 12:15:19AM +0800, Jiqian Chen wrote:
> >> There is a need for some scenarios to use gsi sysfs.
> >> For example, when xen passthrough a device to dumU, it will
Hi David,
I appreciate your concerns, and I agree that the community like any other
open source project has room for improvement.
It's great to hear that you want to contribute and we're trying to make
this easier for all within the project. As such, we are in the process of
setting up a TAB to he
Hi Stefano,
On 12/12/2023 01:36, Stefano Stabellini wrote:
On Mon, 11 Dec 2023, Nicola Vetrini wrote:
On 2023-12-11 17:05, Julien Grall wrote:
On 11/12/2023 15:59, Julien Grall wrote:
Hi Nicola,
On 11/12/2023 14:54, Nicola Vetrini wrote:
On 2023-12-11 13:32, Julien Grall wrote:
Hi,
On 11/
On 12.12.2023 07:49, Chen, Jiqian wrote:
> On 2023/12/11 23:31, Roger Pau Monné wrote:
>> On Mon, Dec 11, 2023 at 12:40:08AM +0800, Jiqian Chen wrote:
>>> --- a/xen/arch/x86/hvm/hypercall.c
>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>> @@ -72,8 +72,11 @@ long hvm_physdev_op(int cmd,
>>> XEN_GUEST_HAN
(I think the Cc list is too long here, but then I don't know who to
keep and who to possibly drop.)
On 12.12.2023 09:49, Roger Pau Monné wrote:
> On Tue, Dec 12, 2023 at 06:16:43AM +, Chen, Jiqian wrote:
>> On 2023/12/11 23:45, Roger Pau Monné wrote:
>>> On Wed, Dec 06, 2023 at 06:07:26AM +000
flight 184096 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184096/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 183973
Tests which did not
Hi,
We were experiencing a crash during PV domU boot on several different models
of hardware but all with Intel CPUs. The Xen version was based on stable-4.15
at 4a4daf6bddbe8a741329df5cc8768f7dec664aed (XSA-444) with some local
patches. Since updating the branch to b918c4cdc7ab2c1c9e9a9b54fa9d9
On 11.12.2023 11:30, Nicola Vetrini wrote:
> Given that 'hwdom_shutdown' is a noreturn function, unreachable
> breaks can be eliminated to resolve violations of Rule 2.1.
> On the occasion, the type of its parameter is changed to uint8_t.
I don't particularly mind that extra change, but it's entir
Instead of being able to use normal spinlocks as recursive ones, too,
make recursive spinlocks a special lock type.
This will make the spinlock structure smaller in production builds and
add type-safety.
This allows to increase the maximum number of physical cpus from 8191
to 65535 without increa
Use named member initializers instead of positional ones for the macros
used to initialize structures.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
V2:
- new patch
---
xen/include/xen/spinlock.h | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/xen/i
With some small adjustments to the LOCK_PROFILE_* macros some #ifdefs
can be dropped from spinlock.c.
Signed-off-by: Juergen Gross
Reviewed-by: Alejandro Vallejo
---
V2:
- new patch
V3:
- add variable name to macros parameter (Jan Beulich)
V4:
- fix coding style issue (Alejandro Vallejo)
---
xe
Rename the recursive spin_lock() functions by replacing the trailing
"_recursive" with a leading "r".
Switch the parameter to be a pointer to rspinlock_t.
Remove the indirection through a macro, as it is adding only complexity
without any gain.
Suggested-by: Jan Beulich
Signed-off-by: Juergen G
Introduce a new type "rspinlock_t" to be used for recursive spinlocks.
For now it is only an alias of spinlock_t, so both types can still be
used for recursive spinlocks. This will be changed later, though.
Switch all recursive spinlocks to the new type.
Define the initializer helpers and use th
Struct lock_profile contains a pointer to the spinlock it is associated
with. Prepare support of differing spinlock_t and rspinlock_t types by
adding a type indicator of the pointer. Use the highest bit of the
block_cnt member for this indicator in order to not grow the struct
while hurting only th
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handling and use them where needed.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
xen/arch/x86/traps.c | 14 --
xen/common/spinlock.c |
Add another function level in spinlock.c hiding the spinlock_t layout
from the low level locking code.
This is done in preparation of introducing rspinlock_t for recursive
locks without having to duplicate all of the locking code.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
xen/common/
Recursive and normal spinlocks are sharing the same data structure for
representation of the lock. This has two major disadvantages:
- it is not clear from the definition of a lock, whether it is intended
to be used recursive or not, while a mixture of both usage variants
needs to be
- in pro
In order to prepare a type-safe recursive spinlock structure, add
explicitly non-recursive locking functions to be used for non-recursive
locking of spinlocks, which are used recursively, too.
Signed-off-by: Juergen Gross
---
V2:
- rename functions (Jan Beulich)
- get rid of !! in pcidevs_locked(
Add rspin_is_locked() and rspin_barrier() in order to prepare differing
spinlock_t and rspinlock_t types.
Signed-off-by: Juergen Gross
---
V2:
- partially carved out from V1 patch, partially new
---
xen/arch/x86/mm/p2m-pod.c | 2 +-
xen/common/domain.c | 2 +-
xen/common/page_all
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing only the size of
recursive spinlocks in debug builds from 8 to 12 bytes.
Signed-off-by: Juergen Gross
---
xen/common/spinlock.c | 1 +
xen/include/xen/spinloc
On 2023-12-12 10:45, Jan Beulich wrote:
On 11.12.2023 11:30, Nicola Vetrini wrote:
Given that 'hwdom_shutdown' is a noreturn function, unreachable
breaks can be eliminated to resolve violations of Rule 2.1.
On the occasion, the type of its parameter is changed to uint8_t.
I don't particularly
On 12.12.2023 10:12, Nicola Vetrini wrote:
> On 2023-12-12 02:42, Stefano Stabellini wrote:
>> On Mon, 11 Dec 2023, Nicola Vetrini wrote:
>>> The "return 0" after the swich statement in 'xen/arch/x86/mm.c'
>>> is unreachable because all switch clauses end with returns.
>>> However, some of them can
In reality all spin_*() functions are macros which are defined to just
call a related real function.
Remove this macro layer, as it is adding complexity without any gain.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
xen/common/spinlock.c | 28 +-
xen/include/xen/spi
On 11.12.2023 11:30, Nicola Vetrini wrote:
> The string literal inside the expansion of BUILD_BUG_ON is considered
> unreachable code; however, such statement can be moved earlier
> with no functional change.
First: Why is this deemed dead code in its present position, but okay when
moved? Second:
On 12.12.2023 11:04, Jan Beulich wrote:
> On 11.12.2023 11:30, Nicola Vetrini wrote:
>> The string literal inside the expansion of BUILD_BUG_ON is considered
>> unreachable code; however, such statement can be moved earlier
>> with no functional change.
>
> First: Why is this deemed dead code in i
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing only the size of
recursive spinlocks in debug builds from 8 to 12 bytes.
Looking at arch/Kconfig, it looks lik
On 11.12.2023 11:30, Nicola Vetrini wrote:
> The break statement is redundant, hence it can be removed.
Except ...
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -723,7 +723,6 @@ ret_t do_platform_op(
>
> ret = continue_hypercall_on_cpu(
>
Hi,
On 12/12/2023 06:26, Juergen Gross wrote:
On 11.12.23 20:11, Julien Grall wrote:
Hi Juergen,
On 23/11/2023 16:08, Juergen Gross wrote:
Today write_messages() will call trace_io() after having written the
complete message to the ring buffer or socket.
In case the message can't be written
On 12.12.2023 10:53, Nicola Vetrini wrote:
> On 2023-12-12 10:45, Jan Beulich wrote:
>> On 11.12.2023 11:30, Nicola Vetrini wrote:
>>> @@ -38,39 +38,32 @@ void hwdom_shutdown(u8 reason)
>>> printk("Hardware Dom%u halted: halting machine\n",
>>> hardware_domain->domain_id);
On 12/12/2023 9:43 am, James Dingwall wrote:
> Hi,
>
> We were experiencing a crash during PV domU boot on several different models
> of hardware but all with Intel CPUs. The Xen version was based on stable-4.15
> at 4a4daf6bddbe8a741329df5cc8768f7dec664aed (XSA-444) with some local
> patches. Si
The procedure used to customize the domain CPU policy is broken when
toolstack tries to set leaves (with subleaves) that the hypervisor didn't
need to serialise (i.e: because they where empty subleaves).
During typical domain creation xg does the following:
1. Probe Xen for max #leaves that a p
On Fri, Dec 08, 2023 at 04:02:23PM +, Anthony PERARD wrote:
> CONFIG_X86_GENERIC=y and fixes around arch specific config values.
>
> Thanks,
>
> Anthony PERARD (3):
> create_build_jobs: Set reset pvops_kconfig_overrides
> create_build_jobs: Enable X86_GENERIC for i386 kernel pvops jobs.
>
On 12.12.23 11:10, Julien Grall wrote:
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing only the size of
recursive spinlocks in debug builds from 8 to 12 byte
On Tue, Dec 12, 2023 at 10:38:08AM +0100, Jan Beulich wrote:
> (I think the Cc list is too long here, but then I don't know who to
> keep and who to possibly drop.)
>
> On 12.12.2023 09:49, Roger Pau Monné wrote:
> > On Tue, Dec 12, 2023 at 06:16:43AM +, Chen, Jiqian wrote:
> >> On 2023/12/11
On 12.12.2023 12:18, Roger Pau Monné wrote:
> On Tue, Dec 12, 2023 at 10:38:08AM +0100, Jan Beulich wrote:
>> (I think the Cc list is too long here, but then I don't know who to
>> keep and who to possibly drop.)
>>
>> On 12.12.2023 09:49, Roger Pau Monné wrote:
>>> On Tue, Dec 12, 2023 at 06:16:43
On Tue, Dec 12, 2023 at 12:19:49PM +0100, Jan Beulich wrote:
> On 12.12.2023 12:18, Roger Pau Monné wrote:
> > On Tue, Dec 12, 2023 at 10:38:08AM +0100, Jan Beulich wrote:
> >> (I think the Cc list is too long here, but then I don't know who to
> >> keep and who to possibly drop.)
> >>
> >> On 12.1
Hi Juergen,
On 12/12/2023 11:09, Juergen Gross wrote:
On 12.12.23 11:10, Julien Grall wrote:
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing only the size
Hi Juergen,
On 11/12/2023 13:16, Juergen Gross wrote:
Update Xen's unaligned.h header to support all architectures, allowing
to remove the architecture specific variants (x86 only until now).
Changes in V2:
- new patch 1 (Julien Grall)
- adjusted patch 2 (Jan Beulich)
Changes in V3:
- adjusted
On 07/12/2023 18:46, Julien Grall wrote:
Hi,
On 07/12/2023 16:20, Henry Wang wrote:
I've finished the opportunity to do two releases (4.17 and 4.18)
and Oleksii Kurochko has volunteered to be the next release manager.
Henry, thanks for your time as release manager.
Oleksii, thanks for step
On 11/12/2023 14:54, Federico Serafini wrote:
Both smmu and smmu-v3 (ported from Linux) define the typedef name
"phys_addr_t": move the type definition to the common header
linux-compat.h to address violations of MISRA C:2012 Rule 5.6
("A typedef name shall be a unique identifier").
No functio
On Tue, Dec 12, 2023 at 09:48:46AM +0100, Juergen Gross wrote:
> On 12.12.23 09:38, Roger Pau Monné wrote:
> > On Fri, Dec 08, 2023 at 04:02:25PM +, Anthony PERARD wrote:
> > > This is following a failure to build "arch/x86/xen/enlighten.c" in
> > > build-i386-pvops jobs with linux 968f35f4ab1c
On 12.12.23 12:56, Anthony PERARD wrote:
On Tue, Dec 12, 2023 at 09:48:46AM +0100, Juergen Gross wrote:
On 12.12.23 09:38, Roger Pau Monné wrote:
On Fri, Dec 08, 2023 at 04:02:25PM +, Anthony PERARD wrote:
This is following a failure to build "arch/x86/xen/enlighten.c" in
build-i386-pvops
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2023-46837 / XSA-447
version 2
arm32: The cache may not be properly cleaned/invalidated (take two)
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
On 12.12.23 12:40, Julien Grall wrote:
Hi Juergen,
On 12/12/2023 11:09, Juergen Gross wrote:
On 12.12.23 11:10, Julien Grall wrote:
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 655
Hi,
On 12/12/2023 12:11, Juergen Gross wrote:
On 12.12.23 12:40, Julien Grall wrote:
Hi Juergen,
On 12/12/2023 11:09, Juergen Gross wrote:
On 12.12.23 11:10, Julien Grall wrote:
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed b
Hi,
On 12/12/2023 09:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing only the size of
recursive spinlocks in debug builds from 8 to 12 bytes.
Signed-off-by: Juergen Gross
---
xen/comm
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
With some small adjustments to the LOCK_PROFILE_* macros some #ifdefs
can be dropped from spinlock.c.
Signed-off-by: Juergen Gross
Reviewed-by: Alejandro Vallejo
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Pipeline #1103837091 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: cf40abbc (
https://gitlab.com/xen-project/xen/-/commit/cf40abbc7ff2a73eaaea84e919fc7762354e75ad
)
Commit Message: tools/xenstor
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 1cd9120eac..20d15f34dd 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -45,7 +45,7 @@ union lock_debug { };
lock profiling on:
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
Rename the recursive spin_lock() functions by replacing the trailing
"_recursive" with a leading "r".
Switch the parameter to be a pointer to rspinlock_t.
Remove the indirection through a macro, as it is adding only complexity
without any g
On 12.12.23 13:57, Julien Grall wrote:
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 1cd9120eac..20d15f34dd 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -45,7 +45,7 @@ union lock_de
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handling and use them where needed.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
xen/arch/x86/traps
Hi Juergen,
On 12/12/2023 13:04, Juergen Gross wrote:
On 12.12.23 13:57, Julien Grall wrote:
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 1cd9120eac..20d15f34dd 100644
--- a/xen/include/xen/spinlock.h
+++ b/xe
On 12.12.23 13:39, Julien Grall wrote:
Hi,
On 12/12/2023 09:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing only the size of
recursive spinlocks in debug builds from 8 to 12 bytes.
Sign
On Mon, Dec 11, 2023 at 05:52:17PM +0100, Jan Kara wrote:
> > +void bdev_associated_mapping(struct block_device *bdev,
> > +struct address_space *mapping)
> > +{
> > + mapping->host = bdev->bd_inode;
> > +}
>
> Here I'm not sure - is the helper really a win? It seems a bi
> +void invalidate_bdev_range(struct block_device *bdev, pgoff_t start,
> +pgoff_t end)
> +{
> + invalidate_mapping_pages(bdev->bd_inode->i_mapping, start, end);
> +}
> +EXPORT_SYMBOL_GPL(invalidate_bdev_range);
Can we have kerneldoc comments for the new helpers please?
flight 184103 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184103/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cee7ba349c0c1ce489001a338a4e28555728b573
baseline version:
ovmf 725acd0b9cc047b20a1b9
Looks good:
Reviewed-by: Christoph Hellwig
On Mon, Dec 11, 2023 at 10:07:53PM +0800, Yu Kuai wrote:
> +static __always_inline int buffer_uptodate_or_error(struct buffer_head *bh)
> +{
> + /*
> + * If the buffer has the write error flag, data was failed to write
> + * out in the block. In this case, set buffer uptodate to preve
On 2023-12-12 11:07, Jan Beulich wrote:
On 12.12.2023 11:04, Jan Beulich wrote:
On 11.12.2023 11:30, Nicola Vetrini wrote:
The string literal inside the expansion of BUILD_BUG_ON is considered
unreachable code; however, such statement can be moved earlier
with no functional change.
First: Why
flight 184102 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184102/
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 12.12.2023 14:38, Nicola Vetrini wrote:
> On 2023-12-12 11:07, Jan Beulich wrote:
>> On 12.12.2023 11:04, Jan Beulich wrote:
>>> On 11.12.2023 11:30, Nicola Vetrini wrote:
The string literal inside the expansion of BUILD_BUG_ON is considered
unreachable code; however, such statement ca
On 12/12/2023 13:08, Juergen Gross wrote:
On 12.12.23 13:39, Julien Grall wrote:
Hi,
On 12/12/2023 09:47, Juergen Gross wrote:
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing only the size of
recursive spinl
On 2023-12-12 15:01, Jan Beulich wrote:
On 12.12.2023 14:38, Nicola Vetrini wrote:
On 2023-12-12 11:07, Jan Beulich wrote:
On 12.12.2023 11:04, Jan Beulich wrote:
On 11.12.2023 11:30, Nicola Vetrini wrote:
The string literal inside the expansion of BUILD_BUG_ON is
considered
unreachable code
On Tue 12-12-23 05:25:25, Christoph Hellwig wrote:
> On Mon, Dec 11, 2023 at 10:07:53PM +0800, Yu Kuai wrote:
> > +static __always_inline int buffer_uptodate_or_error(struct buffer_head *bh)
> > +{
> > + /*
> > +* If the buffer has the write error flag, data was failed to write
> > +* out
On 12.12.23 14:03, Julien Grall wrote:
Hi Juergen,
On 12/12/2023 09:47, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handling and use them where needed.
Signed-off-by: Juergen Gross
---
On Fri, Dec 08, 2023 at 02:49:27PM -0800, Stefano Stabellini wrote:
> On Fri, 8 Dec 2023, Daniel P. Berrangé wrote:
> > On Thu, Dec 07, 2023 at 11:12:48PM +, Michael Young wrote:
> > > Builds of qemu-8.2.0rc2 with xen-4.18.0 are currently failing
> > > with errors like
> > > ../hw/arm/xen_arm.c
On Tue, 12 Dec 2023 at 14:20, Anthony PERARD wrote:
> Building qemu with something like:
> ./configure --enable-xen --cpu=x86_64
> used to work. Can we fix that? It still works with v8.1.0.
> At least, it works on x86, I never really try to build qemu for arm.
> Notice that there's no "--targe
flight 184099 libvirt real [real]
flight 184104 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184099/
http://logs.test-lab.xenproject.org/osstest/logs/184104/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-li
Hi Anthony
Anthony PERARD writes:
> On Fri, Dec 08, 2023 at 02:49:27PM -0800, Stefano Stabellini wrote:
>> On Fri, 8 Dec 2023, Daniel P. Berrangé wrote:
>> > On Thu, Dec 07, 2023 at 11:12:48PM +, Michael Young wrote:
>> > > Builds of qemu-8.2.0rc2 with xen-4.18.0 are currently failing
>> > >
This patch series adds the missing parameter names to address violations of
MISRA C:2012 Rule 8.2. No functional changes are introduced.
Federico Serafini (4):
xen/compat: address violations of MISRA C:2012 Rule 8.2
x86/asm: address violations of MISRA C:2012 Rule 8.2
xen/drivers: address vi
Add missing parameter names. No functional change.
Signed-off-by: Federico Serafini
---
xen/include/xen/compat.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h
index 41a5d61eef..7ec9d6567e 100644
--- a/xen/include/xen/
Add missing parameter name. No functional change.
Signed-off-by: Federico Serafini
---
xen/include/xen/iommu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 69d572543c..f53d045e2c 100644
--- a/xen/include/xen/iommu.h
+
Add missing parameter names. No functional change.
Signed-off-by: Federico Serafini
---
xen/drivers/char/ehci-dbgp.c | 4 ++--
xen/drivers/video/vga.c | 2 +-
xen/include/xen/video.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/drivers/char/ehci-dbgp.c b/x
Add missing parameter names. No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/include/asm/amd.h | 2 +-
xen/arch/x86/include/asm/debugreg.h | 4 ++--
xen/arch/x86/include/asm/flushtlb.h | 3 ++-
xen/arch/x86/include/asm/hap.h | 2 +-
xen/arch/x86/include/asm/
The name "iothread" is overloaded. Use the term Big QEMU Lock (BQL)
instead, it is already widely used and unambiguous.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Cédric Le Goater
Reviewed-by: Philippe Mathieu-Daudé
---
include/qemu/main-loop.h | 10 +-
accel/tcg/tcg-accel-op
v2:
- Rename APIs bql_*() [PeterX]
- Spell out "Big QEMU Lock (BQL)" in doc comments [PeterX]
- Rename "iolock" variables in hw/remote/mpqemu-link.c [Harsh]
- Fix bql_auto_lock() indentation in Patch 2 [Ilya]
- "with BQL taken" -> "with the BQL taken" [Philippe]
- "under BQL" -> "under the BQL" [Ph
The Big QEMU Lock (BQL) has many names and they are confusing. The
actual QemuMutex variable is called qemu_global_mutex but it's commonly
referred to as the BQL in discussions and some code comments. The
locking APIs, however, are called qemu_mutex_lock_iothread() and
qemu_mutex_unlock_iothread().
The term "iothread lock" is obsolete. The APIs use Big QEMU Lock (BQL)
in their names. Update the code comments to use "BQL" instead of
"iothread lock".
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Philippe Mathieu-Daudé
---
docs/devel/reset.rst | 2 +-
hw/display/qxl.h
The name "iothread" is overloaded. Use the term Big QEMU Lock (BQL)
instead, it is already widely used and unambiguous.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Paul Durrant
Acked-by: David Woodhouse
Reviewed-by: Cédric Le Goater
Acked-by: Ilya Leoshkevich
---
include/qemu/main-loop.h |
The term "QEMU global mutex" is identical to the more widely used Big
QEMU Lock ("BQL"). Update the code comments and documentation to use
"BQL" instead of "QEMU global mutex".
Signed-off-by: Stefan Hajnoczi
Acked-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
---
docs/devel/multi-t
On 12/12/2023 11:44, Julien Grall wrote:
Hi Juergen,
On 11/12/2023 13:16, Juergen Gross wrote:
Update Xen's unaligned.h header to support all architectures, allowing
to remove the architecture specific variants (x86 only until now).
Changes in V2:
- new patch 1 (Julien Grall)
- adjusted pat
On Sat, Dec 02, 2023 at 01:41:22AM +, Volodymyr Babchuk wrote:
> diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
> index 9f9f137f99..03a55f345c 100644
> --- a/hw/xenpv/xen_machine_pv.c
> +++ b/hw/xenpv/xen_machine_pv.c
> @@ -37,7 +37,9 @@ static void xen_init_pv(MachineState
On Tue, 12 Dec 2023 at 10:36, Volodymyr Babchuk
wrote:
>
> Hi Anthony
>
> Anthony PERARD writes:
>
> > On Fri, Dec 08, 2023 at 02:49:27PM -0800, Stefano Stabellini wrote:
> >> On Fri, 8 Dec 2023, Daniel P. Berrangé wrote:
> >> > On Thu, Dec 07, 2023 at 11:12:48PM +, Michael Young wrote:
> >>
Hi,
On 11/12/2023 12:32, Julien Grall wrote:
Hi,
On 11/12/2023 10:30, Nicola Vetrini wrote:
The branches of the switch after a call to 'do_unexpected_trap'
cannot return, but there is one path that may return, hence
only some clauses are marked with ASSERT_UNREACHABLE().
I don't understand why
On Tue, Dec 12, 2023 at 03:35:50PM +, Volodymyr Babchuk wrote:
> Hi Anthony
>
> Anthony PERARD writes:
>
> > On Fri, Dec 08, 2023 at 02:49:27PM -0800, Stefano Stabellini wrote:
> >> On Fri, 8 Dec 2023, Daniel P. Berrangé wrote:
> >> > On Thu, Dec 07, 2023 at 11:12:48PM +, Michael Young w
Stefano Stabellini writes:
> +Stewart
>
> On Fri, 8 Dec 2023, Mykyta Poturai wrote:
>> Hello everyone,
>>
>> I am currently working on adding MSI support to virtio-pci on ARM with Xen.
>
> Excellent!
>
>
>> As far as I understand QEMU Xen ARM machine that is used for
>> virtio-pci device emulati
Hi Stefan,
Stefan Hajnoczi writes:
> On Tue, 12 Dec 2023 at 10:36, Volodymyr Babchuk
> wrote:
>>
>> Hi Anthony
>>
>> Anthony PERARD writes:
>>
>> > On Fri, Dec 08, 2023 at 02:49:27PM -0800, Stefano Stabellini wrote:
>> >> On Fri, 8 Dec 2023, Daniel P. Berrangé wrote:
>> >> > On Thu, Dec 07, 2
Pipeline #1103957927 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 0fb4b6b0 (
https://gitlab.com/xen-project/xen/-/commit/0fb4b6b0ea8505fbd4888faa440212e878002494
)
Commit Message: MAINTAINERS:
Instead of defining get_unaligned() and put_unaligned() in a way that
is only supporting architectures allowing unaligned accesses, use the
same approach as the Linux kernel and let the compiler do the
decision how to generate the code for probably unaligned data accesses.
Update include/xen/unali
Second try for the generic unaligned.h approach.
This time including a fix for building stubdom with libxenguest,
which is using a cruel hack to reuse the hypervisor's decompressing
code.
Juergen Gross (2):
xen: make include/xen/unaligned.h usable on all architectures
xen: remove asm/unaligne
With include/xen/unaligned.h now dealing properly with unaligned
accesses for all architectures, asm/unaligned.h can be removed and
users can be switched to include xen/unaligned.h instead.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
xen/arch/x86/include/asm/unaligned.h | 6 --
On Tue, 12 Dec 2023 at 11:02, Volodymyr Babchuk
wrote:
>
>
> Hi Stefan,
>
> Stefan Hajnoczi writes:
>
> > On Tue, 12 Dec 2023 at 10:36, Volodymyr Babchuk
> > wrote:
> >>
> >> Hi Anthony
> >>
> >> Anthony PERARD writes:
> >>
> >> > On Fri, Dec 08, 2023 at 02:49:27PM -0800, Stefano Stabellini wro
On 12.12.2023 17:27, Juergen Gross wrote:
> Instead of defining get_unaligned() and put_unaligned() in a way that
> is only supporting architectures allowing unaligned accesses, use the
> same approach as the Linux kernel and let the compiler do the
> decision how to generate the code for probably
1 - 100 of 142 matches
Mail list logo
