Hi Stefan,
On Thu, Apr 20, 2023 at 7:39 PM Stefan Hajnoczi wrote:
>
> 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.
>
flight 180333 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180333/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
Tests which did not
Hi all,
Following the discussion in April community call, here comes the two
updated possible release schedule options that I came up with.
Both of these two options will satisfy the requirements/concerns that
I've received so far. But I personally would prefer the option 2 as we
shouldn't
BACKGROUND
==
When multiple work items are queued to a workqueue, their execution order
doesn't match the queueing order. They may get executed in any order and
simultaneously. When fully serialized execution - one by one in the queueing
order - is needed, an ordered workqueue should be
flight 180345 xen-unstable-smoke real [real]
flight 180348 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180345/
http://logs.test-lab.xenproject.org/osstest/logs/180348/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 180346 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180346/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3163f34a42a5dacaf63499e69bf0fefdc409d89e
baseline version:
ovmf
flight 180343 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180343/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9bf79303ae5cb4d0e14ed7a219107b53e2ecdcd0
baseline version:
ovmf
On Wed, Apr 19, 2023 at 12:54 AM David Hildenbrand wrote:
>
> On 18.04.23 23:33, Vishal Moola wrote:
> > On Tue, Apr 18, 2023 at 8:45 AM David Hildenbrand wrote:
> >>
> >> On 17.04.23 22:50, Vishal Moola (Oracle) wrote:
> >>> s390 uses page->index to keep track of page tables for the guest
flight 180328 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 2
flight 180340 xen-unstable-smoke real [real]
flight 180344 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180340/
http://logs.test-lab.xenproject.org/osstest/logs/180344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 180339 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180339/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 45f5341f6de16edc7aed082e15e6afd48a664ee1
baseline version:
ovmf
flight 180327 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180327/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
On Thu, Apr 20 2023 at 18:47, Paul Menzel wrote:
> Am 20.04.23 um 17:57 schrieb Thomas Gleixner:
> I quickly applied it on top of your branch, but I am getting:
As I said it was untested. I was traveling and did not have access to a
machine to even build it completely. Fixed up and tested version
flight 180337 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180337/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8f4ec0cc433a33967cdbbb945acd37b6ae1d3fce
baseline version:
ovmf
flight 180335 xen-unstable-smoke real [real]
flight 180336 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180335/
http://logs.test-lab.xenproject.org/osstest/logs/180336/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
Dear Thomas,
Am 20.04.23 um 17:57 schrieb Thomas Gleixner:
On Thu, Apr 20 2023 at 07:51, Sean Christopherson wrote:
On Thu, Apr 20, 2023, Thomas Gleixner wrote:
On Thu, Apr 20 2023 at 10:23, Andrew Cooper wrote:
On 20/04/2023 9:32 am, Thomas Gleixner wrote:
On Wed, Apr 19, 2023, Andrew
> From: Roger Pau Monne
> Sent: Thursday, April 6, 2023 12:41 PM
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Konrad Rzeszutek Wilk
> ; Ross Lagerwall
> Subject: [PATCH v2] livepatch-tools: remove usage of error.h
>
> It's a GNU libc specific header which prevents building
flight 180325 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180325/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
On Thu, Apr 20 2023 at 07:51, Sean Christopherson wrote:
> On Thu, Apr 20, 2023, Thomas Gleixner wrote:
>> On Thu, Apr 20 2023 at 10:23, Andrew Cooper wrote:
>> > On 20/04/2023 9:32 am, Thomas Gleixner wrote:
>> > > On Wed, Apr 19, 2023, Andrew Cooper wrote:
>> > > > This was changed in x2APIC,
On 20.04.2023 16:31, Roger Pau Monné wrote:
> On Thu, Apr 20, 2023 at 10:31:08AM +0200, Jan Beulich wrote:
>> On 19.04.2023 17:55, Roger Pau Monné wrote:
>>> On Wed, Apr 19, 2023 at 03:58:10PM +0200, Jan Beulich wrote:
@@ -1342,6 +1349,17 @@ unsigned int rtc_guest_read(unsigned int
On Thu, Apr 20, 2023, Thomas Gleixner wrote:
> On Thu, Apr 20 2023 at 10:23, Andrew Cooper wrote:
> > On 20/04/2023 9:32 am, Thomas Gleixner wrote:
> > > On Wed, Apr 19, 2023, Andrew Cooper wrote:
> > > > This was changed in x2APIC, which made the x2APIC_ID immutable.
>
> >> I'm pondering to
On 19.04.2023 17:42, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/page-bits.h
> +++ b/xen/arch/riscv/include/asm/page-bits.h
> @@ -1,6 +1,16 @@
> #ifndef __RISCV_PAGE_BITS_H__
> #define __RISCV_PAGE_BITS_H__
>
> +#ifdef CONFIG_RISCV_64
> +#define PAGETABLE_ORDER (9)
>
On Thu, Apr 20, 2023 at 10:31:08AM +0200, Jan Beulich wrote:
> On 19.04.2023 17:55, Roger Pau Monné wrote:
> > On Wed, Apr 19, 2023 at 03:58:10PM +0200, Jan Beulich wrote:
> >> @@ -1342,6 +1349,17 @@ unsigned int rtc_guest_read(unsigned int
> >> * underlying hardware would permit doing
On 20/4/23 13:37, Stefan Hajnoczi wrote:
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(),
Hi Stefan,
On 20/4/23 13:37, Stefan Hajnoczi wrote:
v3:
- Resend full patch series. v2 was sent in the middle of a git rebase and was
missing patches. [Eric]
- Apply Reviewed-by tags.
Based-on: 087bc644b7634436ca9d52fe58ba9234e2bef026 (kevin/block-next)
It seems kevin/block-next got
> On 20 Apr 2023, at 14:08, Julien Grall wrote:
>
> Hi Luca,
>
> On 20/04/2023 13:43, Luca Fancellu wrote:
>>> On 20 Apr 2023, at 13:29, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 20/04/2023 09:46, Luca Fancellu wrote:
> +int __init sve_sanitize_vl_param(int val, unsigned int
Hi Luca,
On 20/04/2023 13:43, Luca Fancellu wrote:
On 20 Apr 2023, at 13:29, Julien Grall wrote:
Hi Luca,
On 20/04/2023 09:46, Luca Fancellu wrote:
+int __init sve_sanitize_vl_param(int val, unsigned int *out)
+{
+/*
+ * Negative SVE parameter value means to use the maximum
On 19.04.2023 17:42, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -4,6 +4,37 @@
> #include
> #include
>
> +/*
> + * RISC-V64 Layout:
> + *
> + * From the riscv-privileged doc:
> + * When mapping between narrower and
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH v3 02/17] xen/arm: implement helpers to get and update
> NUMA status
> > ---
> > v2 -> v3:
> > 1. Rename the first entry of enum dt_numa_status as DT_NUMA_DEFAULT.
> > 2. Make enum dt_numa_status device_tree_numa as
> On 20 Apr 2023, at 13:29, Julien Grall wrote:
>
> Hi Luca,
>
> On 20/04/2023 09:46, Luca Fancellu wrote:
>>> +int __init sve_sanitize_vl_param(int val, unsigned int *out)
>>> +{
>>> +/*
>>> + * Negative SVE parameter value means to use the maximum supported
>>> +
On 20.04.2023 13:25, Henry Wang wrote:
> From: Wei Chen
>
> NUMA has one global and one implementation specific switches. For
> ACPI NUMA implementation, Xen has acpi_numa, so we introduce
> device_tree_numa for device tree NUMA implementation. And use
> enumerations to indicate init, off and on
On 20.04.2023 13:25, Henry Wang wrote:
> From: Wei Chen
>
> We will parse NUMA nodes distances from device tree. So we need
> a matrix to record the distances between any two nodes we parsed.
> Accordingly, we provide this node_set_distance API for device tree
> NUMA to set the distance for any
flight 180331 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180331/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
Tests which did
On 19/04/2023 09:20, Bertrand Marquis wrote:
Hi Jan,
On 19 Apr 2023, at 09:52, Jan Beulich wrote:
On 19.04.2023 09:31, Bertrand Marquis wrote:
Hi Jan,
On 19 Apr 2023, at 08:28, Jan Beulich wrote:
On 18.04.2023 16:25, Julien Grall wrote:
On 18/04/2023 14:13, Bertrand Marquis wrote:
Hi Luca,
On 20/04/2023 09:46, Luca Fancellu wrote:
+int __init sve_sanitize_vl_param(int val, unsigned int *out)
+{
+/*
+ * Negative SVE parameter value means to use the maximum supported
+ * vector length, otherwise if a positive value is provided, check if the
+ * vector
On 20.04.2023 13:25, Henry Wang wrote:
> From: Wei Chen
>
> As a memory range described in device tree cannot be split across
> multiple nodes. And it is very likely than if you have more than
> 64 nodes, you may need a lot more than 2 regions per node. So the
> default NR_NODE_MEMBLKS value
Stefan Hajnoczi wrote:
> On Wed, 19 Apr 2023 at 14:52, Eric Blake wrote:
>>
>> On Wed, Apr 19, 2023 at 01:28:17PM -0400, Stefan Hajnoczi wrote:
>> > virtio_queue_aio_detach_host_notifier() does two things:
>> > 1. It removes the fd handler from the event loop.
>> > 2. It processes the virtqueue
flight 180332 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180332/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
Hi Luca,
> On 20 Apr 2023, at 10:46, Luca Fancellu wrote:
>
>>
>> +int __init sve_sanitize_vl_param(int val, unsigned int *out)
>> +{
>> +/*
>> + * Negative SVE parameter value means to use the maximum supported
>> + * vector length, otherwise if a positive
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
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
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
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
---
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
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
---
include/block/export.h
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
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
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 in block-backend-common.h.
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
---
include/sysemu/block-backend-global-state.h | 1 +
block/block-backend.c
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
vhost_user_server_stop() uses AIO_WAIT_WHILE(). AIO_WAIT_WHILE()
requires that AioContext is only acquired once.
Since blk_exp_request_shutdown() already acquires the AioContext it
shouldn't be acquired again in vhost_user_server_stop().
Signed-off-by: Stefan Hajnoczi
---
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é
v3:
- Resend full patch series. v2 was sent in the middle of a git rebase and was
missing patches. [Eric]
- Apply Reviewed-by tags.
v2:
- Do not rely on BlockBackend request queuing, implement .drained_begin/end()
instead in xen-block, virtio-blk, and virtio-scsi [Paolo]
- Add
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
On Wed, 19 Apr 2023 at 14:52, Eric Blake wrote:
>
> On Wed, Apr 19, 2023 at 01:28:17PM -0400, Stefan Hajnoczi wrote:
> > 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
In the common sysctl command XEN_SYSCTL_physinfo, the cores_per_socket
is calculated based on the cpu_core_mask of CPU0. Currently on Arm
this is a fixed value 1 (can be checked via xl info), which is not
correct. This is because during the Arm cpu online process,
set_cpu_sibling_map() only sets
From: Wei Chen
Device tree based NUMA doesn't have the proximity domain like
ACPI. So we can return node id directly as arch nid.
Signed-off-by: Wei Chen
Signed-off-by: Henry Wang
---
v2 -> v3:
1. No change.
v1 -> v2:
1. Use numa_node_to_arch_nid instead of dummy node_to_pxm.
---
From: Wei Chen
Processor NUMA ID information is stored in device tree's processor
node as "numa-node-id". We need a new helper to parse this ID from
processor node. If we get this ID from processor node, this ID's
validity still need to be checked. Once we got a invalid NUMA ID
from any
From: Wei Chen
node_online_map in smpboot still need for Arm when NUMA is turn
off by Kconfig.
Signed-off-by: Wei Chen
Signed-off-by: Henry Wang
---
v2 -> v3:
1. No change.
v1 -> v2:
1. No change.
---
xen/arch/arm/smpboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Wei Chen
Arm platforms support both ACPI and device tree. We don't
want users to select device tree NUMA or ACPI NUMA manually.
We hope users can just enable NUMA for Arm, and device tree
NUMA and ACPI NUMA can be selected depends on device tree
feature and ACPI feature status
From: Wei Chen
The NUMA information provided in the host Device-Tree
are only for Xen. For dom0, we want to hide them as they
may be different (for now, dom0 is still not aware of NUMA)
The CPU and memory nodes are recreated from scratch for the
domain. So we already skip the "numa-node-id"
From: Wei Chen
In this patch, we can start to create NUMA system that is
based on device tree.
Signed-off-by: Wei Chen
Signed-off-by: Henry Wang
---
v2 -> v3:
1. No change.
v1 -> v2:
1. replace ~0 by INVALID_PADDR.
2. only print error messages for invalid dtb data.
3. remove unnecessary
From: Wei Chen
Current numa command in documentation is x86 only. Remove
x86 from numa command's arch limitation in this patch.
Signed-off-by: Wei Chen
Signed-off-by: Henry Wang
Acked-by: Jan Beulich
---
v2 -> v3:
1. Add the Acked-by tag from Jan.
v1 -> v2:
1. Update Arm NUMA status in
From: Wei Chen
A NUMA aware device tree will provide a "distance-map" node to
describe distance between any two nodes. This patch introduce a
new helper to parse this distance map.
Signed-off-by: Wei Chen
Signed-off-by: Henry Wang
---
v2 -> v3:
1. No change.
v1 -> v2:
1. Get rid of useless
From: Wei Chen
In this function, we scan the whole device tree to parse CPU node id,
memory node id and distance-map. Though early_scan_node will invoke
a handler to process memory nodes. If we want to parse memory node id
in that handler, we have to embed NUMA parse code in that handler.
But we
From: Wei Chen
In this patch, we make NUMA node online and add cpu to
its NUMA node. This will make NUMA-aware components
have NUMA affinity data to support their work.
To keep the mostly the same behavior of x86, we use
numa_detect_cpu_node to online node. The difference is that,
we have
From: Wei Chen
Memory blocks' NUMA ID information is stored in device tree's
memory nodes as "numa-node-id". We need a new helper to parse
and verify this ID from memory nodes.
Signed-off-by: Wei Chen
Signed-off-by: Henry Wang
---
v2 -> v3:
1. No change.
v1 -> v2:
1. Move numa_disabled check
From: Wei Chen
Implement the same helper "arch_get_ram_range" as x86 for NUMA
code to get memory bank from Arm bootinfo.
Signed-off-by: Wei Chen
Signed-off-by: Henry Wang
---
v2 -> v3:
1. No change.
v1 -> v2:
1. Use arch_get_ram_range instead of arch_get_memory_map.
---
xen/arch/arm/numa.c |
From: Wei Chen
NUMA implementation has a cpu_to_node array to store CPU to NODE
map. Xen is using CPU logical ID in runtime components, so we
use CPU logical ID as CPU index in cpu_to_node.
In device tree case, cpu_logical_map is created in dt_smp_init_cpus.
So, when NUMA is enabled,
From: Wei Chen
NUMA has one global and one implementation specific switches. For
ACPI NUMA implementation, Xen has acpi_numa, so we introduce
device_tree_numa for device tree NUMA implementation. And use
enumerations to indicate init, off and on status.
arch_numa_disabled will get
From: Wei Chen
We will parse NUMA nodes distances from device tree. So we need
a matrix to record the distances between any two nodes we parsed.
Accordingly, we provide this node_set_distance API for device tree
NUMA to set the distance for any two nodes in this patch. When
NUMA initialization
(Henry: Following the offline discussion with Wei, I will be
the one to follow-up the upstream comments for this series.
I already fixed all comments in v2 so far. Hence sending v3 out.)
The preparation work to support NUMA on Arm has been merged
and can be found at [1] and [2]. The initial
From: Wei Chen
As a memory range described in device tree cannot be split across
multiple nodes. And it is very likely than if you have more than
64 nodes, you may need a lot more than 2 regions per node. So the
default NR_NODE_MEMBLKS value (MAX_NUMNODES * 2) makes no sense
on Arm.
So, for
On Thu, Apr 20 2023 at 10:23, Andrew Cooper wrote:
> On 20/04/2023 9:32 am, Thomas Gleixner wrote:
>> I'm pondering to simply deny parallel mode if x2APIC is not there.
>
> I'm not sure if that will help much.
Spoilsport.
> Just because x2APIC is there doesn't mean it's in use. There are
>
On Wed, Apr 19, 2023 at 01:51:39PM +0200, Roger Pau Monné wrote:
> I'm afraid the serial output doesn't work on any of the Cubietruck
> boxes, so I had to unbless all of them (because the arndales are not
> suitable builders).
>
> Have already contacted Credativ to further investigate.
In the
From: Mark Syms
Ensure the PV ring is drained on disconnect. Also ensure all pending
AIO is complete, otherwise AIO tries to complete into a mapping of the
ring which has been torn down.
Signed-off-by: Mark Syms
---
CC: Stefano Stabellini
CC: Anthony Perard
CC: Paul Durrant
CC:
Updated patch to address intermittent SIGSEGV on domain disconnect/shutdown.
Mark Syms (1):
Ensure the PV ring is drained on disconnect
hw/block/dataplane/xen-block.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
--
2.40.0
>From
flight 180330 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180330/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
On 19.04.2023 23:55, Andrew Cooper wrote:
> On 19/04/2023 11:46 am, Jan Beulich wrote:
>> There's no need to write back caches on all CPUs upon seeing a WBINVD
>> exit; ones that a vCPU hasn't run on since the last writeback (or since
>> it was started) can't hold data which may need writing back.
On 20/04/2023 9:32 am, Thomas Gleixner wrote:
> On Wed, Apr 19 2023 at 17:21, Andrew Cooper wrote:
>> On 19/04/2023 2:50 pm, Andrew Cooper wrote:
>> For xAPIC, the APIC_ID register is writeable (at least, model
>> specifically), and CPUID is only the value it would have had at reset.
>> So the AP
On 19.04.2023 22:46, Andrew Cooper wrote:
> On 19/04/2023 11:46 am, Jan Beulich wrote:
>> We don't need to invalidate caches here; all we're after is that earlier
>> writes have made it to main memory (and aiui even that just in case).
>>
>> Signed-off-by: Jan Beulich
>> ---
>> This, aiui, being
On 19.04.2023 22:10, Andrew Cooper wrote:
> On 19/04/2023 11:45 am, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -3772,7 +3772,7 @@ long do_mmuext_op(
>> else if ( unlikely(!cache_flush_permitted(currd)) )
>> rc = -EACCES;
>>
On 20.04.2023 10:50, Jan Beulich wrote:
> On 19.04.2023 21:56, Andrew Cooper wrote:
>> But on to the main thing which caught my eye...
>>
>> The FLUSH in FLUSH_CACHE means the flush infrastructure, not "cache
>> flushing", and FLUSH_WRITEBACK is nonsensical next to this.
>
> I agree; I chose the
Thanks Michal,
You gave me an idea.
I am going to try it today.
Regards,
O.
чт, 20 апр. 2023 г. в 11:56, Oleg Nikitenko :
> Thanks Stefano.
>
> I am going to do it today.
>
> Regards,
> O.
>
> ср, 19 апр. 2023 г. в 23:05, Stefano Stabellini :
>
>> On Wed, 19 Apr 2023, Oleg Nikitenko wrote:
>>
On 19.04.2023 21:56, Andrew Cooper wrote:
> On 19/04/2023 11:44 am, Jan Beulich wrote:
>> --- a/xen/arch/x86/flushtlb.c
>> +++ b/xen/arch/x86/flushtlb.c
>> @@ -232,7 +232,7 @@ unsigned int flush_area_local(const void
>> if ( flags & FLUSH_HVM_ASID_CORE )
>> hvm_flush_guest_tlbs();
>>
Thanks Stefano.
I am going to do it today.
Regards,
O.
ср, 19 апр. 2023 г. в 23:05, Stefano Stabellini :
> On Wed, 19 Apr 2023, Oleg Nikitenko wrote:
> > Hi Michal,
> >
> > I corrected xen's command line.
> > Now it is
> > xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=1600M
>
> +int __init sve_sanitize_vl_param(int val, unsigned int *out)
> +{
> +/*
> + * Negative SVE parameter value means to use the maximum supported
> + * vector length, otherwise if a positive value is provided, check
> if the
> + * vector length is a
Hi Luca,
> On 20 Apr 2023, at 09:58, Luca Fancellu wrote:
>
>>>
>>> Hi Bertrand,
>>>
>>> These are the changes I’m doing to this patch to address your comment, are
>>> you ok with them?
>>>
>>> diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c
>>> index
On Wed, Apr 19 2023 at 17:21, Andrew Cooper wrote:
> On 19/04/2023 2:50 pm, Andrew Cooper wrote:
>> What I'm confused by is why this system boots in the first place. I can
>> only think that's is a system which only has 4-bit APIC IDs, and happens
>> to function when bit 4 gets truncated off the
On 19.04.2023 17:55, Roger Pau Monné wrote:
> On Wed, Apr 19, 2023 at 03:58:10PM +0200, Jan Beulich wrote:
>> On 18.04.2023 13:35, Roger Pau Monné wrote:
>>> On Tue, Apr 18, 2023 at 11:24:19AM +0200, Jan Beulich wrote:
... in order to also intercept Dom0 accesses through the alias ports.
On 19/4/23 19:28, Stefan Hajnoczi wrote:
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
On 19/4/23 19:28, Stefan Hajnoczi wrote:
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é
flight 180320 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180320/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
test-amd64-i386-pair 28
>>
>> Hi Bertrand,
>>
>> These are the changes I’m doing to this patch to address your comment, are
>> you ok with them?
>>
>> diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c
>> index f0eab18dc384..1fef466ba0aa 100644
>> --- a/xen/arch/arm/arm64/sve.c
>> +++
1 - 100 of 106 matches
Mail list logo
