flight 135163 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135163/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 135150 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135150/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
build-i386-pvops
Hi Stefano,
On 4/22/19 11:42 PM, Stefano Stabellini wrote:
On Tue, 26 Feb 2019, Julien Grall wrote:
I am not sure about the suggestion of re-using the libfdt concept of
"mem_rsv", which is meant to be for the old /memreserve/. Today, libfdt
(at least our version of it) is not able to parse the n
From: Andrii Anisov
The hypercall employs the same vcpu_register_runstate_memory_area
structure for the interface, but requires registered area to not
cross a page boundary.
Signed-off-by: Andrii Anisov
---
xen/common/domain.c | 5 -
xen/include/public/vcpu.h | 15 +++
2
From: Andrii Anisov
Following discussion [1] it is introduced and implemented a runstate
registration interface which uses guest's phys address instead of a virtual one.
The new hypercall employes the same data structures as a predecessor, but
expects the vcpu_runstate_info structure to not cross
From: Andrii Anisov
VCPUOP_register_runstate_phys_memory_area is implemented via runstate
area mapping.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/domain.c| 62 +
xen/arch/x86/domain.c| 105 +++
xen/common/doma
On Thu, Apr 18, 2019 at 02:59:17PM +0100, Andrew Cooper wrote:
> On 18/04/2019 13:31, Wei Liu wrote:
> > Hi all
> >
> > We now have Gitlab CI as a complementary system to Osstest and have planned
> > to
> > add bots. It's high time we think about how we integrate them and how it may
> > improve ou
Hello Dario,
On 20.04.19 18:24, Dario Faggioli wrote:
In schedule(), if we pick, as the next vcpu to run (next) the same one
that is running already (prev), we never get to call context_switch().
And what about `if ( prev != current )` in arm/domain.c:schedule_tail() ?
We can, therefore, ge
My mistake, I'm currently unable to reproduce the ~100 crashes
AFL found while fuzzing the master branch, on the current staging
branch. It seems some staged patch has since addressed this.
If it is of any interest, most of the crashes came from AVX512
instructions.
Sorry and thanks,
Sam
This involves initializing the boot params EFI related fields and the
efi global variable.
Without this fix a PVH dom0 doesn't detect when booted from EFI, and
thus doesn't support accessing any of the EFI related data.
Reported-by: PGNet Dev
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovs
Or else xen_domain() returns false despite xen_pvh being set.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/enlighten_pvh.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86
On 23/04/2019 11:28, Roger Pau Monne wrote:
> This involves initializing the boot params EFI related fields and the
> efi global variable.
>
> Without this fix a PVH dom0 doesn't detect when booted from EFI, and
> thus doesn't support accessing any of the EFI related data.
>
> Reported-by: PGNet
On Tue, Apr 23, 2019 at 11:36:10AM +0200, Juergen Gross wrote:
> On 23/04/2019 11:28, Roger Pau Monne wrote:
> > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> > index 4969817124a8..51ef98e96d88 100644
> > --- a/include/xen/xen-ops.h
> > +++ b/include/xen/xen-ops.h
> > @@ -209,6 +209,
On 20/04/2019 16:24, Dario Faggioli wrote:
> cpumask_weight() is known to be expensive. In Credit2, we use it in
> load-balancing, but only for knowing how many CPUs are active in a
> runqueue.
With a few small changes it can be improved substantially (by using
POPCNT when available), but it is st
On 23/04/2019 10:13, Andrii Anisov wrote:
> Hello Dario,
>
> On 20.04.19 18:24, Dario Faggioli wrote:
>> In schedule(), if we pick, as the next vcpu to run (next) the same one
>> that is running already (prev), we never get to call context_switch().
>
> And what about `if ( prev != current )` in ar
Hello Dario,
On 20.04.19 18:24, Dario Faggioli wrote:
cpumask_weight() is known to be expensive. In Credit2, we use it in
load-balancing, but only for knowing how many CPUs are active in a
runqueue.
Keeping such count in an integer field of the per-runqueue data
structure we have, completely av
> On Apr 20, 2019, at 4:24 PM, Dario Faggioli wrote:
>
> In schedule(), if we pick, as the next vcpu to run (next) the same one
> that is running already (prev), we never get to call context_switch().
>
> We can, therefore, get rid of all the `if`-s testing prev and next being
> different, tra
On 23/04/2019 11:50, George Dunlap wrote:
>
>
>> On Apr 20, 2019, at 4:24 PM, Dario Faggioli wrote:
>>
>> In schedule(), if we pick, as the next vcpu to run (next) the same one
>> that is running already (prev), we never get to call context_switch().
>>
>> We can, therefore, get rid of all the `
On 20/04/2019 16:24, Dario Faggioli wrote:
> In schedule(), if we pick, as the next vcpu to run (next) the same one
> that is running already (prev), we never get to call context_switch().
>
> We can, therefore, get rid of all the `if`-s testing prev and next being
> different, trading them with an
On 23/04/2019 10:10, Caccavale, Samuel wrote:
> My mistake, I'm currently unable to reproduce the ~100 crashes
> AFL found while fuzzing the master branch, on the current staging
> branch. It seems some staged patch has since addressed this.
>
> If it is of any interest, most of the crashes came
flight 135168 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135168/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
Yes. Current staging resolves all of the SIG-ILL related crashes.
Tangentially I have ~1000 crashes which fail the `ctxt->regs->r(ip) == orig_ip'
assert at x86_emulate/x86_emulate.c:9862 when compiling afl-harness statically
with afl-clang-fast. They do not reproduce when compiled dynamically or
On 23/04/2019 11:12, Caccavale, Samuel wrote:
> Yes. Current staging resolves all of the SIG-ILL related crashes.
>
> Tangentially I have ~1000 crashes which fail the `ctxt->regs->r(ip) ==
> orig_ip'
> assert at x86_emulate/x86_emulate.c:9862 when compiling afl-harness statically
> with afl-clang
flight 84103 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/84103/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
Hello Andrew,
On 23.04.19 12:47, Andrew Cooper wrote:
schedule_tail() is called with current from the continue_running() path.
Not on ARM. On ARM continue_running() is empty.
For the quick check I've put a BUG() into the `else` branch, and did not hit it
during system up, domain create/destroy
On 22/04/2019 13:39, Dongli Zhang wrote:
> Print log at level XENLOG_ERR (instead XENLOG_INFO) as domain_crash()
> indicates there is fatal error.
>
> Signed-off-by: Dongli Zhang
> ---
> xen/common/grant_table.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/common/g
Ping!
Hi George,
How do we proceed with the function naming?
Regards,
Alex
On 19.04.2019 11:32, Alexandru Stefan ISAILA wrote:
>
>
> On 18.04.2019 21:42, Tamas K Lengyel wrote:
>> On Thu, Apr 18, 2019 at 11:02 AM George Dunlap
>> wrote:
>>>
>>> On 4/18/19 2:59 PM, Tamas K Lengyel wrote:
>>>
range_straddles_page_boundary() is open coding several macros from
include/xen/page.h. Use those instead. Additionally there is no need
to have check_pages_physically_contiguous() as a separate function as
it is used only once, so merge it into range_straddles_page_boundary().
Signed-off-by: Juerg
While hunting an issue in swiotlb-xen I stumbled over a wrong test
and found some areas for improvement.
Juergen Gross (3):
xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()
xen/swiotlb: simplify range_straddles_page_boundary()
xen/swiotlb: remember having called xen_cre
Instead of always calling xen_destroy_contiguous_region() in case the
memory is DMA-able for the used device, do so only in case it has been
made DMA-able via xen_create_contiguous_region() before.
This will avoid a lot of xen_destroy_contiguous_region() calls for
64-bit capable devices.
As the m
The condition in xen_swiotlb_free_coherent() for deciding whether to
call xen_destroy_contiguous_region() is wrong: in case the region to
be freed is not contiguous calling xen_destroy_contiguous_region() is
the wrong thing to do: it would result in inconsistent mappings of
multiple PFNs to the sam
flight 135032 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135032/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 133468
test-armhf-armhf-libv
This change reflects the logic in epte_get_entry_emt() and allows
changes in guest MTTRs to be reflected in EPT for domains having
direct access to certain hardware memory regions but without IOMMU
context assigned (e.g. XenGT).
Signed-off-by: Igor Druzhinin
---
xen/arch/x86/hvm/mtrr.c | 2 +-
1
On 4/19/19 9:32 AM, Alexandru Stefan ISAILA wrote:
>
>
> On 18.04.2019 21:42, Tamas K Lengyel wrote:
>> On Thu, Apr 18, 2019 at 11:02 AM George Dunlap
>> wrote:
>>>
>>> On 4/18/19 2:59 PM, Tamas K Lengyel wrote:
On Thu, Apr 18, 2019 at 3:53 AM George Dunlap
wrote:
>
> On 4/1
On 4/23/19 11:37 AM, Andrew Cooper wrote:
> On 22/04/2019 13:39, Dongli Zhang wrote:
>> Print log at level XENLOG_ERR (instead XENLOG_INFO) as domain_crash()
>> indicates there is fatal error.
>>
>> Signed-off-by: Dongli Zhang
>> ---
>> xen/common/grant_table.c | 2 +-
>> 1 file changed, 1 insert
Most hardware that supports i386 supports amd64 too. When doing
builds we do need the right userland, but we don't actually care what
the kernel is doing. With Linux 32-on-64 is good for that.
Especially, there is a kernel regression (evident in the Debian
stretch kernel, but not present in jess
Useful when running on a tty interactively.
Signed-off-by: Ian Jackson
---
ts-syslog-server | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/ts-syslog-server b/ts-syslog-server
index 1234bb7d..06a07adf 100755
--- a/ts-syslog-server
+++ b/ts-syslog-server
@@ -28,6 +28
I am going to push this to osstest pretest right away. This problem
is currently blocking osstest's own self-push-gate and preventing many
other fixes from making it in...
Ian Jackson (3):
ts-syslog-server: --no-stdin option
sg-run-job, ts-host-install: New --build option
builds: Run i386 b
Used to specify that the host will be used for building. Currently
has no effect.
Signed-off-by: Ian Jackson
---
sg-run-job | 2 +-
ts-host-install | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/sg-run-job b/sg-run-job
index 56b6384a..7c58d4ba 100755
--- a/sg-run-job
Or else xen_domain() returns false despite xen_pvh being set.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/enlighten_pvh.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86
This involves initializing the boot params EFI related fields and the
efi global variable.
Without this fix a PVH dom0 doesn't detect when booted from EFI, and
thus doesn't support accessing any of the EFI related data.
Reported-by: PGNet Dev
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovs
flight 135173 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135173/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On Tue, Apr 23, 2019 at 5:45 AM George Dunlap wrote:
>
> On 4/19/19 9:32 AM, Alexandru Stefan ISAILA wrote:
> >
> >
> > On 18.04.2019 21:42, Tamas K Lengyel wrote:
> >> On Thu, Apr 18, 2019 at 11:02 AM George Dunlap
> >> wrote:
> >>>
> >>> On 4/18/19 2:59 PM, Tamas K Lengyel wrote:
> On Thu
flight 135166 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135166/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
build-i386-pvops
On 4/23/19 9:04 AM, Roger Pau Monne wrote:
> Or else xen_domain() returns false despite xen_pvh being set.
Is this new xen_domain() invocation somewhere in EFI initialization that
you add in the second patch?
Asking because I am trying to figure out whether this needs to go to
stable tree.
-bori
Hello Julien, Roger
On Thu, 2019-04-18 at 19:33 +0100, Julien Grall wrote:
> (+ Roger)
>
> On 18/04/2019 12:15, Artem Mygaiev wrote:
> > Hi Julien
> >
> > On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> > > On 18/04/2019 10:15, Artem Mygaiev wrote:
> > > > Hello Julien, Stefano
> > >
>
flight 135037 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135037/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134611
build-arm64
On 4/23/19 6:54 AM, Juergen Gross wrote:
> The condition in xen_swiotlb_free_coherent() for deciding whether to
> call xen_destroy_contiguous_region() is wrong: in case the region to
> be freed is not contiguous calling xen_destroy_contiguous_region() is
> the wrong thing to do: it would result in
On 4/23/19 6:54 AM, Juergen Gross wrote:
> range_straddles_page_boundary() is open coding several macros from
> include/xen/page.h. Use those instead. Additionally there is no need
> to have check_pages_physically_contiguous() as a separate function as
> it is used only once, so merge it into range
On 4/23/19 6:54 AM, Juergen Gross wrote:
> Instead of always calling xen_destroy_contiguous_region() in case the
> memory is DMA-able for the used device, do so only in case it has been
> made DMA-able via xen_create_contiguous_region() before.
>
> This will avoid a lot of xen_destroy_contiguous_re
The code for getting the entry and then populating was repeated in
p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
The code is now in one place with a bool param that lets the caller choose
if it populates after get_entry().
If remapping is being done then both the old and new gfn's s
On Tue, Apr 23, 2019 at 09:37:51AM -0400, Boris Ostrovsky wrote:
> On 4/23/19 9:04 AM, Roger Pau Monne wrote:
> > Or else xen_domain() returns false despite xen_pvh being set.
>
> Is this new xen_domain() invocation somewhere in EFI initialization that
> you add in the second patch?
Yes, there's
flight 135041 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135041/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 129313
test-amd64-amd64-exa
On Tue, Apr 16, 2019 at 12:58:30PM +, Pawel Wieczorkiewicz wrote:
> This change is part of a independant stacked hotpatch modules
> feature. This feature allows to bypass dependencies between modules
> upon loading, but still verifies Xen build ID matching.
OK, so build_id_dep would not be cal
Previous attempts to fix this leak failed to identify the root cause, and
ultimately failed. The cause is the CPU_UP_PREPARE case (re)initialising
ts->heap back to dummy_heap, which leaks the previous allocation.
Rearrange the logic to only initialise ts once. This also avoids the
redundant (but
Wei Liu writes ("Re: [PATCH 1/2] build system: make install-stubdom depend on
install-tools again"):
> On Mon, Apr 15, 2019 at 05:28:08PM +0100, Ian Jackson wrote:
> > In d290e325179ccee966cd679d0fed48be6f4cc1b7
> > "build system: don't let install-stubdom depend on install-tools"
> > the depend
On 23/04/2019 12:47, George Dunlap wrote:
> On 4/23/19 11:37 AM, Andrew Cooper wrote:
>> On 22/04/2019 13:39, Dongli Zhang wrote:
>>> Print log at level XENLOG_ERR (instead XENLOG_INFO) as domain_crash()
>>> indicates there is fatal error.
>>>
>>> Signed-off-by: Dongli Zhang
>>> ---
>>> xen/commo
On Tue, 23 Apr 2019, Juergen Gross wrote:
> Instead of always calling xen_destroy_contiguous_region() in case the
> memory is DMA-able for the used device, do so only in case it has been
> made DMA-able via xen_create_contiguous_region() before.
>
> This will avoid a lot of xen_destroy_contiguous_
flight 135183 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135183/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On Tue, 23 Apr 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 4/22/19 11:42 PM, Stefano Stabellini wrote:
> > On Tue, 26 Feb 2019, Julien Grall wrote:
> > I am not sure about the suggestion of re-using the libfdt concept of
> > "mem_rsv", which is meant to be for the old /memreserve/. Today, libfd
On Tue, Apr 23, 2019 at 8:30 AM Alexandru Stefan ISAILA
wrote:
>
> The code for getting the entry and then populating was repeated in
> p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
>
> The code is now in one place with a bool param that lets the caller choose
> if it populates after
On 23/04/2019 19:05, Stefano Stabellini wrote:
> On Tue, 23 Apr 2019, Juergen Gross wrote:
>> Instead of always calling xen_destroy_contiguous_region() in case the
>> memory is DMA-able for the used device, do so only in case it has been
>> made DMA-able via xen_create_contiguous_region() before.
>
Hi,
Sorry for the formatting.
On Tue, 23 Apr 2019, 18:34 Stefano Stabellini,
wrote:
> On Tue, 23 Apr 2019, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 4/22/19 11:42 PM, Stefano Stabellini wrote:
> > > On Tue, 26 Feb 2019, Julien Grall wrote:
> > > I am not sure about the suggestion of re-usi
flight 135182 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135182/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
version targeted for testi
On Tue, 23 Apr 2019, Julien Grall wrote:
> Hi,
>
> Sorry for the formatting.
>
> On Tue, 23 Apr 2019, 18:34 Stefano Stabellini, wrote:
> On Tue, 23 Apr 2019, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 4/22/19 11:42 PM, Stefano Stabellini wrote:
> > > On Tue, 26
flight 135198 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135198/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On Monday 22 April 2019 12:28, Andrew Cooper wrote:
> On 21/04/2019 23:26, Mathieu Tarral wrote:
>
> Answering out of order.
>
> > I discussed this bug on IRC with andyhpp, who convinced me to move the
> > discussion on the mailing list.
> > Apparently the singlestepping in Xen was in a poor qua
flight 135029 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135029/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134594
build-arm64-pvop
> Also, it's not the first time i'm having this bug,
> I was already working on Xen 6 months before:
> https://github.com/libvmi/libvmi/issues/636
I forgot to add that I was running Xen bare-metal at that time,
so yes, the bug is reproducible without KVM and nested virtualization.
___
flight 135190 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135190/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-laxton0 5 host-install broken blocked in 134020
examine-laxton1 5 host-inst
flight 135204 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135204/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On Mon, 22 Apr 2019, Julien Grall wrote:
> CONFIG_EARLY_PRINTK can only be set when CONFIG_DEBUG is enabled. It can
> be quite convenient to only modify the target.
>
> However, the target clean will not include the .config.
>
> This means CONFIG_DEBUG is not enabled and therefore make will throw
flight 135211 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135211/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 135055 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135055/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 130965
build-i386
flight 135202 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135202/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 134977
build-i386
flight 135057 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135057/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
test-amd64-amd64-xl
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, April 15, 2019 8:03 PM
>
> * Fix the shim build by providing a !CONFIG_HVM declaration for
>hvm_get_guest_bndcfgs(), and removing the introduced
>ASSERT(is_hvm_domain(d))'s. They are needed for DCE to keep the build
77 matches
Mail list logo
