flight 135419 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135419/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 133734
Roger Pau Monne writes ("Re: [Xen-devel] linux 4.19 xenstore memory allocation
failure Re: [linux-4.19 test] 135420: regressions - FAIL"):
> On Tue, Apr 30, 2019 at 03:33:00PM +0100, Ian Jackson wrote:
> > I will leave answering this to the blkfront/linux folks...
>
> I think those allocations
Hi,
On 30/04/2019 22:02, Stefano Stabellini wrote:
Change the signature of process_memory_node to match
device_tree_node_func.
NAck in the current form. If a function return a value, then it should be
checked appropriately and not ignored.
But then, the commit message leads to think you
We now have 4 working arm64 boxes and this is quite ample for our
current test matrix. We have two kinds of box, too. So, great.
This reverts commit 0705bed9e20ea4375e7ac9f8109ef955ebc6fe9c.
CC: Julien Grall
CC: Stefano Stabellini
Signed-off-by: Ian Jackson
---
allow.all | 2 --
1 file
From: David Woodhouse
Where booted from EFI or with no-real-mode, there is no need to stomp
on low memory with the 16-boot code. Instead, just go straight to
trampoline_protmode_entry() at its physical location within the Xen
image.
For now, the boot code (including the EFI loader path) still
From: David Woodhouse
In preparation for splitting the boot and permanent trampolines from
each other. Some of these will change back, but most are boot so do the
plain search/replace that way first, then a subsequent patch will extract
the permanent trampoline code.
Signed-off-by: David
From: David Woodhouse
If the no-real-mode flag is set, don't go there at all. This is a prelude
to not even putting it there in the first place.
Signed-off-by: David Woodhouse
---
xen/arch/x86/boot/head.S | 10 ++
xen/arch/x86/boot/trampoline.S | 4
2 files changed, 10
From: David Woodhouse
The wakeup code is now relocated alongside the trampoline code, so %ds
is just fine here.
Signed-off-by: David Woodhouse
---
xen/arch/x86/boot/wakeup.S | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/boot/wakeup.S
From: David Woodhouse
Ditch the bootsym() access from C code for the variables populated by
16-bit boot code. As well as being cleaner this also paves the way for
not having the 16-bit boot code in low memory for no-real-mode or EFI
loader boots at all.
Signed-off-by: David Woodhouse
---
From: David Woodhouse
We appear to have implemented a memcpy() in the low-memory trampoline
which we then call into from __start_xen(), for no adequately defined
reason.
Kill it with fire.
Signed-off-by: David Woodhouse
---
xen/arch/x86/boot/mem.S| 27 +--
From: David Woodhouse
As a first step toward using the low-memory trampoline only when necessary
for a legacy boot without no-real-mode, clean up the relocations into
three separate groups.
• bootsym() is now used only at boot time when no-real-mode isn't set.
• bootdatasym() is for
Some cleanups for the boot path, originally inspired by an attempt to
avoid scribbling on arbitrarily-chosen low memory.
In the no-real-mode case we don't need to bounce through low memory at
all; we can run the 32-bit trampoline in-place in the Xen image.
The variables containing information
On 01/05/2019 05:22, Tamas K Lengyel wrote:
> Currently the gs_shadow value is only cached when the vCPU is being scheduled
> out by Xen. Reporting this (usually) stale value through vm_event is
> incorrect,
> since it doesn't represent the actual state of the vCPU at the time the event
> was
Hi,
On 30/04/2019 22:02, Stefano Stabellini wrote:
Add a new memory policy option for the iomem parameter.
Possible values are:
- arm_devmem, device nGRE, the default on ARM
- arm_memory, WB cachable memory
- x86_uc: uncachable memory, the default on x86
Store the parameter in a new field in
Hi Stefano,
On 30/04/2019 22:02, Stefano Stabellini wrote:
As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)
Reuse process_memory_node to add reserved-memory regions to the
flight 135457 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135457/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 133615
version
flight 135433 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135433/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 127792
Ian Jackson writes ("[PATCH STABLE] tools/firmware: update OVMF Makefile, when
necessary"):
> Ian Jackson writes ("[PATCH STABLE] tools/firmware: update OVMF Makefile,
> when necessary"):
> > On advice from Wei, I am about to push this squashed backport to the
> > stable trees. We think this
osstest service owner writes ("[linux-linus test] 135426: regressions - FAIL"):
> flight 135426 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/135426/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
No functional change with existing flights. But the effect is that
now, generally, ts-* scripts and the support code will honour
host_arch, if it is set, in preference to arch.
This patch contains only replacements of $r{arch} with $ho->{Arch} or
$gho->{Arch}. In fact, perhaps surprisingly,
With existing flights these are $r{arch} and GUEST_arch.
Nothing uses these yet.
Signed-off-by: Ian Jackson
---
v2: Correctly set $gho->{Arch} in selectguest, not $ho->{Arch}
---
Osstest/TestSupport.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Osstest/TestSupport.pm
Signed-off-by: Ian Jackson
Acked-by: Julien Grall
CC: Stefano Stabellini
---
v2: Drop HOSTCC= setting
---
ts-kernel-build | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/ts-kernel-build b/ts-kernel-build
index 72ca98a1..71eda48d 100755
---
Right now this is a simple wrapper around target_cmd_build.
No functional change.
Signed-off-by: Ian Jackson
---
ts-kernel-build | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/ts-kernel-build b/ts-kernel-build
index 3dad7d36..72ca98a1 100755
---
Introduce job_create_build_crossable, which takes a target->host
architecture map in its arguments, and use it for build-kern,
passing an empty architecture map.
Overall functional change is only to add
host_arch=$arch
to the kernel build jobs, which has no ultimate effect because it's
the same
No functional change.
Verified with standalone-generate-dump-flight-runvars.
Signed-off-by: Ian Jackson
---
mfi-common | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/mfi-common b/mfi-common
index f91156fe..dad03e39 100644
--- a/mfi-common
+++ b/mfi-common
@@ -216,6
This is just tidying up. The only effect is that now these would
honour $r{all_guest_arch} as a fallback. But right now,
$r{GUEST_arch} will always be set, and that is what ends up in
$gho->{Arch}.
Signed-off-by: Ian Jackson
---
ts-debian-di-install | 2 +-
ts-debian-install| 2 +-
2
Cross building this will be much much faster and help with our severe
armhf resource shortage. To achieve this it is necessary to clean up
some technical debt, so that we can separately control host
architecture, rather than just using the job's main $r{arch}.
This is v2 of the series, with some
Our armhf hosts are devboards and very slow, as well as scarce. It
takes 17ks or so for a kernel build. This will go *much* faster on
an amd64 box and we have lots of those too.
standalone-generate-dump-flight-runvars shows that the only change is
to change host_arch from armhf to amd64 in
Having it in the middle makes it quite hard to find !
No functional change.
Signed-off-by: Ian Jackson
---
ts-kernel-build | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/ts-kernel-build b/ts-kernel-build
index 71eda48d..f7d059b0 100755
---
Change `target_var' to set `IDENT_V' rather than just V. For
compatibility with older flights and older flight construction,
look for plain V too when looking up the variable.
And, we now look at all_host_V before V. This has no functional
change with existing flights, because existing flights
No functional change.
Signed-off-by: Ian Jackson
---
ts-memdisk-try-append | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-memdisk-try-append b/ts-memdisk-try-append
index 67c250bd..f6ec2fd5 100755
--- a/ts-memdisk-try-append
+++ b/ts-memdisk-try-append
@@ -23,7 +23,7 @@
No functional change.
Signed-off-by: Ian Jackson
---
ts-debian-di-install | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ts-debian-di-install b/ts-debian-di-install
index 361a1710..5cb3d35d 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -152,10 +152,10
This comment was lamenting the very problem we are fixing now. It
would now be possible to test i386->amd64 tools migration, by writing
an appropriate test job with different src_host_arch and
dst_host_arch etc.
Signed-off-by: Ian Jackson
---
make-flight | 4 ++--
1 file changed, 2
Make an explicit list of the prefixes and a loop to walk over them.
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index
On 5/1/19 11:46 AM, Ian Jackson wrote:
> These releases are out of security support. They are known not to
> build on Debian stretch, which is what we are using, and we do not
> intend to ever update them to fix that.
>
> Xen 4.6 is also out of security support but we want osstest to be able
>
On 5/1/19 7:22 AM, Tamas K Lengyel wrote:
> Currently the gs_shadow value is only cached when the vCPU is being scheduled
> out by Xen. Reporting this (usually) stale value through vm_event is
> incorrect,
> since it doesn't represent the actual state of the vCPU at the time the event
> was
Hi,
On 30/04/2019 22:02, Stefano Stabellini wrote:
Now that map_mmio_regions takes a p2mt parameter, there is no need to
keep "mmio" in the name. The p2mt parameter does a better job at
expressing what the mapping is about. Let's save the environment 5
characters at a time.
At least on Arm,
osstest service owner writes ("[xen-4.9-testing test] 135421: regressions -
FAIL"):
> flight 135421 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/135421/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be
flight 135421 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135421/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 132889
These releases are out of security support. They are known not to
build on Debian stretch, which is what we are using, and we do not
intend to ever update them to fix that.
Xen 4.6 is also out of security support but we want osstest to be able
to continue to build it so that we can test 4.6->4.7
We are going to want to do this after selecthost.
No functional change.
Signed-off-by: Ian Jackson
---
ts-host-install | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/ts-host-install b/ts-host-install
index 45f04764..3c14f171 100755
---
flight 135431 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135431/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 21 leak-check/check fail REGR. vs. 135318
version targeted for
osstest service owner writes ("[freebsd-master test] 135317: regressions -
FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-xen-freebsd 5 host-install(5) fail REGR. vs.
> 135233
I guess this must be a host-specific
On 01/05/2019 08:17, Razvan Cojocaru wrote:
> On 5/1/19 7:22 AM, Tamas K Lengyel wrote:
>> Currently the gs_shadow value is only cached when the vCPU is being scheduled
>> out by Xen. Reporting this (usually) stale value through vm_event is
>> incorrect,
>> since it doesn't represent the actual
Hi. A couple of weeks ago I wrote a writeup about this kind of
problem:
test-arm64-arm64-examine 11 examine-serial/bootloader fail REGR. vs. 119195
This is going to affect all of osstest's branches and it will be
tiresome to force push it. Particularly, I think it may cause the
examine jobs
flight 135460 xen-4.6-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135460/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu queued
On 5/1/19 4:58 PM, Tamas K Lengyel wrote:
>>> It might be worth introducing a "sync state from hw" hook which collects
>>> all the data we intend to pass to the introspection agent.
>>
>> You mean adding another hvm hook?
>
> Actually, instead of another hook I think what would make sense it to
>
On 4/8/19 12:09 PM, George Dunlap wrote:
> mem-set is the primary command that users will need to use and
> understand. Move it first, and clarify the wording; also specify that
> you can't set the target higher than maxmem from the domain config.
>
> mem-max is actually a pretty useless command
On Wed, May 1, 2019 at 1:50 AM Andrew Cooper wrote:
>
> On 01/05/2019 05:22, Tamas K Lengyel wrote:
> > Currently the gs_shadow value is only cached when the vCPU is being
> > scheduled
> > out by Xen. Reporting this (usually) stale value through vm_event is
> > incorrect,
> > since it doesn't
flight 135424 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135424/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133923
On Wed, May 1, 2019 at 8:53 AM Tamas K Lengyel wrote:
>
> On Wed, May 1, 2019 at 8:20 AM Razvan Cojocaru
> wrote:
> >
> > On 5/1/19 4:58 PM, Tamas K Lengyel wrote:
> > >>> It might be worth introducing a "sync state from hw" hook which collects
> > >>> all the data we intend to pass to the
On 5/1/19 6:01 PM, Tamas K Lengyel wrote:
> On Wed, May 1, 2019 at 8:53 AM Tamas K Lengyel wrote:
>>
>> On Wed, May 1, 2019 at 8:20 AM Razvan Cojocaru
>> wrote:
>>>
>>> On 5/1/19 4:58 PM, Tamas K Lengyel wrote:
>> It might be worth introducing a "sync state from hw" hook which collects
Ping?
On 4/5/19 6:13 PM, George Dunlap wrote:
> With this script, once the main checks are out of the way, doing a
> release (either an RC or the final release) should mostly be a matter
> of executing a sequence of 4 commands given by the `help` function in
> this script.
>
> Signed-off-by:
flight 135429 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135429/
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. 134015
Hi all,
I almost dropped this: apologies. With the votes in, we have a clear winner for
[ANNOUNCE] over the other options
ANNOUNCE1 2 2
OPERATIONS -1 -1 1
PROCESS 0 0 -2
Lars
On 26/04/2019, 03:50, "Jan Beulich" wrote:
>>> On 25.04.19 at
On 01/05/2019 12:17, David Woodhouse wrote:
> From: David Woodhouse
>
> We appear to have implemented a memcpy() in the low-memory trampoline
> which we then call into from __start_xen(), for no adequately defined
> reason.
>
> Kill it with fire.
Absolutely.
> Signed-off-by: David Woodhouse
> > It might be worth introducing a "sync state from hw" hook which collects
> > all the data we intend to pass to the introspection agent.
>
> You mean adding another hvm hook?
Actually, instead of another hook I think what would make sense it to
just update vmx_save_vmcs_ctxt to automatically
On Wed, May 1, 2019 at 8:20 AM Razvan Cojocaru
wrote:
>
> On 5/1/19 4:58 PM, Tamas K Lengyel wrote:
> >>> It might be worth introducing a "sync state from hw" hook which collects
> >>> all the data we intend to pass to the introspection agent.
> >>
> >> You mean adding another hvm hook?
> >
> >
On Wed, May 1, 2019 at 7:45 AM Tamas K Lengyel wrote:
>
> On Wed, May 1, 2019 at 1:50 AM Andrew Cooper
> wrote:
> >
> > On 01/05/2019 05:22, Tamas K Lengyel wrote:
> > > Currently the gs_shadow value is only cached when the vCPU is being
> > > scheduled
> > > out by Xen. Reporting this
On 01/05/2019 13:02, Andrew Cooper wrote:
> On 01/05/2019 12:17, David Woodhouse wrote:
>> From: David Woodhouse
>>
>> The wakeup code is now relocated alongside the trampoline code, so %ds
>> is just fine here.
> AFACIT, this is as a consequence of c/s bc4a68f21f43c2 "x86: make
> run-time part
flight 135428 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 133468
flight 135427 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135427/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken in 135286
build-armhf
On Wed, May 1, 2019 at 9:44 AM Razvan Cojocaru
wrote:
>
> On 5/1/19 6:01 PM, Tamas K Lengyel wrote:
> > On Wed, May 1, 2019 at 8:53 AM Tamas K Lengyel wrote:
> >>
> >> On Wed, May 1, 2019 at 8:20 AM Razvan Cojocaru
> >> wrote:
> >>>
> >>> On 5/1/19 4:58 PM, Tamas K Lengyel wrote:
> >> It
Hi,
On 01/05/2019 11:15, Ian Jackson wrote:
We now have 4 working arm64 boxes and this is quite ample for our
current test matrix. We have two kinds of box, too. So, great.
This reverts commit 0705bed9e20ea4375e7ac9f8109ef955ebc6fe9c.
CC: Julien Grall
CC: Stefano Stabellini
Signed-off-by:
On 01/05/2019 12:17, David Woodhouse wrote:
> From: David Woodhouse
>
> The wakeup code is now relocated alongside the trampoline code, so %ds
> is just fine here.
AFACIT, this is as a consequence of c/s bc4a68f21f43c2 "x86: make
run-time part of trampoline relocatable" ?
> Signed-off-by: David
flight 135434 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135434/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
From: Cédric Bosdonnat
Gcc6 build reports misleading indentation as warnings. Fix a few
warnings in stubdom.
Signed-off-by: Cédric Bosdonnat
Acked-by: Daniel De Graaf
Acked-by: Quan Xu
Release-acked-by: Wei Liu
(cherry picked from commit 9fdffbbab3ada427bac07076f042f0265e5ae05f)
---
flight 135463 xen-4.7-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135463/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1queued
flight 135435 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 21 leak-check/check fail REGR. vs. 135082
On Wed, 1 May 2019, Ian Jackson wrote:
> We now have 4 working arm64 boxes and this is quite ample for our
> current test matrix. We have two kinds of box, too. So, great.
>
> This reverts commit 0705bed9e20ea4375e7ac9f8109ef955ebc6fe9c.
Awesome!
> CC: Julien Grall
> CC: Stefano Stabellini
From: David Woodhouse
The wakeup code is now relocated alongside the trampoline code, so %ds
is just fine here.
Signed-off-by: David Woodhouse
---
xen/arch/x86/boot/wakeup.S | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/boot/wakeup.S
From: David Woodhouse
In preparation for splitting the boot and permanent trampolines from
each other. Some of these will change back, but most are boot so do the
plain search/replace that way first, then a subsequent patch will extract
the permanent trampoline code.
Signed-off-by: David
From: David Woodhouse
Where booted from EFI or with no-real-mode, there is no need to stomp
on low memory with the 16-boot code. Instead, just go straight to
trampoline_protmode_entry() at its physical location within the Xen
image.
For now, the boot code (including the EFI loader path) still
From: David Woodhouse
We appear to have implemented a memcpy() in the low-memory trampoline
which we then call into from __start_xen(), for no adequately defined
reason.
Kill it with fire.
Signed-off-by: David Woodhouse
---
xen/arch/x86/boot/mem.S| 27 +--
flight 135436 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135436/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 134998
Tests which
On 01/05/2019 15:58, Tamas K Lengyel wrote:
> On Wed, May 1, 2019 at 7:45 AM Tamas K Lengyel wrote:
>> On Wed, May 1, 2019 at 1:50 AM Andrew Cooper
>> wrote:
>>> On 01/05/2019 05:22, Tamas K Lengyel wrote:
Currently the gs_shadow value is only cached when the vCPU is being
scheduled
On Wed, May 1, 2019 at 11:03 AM Andrew Cooper wrote:
>
> On 01/05/2019 15:58, Tamas K Lengyel wrote:
> > On Wed, May 1, 2019 at 7:45 AM Tamas K Lengyel wrote:
> >> On Wed, May 1, 2019 at 1:50 AM Andrew Cooper
> >> wrote:
> >>> On 01/05/2019 05:22, Tamas K Lengyel wrote:
> Currently the
osstest service owner writes ("[xen-4.10-testing test] 135435: regressions -
FAIL"):
> flight 135435 xen-4.10-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/135435/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be
flight 135430 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135430/
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 135425 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135425/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 134763
On Wed, 2019-05-01 at 17:09 +0100, Andrew Cooper wrote:
> I'm afraid testing says no. S3 works fine without this change, and
> resets with it.
Thanks for testing. That's obvious in retrospect — although the wakeup
code is relocated alongside the trampoline code, it runs in real mode
with its own
> On May 1, 2019, at 14:37, Lars Kurth wrote:
>
> Rich,
> as nobody replied to the mail, I am inclined to dismiss the proposal of ANN
> for now
> Lars
What do you think about the suggestion to apply a tag ("ANNOUNCE"?) for emails
that are mirrored to xen-devel from the -announce mailing list?
Rich,
as nobody replied to the mail, I am inclined to dismiss the proposal of ANN for
now
Lars
> On 25 Apr 2019, at 16:59, Rich Persaud wrote:
>
>> On Apr 25, 2019, at 12:36, Lars Kurth wrote:
>>
>> Alright,
>>
>> there was a lengthy discussion on this topic on IRC - log attached. The
>>
From: David Woodhouse
If the no-real-mode flag is set, don't go there at all. This is a prelude
to not even putting it there in the first place.
Signed-off-by: David Woodhouse
---
xen/arch/x86/boot/head.S | 10 ++
xen/arch/x86/boot/trampoline.S | 4
2 files changed, 10
From: David Woodhouse
As a first step toward using the low-memory trampoline only when necessary
for a legacy boot without no-real-mode, clean up the relocations into
three separate groups.
• bootsym() is now used only at boot time when no-real-mode isn't set.
• bootdatasym() is for
From: David Woodhouse
Ditch the bootsym() access from C code for the variables populated by
16-bit boot code. As well as being cleaner this also paves the way for
not having the 16-bit boot code in low memory for no-real-mode or EFI
loader boots at all.
Signed-off-by: David Woodhouse
---
Some cleanups for the boot path, originally inspired by an attempt to
avoid scribbling on arbitrarily-chosen low memory.
In the no-real-mode case we don't need to bounce through low memory at
all; we can run the 32-bit trampoline in-place in the Xen image.
The variables containing information
flight 135438 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135438/
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-armhf-pvops
Argh, that's the first version again. Sorry. The fixed version is in
http://git.infradead.org/users/dwmw2/xen.git/shortlog/refs/heads/bootcleanup
but I won't post the whole series again right now.
smime.p7s
Description: S/MIME cryptographic signature
flight 135437 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135437/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 135413
test-armhf-armhf-libvirt-raw 13
flight 135442 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135442/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 1c9db326a7108203d5cfd706aa2c0a8818e9cccf
baseline version:
xtf
On Mon, 29 Apr 2019, Stefano Stabellini wrote:
> On Mon, 29 Apr 2019, Jan Beulich wrote:
> > >>> On 29.04.19 at 17:54, wrote:
> > > Anyway, I also tested the change suggested by Stefano. This will
> > > substantially
> > > increase the size of the frametable on platform where the RAM does not
Improve Dom0-less documentation: include a complete configuration
example.
Signed-off-by: Stefano Stabellini
diff --git a/docs/features/dom0less.pandoc b/docs/features/dom0less.pandoc
index 4e342b7..e076e37 100644
--- a/docs/features/dom0less.pandoc
+++ b/docs/features/dom0less.pandoc
@@ -23,6
Currently the gs_shadow value is only cached when the vCPU is being scheduled
out by Xen. Reporting this (usually) stale value through vm_event is incorrect,
since it doesn't represent the actual state of the vCPU at the time the event
was recorded. This prevents vm_event subscribers from
branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-amd64-xsm
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and
branch xen-4.11-testing
xenbranch xen-4.11-testing
job build-amd64-xsm
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and
branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-amd64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and
Hi all,
I forgot to update my calendar to reflect for the new community call time and
thus forgot to ask for agenda items. Sincere apologies. So I propose we have
the meeting next week. Will send out agenda requests tomorrow
Lars
___
Xen-devel mailing
Receiving this register is useful for introspecting 32-bit Windows when the
event being trapped happened while in ring3.
Signed-off-by: Tamas K Lengyel
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
---
xen/arch/x86/vm_event.c
99 matches
Mail list logo
