Re: [PATCH v2 7/9] x86/p2m: pass old PTE directly to write_p2m_entry_pre() hook

At 10:38 +0100 on 06 Nov (1604659085), Jan Beulich wrote: > In no case is a pointer to non-const needed. Since no pointer arithmetic > is done by the sole user of the hook, passing in the PTE itself is quite > fine. > > While doing this adjustment also > - drop the intermediate

[xen-unstable test] 156524: regressions - FAIL

flight 156524 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/156524/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm 14 guest-start fail REGR. vs. 156443

Re: [PATCH 24/24] block: unexport revalidate_disk_size

Christoph Hellwig 于2020年11月6日 周五20:15写道： > revalidate_disk_size is not only called from set_capacity_and_notify, > so drop the export. s/not/now > > > Signed-off-by: Christoph Hellwig Thanks! Jack Wang > > --- > fs/block_dev.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git

[qemu-mainline test] 156522: regressions - FAIL

flight 156522 qemu-mainline real [real] flight 156535 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/156522/ http://logs.test-lab.xenproject.org/osstest/logs/156535/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not

Re: [PATCH] libxl: set vuart_gfn in libxl__build_hvm

On Fri, 6 Nov 2020, Wei Liu wrote: > On Fri, Nov 06, 2020 at 03:11:46PM +, Anthony PERARD wrote: > > On Thu, Nov 05, 2020 at 01:15:05PM -0800, Stefano Stabellini wrote: > > > libxl: set vuart_gfn in libxl__build_hvm > > > > The subject is written two times ;-) > > > > > Setting vuart_gfn was

[PATCH v2] x86/xen: don't unbind uninitialized lock_kicker_irq

When booting a hyperthreaded system with the kernel parameter 'mitigations=auto,nosmt', the following warning occurs: WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112 unbind_from_irqhandler+0x4e/0x60 ... Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006 ...

Re: [PATCH] x86/xen: fix warning when running with nosmt mitigations

On 11/5/20 7:47 PM, Brian Masney wrote: > On Thu, Nov 05, 2020 at 07:35:29PM -0500, Brian Masney wrote: >> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c >> index 799f4eba0a62..4a052459a08e 100644 >> --- a/arch/x86/xen/spinlock.c >> +++ b/arch/x86/xen/spinlock.c >> @@ -93,9

Re: [PATCH 22/24] md: remove a spurious call to revalidate_disk_size in update_size

On Fri, Nov 6, 2020 at 11:04 AM Christoph Hellwig wrote: > > None of the ->resize methods updates the disk size, so calling > revalidate_disk_size here won't do anything. > > Signed-off-by: Christoph Hellwig Acked-by: Song Liu > --- > drivers/md/md-cluster.c | 2 -- > 1 file changed, 2

[xen-4.12-testing test] 156515: tolerable FAIL - PUSHED

flight 156515 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/156515/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qcow2 18 guest-saverestore.2 fail in 156423 pass in 156515 test-armhf-armhf-libvirt

Re: [PATCH 21/24] md: use set_capacity_and_notify

On Fri, Nov 6, 2020 at 11:04 AM Christoph Hellwig wrote: > > Use set_capacity_and_notify to set the size of both the disk and block > device. This also gets the uevent notifications for the resize for free. > > Signed-off-by: Christoph Hellwig Acked-by: Song Liu

Re: preparations for 4.14.1

On Fri, 6 Nov 2020, Jan Beulich wrote: > On 06.11.2020 02:58, Stefano Stabellini wrote: > > On Wed, 4 Nov 2020, Jan Beulich wrote: > >> the release is due in a couple of weeks time. Please point out > >> backports you find missing from the respective staging branch, > >> but which you consider

[xen-unstable-smoke test] 156532: tolerable all pass - PUSHED

flight 156532 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/156532/ 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

[PATCH 10/24] nbd: validate the block size in nbd_set_size

Move the validation of the block from the callers into nbd_set_size. Signed-off-by: Christoph Hellwig --- drivers/block/nbd.c | 47 +++-- 1 file changed, 15 insertions(+), 32 deletions(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index

[PATCH 14/24] pktcdvd: use set_capacity_and_notify

Use set_capacity_and_notify to set the size of both the disk and block device. This also gets the uevent notifications for the resize for free. Signed-off-by: Christoph Hellwig --- drivers/block/pktcdvd.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 24/24] block: unexport revalidate_disk_size

