flight 180329 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180329/
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 Jan,
Sorry for the late reply, I’ve missed this one,
> On 17 Apr 2023, at 10:41, Jan Beulich wrote:
>
> On 12.04.2023 11:49, Luca Fancellu wrote:
>> @@ -118,3 +121,21 @@ void sve_restore_state(struct vcpu *v)
>>
>> sve_load_ctx(sve_ctx_zreg_end, v->arch.vfp.fpregs, 1);
>> }
>> +
>> +int
flight 180326 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180326/
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
flight 180317 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180317/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-vhd 21 guest-start/debian.repeat fail REGR. vs. 180278
test-armhf-armhf-xl
flight 180324 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180324/
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
flight 180323 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180323/
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 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.
>
> Signed-off-by: Jan Beulich
I find it unli
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 an analogue to uses of iommu_sync_cache() (just not
On Wed, Apr 19, 2023 at 6:34 AM Vernon Yang wrote:
>
> On Mon, Apr 17, 2023 at 01:50:19PM -0700, Vishal Moola wrote:
> > Introduce utility functions setting the foundation for ptdescs. These
> > will also assist in the splitting out of ptdesc from struct page.
> >
> > ptdesc_alloc() is defined to
flight 180321 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180321/
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 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;
> else
> -wbinvd();
> +
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
> dom0_max_vcpus=2 dom0_vcpus_pin bootscrub=0 vwfi=native sched=null
> timer_slop=0 way_size=65536 xen_colors=0-3 dom0_colors=
flight 180309 xen-unstable real [real]
flight 180322 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180309/
http://logs.test-lab.xenproject.org/osstest/logs/180322/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
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();
>
> -if ( flags & FLUSH_CACHE )
> +if ( fl
Am 3. April 2023 07:41:19 UTC schrieb Bernhard Beschow :
>When calling pci_bus_irqs() multiple times on the same object without calling
>pci_bus_irqs_cleanup() in between PCIBus::irq_count[] is currently leaked.
>Let's fix this because Xen will do just that in a few commits, and because
>calling
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 first step can be peformed by any thread and without taking the
> A
Hi,
On 16/04/2023 15:32, Julien Grall wrote:
> Currently, Xen on Arm will switch TTBR whilst the MMU is on. This is
similar to replacing existing mappings with new ones. So we need to
follow a break-before-make sequence.
When switching the TTBR, we need to temporarily disable the MMU
before up
Hi Michal,
On 17/04/2023 08:28, Michal Orzel wrote:
On 16/04/2023 16:32, Julien Grall wrote:
From: Julien Grall
Xen is currently not fully compliant with the Arm Arm because it will
switch the TTBR with the MMU on.
In order to be compliant, we need to disable the MMU before
switching the T
Hi,
On 19/04/2023 13:42, Juergen Gross wrote:
On 19.04.23 14:07, Alexander Kanavin wrote:
On 32 bit systems with 64 bit time_t (hello, Y2038 problem),
the following error occurs otherwise:
| xenstored_control.c: In function 'lu_reject_reason':
| xenstored_control.c:646:70: error: format '%ld'
Hi Stewart,
On 14/04/2023 19:57, Stewart Hildebrand wrote:
This is a collection of fixes needed to build the hypervisor with -Og for arm64.
I build-tested this with the following command:
make -j $(nproc) \
EXTRA_CFLAGS_XEN_CORE="-Og" \
XEN_TARGET_ARCH=arm64 \
CROSS_COMPILE=aarc
Hi Stewart,
On 17/04/2023 03:08, Stewart Hildebrand wrote:
On 4/16/23 22:03, Stewart Hildebrand wrote:
On 4/16/23 08:53, Julien Grall wrote:
Hi Stewart,
Hi Julien,
On 14/04/2023 19:57, Stewart Hildebrand wrote:
When building the hypervisor with -Og, we encounter the following error:
Is
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.
Signe
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
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
---
bloc
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
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
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
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 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
Signed-off-by: Stefan Hajnoczi
---
hw/i
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
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
v2:
- Do not rely on BlockBackend request queuing, implement .drained_begin/end()
instead in xen-block, virtio-blk, and virtio-scsi [Paolo]
- Add qdev_is_realized() API [Philippe]
- Add patch to avoid AioContext lock around blk_exp_ref/unref() [Paolo]
- Add patch to call .drained_begin/end() from
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
---
util/vhost-user-server
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
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é
Signed-off-by: Stefan Hajnoczi
---
include/
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
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
flight 180319 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180319/
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
Dear Thomas,
Am 19.04.23 um 14:38 schrieb Thomas Gleixner:
On Wed, Apr 19 2023 at 11:38, Thomas Gleixner wrote:
On Tue, Apr 18 2023 at 22:10, Paul Menzel wrote:
Am 18.04.23 um 10:40 schrieb Thomas Gleixner:
Can you please provide the output of cpuid?
Of course. Here the top, and the whole
On 19/04/2023 2:50 pm, Andrew Cooper wrote:
> On 19/04/2023 2:43 pm, Thomas Gleixner wrote:
>> On Wed, Apr 19 2023 at 14:38, Thomas Gleixner wrote:
>>> On Wed, Apr 19 2023 at 11:38, Thomas Gleixner wrote:
>>> IOW, the BIOS assignes random numbers to the AP APICs for whatever
>>> raisins, which leav
On 19.04.2023 17:57, Roger Pau Monné wrote:
> On Wed, Apr 19, 2023 at 04:39:01PM +0200, Jan Beulich wrote:
>> On 19.04.2023 15:36, Roger Pau Monné wrote:
>>> On Wed, Apr 19, 2023 at 02:00:38PM +0200, Jan Beulich wrote:
On 19.04.2023 13:44, Roger Pau Monné wrote:
> On Wed, Apr 19, 2023 at 1
Hi Ayan,
On 19/04/2023 17:12, Ayan Kumar Halder wrote:
>
> On 19/04/2023 14:19, Michal Orzel wrote:
>> Hi Ayan,
>
> Hi Michal,
>
> ...
>
>> --- /dev/null
>> +++ b/xen/include/xen/libfdt/libfdt-xen.h
>> @@ -0,0 +1,55 @@
>> +/*
>> + * SPDX-License-Identifier: GPL-2.0-only
>> Our CODING_STYLE say
On Wed, Apr 19, 2023 at 04:39:01PM +0200, Jan Beulich wrote:
> On 19.04.2023 15:36, Roger Pau Monné wrote:
> > On Wed, Apr 19, 2023 at 02:00:38PM +0200, Jan Beulich wrote:
> >> On 19.04.2023 13:44, Roger Pau Monné wrote:
> >>> On Wed, Apr 19, 2023 at 10:43:22AM +0200, Jan Beulich wrote:
> On 1
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.
> >>
> >> Also stop intercepting accesses to the CMO
The idea was taken from xvisor but the following changes
were done:
* Use only a minimal part of the code enough to enable MMU
* rename {_}setup_initial_pagetables functions
* add an argument for setup_initial_mapping to have
an opportunity to make set PTE flags.
* update setup_initial_pagetables
The patch does two thing:
1. Setup initial pagetables.
2. Enable MMU which end up with code in
cont_after_mmu_is_enabled()
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- Nothing changed. Only rebase
---
Changes in V4:
- Nothing changed. Only rebase
---
Changes in V3:
- update the comm
After introduction of initial pagetables there is no any sense
in dummy_bss variable as bss section will not be empty anymore.
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- Nothing changed. Only rebase
---
Changes in V4:
- Nothing changed. Only rebase
---
Changes in V3:
* patch was intr
The patch series introduces the following things:
1. Functionality to build the page tables for Xen that map
link-time to physical-time location.
2. Check that Xen is less then page size.
3. Check that load addresses don't overlap with linker addresses.
4. Prepare things for proper switch to vir
Also it was added explanation about ignoring of top VA bits
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
* the patch was introduced in the current patch series.
---
xen/arch/riscv/include/asm/config.h | 31 +
1 file changed, 31 insertions(+)
diff --git a/xen/ar
On 19/04/2023 16:18, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 19/04/2023 15:58, Ayan Kumar Halder wrote:
On 19/04/2023 14:54, Michal Orzel wrote:
On 19/04/2023 15:19, Michal Orzel wrote:
Hi Ayan,
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
The DT functions (dt_read_number(), devi
Hi Ayan,
On 19/04/2023 15:58, Ayan Kumar Halder wrote:
On 19/04/2023 14:54, Michal Orzel wrote:
On 19/04/2023 15:19, Michal Orzel wrote:
Hi Ayan,
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
The DT functions (dt_read_number(), device_tree_get_reg(),
fdt_get_mem_rsv())
currently accept
On 19/04/2023 14:19, Michal Orzel wrote:
Hi Ayan,
Hi Michal,
...
--- /dev/null
+++ b/xen/include/xen/libfdt/libfdt-xen.h
@@ -0,0 +1,55 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-only
Our CODING_STYLE says:
New files should start with a single-line SPDX comment, ..., e.g.
/* SPDX-License-I
On 19/04/2023 14:54, Michal Orzel wrote:
On 19/04/2023 15:19, Michal Orzel wrote:
Hi Ayan,
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
The DT functions (dt_read_number(), device_tree_get_reg(), fdt_get_mem_rsv())
currently accept or return 64-bit values.
In future when we support 32-bit
On 19/04/2023 7:41 am, Jan Beulich wrote:
> On 18.04.2023 19:54, Andrew Cooper wrote:
>> On 18/04/2023 6:30 pm, Andrew Cooper wrote:
>>> On 18/04/2023 12:10 pm, Andrew Cooper wrote:
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 36a07ef77eae..98529215ddec 100644
@@ -5879,6
flight 180318 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180318/
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 15:36, Roger Pau Monné wrote:
> On Wed, Apr 19, 2023 at 02:00:38PM +0200, Jan Beulich wrote:
>> On 19.04.2023 13:44, Roger Pau Monné wrote:
>>> On Wed, Apr 19, 2023 at 10:43:22AM +0200, Jan Beulich wrote:
On 19.04.2023 10:25, Roger Pau Monné wrote:
> On Wed, Apr 19, 2023 at 0
On 19/04/2023 15:29, Michal Orzel wrote:
I am not in favor of changing of the CODING_STYLE and I thought I would
express it right now to spare the round-trip of writing a patch.
Sure thing :)
So, all in all, we agree that SPDX comment must be a single line comment on its
own
(which is also s
The usage of VCPU_SSHOTTMR_future in Linux prior to 4.7 is bogus.
When the hypervisor returns -ETIME (timeout in the past) Linux keeps
retrying to setup the timer with a higher timeout instead of
self-injecting a timer interrupt.
On boxes without any hardware assistance for logdirty we have seen H
On 19/04/2023 16:20, Julien Grall wrote:
>
>
> On 19/04/2023 14:39, Michal Orzel wrote:
>> Hi Julien,
>>
>> On 19/04/2023 15:26, Julien Grall wrote:
>>>
>>>
>>> Hi,
>>>
> diff --git a/xen/include/xen/libfdt/libfdt-xen.h
> b/xen/include/xen/libfdt/libfdt-xen.h
> new file mode 100644
On 19/04/2023 14:39, Michal Orzel wrote:
Hi Julien,
On 19/04/2023 15:26, Julien Grall wrote:
Hi,
diff --git a/xen/include/xen/libfdt/libfdt-xen.h
b/xen/include/xen/libfdt/libfdt-xen.h
new file mode 100644
index 00..3296a368a6
--- /dev/null
+++ b/xen/include/xen/libfdt/libfdt-xen
On 19.04.2023 15:22, Roger Pau Monné wrote:
> On Wed, Apr 19, 2023 at 02:14:44PM +0200, Jan Beulich wrote:
>> On 19.04.2023 13:45, Roger Pau Monne wrote:
>>> --- a/xen/include/public/vcpu.h
>>> +++ b/xen/include/public/vcpu.h
>>> @@ -150,7 +150,7 @@ typedef struct vcpu_set_singleshot_timer
>>> vcp
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.
>>
>> Also stop intercepting accesses to the CMOS ports if we won't ourselves
>> use the CMOS RTC, because of there bei
On 19/04/2023 15:19, Michal Orzel wrote:
>
>
> Hi Ayan,
>
> On 13/04/2023 19:37, Ayan Kumar Halder wrote:
>>
>>
>> The DT functions (dt_read_number(), device_tree_get_reg(), fdt_get_mem_rsv())
>> currently accept or return 64-bit values.
>>
>> In future when we support 32-bit physical address,
On 19/04/2023 2:43 pm, Thomas Gleixner wrote:
> On Wed, Apr 19 2023 at 14:38, Thomas Gleixner wrote:
>> On Wed, Apr 19 2023 at 11:38, Thomas Gleixner wrote:
>> IOW, the BIOS assignes random numbers to the AP APICs for whatever
>> raisins, which leaves the parallel startup low level code up a creek
On Wed, Apr 19 2023 at 14:38, Thomas Gleixner wrote:
> On Wed, Apr 19 2023 at 11:38, Thomas Gleixner wrote:
> IOW, the BIOS assignes random numbers to the AP APICs for whatever
> raisins, which leaves the parallel startup low level code up a creek
> without a paddle, except for actually reading the
Hi Julien,
On 19/04/2023 15:26, Julien Grall wrote:
>
>
> Hi,
>
>>> diff --git a/xen/include/xen/libfdt/libfdt-xen.h
>>> b/xen/include/xen/libfdt/libfdt-xen.h
>>> new file mode 100644
>>> index 00..3296a368a6
>>> --- /dev/null
>>> +++ b/xen/include/xen/libfdt/libfdt-xen.h
>>> @@ -0,0 +
Hi Jan,
On Mon, 2023-04-17 at 13:50 +0200, Jan Beulich wrote:
> On 07.04.2023 17:48, Oleksii Kurochko wrote:
> > The idea was taken from xvisor but the following changes
> > were done:
> > * Use only a minimal part of the code enough to enable MMU
> > * rename {_}setup_initial_pagetables functions
On Wed, Apr 19, 2023 at 02:00:38PM +0200, Jan Beulich wrote:
> On 19.04.2023 13:44, Roger Pau Monné wrote:
> > On Wed, Apr 19, 2023 at 10:43:22AM +0200, Jan Beulich wrote:
> >> On 19.04.2023 10:25, Roger Pau Monné wrote:
> >>> On Wed, Apr 19, 2023 at 08:17:45AM +0200, Jan Beulich wrote:
> On 1
On Mon, Apr 17, 2023 at 01:50:19PM -0700, Vishal Moola wrote:
> Introduce utility functions setting the foundation for ptdescs. These
> will also assist in the splitting out of ptdesc from struct page.
>
> ptdesc_alloc() is defined to allocate new ptdesc pages as compound
> pages. This is to standa
On Wed, 2023-04-19 at 14:38 +0200, Thomas Gleixner wrote:
>
> I'm leaning towards disabling the CPUID lead 0x01 based discovery and be
> done with it.
Makes sense. The large machines where users really want the parallel
startup all ought to have X2APIC and hence CPUID 0x0b.
smime.p7s
Descripti
Hi,
diff --git a/xen/include/xen/libfdt/libfdt-xen.h
b/xen/include/xen/libfdt/libfdt-xen.h
new file mode 100644
index 00..3296a368a6
--- /dev/null
+++ b/xen/include/xen/libfdt/libfdt-xen.h
@@ -0,0 +1,55 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-only
Our CODING_STYLE says:
New files s
On Wed, Apr 19, 2023 at 02:14:44PM +0200, Jan Beulich wrote:
> On 19.04.2023 13:45, Roger Pau Monne wrote:
> > The usage of VCPU_SSHOTTMR_future in Linux prior to 4.7 is bogus.
> > When the hypervisor returns -ENOTIME (timeout in the past) Linux keeps
>
> Nit: -ETIME
Oh, thanks.
>
> > retrying
Hi Ayan,
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
>
>
> The DT functions (dt_read_number(), device_tree_get_reg(), fdt_get_mem_rsv())
> currently accept or return 64-bit values.
>
> In future when we support 32-bit physical address, these DT functions are
> expected to accept/return 32-bit
On 19/04/2023 12:00 pm, Olaf Hering wrote:
> Use a snapshot which includes commit
> b0ded89e917b48b73097d3b8b88dfa3afb264ed0 ("[build] Disable dangling
> pointer checking for GCC"), which fixes build with gcc12.
>
> Signed-off-by: Olaf Hering
Acked-by: Andrew Cooper
But the usual note to whomev
flight 180308 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180308/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 180293
test-armhf-armhf-libvirt-raw 15 saveresto
On 19.04.23 12:06, Olaf Hering wrote:
gcc13 fails to track the allocated memory in backup_ptes:
xg_offline_page.c: In function 'backup_ptes':
xg_offline_page.c:191:13: error: pointer 'orig' may be used after 'realloc'
[-Werror=use-after-free]
191 | free(orig);
Assist the analyze
flight 180314 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180314/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-arm
On 19.04.23 14:07, Alexander Kanavin wrote:
On 32 bit systems with 64 bit time_t (hello, Y2038 problem),
the following error occurs otherwise:
| xenstored_control.c: In function 'lu_reject_reason':
| xenstored_control.c:646:70: error: format '%ld' expects argument of type
'long int', but argume
On Wed, Apr 19 2023 at 11:38, Thomas Gleixner wrote:
> On Tue, Apr 18 2023 at 22:10, Paul Menzel wrote:
>> Am 18.04.23 um 10:40 schrieb Thomas Gleixner:
>>> Can you please provide the output of cpuid?
>>
>> Of course. Here the top, and the whole output is attached.
>
> Thanks for the data. Can you
On 19.04.2023 13:45, Roger Pau Monne wrote:
> The usage of VCPU_SSHOTTMR_future in Linux prior to 4.7 is bogus.
> When the hypervisor returns -ENOTIME (timeout in the past) Linux keeps
Nit: -ETIME
> retrying to setup the timer with a higher timeout instead of
> self-injecting a timer interrupt.
>
Hi Roger,
> -Original Message-
> From: Roger Pau Monne
> Subject: [PATCH v2] xen/vcpu: ignore VCPU_SSHOTTMR_future
>
> The usage of VCPU_SSHOTTMR_future in Linux prior to 4.7 is bogus.
> When the hypervisor returns -ENOTIME (timeout in the past) Linux keeps
> retrying to setup the timer
On 4/17/23 08:35, Juergen Gross wrote:
I'd rather have something like:
diff --git a/tools/xenstore/xenstored_control.c
b/tools/xenstore/xenstored_control.c
index cbd62556c3..f9452d63b4 100644
--- a/tools/xenstore/xenstored_control.c
+++ b/tools/xenstore/xenstored_control.c
@@ -666,12 +666,12
On 32 bit systems with 64 bit time_t (hello, Y2038 problem),
the following error occurs otherwise:
| xenstored_control.c: In function 'lu_reject_reason':
| xenstored_control.c:646:70: error: format '%ld' expects argument of type
'long int', but argument 5 has type 'time_t' {aka 'long long int'}
Hi Ayan,
On 13/04/2023 19:37, Ayan Kumar Halder wrote:
>
>
> rangeset_{xxx}_range() functions are invoked with 'start' and 'size' as
> arguments which are either 'uint64_t' or 'paddr_t'. However, the function
> accepts 'unsigned long' for 'start' and 'size'. 'unsigned long' is 32 bits for
> Arm3
On 19.04.2023 13:44, Roger Pau Monné wrote:
> On Wed, Apr 19, 2023 at 10:43:22AM +0200, Jan Beulich wrote:
>> On 19.04.2023 10:25, Roger Pau Monné wrote:
>>> On Wed, Apr 19, 2023 at 08:17:45AM +0200, Jan Beulich wrote:
On 18.04.2023 15:06, Roger Pau Monné wrote:
> On Tue, Apr 18, 2023 at 0
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.
Roger.
On Mon, Apr 17, 2023 at 12:29:00PM +0200, Roger Pau Monné wrote:
> On Mon, Ap
The usage of VCPU_SSHOTTMR_future in Linux prior to 4.7 is bogus.
When the hypervisor returns -ENOTIME (timeout in the past) Linux keeps
retrying to setup the timer with a higher timeout instead of
self-injecting a timer interrupt.
On boxes without any hardware assistance for logdirty we have seen
On Wed, Apr 19, 2023 at 10:43:22AM +0200, Jan Beulich wrote:
> On 19.04.2023 10:25, Roger Pau Monné wrote:
> > On Wed, Apr 19, 2023 at 08:17:45AM +0200, Jan Beulich wrote:
> >> On 18.04.2023 15:06, Roger Pau Monné wrote:
> >>> On Tue, Apr 18, 2023 at 01:00:53PM +0200, Jan Beulich wrote:
> On 1
flight 180305 linux-linus real [real]
flight 180315 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180305/
http://logs.test-lab.xenproject.org/osstest/logs/180315/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
Use a snapshot which includes commit
b0ded89e917b48b73097d3b8b88dfa3afb264ed0 ("[build] Disable dangling
pointer checking for GCC"), which fixes build with gcc12.
Signed-off-by: Olaf Hering
---
tools/firmware/etherboot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
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.
Signed-off-by: Jan Beulich
---
With us not running AMD IOMMUs in non-coherent ways, I wonder w
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 an analogue to uses of iommu_sync_cache() (just not
range restricted), I wonder whether it shouldn't be c
On Wed, Apr 19, 2023 at 09:56:35AM +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.
> >>
> >> Also stop intercepting accesses to the CMO
We allow its use for writeback purposes only anyway, so let's also carry
these out that way on capable hardware.
We can then also expose the WBNOINVD feature, as there's no difference
to WBINVD anymore. Note that respective emulation logic has already been
in place since ad3abc47dd23 ("x86emul: su
We allow its use for writeback purposes only anyway, so let's also carry
these out that way on capable hardware.
With it now known that WBNOINVD uses the same VM exit code as WBINVD for
both SVM and VT-x, we can now also expose the feature that way without
further distinguishing the specific cases
The majority of the present callers really aren't after invalidating
cache contents, but only after writeback. Make this available by simply
extending the FLUSH_CACHE handling accordingly. No feature checks are
required here: cache_writeback() falls back to cache_flush() as
necessary, while WBNOINV
..., first and foremost by using cache write-back operations instead
of flushing ones when available (and sufficient for the purpose).
In the context of making the last patch I started wondering whether
for PV we don't flush (write back) too little for MMUEXT_FLUSH_CACHE:
Just like for HVM, pCPU-s
On Wed, Apr 19, 2023 at 12:11:09PM +0200, Jan Beulich wrote:
> On 19.04.2023 11:41, Roger Pau Monné wrote:
> > On Tue, Apr 18, 2023 at 05:12:07PM +0100, Andrew Cooper wrote:
> >> On 18/04/2023 5:02 pm, Roger Pau Monné wrote:
> >>> On Tue, Apr 18, 2023 at 04:54:49PM +0100, Andrew Cooper wrote:
> >>>
On 19/04/2023 11:36, Oleg Nikitenko wrote:
>
>
>
> Hi Michal,
>
> I corrected xen's command line.
> Now it is
> xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=1600M
> dom0_max_vcpus=2 dom0_vcpus_pin bootscrub=0 vwfi=native sched=null
> timer_slop=0 way_size=65536 xen_color
1 - 100 of 126 matches
Mail list logo
