Hi George,
Sorry for the early reminder but v1 you said "Everything else looks OK
to me." and you did not give a specific ACK. Can you take a look at the
changes when you have the time?
Thanks,
Alex
On 06.11.2019 17:35, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> Th
Picking up the discussion from IRC to make it more widely visible...
When per-domain options for maximum grant and maptrack frames came in (in
4.10?) Xen's behaviour w.r.t. to the global command line values
(gnttab_max_frames and gnttab_max_maptrack_frames respectively) regressed
For example, a
On Thu, Nov 07, 2019 at 04:56:09PM +0100, Jan Beulich wrote:
> On 07.11.2019 16:46, Roger Pau Monné wrote:
> > On Thu, Nov 07, 2019 at 04:28:56PM +0100, Jan Beulich wrote:
> >> On 07.11.2019 16:06, Roger Pau Monne wrote:
> >>> @@ -530,9 +530,9 @@ static void clear_IO_APIC_pin(unsigned int apic,
>
From: Paul Durrant
The vif-route script should only call 'ip route' when 'ipcmd' has been
set, otherwise it will fail due to an incorrect command string.
This patch also adds routes for 'tap' (i.e. emulated) devices as well as
'vif' (i.e. PV) devices. Empirically offline/online commands relate t
On Mon, Nov 04, 2019 at 04:13:53PM +0100, Daniel Kiper wrote:
> This field contains maximal allowed type for setup_data.
>
> This patch does not bump setup_header version in arch/x86/boot/header.S
> because it will be followed by additional changes coming into the
> Linux/x86 boot protocol.
>
> S
On 08.11.2019 10:27, Roger Pau Monné wrote:
> On Thu, Nov 07, 2019 at 04:56:09PM +0100, Jan Beulich wrote:
>> On 07.11.2019 16:46, Roger Pau Monné wrote:
>>> On Thu, Nov 07, 2019 at 04:28:56PM +0100, Jan Beulich wrote:
On 07.11.2019 16:06, Roger Pau Monne wrote:
> @@ -530,9 +530,9 @@ sta
On 11/5/19 7:43 PM, Andrew Cooper wrote:
> The safety of livepatching depends on every stack having been unwound, but
> there is one corner case where this is not true. The Sharing/Paging/Monitor
> infrastructure may use waitqueues, which copy the stack frame sideways and
> longjmp() to a differen
On Fri, Nov 08, 2019 at 02:25:05AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné [mailto:roger@citrix.com]
> > Sent: Monday, November 4, 2019 5:47 PM
> >
> > On Sat, Nov 02, 2019 at 07:48:06AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monné [mailto:roger@citrix.com]
> > > > S
On 11/5/19 7:43 PM, Andrew Cooper wrote:
> One use of load hooks is to perform a safety check of the system in its
> quiesced state. Any non-zero return value from a load hook will abort the
> apply attempt.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Ross Lagerwall
On 08.11.19 08:14, David Hildenbrand wrote:
On 08.11.19 06:09, Dan Williams wrote:
On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
On 07.11.19 19:22, David Hildenbrand wrote:
Am 07.11.2019 um 16:40 schrieb Dan Williams :
On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand wrote:
Cc xen-devel
Look forward to v3.
On Fri, Nov 08, 2019 at 09:17:37AM +, Paul Durrant wrote:
> On Thu, 7 Nov 2019 at 18:52, Wei Liu wrote:
> >
> > On Thu, Nov 07, 2019 at 04:58:14PM +, p...@xen.org wrote:
> > > From: Paul Durrant
> > >
> > > The vif-route script should only call 'ip route
On Fri, Nov 08, 2019 at 09:42:33AM +, p...@xen.org wrote:
> From: Paul Durrant
>
> The vif-route script should only call 'ip route' when 'ipcmd' has been
> set, otherwise it will fail due to an incorrect command string.
>
> This patch also adds routes for 'tap' (i.e. emulated) devices as wel
On Thu, Nov 07, 2019 at 06:52:00PM +, Wei Liu wrote:
> On Thu, Nov 07, 2019 at 04:58:14PM +, p...@xen.org wrote:
> > --- a/tools/hotplug/Linux/vif-route
> > +++ b/tools/hotplug/Linux/vif-route
> > @@ -22,12 +22,16 @@ dir=$(dirname "$0")
> > main_ip=$(dom0_ip)
> >
> > case "${command}" i
On 9/28/19 4:12 PM, Pawel Wieczorkiewicz wrote:
> By default Livepatch enforces the following buildid-based dependency
> chain between livepatch modules:
> 1) first module depends on given hypervisor buildid
> 2) every consecutive module depends on previous module's buildid
> This way proper li
On 9/28/19 4:12 PM, Pawel Wieczorkiewicz wrote:
> This is an implementation of 4 new livepatch module vetoing hooks,
> that can be optionally supplied along with modules.
> Hooks that currently exists in the livepatch mechanism aren't agile
> enough and have various limitations:
> * run only from w
On Fri, Nov 08, 2019 at 11:09:30AM +0100, Borislav Petkov wrote:
> On Mon, Nov 04, 2019 at 04:13:53PM +0100, Daniel Kiper wrote:
> > This field contains maximal allowed type for setup_data.
> >
> > This patch does not bump setup_header version in arch/x86/boot/header.S
> > because it will be follow
On 9/28/19 4:13 PM, Pawel Wieczorkiewicz wrote:
> Livepatch only tracks an entire payload applied/reverted state. But,
> with an option to supply the apply_payload() and/or revert_payload()
> functions as optional hooks, it becomes possible to intermix the
> execution of the original apply_payload(
On Fri, Nov 08, 2019 at 11:47:02AM +0100, Daniel Kiper wrote:
> Yeah, you are right. Would you like me to repost whole patch series or
> could you fix it before committing?
Lemme finish looking at patch 3 first.
If you have to resend, please remove "This patch" and "We" in your text.
Thx.
--
R
The .file assembler directives generated by the compiler do not include
any path components (gcc) or just the ones specified on the command line
(clang, at least version 5), and hence multiple identically named source
files (in different directories) may produce identically named static
symbols (in
On Mon, Nov 04, 2019 at 04:13:54PM +0100, Daniel Kiper wrote:
> diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
> index edaa30b20841..701a98300f86 100644
> --- a/arch/x86/kernel/kdebugfs.c
> +++ b/arch/x86/kernel/kdebugfs.c
> @@ -44,7 +44,11 @@ static ssize_t setup_data_read(st
On 08.11.2019 09:45, Durrant, Paul wrote:
> When per-domain options for maximum grant and maptrack frames came in (in
> 4.10?) Xen's behaviour w.r.t. to the global command line values
> (gnttab_max_frames and gnttab_max_maptrack_frames respectively) regressed
>
> For example, a host running a
flight 143861 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143861/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 138829
test-amd64-amd6
On Fri, Nov 01, 2019 at 07:17:57AM +0100, Jürgen Groß wrote:
> On 31.10.19 12:58, Roger Pau Monne wrote:
> > The event channel data was not copied back to guest memory, fix this
> > by doing the copy.
> >
> > Signed-off-by: Roger Pau Monné
>
> Release-acked-by: Juergen Gross
Jan? Andrew?
flight 143870 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143870/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
On 08/11/2019 11:55, Wei Liu wrote:
> On Fri, Nov 01, 2019 at 07:17:57AM +0100, Jürgen Groß wrote:
>> On 31.10.19 12:58, Roger Pau Monne wrote:
>>> The event channel data was not copied back to guest memory, fix this
>>> by doing the copy.
>>>
>>> Signed-off-by: Roger Pau Monné
>> Release-acked-by
On 08.11.19 12:38, Jan Beulich wrote:
On 08.11.2019 09:45, Durrant, Paul wrote:
When per-domain options for maximum grant and maptrack frames came in (in
4.10?) Xen's behaviour w.r.t. to the global command line values
(gnttab_max_frames and gnttab_max_maptrack_frames respectively) regressed
On Fri, Nov 08, 2019 at 12:07:08PM +, Andrew Cooper wrote:
> On 08/11/2019 11:55, Wei Liu wrote:
> > On Fri, Nov 01, 2019 at 07:17:57AM +0100, Jürgen Groß wrote:
> >> On 31.10.19 12:58, Roger Pau Monne wrote:
> >>> The event channel data was not copied back to guest memory, fix this
> >>> by do
> -Original Message-
> From: Jürgen Groß
> Sent: 08 November 2019 12:14
> To: Jan Beulich ; Durrant, Paul
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] max_grant_frames/max_maptrack_frames
>
> On 08.11.19 12:38, Jan Beulich wrote:
> > On 08.11.2019 09:45, Durrant, Paul
> -Original Message-
> From: Jan Beulich
> Sent: 08 November 2019 11:38
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] max_grant_frames/max_maptrack_frames
>
> On 08.11.2019 09:45, Durrant, Paul wrote:
> > When per-domain options for maximum grant a
flight 143876 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143876/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 143419
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
On Fri, Nov 08, 2019 at 12:07:03PM +0100, Borislav Petkov wrote:
> On Fri, Nov 08, 2019 at 11:47:02AM +0100, Daniel Kiper wrote:
> > Yeah, you are right. Would you like me to repost whole patch series or
> > could you fix it before committing?
>
> Lemme finish looking at patch 3 first.
>
> If you h
On Fri, Nov 08, 2019 at 01:52:48PM +0100, Daniel Kiper wrote:
> OK, got your comments. I will repost the patch series probably on Tuesday.
> I hope that it will land in 5.5 then.
I don't see why not if you base it ontop of tip:x86/boot and test it
properly before sending.
Out of curiosity, is the
When using posted interrupts and the guest migrates MSI from vCPUs Xen
needs to flush any pending PIRR vectors on the previous vCPU, or else
those vectors could get wrongly injected at a later point when the MSI
fields are already updated.
Rename sync_pir_to_irr to vlapic_sync_pir_to_irr and expor
On Fri, Nov 08, 2019 at 02:03:38PM +0100, Borislav Petkov wrote:
> On Fri, Nov 08, 2019 at 01:52:48PM +0100, Daniel Kiper wrote:
> > OK, got your comments. I will repost the patch series probably on Tuesday.
> > I hope that it will land in 5.5 then.
>
> I don't see why not if you base it ontop of t
On 08.11.2019 13:33, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 08 November 2019 11:38
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org
>> Subject: Re: [Xen-devel] max_grant_frames/max_maptrack_frames
>>
>> On 08.11.2019 09:45, Durrant, Paul wro
On Thu, Nov 07, 2019 at 10:33:02PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2019 at 08:06:08PM +, Jason Gunthorpe wrote:
> > >
> > > enum mmu_range_notifier_event {
> > > MMU_NOTIFY_RELEASE,
> > > };
> > >
> > > ...assuming that we stay with "mmu_range_notifier" as a core name for
On Thu, Nov 07, 2019 at 05:54:52PM -0500, Boris Ostrovsky wrote:
> On 11/7/19 3:36 PM, Jason Gunthorpe wrote:
> > On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
> >
> >>> So, I suppose it can be relaxed to a null test and a WARN_ON that it
> >>> hasn't changed?
> >> You mean
> >>
1: include the PPIN in MCE records when available
2: explicitly disallow guest access to PPIN
3: provide Dom0 access to PPIN via XENPF_resource_op
I have yet to get around to post the Linux side consumer
patch of the interface addition in patch 1.
Jan
Quoting the respective Linux commit:
Intel Xeons from Ivy Bridge onwards support a processor identification
number set in the factory. To the user this is a handy unique number to
identify a particular CPU. Intel can decode this to the fab/production
run to track errors. On systems
To fulfill the "protected" in its name, don't let the real hardware
values "shine through". Report a control register value expressing this.
Signed-off-by: Jan Beulich
---
v2: Use "cp" consistently. Re-base.
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -135,6 +135,8 @@ int guest_rdmsr(st
It was requested that we provide a way independent of the MCE reporting
interface that Dom0 software could use to get hold of the values for
particular CPUs.
Signed-off-by: Jan Beulich
---
v2: New.
TBD: I couldn't identify any suitable utility under tools/misc/ that I
would have felt like m
On Thu, Nov 07, 2019 at 12:53:56PM -0800, John Hubbard wrote:
> > > > +/**
> > > > + * struct mmu_range_notifier_ops
> > > > + * @invalidate: Upon return the caller must stop using any SPTEs
> > > > within this
> > > > + * range, this function can sleep. Return false if
> > > > block
Finally, what is the plan?
Markus what do you think?
Now a lot of patches are reviewed, but a lot of are not.
Is there any hope that all patches will be reviewed? Should I resend the
whole series, or may be reduce it to reviewed subsystems only?
11.10.2019 19:03, Vladimir Sementsov-Ogievskiy wr
On Fri, Nov 08, 2019 at 11:16:26AM +0100, Jan Beulich wrote:
> On 08.11.2019 10:27, Roger Pau Monné wrote:
> > On Thu, Nov 07, 2019 at 04:56:09PM +0100, Jan Beulich wrote:
> >> On 07.11.2019 16:46, Roger Pau Monné wrote:
> >>> On Thu, Nov 07, 2019 at 04:28:56PM +0100, Jan Beulich wrote:
> On
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodem
Hi,
my machine recently crashes randomly. I found this thing in my logs before
the crash happened:
Linux vserver1592 5.3.8-arch1-1 #1 SMP PREEMPT @1572357769 x86_64 GNU/Linux
Nov 08 06:32:34 vserver1592 kernel: [ cut here ]
Nov 08 06:32:34 vserver1592 kernel: WARNING: CPU
On 08.11.2019 17:07, Roger Pau Monné wrote:
> On Fri, Nov 08, 2019 at 11:16:26AM +0100, Jan Beulich wrote:
>> On 08.11.2019 10:27, Roger Pau Monné wrote:
>>> On Thu, Nov 07, 2019 at 04:56:09PM +0100, Jan Beulich wrote:
On 07.11.2019 16:46, Roger Pau Monné wrote:
> On Thu, Nov 07, 2019 a
flight 143882 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 139047
test-amd64-amd6
On Fri, Nov 08, 2019 at 12:18:40PM +0100, Jan Beulich wrote:
> The .file assembler directives generated by the compiler do not include
> any path components (gcc) or just the ones specified on the command line
> (clang, at least version 5), and hence multiple identically named source
> files (in di
This patch synced PIRR with IRR when misx table updated, I ran same test
over 1.5 hours and did not reproduced it, without the patch, I could
reproduced within 10 minutes.
Tested-by: Joe Jin
Thanks,
Joe
On 11/8/19 5:34 AM, Roger Pau Monne wrote:
> When using posted interrupts and the guest mig
On Fri, Nov 8, 2019 at 2:22 AM David Hildenbrand wrote:
>
> On 08.11.19 08:14, David Hildenbrand wrote:
> > On 08.11.19 06:09, Dan Williams wrote:
> >> On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
> >>>
> >>> On 07.11.19 19:22, David Hildenbrand wrote:
>
>
> > Am 07.11.20
No change for existing callers.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sg-report-host-history b/sg-report-host-history
index 42def6bf..c9f4aaa6 100755
--- a/sg-report-host-history
+++ b/sg-report-host-history
This seriously speeds up some of the queries.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sg-report-host-history b/sg-report-host-history
index fc51074d..d47784d9 100755
--- a/sg-report-host-history
+++ b/sg-report
Earlier this week we discovered that sg-report-host-history was running
extremely slowly. We applied an emergency fix 0fa72b13f5af
sg-report-host-history: Reduce limit from 2000 to 200
The main problem is that sg-report-host-history runs once for each
flight, and must generate a relevant histor
This reverts commit 0fa72b13f5af0a544c417fc3c64cda1ea869a0ac.
Now we have the cacheing we can put this back and have useful host
histories again.
Some performance figures (individual measurements):
limit=200 limit=2000
before this series 3
Signed-off-by: Ian Jackson
---
sg-report-host-history | 57 +-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/sg-report-host-history b/sg-report-host-history
index 7dcfac9a..e67c7346 100755
--- a/sg-report-host-history
+++ b/sg-report
This query is just used for the power methods. Put it near there.
Also, indent it in a `do' block. These changes will make the next
change easier to read.
No functional change.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 21 -
1 file changed, 12 insertions(+),
Signed-off-by: Ian Jackson
---
sg-report-host-history | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/sg-report-host-history b/sg-report-host-history
index bd7391e0..42def6bf 100755
--- a/sg-report-host-history
+++ b/sg-report-host-history
@@ -101,6 +101,8 @@ END
This will allow the flights range computation to depend on the hosts
we are interested in.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sg-report-host-history b/sg-report-host-history
index c9f4aaa6..fc51074d 10
This key will distinguish the results of different queries we do per
job. Right now it is not used, so no functional change.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/sg-report-host-history b/sg-report-host
mainquery fetches a number of rows supposed to be larger than needed
for the output limit $limit. And then for each host we sort them by
time of the last step - which means we must have the last step, which
is a separate query for each job. We want to cache this information
even for jobs we do no
We are going to need this as part of our data reuse cache key, so we
need it this early. This change hardly slows the query down.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sg-report-host-history b/sg-report-
This per-job processing was not done with jobquery, so was not cached.
We assign it the cache letter `p'.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/sg-report-host-history b/sg-report-host-history
ind
jobquery now looks for the subquery results in %$jr, under the
cachekey, and only runs the query if it's not found. It then stores
the value.
We are going to persist the contents of %$jr across runs, and then
this will avoid rerunning queries needlessly.
No functional change yet.
Signed-off-by:
Write the %$jr contents out in a fairly terse format. We stuff it
into a parseable SGML/XML comment in the output HTML.
Nothing makes use of this yet - parsing it back in will come later.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 23 +++
1 file changed, 23 ins
On Thu, 7 Nov 2019, Lars Kurth wrote:
> Hi all,
>
> I have received informal advice
>
> On 21/10/2019, 06:54, "Artem Mygaiev" wrote:
>
> > Before we ask Xen FuSA contributors to invest in documentation to
> > be presented as legally-valid evidence for certification, we should
> >
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: george.dun...@citrix.com
CC: jul...@xen.org
CC: lars.ku...@citrix.com
CC: andrew.coop...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: konrad.w...@oracle.com
CC: w...@xen.org
---
docs/process/backport-tag.pandoc | 23 +
On Thu, 7 Nov 2019, Peng Fan wrote:
> The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
>
> Signed-off-by: Peng Fan
Reviewed-by: Stefano Stabellini
Juergen, I think this fix should be in the release (and also
backported to stable trees.)
> ---
> xen/arch/arm/vgic-v3.c | 2 +-
> 1 file
On 08/11/2019 19:49, Ian Jackson wrote:
> Earlier this week we discovered that sg-report-host-history was running
> extremely slowly. We applied an emergency fix 0fa72b13f5af
> sg-report-host-history: Reduce limit from 2000 to 200
>
> The main problem is that sg-report-host-history runs once fo
On Thu, Nov 07, 2019 at 09:00:34PM -0500, Jerome Glisse wrote:
> On Fri, Nov 08, 2019 at 12:32:25AM +, Jason Gunthorpe wrote:
> > On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> > > On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> > > > On Wed, Nov 06, 2019 at
flight 143904 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143904/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail
REGR. vs. 143023
test-am
flight 143895 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142750
test-amd64-amd64-l
Hi,
Sorry for the formatting.
On Sat, 9 Nov 2019, 04:27 Stefano Stabellini,
wrote:
> On Thu, 7 Nov 2019, Peng Fan wrote:
> > The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
> >
> > Signed-off-by: Peng Fan
>
> Reviewed-by: Stefano Stabellini
>
To be honest, I am not sure the code is cor
On 11/8/19 3:10 PM, Marc-André Lureau wrote:
+/*
+ * ERRP_AUTO_PROPAGATE
+ *
+ * This macro is created to be the first line of a function with Error **errp
+ * OUT parameter. It's needed only in cases where we want to use error_prepend,
+ * error_append_hint or dereference *errp. It's still safe
On 08.11.19 19:29, Dan Williams wrote:
On Fri, Nov 8, 2019 at 2:22 AM David Hildenbrand wrote:
On 08.11.19 08:14, David Hildenbrand wrote:
On 08.11.19 06:09, Dan Williams wrote:
On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
On 07.11.19 19:22, David Hildenbrand wrote:
Am 07.1
flight 143905 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143905/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 143158
build-i386-xs
flight 143908 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143908/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 601a18bf08ca815544b2223208b437a83fba6858
baseline version:
ovmf 1bcc65b9a1408cf445b7b
Hi
On Fri, Nov 8, 2019 at 7:31 PM Vladimir Sementsov-Ogievskiy
wrote:
>
> Finally, what is the plan?
>
> Markus what do you think?
>
> Now a lot of patches are reviewed, but a lot of are not.
>
> Is there any hope that all patches will be reviewed? Should I resend the
> whole series, or may be re
On Fri, Oct 11, 2019 at 10:11 PM Vladimir Sementsov-Ogievskiy
wrote:
>
> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
> functions with errp OUT parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
> can't see this addi
Hi
On Fri, Oct 11, 2019 at 9:11 PM Vladimir Sementsov-Ogievskiy
wrote:
>
> Add script to automatically commit tree-wide changes per-subsystem.
Oh interesting! I guess it could use a --help or a larger commit
message to explain a bit what it does (I imagine from the rest of the
series, but someon
flight 143911 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143911/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142849
test-amd64-amd64-lib
81 matches
Mail list logo