revalidate_disk_size is not only called from set_capacity_and_notify, so drop the export. Signed-off-by: Christoph Hellwig --- fs/block_dev.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index 66ebf594c97f47..d8664f5c1ff669 100644 --- a/fs/block_dev.c +++

[PATCH 15/24] nvme: use set_capacity_and_notify in nvme_set_queue_dying

Use the block layer helper to update both the disk and block device sizes. Contrary to the name no notification is sent in this case, as a size 0 is special cased. Signed-off-by: Christoph Hellwig --- drivers/nvme/host/core.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-)

[PATCH 09/24] nbd: refactor size updates

Merge nbd_size_set and nbd_size_update into a single function that also updates the nbd_config fields. This new function takes the device size in bytes as the first argument, and the blocksize as the second argument, simplifying the calculations required in most callers. Signed-off-by: Christoph

[PATCH 20/24] dm-raid: use set_capacity_and_notify

Use set_capacity_and_notify to set the size of both the disk and block device. This also gets the uevent notifications for the resize for free. Signed-off-by: Christoph Hellwig --- drivers/md/dm-raid.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/md/dm-raid.c

[PATCH 13/24] dm: use set_capacity_and_notify

Use set_capacity_and_notify to set the size of both the disk and block device. This also gets the uevent notifications for the resize for free. Signed-off-by: Christoph Hellwig --- drivers/md/dm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/md/dm.c

[PATCH 22/24] md: remove a spurious call to revalidate_disk_size in update_size

None of the ->resize methods updates the disk size, so calling revalidate_disk_size here won't do anything. Signed-off-by: Christoph Hellwig --- drivers/md/md-cluster.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c index

[PATCH 18/24] rnbd: use set_capacity_and_notify

Use set_capacity_and_notify to set the size of both the disk and block device. This also gets the uevent notifications for the resize for free. Signed-off-by: Christoph Hellwig --- drivers/block/rnbd/rnbd-clt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 21/24] md: use set_capacity_and_notify

Use set_capacity_and_notify to set the size of both the disk and block device. This also gets the uevent notifications for the resize for free. Signed-off-by: Christoph Hellwig --- drivers/md/md-cluster.c | 6 ++ drivers/md/md-linear.c | 3 +-- drivers/md/md.c | 24

[PATCH 23/24] virtio-blk: remove a spurious call to revalidate_disk_size

revalidate_disk_size just updates the block device size from the disk size. Thus calling it from revalidate_disk_size doesn't actually do anything. Signed-off-by: Christoph Hellwig --- drivers/block/virtio_blk.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/block/virtio_blk.c

[PATCH 16/24] drbd: use set_capacity_and_notify

Use set_capacity_and_notify to set the size of both the disk and block device. This also gets the uevent notifications for the resize for free. Signed-off-by: Christoph Hellwig --- drivers/block/drbd/drbd_main.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH 12/24] aoe: don't call set_capacity from irq context

Updating the block device size from irq context can lead to torn writes of the 64-bit value, and prevents us from using normal process context locking primitives to serialize access to the 64-bit nr_sectors value. Defer the set_capacity to the already existing workqueue handler, where it can be

[PATCH 11/24] nbd: use set_capacity_and_notify

Use set_capacity_and_notify to update the disk and block device sizes and send a RESIZE uevent to userspace. Note that blktests relies on uevents being sent also for updates that did not change the device size, so the explicit kobject_uevent remains for that case. Signed-off-by: Christoph

[PATCH 19/24] zram: use set_capacity_and_notify

Use set_capacity_and_notify to set the size of both the disk and block device. This also gets the uevent notifications for the resize for free. Signed-off-by: Christoph Hellwig --- drivers/block/zram/zram_drv.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git

[PATCH 17/24] rbd: use set_capacity_and_notify

Use set_capacity_and_notify to set the size of both the disk and block device. This also gets the uevent notifications for the resize for free. Signed-off-by: Christoph Hellwig --- drivers/block/rbd.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/rbd.c

[PATCH 07/24] nbd: remove the call to set_blocksize

