flight 135285 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135285/
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/24/19 20:10, Andrew Cooper 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: Norbert Manthey
> ---
> C
flight 135141 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135141/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134015
test-amd64-amd64-xl-q
>>> On 23.04.19 at 12:54, wrote:
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -360,8 +360,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
> size, void *vaddr,
> /* Convert the size to actually allocated. */
> size = 1UL << (order + XEN_PAGE_SHIF
flight 135156 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135156/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134580
build-arm64-xsm
On 25/04/2019 10:53, Jan Beulich wrote:
On 23.04.19 at 12:54, wrote:
>> --- a/drivers/xen/swiotlb-xen.c
>> +++ b/drivers/xen/swiotlb-xen.c
>> @@ -360,8 +360,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
>> size, void *vaddr,
>> /* Convert the size to actually allocated. */
>>> On 23.04.19 at 20:36, wrote:
> 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
On 25/04/2019 10:53, Jan Beulich wrote:
On 23.04.19 at 12:54, wrote:
>> --- a/drivers/xen/swiotlb-xen.c
>> +++ b/drivers/xen/swiotlb-xen.c
>> @@ -360,8 +360,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t
>> size, void *vaddr,
>> /* Convert the size to actually allocated. */
On 25/04/2019 11:01, Jan Beulich wrote:
On 23.04.19 at 20:36, wrote:
>> 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 on
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 initializing the boot params EFI related fields and
>>> 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 for confirming the fix!
>
> To the deciders:
On Thu, Apr 18, 2019 at 04:09:21PM +0100, Julien Grall wrote:
> Hi,
>
> On 18/04/2019 12:46, Wei Liu wrote:
> > On Wed, Apr 17, 2019 at 06:42:47PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > @Wei, @Ian: Do you have any input?
> >
> > Sorry I haven't been following this closely, but shouldn'
>>> On 16.04.19 at 00:17, wrote:
> On Wed, 13 Mar 2019, Jan Beulich wrote:
>> > @@ -215,6 +216,9 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
>> > /* Use while-break to avoid compiler warning */
>> > while ( iommu_iotlb_flush_all(d, flush_flags) )
>> > bre
>>> 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
>>> 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 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...
>
>> +{
>
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 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()
>>> 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
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 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
>>> 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 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 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 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 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 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 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 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 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 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 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
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 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
>>> 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.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 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/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 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 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 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 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 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 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 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 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
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/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)
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.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
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
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 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
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?
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
(+ 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
>>> 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
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
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.
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
>>> 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 &&
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
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
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
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
-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
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
>>> 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
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(
* 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
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
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.
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
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
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(
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
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:
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
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:
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
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:
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
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 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
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 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: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 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 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 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 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
>>> +
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 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
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
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
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
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
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
1 - 100 of 113 matches
Mail list logo
