On 27.09.19 17:49, Ross Lagerwall wrote:
Other parts of the kernel expect these nonblocking EFI callbacks to
exist and crash when running under Xen. Since the implementations of
xen_efi_set_variable() and xen_efi_query_variable_info() do not take any
locks, use them for the nonblocking callbacks
> On 30. Sep 2019, at 17:13, Ross Lagerwall wrote:
>
> On 9/28/19 4:13 PM, Pawel Wieczorkiewicz wrote:
>> Extend the XC python bindings library to support also all common
snip
>>
>> +
>> +fd = open(filename, O_RDONLY);
>> +if ( fd < 0 )
>> +goto error;
>> +
>> +if ( fstat(f
Today the EFI runtime functions are setup in architecture specific
code (x86 and arm), with the functions themselves living in drivers/xen
as they are not architecture dependent.
As the setup is exactly the same for arm and x86 move the setup to
drivers/xen, too. This at once removes the need to m
flight 142082 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142082/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 01.10.2019 00:38, Roman Shaposhnik wrote:
> Btw, forgot to attach the patch with maxcpus=2 -- interestingly enough
> Xen seems to hang much further down than before (basically after
> attempting to build out Dom0)
All 3 logs contain
(XEN) TSC_DEADLINE disabled due to Errata; please update micr
Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
domain, migration may be needlessly vetoed due to the check of
is_iommu_enabled() in paging_log_dirty_enable().
There is actually no need to prevent logdirty from being enabled unless
devices are assigned to a domain and that d
On 01.10.19 10:28, Paul Durrant wrote:
Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
domain, migration may be needlessly vetoed due to the check of
is_iommu_enabled() in paging_log_dirty_enable().
There is actually no need to prevent logdirty from being enabled unless
de
On 01.10.2019 10:25, Juergen Gross wrote:
> @@ -281,4 +270,26 @@ void xen_efi_reset_system(int reset_type, efi_status_t
> status,
> BUG();
> }
> }
> -EXPORT_SYMBOL_GPL(xen_efi_reset_system);
> +
> +/*
> + * Set XEN EFI runtime services function pointers. Other fields of struct
On 30.09.2019 21:16, Andrew Cooper wrote:
> Clang in particular has a habit of out-of-lining these and creating multiple
> local copies of _mfn() and mfn_x(), etc. Override this behaviour.
Is special casing the typesafe helpers then the right approach? The
fundamental idea after all is to let the
> -Original Message-
> From: Xen-devel On Behalf Of Paul
> Durrant
> Sent: 30 September 2019 17:38
> To: 'Jürgen Groß' ; 'Jan Beulich'
> Cc: 'xen-devel@lists.xenproject.org' ;
> 'osstest service owner'
>
> Subject: Re: [Xen-devel] [xen-unstable test] 141990: regressions - FAIL
>
> > -
On 01.10.2019 10:28, Paul Durrant wrote:
> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
> domain, migration may be needlessly vetoed due to the check of
> is_iommu_enabled() in paging_log_dirty_enable().
> There is actually no need to prevent logdirty from being enabled u
> -Original Message-
> From: Jan Beulich
> Sent: 01 October 2019 09:46
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Roger Pau Monne
> ; George Dunlap ; Juergen
> Gross ; Wei
> Liu
> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto
>
Some cleanups based on top of:
[PATCH v1] xen/balloon: Set pages PageOffline() in balloon_add_region()
Make the PG_offline less error prone, by simply setting PG_offline when
they enter the page list and clearing PG_offline when they leave the
page list.
Only compile-tested.
David Hildenbran
Let's simply use balloon_append() directly.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Signed-off-by: David Hildenbrand
---
drivers/xen/balloon.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
ind
Let's move the clearing to balloon_retrieve(). In
bp_state increase_reservation(), we now clear the flag a little earlier
than before, however, this should not matter for XEN.
Suggested-by: Boris Ostrovsky
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Signed-off-by: David Hilden
Let's move the __SetPageOffline() call which all callers perform into
balloon_append().
In bp_state decrease_reservation(), pages are now marked PG_offline a
little later than before, however, this should not matter for XEN.
Suggested-by: Boris Ostrovsky
Cc: Boris Ostrovsky
Cc: Juergen Gross
C
+Juergen
On 01/10/2019 02:05, Stefano Stabellini wrote:
On Sun, 29 Sep 2019, Julien Grall wrote:
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build
The write-discard property of the type can't be represented in IOMMU
page table entries. Make sure the respective checks / tracking can't
race, by utilizing the domain lock. The other sides of the sharing/
paging/log-dirty exclusion checks should subsequently perhaps also be
put under that lock the
...if there is no IOMMU or it is globally disabled.
Without this patch, the following assertion may be hit:
xl: libxl_create.c:589: libxl__domain_make: Assertion `info->passthrough !=
LIBXL_PASSTHROUGH_ENABLED' failed.
This is because libxl__domain_create_info_setdefault() currently only sets
a
On 01.10.19 11:12, Paul Durrant wrote:
...if there is no IOMMU or it is globally disabled.
Without this patch, the following assertion may be hit:
xl: libxl_create.c:589: libxl__domain_make: Assertion `info->passthrough !=
LIBXL_PASSTHROUGH_ENABLED' failed.
This is because libxl__domain_creat
Hi Andrew,
On 01/10/2019 00:21, Andrew Cooper wrote:
On 30/09/2019 21:17, Julien Grall wrote:
Hi,
On 9/30/19 7:24 PM, Andrew Cooper wrote:
The code generation for barrier_nospec_true() is not correct. We are
taking a
perf it from the added fences, but not gaining any speculative safety.
s/
On 01.10.2019 10:52, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 01 October 2019 09:46
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Roger Pau Monne
>> ; George Dunlap ; Juergen
>> Gross ; Wei
>> Liu
>> Subject: Re: [Xen-devel
On 01.10.2019 11:17, Julien Grall wrote:
> On 01/10/2019 00:21, Andrew Cooper wrote:
>> On 30/09/2019 21:17, Julien Grall wrote:
>>> My worry is this gate config gate nothing on Arm so the user may have
>>> a false sense that it can be used (even though it is clearly BROKEN).
>>>
>>> Also the name
On 30.09.19 23:58, Stefano Stabellini wrote:
Hi Stefano
On Sat, 28 Sep 2019, Julien Grall wrote:
On 28/09/2019 00:52, Oleksandr Tyshchenko wrote:
сб, 28 сент. 2019 г., 01:50 Stefano Stabellini mailto:sstabell...@kernel.org>>:
On Thu, 26 Sep 2019, Oleksandr wrote:
> On 26.09.19 17
On 01.10.19 11:02, Julien Grall wrote:
+Juergen
On 01/10/2019 02:05, Stefano Stabellini wrote:
On Sun, 29 Sep 2019, Julien Grall wrote:
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
Release-acked-by: Juergen Gross
Juergen
___
Xen
Hi Stefano,
On 30/09/2019 22:12, Stefano Stabellini wrote:
On Sun, 29 Sep 2019, Julien Grall wrote:
On 9/27/19 12:11 AM, Stefano Stabellini wrote:
+return 0;
+}
+/*
+ * xen,path specifies the corresponding node in the host DT.
+ * Both interrupt mappings and IOMMU setti
Hi Jan,
On 01/10/2019 10:22, Jan Beulich wrote:
On 01.10.2019 11:17, Julien Grall wrote:
On 01/10/2019 00:21, Andrew Cooper wrote:
On 30/09/2019 21:17, Julien Grall wrote:
My worry is this gate config gate nothing on Arm so the user may have
a false sense that it can be used (even though it i
Hi Stefano,
On 01/10/2019 00:24, Stefano Stabellini wrote:
On Mon, 30 Sep 2019, Julien Grall wrote:
Hi Oleksandr,
On 30/09/2019 10:34, Oleksandr wrote:
On 28.09.19 02:28, Stefano Stabellini wrote:
I have to admit that I don't know about dom0less feature enough ...
But, shouldn't we check i
> -Original Message-
> From: Jan Beulich
> Sent: 01 October 2019 10:19
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; xen-devel@lists.xenproject.org; Juergen Gross
> ; Wei Liu
>
> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto
>
On 01/10/2019 10:26, Julien Grall wrote:
> Hi Jan,
>
> On 01/10/2019 10:22, Jan Beulich wrote:
>> On 01.10.2019 11:17, Julien Grall wrote:
>>> On 01/10/2019 00:21, Andrew Cooper wrote:
On 30/09/2019 21:17, Julien Grall wrote:
> My worry is this gate config gate nothing on Arm so the user m
Hi Andrew,
On 01/10/2019 10:41, Andrew Cooper wrote:
On 01/10/2019 10:26, Julien Grall wrote:
Hi Jan,
On 01/10/2019 10:22, Jan Beulich wrote:
On 01.10.2019 11:17, Julien Grall wrote:
On 01/10/2019 00:21, Andrew Cooper wrote:
On 30/09/2019 21:17, Julien Grall wrote:
My worry is this gate co
Hi,
On 01/10/2019 02:15, Stefano Stabellini wrote:
On Sun, 29 Sep 2019, Julien Grall wrote:
On 4/18/19 7:03 PM, Stefano Stabellini wrote:
On Wed, 17 Apr 2019, Julien Grall wrote:
On 4/17/19 9:45 PM, Stefano Stabellini wrote:
On Wed, 27 Mar 2019, Julien Grall wrote:
But then if clang is alre
On 01/10/2019 02:22, Stefano Stabellini wrote:
On Mon, 30 Sep 2019, Stefano Stabellini wrote:
On Sun, 29 Sep 2019, Julien Grall wrote:
Hi,
Sorry, I am picking up this series again.
On 4/18/19 7:03 PM, Stefano Stabellini wrote:
On Wed, 17 Apr 2019, Julien Grall wrote:
Hi,
On 4/17/19 9:45
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monne
> Sent: 30 September 2019 14:32
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant ;
> Wei Liu ; Jan
> Beulich ; Roger Pau Monne
> Subject: [Xen-devel] [PATCH v3 01/10] ioreq: terminate cf8 handli
On 30/09/2019 14:32, Roger Pau Monne wrote:
> diff --git a/xen/include/asm-x86/hvm/ioreq.h b/xen/include/asm-x86/hvm/ioreq.h
> index 65491c48d2..c3917aa74d 100644
> --- a/xen/include/asm-x86/hvm/ioreq.h
> +++ b/xen/include/asm-x86/hvm/ioreq.h
> @@ -54,6 +54,12 @@ unsigned int hvm_broadcast_ioreq(io
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monne
> Sent: 30 September 2019 14:33
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant ;
> Wei Liu ; Jan
> Beulich ; Roger Pau Monne
> Subject: [Xen-devel] [PATCH v3 06/10] ioreq: allow registering in
Currently only suspend power control requests wait for an ack from the
domain, while power off or reboot requests simply write the command to
xenstore and exit.
Introduce a 1 minute wait for the domain to acknowledge the request, or
else return an error. The suspend code is slightly modified to us
On 01.10.2019 11:36, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 01 October 2019 10:19
>> To: Paul Durrant
>> Cc: Andrew Cooper ; George Dunlap
>> ; Roger Pau
>> Monne ; xen-devel@lists.xenproject.org; Juergen Gross
>> ; Wei Liu
>>
>> Subject: Re: [Xen-devel
> On 1 Oct 2019, at 11:12, Roger Pau Monne wrote:
>
> + libxl_asyncop_how *ao_how = aohow_val(async);
>
> caml_enter_blocking_section();
> - ret = libxl_domain_shutdown(CTX, c_domid);
> + ret = libxl_domain_shutdown(CTX, c_domid, ao_how);
> caml_leave_blocking_section()
> -Original Message-
> From: Jan Beulich
> Sent: 01 October 2019 11:15
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; xen-devel@lists.xenproject.org; Juergen Gross
> ; Wei Liu
>
> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto
>
On 10/1/19 11:24 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 01 October 2019 11:15
>> To: Paul Durrant
>> Cc: Andrew Cooper ; George Dunlap
>> ; Roger Pau
>> Monne ; xen-devel@lists.xenproject.org; Juergen Gross
>> ; Wei Liu
>>
>> Subject: Re: [Xen-devel
Rewrite of the commit message:
Before the problematic commit, libxl used to ignore error when
destroying (force == true) a passthrough device, especially error that
happens when dealing with the DM.
Since fae4880c45fe, if the DM failed to detach the pci device within
the allowed time, the timed o
On Tue, Oct 01, 2019 at 12:18:41PM +0200, Christian Lindig wrote:
>
>
> > On 1 Oct 2019, at 11:12, Roger Pau Monne wrote:
> >
> > + libxl_asyncop_how *ao_how = aohow_val(async);
> >
> > caml_enter_blocking_section();
> > - ret = libxl_domain_shutdown(CTX, c_domid);
> > + ret = libxl_
> -Original Message-
> From: Xen-devel On Behalf Of Roger
> Pau Monne
> Sent: 30 September 2019 14:33
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant ;
> Wei Liu ; Jan
> Beulich ; Roger Pau Monne
> Subject: [Xen-devel] [PATCH v3 07/10] ioreq: allow decoding acces
Paul Durrant writes ("[PATCH-for-4.13] libxl: choose an appropriate default for
passthrough..."):
> ...if there is no IOMMU or it is globally disabled.
>
> Without this patch, the following assertion may be hit:
>
> xl: libxl_create.c:589: libxl__domain_make: Assertion `info->passthrough !=
> L
-Original Message-
> From: George Dunlap
> Sent: 01 October 2019 11:34
> To: Paul Durrant ; 'Jan Beulich'
> Cc: Andrew Cooper ; Roger Pau Monne
> ; xen-
> de...@lists.xenproject.org; Juergen Gross ; Wei Liu
>
> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto
>
On Tue, Oct 01, 2019 at 10:57:13AM +0100, Andrew Cooper wrote:
> On 30/09/2019 14:32, Roger Pau Monne wrote:
> > diff --git a/xen/include/asm-x86/hvm/ioreq.h
> > b/xen/include/asm-x86/hvm/ioreq.h
> > index 65491c48d2..c3917aa74d 100644
> > --- a/xen/include/asm-x86/hvm/ioreq.h
> > +++ b/xen/includ
On 30.09.2019 20:24, Andrew Cooper wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -77,6 +77,27 @@ config HAS_CHECKPOLICY
> string
> option env="XEN_HAS_CHECKPOLICY"
>
> +menu "Speculative hardening"
> +
> +config SPECULATIVE_ARRAY_HARDEN
Seeing also the new item in
> -Original Message-
> From: Ian Jackson
> Sent: 01 October 2019 11:39
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
> ;
> Juergen Gross
> Subject: Re: [PATCH-for-4.13] libxl: choose an appropriate default for
> passthrough...
>
> Paul Durrant write
On 01.10.2019 12:40, Paul Durrant wrote:
>> From: George Dunlap
>> Sent: 01 October 2019 11:34
>>
>> One thing we could imagine is that when specific devices have an active
>> emulator (or whatever) propagating the dirty information, for that code
>> to tell Xen, "I am implementing dirty tracking
> -Original Message-
> From: Jan Beulich
> Sent: 01 October 2019 11:50
> To: Paul Durrant
> Cc: George Dunlap ; Andrew Cooper
> ; Roger Pau
> Monne ; xen-devel@lists.xenproject.org; Juergen Gross
> ; Wei Liu
>
> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto
>
On 10/1/19 11:40 AM, Paul Durrant wrote:
> -Original Message-
>> From: George Dunlap
>> Sent: 01 October 2019 11:34
>> To: Paul Durrant ; 'Jan Beulich'
>> Cc: Andrew Cooper ; Roger Pau Monne
>> ; xen-
>> de...@lists.xenproject.org; Juergen Gross ; Wei Liu
>>
>> Subject: Re: [Xen-devel
On 01/10/2019 09:46, Jan Beulich wrote:
> On 01.10.2019 10:28, Paul Durrant wrote:
>> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
>> domain, migration may be needlessly vetoed due to the check of
>> is_iommu_enabled() in paging_log_dirty_enable().
>> There is actually no
On Tue, Oct 01, 2019 at 11:07:55AM +0200, Jan Beulich wrote:
> The write-discard property of the type can't be represented in IOMMU
> page table entries. Make sure the respective checks / tracking can't
> race, by utilizing the domain lock. The other sides of the sharing/
> paging/log-dirty exclusi
On 01.10.2019 13:30, Roger Pau Monné wrote:
> On Tue, Oct 01, 2019 at 11:07:55AM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/dm.c
>> +++ b/xen/arch/x86/hvm/dm.c
>> @@ -255,16 +255,33 @@ static int set_mem_type(struct domain *d
>>
>> mem_type = array_index_nospec(data->mem_type, ARRA
On Tue, Oct 01, 2019 at 12:12:59PM +0200, Roger Pau Monne wrote:
> Currently only suspend power control requests wait for an ack from the
> domain, while power off or reboot requests simply write the command to
> xenstore and exit.
>
> Introduce a 1 minute wait for the domain to acknowledge the re
On Mon, Sep 30, 2019 at 11:33:14AM +0100, Hongyan Xia wrote:
> From: Wei Liu
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
>
> ---
> Changed since v1:
> * use a global mapping for compat_idle_pg_table_l2, otherwise
> l2_ro_mpt will unmap it.
Hmmm... I wonder why XTF didn't cat
> On 1 Oct 2019, at 11:12, Roger Pau Monne wrote:
>
> tools/ocaml/libs/xl/xenlight_stubs.c | 18 ---
Acked-by: Christian Lindig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Mon, Sep 30, 2019 at 11:32:52AM +0100, Hongyan Xia wrote:
> This series is mostly Wei's effort to switch from xenheap to domheap for
> Xen page tables. In addition, I have also merged several bug fixes from
> my "Remove direct map from Xen" series [1]. As the title suggests, this
> series switch
On 01.10.2019 13:08, Andrew Cooper wrote:
> On 01/10/2019 09:46, Jan Beulich wrote:
>> On 01.10.2019 10:28, Paul Durrant wrote:
>>> Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
>>> domain, migration may be needlessly vetoed due to the check of
>>> is_iommu_enabled() in pa
On 30.09.2019 20:24, Andrew Cooper wrote:
> The code generation for barrier_nospec_true() is not correct. We are taking a
> perf it from the added fences, but not gaining any speculative safety.
You want to be more specific here, I think: ISTR you saying that the LFENCEs
get inserted at the wrong
On 01/10/2019 11:45, Jan Beulich wrote:
> On 30.09.2019 20:24, Andrew Cooper wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -77,6 +77,27 @@ config HAS_CHECKPOLICY
>> string
>> option env="XEN_HAS_CHECKPOLICY"
>>
>> +menu "Speculative hardening"
>> +
>> +config SPEC
On Tue, 1 Oct 2019 at 12:09, George Dunlap wrote:
>
> On 10/1/19 11:40 AM, Paul Durrant wrote:
> > -Original Message-
> >> From: George Dunlap
> >> Sent: 01 October 2019 11:34
> >> To: Paul Durrant ; 'Jan Beulich'
> >>
> >> Cc: Andrew Cooper ; Roger Pau Monne
> >> ; xen-
> >> de...@li
Ping? Can I get a response on this (w.r.t. 'enabled' vs. 'unknown')
before doing a v2? This issue is currently blocking a push, I believe.
On Tue, 1 Oct 2019 at 11:48, Paul Durrant wrote:
>
> > -Original Message-
> > From: Ian Jackson
> > Sent: 01 October 2019 11:39
> > To: Paul Durrant
Paul Durrant writes ("Re: [Xen-devel] [PATCH-for-4.13] libxl: choose an
appropriate default for passthrough..."):
> Ping? Can I get a response on this (w.r.t. 'enabled' vs. 'unknown')
> before doing a v2? This issue is currently blocking a push, I believe.
I definitely think we should introduce "
On 01/10/2019 13:21, Jan Beulich wrote:
> On 30.09.2019 20:24, Andrew Cooper wrote:
>> The code generation for barrier_nospec_true() is not correct. We are taking
>> a
>> perf it from the added fences, but not gaining any speculative safety.
> You want to be more specific here, I think: ISTR you
flight 142099 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142099/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 10/1/19 1:32 PM, Paul Durrant wrote:
> On Tue, 1 Oct 2019 at 12:09, George Dunlap wrote:
>>
>> On 10/1/19 11:40 AM, Paul Durrant wrote:
>>> -Original Message-
From: George Dunlap
Sent: 01 October 2019 11:34
To: Paul Durrant ; 'Jan Beulich'
Cc: Andrew Cooper
On Tue, Oct 01, 2019 at 12:12:59PM +0200, Roger Pau Monne wrote:
> I believe applying this patch is not going to cause regressions in
> osstest, albeit FreeBSD doesn't acknowledge poweroff/reboot requests
> in the currently tested versions, it will shutdown in less than one
> minute, and thus the t
On Tue, 1 Oct 2019 at 14:06, George Dunlap wrote:
>
[snip]
> But the question is, do we want the toolstack to have to become an
> expert in what hardware might have external dirty tracking, and whether
> such tracking is active? At the moment that would mean either 1)
> puttin
Anthony PERARD writes ("Re: [PATCH] libxl: wait for the ack when issuing power
control requests"):
> On Tue, Oct 01, 2019 at 12:12:59PM +0200, Roger Pau Monne wrote:
> > I believe applying this patch is not going to cause regressions in
> > osstest, albeit FreeBSD doesn't acknowledge poweroff/rebo
On 01/10/2019 12:51, Wei Liu wrote:
On Mon, Sep 30, 2019 at 11:33:14AM +0100, Hongyan Xia wrote:
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed since v1:
* use a global mapping for compat_idle_pg_table_l2, otherwise
l2_ro_mpt will unmap it.
Hmmm... I w
On 30/09/2019 11:33, Hongyan Xia wrote:
From: Wei Liu
This then requires moving declaration of root page table mfn into mm.h
and modify setup_cpu_root_pgt to have a single exit path.
We also need to force map_domain_page to use direct map when switching
per-domain mappings. This is contrary to
xennet_fill_frags() uses ~0U as return value when the sk_buff is not able
to cache extra fragments. This is incorrect because the return type of
xennet_fill_frags() is RING_IDX and 0x is an expected value for
ring buffer index.
In the situation when the rsp_cons is approaching 0x,
flight 142062 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 140282
test-amd64-i386-q
On Tue, Oct 01, 2019 at 01:40:57PM +0200, Jan Beulich wrote:
> On 01.10.2019 13:30, Roger Pau Monné wrote:
> > On Tue, Oct 01, 2019 at 11:07:55AM +0200, Jan Beulich wrote:
> >> --- a/xen/arch/x86/hvm/dm.c
> >> +++ b/xen/arch/x86/hvm/dm.c
> >> @@ -255,16 +255,33 @@ static int set_mem_type(struct do
On 01.10.2019 15:29, Paul Durrant wrote:
> The changes in XAPI are not vast; the main complexity is in the device
> emulator (to provide information during the live phase of migration)
> but I still don't see why Citrix's choice of closed vs. open source
> implementation of the emulator really has
flight 142051 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
133580
test-amd64-i38
The code generation for barrier_nospec_true() is not correct; the lfence
instructions are generally too early in the instruction stream, resulting in a
performance hit but no additional speculative safety.
This is caused by inline assembly trying to fight the compiler optimiser, and
the optimiser
There are legitimate circumstance where array hardening is not wanted or
needed. Allow it to be turned off.
Signed-off-by: Andrew Cooper
Release-acked-by: Juergen Gross
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Juergen Gross
v2:
* Rename to CONFIG_SPECULATIVE_HARDEN_ARRAY
*
The main purpose is patch 2. The "l1tf-barrier" work currently causes a perf
hit and gains no safety, and is therefore unfit for inclusion into Xen 4.13 at
this time.
See individual patches for changes from v1.
Andrew Cooper (2):
xen/nospec: Introduce CONFIG_SPECULATIVE_HARDEN_ARRAY
xen/nosp
On 01.10.2019 14:51, Andrew Cooper wrote:
> On 01/10/2019 13:21, Jan Beulich wrote:
>> On 30.09.2019 20:24, Andrew Cooper wrote:
>>> The code generation for barrier_nospec_true() is not correct. We are
>>> taking a
>>> perf it from the added fences, but not gaining any speculative safety.
>> You
On Tue, 1 Oct 2019 at 15:24, Jan Beulich wrote:
>
> On 01.10.2019 15:29, Paul Durrant wrote:
> > The changes in XAPI are not vast; the main complexity is in the device
> > emulator (to provide information during the live phase of migration)
> > but I still don't see why Citrix's choice of closed v
Hi Julien,
On Sat, Sep 07, 2019 at 11:05:45AM +0100, Julien Grall wrote:
> On 9/6/19 6:20 PM, Andrew Cooper wrote:
> > On 06/09/2019 17:00, Arnd Bergmann wrote:
> > > On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper
> > > wrote:
> > > > On 06/09/2019 16:39, Arnd Bergmann wrote:
> > > > > HYPERVISOR_
On 01.10.2019 16:15, Roger Pau Monné wrote:
> On Tue, Oct 01, 2019 at 01:40:57PM +0200, Jan Beulich wrote:
>> On 01.10.2019 13:30, Roger Pau Monné wrote:
>>> On Tue, Oct 01, 2019 at 11:07:55AM +0200, Jan Beulich wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pc
On 01.10.19 15:56, Dongli Zhang wrote:
xennet_fill_frags() uses ~0U as return value when the sk_buff is not able
to cache extra fragments. This is incorrect because the return type of
xennet_fill_frags() is RING_IDX and 0x is an expected value for
ring buffer index.
In the situation when
On 01/10/2019 15:33, Mark Rutland wrote:
Hi Julien,
Hi Mark,
On Sat, Sep 07, 2019 at 11:05:45AM +0100, Julien Grall wrote:
On 9/6/19 6:20 PM, Andrew Cooper wrote:
On 06/09/2019 17:00, Arnd Bergmann wrote:
On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper wrote:
On 06/09/2019 16:39, Arnd Ber
On Tue, Oct 01, 2019 at 03:39:41PM +0100, Julien Grall wrote:
> On 01/10/2019 15:33, Mark Rutland wrote:
> > On Sat, Sep 07, 2019 at 11:05:45AM +0100, Julien Grall wrote:
> > > On 9/6/19 6:20 PM, Andrew Cooper wrote:
> > > > On 06/09/2019 17:00, Arnd Bergmann wrote:
> > > > > On Fri, Sep 6, 2019 at
On 01.10.2019 16:32, Andrew Cooper wrote:
> There are legitimate circumstance where array hardening is not wanted or
> needed. Allow it to be turned off.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with one more question (I'm sorry, I meant to ask on v1 but then
forgot):
> --- a
...if there is no IOMMU or it is globally disabled.
Without this patch, the following assertion may be hit:
xl: libxl_create.c:589: libxl__domain_make: Assertion `info->passthrough !=
LIBXL_PASSTHROUGH_UNKNOWN' failed.
This is because libxl__domain_create_info_setdefault() currently only sets
a
This is mostly a cosmetic patch to avoid the default enumeration value
being 'enabled'. The only non-cosmetic parts are in xl_parse.c where it now
becomes necessary to explicitly parse the 'enabled' value for xl.cfg
'passthrough' option, and error on the value 'unknown', because there is no
longer
This was originally a single patch, which is now patch #2 of this series.
Paul Durrant (2):
libxl: replace 'enabled' with 'unknown' in libxl_passthrough
enumeration
libxl: choose an appropriate default for passthrough...
tools/libxl/libxl_create.c | 10 +++---
tools/libxl/libxl_type
In case a user process using xenbus has open transactions and is killed
e.g. via ctrl-C the following cleanup of the allocated resources might
result in a deadlock due to trying to end a transaction in the xenbus
worker thread:
[ 2551.474706] INFO: task xenbus:37 blocked for more than 120 seconds.
Hi,
I am reviving the thread. I think we need a patch similar to this one for Xen
4.13. This is because generic are now used by Xen so they should be hidden from
the hardware domain.
Andrii, Oleksandr, can one of you look at it?
Cheers,
On 21/01/2019 17:04, Andrii Anisov wrote:
From: Oleks
On 01.10.19 16:57, Paul Durrant wrote:
This was originally a single patch, which is now patch #2 of this series.
Paul Durrant (2):
libxl: replace 'enabled' with 'unknown' in libxl_passthrough
enumeration
libxl: choose an appropriate default for passthrough...
tools/libxl/libxl_crea
On Tue, Oct 01, 2019 at 12:44:38PM +0100, Anthony PERARD wrote:
> On Tue, Oct 01, 2019 at 12:12:59PM +0200, Roger Pau Monne wrote:
> > -return libxl__xs_printf(gc, t, shutdown_path, "%s", cmd);
> > +rc = libxl__xs_printf(gc, XBT_NULL, shutdown_path, "%s", cmd);
> > +if (rc)
> > +
Now that xl.cfg has an option to explicitly enable IOMMU mappings for a
domain, migration may be needlessly vetoed due to the check of
is_iommu_enabled() in paging_log_dirty_enable().
There is actually no need to prevent logdirty from being enabled unless
devices are assigned to a domain and that d
On 30.09.19 23:56, Stefano Stabellini wrote:
Hi Stefano
Some Device Trees may expose both legacy SMMU and generic IOMMU bindings
together. However, the SMMU driver in Xen is only supporting the legacy
SMMU bindings, leading to fatal initialization errors at boot time.
This patch fixes the boo
Currently execution of panic() continues until Xen's panic notifier
(xen_panic_event()) is called at which point we make a hypercall that
never returns.
This means that any notifier that is supposed to be called later as
well as significant part of panic() code (such as pstore writes from
kmsg_dum
On Tue, Oct 01, 2019 at 02:54:19PM +0100, Hongyan Xia wrote:
> On 30/09/2019 11:33, Hongyan Xia wrote:
> > From: Wei Liu
> >
> > This then requires moving declaration of root page table mfn into mm.h
> > and modify setup_cpu_root_pgt to have a single exit path.
> >
> > We also need to force map_
1 - 100 of 171 matches
Mail list logo
