flight 144615 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144615/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 144517
build-i386-libvirt
On 05.12.19 18:16, Ian Jackson wrote:
This is the package (or, one of the packages) containing rst2html.
This is now needed for builds of libvirt upstream.
Really this packages install call should be ts-libvirt-build, but:
Historically we have done it all in ts-xen-build-prep. In the
meantime w
On 05.12.19 08:26, Jan Beulich wrote:
1: refine commit 9143a6c55ef7 for the 64-bit case
2: pull out constant tables
3: fix system halt at boot kernel on x86_64
Only patch 1 is strictly meant to be considered for 4.13, albeit
patch 3 fixes a similar problem (but none which would have been
reporte
flight 144609 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144609/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt 13
flight 144591 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144591/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 15 guest-saverestorefail REGR. vs. 144514
Tests which did not succee
On 12/6/19 11:57 AM, Jan Beulich wrote:
> On 06.12.2019 17:51, Ian Jackson wrote:
>> Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
>> FAIL"):
>>> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
>>> FAIL"):
On 25.11.2019 14:58, osstest s
flight 144588 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144588/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 144574
Tests which did not succeed
flight 144590 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144590/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 49054b6bb66d35484e92c65f27584c4283a60986
baseline version:
ovmf 9caaa79dd7e078ebb4012
flight 144607 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144607/
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
flight 144587 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144587/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 144339
test-amd64-i386-xl-pvshim12
On 12/11/2019 14:03, Jan Beulich wrote:
> On 12.11.2019 14:39, Andrew Cooper wrote:
>> On 12/11/2019 08:35, Jan Beulich wrote:
>>> On 11.11.2019 21:24, Andrew Cooper wrote:
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1077,7 +1077,7 @@ long do_set_segment_base(un
> On 6 Dec 2019, at 14:21, Andrew Cooper wrote:
>
> On 03/12/2019 09:17, George Dunlap wrote:
>>
>>> On Dec 2, 2019, at 5:01 PM, Konrad Rzeszutek Wilk
>>> wrote:
>>>
>>> On Mon, Dec 02, 2019 at 03:55:04PM +, Andrew Cooper wrote:
On 02/12/2019 15:53, Konrad Rzeszutek Wilk wrote:
>>>
On Fri, 6 Dec 2019, Ian Jackson wrote:
> Julien Grall writes ("Re: Problem booting Debian buster on arndale"):
> > On 06/12/2019 16:47, Ian Jackson wrote:
> > > It seems to have hung during boot. NB that I don't know whether this
> > > is a one-off.
> >
> > Looking at [1], most of the recent flig
On 03/12/2019 09:17, George Dunlap wrote:
>
>> On Dec 2, 2019, at 5:01 PM, Konrad Rzeszutek Wilk
>> wrote:
>>
>> On Mon, Dec 02, 2019 at 03:55:04PM +, Andrew Cooper wrote:
>>> On 02/12/2019 15:53, Konrad Rzeszutek Wilk wrote:
>> I plan to release ack the patch in case the missing maintain
On 12/6/19 1:09 PM, Nuernberger, Stefan wrote:
> On Fri, 2019-12-06 at 10:11 -0500, Boris Ostrovsky wrote:
>> On 12/6/19 8:48 AM, Stefan Nuernberger wrote:
>>> From: Uwe Dannowski
>>>
>>> Reading /sys/bus/pci/drivers/pciback/quirks while unbinding can
>>> result
>>> in dereferencing a NULL pointer
On 05/12/2019 07:26, Jan Beulich wrote:
> 1: refine commit 9143a6c55ef7 for the 64-bit case
> 2: pull out constant tables
> 3: fix system halt at boot kernel on x86_64
>
> Only patch 1 is strictly meant to be considered for 4.13, albeit
> patch 3 fixes a similar problem (but none which would have b
On 06/12/2019 11:32, Jan Beulich wrote:
> On 06.12.2019 11:25, Andrew Cooper wrote:
>> On 06/12/2019 10:14, Jan Beulich wrote:
>>> It is wrong for us to check frames beyond the guest specified limit.
>>>
>>> Signed-off-by: Jan Beulich
>> I don't completely agree. The code has been like this since
On 05/12/2019 16:57, Jan Beulich wrote:
> On 05.12.2019 16:47, Andrew Cooper wrote:
>> On 05/12/2019 15:34, Jan Beulich wrote:
>>> Translated domains shouldn't see host physical addresses. While the
>>> address is also not supposed to be handed back even to non-translated
>>> domains when GNTMAP_de
Begin to document how the x86 build of Xen boots. It is by no means complete,
but is a start.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
This came about while I sat in SFO waiting for a delayed flight, and was asked
a question by the Trenchboot folk.
Wr
On 08/10/2019 10:32, Jan Beulich wrote:
> On 25.09.2019 17:27, Jan Beulich wrote:
>> There's nothing to restore here if there's no FPU in the first place.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> To be considered for 4.13 since RSTR_FP_ERR_PTRS support was introduced
>> just recently.
> And alre
Jan Beulich writes ("Re: debina hang after "random: crng init done""):
> On 06.12.2019 17:51, Ian Jackson wrote:
> > I have a repro with Debian buster, too, here:
> >
> > http://logs.test-lab.xenproject.org/osstest/logs/144312/test-amd64-i386-xl-raw/info.html
>
> Does "repro" mean you're able t
On Fri, 2019-12-06 at 10:11 -0500, Boris Ostrovsky wrote:
> On 12/6/19 8:48 AM, Stefan Nuernberger wrote:
> >
> > From: Uwe Dannowski
> >
> > Reading /sys/bus/pci/drivers/pciback/quirks while unbinding can
> > result
> > in dereferencing a NULL pointer. Instead, skip printing information
> > abo
Julien Grall writes ("Re: Problem booting Debian buster on arndale"):
> On 06/12/2019 16:47, Ian Jackson wrote:
> > It seems to have hung during boot. NB that I don't know whether this
> > is a one-off.
>
> Looking at [1], most of the recent flight have managed to boot Xen on
> the arndale. Howe
On 06/12/2019 15:53, Hongyan Xia wrote:
> map_pages_to_xen and modify_xen_mappings are performing almost exactly
> the same operations when shattering an l3 PTE, the only difference
> being whether we want to flush.
>
> Signed-off-by: Hongyan Xia
Just for reviewing purposes, how does this relate
On 06.12.2019 17:51, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
> FAIL"):
>> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
>> FAIL"):
>>> On 25.11.2019 14:58, osstest service owner wrote:
>> ...
test-amd64-amd
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.5b-rc1-tag
xen: branch for v5.5-rc1
It contains:
- a patch to fix a build warning
- a cleanup of no longer needed code in the Xen event handling
- a small series for the Xen gran
Hi Ian,
On 06/12/2019 16:47, Ian Jackson wrote:
Hi. As you know I am working on getting osstest to work with Debian
buster. This is important because Debian's support for oldstable
(which is what stretch is now) is not always very good. Relying on
the LTS caused us serious problems before.
O
Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
FAIL"):
> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
> FAIL"):
> > On 25.11.2019 14:58, osstest service owner wrote:
> ...
> > > test-amd64-amd64-libvirt-xsm 7 xen-boot f
Hi. As you know I am working on getting osstest to work with Debian
buster. This is important because Debian's support for oldstable
(which is what stretch is now) is not always very good. Relying on
the LTS caused us serious problems before.
One of the issues I encountered is that the Xen and
Hi Jan,
On 06/12/2019 16:42, Jan Beulich wrote:
On 06.12.2019 17:20, Julien Grall wrote:
Hi,
On 06/12/2019 16:06, Jan Beulich wrote:
On 06.12.2019 15:46, Julien Grall wrote:
On 05/12/2019 16:50, Jan Beulich wrote:
On 05.12.2019 17:27, Julien Grall wrote:
On 05/12/2019 15:33, Jan Beulich wr
On 06.12.2019 17:20, Julien Grall wrote:
> Hi,
>
> On 06/12/2019 16:06, Jan Beulich wrote:
>> On 06.12.2019 15:46, Julien Grall wrote:
>>> On 05/12/2019 16:50, Jan Beulich wrote:
On 05.12.2019 17:27, Julien Grall wrote:
> On 05/12/2019 15:33, Jan Beulich wrote:
>> +/*
>> + * Strin
Hi,
On 06/12/2019 16:06, Jan Beulich wrote:
On 06.12.2019 15:46, Julien Grall wrote:
On 05/12/2019 16:50, Jan Beulich wrote:
On 05.12.2019 17:27, Julien Grall wrote:
On 05/12/2019 15:33, Jan Beulich wrote:
+/*
+ * String comparison functions mostly matching strcmp() / strncmp(),
+ * except t
On 06/12/2019 16:10, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/i8259.c
+++ b/xen/arch/x86/i8259.c
@@ -347,9 +347,9 @@ void __init init_IRQ(void)
if ( irq == 2 ) /* IRQ2 doesn't exist */
continue;
desc->handler = &i8259A_irq_type;
-per_cpu(vector_irq, cpu)[FIRST_LEGACY_VECTOR
On 06.12.2019 15:46, Julien Grall wrote:
> On 05/12/2019 16:50, Jan Beulich wrote:
>> On 05.12.2019 17:27, Julien Grall wrote:
>>> On 05/12/2019 15:33, Jan Beulich wrote:
+/*
+ * String comparison functions mostly matching strcmp() / strncmp(),
+ * except that they treat '-' and '_'
Thanks for the suggestions. I will attempt to restructure the code.
Hongyan
On Thu, 2019-12-05 at 12:12 +0100, Jan Beulich wrote:
> On 05.12.2019 12:02, Durrant, Paul wrote:
> > > -Original Message-
> > > From: Xen-devel On
> > > Behalf Of Jan
> > > Beulich
> > > Sent: 05 December 2019 1
map_pages_to_xen and modify_xen_mappings are performing almost exactly
the same operations when shattering an l3 PTE, the only difference
being whether we want to flush.
Signed-off-by: Hongyan Xia
---
xen/arch/x86/mm.c | 85 ++-
1 file changed, 40 inse
map_pages_to_xen and modify_xen_mappings use almost exactly the same
page shattering logic, and the code is mingled with other PTE
manipulations so it is less obvious that the intention is page
shattering. Factor out the functions to make them reusable and to make
the intention more obvious.
Of co
map_pages_to_xen and modify_xen_mappings are performing almost exactly
the same operations when shattering an l2 PTE, the only difference
being whether we want to flush.
Signed-off-by: Hongyan Xia
---
xen/arch/x86/mm.c | 81 ++-
1 file changed, 38 inse
> OK. FYI I'm going to have to stop reviewing here for a bit; if you
> re-send the series with the comments on 1-16 addressed though, I'll skim
> through and check it in if it looks good.
Okay, thanks for the heads up. I'm hoping to send v3 in the next few days.
-NR
On 11/21/19 3:02 PM, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not brake in case
> of a error and it is doing a best
On 12/6/19 2:46 PM, Julien Grall wrote:
> Hi Jan,
>
> On 05/12/2019 16:50, Jan Beulich wrote:
>> On 05.12.2019 17:27, Julien Grall wrote:
>>> On 05/12/2019 15:33, Jan Beulich wrote:
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -23,6 +23,49 @@ enum system_state system_state
On 12/6/19 8:48 AM, Stefan Nuernberger wrote:
> From: Uwe Dannowski
>
> Reading /sys/bus/pci/drivers/pciback/quirks while unbinding can result
> in dereferencing a NULL pointer. Instead, skip printing information
> about the dangling quirk.
>
> Reported-by: Conny Seidel
> Signed-off-by: Uwe Danno
Hi Jan,
On 05/12/2019 16:50, Jan Beulich wrote:
On 05.12.2019 17:27, Julien Grall wrote:
On 05/12/2019 15:33, Jan Beulich wrote:
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -23,6 +23,49 @@ enum system_state system_state = SYS_STA
xen_commandline_t saved_cmdline;
static const c
From: Uwe Dannowski
Reading /sys/bus/pci/drivers/pciback/quirks while unbinding can result
in dereferencing a NULL pointer. Instead, skip printing information
about the dangling quirk.
Reported-by: Conny Seidel
Signed-off-by: Uwe Dannowski
Signed-off-by: Stefan Nuernberger
Cc: xen-devel@list
On 12/6/19 12:17 PM, Jan Beulich wrote:
> On 06.12.2019 12:48, George Dunlap wrote:
>> --- a/CODING_STYLE
>> +++ b/CODING_STYLE
>> @@ -133,3 +133,86 @@ the end of files. It should be:
>> * indent-tabs-mode: nil
>> * End:
>> */
>> +
>> +Handling unexpected conditions
>> +-
flight 144586 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144586/
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 06.12.2019 12:48, George Dunlap wrote:
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -133,3 +133,86 @@ the end of files. It should be:
> * indent-tabs-mode: nil
> * End:
> */
> +
> +Handling unexpected conditions
> +--
> +
> +GUIDELINES:
> +
> +Passing errors
It's not always clear what the best way is to handle unexpected
conditions: whether with ASSERT(), domain_crash(), BUG_ON(), or some
other method. All methods have a risk of introducing security
vulnerabilities and unnecessary instabilities to production systems.
Provide guidelines for different
On 06.12.2019 11:33, Andrew Cooper wrote:
> On 06/12/2019 10:14, Jan Beulich wrote:
>> It is wrong for us to check the base address when there's no LDT in the
>> first place.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> TBD: I also wonder whether we wouldn't better set v->arch.pv.ldt_base to
>>
On 06.12.2019 11:25, Andrew Cooper wrote:
> On 06/12/2019 10:14, Jan Beulich wrote:
>> It is wrong for us to check frames beyond the guest specified limit.
>>
>> Signed-off-by: Jan Beulich
>
> I don't completely agree. The code has been like this since it was
> introduced, and is used to check d
flight 144574 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144574/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 144552
test-amd64-amd64-xl-qemut-win7-amd64
I have something to add that isn't correct in the minutes:
C."Outstanding issues".5)
About "libxl / CEPH backend support which impacts xl parameter passing to qemu":
I don't have a patch for it. I'm working on it but it's a bit
complicated.
It's broken in QEMU v4.0 .. v4.2 (releasing soon). Or q
On 12/5/19 6:39 PM, Nick Rosbrook wrote:
>> It actually occurs to me that the "named struct elements of union" would
>> still technically open up a window for divergence: i.e., if somehow the
>> type of the named struct didn't match up with the union element.
>>
>> I.e., the following *shouldn't* h
On 06/12/2019 10:37, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of
>> Andrew Cooper
>> Sent: 05 December 2019 15:31
>> To: Xen-devel List
>> Subject: Re: [Xen-devel] Xen 4.14 and future work
>>
>> On 02/12/2019 19:51, Andrew Cooper wrote:
>>> Hello,
>>>
>>> No
On 06/12/2019 10:15, Jan Beulich wrote:
> There's no need to invoke get_page_from_gfn(), and there's also no need
> to update the passed in frames[]. Invoke get_page_and_type() directly.
>
> Also make the function's frames[] parameter const, change its return
> type to int, and drop the bogus casts
> -Original Message-
> From: Xen-devel On Behalf Of
> Andrew Cooper
> Sent: 05 December 2019 15:31
> To: Xen-devel List
> Subject: Re: [Xen-devel] Xen 4.14 and future work
>
> On 02/12/2019 19:51, Andrew Cooper wrote:
> > Hello,
> >
> > Now that 4.13 is on its way out of the door, it is
On 06/12/2019 10:14, Jan Beulich wrote:
> It is wrong for us to check the base address when there's no LDT in the
> first place.
>
> Signed-off-by: Jan Beulich
> ---
> TBD: I also wonder whether we wouldn't better set v->arch.pv.ldt_base to
> zero for an empty LDT, just like do_mmuext_op() do
On 06/12/2019 10:14, Jan Beulich wrote:
> It is wrong for us to check frames beyond the guest specified limit.
>
> Signed-off-by: Jan Beulich
I don't completely agree. The code has been like this since it was
introduced, and is used to check data from the domain builder (inc
migration), and from
On 06/12/2019 10:18, Jan Beulich wrote:
> On 06.12.2019 11:14, Andrew Cooper wrote:
>> On 06/12/2019 09:58, Jan Beulich wrote:
>>> On 05.12.2019 23:30, Andrew Cooper wrote:
From testing this series, I have re-confirmed the previous reported
observation that:
# while :; do xen-
Vladimir Sementsov-Ogievskiy writes:
> 05.12.2019 17:58, Vladimir Sementsov-Ogievskiy wrote:
>> 05.12.2019 15:36, Markus Armbruster wrote:
>>> Vladimir Sementsov-Ogievskiy writes:
>>>
04.12.2019 17:59, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy writes:
>
>> Here is
On 06.12.2019 11:14, Andrew Cooper wrote:
> On 06/12/2019 09:58, Jan Beulich wrote:
>> On 05.12.2019 23:30, Andrew Cooper wrote:
>>> From testing this series, I have re-confirmed the previous reported
>>> observation that:
>>>
>>> # while :; do xen-hptool smt-enable; xen-hptool smt-disable; done
There's no need to invoke get_page_from_gfn(), and there's also no need
to update the passed in frames[]. Invoke get_page_and_type() directly.
Also make the function's frames[] parameter const, change its return
type to int, and drop the bogus casts from two of its invocations.
Finally a little b
On 06/12/2019 09:58, Jan Beulich wrote:
> On 05.12.2019 23:30, Andrew Cooper wrote:
>> From testing this series, I have re-confirmed the previous reported
>> observation that:
>>
>> # while :; do xen-hptool smt-enable; xen-hptool smt-disable; done
>>
>> in dom0 eventually causes the serial consol
It is wrong for us to check the base address when there's no LDT in the
first place.
Signed-off-by: Jan Beulich
---
TBD: I also wonder whether we wouldn't better set v->arch.pv.ldt_base to
zero for an empty LDT, just like do_mmuext_op() does.
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/d
It is wrong for us to check frames beyond the guest specified limit.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -840,6 +840,7 @@ int arch_set_info_guest(
#ifdef CONFIG_PV
mfn_t cr3_mfn;
struct page_info *cr3_page = NULL;
+unsigned int nr_
A few things stumbled across while doing the investigations.
1: relax GDT check in arch_set_info_guest()
2: relax LDT check in arch_set_info_guest()
3: PV: polish pv_set_gdt()
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.
flight 144583 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144583/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9caaa79dd7e078ebb4012dde3b3d3a5d451df609
baseline version:
ovmf 490a62beb7e1d084f14a9
On 05.12.2019 23:30, Andrew Cooper wrote:
> From testing this series, I have re-confirmed the previous reported
> observation that:
>
> # while :; do xen-hptool smt-enable; xen-hptool smt-disable; done
>
> in dom0 eventually causes the serial console to cease working (wedge midway
> through pri
On 06.12.2019 00:41, Lars Kurth wrote:
> I propose to add the following section to code-review-guide.md
>
>
> ## Problematic Patch Reviews
>
> A typical waterfall software development process is sequential with the
> following
> steps: define requirements, analyse, design, code, test and d
flight 144578 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144578/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 490a62beb7e1d084f14a93b895f9c89a49e4a51d
baseline version:
ovmf 0f9395d7c5cc6ae2beaa2
71 matches
Mail list logo