Block driver have no business setting the file system concept of a block size. Signed-off-by: Christoph Hellwig --- drivers/block/nbd.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index c4f9ccf5cc2ac5..f618688a196654

[PATCH 08/24] nbd: move the task_recv check into nbd_size_update

nbd_size_update is about to acquire a few more callers, so lift the check into the function. Signed-off-by: Christoph Hellwig --- drivers/block/nbd.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index

[PATCH 06/24] block: add a return value to set_capacity_and_notify

Return if the function ended up sending an uevent or not. Signed-off-by: Christoph Hellwig --- block/genhd.c | 7 +-- include/linux/genhd.h | 2 +- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/block/genhd.c b/block/genhd.c index d8d9d6c1c916e1..8c350fecfe8bfe

[PATCH 04/24] sd: update the bdev size in sd_revalidate_disk

This avoids the extra call to revalidate_disk_size in sd_rescan and is otherwise a no-op because the size did not change, or we are in the probe path. Signed-off-by: Christoph Hellwig --- drivers/scsi/sd.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

[PATCH 03/24] nvme: let set_capacity_revalidate_and_notify update the bdev size

There is no good reason to call revalidate_disk_size separately. Signed-off-by: Christoph Hellwig --- drivers/nvme/host/core.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 376096bfc54a83..4e86c9aafd88a7 100644

[PATCH 05/24] block: remove the update_bdev parameter from set_capacity_revalidate_and_notify

The update_bdev argument is always set to true, so remove it. Also rename the function to the slighly less verbose set_capacity_and_notify, as propagating the disk size to the block device isn't really revalidation. Signed-off-by: Christoph Hellwig --- block/genhd.c| 13

[PATCH 01/24] block: remove the call to __invalidate_device in check_disk_size_change

__invalidate_device without the kill_dirty parameter just invalidates various clean entries in caches, which doesn't really help us with anything, but can cause all kinds of horrible lock orders due to how it calls into the file system. The only reason this hasn't been a major issue is because so

[PATCH 02/24] loop: remove loop_set_size

Just use set_capacity_revalidate_and_notify directly, as this function can update the block device size as well when the last parameter is set to true. Signed-off-by: Christoph Hellwig --- drivers/block/loop.c | 37 +++-- 1 file changed, 7 insertions(+), 30

cleanup updating the size of block devices

Hi Jens, this series builds on top of the work that went into the last merge window, and make sure we have a single coherent interfac for updating the size of a block device. Diffstat: block/genhd.c | 16 +++ drivers/block/aoe/aoecmd.c | 15 +-

[linux-linus test] 156462: regressions - FAIL

flight 156462 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/156462/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332

[ovmf test] 156467: all pass - PUSHED

flight 156467 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/156467/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 09af9bd9be2d3e31bba979f8cf6446017b0b863e baseline version: ovmf

Re: [PATCH v1] tools: add readv_exact to xenctrl

On Wed, Oct 28, 2020 at 03:41:51PM +0100, Olaf Hering wrote: > Read a batch of iovec's. > > In the common case of short reads, finish individual iov's with read_exact. > > Signed-off-by: Olaf Hering I see your series, so I will drop this one and go over that series instead. Wei.

Re: [PATCH] libxl: set vuart_gfn in libxl__build_hvm

On Fri, Nov 06, 2020 at 03:11:46PM +, Anthony PERARD wrote: > On Thu, Nov 05, 2020 at 01:15:05PM -0800, Stefano Stabellini wrote: > > libxl: set vuart_gfn in libxl__build_hvm > > The subject is written two times ;-) > > > Setting vuart_gfn was missed when switching ARM guests to the PVH

[libvirt test] 156509: regressions - FAIL

flight 156509 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/156509/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt

Re: [PATCH] libxg: don't use max policy in xc_cpuid_xend_policy()

On Thu, Nov 05, 2020 at 04:56:53PM +0100, Jan Beulich wrote: > Using max undermines the separation between default and max. For example, > turning off AVX512F on an MPX-capable system silently turns on MPX, > despite this not being part of the default policy anymore. Since the > information is

[xen-4.14-testing test] 156460: regressions - FAIL

flight 156460 xen-4.14-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/156460/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-build fail in 156404 REGR. vs. 156394 Tests which

