On 7/10/20 4:22 PM, Juergen Gross wrote:
> efifb_probe() will issue an error message in case the kernel is booted
> as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
> that message by calling efi_mem_desc_lookup() only if EFI_MEMMAP is set.
>
> Fixes: 38ac0287b7f4 ("fbdev/efif
flight 151870 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151870/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
build-i386-pvops
gcc re-orders top level blocks by default when optimizing. This
re-ordering results in all our .type directives to get emitted to the
assembly file first, followed by gcc's. The assembler warns about
attempts to change the type of a symbol when it was already set (and
when there's no intervening se
On Wed, Jul 01, 2020 at 12:25:48PM +0200, Jan Beulich wrote:
> 84e364f2eda2 ("x86: add CMCI software injection interface") merely made
> sure things would build, without any concern about things actually
> working:
> - despite the addition of xenctl_bitmap to xlat.lst, the resulting macro
> wasn'
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Rewrite those functions to use the new APIs. Modify its callers to unmap
> the pointer returned. Since alloc_xen_pagetable_new() is almost never
> useful unless accompanied by page clearing and a mapping, introduce a
> helper alloc_map_c
flight 151891 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151891/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, Jul 01, 2020 at 12:26:54PM +0200, Jan Beulich wrote:
> Use a typedef in struct xen_mc also for the two subops "manually"
> translated in the handler, just for consistency. No functional
> change.
I'm slightly puzzled by the fact that mc_fetch is marked as needs
checking while mc_physcpuinf
On Wed, Jul 01, 2020 at 12:27:16PM +0200, Jan Beulich wrote:
> This was forgotten when the subop was added.
>
> Also take the opportunity and move the dm_op_relocate_memory entry in
> xlat.lst to its designated place.
>
> No change in the resulting generated code.
>
> Fixes: ca2b511d3ff4 ("x86/i
On 14.07.2020 12:24, Roger Pau Monné wrote:
> On Wed, Jul 01, 2020 at 12:25:48PM +0200, Jan Beulich wrote:
>> --- a/xen/tools/compat-build-header.py
>> +++ b/xen/tools/compat-build-header.py
>> @@ -19,6 +19,7 @@ pats = [
>> [ r"(^|[^\w])xen_?(\w*)_compat_t([^\w]|$$)", r"\1compat_\2_t\3" ],
>> [
On 14.07.2020 13:19, Roger Pau Monné wrote:
> On Wed, Jul 01, 2020 at 12:26:54PM +0200, Jan Beulich wrote:
>> Use a typedef in struct xen_mc also for the two subops "manually"
>> translated in the handler, just for consistency. No functional
>> change.
>
> I'm slightly puzzled by the fact that mc_
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Page tables allocated in that function should be mapped and unmapped
> now.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Page tables allocated in that function should be mapped and unmapped
> now.
>
> Note that pl2e now maybe mapped and unmapped in different iterations, so
> we need to add clean-ups for that.
>
> Signed-off-by: Wei Liu
> Signed-off-by:
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> We will soon map and unmap pages in paging_init(). Introduce pl2e so
> that we can use l2_ro_mpt to point to the page table itself.
>
> No functional change.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Map and unmap pages instead of relying on the direct map.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
albeit preferably with ...
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
flight 151874 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151874/
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.
151065
test-amd64-amd
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Avoid repetitive mapping of l2_ro_mpt by keeping it across loops, and
> only unmap and map it when crossing 1G boundaries.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
I do think, however, that .
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Avoid repetitive mapping of l2_ro_mpt by keeping it across loops, and
> only unmap and map it when crossing 1G boundaries.
Oh, one other thing: This reads as if there were such repetitive
mapping operations, and the patch took care of t
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> After inspection ARM doesn't have alloc_xen_pagetable so this function
> is x86 only, which means it is safe for us to change.
Well, it sits inside a "#ifndef CONFIG_ARM" section.
> @@ -1442,29 +1443,42 @@ static __init void copy_mappi
- 7 lip 2020 o 21:39, Michał Leszczyński michal.leszczyn...@cert.pl
napisał(a):
> Intel Processor Trace is an architectural extension available in modern Intel
> family CPUs. It allows recording the detailed trace of activity while the
> processor executes the code. One might use the recorded
On Wed, Jul 01, 2020 at 12:27:37PM +0200, Jan Beulich wrote:
> The original intention was to ignore padding fields, but the pattern
> matched only ones whose names started with an underscore. Also match
> fields whose names are in line with the C spec by not having a leading
> underscore. (Note tha
On Wed, Jul 01, 2020 at 12:25:48PM +0200, Jan Beulich wrote:
> 84e364f2eda2 ("x86: add CMCI software injection interface") merely made
> sure things would build, without any concern about things actually
> working:
> - despite the addition of xenctl_bitmap to xlat.lst, the resulting macro
> wasn'
On Tue, Jul 14, 2020 at 01:47:11PM +0200, Jan Beulich wrote:
> On 14.07.2020 13:19, Roger Pau Monné wrote:
> > On Wed, Jul 01, 2020 at 12:26:54PM +0200, Jan Beulich wrote:
> >> Use a typedef in struct xen_mc also for the two subops "manually"
> >> translated in the handler, just for consistency. No
On Wed, Jul 01, 2020 at 12:26:54PM +0200, Jan Beulich wrote:
> Use a typedef in struct xen_mc also for the two subops "manually"
> translated in the handler, just for consistency. No functional
> change.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks.
On Wed, Jul 01, 2020 at 12:28:07PM +0200, Jan Beulich wrote:
> Translation macros aren't needed at all (or else a devicetree_label
> entry would have been missing), and userlist has been removed quite some
> time ago.
>
> No functional change.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/includ
On Wed, Jul 01, 2020 at 12:28:27PM +0200, Jan Beulich wrote:
> As was already the case for XSM/Flask, avoid generating compat headers
> when they're not going to be needed. To address resulting build issues
> - move compat/hvm/dm_op.h inclusion to the only source file needing it,
> - add a little b
On Tue, Jul 14, 2020 at 03:11:55PM +0200, Michał Leszczyński wrote:
> Kind reminder about this new patch version for external IPT monitoring.
It's on my queue, but with XenSummit I haven't been able to take a
look, will try to do between today and tomorrow.
Roger.
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 151892 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151892/
Failures :-/
flight 151883 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151883/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 151881 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151881/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9c6f3545aee0808b78a0ad4480b6eb9d24989dc1
baseline version:
ovmf d9a4084544134eea50f62
Hello Bertrand,
I succeeded in building the core minimal image with dunfell and its compatible
branches [except xen-troops (modified some files to complete the build)].
But I face the following error while booting.
(XEN)
(XEN) Panic on CPU 0:
(XEN) Timer
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-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 git://xen
Hello
[Sorry for the possible format issues]
On Tue, Jul 14, 2020 at 4:44 PM Manikandan Chockalingam (RBEI/ECF3) <
manikandan.chockalin...@in.bosch.com> wrote:
> Hello Bertrand,
>
> I succeeded in building the core minimal image with dunfell and its
> compatible branches [except xen-troops (modi
flight 151884 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151884/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151854
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 151898 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151898/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 256c4470f86e53661c070f8c64a1052e975f9ef0
baseline version:
ovmf 9c6f3545aee0808b78a0a
flight 151889 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151889/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
build-i386-pvops
On 14.07.2020 16:31, Roger Pau Monné wrote:
> On Tue, Jul 14, 2020 at 01:47:11PM +0200, Jan Beulich wrote:
>> On 14.07.2020 13:19, Roger Pau Monné wrote:
>>> On Wed, Jul 01, 2020 at 12:26:54PM +0200, Jan Beulich wrote:
Use a typedef in struct xen_mc also for the two subops "manually"
tran
On 14.07.2020 16:29, Roger Pau Monné wrote:
> On Wed, Jul 01, 2020 at 12:27:37PM +0200, Jan Beulich wrote:
>> The original intention was to ignore padding fields, but the pattern
>> matched only ones whose names started with an underscore. Also match
>> fields whose names are in line with the C spe
On 14.07.2020 16:58, Roger Pau Monné wrote:
> On Wed, Jul 01, 2020 at 12:28:07PM +0200, Jan Beulich wrote:
>> Translation macros aren't needed at all (or else a devicetree_label
>> entry would have been missing), and userlist has been removed quite some
>> time ago.
>>
>> No functional change.
>>
>
On 14.07.2020 17:03, Roger Pau Monné wrote:
> On Wed, Jul 01, 2020 at 12:28:27PM +0200, Jan Beulich wrote:
>> As was already the case for XSM/Flask, avoid generating compat headers
>> when they're not going to be needed. To address resulting build issues
>> - move compat/hvm/dm_op.h inclusion to th
39 matches
Mail list logo
