From: Antonio Caggiano
Support BLOB resources creation, mapping and unmapping by calling the
new stable virglrenderer 0.10 interface. Only enabled when available and
via the blob config. E.g. -device virtio-vga-gl,blob=true
Signed-off-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
From: Antonio Caggiano
Enable resource UUID feature and implement command resource assign UUID.
This is done by introducing a hash table to map resource IDs to their
UUIDs.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
Changes in v6:
- Set resource uuid as option.
- Implement
From: Antonio Caggiano
Add support for the Venus capset, which enables Vulkan support through
the Venus Vulkan driver for virtio-gpu.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
No change in v6.
hw/display/virtio-gpu-virgl.c | 21 +
1 file changed, 17
Introduce a new virgl_gpu_resource data structure and helper functions
for virgl. It's used to add new member which is specific for virgl in
following patches of blob memory support.
Signed-off-by: Huang Rui
---
New patch:
- Introduce new struct virgl_gpu_resource to store virgl specific
From: Xenia Ragiadakou
When the memory region has a different life-cycle from that of her parent,
could be automatically released, once has been unparent and once all of her
references have gone away, via the object's free callback.
However, currently, the address space subsystem keeps
Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
feature flags.
We would like to enable the feature with virglrenderer, so add to create
virgl renderer context with flags using context_id when valid.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
Changes in v6:
From: Dmitry Osipenko
The udmabuf usage is mandatory when virgl is disabled and blobs feature
enabled in the Qemu machine configuration. If virgl and blobs are enabled,
then udmabuf requirement is optional. Since udmabuf isn't widely supported
by a popular Linux distros today, let's relax the
Configure a new feature flag (context_create_with_flags) for
virglrenderer.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
Changes in v6:
- Move macros configurations under virgl.found() and rename
HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS.
meson.build | 4
1 file changed, 4
Hi all,
Sorry to late for V6, I was occupied by other stuff last two months, and
right now resume the submission.
Antonio Caggiano made the venus with QEMU on KVM platform last
September[1]. This series are inherited from his original work to support
the features of context init, hostmem,
Sync up kernel headers to update venus macro till they are merged into
mainline.
Signed-off-by: Huang Rui
---
Changes in v6:
- Venus capset is applied in kernel, so update it in qemu for future use.
https://lore.kernel.org/lkml/b79dcf75-c9e8-490e-644f-3b97d95f7...@collabora.com/
flight 184170 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184170/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-check fail blocked in 184162
test-amd64-amd64-xl-qemut-win7-amd64
flight 184169 xen-unstable real [real]
flight 184171 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184169/
http://logs.test-lab.xenproject.org/osstest/logs/184171/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Mon, 18 Dec 2023, Jan Beulich wrote:
> On 18.12.2023 17:07, Andrew Cooper wrote:
> > On 11/12/2023 3:56 pm, Jan Beulich wrote:
> >> On 07.12.2023 21:17, Andrew Cooper wrote:
> >>> On 07/12/2023 5:03 pm, Oleksii Kurochko wrote:
> ARCH_FIXED_CONFIG is required in the case of randconfig
>
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> Such declaration is moved in order to provide it for Arm and PPC,
> whilst not violating MISRA C:2012 Rule 8.4 in common/page_alloc.c:
> "A compatible declaration shall be visible when an object or
> function with external linkage is defined".
>
>
On Mon, 18 Dec 2023, Stefano Stabellini wrote:
> On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> > The presence of an unlinked object file triggers a violation
> > of MISRA C Rule 2.1, which is deviated, as it's not part of
> > the final Xen binary.
> >
> > No functional change.
> >
> >
On Mon, 18 Dec 2023, Federico Serafini wrote:
> Exclude efibind.h for all the architectures: it is used to build the
> efi stub, which is a separate entry point for Xen when booted from EFI
> firmware.
> Remove redundant entries from out_of_scope.ecl.
>
> Exclude common/coverage: it is code to
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> The presence of an unlinked object file triggers a violation
> of MISRA C Rule 2.1, which is deviated, as it's not part of
> the final Xen binary.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Acked-by: Stefano Stabellini
> ---
>
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> There is no path that reaches the call to 'advance_pc', thus violating MISRA C
> Rule 2.1.
> A call to ASSERT_UNREACHABLE() is added after the switch, despite this being
> useful to detect errors only in debug builds; if that marker is ever reached,
> a
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> The break statement is redundant, hence it can be removed.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> The statements after a call to the noreturn function 'do_unexpected_trap'
> can't be reached, thus violating MISRA C:2012 Rule 2.1
> ("A project shall not contain unreachable code.").
> ASSERT_UNREACHABLE() is used to signal that the unreachable break-s
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> There are no paths that can reach the last return statement
> of function 'vgic_v3_its_mmio_write' in 'vcig-v3-its.c' and
> 'arch_memory_op' in 'arch/arm/mm.c', thus violating
> MISRA C:2012 Rule 2.1:
> "A project shall not contain unreachable code".
>
On Mon, 18 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, and
> can thus be dropped.
>
> No functional changes.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Mon, 18 Dec 2023, Nicola Vetrini wrote:
> Given that 'hwdom_shutdown' is a noreturn function, unreachable
> breaks can be eliminated to resolve violations of Rule 2.1.
>
> The rename s/maybe_reboot/reboot_or_halt/ is done to clarify
> that the function is noreturn.
>
> No functional change.
>
On Mon, 18 Dec 2023, Federico Serafini wrote:
> MISRA C:2012 Rule 16.3 states that an unconditional break statement
> shall terminate every switch-clause.
>
> Update ECLAIR configuration to take into account:
> - continue, goto, return statements;
> - functions with attribute noreturn;
> -
On Mon, 18 Dec 2023, Federico Serafini wrote:
> Deviate typedef names that are delberately defined multiple times.
>
> Update docs/misra/deviations.rst accordingly.
>
> Tag Rule 5.6 as clean.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Mon, 18 Dec 2023, Jan Beulich wrote:
> On 15.12.2023 22:02, Stefano Stabellini wrote:
> > On Fri, 15 Dec 2023, Jan Beulich wrote:
> >> On 14.12.2023 23:04, Stefano Stabellini wrote:
> >>> On Thu, 14 Dec 2023, Jan Beulich wrote:
> On 14.12.2023 13:07, Simone Ballarin wrote:
> > ---
On 18/12/2023 11:36 pm, Joe Tretter wrote:
> Hi Andrew,
>
> I have tried it with your suggested command line, and it "feels" like
> it makes the issue occur less often (but one never knows with sparse
> intermittent issues).
> The first time I ran my test, it took 23 minutes before the error
>
flight 184165 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184165/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184109
This option is used to enable/disable partial emulation of registers at runtime.
While CONFIG_PARTIAL_EMULATION enables support for partial emulation at compile
time (ie adds code for partial emulation), this option may be enabled or
disabled by Yocto or other build systems.
However, customers can
There are can be situations when the registers cannot be emulated to its full
functionality. This can be due to the complexity involved. In such cases, we can
emulate those registers as RAZ/WI.
A suitable example of this is DBGDTRTX_EL0 (on Arm64) and DBGDTRTXINT(on Arm32).
As this register is not
From: Michal Orzel
Currently if user enables HVC_DCC config option in Linux, it invokes
access to debug data transfer registers (ie MDCCSR_EL0 on arm64,
DBGDTRTXINT on arm32). As these registers are not emulated, Xen injects
an undefined exception to the guest. And Linux crashes.
We wish to
Hi,
Refer
https://lore.kernel.org/all/alpine.DEB.2.22.394.2312071341540.1265976@ubuntu-linux-20-04-desktop/T/
for the previous discussion on this issue.
Also, the linux earlycon hvc driver has been fixed.
See
Le lun. 18 déc. 2023 à 18:04, Sébastien Chaumat a écrit :
>
>
>
> Le lun. 18 déc. 2023, 17:44, Jan Beulich a écrit :
>>
>> On 18.12.2023 17:21, Sébastien Chaumat wrote:
>> > On 05.12.2023 21:31, Sébastien Chaumat wrote:
>> >>> This issue seems that IRQ 7 (the GPIO controller) is natively
Pipeline #574461 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: RELEASE-4.17.3 (
https://gitlab.com/xen-project/xen/-/commits/RELEASE-4.17.3 )
Commit: 949a4aad (
https://gitlab.com/xen-project/xen/-/commit/949a4aad417621638231e4cf9f1b35e8e0328463
)
Commit
flight 184168 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184168/
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
On 27/11/2023 12:44 pm, Jan Beulich wrote:
> On 24.11.2023 23:41, Andrew Cooper wrote:
>> On 24/11/2023 8:41 am, Jan Beulich wrote:
>>> ... to a struct field, which is then going to be accompanied by other
>>> capability/control data presently living in individual variables. As
>>> this structure
On 2023-12-18 18:05, Jan Beulich wrote:
On 14.12.2023 12:44, Nicola Vetrini wrote:
--- a/xen/include/acpi/acmacros.h
+++ b/xen/include/acpi/acmacros.h
@@ -111,7 +111,7 @@
#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void,(void *)
NULL,(acpi_native_uint) i)
#define
On Mon, Dec 18, 2023 at 02:58:01PM +0100, Jan Beulich wrote:
> On 18.12.2023 13:39, Roger Pau Monné wrote:
> > On Tue, Feb 14, 2023 at 05:11:05PM +0100, Jan Beulich wrote:
> >> In order to avoid clobbering Xen's own predictions, defer the barrier as
> >> much as possible. Merely mark the CPU as
On Tue, Feb 14, 2023 at 05:12:08PM +0100, Jan Beulich wrote:
> Since both kernel and user mode run in ring 3, they run in the same
> "predictor mode".
That only true when IBRS is enabled, otherwise all CPU modes share the
same predictor mode?
> While the kernel could take care of this itself,
On 14.12.2023 12:44, Nicola Vetrini wrote:
> --- a/xen/include/acpi/acmacros.h
> +++ b/xen/include/acpi/acmacros.h
> @@ -111,7 +111,7 @@
>
> #define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void,(void *)
> NULL,(acpi_native_uint) i)
> #define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF
Le lun. 18 déc. 2023, 17:44, Jan Beulich a écrit :
> On 18.12.2023 17:21, Sébastien Chaumat wrote:
> > On 05.12.2023 21:31, Sébastien Chaumat wrote:
> >>> This issue seems that IRQ 7 (the GPIO controller) is natively fasteoi
> >>> (so level type) while in xen it is mapped to oapic-edge
On 14.12.2023 22:30, Stefano Stabellini wrote:
> On Thu, 14 Dec 2023, Nicola Vetrini wrote:
>> Resolves violations of MISRA C Rule 11.9.
>> No functional change.
>>
>> Signed-off-by: Nicola Vetrini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
On 14.12.2023 22:29, Stefano Stabellini wrote:
> On Thu, 14 Dec 2023, Nicola Vetrini wrote:
>> No functional change.
>>
>> Signed-off-by: Nicola Vetrini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
Yet it would have been really nice if style had been tidied of the lines
which
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/mm.c
> +++ b/xen/arch/riscv/mm.c
> @@ -1,19 +1,23 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
>
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
>
> #include
>
On 18.12.2023 17:21, Sébastien Chaumat wrote:
> On 05.12.2023 21:31, Sébastien Chaumat wrote:
>>> This issue seems that IRQ 7 (the GPIO controller) is natively fasteoi
>>> (so level type) while in xen it is mapped to oapic-edge instead of
>>> oapic-level
>>> as the SSDT indicates :
>>>
>>>
Pipeline #343260 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 0cc74376 (
https://gitlab.com/xen-project/xen/-/commit/0cc74376d6823e0883f89556be2a267f2240a558
)
Commit Message: x86/hvm:
> >>> On 05.12.2023 21:31, Sébastien Chaumat wrote:
> > [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
>
> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
> ioapic-edge and IRQ9 to ioapic-level ?
>
> IR-IO-APIC7-fasteoi
On 18.12.2023 17:07, Andrew Cooper wrote:
> On 11/12/2023 3:56 pm, Jan Beulich wrote:
>> On 07.12.2023 21:17, Andrew Cooper wrote:
>>> On 07/12/2023 5:03 pm, Oleksii Kurochko wrote:
ARCH_FIXED_CONFIG is required in the case of randconfig
and CI for configs that aren't ready or are not
On 18.12.2023 16:19, Roger Pau Monné wrote:
> On Tue, Feb 14, 2023 at 05:11:40PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -2005,17 +2005,26 @@ void context_switch(struct vcpu *prev, s
>> }
>> else
>> {
>> +unsigned int
On 18.12.2023 16:19, Roger Pau Monné wrote:
> On Tue, Feb 14, 2023 at 05:11:40PM +0100, Jan Beulich wrote:
>> When the outgoing vCPU had IBPB issued and RSB overwritten upon entering
>> Xen, then there's no need for a 2nd barrier during context switch.
>>
>> Note that SCF_entry_ibpb is always
On 11/12/2023 3:56 pm, Jan Beulich wrote:
> On 07.12.2023 21:17, Andrew Cooper wrote:
>> On 07/12/2023 5:03 pm, Oleksii Kurochko wrote:
>>> ARCH_FIXED_CONFIG is required in the case of randconfig
>>> and CI for configs that aren't ready or are not
>>> supposed to be implemented for specific
On 18.12.2023 16:43, Roger Pau Monné wrote:
> On Mon, Dec 18, 2023 at 02:50:27PM +0100, Jan Beulich wrote:
>> On 18.12.2023 14:46, Jan Beulich wrote:
>>> On 18.12.2023 13:11, Roger Pau Monné wrote:
Hello,
I'm not as expert as Andrew in all the speculation stuff, but I will
try
On 18.12.2023 16:40, Roger Pau Monné wrote:
> On Mon, Dec 18, 2023 at 02:46:37PM +0100, Jan Beulich wrote:
>> On 18.12.2023 13:11, Roger Pau Monné wrote:
>>> Hello,
>>>
>>> I'm not as expert as Andrew in all the speculation stuff, but I will
>>> try to provide some feedback.
>>>
>>> On Tue, Feb
On Mon, Dec 18, 2023 at 02:50:27PM +0100, Jan Beulich wrote:
> On 18.12.2023 14:46, Jan Beulich wrote:
> > On 18.12.2023 13:11, Roger Pau Monné wrote:
> >> Hello,
> >>
> >> I'm not as expert as Andrew in all the speculation stuff, but I will
> >> try to provide some feedback.
> >>
> >> On Tue, Feb
On 18/12/2023 3:34 pm, Joe Tretter wrote:
> Hello,
>
> I discussed the below problem with the QubesOS team on Github
> (https://github.com/QubesOS/qubes-issues/issues/4493) and they suggest
> that this seems to be a problem with Xen, and suggested that I post it
> to this e-mail address.
>
> I
On Mon, Dec 18, 2023 at 02:46:37PM +0100, Jan Beulich wrote:
> On 18.12.2023 13:11, Roger Pau Monné wrote:
> > Hello,
> >
> > I'm not as expert as Andrew in all the speculation stuff, but I will
> > try to provide some feedback.
> >
> > On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> Delete these functions because nothing calls these functions anymore.
>
> I introduced these APIs in commit 98563fc3ec44 ("aio: add
> aio_context_acquire() and aio_context_release()") in 2014. It's with a
> sigh of relief that I delete
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> The AioContext lock no longer has any effect. Remove it.
>
> Signed-off-by: Stefan Hajnoczi
> Reviewed-by: Eric Blake
Reviewed-by: Kevin Wolf
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> Now that the AioContext lock no longer exists, AIO_WAIT_WHILE() and
> AIO_WAIT_WHILE_UNLOCKED() are equivalent.
>
> A future patch will get rid of AIO_WAIT_WHILE_UNLOCKED().
>
> Signed-off-by: Stefan Hajnoczi
> Reviewed-by: Eric Blake
Am 05.12.2023 um 19:20 hat Stefan Hajnoczi geschrieben:
> The bdrv_co_lock() and bdrv_co_unlock() functions are already no-ops.
> Remove them.
>
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
Am 05.12.2023 um 19:19 hat Stefan Hajnoczi geschrieben:
> Since the removal of AioContext locking, the correctness of the code
> relies on running requests from a single AioContext at any given time.
>
> Add assertions that verify that callbacks are invoked in the correct
> AioContext.
>
>
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
with ...
> --- a/xen/arch/riscv/configs/tiny64_defconfig
> +++ b/xen/arch/riscv/configs/tiny64_defconfig
> @@ -24,7 +24,6 @@
> # CONFIG_COVERAGE is not set
> # CONFIG_UBSAN is not set
> #
On 18/12/2023 3:13 pm, Jan Beulich wrote:
> As observed by Roger while reviewing a somewhat related change, there's
> no need here either to open-code the (largely, i.e. once setup_max_pdx()
> was called) fixed relationship between max_pdx and max_page. Further we
> can avoid open-coding
On Tue, Feb 14, 2023 at 05:11:40PM +0100, Jan Beulich wrote:
> When the outgoing vCPU had IBPB issued and RSB overwritten upon entering
> Xen, then there's no need for a 2nd barrier during context switch.
>
> Note that SCF_entry_ibpb is always clear for the idle domain, so no
> explicit idle
As observed by Roger while reviewing a somewhat related change, there's
no need here either to open-code the (largely, i.e. once setup_max_pdx()
was called) fixed relationship between max_pdx and max_page. Further we
can avoid open-coding pfn_to_paddr() here.
Signed-off-by: Jan Beulich
---
Such declaration is moved in order to provide it for Arm and PPC,
whilst not violating MISRA C:2012 Rule 8.4 in common/page_alloc.c:
"A compatible declaration shall be visible when an object or
function with external linkage is defined".
Signed-off-by: Julien Grall
Signed-off-by: Nicola Vetrini
On 14/12/23 17:36, Jan Beulich wrote:
On 14.12.2023 13:07, Simone Ballarin wrote:
--- a/xen/include/acpi/acmacros.h
+++ b/xen/include/acpi/acmacros.h
@@ -116,7 +116,7 @@
#define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
#ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED
-#define
On 18.12.2023 12:13, Roger Pau Monné wrote:
> On Mon, Dec 18, 2023 at 09:26:24AM +0100, Jan Beulich wrote:
>> On 15.12.2023 15:54, Roger Pau Monné wrote:
>>> On Wed, Jun 07, 2023 at 08:17:30AM +0200, Jan Beulich wrote:
While frame table setup, directmap init, and boot allocator population
... in order to also deny Dom0 access through the alias ports. Without
this it is only giving the impression of denying access to PIT. Unlike
for CMOS/RTC, do detection pretty early, to avoid disturbing normal
operation later on (even if typically we won't use much of the PIT).
Like for CMOS/RTC
... in order to also deny Dom0 access through the alias ports. Without
this it is only giving the impression of denying access to both PICs.
Unlike for CMOS/RTC, do detection very early, to avoid disturbing normal
operation later on.
Like for CMOS/RTC a fundamental assumption of the probing is
By default there's already no use for this when we run in shim mode.
Plus there may also be a need to suppress the probing in case of issues
with it. Before introducing further port alias probing, introduce a
command line option allowing to bypass it, default it to on when in shim
mode, and gate
Following on from the CMOS/RTC port aliasing change, there are some
more missing restrictions; in particular there's more port aliasing to
be aware of. But first of all introduce a command line option to allow
suppressing this probing of aliases, as was requested.
Of course an alternative to all
On 12/18/2023 12:14 AM, Peter Xu wrote:
> On Wed, Dec 13, 2023 at 10:35:33AM -0500, Steven Sistare wrote:
>> Hi Peter, all have RB's, with all i's dotted and t's crossed - steve
>
> Yes this seems to be more migration related so maybe good candidate for a
> pull from migration submodule.
>
> But
Move the checking into a check hook, and add checking of the padding
fields as well.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -749,6 +749,30 @@ static int cf_check irq_load_isa(struct
return 0;
}
+static int cf_check
Loading is_master from the state save record can lead to out-of-bounds
accesses via at least the two container_of() uses by vpic_domain() and
__vpic_lock(). Make sure the value is consistent with the instance being
loaded.
For ->int_output (which for whatever reason isn't a 1-bit bitfield),
In particular pit_latch_status() and speaker_ioport_read() perform
calculations which assume in-bounds values. Several of the state save
record fields can hold wider ranges, though. Refuse to load values which
cannot result from normal operation, except mode, the init state of
which (see also
Register NULL uniformly as a first step.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v2: New.
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -374,7 +374,7 @@ static int cf_check vmce_load_vcpu_ctxt(
return err ?: vmce_restore_vcpu(v, );
}
..., at least as reasonably feasible without making a check hook
mandatory (in particular strict vs relaxed/zero-extend length checking
can't be done early this way).
Note that only one of the two uses of "real" hvm_load() is accompanied
with a "checking" one. The other directly consumes
With the request to convert bounding to actual refusal, and then
doing so in new hooks, the two previously separate patches now need
to be in a series, with infrastructure work done first. Clearly the
checking in other load handlers could (and likely wants to be) moved
to separate check handlers
Hi Jens,
> On 13 Dec 2023, at 11:31, Jens Wiklander wrote:
>
> Until now has FFA_PARTITION_INFO_GET always returned zero in w3, but
> FF-A v1.1 requires FFA_PARTITION_INFO_GET to return the size of each
> partition information descriptor returned if
> FFA_PARTITION_INFO_GET_COUNT_FLAG isn't
On 14/12/23 17:32, Jan Beulich wrote:
On 14.12.2023 13:07, Simone Ballarin wrote:
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -178,7 +178,7 @@ void __init xen_build_init(void)
if ( [1] >= __note_gnu_build_id_end )
return;
-sz = (void *)__note_gnu_build_id_end
On 14/12/23 13:36, Jan Beulich wrote:
On 14.12.2023 13:07, Simone Ballarin wrote:
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic
qualification from the type pointed
Pipeline #177680 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging-4.17 (
https://gitlab.com/xen-project/xen/-/commits/staging-4.17 )
Commit: 949a4aad (
https://gitlab.com/xen-project/xen/-/commit/949a4aad417621638231e4cf9f1b35e8e0328463
)
Commit Message:
On Mon, 2023-12-11 at 16:56 +0100, Jan Beulich wrote:
> On 07.12.2023 21:17, Andrew Cooper wrote:
> > On 07/12/2023 5:03 pm, Oleksii Kurochko wrote:
> > > ARCH_FIXED_CONFIG is required in the case of randconfig
> > > and CI for configs that aren't ready or are not
> > > supposed to be implemented
On 12.12.2023 02:48, Stefano Stabellini wrote:
> On Mon, 11 Dec 2023, Nicola Vetrini wrote:
>> No functional change.
>>
>> Signed-off-by: Nicola Vetrini
>
> Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
On 18.12.2023 14:46, Jan Beulich wrote:
> On 18.12.2023 13:11, Roger Pau Monné wrote:
>> On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote:
>>> ---
>>> I have to admit that I'm not really certain about the placement of the
>>> IBPB wrt the MSR_SPEC_CTRL writes. For now I've simply used
On 18.12.2023 13:39, Roger Pau Monné wrote:
> On Tue, Feb 14, 2023 at 05:11:05PM +0100, Jan Beulich wrote:
>> In order to avoid clobbering Xen's own predictions, defer the barrier as
>> much as possible. Merely mark the CPU as needing a barrier issued the
>> next time we're exiting to guest
flight 184162 linux-linus real [real]
flight 184166 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184162/
http://logs.test-lab.xenproject.org/osstest/logs/184166/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 18.12.2023 14:46, Jan Beulich wrote:
> On 18.12.2023 13:11, Roger Pau Monné wrote:
>> Hello,
>>
>> I'm not as expert as Andrew in all the speculation stuff, but I will
>> try to provide some feedback.
>>
>> On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote:
>>> In order to be able to
On 18.12.2023 13:11, Roger Pau Monné wrote:
> Hello,
>
> I'm not as expert as Andrew in all the speculation stuff, but I will
> try to provide some feedback.
>
> On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote:
>> In order to be able to defer the context switch IBPB to the last
>>
On Tue, Feb 14, 2023 at 05:11:05PM +0100, Jan Beulich wrote:
> In order to avoid clobbering Xen's own predictions, defer the barrier as
> much as possible. Merely mark the CPU as needing a barrier issued the
> next time we're exiting to guest context.
While I understand that doing the flush in
Hello,
I'm not as expert as Andrew in all the speculation stuff, but I will
try to provide some feedback.
On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote:
> In order to be able to defer the context switch IBPB to the last
> possible point, add logic to the exit-to-guest paths to
On 18.12.2023 12:57, Oleksii wrote:
> On Mon, 2023-12-18 at 12:36 +0100, Jan Beulich wrote:
>> On 18.12.2023 11:45, Oleksii wrote:
>>> On Thu, 2023-12-14 at 16:57 +0100, Jan Beulich wrote:
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by:
Hi all,
Merry Christmas!
Just a quick update from myself.
Whilst I can’t speak for everyone in the community, I know we have valuable
members who are committed to making the Xen Project successful. We are a
strong and passionate community made up of individuals who consistently
seek improvement
On Mon, 2023-12-18 at 12:36 +0100, Jan Beulich wrote:
> On 18.12.2023 11:45, Oleksii wrote:
> > On Thu, 2023-12-14 at 16:57 +0100, Jan Beulich wrote:
> > > On 24.11.2023 11:30, Oleksii Kurochko wrote:
> > > > Signed-off-by: Oleksii Kurochko
> > >
> > > Acked-by: Jan Beulich
> > >
> > > I
Exclude efibind.h for all the architectures: it is used to build the
efi stub, which is a separate entry point for Xen when booted from EFI
firmware.
Remove redundant entries from out_of_scope.ecl.
Exclude common/coverage: it is code to support gcov, hence it is part
of the testing machinery.
On Mon, 2023-12-18 at 12:28 +0100, Jan Beulich wrote:
> On 18.12.2023 11:39, Oleksii wrote:
> > On Thu, 2023-12-14 at 16:55 +0100, Jan Beulich wrote:
> > > On 24.11.2023 11:30, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/riscv/include/asm/current.h
> > > > +++
On Mon, 2023-12-18 at 11:12 +0100, Jan Beulich wrote:
> On 18.12.2023 11:04, Oleksii wrote:
> > On Thu, 2023-12-14 at 15:09 +0100, Jan Beulich wrote:
> > > On 24.11.2023 11:30, Oleksii Kurochko wrote:
> > > > Signed-off-by: Oleksii Kurochko
> > > > ---
> > > > Changes in V2:
> > > > - add
On 18.12.2023 11:49, Oleksii wrote:
> On Thu, 2023-12-14 at 17:04 +0100, Jan Beulich wrote:
>> On 24.11.2023 11:30, Oleksii Kurochko wrote:
>>> +static inline void cpu_relax(void)
>>> +{
>>> + int dummy;
>>> + /* In lieu of a halt instruction, induce a long-latency
>>> stall. */
>>> +
On 18.12.2023 11:45, Oleksii wrote:
> On Thu, 2023-12-14 at 16:57 +0100, Jan Beulich wrote:
>> On 24.11.2023 11:30, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>>
>> Acked-by: Jan Beulich
>>
>> I wonder though ...
>>
>>> --- a/xen/arch/riscv/include/asm/page.h
>>> +++
1 - 100 of 136 matches
Mail list logo