Re: [PATCH v1] docs/xl: fix cpupool-cpu-remove

On Fri, Nov 06, 2020 at 02:05:17PM +0100, Olaf Hering wrote: > The cpu-pool must be specified. > > Signed-off-by: Olaf Hering Acked-by: Wei Liu

Re: [PATCH] tools/libs/light: correct bitmap operations

On Fri, Nov 06, 2020 at 03:05:04PM +0100, Juergen Gross wrote: > Libxl bitmap operations for single bits (test, set, reset) take the bit > number as a signed integer without testing the value to be larger than > 0. > > Correct that by adding the appropriate tests. > > Signed-off-by: Juergen

Re: Xen 4.13.2 released

> On Nov 6, 2020, at 3:49 PM, Anthony PERARD wrote: > > On Wed, Nov 04, 2020 at 08:47:57AM +0100, Jan Beulich wrote: >> On 04.11.2020 00:55, Michael Young wrote: >>> On Tue, 3 Nov 2020, Jan Beulich wrote: I am pleased to announce the release of Xen 4.13.2. This is available

Re: [PATCH] tools/libs/light: correct bitmap operations

On 06.11.2020 15:36, Jürgen Groß wrote: > On 06.11.20 15:35, Jan Beulich wrote: >> On 06.11.2020 15:05, Juergen Gross wrote: >>> Libxl bitmap operations for single bits (test, set, reset) take the bit >>> number as a signed integer without testing the value to be larger than >>> 0. >>> >>> Correct

Re: [PATCH] libxl: set vuart_gfn in libxl__build_hvm

On Thu, Nov 05, 2020 at 01:15:05PM -0800, Stefano Stabellini wrote: > libxl: set vuart_gfn in libxl__build_hvm The subject is written two times ;-) > Setting vuart_gfn was missed when switching ARM guests to the PVH build. > Like libxl__build_pv, libxl__build_hvm should set state->vuart_gfn to >

Re: [XEN PATCH v1] xen/arm : Add support for SMMUv3 driver

Hello Oleksandr, > On 6 Nov 2020, at 2:22 pm, Oleksandr Andrushchenko > wrote: > > Hi, Rahul! > > On 11/6/20 3:58 PM, Rahul Singh wrote: >> Hello Oleksandr, >> >>> On 6 Nov 2020, at 1:00 pm, Oleksandr Andrushchenko >>> wrote: >>> >>> Hello, Rahul! >>> >>> On 11/6/20 2:48 PM, Rahul Singh

Re: [PATCH] tools/libs/light: correct bitmap operations

On 06/11/2020 14:35, Jan Beulich wrote: > On 06.11.2020 15:05, Juergen Gross wrote: >> Libxl bitmap operations for single bits (test, set, reset) take the bit >> number as a signed integer without testing the value to be larger than >> 0. >> >> Correct that by adding the appropriate tests. >> >>

Re: [PATCH] tools/libs/light: correct bitmap operations

On 06.11.20 15:35, Jan Beulich wrote: On 06.11.2020 15:05, Juergen Gross wrote: Libxl bitmap operations for single bits (test, set, reset) take the bit number as a signed integer without testing the value to be larger than 0. Correct that by adding the appropriate tests. Signed-off-by:

Re: [PATCH] tools/libs/light: correct bitmap operations

On 06.11.2020 15:05, Juergen Gross wrote: > Libxl bitmap operations for single bits (test, set, reset) take the bit > number as a signed integer without testing the value to be larger than > 0. > > Correct that by adding the appropriate tests. > > Signed-off-by: Juergen Gross Wouldn't it be

Re: [XEN PATCH v1] xen/arm : Add support for SMMUv3 driver

Hi, Rahul! On 11/6/20 3:58 PM, Rahul Singh wrote: > Hello Oleksandr, > >> On 6 Nov 2020, at 1:00 pm, Oleksandr Andrushchenko >> wrote: >> >> Hello, Rahul! >> >> On 11/6/20 2:48 PM, Rahul Singh wrote: >>> Hello Oleksandr, >>> On 2 Nov 2020, at 10:12 am, Oleksandr Andrushchenko wrote:

[xen-unstable test] 156443: tolerable FAIL

flight 156443 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/156443/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 156401

