On 22.02.2021 11:56, Jan Beulich wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -428,6 +428,14 @@ static void vmx_domain_relinquish_resour
> vmx_free_vlapic_mapping(d);
> }
>
> +static void domain_creation_finished(struct domain *d)
> +{
> +if ( has_vl
Now that we guard the entire Xen VA space against speculative abuse
through hypervisor accesses to guest memory, the argument translation
area's VA also needs to live outside this range, at least for 32-bit PV
guests. To avoid extra is_hvm_*() conditionals, use the alternative VA
uniformly.
While
On 25.02.2021 10:30, Jan Beulich wrote:
> Now that we guard the entire Xen VA space against speculative abuse
> through hypervisor accesses to guest memory, the argument translation
> area's VA also needs to live outside this range, at least for 32-bit PV
> guests. To avoid extra is_hvm_*() conditi
Jan Beulich writes ("Re: [PATCH 0/2] hvmloader: drop usage of system headers"):
> On 24.02.2021 21:08, Andrew Cooper wrote:
> > After some experimentation in the arch container
...
> > while the freestanding form with `gcc -ffreestanding -m32 -E` is:
...
> > # 34 "/usr/lib/gcc/x86_64-pc-linux-gnu/8
On Wed, Feb 24, 2021 at 08:08:25PM +, Andrew Cooper wrote:
> On 24/02/2021 10:26, Roger Pau Monne wrote:
> > Hello,
> >
> > Following two patches aim to make hvmloader standalone, so that it don't
> > try to use system headers. It shouldn't result in any functional
> > change.
> >
> > Thanks, R
On 25.02.2021 10:50, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 0/2] hvmloader: drop usage of system
> headers"):
>> On 24.02.2021 21:08, Andrew Cooper wrote:
>>> After some experimentation in the arch container
> ...
>>> while the freestanding form with `gcc -ffreestanding -m32 -E` is:
Signed-off-by: Hubert Jasudowicz
---
tools/include/xenctrl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 0efcdae8b4..318920166c 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -1644,7 +1644,7 @@
Hi,
> > Because of the wasted frames I'd like this to be an option you can
> > enable when needed. For the majority of use cases this seems to be
> > no problem ...
>
> I see blinks with GNOME on Wayland on Ubuntu 20.04 and virtio-gpu with
> the EDID change included in this patch.
/me looks c
Hubert Jasudowicz writes ("[PATCH][4.15] tools: Fix typo in
xc_vmtrace_set_option comment"):
> Signed-off-by: Hubert Jasudowicz
Release-Acked-by: Ian Jackson
Hi Jan,
On 24/02/2021 14:07, Jan Beulich wrote:
On 24.02.2021 10:43, 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
Hi Jan,
On 24/02/2021 16:00, Jan Beulich wrote:
On 24.02.2021 16:58, 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
@@ -149,6 +149,13 @@ int arch_iommu_domain_init(struct domain *d)
void arch_
On 25/02/2021 07:33, Jan Beulich wrote:
On 24.02.2021 17:39, Paul Durrant wrote:
On 23/02/2021 16:29, Jan Beulich wrote:
When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the
special considerations for the head of the SKB no longer apply. Don't
mistakenly report ERROR to the f
On 22/02/2021 13:45, Bertrand Marquis wrote:
Hi Julien,
On 20 Feb 2021, at 14:04, Julien Grall wrote:
From: Julien Grall
Currently, Xen will send a data abort to a guest trying to write to the
ISPENDR.
Unfortunately, recent version of Linux (at least 5.9+) will start
writing to the regi
In order to support live migration of guests between kernels
that do and do not support 'feature-dynamic-multicast-control',
we add a module parameter that allows the feature to be disabled
at run time, instead of using hardcode value.
The default value is enable.
Signed-off-by: ChiaHao Hsu
---
In order to support live migration of guests between kernels
that do and do not support 'feature-ctrl-ring', we add a
module parameter that allows the feature to be disabled
at run time, instead of using hardcode value.
The default value is enable.
Signed-off-by: ChiaHao Hsu
---
drivers/net/xen-
Hi Andrew,
Andrew Cooper writes:
> On 24/02/2021 23:58, Volodymyr Babchuk wrote:
>> And I am not mentioning x86 support there...
>
> x86 uses per-pCPU stacks, not per-vCPU stacks.
>
> Transcribing from an old thread which happened in private as part of an
> XSA discussion, concerning the implic
On 25/02/2021 09:30, Jan Beulich wrote:
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -170,7 +170,11 @@ extern unsigned char boot_edid_info[128]
> *Guest-defined use.
> * 0xf580 - 0x [168MB, PML4:0]
> *Read-only
On 25.02.2021 13:52, Andrew Cooper wrote:
> On 25/02/2021 09:30, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/config.h
>> +++ b/xen/include/asm-x86/config.h
>> @@ -170,7 +170,11 @@ extern unsigned char boot_edid_info[128]
>> *Guest-defined use.
>> * 0xf580 - 0xff
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, which is most easily achieved by never creating any magic
entries.
To comp
branch xen-unstable
xenbranch xen-unstable
job test-xtf-amd64-amd64-3
testid xtf/test-pv32pae-selftest
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://
Alex Bennée writes:
> Hi,
>
> These patches have been sitting around as part of a larger series to
> improve the support of Xen on AArch64. The second part of the work is
> currently awaiting other re-factoring and build work to go in to make
> the building of a pure-Xen capable QEMU easier. As
On 25.02.2021 14:03, 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, which is most easily achiev
Jan Beulich writes ("[PATCH][4.15] x86/shadow: suppress "fast fault path"
optimization without reserved bits"):
> 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 mac
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_pgtables(struct domain *d)
>>> str
Jan Beulich writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault path"
optimization without reserved bits"):
> As to 4.15: Without this shadow mode simply won't work on such (new)
> hardware. Hence something needs to be done anyway. An alternative
> would be to limit the change to just the
On 25.02.2021 13:01, Julien Grall wrote:
> On 24/02/2021 16:00, Jan Beulich wrote:
>> On 24.02.2021 16:58, 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
@@ -149,6 +149,13 @@ int arch
On 25.02.2021 14:20, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH][4.15] x86/shadow: suppress "fast fault path"
> optimization without reserved bits"):
>> As to 4.15: Without this shadow mode simply won't work on such (new)
>> hardware. Hence something needs to be done anyway. An alternati
On 25.02.2021 14:17, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH][4.15] x86/shadow: suppress "fast fault path"
> optimization without reserved bits"):
>> 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.
Jan Beulich writes ("[4.15] Re: [PATCH] x86/EFI: suppress GNU ld 2.36'es
creation of base relocs"):
> Since getting Andrew's ack has taken across the firm-freeze boundary,
> may I ask for a release-ack here?
Indeed.
Release-Acked-by: Ian Jackson
> As noted this change (alongside
> the earlier
flight 159652 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159652/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 159475
test-amd64-i386-xl
On 25.02.2021 13:11, Paul Durrant wrote:
> On 25/02/2021 07:33, Jan Beulich wrote:
>> On 24.02.2021 17:39, Paul Durrant wrote:
>>> On 23/02/2021 16:29, Jan Beulich wrote:
When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the
special considerations for the head of the SKB
On 23/02/2021 13:24, Ash Wilding wrote:
Hi Julien,
Hi Ash,
Thanks for looking at this,
vcpu_block() is now gaining an smp_mb__after_atomic() to prevent the
CPU to read any information about local events before the flag
_VPF_blocked is set.
Reviewed-by: Ash Wilding
Thanks!
As an asi
This was missing from the work to add the alpine container.
Fixes: a9afe7768bd ("automation: add alpine linux 3.12 x86 build container")
Signed-off-by: Andrew Cooper
---
CC: Wei Liu
CC: Doug Goldstein
CC: Ian Jackson
For 4.15. This is only developer tooling, with no impact on the build.
---
Andrew Cooper writes ("[PATCH for-4.15] automation: Fix containerize to
understand the Alpine container"):
> This was missing from the work to add the alpine container.
>
> Fixes: a9afe7768bd ("automation: add alpine linux 3.12 x86 build container")
> Signed-off-by: Andrew Cooper
Release-Acked-
Defaulting to yes only for X86 and ARM reduces the requirements
for a minimal build when porting new architectures.
Signed-off-by: Connor Davis
---
xen/drivers/char/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
ind
The variables iommu_enabled and iommu_dont_flush_iotlb are defined in
drivers/passthrough/iommu.c and are referenced in common code, which
causes the link to fail when !CONFIG_HAS_PASSTHROUGH.
Guard references to these variables in common code so that xen
builds when !CONFIG_HAS_PASSTHROUGH.
Sign
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':
core.c:2769:19: error: array subscript 1 is above array bounds
of 'struct vcpu *[1]' [-Werror=array-bounds]
2769 | if ( idle_vcpu[cpu] == NULL )
|
Signed-o
Declare struct grant_table {}; in grant_table.h when
!CONFIG_GRANT_TABLE. This fixes the following:
/build/xen/include/xen/grant_table.h:84:50: error: 'struct grant_table'
declared inside parameter list will not be visible outside of this
definition or declaration [-Werror]
84 | static inline i
Add a container for cross-compiling xen to riscv64.
This just includes the cross-compiler and necessary packages for
building xen itself (packages for tools, stubdoms, etc., can be
added later).
To build xen in the container run the following:
$ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen
Signed
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 the patches necessary to get a minimal build
working. Th
shinfo already holds the result of skb_shinfo(skb) at this point - no
need to re-invoke the construct even twice.
Signed-off-by: Jan Beulich
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -557,8 +557,8 @@ check_frags:
}
if (skb_has_frag_list(
On 25.02.2021 16:24, Connor Davis wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -501,7 +501,9 @@ static int sanitise_domain_config(struct
> xen_domctl_createdomain *config)
> return -EINVAL;
> }
>
> +#ifdef CONFIG_HAS_PASSTHROUGH
> if ( !iommu
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':
> core.c:2769:19: error: array subscript 1 is above array bounds
> of 'struct vcpu *[1]' [-Werror=array-bounds]
> 276
On 25.02.2021 16:24, Connor Davis wrote:
> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -66,6 +66,8 @@ int gnttab_acquire_resource(
>
> #define opt_max_grant_frames 0
>
> +struct grant_table {};
> +
> static inline int grant_table_init(struct domain *d,
>
flight 159668 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159668/
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
On 25/02/2021 14:00, Jan Beulich wrote:
On 25.02.2021 13:11, Paul Durrant wrote:
On 25/02/2021 07:33, Jan Beulich wrote:
On 24.02.2021 17:39, Paul Durrant wrote:
On 23/02/2021 16:29, Jan Beulich wrote:
When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the
special considerati
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 forces all userspace to link against libxenctrl to use
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
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Ian Jackson
CC: Paul Durrant
For 4.15. Found whil
Andrew Cooper writes ("[PATCH for-4.15] dmop: Add XEN_DMOP_nr_vcpus"):
> 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 mappin
Andrew Cooper writes ("[PATCH for-4.15] x86/dmop: Properly fail for PV guests"):
> The current code has an early exit for PV guests, but it returns 0 having done
> nothing.
Reviewed-by: Ian Jackson
> diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
> index 5bc172a5d4..612749442e 100644
On 25/02/2021 17:21, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.15] dmop: Add XEN_DMOP_nr_vcpus"):
>> 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 m
Adding xen-devel and Ian to cc.
On 2/24/21 6:11 AM, Daniel P. Berrangé wrote:
The following features have been deprecated for well over the 2
release cycle we promise
This reminded me of a bug report we received late last year when updating to
5.2.0. 'virsh setvcpus' suddenly stopped working
On 25/02/2021 17:22, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.15] x86/dmop: Properly fail for PV
> guests"):
>> The current code has an early exit for PV guests, but it returns 0 having
>> done
>> nothing.
> Reviewed-by: Ian Jackson
Thanks.
>
>> diff --git a/xen/arch/x86/hvm/dm
From: Julien Grall
At the moment, the return of talloc_strdup() is not checked. This means
we may dereference a NULL pointer if the allocation failed.
However, it is pointless to allocate the memory as send_reply() will
copy the data to a different buffer. So drop the use of talloc_strdup().
Th
From: Julien Grall
Hi all,
The AWS coverity instance spotted a few issues that could either
leak memory and derefence NULL pointer.
All the patches are candidate for 4.15 as they are hardening XenStored
code. The changes are low risks.
Cheers,
Julien Grall (5):
tools/xenstored: Avoid unnece
From: Julien Grall
At the moment, the return of talloc_strdup() is not checked. This means
we may dereference a NULL pointer if the allocation failed.
However, it is pointless to allocate the memory as send_reply() will
copy the data to a different buffer. So drop the use of talloc_strdup().
Th
From: Julien Grall
All the error paths but one will free buf. Cover the remaining path so
buf can't be leaked.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Fixes: 7f97193e6aa8 ("tools/xenstore: add live update command to
xenstore
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.
Coverity-ID: 1472398
Coverity-ID: 1472397
Coverity-ID: 1472396
Coverity-ID: 1472395
Signed-of
From: Julien Grall
The function lu_close_dump_state() will use talloc_asprintf() without
checking whether the allocation succeeded. In the unlikely case we are
out of memory, we would dereference a NULL pointer.
As we already computed the filename in lu_get_dump_state(), we can store
the name in
On 25/02/2021 17: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.
>
> Coverity-ID: 1472398
> Coverity-ID: 1472
Hi Andrew,
On 25/02/2021 17:47, Andrew Cooper wrote:
On 25/02/2021 17: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 arr
Julien Grall writes ("[PATCH for-4.15 0/5] xenstore: Address coverity issues in
the LiveUpdate code"):
> tools/xenstored: Avoid unnecessary talloc_strdup() in do_control_lu()
> tools/xenstored: Avoid unnecessary talloc_strdup() in do_lu_start()
> tools/xenstored: control: Store the save file
Andrew Cooper writes ("Re: [PATCH for-4.15] x86/dmop: Properly fail for PV
guests"):
> On 25/02/2021 17:22, Ian Jackson wrote:
> > Andrew Cooper writes ("[PATCH for-4.15] x86/dmop: Properly fail for PV
> > guests"):
> >> The current code has an early exit for PV guests, but it returns 0 having
>
Hi Ian,
On 25/02/2021 17:54, Ian Jackson wrote:
Julien Grall writes ("[PATCH for-4.15 0/5] xenstore: Address coverity issues in the
LiveUpdate code"):
tools/xenstored: Avoid unnecessary talloc_strdup() in do_control_lu()
tools/xenstored: Avoid unnecessary talloc_strdup() in do_lu_start()
Julien Grall writes ("Re: [PATCH for-4.15 0/5] xenstore: Address coverity
issues in the LiveUpdate code"):
> On 25/02/2021 17:54, Ian Jackson wrote:
> > Julien Grall writes ("[PATCH for-4.15 0/5] xenstore: Address coverity
> > issues in the LiveUpdate code"):
> >>tools/xenstored: Silence cove
flight 159660 qemu-mainline real [real]
flight 159677 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159660/
http://logs.test-lab.xenproject.org/osstest/logs/159677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 159674 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159674/
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 159662 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159662/
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-
We can't drop the 32bit libc from the existing containers, because they are
used on older Xen branches as well.
However, we can avoid the dependency being propagated into newer conainers
derived from our dockerfiles.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Doug Goldstein
CC:
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 removes the build time dependency on a 32bit libc just
This fixes a bug we've had for ages, which even ended up being documented as
an inappropriate build dependency.
For 4.15. I'm tempted to suggest that it wants backporting to the stable
branches as well.
Andrew Cooper (3):
tools/hvmloader: Drop machelf include as well
tools/firmware: Build fi
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
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Ian Jackson
---
tools/firmware/hvmloader/32bitbios_support.c |
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 15
> >
> > +/*
> > + * A direct-mapped (or 1:1
flight 159676 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159676/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7f34681c488aee2563eaa2afcc6a2c8aa7c5b912
baseline version:
ovmf 35f87da8a2debd443ac84
On Thu, 25 Feb 2021, Julien Grall wrote:
> On 22/02/2021 13:45, Bertrand Marquis wrote:
> > Hi Julien,
> >
> > > On 20 Feb 2021, at 14:04, Julien Grall wrote:
> > >
> > > From: Julien Grall
> > >
> > > Currently, Xen will send a data abort to a guest trying to write to the
> > > ISPENDR.
> > >
On Thu, 25 Feb 2021, Julien Grall wrote:
> On 23/02/2021 13:24, Ash Wilding wrote:
> > Hi Julien,
>
> Hi Ash,
>
> > Thanks for looking at this,
> >
> > > vcpu_block() is now gaining an smp_mb__after_atomic() to prevent the
> > > CPU to read any information about local events before the flag
> >
On 2/25/21 7:24 AM, 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':
> core.c:2769:19: error: array subscript 1 is above array bounds
> of 'struct vcpu *[1]' [-Werror=array-bounds]
> 2769
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
> function added is required for a successful build, given the .config
> generated from riscv64_defconfig. The function impleme
On 2/24/21 1:47 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The ACPI_DEBUG_PRINT() macro is used in a few places in
> xen-acpi-cpuhotplug.c and xen-acpi-memhotplug.c for printing debug
> messages, but that is questionable, because that macro belongs to
> ACPICA and it should not b
branch xen-unstable
xenbranch xen-unstable
job test-xtf-amd64-amd64-4
testid xtf/test-pv32pae-selftest
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://
Newer Xen versions expose two Xen feature flags to tell us if the domain
is directly mapped or not. Only when a domain is directly mapped it
makes sense to enable swiotlb-xen on ARM.
Introduce a function on ARM to check the new Xen feature flags and also
to deal with the legacy case. Call the func
On Thu, 25 Feb 2021, Connor Davis wrote:
> Add a container for cross-compiling xen to riscv64.
> This just includes the cross-compiler and necessary packages for
> building xen itself (packages for tools, stubdoms, etc., can be
> added later).
>
> To build xen in the container run the following:
>
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
> > function added is required for a successful build, given the .config
> > ge
On Thu, Feb 25, 2021 at 04:45:15PM +0100, Jan Beulich wrote:
> On 25.02.2021 16:24, Connor Davis wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -501,7 +501,9 @@ static int sanitise_domain_config(struct
> > xen_domctl_createdomain *config)
> > return -EINVAL;
On Thu, Feb 25, 2021 at 02:55:45PM -0800, Bob Eshleman wrote:
> On 2/25/21 7:24 AM, 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':
> > core.c:2769:19: error: array subscript 1 is
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':
> > core.c:2769:19: error: array subscript 1 is
On Thu, Feb 25, 2021 at 11:14:53PM +, 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
> > function added is required for a successful build, giv
On Thu, Feb 25, 2021 at 04:53:23PM +0100, Jan Beulich wrote:
> On 25.02.2021 16:24, Connor Davis wrote:
> > --- a/xen/include/xen/grant_table.h
> > +++ b/xen/include/xen/grant_table.h
> > @@ -66,6 +66,8 @@ int gnttab_acquire_resource(
> >
> > #define opt_max_grant_frames 0
> >
> > +struct gran
flight 159671 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159671/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 159475
test-amd64-i386-xl
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index fd9c1bd183ac..8b77fd64199e 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -836,6 +836,40 @@ late_initcall(swiotlb_create_default_debugfs);
> #endif
>
> #ifdef CONFIG_DMA_RESTRICTED_POOL
> +struct page *dev_s
2021年2月25日(木) 20:46 Gerd Hoffmann :
>
> Hi,
>
> > > Because of the wasted frames I'd like this to be an option you can
> > > enable when needed. For the majority of use cases this seems to be
> > > no problem ...
> >
> > I see blinks with GNOME on Wayland on Ubuntu 20.04 and virtio-gpu with
> >
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.
Here is my preferred plan:
1) wait for my series to support the min alig
On Thu, Feb 25, 2021 at 04:31:13PM -0800, Stefano Stabellini wrote:
> On Thu, 25 Feb 2021, Connor Davis wrote:
> > Add a container for cross-compiling xen to riscv64.
> > This just includes the cross-compiler and necessary packages for
> > building xen itself (packages for tools, stubdoms, etc., ca
On 25.02.21 18:41, Julien Grall wrote:
From: Julien Grall
At the moment, the return of talloc_strdup() is not checked. This means
we may dereference a NULL pointer if the allocation failed.
However, it is pointless to allocate the memory as send_reply() will
copy the data to a different buffer
On 25.02.21 18:41, Julien Grall wrote:
From: Julien Grall
At the moment, the return of talloc_strdup() is not checked. This means
we may dereference a NULL pointer if the allocation failed.
However, it is pointless to allocate the memory as send_reply() will
copy the data to a different buffer
On 25.02.21 18:41, Julien Grall wrote:
From: Julien Grall
The function lu_close_dump_state() will use talloc_asprintf() without
checking whether the allocation succeeded. In the unlikely case we are
out of memory, we would dereference a NULL pointer.
As we already computed the filename in lu_g
On 25.02.21 18:41, Julien Grall wrote:
From: Julien Grall
All the error paths but one will free buf. Cover the remaining path so
buf can't be leaked.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Fixes: 7f97193e6aa8 ("tools/xenst
> From: Jan Beulich
> Sent: Thursday, February 25, 2021 4:44 PM
>
> On 22.02.2021 11:56, Jan Beulich wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -428,6 +428,14 @@ static void vmx_domain_relinquish_resour
> > vmx_free_vlapic_mapping(d);
> > }
> >
>
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.
Coverity-ID: 1472398
Coverity-ID: 1472397
Coverity-I
On 26.02.2021 03:54, Connor Davis wrote:
> On Thu, Feb 25, 2021 at 04:45:15PM +0100, Jan Beulich wrote:
>> On 25.02.2021 16:24, Connor Davis wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -501,7 +501,9 @@ static int sanitise_domain_config(struct
>>> xen_domctl_createdoma
1 - 100 of 101 matches
Mail list logo
