Calling build twice in the same environment will fail because the
directory 'binaries' was already created before. Use mkdir -p to ignore
an existing directory and move on to the actual build.
Signed-off-by: Olaf Hering
---
automation/scripts/build | 2 +-
1 file changed, 1 insertion(+), 1
On Thu, 4 May 2023, Luca Fancellu wrote:
> Add a feature to the diff-report.py script that improves the comparison
> between two analysis report, one from a baseline codebase and the other
> from the changes applied to the baseline.
>
> The comparison between reports of different codebase is an
On Thu, 4 May 2023, Luca Fancellu wrote:
> Add a new tool, diff-report.py that can be used to make diff between
> reports generated by xen-analysis.py tool.
> Currently this tool supports the Xen cppcheck text report format in
> its operations.
>
> The tool prints every finding that is in the
On Thu, 4 May 2023, Luca Fancellu wrote:
> repository in the reports
>
> Currently the cppcheck report entries shows the relative file path
> from the /xen folder of the repository instead of the base folder.
> In order to ease the checks, for example, when looking a git diff
> output and the
On Thu, 4 May 2023, Luca Fancellu wrote:
> Allow the use of Cppcheck version above 2.7, exception for 2.8 which
> is known and documented do be broken.
>
> Signed-off-by: Luca Fancellu
Acked-by: Stefano Stabellini
Tested-by: Stefano Stabellini
> ---
>
On Thu, 4 May 2023, Luca Fancellu wrote:
> Currently Cppcheck has a limitation that prevents to use make with
> parallel build and have a parallel Cppcheck invocation on each
> translation unit (the .c files), because of spurious internal errors.
>
> The issue comes from the fact that when using
flight 180680 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278
Tests which are
On Tue, 16 May 2023, Roger Pau Monné wrote:
> On Mon, May 15, 2023 at 05:11:25PM -0700, Stefano Stabellini wrote:
> > On Mon, 15 May 2023, Roger Pau Monné wrote:
> > > On Fri, May 12, 2023 at 06:17:20PM -0700, Stefano Stabellini wrote:
> > > > From: Stefano Stabellini
> > > >
> > > > Mapping the
flight 180685 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180685/
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
On Tue, 16 May 2023, Roger Pau Monné wrote:
> On Tue, May 16, 2023 at 10:10:07AM +0200, Roger Pau Monné wrote:
> > On Mon, May 15, 2023 at 05:16:27PM -0700, Stefano Stabellini wrote:
> > > On Mon, 15 May 2023, Jan Beulich wrote:
> > > > On 15.05.2023 10:48, Roger Pau Monné wrote:
> > > > > On Fri,
On Tue, 16 May 2023, Olaf Hering wrote:
> Am Tue, 16 May 2023 11:46:00 -0700 (PDT)
> schrieb Stefano Stabellini :
>
> > I think you have a point that automation/build/README.md should also
> > describe how to do what gitlab-ci does but locally (i.e. call
> > automation/scripts/build). It should
On Tue, 16 May 2023, Olaf Hering wrote:
> The command used in the example is different from the command used in
> the Gitlab CI pipelines. Adjust it to simulate what will be used by CI.
> This is essentially the build script, which is invoked with a number of
> expected environment variables such
On Tue, 16 May 2023 21:35:30 +0200
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> On 32-bit builds, the prepare_ftrace_return() function only has a global
> definition, but no prototype before it, which causes a warning:
>
> arch/x86/kernel/ftrace.c:625:6: warning: no previous prototype for
Following on from the MISRA discussions.
On x86, most are trivial. The two slightly suspect cases are __hvm_copy()
where constness is dependent on flags, and kextra in __start_xen() which only
compiles because of laundering the pointer through strstr().
The one case which I can't figure out how
Am Tue, 16 May 2023 13:38:42 -0400
schrieb John Snow :
> I haven't touched IDE or block code in quite a long while now -- I
> don't think I can help land this fix, but I won't get in anyone's way,
> either. Maybe just re-submit the patches with an improved commit
> message / cover letter that
Am Tue, 16 May 2023 11:46:00 -0700 (PDT)
schrieb Stefano Stabellini :
> I think you have a point that automation/build/README.md should also
> describe how to do what gitlab-ci does but locally (i.e. call
> automation/scripts/build). It should not only describe
> automation/scripts/containerize.
From: Arnd Bergmann
early_memremap_pgprot_adjust() is a __weak function with a local
prototype, but x86 has a custom implementation that does not
see the prototype, causing a W=1 warning:
arch/x86/mm/ioremap.c:785:17: error: no previous prototype for
'early_memremap_pgprot_adjust'
From: Arnd Bergmann
__vdso_getcpu is declared in a header but this is not included
before the definition, causing a W=1 warning:
arch/x86/entry/vdso/vgetcpu.c:13:1: error: no previous prototype for
'__vdso_getcpu' [-Werror=missing-prototypes]
arch/x86/entry/vdso/vdso32/../vgetcpu.c:13:1:
From: Arnd Bergmann
There are two functions in the olpc platform that have no prototype:
arch/x86/platform/olpc/olpc_dt.c:237:13: error: no previous prototype for
'olpc_dt_fixup' [-Werror=missing-prototypes]
arch/x86/platform/olpc/olpc-xo1-pm.c:73:26: error: no previous prototype for
From: Arnd Bergmann
copy_mc_fragile_handle_tail() is only called from assembler,
but 'make W=1' complains about a missing prototype:
arch/x86/lib/copy_mc.c:26:1: warning: no previous prototype for
‘copy_mc_fragile_handle_tail’ [-Wmissing-prototypes]
26 | copy_mc_fragile_handle_tail(char
From: Arnd Bergmann
arch_wb_cache_pmem() is declared in a global header but defined by
the architecture. On x86, the implementation needs to include the header
to avoid this warning:
arch/x86/lib/usercopy_64.c:39:6: error: no previous prototype for
'arch_wb_cache_pmem'
From: Arnd Bergmann
The purgatory code has uses parts of the decompressor and provides
its own warn() function, but has to include the corresponding
header file to avoid a -Wmissing-prototypes warning.
It turns out that this the function prototype actually differs
from the declaration, so
From: Arnd Bergmann
fb_is_primary_device() is defined as a global function on x86, unlike
the others that have an inline version. The file that defines is
however needs to include the declaration to avoid a warning:
arch/x86/video/fbdev.c:14:5: error: no previous prototype for
flight 180679 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180679/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
test-armhf-armhf-xl-credit2 5
From: Arnd Bergmann
The 32-bit system call entry points can be called on both 32-bit
and 64-bit kernels, but on the former the declarations are hidden:
arch/x86/entry/common.c:238:24: error: no previous prototype for
'do_SYSENTER_32' [-Werror=missing-prototypes]
Move them all out of the
From: Arnd Bergmann
Three functions that are defined in x86 specific code to override
generic __weak implementations cause a warning because of a missing
prototype:
arch/x86/power/cpu.c:298:5: error: no previous prototype for
'hibernate_resume_nonboot_cpu_disable' [-Werror=missing-prototypes]
From: Arnd Bergmann
__pv_queued_spin_unlock_slowpath is defined in a header file as a global
function, and designed to be called from an inline asm, but there is
no prototype visible in the definition:
kernel/locking/qspinlock_paravirt.h:493:1: error: no previous prototype for
From: Arnd Bergmann
arch_pnpbios_disabled() is defined in architecture code on x86, but this
does not include the appropriate header, causing a warning:
arch/x86/kernel/platform-quirks.c:42:13: error: no previous prototype for
'arch_pnpbios_disabled' [-Werror=missing-prototypes]
From: Arnd Bergmann
arch/x86/xen/enlighten_pv.c:1233:34: error: no previous prototype for
'xen_start_kernel' [-Werror=missing-prototypes]
arch/x86/xen/irq.c:22:14: error: no previous prototype for
'xen_force_evtchn_callback' [-Werror=missing-prototypes]
arch/x86/xen/mmu_pv.c:358:20: error: no
From: Arnd Bergmann
The set_highmem_pages_init() function is declared in asm/numa.h, which
must be included in the file that defines it to avoid a W=1 warning:
arch/x86/mm/highmem_32.c:7:13: error: no previous prototype for
'set_highmem_pages_init' [-Werror=missing-prototypes]
Signed-off-by:
From: Arnd Bergmann
The fpregs_soft_set/fpregs_soft_get functions are declared in a
header that is not included in the file that defines them, causing
a W=1 warning:
/home/arnd/arm-soc/arch/x86/math-emu/fpu_entry.c:638:5: error: no previous
prototype for 'fpregs_soft_set'
From: Arnd Bergmann
Two functions in the 32-bit doublefault code are lacking a prototype:
arch/x86/kernel/doublefault_32.c:23:36: error: no previous prototype for
'doublefault_shim' [-Werror=missing-prototypes]
23 | asmlinkage noinstr void __noreturn doublefault_shim(void)
|
From: Arnd Bergmann
'make W=1' warns about a function without a prototype in the x86-32 head code:
arch/x86/kernel/head32.c:72:13: error: no previous prototype for
'mk_early_pgtbl_32' [-Werror=missing-prototypes]
This is called from assembler code, so it does not actually need a prototype.
I
From: Arnd Bergmann
The __div64_32() function is provided for 32-bit architectures that
don't have a custom do_div() implementation. x86_32 has one, and
does not use the header file that declares the function prototype,
so the definition causes a W=1 warning:
lib/math/div64.c:31:32: error: no
From: Arnd Bergmann
When CONFIG_SMP is disabled, the prototype for safe_smp_processor_id()
is hidden, which causes a W=1 warning:
/home/arnd/arm-soc/arch/x86/kernel/apic/ipi.c:316:5: error: no previous
prototype for 'safe_smp_processor_id' [-Werror=missing-prototypes]
Since there are no
From: Arnd Bergmann
Two functions in this file are global but have no prototype in
a header and are not called from elsewhere, so they should
be static:
arch/x86/pci/ce4100.c:86:6: error: no previous prototype for 'sata_revid_init'
[-Werror=missing-prototypes]
arch/x86/pci/ce4100.c:175:5:
From: Arnd Bergmann
On 32-bit builds, the prepare_ftrace_return() function only has a global
definition, but no prototype before it, which causes a warning:
arch/x86/kernel/ftrace.c:625:6: warning: no previous prototype for
‘prepare_ftrace_return’ [-Wmissing-prototypes]
625 | void
From: Arnd Bergmann
This addresses all x86 specific prototype warnings. The majority of the
patches should be straightforward, either adding an #include statement
to get the right header, or ensuring that an unused global function is
left out of the build when the prototype is hidden.
The ones
On 16/05/2023 3:53 pm, Jan Beulich wrote:
> On 16.05.2023 16:16, Andrew Cooper wrote:
>> On 16/05/2023 3:06 pm, Jan Beulich wrote:
>>> On 16.05.2023 15:51, Andrew Cooper wrote:
On 16/05/2023 2:06 pm, Jan Beulich wrote:
> On 15.05.2023 16:42, Andrew Cooper wrote:
> Further is even just
Detach ioeventfds during drained sections to stop I/O submission from
the guest. virtio-blk is no longer reliant on aio_disable_external()
after this patch. This will allow us to remove the
aio_disable_external() API once all other code that relies on it is
converted.
Take extra care to avoid
The virtio-scsi Host Bus Adapter provides access to devices on a SCSI
bus. Those SCSI devices typically have a BlockBackend. When the
BlockBackend enters a drained section, the SCSI device must temporarily
stop submitting new I/O requests.
Implement this behavior by temporarily stopping
virtio_queue_aio_detach_host_notifier() does two things:
1. It removes the fd handler from the event loop.
2. It processes the virtqueue one last time.
The first step can be peformed by any thread and without taking the
AioContext lock.
The second step may need the AioContext lock (depending on
is_external=true suspends fd handlers between aio_disable_external() and
aio_enable_external(). The block layer's drain operation uses this
mechanism to prevent new I/O from sneaking in between
bdrv_drained_begin() and bdrv_drained_end().
The previous commit converted the xen-block device to use
Detach event channels during drained sections to stop I/O submission
from the ring. xen-block is no longer reliant on aio_disable_external()
after this patch. This will allow us to remove the
aio_disable_external() API once all other code that relies on it is
converted.
Extend
All callers now pass is_external=false to aio_set_fd_handler() and
aio_set_event_notifier(). The aio_disable_external() API that
temporarily disables fd handlers that were registered is_external=true
is therefore dead code.
Remove aio_disable_external(), aio_enable_external(), and the
is_external
Host notifiers can now use is_external=false since virtio-blk and
virtio-scsi no longer rely on is_external=true for drained sections.
Signed-off-by: Stefan Hajnoczi
---
hw/virtio/virtio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/virtio/virtio.c
vduse_blk_detach_ctx() waits for in-flight requests using
AIO_WAIT_WHILE(). This is not allowed according to a comment in
bdrv_set_aio_context_commit():
/*
* Take the old AioContex when detaching it from bs.
* At this point, new_context lock is already acquired, and we are now
* also
This is part of ongoing work to remove the aio_disable_external() API.
Use BlockDevOps .drained_begin/end/poll() instead of
aio_set_fd_handler(is_external=true).
As a side-effect the FUSE export now follows AioContext changes like the
other export types.
Signed-off-by: Stefan Hajnoczi
flight 180684 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180684/
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
The FUSE export calls blk_exp_ref/unref() without the AioContext lock.
Instead of fixing the FUSE export, adjust blk_exp_ref/unref() so they
work without the AioContext lock. This way it's less error-prone.
Suggested-by: Paolo Bonzini
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
---
For simplicity, always run BlockDevOps .drained_begin/end/poll()
callbacks in the main loop thread. This makes it easier to implement the
callbacks and avoids extra locks.
Move the function pointer declarations from the I/O Code section to the
Global State section for BlockDevOps, BdrvChildClass,
The BlockBackend quiesce_counter is greater than zero during drained
sections. Add an API to check whether the BlockBackend is in a drained
section.
The next patch will use this API.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Kevin Wolf
---
include/sysemu/block-backend-global-state.h | 1 +
There is no need to suspend activity between aio_disable_external() and
aio_enable_external(), which is mainly used for the block layer's drain
operation.
This is part of ongoing work to remove the aio_disable_external() API.
Reviewed-by: David Woodhouse
Reviewed-by: Paul Durrant
Each vhost-user-blk request runs in a coroutine. When the BlockBackend
enters a drained section we need to enter a quiescent state. Currently
any in-flight requests race with bdrv_drained_begin() because it is
unaware of vhost-user-blk requests.
When blk_co_preadv/pwritev()/etc returns it wakes
vhost-user activity must be suspended during bdrv_drained_begin/end().
This prevents new requests from interfering with whatever is happening
in the drained section.
Previously this was done using aio_set_fd_handler()'s is_external
argument. In a multi-queue block layer world the
The VuServer object has a refcount field and ref/unref APIs. The name is
confusing because it's actually an in-flight request counter instead of
a refcount.
Normally a refcount destroys the object upon reaching zero. The VuServer
counter is used to wake up the vhost-user coroutine when there are
This patch is part of an effort to remove the aio_disable_external()
API because it does not fit in a multi-queue block layer world where
many AioContexts may be submitting requests to the same disk.
The SCSI emulation code is already in good shape to stop using
aio_disable_external(). It was
Only report a transport reset event to the guest after the SCSIDevice
has been unrealized by qdev_simple_device_unplug_cb().
qdev_simple_device_unplug_cb() sets the SCSIDevice's qdev.realized field
to false so that scsi_device_find/get() no longer see it.
scsi_target_emulate_report_luns() also
Add a helper function to check whether the device is realized without
requiring the Big QEMU Lock. The next patch adds a second caller. The
goal is to avoid spreading DeviceState field accesses throughout the
code.
Suggested-by: Philippe Mathieu-Daudé
Reviewed-by: Philippe Mathieu-Daudé
blk_set_aio_context() is not fully transactional because
blk_do_set_aio_context() updates blk->ctx outside the transaction. Most
of the time this goes unnoticed but a BlockDevOps.drained_end() callback
that invokes blk_get_aio_context() fails assert(ctx == blk->ctx). This
happens because blk->ctx
v6:
- Fix scsi_device_unrealize() -> scsi_qdev_unrealize() mistake in Patch 4
commit description [Kevin]
- Explain why we don't schedule a BH in .drained_begin() in Patch 16 [Kevin]
- Copy the comment explaining why the event notifier is tested and cleared in
Patch 16 [Kevin]
- Fix
On Tue, 16 May 2023, Olaf Hering wrote:
> Am Mon, 15 May 2023 16:03:01 -0700 (PDT)
> schrieb Stefano Stabellini :
>
> > Given that opensuse-tumbleweed is still broken (doesn't complete the
> > Xen build successfully) even after these patches, I suggest we use a
> > different example?
>
> I think
On Fri, May 12, 2023 at 5:14 PM Stefano Stabellini
wrote:
>
> On Wed, 10 May 2023, Olaf Hering wrote:
> > Wed, 10 May 2023 00:58:27 +0200 Olaf Hering :
> >
> > > In my debugging (with v8.0.0) it turned out the three pci_set_word
> > > causes the domU to hang. In fact, it is just the last one:
> >
On Fri, May 12, 2023 at 12:26:14PM +, Olaf Hering wrote:
> According to openpty(3) it is required to include to get the
> prototypes for openpty() and login_tty(). But this is not what the
> function AX_CHECK_PTYFUNCS actually does. It makes no attempt to include
> the required header.
>
>
On Fri, May 12, 2023 at 11:36:44AM +, Olaf Hering wrote:
> On a fedora system, if you run `sudo sh install.sh` you break your
> system. The installation clobbers /var/run, a symlink to /run.
> A subsequent boot fails when /var/run and /run are different since
> accesses through /var/run can't
On 11.05.2023 19:09, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -0,0 +1,58 @@
> +#ifndef _ASM_RISCV_PAGE_H
> +#define _ASM_RISCV_PAGE_H
> +
> +#include
> +#include
> +
> +#define VPN_MASK((unsigned long)(PAGETABLE_ENTRIES - 1))
> +
Hello,
as shown in 'build.log' at
https://gitlab.com/xen-project/xen/-/jobs/4284741850/artifacts/browse
there is a logic error spotted by gcc 13.
crypto/rsa.c: In function 'rsa_private':
crypto/rsa.c:56:7: error: the comparison will always evaluate as 'true' for the
address of 'p' will never be
On 11.05.2023 19:09, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -4,6 +4,42 @@
> #include
> #include
>
> +/*
> + * RISC-V64 Layout:
> + *
> + * #ifdef SV39
I did point you at x86'es similar #ifdef. Unlike here, there
The command used in the example is different from the command used in
the Gitlab CI pipelines. Adjust it to simulate what will be used by CI.
This is essentially the build script, which is invoked with a number of
expected environment variables such as CC, CXX and debug.
In addition the input
On 12.05.2023 01:22, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Add the Mandatory rules agreed by the MISRA C working group to
> docs/misra/rules.rst.
>
> Signed-off-by: Stefano Stabellini
Slightly hesitantly
Acked-by: Jan Beulich
primarily because I don't see the point in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-42336 / XSA-431
Mishandling of guest SSBD selection on AMD hardware
ISSUE DESCRIPTION
=
The current logic to set SSBD on AMD Family 17h and Hygon Family 18h
processors requires
flight 180681 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180681/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 176322
test-amd64-amd64-qemuu-nested-amd 20
flight 180677 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
On 15.05.2023 16:42, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu-policy.c
> +++ b/xen/arch/x86/cpu-policy.c
> @@ -408,6 +408,25 @@ static void __init calculate_host_policy(void)
> p->platform_info.cpuid_faulting = cpu_has_cpuid_faulting;
> }
>
> +static void __init
MSR_ARCH_CAPS data is now included in featureset information. Replace
opencoded checks with regular feature ones.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/include/asm/cpufeature.h | 7
The current cpu_has_tsx_ctrl tristate is serving double pupose; to signal the
first pass through tsx_init(), and the availability of MSR_TSX_CTRL.
Drop the variable, replacing it with a once boolean, and altering
cpu_has_tsx_ctrl to come out of the feature information.
No functional change.
This builds on the work from "[PATCH 0/6] x86: Introduce MSR_ARCH_CAPS into
featuresets" and is just cleanup to feature handling.
No functional change.
Andrew Cooper (4):
x86/cpufeature: Rework {boot_,}cpu_has()
x86/vtx: Remove opencoded MSR_ARCH_CAPS check
x86/tsx: Remove opencoded
One area where Xen deviates from Linux is that test_bit() forces a volatile
read. This leads to poor code generation, because the optimiser cannot merge
bit operations on the same word.
Drop the use of test_bit(), and write the expressions in regular C. This
removes the include of bitops.h
MSR_ARCH_CAPS data is now included in featureset information.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vmx.c| 8 ++--
xen/arch/x86/include/asm/cpufeature.h | 3 +++
2 files
On 16.05.2023 16:16, Andrew Cooper wrote:
> On 16/05/2023 3:06 pm, Jan Beulich wrote:
>> On 16.05.2023 15:51, Andrew Cooper wrote:
>>> On 16/05/2023 2:06 pm, Jan Beulich wrote:
On 15.05.2023 16:42, Andrew Cooper wrote:
Further is even just non-default exposure of all the various bits
On Thu, May 04, 2023 at 03:53:18PM -0400, Stefan Hajnoczi wrote:
> @@ -819,11 +841,9 @@ void xen_block_dataplane_start(XenBlockDataPlane
> *dataplane,
> blk_set_aio_context(dataplane->blk, dataplane->ctx, NULL);
> aio_context_release(old_context);
>
> -/* Only reason for failure
On Thu, May 04, 2023 at 03:53:19PM -0400, Stefan Hajnoczi wrote:
> is_external=true suspends fd handlers between aio_disable_external() and
> aio_enable_external(). The block layer's drain operation uses this
> mechanism to prevent new I/O from sneaking in between
> bdrv_drained_begin() and
On Thu, May 04, 2023 at 03:53:18PM -0400, Stefan Hajnoczi wrote:
> Detach event channels during drained sections to stop I/O submission
> from the ring. xen-block is no longer reliant on aio_disable_external()
> after this patch. This will allow us to remove the
> aio_disable_external() API once
On 16/05/2023 3:06 pm, Jan Beulich wrote:
> On 16.05.2023 15:51, Andrew Cooper wrote:
>> On 16/05/2023 2:06 pm, Jan Beulich wrote:
>>> On 15.05.2023 16:42, Andrew Cooper wrote:
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -408,6 +408,25 @@ static void __init
On 16.05.2023 15:51, Andrew Cooper wrote:
> On 16/05/2023 2:06 pm, Jan Beulich wrote:
>> On 15.05.2023 16:42, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu-policy.c
>>> +++ b/xen/arch/x86/cpu-policy.c
>>> @@ -408,6 +408,25 @@ static void __init calculate_host_policy(void)
>>>
On Mon, Jan 16, 2023 at 03:25:33PM +0100, Peter Zijlstra wrote:
> Hi all,
>
> Patches to address the various callthunk fails reported by Joan.
>
> The first two patches are new (and I've temporarily dropped the
> restore_processor_state sealing).
>
> It is my understanding that AP bringup will
On 16/05/2023 2:06 pm, Jan Beulich wrote:
> On 15.05.2023 16:42, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu-policy.c
>> +++ b/xen/arch/x86/cpu-policy.c
>> @@ -408,6 +408,25 @@ static void __init calculate_host_policy(void)
>> p->platform_info.cpuid_faulting = cpu_has_cpuid_faulting;
>> }
On 16.05.2023 14:56, Andrew Cooper wrote:
> On 16/05/2023 1:27 pm, Jan Beulich wrote:
>> On 15.05.2023 16:42, Andrew Cooper wrote:
>>> Seed the default visibility from the dom0 special case, which for the most
>>> part just exposes the *_NO bits.
>> EIBRS and SKIP_L1DFL are outliers here, in not
On 15.05.2023 16:42, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu-policy.c
> +++ b/xen/arch/x86/cpu-policy.c
> @@ -408,6 +408,25 @@ static void __init calculate_host_policy(void)
> p->platform_info.cpuid_faulting = cpu_has_cpuid_faulting;
> }
>
> +static void __init
On 16/05/2023 1:53 pm, Jan Beulich wrote:
> On 15.05.2023 16:42, Andrew Cooper wrote:
>> Extend x86_cpu_policy_fill_native() with a read of ARCH_CAPS based on the
>> CPUID information just read, which removes the need handling it specially in
>> calculate_raw_cpu_policy().
>>
>> Extend
On 16/05/2023 1:27 pm, Jan Beulich wrote:
> On 15.05.2023 16:42, Andrew Cooper wrote:
>> Seed the default visibility from the dom0 special case, which for the most
>> part just exposes the *_NO bits.
> EIBRS and SKIP_L1DFL are outliers here, in not presently being exposed
> to Dom0. If (latent)
On 15.05.2023 16:42, Andrew Cooper wrote:
> Extend x86_cpu_policy_fill_native() with a read of ARCH_CAPS based on the
> CPUID information just read, which removes the need handling it specially in
> calculate_raw_cpu_policy().
>
> Extend generic_identify() to read ARCH_CAPS into x86_capability[],
On 16/05/2023 12.34, Andrew Cooper wrote:
On 16/05/2023 10:13 am, Florian Schmaus wrote:
To avoid implicit function declarations, which will cause an error on
modern compilers. See https://wiki.gentoo.org/wiki/Modern_C_porting
Downstream Gentoo bug: https://bugs.gentoo.org/904449
On 15.05.2023 16:42, Andrew Cooper wrote:
> Seed the default visibility from the dom0 special case, which for the most
> part just exposes the *_NO bits.
EIBRS and SKIP_L1DFL are outliers here, in not presently being exposed
to Dom0. If (latent) exposing of them wasn't an oversight, then this
On 15.05.2023 16:42, Andrew Cooper wrote:
> Bits through 24 are already defined, meaning that we're not far off needing
> the second word. Put both in right away.
>
> The bool bitfield names in the arch_caps union are unused, and somewhat out of
> date. They'll shortly be automatically
On 15.05.2023 16:42, Andrew Cooper wrote:
> We are about to move MSR_ARCH_CAPS into featureset, but the order of
> operations (copy raw policy, then copy x86_capabilitiles[] in) will end up
> clobbering the ARCH_CAPS value currently visible in the Host policy.
>
> To avoid this transient
On 16.05.2023 11:45, Andrew Cooper wrote:
> On 16/05/2023 8:58 am, Jan Beulich wrote:
>> On 15.05.2023 16:42, Andrew Cooper wrote:
>>> @@ -858,7 +839,7 @@ void __init init_dom0_cpuid_policy(struct domain *d)
>>> * so dom0 can turn off workarounds as appropriate. Temporary, until
>>> the
Am Mon, 15 May 2023 16:03:01 -0700 (PDT)
schrieb Stefano Stabellini :
> Given that opensuse-tumbleweed is still broken (doesn't complete the
> Xen build successfully) even after these patches, I suggest we use a
> different example?
I think the example in automation/build/README.md needs to be
On 16/05/2023 10:13 am, Florian Schmaus wrote:
> To avoid implicit function declarations, which will cause an error on
> modern compilers. See https://wiki.gentoo.org/wiki/Modern_C_porting
>
> Downstream Gentoo bug: https://bugs.gentoo.org/904449
>
> Signed-off-by: Florian Schmaus
Thanks for the
To avoid implicit function declarations, which will cause an error on
modern compilers. See https://wiki.gentoo.org/wiki/Modern_C_porting
Downstream Gentoo bug: https://bugs.gentoo.org/904449
Signed-off-by: Florian Schmaus
---
m4/ptyfuncs.m4 | 3 +++
tools/configure | 3 +++
2 files changed,
1 - 100 of 126 matches
Mail list logo