[PATCH] tools/libs/light: correct bitmap operations

Libxl bitmap operations for single bits (test, set, reset) take the bit number as a signed integer without testing the value to be larger than 0. Correct that by adding the appropriate tests. Signed-off-by: Juergen Gross --- tools/libs/light/libxl_utils.c | 6 +++--- 1 file changed, 3

Re: [XEN PATCH v1] xen/arm : Add support for SMMUv3 driver

Hello Oleksandr, > On 6 Nov 2020, at 1:00 pm, Oleksandr Andrushchenko > wrote: > > Hello, Rahul! > > On 11/6/20 2:48 PM, Rahul Singh wrote: >> Hello Oleksandr, >> >>> On 2 Nov 2020, at 10:12 am, Oleksandr Andrushchenko >>> wrote: >>> >>> Hi, >>> >>> On 11/2/20 11:55 AM, Bertrand Marquis

Re: [PATCH v2 2/4] xen/pci: Introduce new CONFIG_PCI_ATS flag for PCI ATS functionality.

Hi, On 06/11/2020 12:48, Jan Beulich wrote: On 06.11.2020 12:43, Rahul Singh wrote: Hello Jan, On 4 Nov 2020, at 3:49 pm, Jan Beulich wrote: On 04.11.2020 16:43, Jan Beulich wrote: On 03.11.2020 16:59, Rahul Singh wrote: --- a/xen/drivers/pci/Kconfig +++ b/xen/drivers/pci/Kconfig @@ -1,3

[PATCH v1] docs/xl: fix cpupool-cpu-remove

The cpu-pool must be specified. Signed-off-by: Olaf Hering --- docs/man/xl.1.pod.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in index d0f50f0b4a..2f576a25e3 100644 --- a/docs/man/xl.1.pod.in +++ b/docs/man/xl.1.pod.in @@

Re: [XEN PATCH v1] xen/arm : Add support for SMMUv3 driver

Hello, Rahul! On 11/6/20 2:48 PM, Rahul Singh wrote: > Hello Oleksandr, > >> On 2 Nov 2020, at 10:12 am, Oleksandr Andrushchenko >> wrote: >> >> Hi, >> >> On 11/2/20 11:55 AM, Bertrand Marquis wrote: >>> Hi, >>> On 2 Nov 2020, at 05:55, Oleksandr Andrushchenko wrote: Hi,

Re: [XEN PATCH v1] xen/arm : Add support for SMMUv3 driver

Hello Oleksandr, > On 2 Nov 2020, at 10:12 am, Oleksandr Andrushchenko > wrote: > > Hi, > > On 11/2/20 11:55 AM, Bertrand Marquis wrote: >> Hi, >> >>> On 2 Nov 2020, at 05:55, Oleksandr Andrushchenko wrote: >>> >>> Hi, Julien! >>> >>> On 10/30/20 7:18 PM, Julien Grall wrote: Hi

Re: [PATCH v2 2/4] xen/pci: Introduce new CONFIG_PCI_ATS flag for PCI ATS functionality.

On 06.11.2020 12:43, Rahul Singh wrote: > Hello Jan, > >> On 4 Nov 2020, at 3:49 pm, Jan Beulich wrote: >> >> On 04.11.2020 16:43, Jan Beulich wrote: >>> On 03.11.2020 16:59, Rahul Singh wrote: --- a/xen/drivers/pci/Kconfig +++ b/xen/drivers/pci/Kconfig @@ -1,3 +1,12 @@

[xen-unstable-smoke test] 156523: tolerable all pass - PUSHED

flight 156523 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/156523/ 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

Re: [PATCH v2 2/4] xen/pci: Introduce new CONFIG_PCI_ATS flag for PCI ATS functionality.

Hello Jan, > On 4 Nov 2020, at 3:49 pm, Jan Beulich wrote: > > On 04.11.2020 16:43, Jan Beulich wrote: >> On 03.11.2020 16:59, Rahul Singh wrote: >>> --- a/xen/drivers/pci/Kconfig >>> +++ b/xen/drivers/pci/Kconfig >>> @@ -1,3 +1,12 @@ >>> >>> config HAS_PCI >>> bool >>> + >>> +config

Re: [PATCH v2 4/4] xen/pci: solve compilation error on ARM with HAS_PCI enabled.

