This is kind of fallout from XSA-427 investigations, partly related to
there having been a more intrusive first approach.
Most patches aren't really dependent upon one another, so can probably
go in independently (as they get acked).
A few patches from v2 went in, but there are also two new OOS p
validate_guest_pt_write(), by calling sh_validate_guest_entry(), already
guarantees the needed update of log-dirty information. Move the
operation into the sole code path needing it (when SHOPT_SKIP_VERIFY is
enabled), making clear that only one such call is needed.
Signed-off-by: Jan Beulich
--
There's no need for an indirect call here, as the mode is invariant
throughout the entire paging-locked region. All it takes to avoid it is
to have a forward declaration of sh_update_cr3() in place.
Signed-off-by: Jan Beulich
---
I find this and the respective Win7 related comment suspicious: If
When in 3-level guest mode we help a guest to stay alive, we also
shouldn't emit a trace entry to the contrary. Move the invocation up
into the respective #ifdef, noting that while this moves it into the
locked region, emitting trace records with the paging lock held is okay
(as done elsewhere as w
shadow_mode_...(), with the exception of shadow_mode_enabled(), are
shorthands for shadow_mode_enabled() && paging_mode_...(). While
potentially useful outside of shadow-internal functions, when we already
know that we're dealing with a domain in shadow mode, the "paging"
checks are sufficient and
The code has been identified as HVM-only, and its main functions are
pretty well isolated. Move them to their own file. While moving, besides
making two functions non-static, do a few style adjustments, mainly
comment formatting, but leave the code otherwise untouched.
Signed-off-by: Jan Beulich
PV domains won't use it, and even HVM ones won't when OOS is turned off
for them. There's therefore no point in putting extra pressure on the
(limited) pool of memory.
While there also zap the sh_type_to_size[] entry when OOS is disabled
altogether.
Signed-off-by: Jan Beulich
---
v3: New.
--- a
The tracking lasted only for about two weeks, but the related comment
parts were never purged.
Fixes: 50b74f55e0c0 ("OOS cleanup: Fixup arrays instead of fixup tables")
Signed-off-by: Jan Beulich
---
I'm heavily inclined to fold this into "x86/shadow: move OOS functions
to their own file".
This
The function is used from (HVM-only) OOS code only - replace the
respective #ifdef inside the function to make this more obvious. (Note
that SHOPT_OUT_OF_SYNC won't be set when !HVM, so the #ifdef surrounding
the function is already sufficient.)
Requested-by: Andrew Cooper
Signed-off-by: Jan Beul
While benign at present, it is still a little fragile to operate on a
wrong "old_mode" value in sh_update_paging_modes(). This can happen when
no monitor table was present initially - we'd create one for the new
mode without updating old_mode. Correct this in two ways, each of which
would be suffic
While 670d6b908ff2 ('x86 shadow: Move the shadow linear mapping for
n-on-3-on-4 shadows so') bumped the amount by one too little for the
32-on-64 case (which luckily was dead code, and hence a bump wasn't
necessary in the first place), 0b841314dace ('x86/shadow:
sh_{make,destroy}_monitor_table() ar
With an initial mode installed by shadow_vcpu_init(), there's no need
for sh_update_paging_modes() to deal with the "mode is still unset"
case. Leave an assertion, though.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/co
Emulation related functions are involved in HVM handling only, and in
some cases they even invoke such checks after having already done things
which are valid for HVM domains only. OOS active also implies HVM. In
sh_remove_all_mappings() one of the two checks is redundant with an
earlier paging_mod
On 15.05.2023 13:31, Alejandro Vallejo wrote:
> Because CpuIdUserDis is reported in CPUID itself, the extended leaf
> containing that bit must be retrieved before calling c_early_init()
>
> Signed-off-by: Alejandro Vallejo
Reviewed-by: Jan Beulich
On 15.05.2023 16:42, Andrew Cooper wrote:
> Right now, dom0's feature configuration is split between between the common
> path and a dom0-specific one. This mostly is by accident, and causes some
> very subtle bugs.
>
> First, start by clearly defining init_dom0_cpuid_policy() to be the domain
>
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, May 12, 2023 at 06:17:19PM -0700, Stefano Stabellini wrote:
> > >> From: Stefano Stabellini
> > >>
> > >> Xen always generates
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, May 12, 2023 at 06:17:19PM -0700, Stefano Stabellini w
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, May 12, 2023 at 06:17:19PM -0700, Stefano Stabellini w
flight 180674 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180674/
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 fai
On 16.05.2023 10:24, 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, May 12, 20
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 ACPI tables to Dom0 PVH 1:1 leads to memory corruptions
On Tue, May 16, 2023 at 11:13:17AM +0200, Jan Beulich wrote:
> On 16.05.2023 10:24, 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 16/05/2023 8:58 am, Jan Beulich wrote:
> On 15.05.2023 16:42, Andrew Cooper wrote:
>> Right now, dom0's feature configuration is split between between the common
>> path and a dom0-specific one. This mostly is by accident, and causes some
>> very subtle bugs.
>>
>> First, start by clearly defin
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, 6
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
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 fi
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
>>>
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 breakage,
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 generated
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 woul
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
Signed-off-by
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 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) exp
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 generic_iden
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 guest_common_max_featur
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 pr
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 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 a
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)
>>> p->platform_inf
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 cal
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 al
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 bdrv_dr
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 is
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 okay
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 chang
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 (whic
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.
Sign
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 MSR_ARC
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
xen/arch/x86/spec_ctr
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 guest_common_max_featur
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
test-amd64-i386-xl-qemuu-debianhvm-i386-x
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 debi
-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 t
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 enume
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 shou
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 we
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:
> --- /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))
> +
>
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 f
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.
>
> Th
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 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
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 EPOLL_ENABLE
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 i
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 ne
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
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é
Signed-o
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 n
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 th
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 aio_disable_exter
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
Signed-off-by:
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 +
b
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 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
---
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 1
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
Reviewed-
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 ta
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 b/hw/virtio/vi
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
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 xen_device_set_event
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 t
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 B
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-scs
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 atta
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
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 t
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 prepare_ftr
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: error
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 caller
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 pr
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 c
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
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' [-Werror=missing-proto
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: A
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 p
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]
Signed-off-by:
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
'__pv_queued_spin
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]
a
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 #ifdef
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 host-ins
1 - 100 of 126 matches
Mail list logo
