flight 148135 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148135/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 139698
test-amd64-amd64-qemu
flight 148127 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148127/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 146104
Tests which did not suc
flight 148144 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148144/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On Fri, 6 Mar 2020, Anthony PERARD wrote:
> From: Julien Grall
>
> At the moment, early printk can only be configured on the make command
> line. It is not very handy because a user has to remove the option
> everytime it is using another command other than compiling the
> hypervisor.
>
> Furthe
On Fri, 6 Mar 2020, Anthony PERARD wrote:
> We are going to move the generation of the early printk macro into
> Kconfig. This means all macro will be prefix with CONFIG_. We do that
> ahead of the change.
>
> We also take the opportunity to better name some variables, which are
> used by only one
Anchal Agarwal writes:
> There are no pm handlers for the legacy devices, so during tear down
> stale event channel <> IRQ mapping may still remain in the image and
> resume may fail. To avoid adding much code by implementing handlers for
> legacy devices, add a new irq_chip flag IRQCHIP_SHUTDOWN
Hi David,
On 01/02/2020 00:32, David Woodhouse wrote:
/*
* Hand the specified arbitrary page range to the specified heap zone
* checking the node_id of the previous page. If they differ and the
@@ -1799,18 +1811,23 @@ static void init_heap_pages(
{
unsigned int nid = phy
flight 148126 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148126/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 146194
Tests which di
On Fri, Feb 21, 2020 at 03:24:45PM +0100, Roger Pau Monné wrote:
> On Fri, Feb 14, 2020 at 11:25:34PM +, Anchal Agarwal wrote:
> > From: Munehisa Kamata >
> > Add freeze, thaw and restore callbacks for PM suspend and hibernation
> > support. All frontend drivers that needs to use PM_HIBERNATI
flight 148124 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 146100
Tests which di
flight 148120 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148120/
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. 144861
test-amd64-i386-f
On 05/03/2020 08:20, Jan Beulich wrote:
> On 04.03.2020 19:40, Andrew Cooper wrote:
>> On 04/03/2020 10:25, Jan Beulich wrote:
>>> On 03.03.2020 19:24, Andrew Cooper wrote:
ITSC being visible to the guest is currently implicit with the toolstack
unconditionally asking for it, and Xen clip
From: Julien Grall
At the moment, early printk can only be configured on the make command
line. It is not very handy because a user has to remove the option
everytime it is using another command other than compiling the
hypervisor.
Furthermore, early printk is one of the few odds one that are no
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.arm-early-printk-v2
Hi,
That two patchs is to unblock my work on "xen: Build system improvements".
There is an easier fix to build with early printk, but it is just better to use
Kconfi
We are going to move the generation of the early printk macro into
Kconfig. This means all macro will be prefix with CONFIG_. We do that
ahead of the change.
We also take the opportunity to better name some variables, which are
used by only one driver and wouldn't make sens for other UART driver.
On Wed, Mar 04, 2020 at 06:29:39PM +0100, Jonas Licht wrote:
> Am 04.03.20 um 11:31 schrieb Wei Liu:
> > Hi Jonas
> Hi Wei
> > Thanks for this patch.
> >
> > On Mon, Mar 02, 2020 at 06:53:38PM +0100, jonas.li...@fem.tu-ilmenau.de
> > wrote:
> >> Fixes the libxenstat Makefile to determine the corre
On 06.03.2020 17:27, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 06 March 2020 13:46
>> To: Paul Durrant
>> Cc: sstabell...@kernel.org; jul...@xen.org; volodymyr_babc...@epam.com;
>> w...@xen.org;
>> konrad.w...@oracle.com; andrew.coop...@citrix.com; ian.jack.
flight 148177 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148177/
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
> -Original Message-
> From: Jan Beulich
> Sent: 06 March 2020 13:46
> To: Paul Durrant
> Cc: sstabell...@kernel.org; jul...@xen.org; volodymyr_babc...@epam.com;
> w...@xen.org;
> konrad.w...@oracle.com; andrew.coop...@citrix.com; ian.jack...@eu.citrix.com;
> george.dun...@citrix.com; xe
Hi Paul,
On 06/03/2020 12:19, Paul Durrant wrote:
+
+`` and `` should be suitable to formulate a `WRITE` operation
+to the receiving xenstored and the `|+` list should be
+similarly suitable to formulate a subsequent `SET_PERMS` operation.
+`` specifies the number of entries in the `|+`
+list an
On 3/5/20 4:57 AM, Yan Yankovskyi wrote:
> Make event channel functions pass event channel port using
> evtchn_port_t type. It eliminates signed <-> unsigned conversion.
> Also rename 'evtchn' variables to 'port' in case if 'port' is not
> ambiguous.
> @@ -171,10 +171,10 @@ static int xen_irq_i
Hi,
On 06/03/2020 14:35, Jürgen Groß wrote:
On 04.03.20 14:42, Julien Grall wrote:
Hi,
On 04/03/2020 06:32, Juergen Gross wrote:
diff --git a/xen/include/xen/rcupdate.h b/xen/include/xen/rcupdate.h
index 31c8b86d13..9f6d420898 100644
--- a/xen/include/xen/rcupdate.h
+++ b/xen/include/xen/rcup
From: Varad Gautam
XEN_DOMCTL_destroydomain creates a continuation if domain_kill -ERESTARTS.
In that scenario, it is possible to receive multiple __pirq_guest_unbind
calls for the same pirq from domain_kill, if the pirq has not yet been
removed from the domain's pirq_tree, as:
domain_kill()
flight 148119 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148119/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 133580
test-amd64-amd64-xl
> -Original Message-
> From: Xen-devel On Behalf Of
> Durrant, Paul
> Sent: 05 March 2020 17:37
> To: Jan Beulich ; Gautam, Varad
> Cc: xen-devel@lists.xenproject.org; Roger Pau Monné ;
> Julien Grall
> ; Andrew Cooper
> Subject: Re: [Xen-devel] [PATCH v3] x86: irq: Do not BUG_ON multi
Vladimir Sementsov-Ogievskiy writes:
> File with errp-cleaning APIs dropped for two reasons:
>
> 1. I'm tired after a 3-days war with coccinelle, and don't want to add more
>patches here.
Oww. In my experience, Coccinelle is both awesome and terrible. I hope
you didn't do all that work jus
> Keyed types in libxl_types.idl can have elements of type 'None'. The
> golang type generator (correctly) don't implement any union types for
> these empty elements. However, the toC and fromC helper generators
> incorrectly treat these elements as invalid.
>
> Consider for example, libxl_channe
On 06.03.2020 15:26, Julien Grall wrote:
> On 06/03/2020 13:44, Jan Beulich wrote:
>> On 06.03.2020 13:35, Paul Durrant wrote:
From: Xen-devel On Behalf Of Jan
Beulich
Sent: 06 March 2020 12:20
On 05.03.2020 13:45, pdurr...@amzn.com wrote:
> --- a/xen/arch/x86/mm/shad
On 06.03.2020 15:31, Andrew Cooper wrote:
> On 06/03/2020 14:11, Jan Beulich wrote:
>> On 06.03.2020 14:52, Andrew Cooper wrote:
>>> Depending on the view of other PV shim usability issues, 6dd95b02ea27
>>> and f9dee1f945eb regarding vtsc make a large difference and should be
>>> considered.
>> I'v
On 04.03.20 14:42, Julien Grall wrote:
Hi,
On 04/03/2020 06:32, Juergen Gross wrote:
diff --git a/xen/include/xen/rcupdate.h b/xen/include/xen/rcupdate.h
index 31c8b86d13..9f6d420898 100644
--- a/xen/include/xen/rcupdate.h
+++ b/xen/include/xen/rcupdate.h
@@ -34,10 +34,40 @@
#include
#incl
On 06/03/2020 14:11, Jan Beulich wrote:
> On 06.03.2020 14:52, Andrew Cooper wrote:
>> The former is pretty useless without the other two, because you're
>> taking out the security feature without gaining the majority performance
>> win from avoiding VMexits due to CR4 traps.
> ... I'm unconvinced
Hi Jan,
On 06/03/2020 13:44, Jan Beulich wrote:
On 06.03.2020 13:35, Paul Durrant wrote:
-Original Message-
From: Xen-devel On Behalf Of Jan
Beulich
Sent: 06 March 2020 12:20
To: pdurr...@amzn.com
Cc: Stefano Stabellini ; Julien Grall ; Wei
Liu ;
Konrad Rzeszutek Wilk ; Andrew Cooper
On 06.03.2020 14:52, Andrew Cooper wrote:
> You've recently backported 328dd238da "x86/sm{e, a}p: do not enable
> SMEP/SMAP in PV shim by default on AMD", but have missed 5de961d9c097
> "x86: do not enable global pages when virtualized on AMD or Hygon
> hardware" and b041709c369b "x86/pv: Fix `glob
> -Original Message-
> From: Jan Beulich
> Sent: 06 March 2020 13:52
> To: Paul Durrant
> Cc: pdurr...@amzn.com; 'Stefano Stabellini' ; 'Julien
> Grall' ;
> 'Wei Liu' ; 'Konrad Rzeszutek Wilk' ;
> 'Andrew Cooper'
> ; 'Ian Jackson' ;
> 'George Dunlap'
> ; 'Tim Deegan' ; 'Tamas K Lengyel
[Adding George, as scheduler maintainer, and Juergen as he commented,
later in this thread]
[Adding xen-users back, as the thread originated from there... sorry
for cross-posting]
On Mon, 2020-02-17 at 11:58 -0800, Sarah Newman wrote:
> If there are no merged or proposed fixes soon, it may be
On 06.03.2020 14:48, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 06 March 2020 13:44
>> To: Paul Durrant
>> Cc: pdurr...@amzn.com; 'Stefano Stabellini' ;
>> 'Julien Grall' ;
>> 'Wei Liu' ; 'Konrad Rzeszutek Wilk' ;
>> 'Andrew Cooper'
>> ; Durrant, Paul ; 'Ian
Hello,
You've recently backported 328dd238da "x86/sm{e, a}p: do not enable
SMEP/SMAP in PV shim by default on AMD", but have missed 5de961d9c097
"x86: do not enable global pages when virtualized on AMD or Hygon
hardware" and b041709c369b "x86/pv: Fix `global-pages` to match the
documentation".
Th
> -Original Message-
> From: Jan Beulich
> Sent: 06 March 2020 13:44
> To: Paul Durrant
> Cc: pdurr...@amzn.com; 'Stefano Stabellini' ; 'Julien
> Grall' ;
> 'Wei Liu' ; 'Konrad Rzeszutek Wilk' ;
> 'Andrew Cooper'
> ; Durrant, Paul ; 'Ian
> Jackson'
> ; 'George Dunlap' ; 'Tim
> Deegan'
On 06.03.2020 14:45, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 06 March 2020 13:39
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Wei Liu ;
>> pdurr...@amzn.com; Roger Pau Monné
>> Subject: Re: [Xen
On Thu, Mar 5, 2020 at 2:12 PM Ian Jackson wrote:
>
> Jason Andryuk writes ("Re: [PATCH 1/2] tools/helpers: Introduce
> cmp-fd-file-inode utility"):
> > I'd be happy to use stat if it works. The comment in locking.sh above
> > the usage is:
> > # We can't just stat /dev/stdin or /proc/se
On 06.03.2020 14:41, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 06 March 2020 13:36
>> To: Paul Durrant
>> Cc: sstabell...@kernel.org; jul...@xen.org; volodymyr_babc...@epam.com;
>> w...@xen.org;
>> konrad.w...@oracle.com; andrew.coop...@citrix.com; ian.jack.
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 06 March 2020 13:39
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ;
> pdurr...@amzn.com; Roger Pau Monné
> Subject: Re: [Xen-devel] [PATCH v3 3/6] x86 / pv: do not treat PGC_
On 06.03.2020 13:35, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 06 March 2020 12:20
>> To: pdurr...@amzn.com
>> Cc: Stefano Stabellini ; Julien Grall
>> ; Wei Liu ;
>> Konrad Rzeszutek Wilk ; Andrew Cooper
>> ; Paul
>> Durrant ; Ian
> -Original Message-
> From: Jan Beulich
> Sent: 06 March 2020 13:36
> To: Paul Durrant
> Cc: sstabell...@kernel.org; jul...@xen.org; volodymyr_babc...@epam.com;
> w...@xen.org;
> konrad.w...@oracle.com; andrew.coop...@citrix.com; ian.jack...@eu.citrix.com;
> george.dun...@citrix.com; xe
On 06.03.2020 13:03, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 06 March 2020 11:56
>> To: pdurr...@amzn.com
>> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
>> Roger Pau Monné
>> ; Wei Liu ; Andrew Cooper
>>
>> Subject: Re:
On 06.03.2020 14:26, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 06 March 2020 13:24
>>
>> On 06.03.2020 14:13, Paul Durrant wrote:
>>> My aim is to make the separation abundantly obvious by getting rid
>>> of shared xenheap pages (for non-system domains at least)
On 06.03.2020 14:10, Igor Druzhinin wrote:
> On 06/03/2020 09:43, Jan Beulich wrote:
>> On 04.03.2020 16:33, Igor Druzhinin wrote:
>>> --- a/xen/arch/x86/acpi/power.c
>>> +++ b/xen/arch/x86/acpi/power.c
>>> @@ -305,7 +305,6 @@ static int enter_state(u32 state)
>>> cpufreq_add_cpu(0);
>>>
>>>
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 06 March 2020 13:24
> To: Paul Durrant
> Cc: sstabell...@kernel.org; jul...@xen.org; volodymyr_babc...@epam.com;
> w...@xen.org;
> konrad.w...@oracle.com; andrew.coop...@citrix.com; ian.jack...@eu.citrix.com;
> ge
> -Original Message-
> From: Jan Beulich
> Sent: 06 March 2020 13:19
> To: Paul Durrant
> Cc: pdurr...@amzn.com; xen-devel@lists.xenproject.org; 'Andrew Cooper'
> ;
> 'George Dunlap' ; 'Wei Liu' ; 'Roger
> Pau Monné'
>
> Subject: Re: [EXTERNAL][PATCH v3 2/6] x86 / p2m: remove page_list
On 06.03.2020 14:13, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 06 March 2020 13:10
>> To: David Woodhouse ; Durrant, Paul
>>
>> Cc: sstabell...@kernel.org; jul...@xen.org; w...@xen.org;
>> konrad.w...@oracle.com;
>> andrew.coop...
> -Original Message-
> From: David Woodhouse
> Sent: 06 March 2020 13:16
> To: Jan Beulich ; Durrant, Paul
> Cc: jul...@xen.org; andrew.coop...@citrix.com; sstabell...@kernel.org;
> konrad.w...@oracle.com;
> volodymyr_babc...@epam.com; ian.jack...@eu.citrix.com; w...@xen.org;
> george.d
On 06.03.2020 14:11, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 06 March 2020 13:07
>> To: Durrant, Paul
>> Cc: pdurr...@amzn.com; xen-devel@lists.xenproject.org; Andrew Cooper
>> ;
>> George Dunlap ; Wei Liu ; Roger Pau
>> Monné
>> Subject: RE: [EXTERNAL][
On Fri, 2020-03-06 at 14:10 +0100, Jan Beulich wrote:
> Establishing of what the new separation rule and mechanism is going
> to be (no matter how the two resulting pieces are going to be
> named).
Paul's opinion seemed to be that with secret hiding coming along and
destroying the "xenheap is mapp
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 06 March 2020 13:10
> To: David Woodhouse ; Durrant, Paul
>
> Cc: sstabell...@kernel.org; jul...@xen.org; w...@xen.org;
> konrad.w...@oracle.com;
> andrew.coop...@citrix.com; ian.jack...@eu.citrix.com;
> george.
> -Original Message-
> From: Jan Beulich
> Sent: 06 March 2020 13:07
> To: Durrant, Paul
> Cc: pdurr...@amzn.com; xen-devel@lists.xenproject.org; Andrew Cooper
> ;
> George Dunlap ; Wei Liu ; Roger Pau
> Monné
> Subject: RE: [EXTERNAL][PATCH v3 2/6] x86 / p2m: remove page_list check in
On 06/03/2020 09:43, Jan Beulich wrote:
> On 04.03.2020 16:33, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/acpi/power.c
>> +++ b/xen/arch/x86/acpi/power.c
>> @@ -305,7 +305,6 @@ static int enter_state(u32 state)
>> cpufreq_add_cpu(0);
>>
>> enable_cpu:
>> -rcu_barrier();
>> mtrr_a
On 06.03.2020 13:57, David Woodhouse wrote:
> On Fri, 2020-03-06 at 13:36 +0100, Jan Beulich wrote:
>> And of course this means you're intending to (at least
>> partially) resurrect the distinction between domheap and xenheap,
>> which isn't said anywhere in Paul's series, I don't think.
>
> Right
On Fri, 2020-03-06 at 13:55 +0100, Jan Beulich wrote:
> I'm sorry, but this doesn't really make things much more clear.
> Further up you say "As it processes the live update information
> ...", i.e. that's a case where you get positive indication that a
> page is in use. You also have that reserved
flight 148169 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148169/
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
> -Original Message-
> From: Jan Beulich
> Sent: 06 March 2020 12:47
> To: Durrant, Paul
> Cc: pdurr...@amzn.com; xen-devel@lists.xenproject.org; Andrew Cooper
> ;
> George Dunlap ; Wei Liu ; Roger Pau
> Monné
> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in
> p2m_al
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 06 March 2020 12:20
> To: pdurr...@amzn.com
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ;
> Konrad Rzeszutek Wilk ; Andrew Cooper
> ; Paul
> Durrant ; Ian Jackson ;
> George Dunlap
> ; Tim Deegan ; Tamas
On 06.03.2020 13:50, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 06 March 2020 12:47
>> To: Durrant, Paul
>> Cc: pdurr...@amzn.com; xen-devel@lists.xenproject.org; Andrew Cooper
>> ;
>> George Dunlap ; Wei Liu ; Roger Pau
>> Monné
>> Subject: Re: [PATCH v3
> -Original Message-
> From: Julien Grall
> Sent: 06 March 2020 12:03
> To: pdurr...@amzn.com; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich
> ; Konrad Rzeszutek Wilk ; Stefano
> Stabellini
> ; Wei Liu
> Subject: RE
06.03.2020 15:37, Eric Blake wrote:
On 3/5/20 11:15 PM, Vladimir Sementsov-Ogievskiy wrote:
Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with an errp OUT parameter.
As an aid to writing imperative-style commit messages, I like to prepend an implicit
"Apply th
On Fri, 2020-03-06 at 13:36 +0100, Jan Beulich wrote:
> Oh, so really this is an optimization to allow the memory range to
> not remain unused altogether by "old" Xen, i.e. unlike the kexec
> range.
Right. At the moment I just *don't* use the pages in the reserved
region (and that includes initte
On 06.03.2020 13:37, David Woodhouse wrote:
> On Fri, 2020-03-06 at 13:25 +0100, Jan Beulich wrote:
>> And likely interrupt remapping tables, device tables, etc. I don't
>> have a clear picture on how you want to delineate ones in use in any
>> such way from ones indeed free to re-use.
>
> Right.
On Fri, 2020-03-06 at 13:29 +0100, Jan Beulich wrote:
> How do you tell pages in use by domains from ones free to re-use?
> Because of the overloading of struct page_info, I expect you can't
> judge by just looking at a page's struct page_info instance. Are
> you peeking into the migration streams
On 06.03.2020 13:07, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 06 March 2020 11:46
>> To: pdurr...@amzn.com
>> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
>> Andrew Cooper
>> ; George Dunlap ; Wei
>> Liu ; Roger Pau
>> Monné
>> Subject: Re: [PATCH
On 3/5/20 11:15 PM, Vladimir Sementsov-Ogievskiy wrote:
Script adds ERRP_AUTO_PROPAGATE macro invocation where appropriate and
does corresponding changes in code (look for details in
include/qapi/error.h)
Usage example:
spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
--macro-f
On 3/5/20 11:15 PM, Vladimir Sementsov-Ogievskiy wrote:
Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with an errp OUT parameter.
As an aid to writing imperative-style commit messages, I like to prepend
an implicit "Apply this patch to..." before the user's tex
On Fri, 2020-03-06 at 13:25 +0100, Jan Beulich wrote:
> And likely interrupt remapping tables, device tables, etc. I don't
> have a clear picture on how you want to delineate ones in use in any
> such way from ones indeed free to re-use.
Right. The solution there is two-fold:
For pages in the gen
On 06.03.2020 13:20, David Woodhouse wrote:
> On Fri, 2020-03-06 at 12:37 +0100, Jan Beulich wrote:
>>> For live update we need to give a region of memory to the new Xen which
>>> it can use for its boot allocator, before it's handled any of the live
>>> update records and before it knows which *ot
On 06.03.2020 12:59, Durrant, Paul wrote:
>> -Original Message-
>> From: David Woodhouse
>> Sent: 06 March 2020 11:53
>> To: Jan Beulich ; Durrant, Paul
>> Cc: jul...@xen.org; andrew.coop...@citrix.com; sstabell...@kernel.org;
>> konrad.w...@oracle.com;
>> volodymyr_babc...@epam.com; ian
On 06.03.2020 12:52, David Woodhouse wrote:
> On Fri, 2020-03-06 at 12:37 +0100, Jan Beulich wrote:
>> I've started looking at the latest version of Paul's series, but I'm
>> still struggling to see the picture: There's no true distinction
>> between Xen heap and domain heap on x86-64 (except on ve
> -Original Message-
> From: Jan Beulich
> Sent: 06 March 2020 11:46
> To: pdurr...@amzn.com
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau
> Monné
> Subject: Re: [PATCH v3 2/6] x86 / p2m: remove page_list check in
> p2m_
On Fri, 2020-03-06 at 12:37 +0100, Jan Beulich wrote:
> > For live update we need to give a region of memory to the new Xen which
> > it can use for its boot allocator, before it's handled any of the live
> > update records and before it knows which *other* memory is still
> > available for use.
>
On 05.03.2020 13:45, pdurr...@amzn.com wrote:
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2087,19 +2087,22 @@ static int sh_remove_all_mappings(struct domain *d,
> mfn_t gmfn, gfn_t gfn)
> * The qemu helper process has an untyped mapping of this
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 06 March 2020 11:56
> To: pdurr...@amzn.com
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Roger Pau Monné
> ; Wei Liu ; Andrew Cooper
>
> Subject: Re: [Xen-devel] [PATCH v3 3/6] x86 / pv: do not treat P
> -Original Message-
> From: David Woodhouse
> Sent: 06 March 2020 11:53
> To: Jan Beulich ; Durrant, Paul
> Cc: jul...@xen.org; andrew.coop...@citrix.com; sstabell...@kernel.org;
> konrad.w...@oracle.com;
> volodymyr_babc...@epam.com; ian.jack...@eu.citrix.com; w...@xen.org;
> george.d
On 05.03.2020 13:45, pdurr...@amzn.com wrote:
> From: Paul Durrant
>
> ... now that it is safe to assign them.
>
> This avoids relying on libxl (or whatever toolstack is in use) setting
> max_pages up with sufficient 'slop' to allow all necessary ioreq server
> pages to be allocated.
>
> Signed
Hi Paul,
On 05/03/2020 17:30, pdurr...@amzn.com wrote:
From: Paul Durrant
This patch details proposes extra migration data and xenstore protocol
extensions to support non-cooperative live migration of guests.
NOTE: doc/misc/xenstore.txt is also amened to replace the term
for the INTRO
On 05.03.2020 13:45, pdurr...@amzn.com wrote:
> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -792,6 +792,10 @@ int __init dom0_construct_pv(struct domain *d,
> {
> mfn = mfn_x(page_to_mfn(page));
> BUG_ON(SHARED_M2P(get_gpfn_from_mfn(mfn)));
>
On Fri, 2020-03-06 at 12:37 +0100, Jan Beulich wrote:
> I've started looking at the latest version of Paul's series, but I'm
> still struggling to see the picture: There's no true distinction
> between Xen heap and domain heap on x86-64 (except on very large
> systems). Therefore it is unclear to m
On 05.03.2020 13:45, pdurr...@amzn.com wrote:
> From: Paul Durrant
>
> There does not seem to be any justification for refusing to create the
> domain's p2m table simply because it may have assigned pages.
I think there is: If any such allocation had happened before, how
would it be represented
On 05.03.2020 13:44, pdurr...@amzn.com wrote:
> From: Paul Durrant
>
> ... and save the MFN.
>
> This patch modifies the 'shared_info' field of struct domain to be
> a structure comprising an MFN and a virtual address. Allocations are
> still done from xenheap, so the virtual address still equat
Keyed types in libxl_types.idl can have elements of type 'None'. The
golang type generator (correctly) don't implement any union types for
these empty elements. However, the toC and fromC helper generators
incorrectly treat these elements as invalid.
Consider for example, libxl_channelinfo. The
On 26.02.2020 17:53, Woodhouse, David wrote:
> On Wed, 2020-02-26 at 16:12 +, Julien Grall wrote:
>> (+David)
>>
>> On 26/02/2020 15:23, Jan Beulich wrote:
>>> On 26.02.2020 15:05, Durrant, Paul wrote:
> From: Jan Beulich
> Sent: 26 February 2020 13:58
>
> On 25.02.2020 10:53,
p...@xen.org writes ("[PATCH] MAINTAINERS: Update my entries (again again)"):
> From: Paul Durrant
>
> Unfortunately I need to stop using all my Amazon email addresses for all
> open source work.
Acked-by: Ian Jackson
And applied.
Ian.
___
Xen-deve
From: Paul Durrant
Unfortunately I need to stop using all my Amazon email addresses for all
open source work.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
Cc: Wei Liu
---
MAINTAINERS | 8 -
On Wed, 4 Mar 2020 16:35:59 +0100
Philippe Mathieu-Daudé wrote:
> v2:
> - do not modify qed.h (structure with single member)
> - based on hw/scsi/spapr_vscsi fix series
>
> This is a tree-wide cleanup inspired by a Linux kernel commit
> (from Gustavo A. R. Silva).
>
> --v-- description start -
On 3/5/20 10:51 AM, Juergen Gross wrote:
> Commit 0265d6e8ddb890 ("xen/blkfront: limit allocated memory size to
> actual use case") made struct blkfront_ring_info size dynamic. This is
> fine when running with only one queue, but with multiple queues the
> addressing of the single queues has to b
On 3/5/20 5:03 AM, Juergen Gross wrote:
> Commit 060eabe8fbe726 ("xenbus/backend: Protect xenbus callback with
> lock") introduced a bug by holding a lock while calling a function
> which might schedule.
>
> Fix that by using a semaphore instead.
>
> Fixes: 060eabe8fbe726 ("xenbus/backend: Protec
On 3/3/20 5:14 PM, Dongli Zhang wrote:
> This patch adds the barrier to guarantee that req->err is always updated
> before req->state.
>
> Otherwise, read_reply() would not return ERR_PTR(req->err) but
> req->body, when process_writes()->xb_write() is failed.
>
> Signed-off-by: Dongli Zhang
App
Hi Paul,
On 05/03/2020 17:30, pdurr...@amzn.com wrote:
From: Paul Durrant
It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provide
On Fri 06 Mar 2020 06:15:27 AM CET, Vladimir Sementsov-Ogievskiy wrote:
Sorry I just gave a quick look at these patches and noticed this:
> + * Function may use error system to return errors. In this case function
> + * defines Error **errp parameter, which should be the last one (except for
> +
On Fri, 6 Mar 2020 08:15:27 +0300
Vladimir Sementsov-Ogievskiy wrote:
> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
> functions with an errp OUT parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user
> can't see t
On Thu, Feb 27, 2020 at 09:17:51PM +, Stewart Hildebrand wrote:
> Thanks for your efforts with this. With your br.build-system-xen-v3
> branch, I'm having trouble doing an aarch64 build with early printk
> enabled. I suspect the following unmerged patch that Julien authored
> last September may
On 04.03.2020 16:33, Igor Druzhinin wrote:
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -305,7 +305,6 @@ static int enter_state(u32 state)
> cpufreq_add_cpu(0);
>
> enable_cpu:
> -rcu_barrier();
> mtrr_aps_sync_begin();
> enable_nonboot_cpus();
>
> -Original Message-
> From: detected-as-s...@amazon.com On Behalf Of
> Alan Robinson
> Sent: 06 March 2020 07:02
> To: pdurr...@amzn.com
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Julien Grall
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; Andrew Cooper
> ; Durrant, Paul ; I
On 03.03.2020 18:20, Roger Pau Monne wrote:
> Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
> This greatly increases the performance of TLB flushes when running
> with a high amount of vCPUs as a Xen guest, and is specially important
> when running in shim mode.
>
> The foll
1 - 100 of 114 matches
Mail list logo
