Building Xen with CONFIG_STATIC_SHM=y results in a build failure:
arch/arm/static-shmem.c: In function 'process_shm':
arch/arm/static-shmem.c:327:41: error: 'gbase' may be used uninitialized
[-Werror=maybe-uninitialized]
327 | if ( is_domain_direct_mapped(d) && (pbase != gbase) )
arch/a
flight 186401 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186401/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186393
test-amd64-amd64-xl-qemut-win7-amd64
On 2024/6/18 16:38, Jan Beulich wrote:
> On 18.06.2024 08:49, Chen, Jiqian wrote:
>> On 2024/6/17 22:45, Jan Beulich wrote:
>>> On 17.06.2024 11:00, Jiqian Chen wrote:
If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see qemu code
xen_
flight 186404 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186404/
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 2024/6/18 16:33, Jan Beulich wrote:
> On 18.06.2024 08:25, Chen, Jiqian wrote:
>> On 2024/6/17 22:17, Jan Beulich wrote:
>>> On 17.06.2024 11:00, Jiqian Chen wrote:
--- a/xen/drivers/pci/physdev.c
+++ b/xen/drivers/pci/physdev.c
@@ -2,11 +2,17 @@
#include
#include
>>
flight 186405 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186405/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 26a30abdd0f7fe5a9d2421cba6efe9397185ad98
baseline version:
ovmf c1d1910be6e04a8b1a730
flight 186398 linux-linus real [real]
flight 186403 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186398/
http://logs.test-lab.xenproject.org/osstest/logs/186403/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Mon, 27 May 2024, Oleksii K. wrote:
> > I don't think it is a big problem if this is not merged for the code
> > freeze as this is technically a bug fix.
>
> Agree, this is not a problem as it is still looks to me as a bug fix.
>
> ~ Oleksii
Hi Oleksii, this version of the series was already
flight 186402 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186402/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c1d1910be6e04a8b1a73090cf2881fb698947a6e
baseline version:
ovmf ffce430d2b65d508a1604
On Fri, 13 Jun 2024, Roger Pau Monné wrote:
> On Fri, Jun 14, 2024 at 01:49:50PM +0100, Andrew Cooper wrote:
> > These being in cache.h is inherited from Linux, but is an inappropriate
> > location to live.
> >
> > __read_mostly is an optimisation related to data placement in order to avoid
> > ha
flight 186399 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186399/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ffce430d2b65d508a1604dc986ba16db3583943d
baseline version:
ovmf bfda27ddc89502190c79f
flight 186393 xen-unstable real [real]
flight 186400 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186393/
http://logs.test-lab.xenproject.org/osstest/logs/186400/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
* Use 64bit accesses instead of 32bit accesses
* Simplify the constant names
* Pull base into a local variable to avoid it being reloaded because of the
memory clobber in writeq().
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
RFC. This is m
Hello Anthony, thank you very much for your review comments! They are very
thorough and knowledgeable.
I unfortunately only just saw them, I don't know why I missed them back in
April but doesn't matter. I am not going to continue work on these patches
due to circumstances changing for me, if the
flight 186396 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186396/
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 186397 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186397/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bfda27ddc89502190c79f74fc20cb81458d58449
baseline version:
ovmf b0c5781671f322472836f
On 18.06.2024 16:50, Roger Pau Monné wrote:
> On Tue, Jun 18, 2024 at 04:34:50PM +0200, Jan Beulich wrote:
>> On 18.06.2024 13:30, Roger Pau Monné wrote:
>>> On Mon, Jun 17, 2024 at 03:41:12PM +0200, Jan Beulich wrote:
On 13.06.2024 18:56, Roger Pau Monne wrote:
> @@ -2686,11 +2705,27 @@ v
On 18.06.2024 17:21, Andrew Cooper wrote:
> On 18/06/2024 11:05 am, Jan Beulich wrote:
>> On 17.06.2024 19:39, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/xstate.c
>>> +++ b/xen/arch/x86/xstate.c
>>> @@ -604,9 +604,164 @@ static bool valid_xcr0(uint64_t xcr0)
>>> if ( !(xcr0 & X86_XCR0_BNDREGS
flight 186389 linux-linus real [real]
flight 186395 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186389/
http://logs.test-lab.xenproject.org/osstest/logs/186395/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On 18/06/2024 11:05 am, Jan Beulich wrote:
> On 17.06.2024 19:39, Andrew Cooper wrote:
>> Right now, xstate_ctxt_size() performs a cross-check of size with CPUID in
>> for
>> every call. This is expensive, being used for domain create/migrate, as well
>> as to service certain guest CPUID instruct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, Jun 18, 2024 at 04:43:50PM +0200, Roger Pau Monné wrote:
> On Mon, Jun 17, 2024 at 08:57:14PM -0400, Demi Marie Obenour wrote:
> > Given the recent progress on PVH dom0, is it reasonable to assume that
> > PVH dom0 will be ready in time for R
Hi all,
The June community call recording has been uploaded:
https://youtu.be/cJyX6FLK4iU
This has also been saved in the Cryptpad file.
https://cryptpad.fr/pad/#/2/pad/view/bFelqwYToFejOhnu1bInhJ7sJwPGqW55gOpWx+VJ0GU/
Many thanks,
Kelly Choi
Community Manager
Xen Project
On Tue, Jun 18, 2024 at 04:34:50PM +0200, Jan Beulich wrote:
> On 18.06.2024 13:30, Roger Pau Monné wrote:
> > On Mon, Jun 17, 2024 at 03:41:12PM +0200, Jan Beulich wrote:
> >> On 13.06.2024 18:56, Roger Pau Monne wrote:
> >>> fixup_irqs() is used to evacuate interrupts from to be offlined CPUs.
On Mon, Jun 17, 2024 at 08:57:14PM -0400, Demi Marie Obenour wrote:
> Given the recent progress on PVH dom0, is it reasonable to assume that
> PVH dom0 will be ready in time for R4.3, and that therefore Qubes OS
> doesn't need to worry about this problem on x86?
PVH dom0 will only be ready (whatev
On 18.06.2024 13:30, Roger Pau Monné wrote:
> On Mon, Jun 17, 2024 at 03:41:12PM +0200, Jan Beulich wrote:
>> On 13.06.2024 18:56, Roger Pau Monne wrote:
>>> fixup_irqs() is used to evacuate interrupts from to be offlined CPUs. Given
>>> the CPU is to become offline, the normal migration logic use
flight 186390 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186390/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186343
test-amd64-amd64-libvirt-xsm 15 migrate-s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, Jun 18, 2024 at 08:33:38AM +0200, Christian König wrote:
> Am 18.06.24 um 02:57 schrieb Demi Marie Obenour:
> > On Mon, Jun 17, 2024 at 10:46:13PM +0200, Marek Marczykowski-Górecki
> > wrote:
> > > On Mon, Jun 17, 2024 at 09:46:29AM +0200, Ro
On 18/06/2024 9:07 am, Oleksii K. wrote:
> On Mon, 2024-06-17 at 18:55 +0100, Andrew Cooper wrote:
>> struct type_descriptor is arranged with a NUL terminated string
> Should it be NULL instead of NUL?
NULL and NUL can be used interchangeably; they're different spellings
for the same thing.
In th
On 19/03/2024 1:26 pm, Jan Beulich wrote:
> At least XENMEM_memory_exchange can have huge values passed in the
> nr_extents and nr_exchanged fields. Adding such values to pointers can
> overflow, resulting in UB. Cast respective pointers to "unsigned long"
> while at the same time making the necess
flight 186394 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186394/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b0c5781671f322472836ff25ee11242f59aa9945
baseline version:
ovmf 176b9d41f8f71c7572dab
Hi Andrew,
On 18/06/2024 14:00, Andrew Cooper wrote:
When centralising irq_ack_none(), different architectures had different names
for the parameter of irq_ack_none(). As it's type is struct irq_desc *, it
should be named desc. Make this consistent.
No functional change.
Fixes: 8aeda4a241ab
On 18.06.2024 15:00, Andrew Cooper wrote:
> When centralising irq_ack_none(), different architectures had different names
> for the parameter of irq_ack_none(). As it's type is struct irq_desc *, it
> should be named desc. Make this consistent.
>
> No functional change.
>
> Fixes: 8aeda4a241ab
When centralising irq_ack_none(), different architectures had different names
for the parameter of irq_ack_none(). As it's type is struct irq_desc *, it
should be named desc. Make this consistent.
No functional change.
Fixes: 8aeda4a241ab ("arch/irq: Make irq_ack_none() mandatory")
Signed-off-b
On 14/06/2024 12:12 pm, Jan Beulich wrote:
> On 14.06.2024 12:14, Andrew Cooper wrote:
>> On 14/06/2024 7:27 am, Jan Beulich wrote:
>>> On 13.06.2024 18:17, Andrew Cooper wrote:
On 13/06/2024 9:19 am, Jan Beulich wrote:
> Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If
On Mon, Jun 17, 2024 at 03:41:12PM +0200, Jan Beulich wrote:
> On 13.06.2024 18:56, Roger Pau Monne wrote:
> > fixup_irqs() is used to evacuate interrupts from to be offlined CPUs. Given
> > the CPU is to become offline, the normal migration logic used by Xen where
> > the
> > vector in the previ
On Mon, Jun 17, 2024 at 03:31:13PM +0200, Jan Beulich wrote:
> On 13.06.2024 18:56, Roger Pau Monne wrote:
> > Currently there's logic in fixup_irqs() that attempts to prevent
> > _assign_irq_vector() from failing, as fixup_irqs() is required to evacuate
> > all
> > interrupts from the CPUs not pr
On Mon, Jun 17, 2024 at 03:18:42PM +0200, Jan Beulich wrote:
> On 13.06.2024 18:56, Roger Pau Monne wrote:
> > Given the current logic it's possible for ->arch.old_cpu_mask to get out of
> > sync: if a CPU set in old_cpu_mask is offlined and then onlined
> > again without old_cpu_mask having been u
On 5/6/24 15:14, Gerd Hoffmann wrote:
Gerd Hoffmann (3):
stdvga: fix screen blanking
ui+display: rename is_placeholder() -> surface_is_placeholder()
ui+display: rename is_buffer_shared() -> surface_is_allocated()
Since Marc-André reviewed, I'm queuing this series, thanks!
On 18/06/2024 10:44 am, Anthony PERARD wrote:
> On Mon, Jun 17, 2024 at 04:34:09PM +0100, Andrew Cooper wrote:
>> On 17/06/2024 3:40 pm, Anthony PERARD wrote:
>>> diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
>>> index 3545f3fd..d974fea5 100644
>>> --- a/Osstest/Debian.pm
>>> +++ b/Osstest/Deb
On 5/6/24 15:14, Gerd Hoffmann wrote:
No functional change.
Signed-off-by: Gerd Hoffmann
---
include/ui/surface.h | 2 +-
ui/console.c | 2 +-
ui/sdl2-2d.c | 2 +-
ui/sdl2-gl.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Philippe Mathieu
On 17.06.2024 19:39, Andrew Cooper wrote:
> We're soon going to need a compressed helper of the same form.
>
> The size of the uncompressed image depends on the single element with the
> largest offset + size. Sadly this isn't always the element with the largest
> index.
>
> Name the per-xstate-
On 17.06.2024 19:39, Andrew Cooper wrote:
> This is a tangle, but it's a small step in the right direction.
>
> In the following change, xstate_init() is going to start using the Raw policy.
>
> calculate_raw_cpu_policy() is sufficiently separate from the other policies to
> safely move like this
On 18.06.2024 11:54, Alessandro Zucchelli wrote:
> The file contains violations of Rule 7.3 which states as following: The
> lowercase character `l' shall not be used in a literal suffix.
>
> This file defines a non-compliant constant used in a macro expanded in a
> non-excluded file, so this devi
On 17.06.2024 19:39, Andrew Cooper wrote:
> Right now, xstate_ctxt_size() performs a cross-check of size with CPUID in for
> every call. This is expensive, being used for domain create/migrate, as well
> as to service certain guest CPUID instructions.
>
> Instead, arrange to check the sizes once
The file contains violations of Rule 7.3 which states as following: The
lowercase character `l' shall not be used in a literal suffix.
This file defines a non-compliant constant used in a macro expanded in a
non-excluded file, so this deviation is needed in order to avoid
a spurious violation invo
On Mon, Jun 17, 2024 at 04:34:09PM +0100, Andrew Cooper wrote:
> On 17/06/2024 3:40 pm, Anthony PERARD wrote:
> > diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> > index 3545f3fd..d974fea5 100644
> > --- a/Osstest/Debian.pm
> > +++ b/Osstest/Debian.pm
> > @@ -972,7 +972,19 @@ END
> >
Nothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and
privcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd
created and added to the irqfds_list by privcmd_irqfd_assign() may get
removed by another thread executing privcmd_irqfd_deassign(), while the
former is st
irqfd_wakeup() gets EPOLLHUP, when it is called by
eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which
gets called under spin_lock_irqsave(). We can't use a mutex here as it
will lead to a deadlock.
Fix it by switching over to a spin lock.
Reported-by: Al Viro
Signed-off-by: Vir
On 18.06.2024 10:23, Chen, Jiqian wrote:
> On 2024/6/17 23:32, Jan Beulich wrote:
>> On 17.06.2024 11:00, Jiqian Chen wrote:
>>> @@ -1516,14 +1519,39 @@ static void pci_add_dm_done(libxl__egc *egc,
>>> rc = ERROR_FAIL;
>>> goto out;
>>> }
>>> -r = xc_domai
On 18.06.2024 10:10, Chen, Jiqian wrote:
> On 2024/6/17 23:10, Jan Beulich wrote:
>> On 17.06.2024 11:00, Jiqian Chen wrote:
>>> --- a/tools/include/xen-sys/Linux/privcmd.h
>>> +++ b/tools/include/xen-sys/Linux/privcmd.h
>>> @@ -95,6 +95,11 @@ typedef struct privcmd_mmap_resource {
>>> __u64 ad
flight 186392 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186392/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 176b9d41f8f71c7572dab615a8d5259dd2cbc02a
baseline version:
ovmf 537a81ae81622d6505218
flight 186386 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186386/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186376
test-amd64-amd64-xl-qemut-win7-amd64
On Tue, Jun 18, 2024 at 09:37:08AM +0100, Frediano Ziglio wrote:
> On Mon, Jun 17, 2024 at 3:37 PM Roger Pau Monné wrote:
> >
> > On Mon, Jun 17, 2024 at 04:22:21PM +0200, Jan Beulich wrote:
> > > On 17.06.2024 16:13, Frediano Ziglio wrote:
> > > > Current timer tick is causing some deadline to fa
On 18.06.2024 08:57, Chen, Jiqian wrote:
> On 2024/6/17 22:52, Jan Beulich wrote:
>> On 17.06.2024 11:00, Jiqian Chen wrote:
>>> The gsi of a passthrough device must be configured for it to be
>>> able to be mapped into a hvm domU.
>>> But When dom0 is PVH, the gsis don't get registered, it causes
On 18.06.2024 08:49, Chen, Jiqian wrote:
> On 2024/6/17 22:45, Jan Beulich wrote:
>> On 17.06.2024 11:00, Jiqian Chen wrote:
>>> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
>>> a passthrough device by using gsi, see qemu code
>>> xen_pt_realize->xc_physdev_map_pirq and libxl code
On Mon, Jun 17, 2024 at 3:37 PM Roger Pau Monné wrote:
>
> On Mon, Jun 17, 2024 at 04:22:21PM +0200, Jan Beulich wrote:
> > On 17.06.2024 16:13, Frediano Ziglio wrote:
> > > Current timer tick is causing some deadline to fail.
> > > The current high value constant was probably due to an old
> > >
On 18.06.2024 08:25, Chen, Jiqian wrote:
> On 2024/6/17 22:17, Jan Beulich wrote:
>> On 17.06.2024 11:00, Jiqian Chen wrote:
>>> --- a/xen/drivers/pci/physdev.c
>>> +++ b/xen/drivers/pci/physdev.c
>>> @@ -2,11 +2,17 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #ifndef C
On 18.06.2024 10:21, Oleksii K. wrote:
> On Fri, 2024-06-14 at 10:47 +0100, Andrew Cooper wrote:
>> On 11/06/2024 7:23 pm, Oleksii K. wrote:
>>> [OPTION 1] If we accepting of loosing 4 Gb of VA then we could
>>> implement mfn_to_page() and page_to_mfn() in the following way:
>>> ```
>>> diff --g
On 2024/6/17 23:32, Jan Beulich wrote:
> On 17.06.2024 11:00, Jiqian Chen wrote:
>> Some type of domain don't have PIRQs, like PVH, it doesn't do
>> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
>> to guest base on PVH dom0, callstack
>> pci_add_dm_done->XEN_DOMCTL_irq_permission will
On Fri, 2024-06-14 at 10:47 +0100, Andrew Cooper wrote:
> On 11/06/2024 7:23 pm, Oleksii K. wrote:
> > On Tue, 2024-06-11 at 16:53 +0100, Andrew Cooper wrote:
> > > On 30/05/2024 7:22 pm, Oleksii K. wrote:
> > > > On Thu, 2024-05-30 at 18:23 +0100, Andrew Cooper wrote:
> > > > > On 29/05/2024 8:55
On Mon, 2024-06-17 at 15:31 +0200, Jan Beulich wrote:
> On 13.06.2024 18:56, Roger Pau Monne wrote:
> > Currently there's logic in fixup_irqs() that attempts to prevent
> > _assign_irq_vector() from failing, as fixup_irqs() is required to
> > evacuate all
> > interrupts from the CPUs not present in
On Mon, 2024-06-17 at 15:18 +0200, Jan Beulich wrote:
> On 13.06.2024 18:56, Roger Pau Monne wrote:
> > Given the current logic it's possible for ->arch.old_cpu_mask to
> > get out of
> > sync: if a CPU set in old_cpu_mask is offlined and then onlined
> > again without old_cpu_mask having been upda
On 2024/6/17 23:10, Jan Beulich wrote:
> On 17.06.2024 11:00, Jiqian Chen wrote:
>> In PVH dom0, it uses the linux local interrupt mechanism,
>> when it allocs irq for a gsi, it is dynamic, and follow
>> the principle of applying first, distributing first. And
>> irq number is alloced from small to
On Mon, 2024-06-17 at 18:55 +0100, Andrew Cooper wrote:
> struct type_descriptor is arranged with a NUL terminated string
Should it be NULL instead of NUL?
> following the
> kind/info fields.
>
> The only reason this doesn't trip UBSAN detection itself (on more
> modern
> compilers at least) is b
flight 186391 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186391/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 537a81ae81622d65052184b281e8b2754d0b5313
baseline version:
ovmf 128513afcdfa77e94c963
On 17.06.2024 19:55, Andrew Cooper wrote:
> struct type_descriptor is arranged with a NUL terminated string following the
> kind/info fields.
>
> The only reason this doesn't trip UBSAN detection itself (on more modern
> compilers at least) is because struct type_descriptor is only referenced in
>
On 17.06.2024 19:30, Andrew Cooper wrote:
> On 17/06/2024 11:25 am, Jan Beulich wrote:
>> On 14.06.2024 20:26, Andrew Cooper wrote:
>>> On 23/05/2024 4:44 pm, Jan Beulich wrote:
On 23.05.2024 13:16, Andrew Cooper wrote:
> This is a tangle, but it's a small step in the right direction.
67 matches
Mail list logo