Hello Jan, > On 6 Nov 2020, at 9:21 am, Jan Beulich wrote: > > On 03.11.2020 16:59, Rahul Singh wrote: >> If mem-sharing, mem-paging and log-dirty functionality is not enabled >> for architecture when HAS_PCI is enabled, compiler will throw an error. > > Nit: Is it really "and", not "or”? Ok

Re: [RFC PATCH 4/6] xen/arm64: Port Linux LL/SC and LSE atomics helpers to Xen

Hey Julien, > > First of all, thank you for taking a stab at adding LSE support in > Xen! No problem! >> >> In retrospect I should have put an intermediate patch between #3 and >> #4, deleting the existing headers. This would have made the patch >> diff for #4 and #5 much easier to read seeing

Re: [RFC PATCH 4/6] xen/arm64: Port Linux LL/SC and LSE atomics helpers to Xen

On 06/11/2020 10:55, Ash Wilding wrote: Hi, Hi Ash, First of all, thank you for taking a stab at adding LSE support in Xen! In retrospect I should have put an intermediate patch between #3 and #4, deleting the existing headers. This would have made the patch diff for #4 and #5 much

RE: [RFC PATCH 4/6] xen/arm64: Port Linux LL/SC and LSE atomics helpers to Xen

Hi, In retrospect I should have put an intermediate patch between #3 and #4, deleting the existing headers. This would have made the patch diff for #4 and #5 much easier to read seeing as they are copying the Linux versions wholesale into Xen. I'll do that for V1 when we get there, but for now

RE: [RFC PATCH 5/6] xen/arm32: Port Linux LL/SC atomics helpers to Xen

Hi, As mentioned in my reply to patch #4 just now, in retrospect I should have put an intermediate patch between #3 and #4, deleting the existing headers. This would have made the patch diff for #4 and #5 much easier to read seeing as they are copying the Linux versions into Xen. I'll do that

Re: [RFC PATCH 12/15] stubs/xen-hw-stub: drop xenstore_store_pv_console_info stub

Philippe Mathieu-Daudé writes: > On 11/5/20 6:51 PM, Alex Bennée wrote: >> We should never build something that calls this without having it. > > "because ..."? xen-all.c is only built when we have CONFIG_XEN which also gates the only call-site in xen-console.c > > Reviewed-by: Philippe

Re: [PATCH v2 3/4] xen/pci: Move x86 specific code to x86 directory.

Hello Jan, > On 6 Nov 2020, at 9:09 am, Jan Beulich wrote: > > On 03.11.2020 16:59, Rahul Singh wrote: >> --- a/xen/drivers/passthrough/pci.c >> +++ b/xen/drivers/passthrough/pci.c >> @@ -14,7 +14,6 @@ >> * this program; If not, see . >> */ >> >> -#include

[PATCH v2 9/9] x86/shadow: adjust TLB flushing in sh_unshadow_for_p2m_change()

Accumulating transient state of d->dirty_cpumask in a local variable is unnecessary here: The flush is fine to make with the dirty set at the time of the call. With this, move the invocation to a central place at the end of the function. Signed-off-by: Jan Beulich --- v2: New. ---

[PATCH v2 8/9] x86/shadow: cosmetics to sh_unshadow_for_p2m_change()

Besides the adjustments for style - use switch(), - widen scope of commonly used variables, - narrow scope of other variables. Signed-off-by: Jan Beulich --- v2: New. --- a/xen/arch/x86/mm/shadow/common.c +++ b/xen/arch/x86/mm/shadow/common.c @@ -3081,7 +3081,9 @@ static void

[PATCH v2 7/9] x86/p2m: pass old PTE directly to write_p2m_entry_pre() hook

In no case is a pointer to non-const needed. Since no pointer arithmetic is done by the sole user of the hook, passing in the PTE itself is quite fine. While doing this adjustment also - drop the intermediate sh_write_p2m_entry_pre(): sh_unshadow_for_p2m_change() can itself be used as the hook

[PATCH v2 6/9] x86/p2m: avoid unnecessary calls of write_p2m_entry_pre() hook

When shattering a large page, we first construct the new page table page and only then hook it up. The "pre" hook in this case does nothing, for the page starting out all blank. Avoid 512 calls into shadow code in this case by passing in INVALID_GFN, indicating the page being updated is (not yet)

