flight 167809 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Sun, 23 Jan 2022, Julien Grall wrote:
> > diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> > index da88ad141a..5b0bcaaad4 100644
> > --- a/xen/common/event_channel.c
> > +++ b/xen/common/event_channel.c
> > @@ -232,7 +232,7 @@ int evtchn_allocate_port(struct domain *d,
On Mon, 24 Jan 2022, Julien Grall wrote:
> On 24/01/2022 19:06, Stefano Stabellini wrote:
> > It looks like XEN_DOMCTL_host_node_by_path and
> > XEN_DOMCTL_find_host_compatible_node would also solve the problem but I
> > think that a single hypercall that retrieves the entire host DTB would
> > be
On Mon, Jan 24, 2022 at 10:11 AM Christoph Hellwig wrote:
>
> Only the priv field of rnbd_dev_blk_io is used, so store the value of
> that in bio->bi_private directly and remove the entire bio_set overhead.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Jack Wang
Thanks!
> ---
>
flight 167806 xen-unstable real [real]
flight 167807 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167806/
http://logs.test-lab.xenproject.org/osstest/logs/167807/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi,
On 24/01/2022 19:06, Stefano Stabellini wrote:
It looks like XEN_DOMCTL_host_node_by_path and
XEN_DOMCTL_find_host_compatible_node would also solve the problem but I
think that a single hypercall that retrieves the entire host DTB would
be easier to implement
DOMCTL should only be used to
On Mon, 24 Jan 2022, Oleksii Moisieiev wrote:
> On Fri, Jan 21, 2022 at 12:49:55PM -0800, Stefano Stabellini wrote:
> > On Fri, 21 Jan 2022, Oleksii Moisieiev wrote:
> > > On Thu, Jan 20, 2022 at 02:29:41PM -0800, Stefano Stabellini wrote:
> > > > On Thu, 20 Jan 2022, Oleksii Moisieiev wrote:
> >
On Mon, 24 Jan 2022, Ayan Kumar Halder wrote:
> Hi Andre,
>
> Thanks forn your comments.
>
> On 24/01/2022 14:36, Andre Przywara wrote:
> > On Mon, 24 Jan 2022 12:07:42 +
> > Ayan Kumar Halder wrote:
> >
> > Hi Ayan,
> >
> > > Many thanks for your feedback. I have one clarification :-
> >
On Fri, Jan 21, 2022 at 12:49:55PM -0800, Stefano Stabellini wrote:
> On Fri, 21 Jan 2022, Oleksii Moisieiev wrote:
> > On Thu, Jan 20, 2022 at 02:29:41PM -0800, Stefano Stabellini wrote:
> > > On Thu, 20 Jan 2022, Oleksii Moisieiev wrote:
> > > > On Wed, Jan 19, 2022 at 05:28:21PM -0800, Stefano
Hi,
On 24/01/2022 17:27, Ayan Kumar Halder wrote:
Thanks forn your comments.
On 24/01/2022 14:36, Andre Przywara wrote:
On Mon, 24 Jan 2022 12:07:42 +
Ayan Kumar Halder wrote:
Hi Ayan,
Many thanks for your feedback. I have one clarification :-
On 22/01/2022 01:30, Andre Przywara
Hi Andre,
On 24/01/2022 14:36, Andre Przywara wrote:
On Mon, 24 Jan 2022 12:07:42 +
Also, if an instruction is being modified by the guest (after it has
been loaded in the I cache), and if the guest does not invalidate the I
cache + ISB, then this is a malicious behavior by the guest. Is
Hi,
On 13/01/2022 22:53, Stefano Stabellini wrote:
+kinfo->mem.nr_banks = nr_banks;
+
+/*
+ * The property 'memory' should match the amount of memory given to
+ * the guest.
+ * Currently, it is only possible to either acquire static memory or
+ * let Xen allocate.
Hi Andre,
Thanks forn your comments.
On 24/01/2022 14:36, Andre Przywara wrote:
On Mon, 24 Jan 2022 12:07:42 +
Ayan Kumar Halder wrote:
Hi Ayan,
Many thanks for your feedback. I have one clarification :-
On 22/01/2022 01:30, Andre Przywara wrote:
On Thu, 20 Jan 2022 21:55:27 +
On 23.09.2021 14:02, Wei Chen wrote:
> We will reuse nodes_cover_memory for Arm to check its bootmem
> info. So we introduce two arch helpers to get memory map's
> entry number and specified entry's range:
> arch_get_memory_bank_number
> arch_get_memory_bank_range
I'm sorry, but
On 23.09.2021 14:02, Wei Chen wrote:
> There is some code in acpi_numa_memory_affinity_init to update node
> memory range and update node_memblk_range array. This code is not
> ACPI specific, it can be shared by other NUMA implementation, like
> device tree based NUMA implementation.
>
> So in
On Mon, 24 Jan 2022, Ross Lagerwall wrote:
> In some cases, a particular mapcache entry may be mapped 256 times
> causing the lock field to wrap to 0. For example, this may happen when
> using emulated NVME and the guest submits a large scatter-gather write.
> At this point, the entry map be
On 23.09.2021 14:02, Wei Chen wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -391,8 +391,8 @@ acpi_numa_memory_affinity_init(const struct
> acpi_srat_mem_affinity *ma)
> memblk_nodeid[num_node_memblks] = node;
> if (ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) {
>
On 23.09.2021 14:02, Wei Chen wrote:
> x86 provides a mem_hotplug to maintain the end of memory hotplug
> end address. This variable can be accessed out of mm.c. We want
> some code out of mm.c can be reused by other architectures without
> memory hotplug ability. So in this patch, we introduce
RMRRs are setup ahead of populating the p2m and hence the ASSERT when
populating the low 1MB needs to be relaxed when it finds an existing
entry: it's either RAM or a RMRR resulting from the IOMMU setup.
Rework the logic a bit and introduce a local mfn variable in order to
assert that if the gfn
On Mon, Jan 24, 2022 at 05:01:04PM +0100, Jan Beulich wrote:
> On 24.01.2022 16:23, Roger Pau Monne wrote:
> > RMRRs are setup ahead of populating the p2m and hence the ASSERT when
> > populating the low 1MB needs to be relaxed when it finds an existing
> > entry: it's either RAM or a RMRR
On 24.01.2022 16:51, Roger Pau Monne wrote:
> I find it useful for debugging certain issues to have the memory map
> dom0 is using, so print it when using `dom0=verbose` on the command
> line.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
with one further request:
> ---
By writing an empty "hotplug-status" xenstore node in the backend path
libxl can force Linux netback to wait for hotplug script execution
before proceeding to the 'connected' state.
This is required so that netback doesn't skip state 2 (InitWait) and
thus blocks libxl waiting for such state in
On 24.01.2022 16:23, Roger Pau Monne wrote:
> RMRRs are setup ahead of populating the p2m and hence the ASSERT when
> populating the low 1MB needs to be relaxed when it finds an existing
> entry: it's either RAM or a RMRR resulting from the IOMMU setup.
>
> Rework the logic a bit and introduce a
I find it useful for debugging certain issues to have the memory map
dom0 is using, so print it when using `dom0=verbose` on the command
line.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/e820.c | 2 +-
xen/arch/x86/hvm/dom0_build.c | 6 ++
xen/arch/x86/include/asm/e820.h |
RMRRs are setup ahead of populating the p2m and hence the ASSERT when
populating the low 1MB needs to be relaxed when it finds an existing
entry: it's either RAM or a RMRR resulting from the IOMMU setup.
Rework the logic a bit and introduce a local mfn variable in order to
assert that if the gfn
On 20.01.2022 16:52, Roger Pau Monné wrote:
> On Thu, Jan 20, 2022 at 03:04:39PM +0100, Jan Beulich wrote:
>> From: Artem Bityutskiy
>>
>> Enable local interrupts before requesting C1 on the last two generations
>> of Intel Xeon platforms: Sky Lake, Cascade Lake, Cooper Lake, Ice Lake.
>> This
On Mon, 24 Jan 2022 12:07:42 +
Ayan Kumar Halder wrote:
Hi Ayan,
> Many thanks for your feedback. I have one clarification :-
>
> On 22/01/2022 01:30, Andre Przywara wrote:
> > On Thu, 20 Jan 2022 21:55:27 +
> > Ayan Kumar Halder wrote:
> >
> > Hi,
> >
> >> At the moment, Xen is
On 20.01.2022 16:23, Roger Pau Monne wrote:
> Both QEMU/KVM and HyperV support using bits 11:5 from the MSI address
> field in order to store the high part of the target APIC ID. This
> allows expanding the maximum APID ID usable without interrupt
> remapping support from 255 to 32768.
>
> Note
On Mon, Jan 24, 2022 at 10:07:54AM +0100, Roger Pau Monné wrote:
> On Fri, Jan 21, 2022 at 03:05:07PM +, James Dingwall wrote:
> > On Fri, Jan 21, 2022 at 03:00:29PM +0100, Roger Pau Monné wrote:
> > > On Fri, Jan 21, 2022 at 01:34:54PM +, James Dingwall wrote:
> > > > On 2022-01-13 16:11,
On 20.01.2022 16:23, Roger Pau Monne wrote:
> Such field uses bits 55:48, but for the purposes the register will be
> used use bits 55:49 instead. Bit 48 is used to signal an RTE entry is
> in remappable format which is not supported by the vIO-APIC.
Neither here nor in the cover letter you point
flight 167802 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167802/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167796
Hi Andre,
Many thanks for your feedback. I have one clarification :-
On 22/01/2022 01:30, Andre Przywara wrote:
On Thu, 20 Jan 2022 21:55:27 +
Ayan Kumar Halder wrote:
Hi,
At the moment, Xen is only handling data abort with valid syndrome (i.e.
ISV=0). Unfortunately, this doesn't cover
flight 167805 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167805/
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
flight 167804 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167804/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
In some cases, a particular mapcache entry may be mapped 256 times
causing the lock field to wrap to 0. For example, this may happen when
using emulated NVME and the guest submits a large scatter-gather write.
At this point, the entry map be remapped causing QEMU to write the wrong
data or crash
flight 167801 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167801/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167684
test-armhf-armhf-libvirt 16
Pass the block_device and operation that we plan to use this bio for to
bio_alloc to optimize the assignment. NULL/0 can be passed, both for the
passthrough case on a raw request_queue and to temporarily avoid
refactoring some nasty code.
Also move the gfp_mask argument after the nr_vecs
Pass the block_device that we plan to use this bio for and the
operation to bio_init to optimize the assignment. A NULL block_device
can be passed, both for the passthrough case on a raw request_queue and
to temporarily avoid refactoring some nasty code.
Signed-off-by: Christoph Hellwig
Pass the block_device and operation that we plan to use this bio for to
bio_alloc_bioset to optimize the assigment. NULL/0 can be passed, both
for the passthrough case on a raw request_queue and to temporarily avoid
refactoring some nasty code.
Also move the gfp_mask argument after the nr_vecs
Pass the block_device and operation that we plan to use this bio for to
bio_alloc_kiocb to optimize the assigment.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
---
block/bio.c | 12
block/fops.c| 17 -
include/linux/bio.h | 4
Pass the block_device that we plan to use this bio for and the
operation to bio_reset to optimize the assigment. A NULL block_device
can be passed, both for the passthrough case on a raw request_queue and
to temporarily avoid refactoring some nasty code.
Signed-off-by: Christoph Hellwig
From: Chaitanya Kulkarni
All callers need to set the block_device and operation, so lift that into
the common code.
Signed-off-by: Chaitanya Kulkarni
Signed-off-by: Christoph Hellwig
---
block/bio.c | 6 +-
block/blk-lib.c | 19 +--
Keep blk_next_bio next to the core bio infrastructure.
Signed-off-by: Christoph Hellwig
Reviewed-by: Chaitanya Kulkarni
---
block/bio.c | 13 +
block/blk-lib.c | 13 -
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index
Remove handling of NULL returns from sleeping bio_alloc calls given that
those can't fail.
Signed-off-by: Christoph Hellwig
---
drivers/block/xen-blkback/blkback.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
Just open code it next to the bio allocations, which saves a few lines
of code, prepares for future changes and allows to remove the duplicate
bi_opf assignment for the bio_clone_fast case in kcryptd_io_read.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-crypt.c | 21 -
Only the priv field of rnbd_dev_blk_io is used, so store the value of
that in bio->bi_private directly and remove the entire bio_set overhead.
Signed-off-by: Christoph Hellwig
---
drivers/block/rnbd/rnbd-srv-dev.c | 4 +---
drivers/block/rnbd/rnbd-srv-dev.h | 13 ++---
The memory mapped in process_rdma is contiguous, so there is no need
to loop over bio_add_page. Remove rnbd_bio_map_kern and just open code
the bio allocation and mapping in the caller.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jack Wang
Tested-by: Jack Wang
---
Remove handling of NULL returns from sleeping bio_alloc calls given that
those can't fail.
Signed-off-by: Christoph Hellwig
---
drivers/block/drbd/drbd_receiver.c | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/block/drbd/drbd_receiver.c
Use blkdev_issue_flush, which uses an on-stack bio instead of an
opencoded version with a bio embedded into struct pool.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-thin.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/md/dm-thin.c
Use blkdev_issue_flush, which uses an on-stack bio instead of an
opencoded version with a bio embedded into struct dm_snapshot.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-snap.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git
Remove handling of NULL returns from sleeping bio_alloc calls given that
those can't fail.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-crypt.c | 5 +
drivers/md/dm-log-writes.c | 18 --
drivers/md/dm-thin.c | 25 +
bio_alloc will never fail if it is allowed to sleep, so there is no
need for this loop. Also remove the __GFP_HIGH specifier as it doesn't
make sense here given that we'll always fall back to the mempool anyway.
Signed-off-by: Christoph Hellwig
---
fs/ntfs3/fsntfs.c | 23
bio_alloc will never fail when it can sleep. Remove the now simple
bl_alloc_init_bio helper and open code it in the only caller.
Signed-off-by: Christoph Hellwig
---
fs/nfs/blocklayout/blocklayout.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git
bio_alloc will never fail when it can sleep. Remove the now simple
nilfs_alloc_seg_bio helper and open code it in the only caller.
Signed-off-by: Christoph Hellwig
---
fs/nilfs2/segbuf.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git
Hi Jens,
this series is posted early because it has wide-ranging changes and could use
some
early ACKs before -rc1.
It changes the interface to the bio allocators to always pass a block_device and
the operation, which is information needed for every bio submitted through
bio_submit. This means
open code mpage_alloc in it's two callers and simplify the results
because of the context:
- __mpage_writepage always passes GFP_NOFS and can thus always sleep and
will never get a NULL return from bio_alloc at all.
- do_mpage_readpage can only get a non-sleeping context for readahead
On Fri, Jan 21, 2022 at 03:05:07PM +, James Dingwall wrote:
> On Fri, Jan 21, 2022 at 03:00:29PM +0100, Roger Pau Monné wrote:
> > On Fri, Jan 21, 2022 at 01:34:54PM +, James Dingwall wrote:
> > > On 2022-01-13 16:11, Roger Pau Monné wrote:
> > > > On Thu, Jan 13, 2022 at 11:19:46AM +,
On 23.01.2022 22:52, Hans van Kranenburg wrote:
> (To both the Debian bug # and xen-devel list, reply-all is fine)
> Hi Xen people,
>
> I just filed a bug at Debian on the binutils package, because since the
> latest binutils package update (Debian 2.37.50.20220106-2), Xen (both
> 4.14 and
Making adjustments to arbitrarily chosen values shouldn't require
auditing the code for possible derived numbers - such a change should
be doable in a single place, having an effect on all code depending on
that choice.
For one make the TDCR write actually use APIC_DIVISOR. With the
necessary
In TDT mode there's no point writing TDCR or TMICT, while outside of
that mode there's no need for the MFENCE.
No change intended to overall functioning.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1059,24 +1059,25 @@ static void
Use the original calibration against PIT only when the platform timer
is PIT. This implicitly excludes the "xen_guest" case from using the PIT
logic (init_pit() fails there, and as of 5e73b2594c54 ["x86/time: minor
adjustments to init_pit()"] using_pit also isn't being set too early
anymore), so
Calibration logic assumes that the platform timer (HPET or ACPI PM
timer) and the TSC are read at about the same time. This assumption may
not hold when a long latency event (e.g. SMI or NMI) occurs between the
two reads. Reduce the risk of reading uncorrelated values by doing at
least four pairs
... plus some tidying (or so I hope). Only the 1st patch was submitted
so far (i.e. as v1), all others are new.
1: time: further improve TSC / CPU freq calibration accuracy
2: APIC: calibrate against platform timer when possible
3: APIC: skip unnecessary parts of __setup_APIC_LVTT()
4: APIC: make
63 matches
Mail list logo
