> On 20. Apr 2020, at 21:26, 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 16/04/2020 12:36, Wieczorkiewicz, Pawel wrote:
>>> Unf
On 20.04.2020 19:08, Andrew Cooper wrote:
> 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. Thi
On 20.04.2020 20:05, Andrew Cooper wrote:
> 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.
>>>
>>> Ring
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 isn
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 suppress
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, Ap
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 for
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 r
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 s
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
+++ b/common/libc
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 ++
tools/
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 th
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:
- Dr
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 architectur
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"
-#de
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
Bloat-o
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 Fri
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 itse
> -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 fol
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
subarch_per
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, w
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 Mo
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
xen/arch/x86/acpi/suspend.
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 up/d
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 vm_event
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
> > fuzzing
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 b
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
> > subse
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 w
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] xenopro
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 imp
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 str
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 need
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
> +++ b/xen/arch/x86/x86_em
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
gen8/
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 sched_granu
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 valu
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 Beulich
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 t
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 still
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 17:14,
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 fo
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 suspiciou
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 @@ void
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 wit
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 vcpu_destroy_p
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 Jackso
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 differe
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 x
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. W
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 wa
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 p2m_mem_paging_populate(struct
76 matches
Mail list logo