[PATCH v2 5/9] x86/p2m: split write_p2m_entry() hook

Fair parts of the present handlers are identical; in fact nestedp2m_write_p2m_entry() lacks a call to p2m_entry_modify(). Move common parts right into write_p2m_entry(), splitting the hooks into a "pre" one (needed just by shadow code) and a "post" one. For the common parts moved I think that the

[PATCH v2 4/9] x86/HAP: move nested-P2M flush calculations out of locked region

By latching the old MFN into a local variable, these calculations don't depend on anything but local variables anymore. Hence the point in time when they get performed doesn't matter anymore, so they can be moved past the locked region. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/hap/hap.c

[PATCH v2 3/9] x86/p2m: suppress audit_p2m hook when possible

When P2M_AUDIT is false, it's unused, so instead of having a dangling NULL pointer sit there, omit the field altogether. Instead of adding "#if P2M_AUDIT && defined(CONFIG_HVM)" in even more places, fold the latter part right into the definition of P2M_AUDIT. Signed-off-by: Jan Beulich --- v2:

[PATCH v2 2/9] x86/p2m: collapse the two ->write_p2m_entry() hooks

The struct paging_mode instances get set to the same functions regardless of mode by both HAP and shadow code, hence there's no point having this hook there. The hook also doesn't need moving elsewhere - we can directly use struct p2m_domain's. This merely requires (from a strictly formal pov; in

[PATCH v2 1/9] x86/p2m: paging_write_p2m_entry() is a private function

As it gets installed by p2m_pt_init(), it doesn't need to live in paging.c. The function working in terms of l1_pgentry_t even further indicates its non-paging-generic nature. Move it and drop its paging_ prefix, not adding any new one now that it's static. This then also makes more obvious that

[PATCH v2 0/9] x86/p2m: hook adjustments

This started out with me getting confused by the two write_p2m_entry() hooks we have - there really ought to be no more than one, or if two were absolutely needed they imo would better have distinct names. Other adjustment opportunities (and I hope they're improvements) were found while getting

[qemu-mainline test] 156424: regressions - FAIL

flight 156424 qemu-mainline real [real] flight 156521 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/156424/ http://logs.test-lab.xenproject.org/osstest/logs/156521/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not

Re: [PATCH v2 4/4] xen/pci: solve compilation error on ARM with HAS_PCI enabled.

On 03.11.2020 16:59, Rahul Singh wrote: > If mem-sharing, mem-paging and log-dirty functionality is not enabled > for architecture when HAS_PCI is enabled, compiler will throw an error. Nit: Is it really "and", not "or"? > @@ -1418,12 +1417,7 @@ static int assign_device(struct domain *d, u16

Re: [PATCH v2 3/4] xen/pci: Move x86 specific code to x86 directory.

On 03.11.2020 16:59, Rahul Singh wrote: > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -14,7 +14,6 @@ > * this program; If not, see . > */ > > -#include > #include > #include > #include I think this hunk wants dropping -

Re: preparations for 4.14.1

On 06.11.2020 09:45, Julien Grall wrote: > On 04/11/2020 10:12, Jan Beulich wrote: >> the release is due in a couple of weeks time. Please point out >> backports you find missing from the respective staging branch, >> but which you consider relevant. (Ian: Please double check >> there are indeed

Re: preparations for 4.14.1

On 04/11/2020 10:12, Jan Beulich wrote: All, Hi Jan, the release is due in a couple of weeks time. Please point out backports you find missing from the respective staging branch, but which you consider relevant. (Ian: Please double check there are indeed no tools side backports needed

Re: [PATCH v2 2/4] xen/pci: Introduce new CONFIG_PCI_ATS flag for PCI ATS functionality.

On 05.11.2020 22:04, Stefano Stabellini wrote: > On Wed, 4 Nov 2020, Jan Beulich wrote: >> On 04.11.2020 16:43, Jan Beulich wrote: >>> On 03.11.2020 16:59, Rahul Singh wrote: --- a/xen/drivers/pci/Kconfig +++ b/xen/drivers/pci/Kconfig @@ -1,3 +1,12 @@ config HAS_PCI