flight 186624 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186624/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e939ecf6c19f932535d073e383d016e8bf2e8ee7
baseline version:
ovmf 8bf27965dbb94e453
flight 186620 linux-linus real [real]
flight 186623 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186620/
http://logs.test-lab.xenproject.org/osstest/logs/186623/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On 02.07.24 05:10, Chen Ni wrote:
Replace a comma between expression statements by a semicolon.
Fixes: 8310b77b48c5 ("Xen/gnttab: handle p2m update errors on a per-slot basis")
Signed-off-by: Chen Ni
Reviewed-by: Juergen Gross
Juergen
Replace a comma between expression statements by a semicolon.
Fixes: 8310b77b48c5 ("Xen/gnttab: handle p2m update errors on a per-slot basis")
Signed-off-by: Chen Ni
---
arch/x86/xen/p2m.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p
On 2024/7/1 15:32, Jan Beulich wrote:
> On 30.06.2024 14:33, Jiqian Chen wrote:
>> --- a/tools/libs/ctrl/xc_physdev.c
>> +++ b/tools/libs/ctrl/xc_physdev.c
>> @@ -111,3 +111,38 @@ int xc_physdev_unmap_pirq(xc_interface *xch,
>> return rc;
>> }
>>
>> +int xc_physdev_gsi_from_pcidev(xc_interf
On 2024/7/1 15:54, Jan Beulich wrote:
> On 30.06.2024 14:33, Jiqian Chen wrote:
>> Hypercall PHYSDEVOP_map_pirq support to map a gsi into a specific
>> pirq or a free pirq, it depends on the parameter pirq(>0 or <0).
>> But in current xc_physdev_map_pirq, it set *pirq=index when
>> parameter pirq i
On 2024/7/1 15:52, Jan Beulich wrote:
> On 30.06.2024 14:33, 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
>
> As per below, it's not "don't" but "may not
On 2024/7/1 15:44, Jan Beulich wrote:
> On 30.06.2024 14:33, 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
>> pci_add_dm_done->xc_physdev_map_pirq. Then x
On 2024/7/1 15:18, Jan Beulich wrote:
> On 30.06.2024 14:33, Jiqian Chen wrote:
>> When a device has been reset on dom0 side, the vpci on Xen
>> side won't get notification, so the cached state in vpci is
>> all out of date compare with the real device state.
>> To solve that problem, add a new hyp
From: "Edgar E. Iglesias"
Bail out in qemu_ram_block_from_host() when
xen_ram_addr_from_mapcache() does not find an existing
mapping.
Signed-off-by: Edgar E. Iglesias
---
system/physmem.c | 4
1 file changed, 4 insertions(+)
diff --git a/system/physmem.c b/system/physmem.c
index 33d09f75
From: "Edgar E. Iglesias"
This fixes the unmapping of the first mapping in a bucket of a mapcache.
We also add error handling to qemu_ram_block_from_host() to bail out when
xen_ram_addr_from_mapcache() doesn't find an existing mapping.
Cheers,
Edgar
Edgar E. Iglesias (2):
physmem: Bail out q
From: "Edgar E. Iglesias"
This fixes the clobbering of the entry->next pointer when
unmapping the first entry in a bucket of a mapcache.
Fixes: 123acd816d ("xen: mapcache: Unmap first entries in buckets")
Reported-by: Anthony PERARD
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c |
On Mon, Jul 1, 2024 at 6:21 PM Anthony PERARD
wrote:
> On Mon, Jul 01, 2024 at 04:34:53PM +0200, Edgar E. Iglesias wrote:
> > On Mon, Jul 1, 2024 at 4:30 PM Edgar E. Iglesias <
> edgar.igles...@gmail.com>
> > wrote:
> > > On Mon, Jul 1, 2024 at 3:58 PM Edgar E. Iglesias <
> edgar.igles...@gmail.c
flight 186621 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186621/
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 Thu, Jun 27, 2024 at 05:18:15PM -0700, Elliott Mitchell wrote:
> I'm rather surprised it was so long before the next system restart.
> Seems a quiet period as far as security updates go. Good news is I made
> several new observations, but I don't know how valuable these are.
>
> On Mon, May
From: Michael Kelley
With CONFIG_SWIOTLB_DYNAMIC enabled, each round-trip map/unmap pair
in the swiotlb results in 6 calls to swiotlb_find_pool(). In multiple
places, the pool is found and used in one function, and then must
found again in the next function that is called because only the
tlb_add
On Mon, Jul 01, 2024 at 04:34:53PM +0200, Edgar E. Iglesias wrote:
> On Mon, Jul 1, 2024 at 4:30 PM Edgar E. Iglesias
> wrote:
> > On Mon, Jul 1, 2024 at 3:58 PM Edgar E. Iglesias
> > wrote:
> >> Any chance you could try to get a backtrace from QEMU when it failed?
Here it is:
#3 0x7fa876
On 24/06/2024 1:28 pm, Jan Beulich wrote:
> Much like noted in 43d5c5d5f70b ("xen: avoid UB in guest handle
> arithmetic"), address calculations involved in accessing a struct field
> can overflow, too. Cast respective pointers to "unsigned long" and
> convert type checking accordingly. Remaining a
On 06/03/2024 1:44 pm, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -47,12 +55,13 @@ UNLIKELY_START(z, syscall_no_callback) /
> testb $4, X86_EXC_UD * TRAPINFO_sizeof + TRAPINFO_flags(%rdi)
> setnz %cl
> lea TBF_EXCEPTI
On Thu, Jun 27, 2024 at 10:55 AM Jan Beulich wrote:
>
> On 26.06.2024 18:16, Milan Djokic wrote:
> >> +config RISCV_EFI
> >> + bool "UEFI boot service support"
> >> + depends on RISCV_64
> >> + default n
> >
> > Nit: This line can be omitted (and if I'm not mistaken we generally do omi
On 01/07/2024 4:15 pm, Olaf Hering wrote:
> The build system uses find(1). Make sure it is available.
>
> Signed-off-by: Olaf Hering
Acked-by: Andrew Cooper
CC Oleksii. This is probably non-optional to take.
I suspect it means we can't rebuild the OpenSUSE dockerfiles any more...
~Andrew
>
On Mon, Jul 01, 2024 at 05:07:19PM +0200, Jan Beulich wrote:
> On 01.07.2024 15:29, Roger Pau Monné wrote:
> > On Mon, Jul 01, 2024 at 12:40:35PM +0200, Jan Beulich wrote:
> >> On 01.07.2024 11:55, Roger Pau Monné wrote:
> >>> On Thu, Jul 27, 2023 at 09:38:55AM +0200, Jan Beulich wrote:
> ---
The build system uses find(1). Make sure it is available.
Signed-off-by: Olaf Hering
---
automation/build/suse/opensuse-leap.dockerfile | 1 +
automation/build/suse/opensuse-tumbleweed.dockerfile | 1 +
2 files changed, 2 insertions(+)
diff --git a/automation/build/suse/opensuse-leap.dock
On Tue, 2024-06-25 at 20:07 +0100, Andrew Cooper wrote:
> ... and use it in self-tests.h.
>
> This is intended to replace constructs such as __bitop_bad_size().
> It
> produces a better diagnostic, and is MISRA-friendly.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau
On 01.07.2024 15:29, Roger Pau Monné wrote:
> On Mon, Jul 01, 2024 at 12:40:35PM +0200, Jan Beulich wrote:
>> On 01.07.2024 11:55, Roger Pau Monné wrote:
>>> On Thu, Jul 27, 2023 at 09:38:55AM +0200, Jan Beulich wrote:
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -266
On Fri, 2024-06-28 at 15:31 +0100, Andrew Cooper wrote:
> More fixes to CLOEXEC handling in libxenstore. For 4.19, because the
> first
> attempt to fix this wasn't complete.
>
> libxl is far worse, but I don't have time to get started on that
> mess.
>
> Andrew Cooper (3):
> tools/libxs: Fix C
On Mon, 2024-07-01 at 15:21 +0200, Jan Beulich wrote:
> On 01.07.2024 13:13, Roger Pau Monné wrote:
> > On Mon, Jul 01, 2024 at 11:47:34AM +0200, Jan Beulich wrote:
> > > On 01.07.2024 10:55, Roger Pau Monné wrote:
> > > > On Thu, Jul 27, 2023 at 09:38:29AM +0200, Jan Beulich wrote:
> > > > > Its o
xen-hvmcrash would previously save records, overwrite the instruction
pointer with a bogus value, and then restore them to crash a domain
just enough to cause the guest OS to memdump.
This approach is found to be unreliable when tested on a guest running
Windows 10 x64, with some executions doing
On 2024-07-01 16:09, Marek Marczykowski-Górecki wrote:
On Mon, Jul 01, 2024 at 03:36:01PM +0200, Alessandro Zucchelli wrote:
From: Simone Ballarin
Add inclusion guard to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header
On Mon, Jul 1, 2024 at 4:30 PM Edgar E. Iglesias
wrote:
>
>
> On Mon, Jul 1, 2024 at 3:58 PM Edgar E. Iglesias
> wrote:
>
>> On Mon, Jul 1, 2024 at 2:55 PM Anthony PERARD
>> wrote:
>>
>>> Hi all,
>>>
>>> Following this commit, a test which install Debian in a guest with OVMF
>>> as firmware sta
On Mon, Jul 1, 2024 at 3:58 PM Edgar E. Iglesias
wrote:
> On Mon, Jul 1, 2024 at 2:55 PM Anthony PERARD
> wrote:
>
>> Hi all,
>>
>> Following this commit, a test which install Debian in a guest with OVMF
>> as firmware started to fail. QEMU exit with an error when GRUB is
>> running on the fresh
On 01.07.2024 15:36, Alessandro Zucchelli wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -260,17 +260,18 @@ $(objtree)/arch/x86/include/asm/asm-macros.h:
> $(obj)/asm-macros.i $(src)/Makefil
> $(call filechk,asm-macros.h)
>
> define filechk_asm-macros.h
> + gu
On 01.07.2024 13:10, Alessandro Zucchelli wrote:
> From: Simone Ballarin
>
> Add deviation comments to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Inclusion guards must
On 01.07.2024 15:36, Alessandro Zucchelli wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -3,6 +3,11 @@
> * is intended to be included by common/efi/boot.c _only_, and
> * therefore can define arch specific global variables.
> */
> +
> +#ifndef X86_EFI_EFI_
On Mon, Jul 01, 2024 at 03:36:01PM +0200, Alessandro Zucchelli wrote:
> From: Simone Ballarin
>
> Add inclusion guard to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Mec
On Mon, Jul 1, 2024 at 2:55 PM Anthony PERARD
wrote:
> Hi all,
>
> Following this commit, a test which install Debian in a guest with OVMF
> as firmware started to fail. QEMU exit with an error when GRUB is
> running on the freshly installed Debian (I don't know if GRUB is
> starting Linux or not
This section explains which format should be followed by header
inclusion guards via a drop-down list of rules.
No functional change.
Signed-off-by: Alessandro Zucchelli
---
CODING_STYLE | 19 +++
1 file changed, 19 insertions(+)
diff --git a/CODING_STYLE b/CODING_STYLE
index 7
This addresses violations of MISRA C:2012 Rule 4.10 which states as
following: Precautions shall be taken in order to prevent the contents
of a header file being included more than once.
Added inclusion guards for autogenerated header files: include/xen/compile.h
and include/xen/hypercall-defs.h.
From: Maria Celeste Cesario
Edit inclusion guards in order to make them consistent with the
estabilished naming conventions.
No functional change.
Signed-off-by: Maria Celeste Cesario
Signed-off-by: Simone Ballarin
Reviewed-by: Stefano Stabellini
Signed-off-by: Alessandro Zucchelli
---
C
From: Nicola Vetrini
Signed-off-by: Nicola Vetrini
Signed-off-by: Alessandro Zucchelli
---
docs/misra/safe.json | 10 +-
xen/include/public/arch-x86/xen.h | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/docs/misra/safe.json b/docs/misra/safe.json
in
From: Nicola Vetrini
Add safe deviation for *.c files, as estabilished in past discussion.
Signed-off-by: Maria Celeste Cesario
Signed-off-by: Simone Ballarin
Signed-off-by: Nicola Vetrini
Signed-off-by: Alessandro Zucchelli
---
Changes in v4:
- split the commit from the unrelated SAF dev
From: Maria Celeste Cesario
Modify creation rule for asm-offsets.h to conform to
the new standard and to not generate conflicting guards
between architectures (which is a violation of the directive).
Modify generic-y creation rule to generate code without violations
and to conform to the new stan
From: Maria Celeste Cesario
Add or modify inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
prevent the contents of a header file being included more than once").
Mechanical change.
Signed-off-by: Maria Celeste Cesario
Signed-off-by:
From: Simone Ballarin
Amend generation script, add inclusion guards to address violations
of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
This patch amends the Makefile adding the required inclusion gu
From: Simone Ballarin
Add inclusion guard to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Mechanical change.
Signed-off-by: Simone Ballarin
Signed-off-by: Maria Celeste Cesario
From: Simone Ballarin
Add inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Mechanical change.
Signed-off-by: Simone Ballarin
Signed-off-by: Maria Celeste Cesario
From: Simone Ballarin
Add inclusion guard to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Mechanical change.
Signed-off-by: Simone Ballarin
Signed-off-by: Maria Celeste Cesario
From: Simone Ballarin
Amend inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of the headers
(comments are permitted a
From: Simone Ballarin
Add inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Mechanical change.
Signed-off-by: Simone Ballarin
Signed-off-by: Maria Celeste Cesario
From: Simone Ballarin
Add or move inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of the headers
(comments are permi
On Mon, Jul 01, 2024 at 12:40:35PM +0200, Jan Beulich wrote:
> On 01.07.2024 11:55, Roger Pau Monné wrote:
> > On Thu, Jul 27, 2023 at 09:38:55AM +0200, Jan Beulich wrote:
> >> --- a/xen/arch/x86/io_apic.c
> >> +++ b/xen/arch/x86/io_apic.c
> >> @@ -2663,18 +2663,21 @@ void __init ioapic_init(void)
On 01.07.2024 13:13, Roger Pau Monné wrote:
> On Mon, Jul 01, 2024 at 11:47:34AM +0200, Jan Beulich wrote:
>> On 01.07.2024 10:55, Roger Pau Monné wrote:
>>> On Thu, Jul 27, 2023 at 09:38:29AM +0200, Jan Beulich wrote:
Its original introduction had two issues: For one the "common" part of
flight 186615 linux-linus real [real]
flight 186618 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186615/
http://logs.test-lab.xenproject.org/osstest/logs/186618/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
Hi all,
Following this commit, a test which install Debian in a guest with OVMF
as firmware started to fail. QEMU exit with an error when GRUB is
running on the freshly installed Debian (I don't know if GRUB is
starting Linux or not).
The error is:
Bad ram offset
Some logs:
h
On Thu, May 02, 2024 at 06:55:26PM +0200, Carlo Nonato wrote:
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> index 41252ec553..ff80625bd6 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -726,6 +726,19 @@ int libxl__doma
Build AMD Architectural P-state driver when CONFIG_AMD is on, and
Intel Hardware P-States driver together with ACPI Processor P-States driver
when CONFIG_INTEL is on respectively, allowing for a platform-specific build.
Signed-off-by: Sergiy Kibrik
CC: Jason Andryuk
CC: Jan Beulich
---
changes
Separate ACPI driver from generic initialization cpufreq code.
This way acpi-cpufreq can become optional in the future and be disabled
from non-Intel builds.
Other than acpi_register_driver() helper added and clean up a list of
included headers no changes to code were introduced.
Signed-off-by: S
This short series aims to make platform-specific parts of cpufreq optional
and dependant on INTEL & AMD config options. This is to allow for tuning
the build for either AMD or Intel platform exclusively and hence to drop
the code that would be left unused.
The initial v1 patch has been extended to
flight 186616 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186616/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8bf27965dbb94e453c60de3270acf238ea3d
baseline version:
ovmf 8c09d862bfb034e00b6b3
On Mon, Jul 01, 2024 at 11:47:34AM +0200, Jan Beulich wrote:
> On 01.07.2024 10:55, Roger Pau Monné wrote:
> > On Thu, Jul 27, 2023 at 09:38:29AM +0200, Jan Beulich wrote:
> >> Its original introduction had two issues: For one the "common" part of
> >> the checks (carried out in the macro) was inve
From: Simone Ballarin
Add deviation comments to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of the headers
(comments are permitted a
The Xen sources contain violations of MISRA C:2012 Directive 4.10 whose
headline states:
"Precautions shall be taken in order to prevent the contents of a header file
being included more than once".
Following V2 and V3, here are all the rules that have been applied:
- private headers -> __H
- asm
From: Simone Ballarin
This patch modifies deviations for Directive 4.10:
"Precautions shall be taken in order to prevent the contents of
a header file being included more than once"
This patch avoids the file-based deviation for empty headers, and
replaces it with a comment-based one using the f
From: Simone Ballarin
Some headers, under specific circumstances (documented in a comment at
the beginning of the file), explicitly avoid inclusion guards: the caller
is responsible for including them correctly.
These files are not supposed to comply with Directive 4.10:
"Precautions shall be ta
On 01.07.2024 11:55, Roger Pau Monné wrote:
> On Thu, Jul 27, 2023 at 09:38:55AM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -2663,18 +2663,21 @@ void __init ioapic_init(void)
>> nr_irqs_gsi, nr_irqs - nr_irqs_gsi);
>> }
>>
>> -unsi
On Thu, Jul 27, 2023 at 09:38:55AM +0200, Jan Beulich wrote:
> PHYSDEVOP_pirq_eoi_gmfn_v accepting just a single GFN implies that no
> more than 32k pIRQ-s can be used by a domain on x86. Document this upper
> bound.
>
> To also enforce the limit, (ab)use both arch_hwdom_irqs() (changing its
> par
On 01.07.2024 10:55, Roger Pau Monné wrote:
> On Thu, Jul 27, 2023 at 09:38:29AM +0200, Jan Beulich wrote:
>> Its original introduction had two issues: For one the "common" part of
>> the checks (carried out in the macro) was inverted.
>
> Is the current logic in evtchn_close() really malfunctioni
On Mon, Jul 01, 2024 at 11:03:02AM +0200, Jürgen Groß wrote:
> On 28.06.24 16:31, Andrew Cooper wrote:
> > More fixes to CLOEXEC handling in libxenstore. For 4.19, because the first
> > attempt to fix this wasn't complete.
> >
> > libxl is far worse, but I don't have time to get started on that me
On 2024-07-01 10:27, Jan Beulich wrote:
On 27.06.2024 02:57, Stefano Stabellini wrote:
On Wed, 26 Jun 2024, Nicola Vetrini wrote:
From: Alessandro Zucchelli
This addresses violations of MISRA C:2012 Rule 5.3 which states as
following: An identifier declared in an inner scope shall not hide an
On 28.06.24 16:31, Andrew Cooper wrote:
More fixes to CLOEXEC handling in libxenstore. For 4.19, because the first
attempt to fix this wasn't complete.
libxl is far worse, but I don't have time to get started on that mess.
Andrew Cooper (3):
tools/libxs: Fix CLOEXEC handling in get_dev()
On 26.06.2024 11:28, Federico Serafini wrote:
> Add defensive return statement at the end of an unreachable
> default case. Other than improve safety, this meets the requirements
> to deviate a violation of MISRA C Rule 16.3: "An unconditional `break'
> statement shall terminate every switch-clause
On 28.06.24 17:08, Andrew Cooper wrote:
Appears to been missed from the previous attempt in 2007.
Fixes: fed194611785 ("xenstore: Remove broken and unmaintained test code")
Signed-off-by: Andrew Cooper
Reviewed-by: Juergen Gross
Juergen
On Thu, Jul 27, 2023 at 09:38:29AM +0200, Jan Beulich wrote:
> Its original introduction had two issues: For one the "common" part of
> the checks (carried out in the macro) was inverted.
Is the current logic in evtchn_close() really malfunctioning?
pirq->evtchn = 0;
pirq_cleanup_check(pirq, d1);
On 26.06.2024 11:28, Federico Serafini wrote:
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -118,9 +118,11 @@ static int pt_irq_masked(struct periodic_time *pt)
> return 0;
>
> gsi = hvm_isa_irq_to_gsi(pt->irq);
> +
> +/* Fallthrough to check if
On 26.06.2024 11:28, Federico Serafini wrote:
> @@ -2798,11 +2800,12 @@ void hvm_emulate_one_vm_event(enum emul_kind kind,
> unsigned int trapnr,
> hvio->mmio_insn_bytes = sizeof(hvio->mmio_insn);
> memcpy(hvio->mmio_insn, curr->arch.vm_event->emul.insn.data,
> hv
On 27.06.2024 02:52, Stefano Stabellini wrote:
> On Wed, 26 Jun 2024, Federico Serafini wrote:
>> Add break or pseudo keyword fallthrough to address violations of
>> MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
>> every switch-clause".
>>
>> No functional change.
>>
>> Sig
On 26.06.2024 11:27, Federico Serafini wrote:
> Add missing break statements to address violations of MISRA C Rule
> 16.3: "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Jan Beulich
On 28.06.2024 08:30, Nicola Vetrini wrote:
> The label 'out_unmap' is only reachable after ASSERT_UNREACHABLE,
> so the code below is only executed upon erroneously reaching that
> program point and calling domain_crash, thus resulting in the
> for loop after 'out_unmap' to become unreachable in so
On 27.06.2024 02:57, Stefano Stabellini wrote:
> On Wed, 26 Jun 2024, Nicola Vetrini wrote:
>> From: Alessandro Zucchelli
>>
>> This addresses violations of MISRA C:2012 Rule 5.3 which states as
>> following: An identifier declared in an inner scope shall not hide an
>> identifier declared in an o
On 19.06.24 12:40, Frediano Ziglio wrote:
Current timer tick is causing some deadline to fail.
The current high value constant was probably due to an old
bug in the Xen timer implementation causing errors if the
deadline was in the future.
This was fixed in Xen commit:
19c6cbd90965 xen/vcpu: ign
Transactional Synchronization Extensions are supported on certain Intel's
CPUs only, hence can be put under CONFIG_INTEL build option.
The whole TSX support, even if supported by CPU, may need to be disabled via
options, by microcode or through spec-ctrl, depending on a set of specific
conditions.
On 25.06.2024 12:14, Alessandro Zucchelli wrote:
> In the file common/softirq macro set_bit is called with argument
> smp_processor_id.
> Once expanded this set_bit's argument is used in sizeof operations
> and thus 'smp_processor_id', being a macro that expands to a
> function call with potential
hi, Christoph Hellwig,
On Wed, Jun 26, 2024 at 09:54:05PM -0700, Christoph Hellwig wrote:
> On Thu, Jun 27, 2024 at 10:35:38AM +0800, Oliver Sang wrote:
> >
> > I failed to apply patch in your previous reply to 1122c0c1cc or current tip
> > of axboe-block/for-next:
> > c1440ed442a58 (axboe-block/
flight 186613 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186613/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 8 xen-boot fail pass in 186588
Tests which did not succeed, but
On 25.06.2024 12:14, Alessandro Zucchelli wrote:
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -183,13 +183,14 @@ static bool evtchn_usable(const struct evtchn *evtchn)
> /* Wait on a Xen-attached event channel. */
> #define wait_on_xen_event_channel(port, condition)
Hi all,
I would like to remind you that the code freeze date for Xen 4.19 is
today ( 01.07.2024 ).
Have a nice week!
Best regards,
Oleksii
On 30.06.2024 14:33, Jiqian Chen wrote:
> Hypercall PHYSDEVOP_map_pirq support to map a gsi into a specific
> pirq or a free pirq, it depends on the parameter pirq(>0 or <0).
> But in current xc_physdev_map_pirq, it set *pirq=index when
> parameter pirq is <0, it causes to force all cases to be map
On 30.06.2024 14:33, 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
As per below, it's not "don't" but "may not". As the details don't
follow right away, you
On 30.06.2024 14:33, 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
> pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
> will call into Xen, but
On 30.06.2024 14:33, Jiqian Chen wrote:
> --- a/tools/libs/ctrl/xc_physdev.c
> +++ b/tools/libs/ctrl/xc_physdev.c
> @@ -111,3 +111,38 @@ int xc_physdev_unmap_pirq(xc_interface *xch,
> return rc;
> }
>
> +int xc_physdev_gsi_from_pcidev(xc_interface *xch, uint32_t sbdf)
> +{
> +int rc = -
On 25/06/2024 21:07, Andrew Cooper wrote:
>
>
> ... which is better optimised for scalar values, rather than using the
> arbitrary-sized bitmap helpers.
>
> For ARM32:
>
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-16 (-16)
> Function old new d
On 25/06/2024 21:07, Andrew Cooper wrote:
>
>
> The current implementation wants to take an in-memory bitmap. However, all
> ARM callers and all-but-1 x86 callers spill a scalar to the stack in order to
> use the "generic arbitrary bitmap" helpers under the hood.
>
> This functions, but it's
On 30.06.2024 14:33, Jiqian Chen wrote:
> When a device has been reset on dom0 side, the vpci on Xen
> side won't get notification, so the cached state in vpci is
> all out of date compare with the real device state.
> To solve that problem, add a new hypercall to clear all vpci
> device state. Whe
93 matches
Mail list logo
