flight 135185 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135185/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134611
build-arm64
flight 135175 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135175/
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
flight 135307 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135307/
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
flight 135308 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135308/
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 135191 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135191/
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
build-i386-libvirt
flight 135306 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135306/
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 Thu, Apr 25, 2019 at 2:01 PM Andrew Cooper wrote:
>
> On 25/04/2019 20:57, Tamas K Lengyel wrote:
> > On Thu, Apr 25, 2019 at 12:58 PM Andrew Cooper
> > wrote:
> >> On 25/04/2019 16:32, Tamas K Lengyel wrote:
> >>> diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
> >>> index 6f
> On Apr 25, 2019, at 12:36, Lars Kurth wrote:
>
> Alright,
>
> there was a lengthy discussion on this topic on IRC - log attached. The
> consensus appears to be to use Canonical messages with a CAPITALISED tag.
> E.g. "[TAG] Xen 4.13 Development Update".
>
> The options which seemed to have
flight 135305 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135305/
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 135295 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135295/
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 Thu, 25 Apr 2019, Jan Beulich wrote:
> >>> On 17.04.19 at 23:12, wrote:
> > On Wed, 27 Feb 2019, Jan Beulich wrote:
> >> >>> On 27.02.19 at 00:07, wrote:
> >> > --- a/xen/include/public/domctl.h
> >> > +++ b/xen/include/public/domctl.h
> >> > @@ -571,12 +571,14 @@ struct xen_domctl_bind_pt_irq
Hi Stefano,
On 25/04/2019 18:51, Stefano Stabellini wrote:
> Xen assumes that RAM starts at addresses greater than 0x0 in a few
> places. The PDX code is one of them but there are more.
A bit more context in the commit message would have been useful. Imagine
if we have to look at the commit mess
On 25/04/2019 19:01, Andrii Anisov wrote:
>
>
> On 17.04.19 20:58, Julien Grall wrote:
>> All the TLBs helpers invalidate all the TLB entries are using the same
>> pattern:
>> DSB SY
>> TLBI ...
>> DSB SY
>> ISB
>>
>> This pattern is following pattern recommended by the Arm
On 25/04/2019 19:00, Andrii Anisov wrote:
> Hello Julien,
Hi,
> On 17.04.19 20:58, Julien Grall wrote:
>> The function flush_xen_text_tlb_local() has been misused and will result
>> to invalidate the instruction cache more than necessary.
>>
>> For instance, there are no need to invalidate the
flight 135304 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135304/
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
Hi,
On 25/04/2019 19:00, Andrii Anisov wrote:
>
>
> On 17.04.19 20:58, Julien Grall wrote:
>> The logic to set SCTLR_EL2.WXN is the same for the boot CPU and
>> non-boot CPU. So introduce a function to set the bit and clear TBLs.
> s/TBL/TLB/
>
>>
>> This new function will help us to document a
This aperture doesn't exist in QEMU-XEN and hvmloader places BARs
in arbitrary order disregarding prefetchable bit. This makes
prefetchable and non-prefetchable BARs to follow each other that's
quite likely with PCI passthrough devices. In that case, the existing
code, that tries to work out apertu
In case BAR64 is placed below 4G choose the correct aperture.
This fixes a failed assertion down the code path.
Acked-by: Anthony PERARD
Signed-off-by: Igor Druzhinin
---
OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/OvmfP
On Xen, hvmloader firmware leaves address decoding enabled for
enumerated PCI device before jumping into OVMF. OVMF seems to
expect it to be disabled and tries to size PCI BARs in several places
without disabling it which causes BAR64, for example, being
incorrectly placed by QEMU.
Fix it by disab
Igor Druzhinin (3):
OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge
aperture
OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64
OvmfPkg/XenSupport: turn off address decoding before BAR sizing
OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 53 +
On 25/04/2019 20:57, Tamas K Lengyel wrote:
> On Thu, Apr 25, 2019 at 12:58 PM Andrew Cooper
> wrote:
>> On 25/04/2019 16:32, Tamas K Lengyel wrote:
>>> diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
>>> index 6faa563167..594de6148f 100644
>>> --- a/xen/include/asm-x86/mm.h
>>> +
On Thu, Apr 25, 2019 at 12:58 PM Andrew Cooper
wrote:
>
> On 25/04/2019 16:32, Tamas K Lengyel wrote:
> > diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
> > index 6faa563167..594de6148f 100644
> > --- a/xen/include/asm-x86/mm.h
> > +++ b/xen/include/asm-x86/mm.h
> > @@ -133,7 +13
On 25/04/2019 00:43, Mathieu Tarral wrote:
> On Wednesday 24 April 2019 14:00, Andrew Cooper
> wrote:
>
>> On 23/04/2019 22:59, Mathieu Tarral wrote:
>>
> The funny thing is that it's always at the same instruction that it
> fails, the 106th singlestep,
> at 0x806d32dc:
> [0x7c90
On 25/04/2019 05:51, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 16, 2019 at 12:22:39PM +, Pawel Wieczorkiewicz wrote:
>> When there is no changed function in the generated payload, do not
>> create an empty .livepatch.funcs section. Hypervisor code considers
>> such payloads as broken and rejec
On 25/04/2019 16:32, Tamas K Lengyel wrote:
> diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
> index 6faa563167..594de6148f 100644
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -133,7 +133,10 @@ struct page_info
> * of sharing share the version t
On Thu, Apr 11, 2019 at 09:19:56AM +0200, Christoph Hellwig wrote:
> Hi all,
I will slurp these up.. right after I test them for correctness.
>
> below are a couple of cleanups for swiotlb-xen.c. They were done in
> preparation of eventually using the dma-noncoherent.h cache flushing
> hooks, b
On 25/04/2019 16:50, Ian Jackson wrote:
> Many build systems (including Xen's, and autoconf) use uname to try to
> discern the system's architecture. When running i386 userland on an
> amd64 kernel, this gives the wrong answer. These build systems then
> go off and try to do a sort of cross compi
On 25/04/2019 17:50, Ian Jackson wrote:
> 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
flight 84136 examine real [real]
http://osstest.xensource.com/osstest/logs/84136/
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
On 17.04.19 20:58, Julien Grall wrote:
At the moment, create_xen_entries will only flush the TLBs if the full
range has successfully been updated. This may lead to leave unwanted
entries in the TLBs if we fail to update some entries.
Signed-off-by: Julien Grall
---
Reviewed-by: Andrii Aniso
On 17.04.19 20:58, Julien Grall wrote:
All the TLBs helpers invalidate all the TLB entries are using the same
pattern:
DSB SY
TLBI ...
DSB SY
ISB
This pattern is following pattern recommended by the Arm Arm to ensure
visibility of updates to translation tables (see K10-5610
On 17.04.19 20:58, Julien Grall wrote:
TLB helpers in the headers tlbflush.h are currently quite confusing to
use the name may lead to think they are dealing with hypervisors TLBs
while they actually deal with guest TLBs.
Rename them to make it clearer that we are dealing with guest TLBs.
Sig
Hello Julien,
On 17.04.19 20:58, Julien Grall wrote:
The function flush_xen_text_tlb_local() has been misused and will result
to invalidate the instruction cache more than necessary.
For instance, there are no need to invalidate the instruction cache if
we are setting SCTLR_EL2.WXN.
There are
On 17.04.19 20:58, Julien Grall wrote:
At the moment, TLB helpers are scattered in 2 headers: page.h (for
Xen TLB helpers) and tlbflush.h (for guest TLB helpers).
This patch is gathering all of them in tlbflush. This will help to
uniformize and update the logic of the helpers in follow-up patc
On 17.04.19 20:58, Julien Grall wrote:
Now that we dropped flush_xen_text_tlb_local(), we have only one set of
helpers acting on Xen TLBs. There naming are quite confusing because the
TLB instructions used will act on both Data and Instruction TLBs.
Take the opportunity to rework the documenta
On 17.04.19 20:58, Julien Grall wrote:
The logic to set SCTLR_EL2.WXN is the same for the boot CPU and
non-boot CPU. So introduce a function to set the bit and clear TBLs.
s/TBL/TLB/
This new function will help us to document and update the logic in a
single place.
Signed-off-by: Julien Gr
Xen assumes that RAM starts at addresses greater than 0x0 in a few
places. The PDX code is one of them but there are more.
For now, skip the first page in memory when the start addess is 0x0.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/bootfdt.c | 7 +++
1 file changed, 7 insertions(
flight 135161 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135161/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 133923
build-i386-pvops
Hi Andrew,
On 04/23/2019 06:37 PM, 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 ch
Lars Kurth writes ("[VOTE] tagging for operational messages sent to xen-devel@
(was Re: [Xen-devel] Xen 4.13 Development Update)"):
> Alright,
>
> there was a lengthy discussion on this topic on IRC - log attached. The
> consensus appears to be to use Canonical messages with a CAPITALISED tag.
flight 135297 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135297/
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
* Use XFREE() instead of opencoding it in nvmx_cpu_dead()
* Avoid redundant evaluations of per_cpu()
* Don't allocate vvmcs_buf at all if it isn't going to be used. It is never
touched on hardware lacking the VMCS Shadowing feature.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei
On 25/04/2019 16:49, Jan Beulich wrote:
On 25.04.19 at 16:50, wrote:
>> On 25/04/2019 14:30, Jan Beulich wrote:
>> On 23.04.19 at 13:37, wrote:
void memory_type_changed(struct domain *d)
{
-if ( has_iommu_pt(d) && d->vcpu && d->vcpu[0] )
+if ( (has_iommu_pt(
>>> On 25.04.19 at 17:32, wrote:
> On 25/04/2019 16:15, Jan Beulich wrote:
> On 25.04.19 at 16:57, wrote:
>>> On 15/04/2019 06:25, Juergen Gross wrote:
This email only tracks big items for xen.git tree. Please reply for items
you
would like to see in 4.13 so that people have a
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
-r would fail with a bash syntax error. This bug has existed ever
since this feature was introduced.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index 37ccb59d..6ed4d85e 100755
--- a/mg-repro-s
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
Many build systems (including Xen's, and autoconf) use uname to try to
discern the system's architecture. When running i386 userland on an
amd64 kernel, this gives the wrong answer. These build systems then
go off and try to do a sort of cross compile thing, and, generally,
fall over.
The uname
Nothing sets this yet.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 38 ++
1 file changed, 38 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 600f18b1..addaaad2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1334,6 +13
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
My previous attempt failed because many build systems look at uname
and end up confused about the architecture. In this v2 of the series,
I take countermeasures.
Ian Jackson (6):
ts-syslog-server: --no-stdin option
sg-run-job, ts-host-install: New --build option
mg-repro-setup: Fix runvar a
>>> On 25.04.19 at 16:50, wrote:
> On 25/04/2019 14:30, Jan Beulich wrote:
> On 23.04.19 at 13:37, wrote:
>>> void memory_type_changed(struct domain *d)
>>> {
>>> -if ( has_iommu_pt(d) && d->vcpu && d->vcpu[0] )
>>> +if ( (has_iommu_pt(d) || cache_flush_permitted(d)) && d->vcpu &&
Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing" introduced
grabbing extra references for pages that drop references tied to PGC_allocated.
However, these pages are actually owned by dom_cow, resulting both sharing and
unsharing breaking.
Signed-off-by: Tamas K Lengyel
Cc: Geo
Hi,
On 25/04/2019 16:15, Jan Beulich wrote:
On 25.04.19 at 16:57, wrote:
On 15/04/2019 06:25, Juergen Gross wrote:
This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.13 so that people have an idea what is going on and
prioritise accordingly.
The page_lock/unlock functions were designed to be working with PV pagetable
updates. It's recycled use in mem_sharing is somewhat odd and results in
unecessary complications. Replace it with a separate per-page lock.
Signed-off-by: Tamas K Lengyel
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew C
Improves performance for release builds.
Signed-off-by: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
xen/include/asm-x86/mem_sharing.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/asm-x86/mem_sharing.h
b/xen/include/asm-x86/mem_s
>>> On 25.04.19 at 16:57, wrote:
> On 15/04/2019 06:25, Juergen Gross wrote:
>> This email only tracks big items for xen.git tree. Please reply for items you
>> would like to see in 4.13 so that people have an idea what is going on and
>> prioritise accordingly.
>
> Those e-mails become easily un
(+ Committers)
Hi Juergen,
On 15/04/2019 06:25, Juergen Gross wrote:
This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.13 so that people have an idea what is going on and
prioritise accordingly.
Those e-mails become easily unnoticed on xen-de
flight 135294 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135294/
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 4/25/19 1:33 PM, Jan Beulich wrote:
>> With this system, all published commits should have already passed Gitlab CI
>> and osstest tests.
>
> While this is certainly desirable as a goal, is the problem of
> occasional build issues really this big, warranting introduction
> of further overhead?
On 25/04/2019 14:30, Jan Beulich wrote:
On 23.04.19 at 13:37, wrote:
>> 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 assign
flight 135160 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135160/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 133846
build-i386-pvops
On 4/25/19 6:02 AM, Roger Pau Monné wrote:
> On Wed, Apr 24, 2019 at 11:45:43AM -0400, Boris Ostrovsky wrote:
>> On 4/24/19 11:45 AM, Roger Pau Monné wrote:
>>> On Wed, Apr 24, 2019 at 11:36:41AM -0400, Boris Ostrovsky wrote:
On 4/23/19 9:04 AM, Roger Pau Monne wrote:
> This involves initi
>>> On 25.04.19 at 15:33, wrote:
> On Thu, Apr 25, 2019 at 5:14 AM Jan Beulich wrote:
>>
>> >>> On 15.04.19 at 19:51, wrote:
>> > Simply changing to get_page with dom_cow is not enough, I ran into
>> > issues where the system still deadlocks due to the ordering of
>> > put_page_and_type being ca
Hi all,
In commit
8a46b39f3aff ("xenbus: drop useless LIST_HEAD in xenbus_write_watch() and
xenbus_file_write()")
Fixes tag
Fixes: 1107ba885e469("xen: add xenfs to allow usermode <-> Xen interaction")
has these problem(s):
- missing space between the SHA1 and the subject
--
Cheers,
S
On 25/04/2019 14:37, Jan Beulich wrote:
On 25.04.19 at 15:25, wrote:
>> On 25/04/2019 14:21, Jan Beulich wrote:
>> On 19.04.19 at 10:50, wrote:
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -334,7 +334,8 @@ void subarch_percpu_traps_init(void)
flight 135288 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135288/
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 25.04.19 at 15:25, wrote:
> On 25/04/2019 14:21, Jan Beulich wrote:
> On 19.04.19 at 10:50, wrote:
>>> --- a/xen/arch/x86/x86_64/traps.c
>>> +++ b/xen/arch/x86/x86_64/traps.c
>>> @@ -334,7 +334,8 @@ void subarch_percpu_traps_init(void)
>>> (unsigned
On Thu, Apr 25, 2019 at 5:14 AM Jan Beulich wrote:
>
> >>> On 15.04.19 at 19:51, wrote:
> > Simply changing to get_page with dom_cow is not enough, I ran into
> > issues where the system still deadlocks due to the ordering of
> > put_page_and_type being called before mem_sharing_page_unlock. So t
>>> On 23.04.19 at 13:37, wrote:
> 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 Dru
On 25/04/2019 14:21, Jan Beulich wrote:
On 19.04.19 at 10:50, wrote:
>> When executing SYSEXIT or SYSENTRY in Zhaoxin CPU, CPU needs to
> SYSENTER
>
>> --- a/xen/arch/x86/x86_64/traps.c
>> +++ b/xen/arch/x86/x86_64/traps.c
>> @@ -334,7 +334,8 @@ void subarch_percpu_traps_init(void)
>>
>>> On 24.04.19 at 20:10, wrote:
> c/s f8303458 restricted speculative access for do_vcpu_op(), but neglected its
> compat counterpart, which is reachable by guests using the 32bit ABI.
>
> Make an identical adjustment.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
>>> On 19.04.19 at 10:50, wrote:
> When executing SYSEXIT or SYSENTRY in Zhaoxin CPU, CPU needs to
SYSENTER
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -334,7 +334,8 @@ void subarch_percpu_traps_init(void)
> (unsigned long)lsta
On 25/04/2019 14:10, Jan Beulich wrote:
On 23.04.19 at 18:00, wrote:
>> 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()
> indic
>>> On 23.04.19 at 18:00, wrote:
> 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-of
On 25/04/2019 13:58, Jan Beulich wrote:
On 25.04.19 at 14:53, wrote:
>> On 25/04/2019 13:17, Razvan Cojocaru wrote:
>>> On 4/25/19 1:04 PM, Jan Beulich wrote:
>>> On 15.04.19 at 16:10, wrote:
> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>> You are correct -- cherry picking that comm
On 4/25/19 1:53 PM, Julien Grall wrote:
> Hi Jan,
>
> On 25/04/2019 13:37, Jan Beulich wrote:
> On 18.04.19 at 16:02, wrote:
>>> Andrew Cooper writes ("Re: Xen project CI systems and committer
>>> workflow"):
While everything presented here is fine to do as a matter of policy,
the
>
>>> On 25.04.19 at 14:53, wrote:
> On 25/04/2019 13:17, Razvan Cojocaru wrote:
>> On 4/25/19 1:04 PM, Jan Beulich wrote:
>> On 15.04.19 at 16:10, wrote:
On 4/15/19 5:04 PM, Matt Leinhos wrote:
> You are correct -- cherry picking that commit into RELEASE-4.11.1
> addresses the cr
>>> On 24.04.19 at 16:46, wrote:
> On Wed, Apr 24, 2019 at 02:27:32PM +, Alexandru Stefan ISAILA wrote:
>> @@ -1053,15 +1053,11 @@ static void change_type_range(struct p2m_domain *p2m,
>> * This should be revisited later, but for now post a warning.
>> */
>> if ( unlikely(end
On 25/04/2019 13:17, Razvan Cojocaru wrote:
> On 4/25/19 1:04 PM, Jan Beulich wrote:
> On 15.04.19 at 16:10, wrote:
>>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
You are correct -- cherry picking that commit into RELEASE-4.11.1
addresses the crash. The problem cannot be reproduced on
Hi Jan,
On 25/04/2019 13:37, Jan Beulich wrote:
On 18.04.19 at 16:02, wrote:
Andrew Cooper writes ("Re: Xen project CI systems and committer workflow"):
While everything presented here is fine to do as a matter of policy, the
committers still need to retain the ability to actually push direct
>>> On 23.04.19 at 17:49, wrote:
> 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 t
>>> On 18.04.19 at 16:02, wrote:
> Andrew Cooper writes ("Re: Xen project CI systems and committer workflow"):
>> While everything presented here is fine to do as a matter of policy, the
>> committers still need to retain the ability to actually push directly to
>> the staging branches on xen.git
>>> On 18.04.19 at 14:31, wrote:
> ## New world
>
> There will be an unified endpoint for committers and bots. Committers and bots
> will have their git trees. Patches are committed to those trees. An automated
> system will get patches from those trees and trigger CI runs.
>
> The system will p
On 4/25/19 1:04 PM, Jan Beulich wrote:
On 15.04.19 at 16:10, wrote:
>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>>> You are correct -- cherry picking that commit into RELEASE-4.11.1
>>> addresses the crash. The problem cannot be reproduced on 4.12.
>>>
>>> I hope this helps.
>>
>> Thank you f
>>> On 22.04.19 at 18:49, wrote:
> The pattern _AC(1, UL{,L}) << X is commonly used in the headers to make
> define usuable in both assembly and C.
>
> So introduce _BITUL and _BITULL to make the code slightly more readable.
I don't particularly like the names, and I specifically object to
the l
>>> On 15.04.19 at 10:48, wrote:
> Although xen-stable-4.12 is released now for some time (thanks for the
> timely release !),
> the release tag "RELEASE-4.12.0" is still only available in the
> "staging-4.12" branch of the Xen git tree.
> The "stable-4.12" is still a few (release-) commits sh
On 4/25/19 12:40 PM, Jan Beulich wrote:
On 18.04.19 at 15:11, wrote:
>> On 4/18/19 2:52 AM, Daniel P. Smith wrote:
>>> This deals with two casting issues for compiling under go 1.11:
>>> - explicitly cast to *C.xentoollog_logger for Ctx.logger pointer
>>> - add cast to unsafe.Pointer for the
>>> On 18.04.19 at 15:11, wrote:
> On 4/18/19 2:52 AM, Daniel P. Smith wrote:
>> This deals with two casting issues for compiling under go 1.11:
>> - explicitly cast to *C.xentoollog_logger for Ctx.logger pointer
>> - add cast to unsafe.Pointer for the C string cpath
>>
>> Signed-off-by: Daniel P
>>> On 17.04.19 at 16:51, wrote:
> On Wed, Apr 17, 2019 at 02:44:21PM +0200, Juergen Gross wrote:
>> Let Config.mk have:
>>
>> -include config/basic_tools.mk
>>
>> at the very beginning, with config/basic_tools.mk being created via
>> configure and containing the basic tool variables:
>>
>> CC
>>> On 17.04.19 at 19:07, wrote:
> Anyway, it is not the first time I see build error when trying to make the
> code using
> typesafe gfn/mfn. The headers dependency are quite messy in general.
Because of this, ...
> Andrew, Jan do you have a suggestion how to process on the x86 side?
... I do
>>> On 15.04.19 at 19:51, wrote:
> Simply changing to get_page with dom_cow is not enough, I ran into
> issues where the system still deadlocks due to the ordering of
> put_page_and_type being called before mem_sharing_page_unlock. So the
> ordering still has to be changed.
Dead locks because of
>>> On 15.04.19 at 19:28, wrote:
>> On Apr 15, 2019, at 4:31 PM, Tamas K Lengyel wrote:
>> On Mon, Apr 15, 2019 at 9:21 AM George Dunlap
>> wrote:
>>> On 4/12/19 8:47 PM, Tamas K Lengyel wrote:
Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing"
introduced
grabb
flight 135293 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135293/
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 17.04.19 at 23:12, wrote:
> On Wed, 27 Feb 2019, Jan Beulich wrote:
>> >>> On 27.02.19 at 00:07, wrote:
>> > --- a/xen/include/public/domctl.h
>> > +++ b/xen/include/public/domctl.h
>> > @@ -571,12 +571,14 @@ struct xen_domctl_bind_pt_irq {
>> > */
>> > #define DPCI_ADD_MAPPING 1
>>> On 14.04.19 at 18:33, wrote:
> Hi,
>
> On 4/9/19 1:21 PM, Jan Beulich wrote:
> On 09.04.19 at 11:50, wrote:
>>> On 08/04/2019 15:29, Jan Beulich wrote:
>>> On 08.04.19 at 13:47, wrote:
> de-allocation step aside, I am not really convinced you can reuse
> guest_remove_page()
flight 84132 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/84132/
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
>>> On 24.04.19 at 13:51, wrote:
> On 11/04/2019 13:45, Jan Beulich wrote:
>> --- a/xen/common/core_parking.c
>> +++ b/xen/common/core_parking.c
>
>
> [...]
>
>> +bool core_parking_remove(unsigned int cpu)
>
> Something looks wrong. This function is implemented in common code but...
>
>> +{
>
>>> On 16.04.19 at 18:23, wrote:
> On 3/27/2019 7:21 AM, Jan Beulich wrote:
> On 27.03.19 at 14:25, wrote:
>>> On 3/27/2019 1:14 AM, Jan Beulich wrote:
>>> On 26.03.19 at 18:21, wrote:
> zeta /usr/local/src/xen # cat xen/.config |grep CONFIG_HVM
> # CONFIG_HVM is not set
> z
>>> On 16.04.19 at 11:54, wrote:
> On 4/9/19 12:42 PM, Jan Beulich wrote:
> On 09.04.19 at 13:26, wrote:
>>> On 03/04/2019 14:04, Jan Beulich wrote:
Also please note the quotation used by the mentioned
existing doc comments, as well as a few other formal aspects
(like them also
1 - 100 of 113 matches
Mail list logo
