On Mon, Feb 3, 2025 at 2:36 AM Jan Beulich wrote:
>
> On 01.02.2025 00:36, Tamas K Lengyel wrote:
> > On Fri, Jan 31, 2025 at 1:30 AM Jan Beulich wrote:
> >> On 31.01.2025 01:26, Tamas K Lengyel wrote:
> >>> On Thu, Jan 30, 2025 at 8:24 AM Jan Beulich wrote:
&
On Fri, Jan 31, 2025 at 1:30 AM Jan Beulich wrote:
>
> On 31.01.2025 01:26, Tamas K Lengyel wrote:
> > On Thu, Jan 30, 2025 at 8:24 AM Jan Beulich wrote:
> >>
> >> On 21.01.2025 11:19, Sergiy Kibrik wrote:
> >>> Use more generic CONFIG_VM
cess & monitor depending on it.
> >
> > Suggested-by: Jan Beulich
>
> I don't think this is applicable; my suggestion went in a different direction.
>
> > Suggested-by: Tamas K Lengyel
> > Signed-off-by: Sergiy Kibrik
>
> Before considering to
CC: Jan Beulich
> CC: Tamas K Lengyel
> Reviewed-by: Ayan Kumar Halder
> Signed-off-by: Stefano Stabellini
> Signed-off-by: Sergiy Kibrik
> ---
> changes in v2:
> - rename CONFIG_MEM_ACCESS -> CONFIG_VM_EVENT
> - tags
> ---
> xen/arch/arm/Makefile
gested-by: Jan Beulich
> Suggested-by: Tamas K Lengyel
> Signed-off-by: Sergiy Kibrik
Acked-by: Tamas K Lengyel
"uninteresting" updates to occur
> without EPT violations, improving efficiency.
>
> Considering that this feature provides a significant performance boost for
> introspection tools probably we could consider to take it to current release.
>
> I see that the patch se
On Mon, Jan 6, 2025 at 10:10 AM Jan Beulich wrote:
>
> On 06.01.2025 15:05, Tamas K Lengyel wrote:
> > On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich wrote:
> >>
> >> On 30.12.2024 07:30, Sergiy Kibrik wrote:
> >>> From: Stefano Stabellini
> >>>
On Mon, Jan 6, 2025 at 5:16 AM Jan Beulich wrote:
>
> On 30.12.2024 07:30, Sergiy Kibrik wrote:
> > From: Stefano Stabellini
> >
> > Extend coverage of CONFIG_MEM_ACCESS option and make the build of VM events
> > and monitoring support optional.
>
> Yet doesn't this end up in things becoming misl
7;t see ept_entry_t having a pw field. What's the deal there?
Never mind, I see it in the 1/2 patch, for some reason my mail client
bundled 2/2 under the cover email so I read the patches out-of-order.
Acked-by: Tamas K Lengyel
On Thu, Dec 19, 2024 at 1:17 PM Petr Beneš wrote:
>
> From: Petr Beneš
>
> This patch introduces a new XENMEM_access_r_pw permission. Functionally, it
> is similar to XENMEM_access_r, but for processors with
> TERTIARY_EXEC_EPT_PAGING_WRITE support (Intel 12th Gen/Alder Lake and later),
> it a
On Tue, Sep 10, 2024 at 6:09 AM Federico Serafini
wrote:
>
> Address a violation of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Tamas K Lengyel
On Tue, Sep 10, 2024 at 6:09 AM Federico Serafini
wrote:
>
> Address a violation of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Tamas K Lengyel
These symlinks however
are gone as oss-fuzz uses separate docker containers for the build and for the
run.
Update the oss-fuzz build script to copy the required C files into the
build folder to fix this oss-fuzz specific issue.
Signed-off-by: Tamas K Lengyel
---
tools/fuzz/oss-fuzz/build.sh | 4 ++
brik
With the commit message fixed (probably could be done when applied):
Acked-by: Tamas K Lengyel
On Mon, Jul 22, 2024 at 9:57 AM Jan Beulich wrote:
>
> On 22.07.2024 15:51, Tamas K Lengyel wrote:
> > On Mon, Jul 22, 2024 at 8:24 AM Jan Beulich wrote:
> >>
> >> On 22.07.2024 13:27, Tamas K Lengyel wrote:
> >>> This target enables integra
On Mon, Jul 22, 2024 at 8:24 AM Jan Beulich wrote:
>
> On 22.07.2024 13:27, Tamas K Lengyel wrote:
> > This target enables integration into oss-fuzz. Changing invalid input return
> > to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the
> > missing
On Mon, Jul 22, 2024 at 8:20 AM Jan Beulich wrote:
>
> On 22.07.2024 13:27, Tamas K Lengyel wrote:
> > --- /dev/null
> > +++ b/LICENSES/Apache-2.0
> > @@ -0,0 +1,202 @@
> > +
> > + Apache License
> > +
On Mon, Jul 22, 2024 at 7:34 AM Jan Beulich wrote:
>
> On 22.07.2024 13:29, Tamas K Lengyel wrote:
> > On Mon, Jul 22, 2024 at 7:08 AM Jan Beulich wrote:
> >>
> >> On 22.07.2024 13:03, Tamas K Lengyel wrote:
> >>> On Mon, Jul 22, 2024 at 5:20 AM Jan Beul
On Mon, Jul 22, 2024 at 7:08 AM Jan Beulich wrote:
>
> On 22.07.2024 13:03, Tamas K Lengyel wrote:
> > On Mon, Jul 22, 2024 at 5:20 AM Jan Beulich wrote:
> >>
> >> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> >>> This target enables integra
The build integration script for oss-fuzz targets. Future fuzzing targets can
be added to this script and those targets will be automatically picked up by
oss-fuzz without having to open separate PRs on the oss-fuzz repo.
Signed-off-by: Tamas K Lengyel
---
v3: Add Apache-2.0 to LICENSES and use
This target enables integration into oss-fuzz. Changing invalid input return
to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the
missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz
build.
Signed-off-by: Tamas K Lengyel
---
v3: don't include libf
On Mon, Jul 22, 2024 at 5:20 AM Jan Beulich wrote:
>
> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> > This target enables integration into oss-fuzz. Changing invalid input return
> > to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the
> > missing
On Thu, Jul 18, 2024 at 1:36 PM Alejandro Vallejo
wrote:
>
> On Tue Jun 25, 2024 at 11:47 PM BST, Tamas K Lengyel wrote:
> > The build integration script for oss-fuzz targets. Future fuzzing targets
> > can
> > be added to this script and those targets will be automatica
On Thu, Jul 18, 2024 at 9:03 AM Jan Beulich wrote:
>
> On 18.07.2024 14:54, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich wrote:
> >> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> >>> +cd xen
> >>
> >> This looks to s
On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich wrote:
>
> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> > --- /dev/null
> > +++ b/scripts/oss-fuzz/build.sh
> > @@ -0,0 +1,23 @@
> > +#!/bin/bash -eu
> > +# SPDX-License-Identifier: Apache-2.0
>
> Hmm. Aiui
On Thu, Jul 18, 2024 at 7:03 AM Jan Beulich wrote:
>
> On 26.06.2024 00:47, Tamas K Lengyel wrote:
> > This target enables integration into oss-fuzz. Changing invalid input return
> > to -1 as values other then 0/-1 are reserved by libfuzzer.
>
> And existing behavior
On Tue, Jul 9, 2024 at 12:12 PM Jan Beulich wrote:
>
> On 09.07.2024 17:37, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 6:47 PM Tamas K Lengyel wrote:
> >>
> >> This target enables integration into oss-fuzz. Changing invalid input
> >> return
&
On Tue, Jun 25, 2024 at 6:47 PM Tamas K Lengyel wrote:
>
> This target enables integration into oss-fuzz. Changing invalid input return
> to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the
> missing __wrap_vsnprintf wrapper which is required for successful oss-
On Wed, Jun 26, 2024 at 8:41 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 24/06/2024 23:18, Tamas K Lengyel wrote:
> > On Mon, Jun 24, 2024 at 5:58 PM Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 21/06/2024 20:14, Tamas K Lengyel wrote:
&
This target enables integration into oss-fuzz. Changing invalid input return
to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the
missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz
build.
Signed-off-by: Tamas K Lengyel
---
tools/fuzz
The build integration script for oss-fuzz targets. Future fuzzing targets can
be added to this script and those targets will be automatically picked up by
oss-fuzz without having to open separate PRs on the oss-fuzz repo.
Signed-off-by: Tamas K Lengyel
---
scripts/oss-fuzz/build.sh | 23
On Tue, Jun 25, 2024 at 10:56 AM Jan Beulich wrote:
>
> On 25.06.2024 15:40, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 9:15 AM Jan Beulich wrote:
> >>
> >> On 25.06.2024 14:40, Tamas K Lengyel wrote:
> >>> On Tue, Jun 25, 2024 at 7:52 AM Jan B
On Tue, Jun 25, 2024 at 9:18 AM Jan Beulich wrote:
>
> On 25.06.2024 14:39, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 7:40 AM Jan Beulich wrote:
> >>
> >> On 25.06.2024 13:15, Tamas K Lengyel wrote:
> >>> On Tue, Jun 25, 2024 at 5:17 AM Jan Beul
On Tue, Jun 25, 2024 at 9:15 AM Jan Beulich wrote:
>
> On 25.06.2024 14:40, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 7:52 AM Jan Beulich wrote:
> >>
> >> On 25.06.2024 13:12, Tamas K Lengyel wrote:
> >>> On Tue, Jun 25, 2024 at 2:00 AM Jan Beul
On Tue, Jun 25, 2024 at 7:52 AM Jan Beulich wrote:
>
> On 25.06.2024 13:12, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 2:00 AM Jan Beulich wrote:
> >>
> >> On 24.06.2024 23:23, Tamas K Lengyel wrote:
> >>> On Mon, Jun 24, 2024 at 11:55 AM Jan B
On Tue, Jun 25, 2024 at 7:40 AM Jan Beulich wrote:
>
> On 25.06.2024 13:15, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich wrote:
> >>
> >> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> >>> --- /dev/null
> >>&g
On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich wrote:
>
> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> > --- /dev/null
> > +++ b/scripts/oss-fuzz/build.sh
> > @@ -0,0 +1,22 @@
> > +#!/bin/bash -eu
> > +# Copyright 2024 Google LLC
> > +#
> > +# Lic
On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich wrote:
>
> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> > --- /dev/null
> > +++ b/scripts/oss-fuzz/build.sh
> > @@ -0,0 +1,22 @@
> > +#!/bin/bash -eu
> > +# Copyright 2024 Google LLC
> > +#
> > +# Lic
On Tue, Jun 25, 2024 at 2:00 AM Jan Beulich wrote:
>
> On 24.06.2024 23:23, Tamas K Lengyel wrote:
> > On Mon, Jun 24, 2024 at 11:55 AM Jan Beulich wrote:
> >>
> >> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> >>> @@ -58,6 +58,9 @@ afl-harness
On Mon, Jun 24, 2024 at 5:58 PM Julien Grall wrote:
>
> Hi,
>
> On 21/06/2024 20:14, Tamas K Lengyel wrote:
> > The build integration script for oss-fuzz targets.
>
> Do you have any details how this is meant and/or will be used?
https://google.github.io/oss-fuzz/get
On Mon, Jun 24, 2024 at 11:55 AM Jan Beulich wrote:
>
> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> > @@ -58,6 +58,9 @@ afl-harness: afl-harness.o $(OBJS) cpuid.o wrappers.o
> > afl-harness-cov: afl-harness-cov.o $(patsubst %.o,%-cov.o,$(OBJS)) cpuid.o
> > wrappers.o
This target enables integration into oss-fuzz.
Signed-off-by: Tamas K Lengyel
---
tools/fuzz/x86_instruction_emulator/Makefile| 10 --
tools/fuzz/x86_instruction_emulator/fuzz-emul.c | 6 ++
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/tools/fuzz
The build integration script for oss-fuzz targets.
Signed-off-by: Tamas K Lengyel
---
scripts/oss-fuzz/build.sh | 22 ++
1 file changed, 22 insertions(+)
create mode 100755 scripts/oss-fuzz/build.sh
diff --git a/scripts/oss-fuzz/build.sh b/scripts/oss-fuzz/build.sh
new
m_access.c
> as well and provide stubs in asm/mem_access.h for the users of this
> header.
>
> Signed-off-by: Alessandro Zucchelli
Acked-by: Tamas K Lengyel
> -ap2m = array_access_nospec(d->arch.altp2m_p2m, altp2m_idx);
> +ap2m = d->arch.altp2m_p2m[altp2m_idx];
Why is it no longer necessary to use array_access_nospec?
Tamas
On Fri, May 17, 2024 at 9:55 AM Oleksii Kurochko
wrote:
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Tamas K Lengyel
On Fri, May 17, 2024 at 9:55 AM Oleksii Kurochko
wrote:
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Tamas K Lengyel
> Currently altp2m support provided for VT-d only, so option is dependant on
> VMX.
No clue what is meant by "support provided for VT-d only". Altp2m has
nothing to do with VT-d. It would be more accurate to say it's only
implemented for Intel EPT.
Tamas
On Wed, May 8, 2024 at 12:26 PM Julien Grall wrote:
>
> Hi Tamas,
>
> On 08/05/2024 17:01, Tamas K Lengyel wrote:
> > On Wed, May 8, 2024 at 10:02 AM Alessandro Zucchelli
> > wrote:
> >>
> >> On 2024-05-03 11:32, Julien Grall wrote:
> >>> Hi,
On Wed, May 8, 2024 at 10:02 AM Alessandro Zucchelli
wrote:
>
> On 2024-05-03 11:32, Julien Grall wrote:
> > Hi,
> >
> > On 03/05/2024 08:09, Alessandro Zucchelli wrote:
> >> On 2024-04-29 17:58, Jan Beulich wrote:
> >>> On 29.04.2024 17:45, Alessandro Zucchelli wrote:
> Change #ifdef CONFIG_
pping required the singlestep
> monitor to be explicitly enabled through xc_monitor_singlestep, even though
> it operates entirely within Xen and does not generate external events.
>
> Signed-off-by: Petr Beneš
Acked-by: Tamas K Lengyel
On Tue, Apr 16, 2024 at 3:29 AM Andrew Cooper wrote:
>
> On 16/04/2024 7:31 am, Sergiy Kibrik wrote:
> > Instead of using generic CONFIG_HVM option switch to a bit more specific
> > CONFIG_VMX option for altp2m support, as it depends on VMX. Also guard
> > altp2m routines, so that it can be disabl
On Tue, Apr 2, 2024 at 3:24 AM Federico Serafini
wrote:
>
> Add break statement to address a violation of MISRA C:2012 Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause ").
>
> No functional change.
>
> Signed-off-by
On Wed, Feb 28, 2024 at 8:28 AM Roger Pau Monné wrote:
>
> On Wed, Feb 28, 2024 at 12:18:31PM +0100, Jan Beulich wrote:
> > On 28.02.2024 11:53, Roger Pau Monné wrote:
> > > On Fri, Feb 23, 2024 at 08:43:24AM +0100, Jan Beulich wrote:
> > >> On 22.02.2024 19:03,
On Thu, Feb 22, 2024 at 5:06 AM Jan Beulich wrote:
>
> On 22.02.2024 10:05, Roger Pau Monne wrote:
> > The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the same
> > can be achieved with an atomic increment, which is both simpler to read, and
> > avoid any need for a loop.
> >
>
his has been a known bug that awaited a fix for a long time.
Reviewed-by: Tamas K Lengyel
On Thu, Feb 8, 2024 at 9:00 AM Jan Beulich wrote:
>
> On 08.02.2024 14:45, Tamas K Lengyel wrote:
> > On Thu, Feb 8, 2024 at 2:46 AM Jan Beulich wrote:
> >>
> >> On 08.02.2024 05:32, George Dunlap wrote:
> >>> Er, ok, just one more commen
On Thu, Feb 8, 2024 at 2:46 AM Jan Beulich wrote:
>
> On 08.02.2024 05:32, George Dunlap wrote:
> > Er, ok, just one more comment: this could allow an altp2m to have more
> > permissions than the host; for example, the host p2m entry could be
> > p2m_access_r, but if the altp2m's default_access we
On Wed, Feb 7, 2024 at 5:21 PM Andrew Cooper wrote:
>
> On 07/02/2024 1:18 am, George Dunlap wrote:
> > On Tue, Feb 6, 2024 at 6:08 PM Petr Beneš wrote:
> >> From: Petr Beneš
> >>
> >> This patch addresses a behavior discrepancy in the handling of altp2m
> >> views,
> >> where upon the creation
y reducing the overhead associated with setting memory access permissions
> across the altp2m range.
>
> Signed-off-by: Petr Beneš
Acked-by: Tamas K Lengyel
functions from which
> aren't available in case of !CONFIG_MEM_ACCESS.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Oleksii Kurochko
Acked-by: Tamas K Lengyel
; Signed-off-by: Oleksii Kurochko
> Acked-by: Jan Beulich
Acked-by: Tamas K Lengyel
states, but there's no support for that in the code at all
>so leave a TODO for when we finally start working on nested-virt in
>earnest.
>
> Reported-by: Reima Ishii
> Signed-off-by: Andrew Cooper
Reviewed-by: Tamas K Lengyel
On Fri, Jan 5, 2024 at 2:34 AM Jan Beulich wrote:
>
> On 04.01.2024 18:13, Tamas K Lengyel wrote:
> > Fix warning:
> > (XEN) UBSAN: Undefined behaviour in arch/x86/cpu/mwait-idle.c:1300:44
> > (XEN) left shift of 15 by 28 places cannot be represented in type 'int&#x
> > Getting ~0 back is strictly less bad than getting stack rubble because
> > at least it's obviously wrong.
>
> But then why not change things so there's no issue anymore? Plus I'm not
> sure how / whether "obviously wrong" would manifest. I expect it would
> be an entirely unobvious boot hang, o
Fix warning:
(XEN) UBSAN: Undefined behaviour in arch/x86/cpu/mwait-idle.c:1300:44
(XEN) left shift of 15 by 28 places cannot be represented in type 'int'
Signed-off-by: Tamas K Lengyel
Fixes: 5a211704e88 ("mwait-idle: prevent SKL-H boot failure when C8+C9+C10
enabled"
On Wed, Dec 20, 2023 at 6:53 AM Julien Grall wrote:
>
> Hi Federico,
>
> On 20/12/2023 11:03, Federico Serafini wrote:
> > Refactor of the code to have a break statement at the end of the
> > switch-clause. This addresses violations of Rule 16.3
> > ("An unconditional `break' statement shall termi
Hi all,
I think this form is bad and is not helpful. We ought to be able to
recommend an alternative term beside "broken" and "deprecated". I
would not use the term broken in this context but that also doesn't
mean we shouldn't use it in any context. But also in this context
deprecated is not the r
acquired some lines above by rcu_lock_live_remote_domain_by_id.
>
> Fixes: 72f8d45d69b8 ("x86/mem_sharing: enable mem_sharing on first memop")
>
> > Signed-off-by: Frediano Ziglio
>
> Reviewed-by: Andrew Cooper
Acked-by: Tamas K Lengyel
On Wed, Nov 22, 2023 at 11:27 AM Andrew Cooper
wrote:
>
> On 22/11/2023 4:26 pm, Frediano Ziglio wrote:
> > ambigious -> ambiguous
> >
> > Signed-off-by: Frediano Ziglio
>
> Acked-by: Andrew Cooper
Not sure if it's still needed but either case:
Acked-by: Tamas K Lengyel
On Wed, Nov 1, 2023 at 3:21 PM Andrew Cooper wrote:
>
> Right now, vvmx will blindly copy L12's ACTIVITY_STATE into the L02 VMCS and
> enter the vCPU. Luckily for us, nested-virt is explicitly unsupported for
> security bugs.
>
> The inactivity states are HLT, SHUTDOWN and WAIT-FOR-SIPI, and as n
On Fri, Oct 20, 2023 at 6:57 AM Andrew Cooper wrote:
>
> On 20/10/2023 2:14 am, Henry Wang wrote:
> > Hi all,
> >
> >> On Oct 20, 2023, at 07:48, Andrew Cooper wrote:
> >>
> >> On 18/10/2023 9:02 am, Tamas K Lengyel wrote:
> >>> When mappi
_info page to same gfn during fork")
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 94b6b782ef..142258f16a 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++
f-by: Nicola Vetrini
Acked-by: Tamas K Lengyel
On Mon, Oct 9, 2023 at 2:55 AM Nicola Vetrini
wrote:
>
> The function is used only within this file, and therefore can be static.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Acked-by: Tamas K Lengyel
> page.
>
> Fixes: 41548c5472a3 ('mem_sharing: VM forking')
> Signed-off-by: Roger Pau Monné
Re-sending due to mailserver issues:
Acked-by: Tamas K Lengyel
with the
> backing function yet to be filled in).
>
> Signed-off-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
Acked-by: Tamas K Lengyel
On Tue, Oct 3, 2023 at 11:07 AM Julien Grall wrote:
>
> Hi Roger,
>
> On 03/10/2023 15:29, Roger Pau Monné wrote:
> > On Tue, Oct 03, 2023 at 09:53:11AM -0400, Tamas K Lengyel wrote:
>
> Tamas, somehow your e-mails don't show up in my inbox (even if I am
> CCed
On Wed, Aug 16, 2023 at 12:30 PM Oleksii Kurochko
wrote:
>
> Signed-off-by: Oleksii Kurochko
> ---
> xen/arch/riscv/include/asm/vm_event.h | 52 +++
> 1 file changed, 52 insertions(+)
> create mode 100644 xen/arch/riscv/include/asm/vm_event.h
I don't think we ought to r
On Thu, May 4, 2023 at 3:44 AM Jan Beulich wrote:
>
> On 03.05.2023 19:14, Tamas K Lengyel wrote:
> >> @@ -1974,7 +2046,10 @@ int mem_sharing_fork_reset(struct domain
> >>
> >> state:
> >> if ( reset_state )
> >> +{
> >>
> @@ -1974,7 +2046,10 @@ int mem_sharing_fork_reset(struct domain
>
> state:
> if ( reset_state )
> +{
> rc = copy_settings(d, pd);
> +/* TBD: What to do here with -ERESTART? */
Ideally we could avoid hitting code-paths that are restartable during fork
reset since it ge
On Wed, Mar 29, 2023 at 10:29 PM Johnson, Ethan
wrote:
>
> On 2023-03-16 02:14:18 +, Andrew Cooper wrote:
> > Ok, so there is a lot here. Apologies in advance for the overly long
> > answer.
> >
> > First, while altp2m was developed in parallel with EPTP-switching, we
> > took care to split t
On Tue, Mar 28, 2023 at 4:59 AM Jan Beulich wrote:
>
> On 21.03.2023 14:58, Dmitry Isaykin wrote:
> > Adds monitor support for I/O instructions.
> >
> > Signed-off-by: Dmitry Isaykin
> > Signed-off-by: Anton Belousov
>
> Acked-by: Jan Beulich
Acked-by: Tamas K Lengyel
On Tue, Mar 21, 2023 at 3:49 AM Ковалёв Сергей wrote:
>
>
>
> 21.03.2023 2:34, Tamas K Lengyel пишет:
> >
> >
> > On Mon, Mar 20, 2023 at 3:23 PM Ковалёв Сергей > <mailto:va...@list.ru>> wrote:
> > >
> > >
> > >
> >
On Mon, Mar 20, 2023 at 3:34 PM Andrew Cooper
wrote:
>
> On 20/03/2023 7:22 pm, Ковалёв Сергей wrote:
> >
> > 21.03.2023 1:51, Tamas K Lengyel wrote:
> >> On Mon, Mar 20, 2023 at 12:32 PM Ковалёв Сергей >> <mailto:va...@list.ru>> wrote:
> >>
On Mon, Mar 20, 2023 at 3:23 PM Ковалёв Сергей wrote:
>
>
>
> 21.03.2023 1:51, Tamas K Lengyel wrote:
> >
> >
> > On Mon, Mar 20, 2023 at 12:32 PM Ковалёв Сергей > <mailto:va...@list.ru>> wrote:
> > >
> > > gva_to_gfn command used
On Mon, Mar 20, 2023 at 12:32 PM Ковалёв Сергей wrote:
>
> gva_to_gfn command used for fast address translation in LibVMI project.
> With such a command it is possible to perform address translation in
> single call instead of series of queries to get every page table.
You have a couple assumptio
> Are you actually sure you want to tie the vm-event interface to the ioreq
> one (this is also a question to you, Tamas)? It would look slightly better
> to me if this was a simple boolean named after its purpose (e.g. "write"
> or "out" when it's meant to be set for OUT / OUTS and clear for IN /
On Wed, Mar 15, 2023 at 2:55 PM Dmitry Isaykin
wrote:
>
> Adds monitor support for I/O instructions.
>
> Signed-off-by: Dmitry Isaykin
> Signed-off-by: Anton Belousov
Acked-by: Tamas K Lengyel
On Fri, Mar 10, 2023 at 10:57 PM Dmitry Isaykin
wrote:
>
> Adds monitor support for I/O instructions.
>
> Signed-off-by: Dmitry Isaykin
> Signed-off-by: Anton Belousov
> ---
> tools/include/xenctrl.h| 1 +
> tools/libs/ctrl/xc_monitor.c | 13 +
> xen/arch/
On Wed, Feb 22, 2023 at 5:48 AM Jan Beulich wrote:
>
> On 21.02.2023 16:59, Tamas K Lengyel wrote:
> > On Tue, Feb 21, 2023 at 8:54 AM Jan Beulich wrote:
> >>
> >> On 15.02.2023 18:07, Tamas K Lengyel wrote:
> >>> An assert failure has been o
On Tue, Feb 21, 2023 at 8:54 AM Jan Beulich wrote:
>
> On 15.02.2023 18:07, Tamas K Lengyel wrote:
> > An assert failure has been observed in p2m_teardown when performing vm
> > forking and then destroying the forked VM (p2m-basic.c:173). The assert
> > checks whether t
On Thu, Feb 16, 2023 at 10:24 AM Jan Beulich wrote:
>
> On 16.02.2023 16:10, Tamas K Lengyel wrote:
> > On Thu, Feb 16, 2023 at 9:27 AM Jan Beulich wrote:
> >>
> >> On 16.02.2023 13:22, Tamas K Lengyel wrote:
> >>> On Thu, Feb 16, 2023 at 3:31 AM Jan B
On Thu, Feb 16, 2023 at 9:27 AM Jan Beulich wrote:
>
> On 16.02.2023 13:22, Tamas K Lengyel wrote:
> > On Thu, Feb 16, 2023 at 3:31 AM Jan Beulich wrote:
> >>
> >> On 15.02.2023 17:29, Tamas K Lengyel wrote:
> >>> On Wed, Feb 15, 2023 at 5:27 AM Jan B
On Thu, Feb 16, 2023 at 3:31 AM Jan Beulich wrote:
>
> On 15.02.2023 17:29, Tamas K Lengyel wrote:
> > On Wed, Feb 15, 2023 at 5:27 AM Jan Beulich wrote:
> >> Did you consider the alternative of adjusting the ASSERT() in question
> >> instead? It could reas
only happen after mem_sharing already relinquished all shared pages.
In this patch we flip the order in which relinquish ops are called to avoid
tripping the assert.
Signed-off-by: Tamas K Lengyel
Fixes: e7aa55c0aab3 ("x86/p2m: free the paging memory pool preemptively")
---
v2: comsetic
On Wed, Feb 15, 2023 at 6:03 AM Jan Beulich wrote:
>
> On 14.02.2023 06:07, Tamas K Lengyel wrote:
> > When VM forking is initiated a VM is not supposed to try to perform
mem_sharing
> > yet as the fork process hasn't completed all required steps. However,
the vCPU
>
On Wed, Feb 15, 2023 at 5:27 AM Jan Beulich wrote:
>
> On 14.02.2023 06:07, Tamas K Lengyel wrote:
> > An assert failure has been observed at p2m-basic.c:173 when performing
vm
>
> Please can you at least also name the function here? The line number is
> going to change, an
ff-by: Tamas K Lengyel
---
xen/arch/x86/include/asm/hvm/domain.h | 8
xen/arch/x86/mm/mem_sharing.c | 10 +++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/include/asm/hvm/domain.h
b/xen/arch/x86/include/asm/hvm/domain.h
index 698455444e..76a08
after
mem_sharing already relinquished all shared pages.
In this patch we flip the order in which relinquish ops are called to avoid
tripping the assert.
Signed-off-by: Tamas K Lengyel
---
Note: it is unclear why this assert hasn't tripped in the past. It hasn't
been observed with 4.17-r
1 - 100 of 1102 matches
Mail list logo
