flight 142274 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142274/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d19040804afb2bdd60f18e8aef7da78028575fe6
baseline version:
ovmf
flight 142263 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142263/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-raw7 xen-boot fail like 142223
test-amd64-i386-examine 8
flight 142265 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142265/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142019 REGR.
vs. 139698
Tests
flight 142258 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-amd
testid redhat-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On Wed, Oct 02, 2019 at 12:49:35PM +0200, Roger Pau Monne wrote:
>The current implementation of host_maskall makes it sticky across
>assign and deassign calls, which means that once a guest forces Xen to
>set host_maskall the maskall bit is not going to be cleared until a
>call to
When reserved-memory regions are present in the host device tree, dom0
is started with multiple memory nodes. Each memory node should have a
unique name, but today they are all called "memory" leading to Linux
printing the following warning at boot:
OF: Duplicate name in base, renamed to
flight 142284 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142284/
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
Thank you Wei,
I just didn't realize that. I thought that an applicant should know what
bugs already existed and tried to fix them. I was trying to find some
on the github page but haven't succeeded.
But now I can try to do my best. At least, I will try to help with typo
extermination.
On Thu,
flight 142249 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142249/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 141822
The pull request you sent on Fri, 4 Oct 2019 07:05:20 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.4-rc2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/50dfd03d9579cde9150679e90f8f244c626b7a09
Thank you!
--
Deet-doot-dot, I
flight 142276 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142276/
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
On 10/4/19 12:42 PM, Julien Grall wrote:
flask_assign_{, dt}device() may be used to check whether you can test if
a device is assigned. In this case, the domain will be NULL.
However, flask_iommu_resource_use_perm() will be called and may end up
to deference a NULL pointer. This can be
On 10/4/19 12:56 PM, Julien Grall wrote:
xmalloc_array() may return NULL if there are memory. Rather than trying
to deference it directly, we should check the return value first.
Coverity-ID: 1381852
Signed-off-by: Julien Grall
Acked-by: Daniel De Graaf
On 04/10/2019 14:30, Jan Beulich wrote:
> On 04.10.2019 15:18, Andrew Cooper wrote:
>> On 26/09/2019 15:28, Jan Beulich wrote:
>>> @@ -1068,8 +1067,29 @@ static void * __init allocate_ppr_log(st
>>> IOMMU_PPR_LOG_DEFAULT_ENTRIES, "PPR Log");
>>> }
>>>
>>> +/*
On Fri, Oct 04, 2019 at 05:04:27PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [XEN PATCH for-4.13 3/6] libxl:
> libxl__domain_config_setdefault: New function"):
> > On Fri, Oct 04, 2019 at 04:17:04PM +0100, Ian Jackson wrote:
> > > +
On Fri, Oct 04, 2019 at 04:17:03PM +0100, Ian Jackson wrote:
> We are going to change the libxl API in a moment and this change will
> make it simpler.
>
> Signed-off-by: Ian Jackson
Reviewed-by: Anthony PERARD
--
Anthony PERARD
___
Xen-devel
On Fri, Oct 04, 2019 at 04:17:07PM +0100, Ian Jackson wrote:
> These are now redundant because shadow_memkb and iommu_memkb are now
> defaulted automatically by libxl_domain_need_memory and
> libxl_domain_create etc. Callers should not now call these; instead,
> they should just let libxl take
Anthony PERARD writes ("Re: [XEN PATCH for-4.13 5/6] libxl: Move shadow_memkb
and iommu_memkb defaulting into libxl"):
> On Fri, Oct 04, 2019 at 04:17:06PM +0100, Ian Jackson wrote:
> > @@ -862,6 +864,30 @@ static void domcreate_destruction_cb(libxl__egc *egc,
> >
On Fri, Oct 04, 2019 at 04:17:06PM +0100, Ian Jackson wrote:
> @@ -862,6 +864,30 @@ static void domcreate_destruction_cb(libxl__egc *egc,
> libxl__domain_destroy_state *dds,
> int rc);
>
> +static _Bool
On 10/2/19 9:11 AM, Jan Beulich wrote:
> On 01.10.2019 22:59, Andrew Cooper wrote:
>> On 01/10/2019 09:38, Jan Beulich wrote:
>>> 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
xmalloc_array() may return NULL if there are memory. Rather than trying
to deference it directly, we should check the return value first.
Coverity-ID: 1381852
Signed-off-by: Julien Grall
---
xen/xsm/flask/ss/services.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On 10/2/19 10:10 AM, Andrew Cooper wrote:
> On 02/10/2019 09:40, Jan Beulich wrote:
>> On 01.10.2019 17:11, 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
flask_assign_{, dt}device() may be used to check whether you can test if
a device is assigned. In this case, the domain will be NULL.
However, flask_iommu_resource_use_perm() will be called and may end up
to deference a NULL pointer. This can be prevented by moving the call
after we check the
flight 142264 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142264/
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 Fri, Oct 04, 2019 at 04:17:05PM +0100, Ian Jackson wrote:
> diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
> index fd6f33312e..26cf136ac2 100644
> --- a/tools/libxl/libxl_mem.c
> +++ b/tools/libxl/libxl_mem.c
> @@ -446,20 +446,12 @@ int libxl_get_memory_target_0x040700(
>
On 10/4/19 4:40 PM, Jürgen Groß wrote:
> On 04.10.19 17:37, George Dunlap wrote:
>> On 10/4/19 4:03 PM, Jürgen Groß wrote:
>>> On 04.10.19 16:56, George Dunlap wrote:
On 10/4/19 3:43 PM, Jürgen Groß wrote:
> On 04.10.19 16:34, George Dunlap wrote:
>> On 10/4/19 3:24 PM, Jürgen Groß
Anthony PERARD writes ("Re: [XEN PATCH for-4.13 1/6] libxl: Offer API versions
0x040700 and 0x040800"):
> On Fri, Oct 04, 2019 at 04:17:02PM +0100, Ian Jackson wrote:
> > It is surprising that no-one noticed this. I wonder if anyone is
> > using our LIBXL_API_VERSION facility. If not maybe we
Anthony PERARD writes ("Re: [XEN PATCH for-4.13 3/6] libxl:
libxl__domain_config_setdefault: New function"):
> On Fri, Oct 04, 2019 at 04:17:04PM +0100, Ian Jackson wrote:
> > +libxl__domain_config_setdefault(gc,d_config,domid);
>
> Shouldn't you check for error ?
Blimey, yes! Thanks!
Jürgen Groß writes ("Re: [PATCH v8 1/4] libxl: fix cold plugged PCI device with
stubdomain"):
> On 02.10.19 17:43, Ian Jackson wrote:
> > Hi Juergen. This series
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg03072.html
> > needs your release review.
>
> Fir the
Marek Marczykowski-Górecki writes ("[PATCH v8 2/4] libxl: do not attach
xen-pciback to HVM domain, if stubdomain is in use"):
> HVM domains use IOMMU and device model assistance for communicating with
> PCI devices, xen-pcifront/pciback isn't directly needed by HVM domain.
> But pciback serve
Jürgen Groß writes ("Re: [PATCH 0/2] libxl fixes with pci passthrough"):
> On 02.10.19 17:45, Ian Jackson wrote:
> > Hi Juergen. Here's another bugfix series
> >
> > https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg03320.html
> >
On Fri, Oct 04, 2019 at 04:17:04PM +0100, Ian Jackson wrote:
> Break out this into a new function. We are going to want to call it
> from a new call site.
>
> Unfortunately not all of the defaults can be moved into the new
> function without changing the order in which things are done. That
>
flight 142252 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142252/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142080
test-armhf-armhf-libvirt-raw 13
On 04.10.19 17:37, George Dunlap wrote:
On 10/4/19 4:03 PM, Jürgen Groß wrote:
On 04.10.19 16:56, George Dunlap wrote:
On 10/4/19 3:43 PM, Jürgen Groß wrote:
On 04.10.19 16:34, George Dunlap wrote:
On 10/4/19 3:24 PM, Jürgen Groß wrote:
On 04.10.19 16:08, George Dunlap wrote:
On 10/4/19
On 10/4/19 4:03 PM, Jürgen Groß wrote:
> On 04.10.19 16:56, George Dunlap wrote:
>> On 10/4/19 3:43 PM, Jürgen Groß wrote:
>>> On 04.10.19 16:34, George Dunlap wrote:
On 10/4/19 3:24 PM, Jürgen Groß wrote:
> On 04.10.19 16:08, George Dunlap wrote:
>> On 10/4/19 7:40 AM, Juergen Gross
On Fri, Oct 04, 2019 at 10:49:28AM +0100, Julien Grall wrote:
> Hi Brian,
>
> On 04/10/2019 01:25, Brian Woods wrote:
> >
> >In the log, there's:
> >(XEN) MODULE[0]: 0140 - 015328f1 Xen
> >(XEN) MODULE[1]: 076d2000 - 076dc080 Device Tree
> >(XEN) MODULE[2]:
On Fri, Oct 04, 2019 at 04:17:02PM +0100, Ian Jackson wrote:
> According to git log -G:
>
> 0x040700 was introduced in 304400459ef0 (aka 4.7.0-rc1~481)
> "tools/libxl: rename remus device to checkpoint device"
>
> 0x040800 was introduced in 57f8b13c7240 (aka 4.8.0-rc1~437)
> "libxl: memory
We are going to change the libxl API in a moment and this change will
make it simpler.
Signed-off-by: Ian Jackson
---
tools/xl/xl_vmcontrol.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index b20582e15b..d33c6b38c9
This should calculate the extra memory needed for shadow and iommu,
the defaults for which depend on values in c_info. So we need this to
have the complete domain config available.
And the defaults should actually be updated and stored. So make it
non-const.
We provide the usual kind of
Break out this into a new function. We are going to want to call it
from a new call site.
Unfortunately not all of the defaults can be moved into the new
function without changing the order in which things are done. That
does not seem wise at this stage of the release. The effect is that
These are now redundant because shadow_memkb and iommu_memkb are now
defaulted automatically by libxl_domain_need_memory and
libxl_domain_create etc. Callers should not now call these; instead,
they should just let libxl take care of it.
libxl_get_required_shadow_memory was introduced in
libxl_get_required_shadow_memory has always been anomalous. libxl
ought to default these things itself. Recently, another analogous
setting, iommu_memkb, was introduced, along with another function
along the same lines.
This API is not very good. Fixing it was not entirely trivial.
(Thanks to
Defaulting is supposed to be done by libxl. So these calculations
should be here in libxl. libxl__domain_config_setdefault has all the
necessary information including the values of max_memkb and max_vcpus.
The overall functional effect depends on the caller:
For xl, no change. The code moves
According to git log -G:
0x040700 was introduced in 304400459ef0 (aka 4.7.0-rc1~481)
"tools/libxl: rename remus device to checkpoint device"
0x040800 was introduced in 57f8b13c7240 (aka 4.8.0-rc1~437)
"libxl: memory size in kb requires 64 bit variable"
It is surprising that no-one noticed
On 04.10.19 16:56, George Dunlap wrote:
On 10/4/19 3:43 PM, Jürgen Groß wrote:
On 04.10.19 16:34, George Dunlap wrote:
On 10/4/19 3:24 PM, Jürgen Groß wrote:
On 04.10.19 16:08, George Dunlap wrote:
On 10/4/19 7:40 AM, Juergen Gross wrote:
sched_tick_suspend() and sched_tick_resume() should
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
arch/Kconfig | 4 ++--
arch/alpha/Kconfig | 2 +-
On 10/4/19 3:43 PM, Jürgen Groß wrote:
> On 04.10.19 16:34, George Dunlap wrote:
>> On 10/4/19 3:24 PM, Jürgen Groß wrote:
>>> On 04.10.19 16:08, George Dunlap wrote:
On 10/4/19 7:40 AM, Juergen Gross wrote:
> sched_tick_suspend() and sched_tick_resume() should not call the
>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
certs/Kconfig | 14 ++---
init/Kconfig | 28 +-
On 04/10/2019 15:29, Dario Faggioli wrote:
> On Fri, 2019-10-04 at 08:50 +0100, Andrew Cooper wrote:
>> On 04/10/2019 07:40, Juergen Gross wrote:
>>> sched_tick_suspend() and sched_tick_resume() should not call the
>>> scheduler specific timer handlers in case the cpu they are running
>>> on
>>>
On 04.10.19 16:34, George Dunlap wrote:
On 10/4/19 3:24 PM, Jürgen Groß wrote:
On 04.10.19 16:08, George Dunlap wrote:
On 10/4/19 7:40 AM, Juergen Gross wrote:
sched_tick_suspend() and sched_tick_resume() should not call the
scheduler specific timer handlers in case the cpu they are running
On 10/4/19 3:24 PM, Jürgen Groß wrote:
> On 04.10.19 16:08, George Dunlap wrote:
>> On 10/4/19 7:40 AM, Juergen Gross wrote:
>>> sched_tick_suspend() and sched_tick_resume() should not call the
>>> scheduler specific timer handlers in case the cpu they are running on
>>> is just being moved to or
On Fri, 2019-10-04 at 08:50 +0100, Andrew Cooper wrote:
> On 04/10/2019 07:40, Juergen Gross wrote:
> > sched_tick_suspend() and sched_tick_resume() should not call the
> > scheduler specific timer handlers in case the cpu they are running
> > on
> > is just being moved to or from a cpupool.
> >
On 04.10.19 16:08, George Dunlap wrote:
On 10/4/19 7:40 AM, Juergen Gross wrote:
sched_tick_suspend() and sched_tick_resume() should not call the
scheduler specific timer handlers in case the cpu they are running on
is just being moved to or from a cpupool.
Use a new percpu lock for that
flight 142250 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142250/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 61af5f249495b18f45ca164376c871081448c0e4
baseline version:
ovmf
On 10/4/19 7:40 AM, Juergen Gross wrote:
> sched_tick_suspend() and sched_tick_resume() should not call the
> scheduler specific timer handlers in case the cpu they are running on
> is just being moved to or from a cpupool.
>
> Use a new percpu lock for that purpose.
Is there a reason we can't
flight 142268 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142268/
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
On 26/09/2019 15:29, Jan Beulich wrote:
> Make sure we don't leave any DTEs unexpected requests through which
> would be passed through untranslated. Set V and IV right away (with
> all other fields left as zero), relying on the V and/or IV bits
> getting cleared only by
On 04.10.2019 15:26, Andrew Cooper wrote:
> On 26/09/2019 15:29, Jan Beulich wrote:
>> The command ring buffer doesn't need clearing up front in any event.
>> Subsequently we'll also want to avoid clearing the device tables.
>>
>> While playing with functions signatures replace undue use of fixed
On 04.10.2019 15:18, Andrew Cooper wrote:
> On 26/09/2019 15:28, Jan Beulich wrote:
>> @@ -1068,8 +1067,29 @@ static void * __init allocate_ppr_log(st
>> IOMMU_PPR_LOG_DEFAULT_ENTRIES, "PPR Log");
>> }
>>
>> +/*
>> + * Within ivrs_mappings[] we allocate an extra
On 26/09/2019 15:29, Jan Beulich wrote:
> The command ring buffer doesn't need clearing up front in any event.
> Subsequently we'll also want to avoid clearing the device tables.
>
> While playing with functions signatures replace undue use of fixed width
> types at the same time, and extend this
On 26/09/2019 15:28, Jan Beulich wrote:
> @@ -1068,8 +1067,29 @@ static void * __init allocate_ppr_log(st
> IOMMU_PPR_LOG_DEFAULT_ENTRIES, "PPR Log");
> }
>
> +/*
> + * Within ivrs_mappings[] we allocate an extra array element to store
> + * - segment number,
>
On 04/10/2019 14:04, Jan Beulich wrote:
> On 04.10.2019 13:33, Igor Druzhinin wrote:
>> On 04/10/2019 11:40, Jan Beulich wrote:
>>> On 03.10.2019 15:49, Igor Druzhinin wrote:
If a bootloader is using native driver instead of EFI GOP it might
reset graphics mode to be different from what
On 04.10.2019 13:33, Igor Druzhinin wrote:
> On 04/10/2019 11:40, Jan Beulich wrote:
>> On 03.10.2019 15:49, Igor Druzhinin wrote:
>>> If a bootloader is using native driver instead of EFI GOP it might
>>> reset graphics mode to be different from what firmware thinks it
>>> currently is. Set
On 04.10.2019 13:25, Igor Druzhinin wrote:
> On 04/10/2019 12:14, Jan Beulich wrote:
>> On 04.10.2019 12:54, Igor Druzhinin wrote:
>>> On 04/10/2019 11:34, Jan Beulich wrote:
On 03.10.2019 15:49, Igor Druzhinin wrote:
> - 0 is a possible and allowed value for a color mask accroding to
On 02/10/2019 10:17, Jan Beulich wrote:
> On 02.10.2019 10:51, Andrew Cooper wrote:
>> On 02/10/2019 08:07, Jan Beulich wrote:
>>> On 01.10.2019 21:44, Andrew Cooper wrote:
In this example, hardware can the emulator can disagree by using a
different access width.
I've been
flight 142243 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
140282
> On 2. Oct 2019, at 23:02, Andrew Cooper wrote:
>
> On 02/10/2019 10:50, Wieczorkiewicz, Pawel wrote:
>> I've taken, as a simple example,
>> p2m_mem_access_sanity_check(), and this looks to be the way gcc9 has
>> generated
>> code (in a non-debug build). Hence either I'm
On 04/10/2019 11:40, Jan Beulich wrote:
> On 03.10.2019 15:49, Igor Druzhinin wrote:
>> If a bootloader is using native driver instead of EFI GOP it might
>> reset graphics mode to be different from what firmware thinks it
>> currently is. Set chosen mode unconditionally to fix this possible
>>
On 04/10/2019 12:14, Jan Beulich wrote:
> On 04.10.2019 12:54, Igor Druzhinin wrote:
>> On 04/10/2019 11:34, Jan Beulich wrote:
>>> On 03.10.2019 15:49, Igor Druzhinin wrote:
- 0 is a possible and allowed value for a color mask accroding to
UEFI Spec 2.6 (11.9) especially for reserved
On 04.10.2019 12:54, Igor Druzhinin wrote:
> On 04/10/2019 11:34, Jan Beulich wrote:
>> On 03.10.2019 15:49, Igor Druzhinin wrote:
>>> - 0 is a possible and allowed value for a color mask accroding to
>>> UEFI Spec 2.6 (11.9) especially for reserved mask
>>
>> Hmm, looking at 2.8 (where it's
On 04/10/2019 11:34, Jan Beulich wrote:
> On 03.10.2019 15:49, Igor Druzhinin wrote:
>> - 0 is a possible and allowed value for a color mask accroding to
>> UEFI Spec 2.6 (11.9) especially for reserved mask
>
> Hmm, looking at 2.8 (where it's section 12.9, which in turn is why
> section titles
On 03.10.2019 15:49, Igor Druzhinin wrote:
> If a bootloader is using native driver instead of EFI GOP it might
> reset graphics mode to be different from what firmware thinks it
> currently is. Set chosen mode unconditionally to fix this possible
> misalignment.
>
> Observed with EFI GRUB2
On 03.10.2019 15:49, Igor Druzhinin wrote:
> - 0 is a possible and allowed value for a color mask accroding to
> UEFI Spec 2.6 (11.9) especially for reserved mask
Hmm, looking at 2.8 (where it's section 12.9, which in turn is why
section titles would be more helpful in such references) I can't
On 03.10.2019 16:25, Andrew Cooper wrote:
> The names in retpoline_safe() are copied from should_use_eager_fpu(). The
> names in mds_calculations() come partly from Linux's intel-family.h, and
> partly from conversations with Intel.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Hi Brian,
On 04/10/2019 01:25, Brian Woods wrote:
On Thu, Oct 03, 2019 at 10:20:36PM +0100, Julien Grall wrote:
Hi Brian,
On 10/3/19 9:24 PM, Brian Woods wrote:
On Thu, Oct 03, 2019 at 07:23:23PM +, Julien Grall wrote:
There's a WARN_ON() between the two debug printks calls I shared
flight 14 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/14/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142019 REGR.
vs. 139698
Tests
On Thu, Oct 03, 2019 at 04:12:30PM +, Lars Kurth wrote:
> Specifically
> * xen.org to xenproject.org
> * http to https
> * Replaced pages where page has moved
> (including on xen pages as well as external pages)
> * Removed some URLs (e.g. downloads for Linux PV drivers)
>
> Tested-by: Lars
On 02.10.2019 21:31, Andrew Cooper wrote:
> On 02/10/2019 09:24, Jan Beulich wrote:
>> On 01.10.2019 17:37, Andrew Cooper wrote:
>>> On 01/10/2019 15:32, Jan Beulich wrote:
On 01.10.2019 14:51, Andrew Cooper wrote:
> On 01/10/2019 13:21, Jan Beulich wrote:
>> On 30.09.2019 20:24,
On Thu, Oct 03, 2019 at 04:12:30PM +, Lars Kurth wrote:
> Specifically
> * xen.org to xenproject.org
> * http to https
> * Replaced pages where page has moved
> (including on xen pages as well as external pages)
> * Removed some URLs (e.g. downloads for Linux PV drivers)
>
> Tested-by: Lars
On Thu, Oct 03, 2019 at 11:47:36AM +0100, Andrew Cooper wrote:
> Linux has started using RDTSCP as of v5.1. This has highlighted a bug in Xen,
> where virtual vmexit simply gives up.
>
> (XEN) d1v1 Unhandled nested vmexit: reason 51
> (XEN) domain_crash called from vvmx.c:2671
> (XEN)
On 03/10/2019 17:12, Lars Kurth wrote:
> Specifically
> * xen.org to xenproject.org
> * http to https
> * Replaced pages where page has moved
> (including on xen pages as well as external pages)
> * Removed some URLs (e.g. downloads for Linux PV drivers)
>
> Tested-by: Lars Kurth
>
Hi Stefano,
On 04/10/2019 02:14, Stefano Stabellini wrote:
+
+Dom0-less Device Passthrough
+
+
+The partial device tree for dom0-less guests should have the following
+properties for each node corresponding to a physical device to assign to
+the guest:
+
+- xen,reg
+
Hi Stefano,
On 04/10/2019 02:14, Stefano Stabellini wrote:
Scan the user provided dtb fragment at boot. For each device node, map
memory to guests, and route interrupts and setup the iommu.
The memory region to remap is specified by the "xen,reg" property.
The iommu is setup by passing the
On 04/10/2019 07:40, Juergen Gross wrote:
> sched_tick_suspend() and sched_tick_resume() should not call the
> scheduler specific timer handlers in case the cpu they are running on
> is just being moved to or from a cpupool.
>
> Use a new percpu lock for that purpose.
>
> Reported-by: Sergey
flight 142223 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142223/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580
sched_tick_suspend() and sched_tick_resume() should not call the
scheduler specific timer handlers in case the cpu they are running on
is just being moved to or from a cpupool.
Use a new percpu lock for that purpose.
Reported-by: Sergey Dyasli
Signed-off-by: Juergen Gross
---
To be applied on
flight 142224 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142224/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 141913
test-amd64-i386-qemut-rhel6hvm-amd 12
88 matches
Mail list logo
