flight 159717 xen-unstable real [real]
flight 159724 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159717/
http://logs.test-lab.xenproject.org/osstest/logs/159724/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On Fri, Feb 26, 2021 at 09:31:02AM +0100, Jan Beulich wrote:
> On 26.02.2021 04:08, Connor Davis wrote:
> > On Thu, Feb 25, 2021 at 04:50:02PM +0100, Jan Beulich wrote:
> >> On 25.02.2021 16:24, Connor Davis wrote:
> >>> Return from cpu_schedule_up when either cpu is 0 or
> >>> NR_CPUS == 1. This f
On Thu, Feb 25, 2021 at 05:06:46PM -0800, Stefano Stabellini wrote:
> On Thu, 25 Feb 2021, Andrew Cooper wrote:
> > On 25/02/2021 15:24, Connor Davis wrote:
> > > Add the minimum code required to get xen to build with
> > > XEN_TARGET_ARCH=riscv64. It is minimal in the sense that every file and
> >
flight 159703 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Fri, 26 Feb 2021, Julien Grall wrote:
> From: Julien Grall
>
> A vCPU can get scheduled as soon as _VPF_down is cleared. As there is
> currently not ordering guarantee in arch_set_info_guest(), it may be
> possible that flag can be observed cleared before the new values of vCPU
> registers are
flight 159702 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159702/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-check fail blocked in 159590
test-amd64-amd64-xl-qemuu-win7-amd64 19
flight 159708 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159708/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 62f2cf57840e3b08122b6326b0ed9f4b25ce15d9
baseline version:
ovmf 6ffbb3581ab7c25a35041
Introduce two feature flags to tell the domain whether it is
direct-mapped or not. It allows the guest kernel to make informed
decisions on things such as swiotlb-xen enablement.
The introduction of both flags (XENFEAT_direct_mapped and
XENFEAT_not_direct_mapped) allows the guest kernel to avoid a
flight 159700 qemu-mainline real [real]
flight 159719 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159700/
http://logs.test-lab.xenproject.org/osstest/logs/159719/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Oops, I didn't finish this sentence before sending:
On Fri, Feb 26, 2021 at 10:39:27PM +, Andy Smith wrote:
> Also, it's always the md device that the guest block devices are
> on that is stalled - IO to other devices in dom0
…seems fine.
Thanks,
Andy
On Fri, 26 Feb 2021, Andrew Cooper wrote:
> Looks like a copy&paste error.
>
> Fixes: f6e1d8515d7 ("automation: add alpine linux x86 build jobs")
> Signed-off-by: Andrew Cooper
Thanks for the patch and of course it is correct
Acked-by: Stefano Stabellini
However unfortunately it breaks the A
Hi,
I suspect this might be an issue in the dom0 kernel (Debian buster,
kernel 4.19.0-13-amd64), but just lately I've been sporadically
having issues where dom0 blocks or severely slows down on all access
to the particular md device that hosts all domU block devices.
Setup in dom0: an md RAID10 t
On Fri, 26 Feb 2021, Jan Beulich wrote:
> On 25.02.2021 21:51, Stefano Stabellini wrote:
> > On Thu, 25 Feb 2021, Jan Beulich wrote:
> >> On 25.02.2021 02:22, Stefano Stabellini wrote:
> >>> --- a/xen/include/public/features.h
> >>> +++ b/xen/include/public/features.h
> >>> @@ -114,6 +114,13 @@
> >
From: Julien Grall
A vCPU can get scheduled as soon as _VPF_down is cleared. As there is
currently not ordering guarantee in arch_set_info_guest(), it may be
possible that flag can be observed cleared before the new values of vCPU
registers are observed.
Add an smp_mb() before the flag is cleare
On Fri, 26 Feb 2021, Roger Pau Monne wrote:
> The current build of the firmware relies on having 32bit compatible
> headers installed in order to build some of the 32bit firmware, but
> that usually requires multilib support and installing a i386 libc when
> building from an amd64 environment which
On Fri, 26 Feb 2021, Roger Pau Monne wrote:
> Hello,
>
> While the series started as a build fix for Alpine I think they are
> interesting on their own for other OSes/distros, since it allows to
> remove the i386 libc as a build dependency.
>
> THis is done by proving a suitable set of standalone
flight 159716 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159716/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
The pull request you sent on Fri, 26 Feb 2021 14:16:41 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.12b-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5c2e7a0af211cb7a3a24fcfe98f0ceb67560b53b
Thank you!
--
Deet-doot-dot,
From: Julien Grall
In case of failure in do_lu_start(), XenStored will first free lu_start
and then try to dereference it.
This will result to a NULL dereference as the destruction callback will
set lu_start to NULL.
The crash can be avoided by freeing lu_start *after* the reply has been
set.
On 26/02/2021 10:59, Hubert Jasudowicz wrote:
> Make sure xen-vmtrace exits cleanly in case SIGPIPE is sent. This can
> happen when piping the output to some other program.
>
> Additionaly, add volatile qualifier to interrupted flag to avoid
> it being optimized away by the compiler.
>
> Signed-off
flight 159692 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159692/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 159475
test-armhf-armhf-libvirt 16 save
Hi,
At 14:03 +0100 on 25 Feb (1614261809), Jan Beulich wrote:
> When none of the physical address bits in PTEs are reserved, we can't
> create any 4k (leaf) PTEs which would trigger reserved bit faults. Hence
> the present SHOPT_FAST_FAULT_PATH machinery needs to be suppressed in
> this case, whic
At 16:08 +0100 on 26 Feb (1614355713), Jan Beulich wrote:
> Prior to be640b1800bb ("x86: make get_page_from_l1e() return a proper
> error code") a positive return value did indicate an error. Said commit
> failed to adjust this return path, but luckily the only caller has
> always been inside a sha
On 26/02/2021 16:21, Bob Eshleman wrote:
>>> On 2/25/21 3:14 PM, Andrew Cooper wrote:
>>>
>>> It sounds like you'd prefer no common to start and none of the
>>> arch_* calls it relies on?
>> We definitely want "stuff compiled under RISC-V" to be caught in CI, but
>> that doesn't mean "wedge all of
On Fri, 2021-02-26 at 09:31 +0100, Jan Beulich wrote:
> On 26.02.2021 04:08, Connor Davis wrote:
> > On Thu, Feb 25, 2021 at 04:50:02PM +0100, Jan Beulich wrote:
> > > On 25.02.2021 16:24, Connor Davis wrote:
> > > > index 9745a77eee..f5ec65bf9b 100644
> > > > --- a/xen/common/sched/core.c
> > > >
On 26.02.2021 17:36, Andrew Cooper wrote:
> On 26/02/2021 16:34, osstest service owner wrote:
>> flight 159709 xen-unstable-smoke real [real]
>> flight 159713 xen-unstable-smoke real-retest [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/159709/
>> http://logs.test-lab.xenproject.org/oss
Similarly to commit 78271684719 ("cpu: tcg_ops: move to tcg-cpu-ops.h,
keep a pointer in CPUClass"):
We cannot in principle make the SysEmu Operations field definitions
conditional on CONFIG_SOFTMMU in code that is included by both
common_ss and specific_ss modules.
Therefore, what we can do safe
On 26/02/2021 16:34, osstest service owner wrote:
> flight 159709 xen-unstable-smoke real [real]
> flight 159713 xen-unstable-smoke real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/159709/
> http://logs.test-lab.xenproject.org/osstest/logs/159713/
>
> Regressions :-(
>
> Tests
flight 159709 xen-unstable-smoke real [real]
flight 159713 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159709/
http://logs.test-lab.xenproject.org/osstest/logs/159713/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
>> On 2/25/21 3:14 PM, Andrew Cooper wrote:
>>
>> It sounds like you'd prefer no common to start and none of the
>> arch_* calls it relies on?
>
> We definitely want "stuff compiled under RISC-V" to be caught in CI, but
> that doesn't mean "wedge all of common in with stubs to begin with".
>
> Ho
On 2/25/21 7:23 AM, Connor Davis wrote:
> Hi all,
>
> This series introduces a minimal build for RISCV. It is based on Bobby's
> previous work from last year[0]. I have worked to rebase onto current Xen,
> as well as update the various header files borrowed from Linux.
>
> This series provides th
On 26/02/2021 15:30, Bob Eshleman wrote:
> On 2/25/21 3:14 PM, Andrew Cooper wrote:
>> Well - this is orders of magnitude more complicated than it ought to
>> be. An empty head.S doesn't (well - shouldn't) need the overwhelming
>> majority of this.
>>
>> Do you know how all of this is being pulled
On 26/02/2021 14:41, Norbert Manthey wrote:
> The read value could be larger than a signed 32bit integer. As -1 is
> used as error value, we should not rely on using the full 32 bits.
> Hence, when reading the port number, we should make sure we only return
> valid values.
>
> This change sanity ch
On 2/25/21 3:14 PM, Andrew Cooper wrote:
>
> Well - this is orders of magnitude more complicated than it ought to
> be. An empty head.S doesn't (well - shouldn't) need the overwhelming
> majority of this.
>
> Do you know how all of this is being pulled in? Is it from attempting
> to compile com
On 2/26/21 3:53 PM, Julien Grall wrote:
> Hi Norbert,
>
> On 26/02/2021 14:41, Norbert Manthey wrote:
>> In case of a failure deep in the call tree, we might return NULL as the
>> value of the domain. In that case, error out instead of dereferencing
>> the NULL pointer.
>>
>> This bug was discovere
On 2/25/21 7:01 PM, Connor Davis wrote:
> On Thu, Feb 25, 2021 at 02:55:45PM -0800, Bob Eshleman wrote:
>> riscv64-unknown-linux-gnu-gcc (GCC) 10.1.0
>>
>> Which version of GCC are you seeing emit this?
>
> The one from cloned from github.com/riscv/riscv-gnu-toolchain
> in the docker container u
On 26/02/2021 15:08, Jan Beulich wrote:
> Prior to be640b1800bb ("x86: make get_page_from_l1e() return a proper
> error code") a positive return value did indicate an error. Said commit
> failed to adjust this return path, but luckily the only caller has
> always been inside a shadow_mode_refcounts
On 26.02.2021 16:08, Jan Beulich wrote:
> Prior to be640b1800bb ("x86: make get_page_from_l1e() return a proper
> error code") a positive return value did indicate an error. Said commit
> failed to adjust this return path, but luckily the only caller has
> always been inside a shadow_mode_refcounts
Prior to be640b1800bb ("x86: make get_page_from_l1e() return a proper
error code") a positive return value did indicate an error. Said commit
failed to adjust this return path, but luckily the only caller has
always been inside a shadow_mode_refcounts() conditional.
Subsequent changes caused 1 to
Hi Norbert,
On 26/02/2021 14:41, Norbert Manthey wrote:
In case of a failure deep in the call tree, we might return NULL as the
value of the domain. In that case, error out instead of dereferencing
the NULL pointer.
This bug was discovered and resolved using Coverity Static Analysis
Security Te
In case of a failure deep in the call tree, we might return NULL as the
value of the domain. In that case, error out instead of dereferencing
the NULL pointer.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Mant
When starting the daemon, we might see a NULL pointer instead of the
path to the socket.
Only relevant in case we start the process in a very deep directory
path, with a length close to 4096 so that appending "/socket" would
exceed the limit. Hence, such an error is unlikely, but should still be
f
The read value could be larger than a signed 32bit integer. As -1 is
used as error value, we should not rely on using the full 32 bits.
Hence, when reading the port number, we should make sure we only return
valid values.
This change sanity checks the input.
The issue is that the value for the por
In rare cases, the path to the daemon socket cannot be created as it is
longer than PATH_MAX. Instead of failing with a NULL pointer dereference,
terminate the application with an error message.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys
From: Michael Kurth
In case of allocation error, we should not dereference the obtained
NULL pointer.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Michael Kurth
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas F
In the out of memory case, we might return a NULL pointer when
canonicalizing node names. This NULL pointer is not checked when
creating a directory, or when removing a node. This change handles
the NULL pointer for these two cases.
This bug was discovered and resolved using Coverity Static Analys
In case a command fails, also free the memory. As this is for the CLI
client, currently the leaked memory is freed right after receiving the
error, as the application terminates next.
Similarly, if the allocation fails, do not use the NULL pointer
afterwards, but instead error out.
This bug was d
When passing format strings to the trace function, allow gcc to analyze
those and warn on issues.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xenstored_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/
In case of allocation error, we should not dereference the obtained
NULL pointer. Hence, fail early.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
Use the correct format specifier for unsigned values. Additionally, a
cast was dropped, as the format specifier did not require it anymore.
This was reported by analysis with cppcheck.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xs_
Dear all,
we have been running some code analysis tools on the xenstore code, and triaged
the results. This series presents the robustness fixes we identified.
Best,
Norbert
Michael Kurth (1):
xenstore: add missing NULL check
Norbert Manthey (9):
xenstore: add missing NULL check
xenstore:
On 26.02.2021 11:56, Julien Grall wrote:
> From: Julien Grall
>
> The new x86 IOMMU page-tables allocator will release the pages when
> relinquishing the domain resources. However, this is not sufficient
> when the domain is dying because nothing prevents page-table to be
> allocated.
>
> As the
On 26.02.2021 11:56, Julien Grall wrote:
> From: Julien Grall
>
> When using CONFIG_BIGMEM=y, the page_list cannot be accessed whilst it
> is is unitialized. However, iommu_free_pgtables() will be called even if
> the domain is not using an IOMMU.
>
> Consequently, Xen will try to go through the
On 26.02.2021 09:59, Roger Pau Monne wrote:
> The current build of the firmware relies on having 32bit compatible
> headers installed in order to build some of the 32bit firmware, but
> that usually requires multilib support and installing a i386 libc when
> building from an amd64 environment which
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.12b-rc1-tag
xen: branch for v5.12-rc1
It contains:
- A small series for Xen event channels adding some sysfs nodes for
per pv-device settings and statistics, and 2 fixes of theor
markdown as a dependency was dropped in 4.12
Fixes: 5d94433a66 ("cirrus-ci: introduce some basic FreeBSD testing")
Signed-off-by: Andrew Cooper
---
CC: Roger Pau Monné
CC: Ian Jackson
https://cirrus-ci.com/build/6589407613419520 is a successful run with this
change in effect.
---
.cirrus.yml
On 26/02/2021 09:10, Jan Beulich wrote:
> On 25.02.2021 21:30, Andrew Cooper wrote:
>> firmware should always have been -ffreestanding, as it doesn't execute in the
>> host environment.
>>
>> inttypes.h isn't a freestanding header, but the 32bitbios_support.c only
>> wants
>> the stdint.h types so
flight 159704 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159704/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 159695 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159695/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6ffbb3581ab7c25a35041bac03b760af54f852bf
baseline version:
ovmf 7f34681c488aee2563eaa
On 2021-02-26, Hubert Jasudowicz wrote:
> Make sure xen-vmtrace exits cleanly in case SIGPIPE is sent. This can
> happen when piping the output to some other program.
>
> Additionaly, add volatile qualifier to interrupted flag to avoid
> it being optimized away by the compiler.
>
> Signed-off-by:
Looks like a copy&paste error.
Fixes: f6e1d8515d7 ("automation: add alpine linux x86 build jobs")
Signed-off-by: Andrew Cooper
---
CC: Doug Goldstein
CC: Ian Jackson
CC: Stefano Stabellini
---
automation/gitlab-ci/build.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
Make sure xen-vmtrace exits cleanly in case SIGPIPE is sent. This can
happen when piping the output to some other program.
Additionaly, add volatile qualifier to interrupted flag to avoid
it being optimized away by the compiler.
Signed-off-by: Hubert Jasudowicz
---
tools/misc/xen-vmtrace.c | 5
From: Julien Grall
The new x86 IOMMU page-tables allocator will release the pages when
relinquishing the domain resources. However, this is not sufficient
when the domain is dying because nothing prevents page-table to be
allocated.
As the domain is dying, it is not necessary to continue to modi
From: Julien Grall
The new per-domain IOMMU page-table allocator will now free the
page-tables when domain's resources are relinquished. However, the
per-domain IOMMU structure will still contain a dangling pointer to
the root page-table.
Xen may access the IOMMU page-tables afterwards at least
From: Julien Grall
When using CONFIG_BIGMEM=y, the page_list cannot be accessed whilst it
is is unitialized. However, iommu_free_pgtables() will be called even if
the domain is not using an IOMMU.
Consequently, Xen will try to go through the page list and deference a
NULL pointer.
Bail out earl
From: Julien Grall
Hi all,
This series is a collection of bug fixes for the IOMMU teardown code.
All of them are candidate for 4.15 as they can either leak memory or
lead to host crash/host corruption.
This is sent directly on xen-devel because all the issues were either
introduced in 4.15 or h
Hi Jan,
On 25/02/2021 13:18, Jan Beulich wrote:
On 25.02.2021 12:56, Julien Grall wrote:
On 24/02/2021 14:07, Jan Beulich wrote:
On 24.02.2021 10:43, Julien Grall wrote:
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -267,6 +267,12 @@ int iommu_free_pgt
On Fri, Feb 26, 2021 at 1:17 PM Christoph Hellwig wrote:
>
> On Fri, Feb 26, 2021 at 12:17:50PM +0800, Claire Chang wrote:
> > Do you think I should fix this and rebase on the latest linux-next
> > now? I wonder if there are more factor and clean up coming and I
> > should wait after that.
>
> Her
flight 159685 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159685/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 26.02.21 09:57, Julien Grall wrote:
Hi Juergen,
On 26/02/2021 07:10, Jürgen Groß wrote:
On 25.02.21 18:41, Julien Grall wrote:
From: Julien Grall
Coverity will report unitialized values for every use of xs_state_*
structures in the save part. This can be prevented by using the [0]
rather
On 26.02.2021 09:59, Roger Pau Monne wrote:
> elfstructs.h doesn't require anything from inttypes.h: it's more
> appropriate to include stdint.h instead which contains the type
> declarations required for the ELF types.
>
> Signed-off-by: Roger Pau Monné
Let's go with Andrew's slightly larger ch
On 25.02.2021 21:30, Andrew Cooper wrote:
> firmware should always have been -ffreestanding, as it doesn't execute in the
> host environment.
>
> inttypes.h isn't a freestanding header, but the 32bitbios_support.c only wants
> the stdint.h types so switch to the more appropriate include.
>
> This
On 25.02.2021 21:30, Andrew Cooper wrote:
> The logic behind switching to elfstructs applies to sun builds as well.
>
> Fixes: 81b2b328a2 ("hvmloader: use Xen private header for elf structs")
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 25.02.2021 21:51, Stefano Stabellini wrote:
> On Thu, 25 Feb 2021, Jan Beulich wrote:
>> On 25.02.2021 02:22, Stefano Stabellini wrote:
>>> --- a/xen/include/public/features.h
>>> +++ b/xen/include/public/features.h
>>> @@ -114,6 +114,13 @@
>>> */
>>> #define XENFEAT_linux_rsdp_unrestricted
It's now safe to enable the build of rombios on Alpine systems, as
hvmloader already builds fine there.
Signed-off-by: Roger Pau Monné
---
automation/scripts/build | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/automation/scripts/build b/automation/scripts/build
index d
The current build of the firmware relies on having 32bit compatible
headers installed in order to build some of the 32bit firmware, but
that usually requires multilib support and installing a i386 libc when
building from an amd64 environment which is cumbersome just to get
some headers.
Usually th
elfstructs.h doesn't require anything from inttypes.h: it's more
appropriate to include stdint.h instead which contains the type
declarations required for the ELF types.
Signed-off-by: Roger Pau Monné
---
tools/firmware/hvmloader/32bitbios_support.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
Hello,
While the series started as a build fix for Alpine I think they are
interesting on their own for other OSes/distros, since it allows to
remove the i386 libc as a build dependency.
THis is done by proving a suitable set of standalone headers that are
suitable for the needs of the firmware b
Hi Juergen,
On 26/02/2021 07:10, Jürgen Groß wrote:
On 25.02.21 18:41, Julien Grall wrote:
From: Julien Grall
Coverity will report unitialized values for every use of xs_state_*
structures in the save part. This can be prevented by using the [0]
rather than [] to define variable length array.
On 25.02.2021 18:09, Andrew Cooper wrote:
> The current code has an early exit for PV guests, but it returns 0 having done
> nothing.
>
> Fixes: 524a98c2ac5 ("public / x86: introduce __HYPERCALL_dm_op...")
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 25.02.2021 18:09, Andrew Cooper wrote:
> Curiously absent from the stable API/ABIs is an ability to query the number of
> vcpus which a domain has. Emulators need to know this information in
> particular to know how many stuct ioreq's live in the ioreq server mappings.
>
> In practice, this fo
flight 159681 qemu-mainline real [real]
flight 159697 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159681/
http://logs.test-lab.xenproject.org/osstest/logs/159697/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 26.02.2021 04:08, Connor Davis wrote:
> On Thu, Feb 25, 2021 at 04:50:02PM +0100, Jan Beulich wrote:
>> On 25.02.2021 16:24, Connor Davis wrote:
>>> Return from cpu_schedule_up when either cpu is 0 or
>>> NR_CPUS == 1. This fixes the following:
>>>
>>> core.c: In function 'cpu_schedule_up':
>>>
83 matches
Mail list logo
