On 20.04.2020 19:53, Julien Grall wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1517,20 +1517,23 @@ long do_vcpu_op(int cmd, unsigned int vc
>> return rc;
>> }
>> -#ifdef VM_ASSIST_VALID
>> -long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
On 20.04.2020 22:16, Andrew Cooper wrote:
> On 14/04/2020 12:34, Jan Beulich wrote:
>> In preparation for the addition of VMASST_TYPE_runstate_update_flag
>> commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
>> the hypercall for Arm. I consider it not logical that it then
At 15:06 +0200 on 20 Apr (1587395210), Jan Beulich wrote:
> On 18.04.2020 11:03, Tim Deegan wrote:
> > At 16:28 +0200 on 17 Apr (1587140897), Jan Beulich wrote:
> >> sh_remove_write_access() bails early for !external guests, and hence its
> >> building and thus the need for the hook can be
On Mon, Apr 20, 2020 at 10:09 AM Tamas K Lengyel wrote:
>
> On Mon, Apr 20, 2020 at 9:51 AM Jan Beulich wrote:
> >
> > On 20.04.2020 16:27, Tamas K Lengyel wrote:
> > > On Mon, Apr 20, 2020 at 8:19 AM Jan Beulich wrote:
> > >>
> > >> On 20.04.2020 16:15, Tamas K Lengyel wrote:
> > >>> On Mon,
On 20/04/2020 21:38, Jaromír Doleček wrote:
> Hello,
>
> I'm working on NetBSD Xen support.
>
> Recently, we've switched to grant version 2 mainly for the improved
> status handling,
Really? The status handling is certainly different, but v2 is much
harder to use correctly.
> and eventually
Hello,
I'm working on NetBSD Xen support.
Recently, we've switched to grant version 2 mainly for the improved
status handling, and eventually for copy-only subpage grant support,
which I'd like to experiment with in our netback driver. Currently we
don't need the 64-bit frame, which I found was
On 14/04/2020 12:34, Jan Beulich wrote:
> In preparation for the addition of VMASST_TYPE_runstate_update_flag
> commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
> the hypercall for Arm. I consider it not logical that it then isn't also
> exposed to x86 HVM guests (with the
On 14/04/2020 12:35, Jan Beulich wrote:
> While I can't spot anything that would go wrong, just like the
> respective hypercall only permits applicable bits to be set, we should
> also do so when loading guest context.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Acked-by: Andrew
On 16/04/2020 12:44, Wieczorkiewicz, Pawel wrote:
>>> +}
>>> +
>>> static void xen_console_write(const char *buf, size_t len)
>>> {
>>> hypercall_console_write(buf, len);
>>> @@ -246,7 +253,14 @@ static void xen_console_write(const char *buf, size_t
>>> len)
>>> void arch_setup(void)
>>> {
On 20/04/2020 20:26, Andrew Cooper wrote:
---
common/libc/vsnprintf.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
index a49fd30..3202137 100644
--- a/common/libc/vsnprintf.c
+++
On 16/04/2020 12:36, Wieczorkiewicz, Pawel wrote:
>> Unfortunately, this comes with collateral damage.
>>
>> # ./xtf-runner hvm64 example
>> Executing 'xl create -p tests/example/test-hvm64-example.cfg'
>> Executing 'xl console test-hvm64-example'
>> Executing 'xl unpause test-hvm64-example'
>>
The CET spec has been published and guest kernels are starting to get support.
Introduce the CPUID and MSRs, and fully block the MSRs from guest use.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
tools/libxl/libxl_cpuid.c | 2 ++
On 20/04/2020 15:05, Jan Beulich wrote:
> On 17.04.2020 17:50, Andrew Cooper wrote:
>> This is the start of some performance and security-hardening improvements,
>> based on the fact that 32bit PV guests are few and far between these days.
>>
>> Ring1 is full or architectural corner cases, such as
Hi Jan,
On 14/04/2020 12:34, Jan Beulich wrote:
In preparation for the addition of VMASST_TYPE_runstate_update_flag
commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
the hypercall for Arm. I consider it not logical that it then isn't also
exposed to x86 HVM guests (with
Hi Paul,
On 07/04/2020 18:38, Paul Durrant wrote:
... and update xen-domctx to dump some information describing the record.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
v2:
-
On 20/04/2020 14:47, Roger Pau Monné wrote:
> On Fri, Apr 17, 2020 at 04:50:02PM +0100, Andrew Cooper wrote:
>> This is the start of some performance and security-hardening improvements,
>> based on the fact that 32bit PV guests are few and far between these days.
>>
>> Ring1 is full or
Hi Paul,
On 07/04/2020 18:38, Paul Durrant wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 1ad34c35eb..8ab39acf0c 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -38,7 +38,7 @@
#include "hvm/save.h"
#include "memory.h"
Hi Paul,
On 07/04/2020 18:38, Paul Durrant wrote:
To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.
Currently there is a framework (entered
On 20/04/2020 16:47, Jan Beulich wrote:
> On 20.04.2020 16:39, Andrew Cooper wrote:
>> On 20/04/2020 15:12, Jan Beulich wrote:
>>> On 17.04.2020 17:50, Andrew Cooper wrote:
There is no need for the Compat GDT if there are no 32bit PV guests. This
saves 4k per online CPU
On Mon, Apr 20, 2020 at 9:51 AM Jan Beulich wrote:
>
> On 20.04.2020 16:27, Tamas K Lengyel wrote:
> > On Mon, Apr 20, 2020 at 8:19 AM Jan Beulich wrote:
> >>
> >> On 20.04.2020 16:15, Tamas K Lengyel wrote:
> >>> On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monné
> >>> wrote:
>
> On
On 20.04.2020 16:27, Tamas K Lengyel wrote:
> On Mon, Apr 20, 2020 at 8:19 AM Jan Beulich wrote:
>>
>> On 20.04.2020 16:15, Tamas K Lengyel wrote:
>>> On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monné
>>> wrote:
On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
> When
On 20.04.2020 16:39, Andrew Cooper wrote:
> On 20/04/2020 15:12, Jan Beulich wrote:
>> On 17.04.2020 17:50, Andrew Cooper wrote:
>>> There is no need for the Compat GDT if there are no 32bit PV guests. This
>>> saves 4k per online CPU
>>>
>>> Bloat-o-meter reports the following savings in Xen
> -Original Message-
> From: Julien Grall
> Sent: 20 April 2020 15:15
> To: p...@xen.org; 'Jan Beulich' ;
> xen-devel@lists.xenproject.org
> Cc: 'Andrew Cooper' ; 'George Dunlap'
> ; 'Ian
> Jackson' ; 'Stefano Stabellini'
> ; 'Wei Liu'
>
> Subject: Re: [PATCH 0/3] xenoprof: XSA-313
This will cause all SYSCALL/SYSRET instructions to suffer #UD rather than
following the MSR_{L,C}STAR pointers, allowing us to drop the star_enter()
panic helper, allowing us to clean up the IST stacks in a subsequent patch.
Drop the now-dead conditional SYSENTER logic in the middle of
ISTs are used to force a stack switch on CPL0=>0 interrupts/exceptions. They
however come with a nasty corner case in the case of reentrancy where the
outer exception frame gets clobbered.
When the SYSCALL/SYSRET instructions aren't used, there is no need to use IST
for anything other than #DF,
This make the S3 BSP path consistent with AP paths, and reduces the amount of
state needing stashing specially. Also, it takes care of re-setting up Xen's
LBR configuration if requested, which was missing previously.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau
Various bits of cleanup for !CONFIG_PV builds.
Andrew Cooper (3):
x86/S3: Use percpu_traps_init() rather than opencoding SYSCALL/SYSENTER
restoration
x86/boot: Don't enable EFER.SCE for !CONFIG_PV builds
x86/pv: Don't use IST for NMI/#MC/#DB in !CONFIG_PV builds
On 20/04/2020 15:12, Jan Beulich wrote:
> On 17.04.2020 17:50, Andrew Cooper wrote:
>> There is no need for the Compat GDT if there are no 32bit PV guests. This
>> saves 4k per online CPU
>>
>> Bloat-o-meter reports the following savings in Xen itself:
>>
>> add/remove: 0/3 grow/shrink: 1/4
On Mon, Apr 20, 2020 at 8:19 AM Jan Beulich wrote:
>
> On 20.04.2020 16:15, Tamas K Lengyel wrote:
> > On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monné
> > wrote:
> >>
> >> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
> >>> When a forked VM is being reset while having
On Mon, Apr 20, 2020 at 1:57 AM Roger Pau Monné wrote:
>
> On Fri, Apr 17, 2020 at 10:06:32AM -0700, Tamas K Lengyel wrote:
> > The memory sharing subsystem by default doesn't allow a domain to share
> > memory
> > if it has an IOMMU active for obvious security reasons. However, when
> >
On 20.04.2020 16:15, Tamas K Lengyel wrote:
> On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monné wrote:
>>
>> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
>>> When a forked VM is being reset while having vm_events active, re-copying
>>> the
>>> vCPU info page can lead to events
On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monné wrote:
>
> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
> > When a forked VM is being reset while having vm_events active, re-copying
> > the
> > vCPU info page can lead to events being lost. This seems to only affect a
> >
On 17.04.2020 17:50, Andrew Cooper wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -49,6 +49,22 @@ config PV
>
> If unsure, say Y.
>
> +config PV32
> + bool "Support for 32bit PV guests"
> + depends on PV
> + default y
I guess I can see why you don't
Hi Paul,
On 15/04/2020 09:50, Paul Durrant wrote:
-Original Message-
From: Jan Beulich
Sent: 15 April 2020 09:45
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper ; George Dunlap
; Ian Jackson
; Julien Grall ; Stefano Stabellini
; Wei Liu ; Paul Durrant
Subject: [PATCH 0/3]
On 17.04.2020 17:50, Andrew Cooper wrote:
> There is no need for the Compat GDT if there are no 32bit PV guests. This
> saves 4k per online CPU
>
> Bloat-o-meter reports the following savings in Xen itself:
>
> add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605)
> Function
On 17.04.2020 17:50, Andrew Cooper wrote:
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -215,7 +215,7 @@ int switch_compat(struct domain *d)
> return 0;
>
> d->arch.has_32bit_shinfo = 1;
> -d->arch.is_32bit_pv = 1;
> +d->arch.pv.is_32bit = 1;
>
>
On 17.04.2020 17:50, Andrew Cooper wrote:
> This is the start of some performance and security-hardening improvements,
> based on the fact that 32bit PV guests are few and far between these days.
>
> Ring1 is full or architectural corner cases, such as counting as supervisor
... full of ...
>
On 18.04.2020 00:24, Stefano Stabellini wrote:
> +Backport Tag
> +
> +
> +A backport tag is an optional tag in the commit message to request a
> +given commit to be backported to the stable trees:
> +
> +Backport: 4.9+
> +
> +It marks a commit for being a candidate for backports to
On Fri, Apr 17, 2020 at 04:50:02PM +0100, Andrew Cooper wrote:
> This is the start of some performance and security-hardening improvements,
> based on the fact that 32bit PV guests are few and far between these days.
>
> Ring1 is full or architectural corner cases, such as counting as supervisor
On 20.04.2020 15:34, Julien Grall wrote:
> Hi Jan,
>
> On 20/04/2020 09:04, Jan Beulich wrote:
>> On 19.04.2020 12:49, Julien Grall wrote:
>>> --- a/docs/misc/pvcalls.pandoc
>>> +++ b/docs/misc/pvcalls.pandoc
>>> @@ -246,9 +246,7 @@ The format is defined as follows:
>>> uint32_t
On 20.04.20 15:06, Sergey Dyasli wrote:
Currently it might be not obvious which scheduling mode (e.g. core-
scheduling) is being used by the scheduler. Alleviate this by printing
additional information about the selected granularity per-cpupool.
Note: per-cpupool granularity selection is not
On 16/04/2020 12:51, Wieczorkiewicz, Pawel wrote:
>> On 16. Apr 2020, at 12:36, Andrew Cooper wrote:
>>
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content is safe.
>>
>>
>>
>> On
Thank you Juergen and Dario!
On 4/16/2020 12:09 PM, Dario Faggioli wrote:
> On Wed, 2020-04-15 at 11:08 +0200, Jürgen Groß wrote:
>> On 27.03.20 20:30, Jeff Kubascik wrote:
>>> For each UNIT, sched_set_affinity is called before unit->priv is
>>> updated
>>> to the new cpupool private UNIT data
On 17.04.2020 16:42, Anthony PERARD wrote:
> On Fri, Apr 17, 2020 at 03:39:48PM +0200, Jan Beulich wrote:
>> On 17.04.2020 15:19, Anthony PERARD wrote:
>>> Or do you mean keeping exception to the rule? And hope that when someone
>>> changes the rule, it doesn't forget to check if the exception
On 16/04/2020 13:14, Jan Beulich wrote:
> The special AMD behavior of leaving SS mostly alone wasn't really
> complete: We need to adjust CPL aka SS.DPL.
>
> Signed-off-by: Jan Beulich
Oops.
Reviewed-by: Andrew Cooper
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++
Hi Jan,
On 20/04/2020 09:04, Jan Beulich wrote:
On 19.04.2020 12:49, Julien Grall wrote:
--- a/docs/misc/pvcalls.pandoc
+++ b/docs/misc/pvcalls.pandoc
@@ -246,9 +246,7 @@ The format is defined as follows:
uint32_t domain;
uint32_t type;
While it's described as errata for gen8/9, the previous reporting was from
2015 which predates those generations. I tested it on a gen 7 box (which
was causing me the grief of consuming my Xen console buffer). It could be
the case that the FPD code isn't implemented (which wouldn't matter for
On 20.04.2020 15:06, Sergey Dyasli wrote:
> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -40,6 +40,30 @@ static DEFINE_SPINLOCK(cpupool_lock);
> static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
> static unsigned int __read_mostly
Currently it might be not obvious which scheduling mode (e.g. core-
scheduling) is being used by the scheduler. Alleviate this by printing
additional information about the selected granularity per-cpupool.
Note: per-cpupool granularity selection is not implemented yet.
The single global
On 18.04.2020 11:03, Tim Deegan wrote:
> At 16:28 +0200 on 17 Apr (1587140897), Jan Beulich wrote:
>> sh_remove_write_access() bails early for !external guests, and hence its
>> building and thus the need for the hook can be suppressed altogether in
>> !HVM configs.
>>
>> Signed-off-by: Jan
On Mon, Apr 20, 2020 at 02:36:49PM +0200, Jan Beulich wrote:
> On 20.04.2020 12:27, Wei Liu wrote:
> > On Mon, Apr 20, 2020 at 10:31:28AM +0100, Julien Grall wrote:
> >> On 17/04/2020 23:24, Stefano Stabellini wrote:
> >>> Create a new document under docs/process to describe our special tags.
>
Sure.
I will make it a bit later, when I have the more stable result.
Best regards,
Alexander
>Понедельник, 20 апреля 2020, 8:59 +03:00 от Oleksandr Andrushchenko
>:
>
>Hi,
>
>On 4/19/20 14:26, Santucco wrote:
>> Hello,
>> I have found a source of the problem.
>> In displ_be, BaseDump
On 20/04/2020 13:35, Jan Beulich wrote:
On 20.04.2020 14:31, Jan Beulich wrote:
On 20.04.2020 14:20, Julien Grall wrote:
On 20/04/2020 13:12, Jan Beulich wrote:
On 20.04.2020 14:08, Julien Grall wrote:
Are the unions plain ones? I could see room for behavior like
the one you describe with
On 20.04.2020 12:27, Wei Liu wrote:
> On Mon, Apr 20, 2020 at 10:31:28AM +0100, Julien Grall wrote:
>> On 17/04/2020 23:24, Stefano Stabellini wrote:
>>> Create a new document under docs/process to describe our special tags.
>>> Add a description of the Fixes tag and the new Backport tag. Also
>>>
On 20.04.2020 14:31, Jan Beulich wrote:
> On 20.04.2020 14:20, Julien Grall wrote:
>> On 20/04/2020 13:12, Jan Beulich wrote:
>>> On 20.04.2020 14:08, Julien Grall wrote:
>>> Are the unions plain ones? I could see room for behavior like
>>> the one you describe with transparent unions, albeit
On 20.04.2020 14:20, Julien Grall wrote:
> Hi,
>
> On 20/04/2020 13:12, Jan Beulich wrote:
>> On 20.04.2020 14:08, Julien Grall wrote:
>>> On 20/04/2020 08:26, Jan Beulich wrote:
On 17.04.2020 19:13, Julien Grall wrote:
> FWIW, the different matters on Arm. Although, it looks like the
Hi,
On 20/04/2020 13:12, Jan Beulich wrote:
On 20.04.2020 14:08, Julien Grall wrote:
On 20/04/2020 08:26, Jan Beulich wrote:
On 17.04.2020 19:13, Julien Grall wrote:
FWIW, the different matters on Arm. Although, it looks like the
compiler will not warn you if you are using the wrong handler
On 20.04.2020 12:10, Julien Grall wrote:
> Hi,
>
> On 20/04/2020 10:16, Jan Beulich wrote:
>> On 18.04.2020 12:23, Julien Grall wrote:
>>> On 30/03/2020 08:52, Jan Beulich wrote:
On 28.03.2020 11:52, Julien Grall wrote:
> On 26/03/2020 15:39, Jan Beulich wrote:
>> On 22.03.2020
Hi Christian,
On 16/04/2020 14:25, Christian Lindig wrote:
The changes in the OCaml C stubs look good to me. They don't really touch the
interface but are mostly concerned with types on the C side by adding casts,
const, and so on. The extended error handling is an improvement.
Thank you
On 20.04.2020 14:08, Julien Grall wrote:
> On 20/04/2020 08:26, Jan Beulich wrote:
>> On 17.04.2020 19:13, Julien Grall wrote:
>>> FWIW, the different matters on Arm. Although, it looks like the
>>> compiler will not warn you if you are using the wrong handler :(.
>>
>> I find this highly
Hi Jan,
On 20/04/2020 08:26, Jan Beulich wrote:
On 17.04.2020 19:13, Julien Grall wrote:
On 17/04/2020 10:44, Jan Beulich wrote:
On 17.04.2020 10:37, Julien Grall wrote:
On 16/04/2020 16:46, Jan Beulich wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1779,7 +1779,8 @@
On Mon, Apr 20, 2020 at 10:31:28AM +0100, Julien Grall wrote:
> Hi Stefano,
>
> On 17/04/2020 23:24, Stefano Stabellini wrote:
> > Create a new document under docs/process to describe our special tags.
> > Add a description of the Fixes tag and the new Backport tag. Also
> > clarify that lines
Hi,
On 20/04/2020 10:16, Jan Beulich wrote:
On 18.04.2020 12:23, Julien Grall wrote:
On 30/03/2020 08:52, Jan Beulich wrote:
On 28.03.2020 11:52, Julien Grall wrote:
On 26/03/2020 15:39, Jan Beulich wrote:
On 22.03.2020 17:14, jul...@xen.org wrote:
@@ -3116,24 +3116,24 @@ int
Hi Jan,
On 20/04/2020 07:03, Jan Beulich wrote:
On 18.04.2020 13:14, Julien Grall wrote:
On 16/04/2020 16:48, Jan Beulich wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2151,16 +2151,17 @@ static int mod_l1_entry(l1_pgentry_t *pl
paging_mode_translate(pg_dom) )
Hi Stefano,
On 17/04/2020 23:24, Stefano Stabellini wrote:
Create a new document under docs/process to describe our special tags.
Add a description of the Fixes tag and the new Backport tag. Also
clarify that lines with tags should not be split.
Signed-off-by: Stefano Stabellini
CC: Ian
On 18.04.2020 13:43, Julien Grall wrote:
> On 18/04/2020 12:01, Julien Grall wrote:
>> On 26/03/2020 15:54, Jan Beulich wrote:
>>> On 22.03.2020 17:14, jul...@xen.org wrote:
From: Julien Grall
Note that the code is now using cr3_to_mfn() to get the MFN. This is
slightly
On 18.04.2020 12:23, Julien Grall wrote:
> On 30/03/2020 08:52, Jan Beulich wrote:
>> On 28.03.2020 11:52, Julien Grall wrote:
>>> On 26/03/2020 15:39, Jan Beulich wrote:
On 22.03.2020 17:14, jul...@xen.org wrote:
> @@ -3116,24 +3116,24 @@ int vcpu_destroy_pagetables(struct vcpu *v)
>
> -Original Message-
> From: Markus Armbruster
> Sent: 20 April 2020 09:33
> To: qemu-de...@nongnu.org
> Cc: Stefano Stabellini ; Anthony Perard
> ; Paul
> Durrant ; xen-devel@lists.xenproject.org
> Subject: [PATCH 09/11] xen/pt: Fix flawed conversion to realize()
>
> The conversion of
The conversion of xen_pt_initfn() to xen_pt_realize() blindly replaced
XEN_PT_ERR() by error_setg(). Several error conditions that did not
fail xen_pt_initfn() now fail xen_pt_realize(). Unsurprisingly, the
cleanup on these errors looks highly suspicious.
Revert the inappropriate replacements.
On 19.04.2020 12:49, Julien Grall wrote:
> --- a/docs/misc/pvcalls.pandoc
> +++ b/docs/misc/pvcalls.pandoc
> @@ -246,9 +246,7 @@ The format is defined as follows:
> uint32_t domain;
> uint32_t type;
> uint32_t protocol;
> -
On Fri, Apr 17, 2020 at 10:06:32AM -0700, Tamas K Lengyel wrote:
> The memory sharing subsystem by default doesn't allow a domain to share memory
> if it has an IOMMU active for obvious security reasons. However, when fuzzing
> a
> VM fork, the same security restrictions don't necessarily apply.
On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote:
> When a forked VM is being reset while having vm_events active, re-copying the
> vCPU info page can lead to events being lost. This seems to only affect a
> subset of events (interrupts), while not others (cpuid, MTF, EPT) thus it
On 17.04.2020 19:13, Julien Grall wrote:
> On 17/04/2020 10:44, Jan Beulich wrote:
>> On 17.04.2020 10:37, Julien Grall wrote:
>>> On 16/04/2020 16:46, Jan Beulich wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1779,7 +1779,8 @@ void
On 18.04.2020 13:14, Julien Grall wrote:
> On 16/04/2020 16:48, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -2151,16 +2151,17 @@ static int mod_l1_entry(l1_pgentry_t *pl
>> paging_mode_translate(pg_dom) )
>> {
>> p2m_type_t
74 matches
Mail list logo
