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

[Tim Deegan]

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 sh_write_p2m_entry_pre():
>   sh_unshadow_for_p2m_change() can itself be used as the hook function,
>   moving the conditional into there,
> - introduce a local variable holding the flags of the old entry.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Tim Deegan 

[xen-unstable test] 156524: regressions - FAIL

[osstest service owner]

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
 test-amd64-i386-libvirt-xsm  14 guest-start  fail REGR. vs. 156443
 test-amd64-amd64-libvirt-xsm 14 guest-start  fail REGR. vs. 156443
 test-amd64-amd64-xl-xsm  14 guest-start  fail REGR. vs. 156443
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install 
fail REGR. vs. 156443
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install 
fail REGR. vs. 156443
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 156443
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 156443
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 debian-hvm-install fail 
REGR. vs. 156443
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 156443
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 156443
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 156443

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 156443
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 156443
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 156443
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 156443
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 156443
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 156443
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 156443
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 156443
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 156443
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 156443
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 156443
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  

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

[Jack Wang]

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 a/fs/block_dev.c b/fs/block_dev.c
> index 66ebf594c97f47..d8664f5c1ff669 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -1362,7 +1362,6 @@ void revalidate_disk_size(struct gendisk *disk, bool
> verbose)
> bdput(bdev);
> }
>  }
> -EXPORT_SYMBOL(revalidate_disk_size);
>
>  void bd_set_nr_sectors(struct block_device *bdev, sector_t sectors)
>  {
> --
> 2.28.0
>
>
> ___
> Linux-nvme mailing list
> linux-n...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>

[qemu-mainline test] 156522: regressions - FAIL

[osstest service owner]

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 be run:
 test-arm64-arm64-libvirt-xsm 14 guest-start  fail REGR. vs. 152631
 test-armhf-armhf-xl-vhd  12 debian-di-installfail REGR. vs. 152631
 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 152631
 test-amd64-amd64-xl-qcow2   21 guest-start/debian.repeat fail REGR. vs. 152631
 test-armhf-armhf-libvirt 14 guest-start  fail REGR. vs. 152631

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu326c9a0eb67672f3d7515fe41e9deaa58fb15227
baseline version:
 qemuu1d806cef0e38b5db8347a8e12f214d543204a314

Last test of basis   152631  2020-08-20 09:07:46 Z   78 days
Failing since152659  2020-08-21 14:07:39 Z   77 days  172 attempts
Testing same since   156522  2020-11-06 09:30:32 Z0 days1 attempts


People who touched revisions under test:
Aaron Lindsay 
  Alberto Garcia 
  Aleksandar Markovic 
  Alex Bennée 
  Alex Chen 
  Alex Williamson 
  Alexander Bulekov 
  AlexChen 
  Alexey Kirillov 
  Alistair Francis 
  Alistair Francis 
  Amey Narkhede 
  Ana Pazos 
  Andreas Gustafsson 
  Andrew Jones 
  Andrey Konovalov 
  Andrey Shinkevich 
  Ani Sinha 
  Anthony PERARD 
  Anton Blanchard 
  Anup Patel 
  Artyom Tarasenko 
  Babu Moger 
  BALATON Zoltan 
  Bastian Koppelmann 
  Ben Widawsky 
  Bharat Bhushan 
  Bihong Yu 
  Bin Meng 
  Bruce Rogers 
  

Re: [PATCH] libxl: set vuart_gfn in libxl__build_hvm

[Stefano Stabellini]

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 missed when switching ARM guests to the PVH build.
> > > Like libxl__build_pv, libxl__build_hvm should set state->vuart_gfn to
> > > dom->vuart_gfn.
> > > 
> > > Without this change, xl console cannot connect to the vuart console (-t
> > > vuart), see https://marc.info/?l=xen-devel=160402342101366.
> > > 
> > > Signed-off-by: Stefano Stabellini 
> > > 
> > > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > > index f8661e90d4..36fe8915e7 100644
> > > --- a/tools/libxl/libxl_dom.c
> > > +++ b/tools/libxl/libxl_dom.c
> > > @@ -1184,6 +1184,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> > >  LOG(ERROR, "hvm build set params failed");
> > >  goto out;
> > >  }
> > > +state->vuart_gfn = dom->vuart_gfn;
> > >  
> > >  rc = hvm_build_set_xs_values(gc, domid, dom, info);
> > >  if (rc != 0) {
> > 
> > Reviewed-by: Anthony PERARD 
> 
> This patch is based on an old tree. I have ported it to staging. Please
> check the code and shout if it is not done correctly.

all good, thanks!

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

[Brian Masney]

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
...
Call Trace:
 xen_uninit_lock_cpu+0x28/0x62
 xen_hvm_cpu_die+0x21/0x30
 takedown_cpu+0x9c/0xe0
 ? trace_suspend_resume+0x60/0x60
 cpuhp_invoke_callback+0x9a/0x530
 _cpu_up+0x11a/0x130
 cpu_up+0x7e/0xc0
 bringup_nonboot_cpus+0x48/0x50
 smp_init+0x26/0x79
 kernel_init_freeable+0xea/0x229
 ? rest_init+0xaa/0xaa
 kernel_init+0xa/0x106
 ret_from_fork+0x35/0x40

The secondary CPUs are not activated with the nosmt mitigations and only
the primary thread on each CPU core is used. In this situation,
xen_hvm_smp_prepare_cpus(), and more importantly xen_init_lock_cpu(), is
not called, so the lock_kicker_irq is not initialized for the secondary
CPUs. Let's fix this by exiting early in xen_uninit_lock_cpu() if the
irq is not set to avoid the warning from above for each secondary CPU.

Signed-off-by: Brian Masney 
---
Changes since v1:
- Remove duplicate per_cpu() call and pass in irq variable.
- Changed subject from 'x86/xen: fix warning when running with nosmt
  mitigations'
- Shorten code comment

 arch/x86/xen/spinlock.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 799f4eba0a62..043c73dfd2c9 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -93,10 +93,20 @@ void xen_init_lock_cpu(int cpu)
 
 void xen_uninit_lock_cpu(int cpu)
 {
+   int irq;
+
if (!xen_pvspin)
return;
 
-   unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL);
+   /*
+* When booting the kernel with 'mitigations=auto,nosmt', the secondary
+* CPUs are not activated, and lock_kicker_irq is not initialized.
+*/
+   irq = per_cpu(lock_kicker_irq, cpu);
+   if (irq == -1)
+   return;
+
+   unbind_from_irqhandler(irq, NULL);
per_cpu(lock_kicker_irq, cpu) = -1;
kfree(per_cpu(irq_name, cpu));
per_cpu(irq_name, cpu) = NULL;
-- 
2.26.2

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

[boris . ostrovsky]

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 +93,24 @@ void xen_init_lock_cpu(int cpu)
>>  
>>  void xen_uninit_lock_cpu(int cpu)
>>  {
>> +int irq;
>> +
>>  if (!xen_pvspin)
>>  return;
>>  
>> +/*
>> + * When booting the kernel with 'mitigations=auto,nosmt', the secondary
>> + * CPUs are not activated and only the primary thread on each CPU core
>> + * is used. In this situation, xen_hvm_smp_prepare_cpus(), and more
>> + * importantly xen_init_lock_cpu(), is not called, so the
>> + * lock_kicker_irq is not initialized for the secondary CPUs. Let's
>> + * exit early if the irq is not set to avoid a warning in the console
>> + * log.
>> + */
>> +irq = per_cpu(lock_kicker_irq, cpu);
>> +if (irq == -1)
>> +return;
>> +
>>  unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL);
> As soon as I saw this on lore, I saw that I should have passed the irq
> variable to unbind_from_irqhandler() rather than doing another per_cpu()
> lookup. I'll wait for feedback about the general approach before posting
> a v2.


This looks good. I'd shorten the comment though: your commit message already 
describes the scenario. And change the subject to something like "Don't unbind 
uninitialized lock_kicker_irq".


-boris

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

[Song Liu]

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 deletions(-)
>
> diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
> index 87442dc59f6ca3..35e2690c1803dd 100644
> --- a/drivers/md/md-cluster.c
> +++ b/drivers/md/md-cluster.c
> @@ -1299,8 +1299,6 @@ static void update_size(struct mddev *mddev, sector_t 
> old_dev_sectors)
> } else {
> /* revert to previous sectors */
> ret = mddev->pers->resize(mddev, old_dev_sectors);
> -   if (!ret)
> -   revalidate_disk_size(mddev->gendisk, true);
> ret = __sendmsg(cinfo, );
> if (ret)
> pr_err("%s:%d: failed to send METADATA_UPDATED msg\n",
> --
> 2.28.0
>

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

[osstest service owner]

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  8 xen-boot fail in 156423 pass in 156515
 test-arm64-arm64-xl-thunderx  8 xen-boot   fail pass in 156423
 test-amd64-amd64-xl-credit2  20 guest-localmigrate/x10 fail pass in 156423
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 156423

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-thunderx 15 migrate-support-check fail in 156423 never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail in 156423 never 
pass
 test-amd64-amd64-xl-qcow219 guest-localmigrate/x10   fail  like 156358
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 156358
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 156358
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 156358
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 156358
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 156358
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 156358
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 156358
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 156358
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 156358
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 156358
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 156358
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass

version targeted for testing:
 xen  4f9294d21c47415376215d68a0298e88582b8e7a
baseline version:
 xen  

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

[Song Liu]

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

[Stefano Stabellini]

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 relevant. (Ian: Please double check
> >> there are indeed no tools side backports needed here.)
> >>
> >> Julien, Stefano, on the Arm side I'd like to ask for
> >>
> >> 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics 
> >> helpers
> >>
> >> just like I did when sending the respective 4.13.2 / 4.12.4
> >> mail. Is there a particular reason it wasn't put in?
> > 
> > No, I have just backported 5d45ecabe3c0 and a couple of other fixes.
> 
> Thanks.
> 
> > Jan, do you think we should backport the following also?
> > 
> > 8856a914b build: also check for empty .bss.* in .o -> .init.o conversion
> 
> Not having it wasn't causing active problems afaict, so it
> was more to prevent future issues to put it in place. Did
> we gain dependencies on this change which want backporting?

No that's OK. I was just wondering if it was fixing something important
enough to backport. I think we are good on my side then.

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

[osstest service owner]

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  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
baseline version:
 xen  2a5f9f6a6932214fda76b9b3c03e024772882d34

Last test of basis   156523  2020-11-06 10:00:26 Z0 days
Testing same since   156532  2020-11-06 17:01:35 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jason Andryuk 
  Juergen Gross 
  Olaf Hering 
  Stefano Stabellini 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   2a5f9f6a69..0a5e0ce0fb  0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258 -> smoke

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

[Christoph Hellwig]

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 eb8a5da48ad75a..327060e01ad58e 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -296,16 +296,21 @@ static void nbd_size_clear(struct nbd_device *nbd)
}
 }
 
-static void nbd_set_size(struct nbd_device *nbd, loff_t bytesize,
+static int nbd_set_size(struct nbd_device *nbd, loff_t bytesize,
loff_t blksize)
 {
struct block_device *bdev;
 
+   if (!blksize)
+   blksize = NBD_DEF_BLKSIZE;
+   if (blksize < 512 || blksize > PAGE_SIZE || !is_power_of_2(blksize))
+   return -EINVAL;
+
nbd->config->bytesize = bytesize;
nbd->config->blksize = blksize;
 
if (!nbd->task_recv)
-   return;
+   return 0;
 
if (nbd->config->flags & NBD_FLAG_SEND_TRIM) {
nbd->disk->queue->limits.discard_granularity = blksize;
@@ -325,6 +330,7 @@ static void nbd_set_size(struct nbd_device *nbd, loff_t 
bytesize,
bdput(bdev);
}
kobject_uevent(_to_dev(nbd)->kobj, KOBJ_CHANGE);
+   return 0;
 }
 
 static void nbd_complete_rq(struct request *req)
@@ -1304,8 +1310,7 @@ static int nbd_start_device(struct nbd_device *nbd)
args->index = i;
queue_work(nbd->recv_workq, >work);
}
-   nbd_set_size(nbd, config->bytesize, config->blksize);
-   return error;
+   return nbd_set_size(nbd, config->bytesize, config->blksize);
 }
 
 static int nbd_start_device_ioctl(struct nbd_device *nbd, struct block_device 
*bdev)
@@ -1347,14 +1352,6 @@ static void nbd_clear_sock_ioctl(struct nbd_device *nbd,
nbd_config_put(nbd);
 }
 
-static bool nbd_is_valid_blksize(unsigned long blksize)
-{
-   if (!blksize || !is_power_of_2(blksize) || blksize < 512 ||
-   blksize > PAGE_SIZE)
-   return false;
-   return true;
-}
-
 static void nbd_set_cmd_timeout(struct nbd_device *nbd, u64 timeout)
 {
nbd->tag_set.timeout = timeout * HZ;
@@ -1379,19 +1376,12 @@ static int __nbd_ioctl(struct block_device *bdev, 
struct nbd_device *nbd,
case NBD_SET_SOCK:
return nbd_add_socket(nbd, arg, false);
case NBD_SET_BLKSIZE:
-   if (!arg)
-   arg = NBD_DEF_BLKSIZE;
-   if (!nbd_is_valid_blksize(arg))
-   return -EINVAL;
-   nbd_set_size(nbd, config->bytesize, arg);
-   return 0;
+   return nbd_set_size(nbd, config->bytesize, arg);
case NBD_SET_SIZE:
-   nbd_set_size(nbd, arg, config->blksize);
-   return 0;
+   return nbd_set_size(nbd, arg, config->blksize);
case NBD_SET_SIZE_BLOCKS:
-   nbd_set_size(nbd, arg * config->blksize,
-config->blksize);
-   return 0;
+   return nbd_set_size(nbd, arg * config->blksize,
+   config->blksize);
case NBD_SET_TIMEOUT:
nbd_set_cmd_timeout(nbd, arg);
return 0;
@@ -1808,18 +1798,11 @@ static int nbd_genl_size_set(struct genl_info *info, 
struct nbd_device *nbd)
if (info->attrs[NBD_ATTR_SIZE_BYTES])
bytes = nla_get_u64(info->attrs[NBD_ATTR_SIZE_BYTES]);
 
-   if (info->attrs[NBD_ATTR_BLOCK_SIZE_BYTES]) {
+   if (info->attrs[NBD_ATTR_BLOCK_SIZE_BYTES])
bsize = nla_get_u64(info->attrs[NBD_ATTR_BLOCK_SIZE_BYTES]);
-   if (!bsize)
-   bsize = NBD_DEF_BLKSIZE;
-   if (!nbd_is_valid_blksize(bsize)) {
-   printk(KERN_ERR "Invalid block size %llu\n", bsize);
-   return -EINVAL;
-   }
-   }
 
if (bytes != config->bytesize || bsize != config->blksize)
-   nbd_set_size(nbd, bytes, bsize);
+   return nbd_set_size(nbd, bytes, bsize);
return 0;
 }
 
-- 
2.28.0

[PATCH 14/24] pktcdvd: use set_capacity_and_notify

[Christoph Hellwig]

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 a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 467dbd06b7cdb1..4326401cede445 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2130,8 +2130,7 @@ static int pkt_open_dev(struct pktcdvd_device *pd, 
fmode_t write)
}
 
set_capacity(pd->disk, lba << 2);
-   set_capacity(pd->bdev->bd_disk, lba << 2);
-   bd_set_nr_sectors(pd->bdev, lba << 2);
+   set_capacity_and_notify(pd->bdev->bd_disk, lba << 2);
 
q = bdev_get_queue(pd->bdev);
if (write) {
-- 
2.28.0

[PATCH 24/24] block: unexport revalidate_disk_size

[Christoph Hellwig]

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
+++ b/fs/block_dev.c
@@ -1362,7 +1362,6 @@ void revalidate_disk_size(struct gendisk *disk, bool 
verbose)
bdput(bdev);
}
 }
-EXPORT_SYMBOL(revalidate_disk_size);
 
 void bd_set_nr_sectors(struct block_device *bdev, sector_t sectors)
 {
-- 
2.28.0

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

[Christoph Hellwig]

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(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index aa6e27c2eec945..223c681d774a6f 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -93,16 +93,6 @@ static void nvme_put_subsystem(struct nvme_subsystem 
*subsys);
 static void nvme_remove_invalid_namespaces(struct nvme_ctrl *ctrl,
   unsigned nsid);
 
-static void nvme_update_bdev_size(struct gendisk *disk)
-{
-   struct block_device *bdev = bdget_disk(disk, 0);
-
-   if (bdev) {
-   bd_set_nr_sectors(bdev, get_capacity(disk));
-   bdput(bdev);
-   }
-}
-
 /*
  * Prepare a queue for teardown.
  *
@@ -119,8 +109,7 @@ static void nvme_set_queue_dying(struct nvme_ns *ns)
blk_set_queue_dying(ns->queue);
blk_mq_unquiesce_queue(ns->queue);
 
-   set_capacity(ns->disk, 0);
-   nvme_update_bdev_size(ns->disk);
+   set_capacity_and_notify(ns->disk, 0);
 }
 
 static void nvme_queue_scan(struct nvme_ctrl *ctrl)
-- 
2.28.0

[PATCH 09/24] nbd: refactor size updates

[Christoph Hellwig]

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 Hellwig 
---
 drivers/block/nbd.c | 44 ++--
 1 file changed, 18 insertions(+), 26 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 58b7090dcbd832..eb8a5da48ad75a 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -296,28 +296,30 @@ static void nbd_size_clear(struct nbd_device *nbd)
}
 }
 
-static void nbd_size_update(struct nbd_device *nbd)
+static void nbd_set_size(struct nbd_device *nbd, loff_t bytesize,
+   loff_t blksize)
 {
-   struct nbd_config *config = nbd->config;
-   sector_t nr_sectors = config->bytesize >> 9;
struct block_device *bdev;
 
+   nbd->config->bytesize = bytesize;
+   nbd->config->blksize = blksize;
+
if (!nbd->task_recv)
return;
 
-   if (config->flags & NBD_FLAG_SEND_TRIM) {
-   nbd->disk->queue->limits.discard_granularity = config->blksize;
-   nbd->disk->queue->limits.discard_alignment = config->blksize;
+   if (nbd->config->flags & NBD_FLAG_SEND_TRIM) {
+   nbd->disk->queue->limits.discard_granularity = blksize;
+   nbd->disk->queue->limits.discard_alignment = blksize;
blk_queue_max_discard_sectors(nbd->disk->queue, UINT_MAX);
}
-   blk_queue_logical_block_size(nbd->disk->queue, config->blksize);
-   blk_queue_physical_block_size(nbd->disk->queue, config->blksize);
+   blk_queue_logical_block_size(nbd->disk->queue, blksize);
+   blk_queue_physical_block_size(nbd->disk->queue, blksize);
 
-   set_capacity(nbd->disk, nr_sectors);
+   set_capacity(nbd->disk, bytesize >> 9);
bdev = bdget_disk(nbd->disk, 0);
if (bdev) {
if (bdev->bd_disk)
-   bd_set_nr_sectors(bdev, nr_sectors);
+   bd_set_nr_sectors(bdev, bytesize >> 9);
else
set_bit(GD_NEED_PART_SCAN, >disk->state);
bdput(bdev);
@@ -325,15 +327,6 @@ static void nbd_size_update(struct nbd_device *nbd)
kobject_uevent(_to_dev(nbd)->kobj, KOBJ_CHANGE);
 }
 
-static void nbd_size_set(struct nbd_device *nbd, loff_t blocksize,
-loff_t nr_blocks)
-{
-   struct nbd_config *config = nbd->config;
-   config->blksize = blocksize;
-   config->bytesize = blocksize * nr_blocks;
-   nbd_size_update(nbd);
-}
-
 static void nbd_complete_rq(struct request *req)
 {
struct nbd_cmd *cmd = blk_mq_rq_to_pdu(req);
@@ -1311,7 +1304,7 @@ static int nbd_start_device(struct nbd_device *nbd)
args->index = i;
queue_work(nbd->recv_workq, >work);
}
-   nbd_size_update(nbd);
+   nbd_set_size(nbd, config->bytesize, config->blksize);
return error;
 }
 
@@ -1390,15 +1383,14 @@ static int __nbd_ioctl(struct block_device *bdev, 
struct nbd_device *nbd,
arg = NBD_DEF_BLKSIZE;
if (!nbd_is_valid_blksize(arg))
return -EINVAL;
-   nbd_size_set(nbd, arg,
-div_s64(config->bytesize, arg));
+   nbd_set_size(nbd, config->bytesize, arg);
return 0;
case NBD_SET_SIZE:
-   nbd_size_set(nbd, config->blksize,
-div_s64(arg, config->blksize));
+   nbd_set_size(nbd, arg, config->blksize);
return 0;
case NBD_SET_SIZE_BLOCKS:
-   nbd_size_set(nbd, config->blksize, arg);
+   nbd_set_size(nbd, arg * config->blksize,
+config->blksize);
return 0;
case NBD_SET_TIMEOUT:
nbd_set_cmd_timeout(nbd, arg);
@@ -1827,7 +1819,7 @@ static int nbd_genl_size_set(struct genl_info *info, 
struct nbd_device *nbd)
}
 
if (bytes != config->bytesize || bsize != config->blksize)
-   nbd_size_set(nbd, bsize, div64_u64(bytes, bsize));
+   nbd_set_size(nbd, bytes, bsize);
return 0;
 }
 
-- 
2.28.0

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

[Christoph Hellwig]

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 b/drivers/md/dm-raid.c
index 9c1f7c4de65b35..294f34d2d61bae 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -700,8 +700,7 @@ static void rs_set_capacity(struct raid_set *rs)
 {
struct gendisk *gendisk = dm_disk(dm_table_get_md(rs->ti->table));
 
-   set_capacity(gendisk, rs->md.array_sectors);
-   revalidate_disk_size(gendisk, true);
+   set_capacity_and_notify(gendisk, rs->md.array_sectors);
 }
 
 /*
-- 
2.28.0

[PATCH 13/24] dm: use set_capacity_and_notify

[Christoph Hellwig]

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 b/drivers/md/dm.c
index c18fc25485186d..62ad44925e73ec 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1971,8 +1971,7 @@ static struct dm_table *__bind(struct mapped_device *md, 
struct dm_table *t,
if (size != dm_get_size(md))
memset(>geometry, 0, sizeof(md->geometry));
 
-   set_capacity(md->disk, size);
-   bd_set_nr_sectors(md->bdev, size);
+   set_capacity_and_notify(md->disk, size);
 
dm_table_event_callback(t, event_callback, md);
 
-- 
2.28.0

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

[Christoph Hellwig]

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 87442dc59f6ca3..35e2690c1803dd 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -1299,8 +1299,6 @@ static void update_size(struct mddev *mddev, sector_t 
old_dev_sectors)
} else {
/* revert to previous sectors */
ret = mddev->pers->resize(mddev, old_dev_sectors);
-   if (!ret)
-   revalidate_disk_size(mddev->gendisk, true);
ret = __sendmsg(cinfo, );
if (ret)
pr_err("%s:%d: failed to send METADATA_UPDATED msg\n",
-- 
2.28.0

[PATCH 18/24] rnbd: use set_capacity_and_notify

[Christoph Hellwig]

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 a/drivers/block/rnbd/rnbd-clt.c b/drivers/block/rnbd/rnbd-clt.c
index 8b2411ccbda97c..bb13d7dd195a08 100644
--- a/drivers/block/rnbd/rnbd-clt.c
+++ b/drivers/block/rnbd/rnbd-clt.c
@@ -100,8 +100,7 @@ static int rnbd_clt_change_capacity(struct rnbd_clt_dev 
*dev,
rnbd_clt_info(dev, "Device size changed from %zu to %zu sectors\n",
   dev->nsectors, new_nsectors);
dev->nsectors = new_nsectors;
-   set_capacity(dev->gd, dev->nsectors);
-   revalidate_disk_size(dev->gd, true);
+   set_capacity_and_notify(dev->gd, dev->nsectors);
return 0;
 }
 
-- 
2.28.0

[PATCH 21/24] md: use set_capacity_and_notify

[Christoph Hellwig]

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 ++--
 3 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
index 4aaf4820b6f625..87442dc59f6ca3 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -581,8 +581,7 @@ static int process_recvd_msg(struct mddev *mddev, struct 
cluster_msg *msg)
process_metadata_update(mddev, msg);
break;
case CHANGE_CAPACITY:
-   set_capacity(mddev->gendisk, mddev->array_sectors);
-   revalidate_disk_size(mddev->gendisk, true);
+   set_capacity_and_notify(mddev->gendisk, mddev->array_sectors);
break;
case RESYNCING:
set_bit(MD_RESYNCING_REMOTE, >recovery);
@@ -1296,8 +1295,7 @@ static void update_size(struct mddev *mddev, sector_t 
old_dev_sectors)
if (ret)
pr_err("%s:%d: failed to send CHANGE_CAPACITY msg\n",
   __func__, __LINE__);
-   set_capacity(mddev->gendisk, mddev->array_sectors);
-   revalidate_disk_size(mddev->gendisk, true);
+   set_capacity_and_notify(mddev->gendisk, mddev->array_sectors);
} else {
/* revert to previous sectors */
ret = mddev->pers->resize(mddev, old_dev_sectors);
diff --git a/drivers/md/md-linear.c b/drivers/md/md-linear.c
index 5ab22069b5be9c..98f1b4b2bdcef8 100644
--- a/drivers/md/md-linear.c
+++ b/drivers/md/md-linear.c
@@ -200,9 +200,8 @@ static int linear_add(struct mddev *mddev, struct md_rdev 
*rdev)
"copied raid_disks doesn't match mddev->raid_disks");
rcu_assign_pointer(mddev->private, newconf);
md_set_array_sectors(mddev, linear_size(mddev, 0, 0));
-   set_capacity(mddev->gendisk, mddev->array_sectors);
+   set_capacity_and_notify(mddev->gendisk, mddev->array_sectors);
mddev_resume(mddev);
-   revalidate_disk_size(mddev->gendisk, true);
kfree_rcu(oldconf, rcu);
return 0;
 }
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 98bac4f304ae26..32e375d50fee17 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5355,10 +5355,9 @@ array_size_store(struct mddev *mddev, const char *buf, 
size_t len)
 
if (!err) {
mddev->array_sectors = sectors;
-   if (mddev->pers) {
-   set_capacity(mddev->gendisk, mddev->array_sectors);
-   revalidate_disk_size(mddev->gendisk, true);
-   }
+   if (mddev->pers)
+   set_capacity_and_notify(mddev->gendisk,
+   mddev->array_sectors);
}
mddev_unlock(mddev);
return err ?: len;
@@ -6107,8 +6106,7 @@ int do_md_run(struct mddev *mddev)
md_wakeup_thread(mddev->thread);
md_wakeup_thread(mddev->sync_thread); /* possibly kick off a reshape */
 
-   set_capacity(mddev->gendisk, mddev->array_sectors);
-   revalidate_disk_size(mddev->gendisk, true);
+   set_capacity_and_notify(mddev->gendisk, mddev->array_sectors);
clear_bit(MD_NOT_READY, >flags);
mddev->changed = 1;
kobject_uevent(_to_dev(mddev->gendisk)->kobj, KOBJ_CHANGE);
@@ -6423,10 +6421,9 @@ static int do_md_stop(struct mddev *mddev, int mode,
if (rdev->raid_disk >= 0)
sysfs_unlink_rdev(mddev, rdev);
 
-   set_capacity(disk, 0);
+   set_capacity_and_notify(disk, 0);
mutex_unlock(>open_mutex);
mddev->changed = 1;
-   revalidate_disk_size(disk, true);
 
if (mddev->ro)
mddev->ro = 0;
@@ -7257,8 +7254,8 @@ static int update_size(struct mddev *mddev, sector_t 
num_sectors)
if (mddev_is_clustered(mddev))
md_cluster_ops->update_size(mddev, old_dev_sectors);
else if (mddev->queue) {
-   set_capacity(mddev->gendisk, mddev->array_sectors);
-   revalidate_disk_size(mddev->gendisk, true);
+   set_capacity_and_notify(mddev->gendisk,
+   mddev->array_sectors);
}
}
return rv;
@@ -9035,10 +9032,9 @@ void md_do_sync(struct md_thread *thread)
mddev_lock_nointr(mddev);
md_set_array_sectors(mddev, mddev->pers->size(mddev, 0, 0));
mddev_unlock(mddev);
-   if (!mddev_is_clustered(mddev)) {
-   set_capacity(mddev->gendisk, mddev->array_sectors);
-   

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

[Christoph Hellwig]

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 b/drivers/block/virtio_blk.c
index 3e812b4c32e669..145606dc52db1e 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -598,7 +598,6 @@ static void virtblk_update_cache_mode(struct virtio_device 
*vdev)
struct virtio_blk *vblk = vdev->priv;
 
blk_queue_write_cache(vblk->disk->queue, writeback, false);
-   revalidate_disk_size(vblk->disk, true);
 }
 
 static const char *const virtblk_cache_types[] = {
-- 
2.28.0

[PATCH 16/24] drbd: use set_capacity_and_notify

[Christoph Hellwig]

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 a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 65b95aef8dbc95..1c8c18b2a25f33 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -2036,8 +2036,7 @@ void drbd_set_my_capacity(struct drbd_device *device, 
sector_t size)
 {
char ppb[10];
 
-   set_capacity(device->vdisk, size);
-   revalidate_disk_size(device->vdisk, false);
+   set_capacity_and_notify(device->vdisk, size);
 
drbd_info(device, "size = %s (%llu KB)\n",
ppsize(ppb, size>>1), (unsigned long long)size>>1);
@@ -2068,8 +2067,7 @@ void drbd_device_cleanup(struct drbd_device *device)
}
D_ASSERT(device, first_peer_device(device)->connection->net_conf == 
NULL);
 
-   set_capacity(device->vdisk, 0);
-   revalidate_disk_size(device->vdisk, false);
+   set_capacity_and_notify(device->vdisk, 0);
if (device->bitmap) {
/* maybe never allocated. */
drbd_bm_resize(device, 0, 1);
-- 
2.28.0

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

[Christoph Hellwig]

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 merged with the update of the
block device size by using set_capacity_and_notify.  As an extra
bonus this also adds proper uevent notifications for the resize.

Signed-off-by: Christoph Hellwig 
---
 drivers/block/aoe/aoecmd.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index 313f0b946fe2b3..ac720bdcd983e7 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -890,19 +890,13 @@ void
 aoecmd_sleepwork(struct work_struct *work)
 {
struct aoedev *d = container_of(work, struct aoedev, work);
-   struct block_device *bd;
-   u64 ssize;
 
if (d->flags & DEVFL_GDALLOC)
aoeblk_gdalloc(d);
 
if (d->flags & DEVFL_NEWSIZE) {
-   ssize = get_capacity(d->gd);
-   bd = bdget_disk(d->gd, 0);
-   if (bd) {
-   bd_set_nr_sectors(bd, ssize);
-   bdput(bd);
-   }
+   set_capacity_and_notify(d->gd, d->ssize);
+
spin_lock_irq(>lock);
d->flags |= DEVFL_UP;
d->flags &= ~DEVFL_NEWSIZE;
@@ -971,10 +965,9 @@ ataid_complete(struct aoedev *d, struct aoetgt *t, 
unsigned char *id)
d->geo.start = 0;
if (d->flags & (DEVFL_GDALLOC|DEVFL_NEWSIZE))
return;
-   if (d->gd != NULL) {
-   set_capacity(d->gd, ssize);
+   if (d->gd != NULL)
d->flags |= DEVFL_NEWSIZE;
-   } else
+   else
d->flags |= DEVFL_GDALLOC;
schedule_work(>work);
 }
-- 
2.28.0

[PATCH 11/24] nbd: use set_capacity_and_notify

[Christoph Hellwig]

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 Hellwig 
---
 drivers/block/nbd.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 327060e01ad58e..a6f51934391edb 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -299,8 +299,6 @@ static void nbd_size_clear(struct nbd_device *nbd)
 static int nbd_set_size(struct nbd_device *nbd, loff_t bytesize,
loff_t blksize)
 {
-   struct block_device *bdev;
-
if (!blksize)
blksize = NBD_DEF_BLKSIZE;
if (blksize < 512 || blksize > PAGE_SIZE || !is_power_of_2(blksize))
@@ -320,16 +318,9 @@ static int nbd_set_size(struct nbd_device *nbd, loff_t 
bytesize,
blk_queue_logical_block_size(nbd->disk->queue, blksize);
blk_queue_physical_block_size(nbd->disk->queue, blksize);
 
-   set_capacity(nbd->disk, bytesize >> 9);
-   bdev = bdget_disk(nbd->disk, 0);
-   if (bdev) {
-   if (bdev->bd_disk)
-   bd_set_nr_sectors(bdev, bytesize >> 9);
-   else
-   set_bit(GD_NEED_PART_SCAN, >disk->state);
-   bdput(bdev);
-   }
-   kobject_uevent(_to_dev(nbd)->kobj, KOBJ_CHANGE);
+   set_bit(GD_NEED_PART_SCAN, >disk->state);
+   if (!set_capacity_and_notify(nbd->disk, bytesize >> 9))
+   kobject_uevent(_to_dev(nbd)->kobj, KOBJ_CHANGE);
return 0;
 }
 
-- 
2.28.0

[PATCH 19/24] zram: use set_capacity_and_notify

[Christoph Hellwig]

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 a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 1b697208d66157..6d15d51cee2b7e 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1695,7 +1695,7 @@ static void zram_reset_device(struct zram *zram)
disksize = zram->disksize;
zram->disksize = 0;
 
-   set_capacity(zram->disk, 0);
+   set_capacity_and_notify(zram->disk, 0);
part_stat_set_all(>disk->part0, 0);
 
up_write(>init_lock);
@@ -1741,9 +1741,7 @@ static ssize_t disksize_store(struct device *dev,
 
zram->comp = comp;
zram->disksize = disksize;
-   set_capacity(zram->disk, zram->disksize >> SECTOR_SHIFT);
-
-   revalidate_disk_size(zram->disk, true);
+   set_capacity_and_notify(zram->disk, zram->disksize >> SECTOR_SHIFT);
up_write(>init_lock);
 
return len;
@@ -1790,7 +1788,6 @@ static ssize_t reset_store(struct device *dev,
/* Make sure all the pending I/O are finished */
fsync_bdev(bdev);
zram_reset_device(zram);
-   revalidate_disk_size(zram->disk, true);
bdput(bdev);
 
mutex_lock(>bd_mutex);
-- 
2.28.0

[PATCH 17/24] rbd: use set_capacity_and_notify

[Christoph Hellwig]

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 b/drivers/block/rbd.c
index f84128abade319..b7a194ffda55b4 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -4920,8 +4920,7 @@ static void rbd_dev_update_size(struct rbd_device 
*rbd_dev)
!test_bit(RBD_DEV_FLAG_REMOVING, _dev->flags)) {
size = (sector_t)rbd_dev->mapping.size / SECTOR_SIZE;
dout("setting size to %llu sectors", (unsigned long long)size);
-   set_capacity(rbd_dev->disk, size);
-   revalidate_disk_size(rbd_dev->disk, true);
+   set_capacity_and_notify(rbd_dev->disk, size);
}
 }
 
-- 
2.28.0

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

[Christoph Hellwig]

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 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -296,7 +296,7 @@ static void nbd_size_clear(struct nbd_device *nbd)
}
 }
 
-static void nbd_size_update(struct nbd_device *nbd, bool start)
+static void nbd_size_update(struct nbd_device *nbd)
 {
struct nbd_config *config = nbd->config;
struct block_device *bdev = bdget_disk(nbd->disk, 0);
@@ -311,11 +311,9 @@ static void nbd_size_update(struct nbd_device *nbd, bool 
start)
blk_queue_physical_block_size(nbd->disk->queue, config->blksize);
set_capacity(nbd->disk, nr_sectors);
if (bdev) {
-   if (bdev->bd_disk) {
+   if (bdev->bd_disk)
bd_set_nr_sectors(bdev, nr_sectors);
-   if (start)
-   set_blocksize(bdev, config->blksize);
-   } else
+   else
set_bit(GD_NEED_PART_SCAN, >disk->state);
bdput(bdev);
}
@@ -329,7 +327,7 @@ static void nbd_size_set(struct nbd_device *nbd, loff_t 
blocksize,
config->blksize = blocksize;
config->bytesize = blocksize * nr_blocks;
if (nbd->task_recv != NULL)
-   nbd_size_update(nbd, false);
+   nbd_size_update(nbd);
 }
 
 static void nbd_complete_rq(struct request *req)
@@ -1309,7 +1307,7 @@ static int nbd_start_device(struct nbd_device *nbd)
args->index = i;
queue_work(nbd->recv_workq, >work);
}
-   nbd_size_update(nbd, true);
+   nbd_size_update(nbd);
return error;
 }
 
-- 
2.28.0

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

[Christoph Hellwig]

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 f618688a196654..58b7090dcbd832 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -299,8 +299,11 @@ static void nbd_size_clear(struct nbd_device *nbd)
 static void nbd_size_update(struct nbd_device *nbd)
 {
struct nbd_config *config = nbd->config;
-   struct block_device *bdev = bdget_disk(nbd->disk, 0);
sector_t nr_sectors = config->bytesize >> 9;
+   struct block_device *bdev;
+
+   if (!nbd->task_recv)
+   return;
 
if (config->flags & NBD_FLAG_SEND_TRIM) {
nbd->disk->queue->limits.discard_granularity = config->blksize;
@@ -309,7 +312,9 @@ static void nbd_size_update(struct nbd_device *nbd)
}
blk_queue_logical_block_size(nbd->disk->queue, config->blksize);
blk_queue_physical_block_size(nbd->disk->queue, config->blksize);
+
set_capacity(nbd->disk, nr_sectors);
+   bdev = bdget_disk(nbd->disk, 0);
if (bdev) {
if (bdev->bd_disk)
bd_set_nr_sectors(bdev, nr_sectors);
@@ -326,8 +331,7 @@ static void nbd_size_set(struct nbd_device *nbd, loff_t 
blocksize,
struct nbd_config *config = nbd->config;
config->blksize = blocksize;
config->bytesize = blocksize * nr_blocks;
-   if (nbd->task_recv != NULL)
-   nbd_size_update(nbd);
+   nbd_size_update(nbd);
 }
 
 static void nbd_complete_rq(struct request *req)
-- 
2.28.0

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

[Christoph Hellwig]

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 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -47,9 +47,9 @@ static void disk_release_events(struct gendisk *disk);
 
 /*
  * Set disk capacity and notify if the size is not currently zero and will not
- * be set to zero.
+ * be set to zero.  Returns true if a uevent was sent, otherwise false.
  */
-void set_capacity_and_notify(struct gendisk *disk, sector_t size)
+bool set_capacity_and_notify(struct gendisk *disk, sector_t size)
 {
sector_t capacity = get_capacity(disk);
 
@@ -60,7 +60,10 @@ void set_capacity_and_notify(struct gendisk *disk, sector_t 
size)
char *envp[] = { "RESIZE=1", NULL };
 
kobject_uevent_env(_to_dev(disk)->kobj, KOBJ_CHANGE, envp);
+   return true;
}
+
+   return false;
 }
 EXPORT_SYMBOL_GPL(set_capacity_and_notify);
 
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 596f31b5a3e133..4b22bfd9336e1a 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -315,7 +315,7 @@ static inline int get_disk_ro(struct gendisk *disk)
 extern void disk_block_events(struct gendisk *disk);
 extern void disk_unblock_events(struct gendisk *disk);
 extern void disk_flush_events(struct gendisk *disk, unsigned int mask);
-void set_capacity_and_notify(struct gendisk *disk, sector_t size);
+bool set_capacity_and_notify(struct gendisk *disk, sector_t size);
 
 /* drivers/char/random.c */
 extern void add_disk_randomness(struct gendisk *disk) __latent_entropy;
-- 
2.28.0

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

[Christoph Hellwig]

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 a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 656bcf4940d6d1..4a34dd5b153196 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1750,10 +1750,8 @@ static int sd_sync_cache(struct scsi_disk *sdkp, struct 
scsi_sense_hdr *sshdr)
 static void sd_rescan(struct device *dev)
 {
struct scsi_disk *sdkp = dev_get_drvdata(dev);
-   int ret;
 
-   ret = sd_revalidate_disk(sdkp->disk);
-   revalidate_disk_size(sdkp->disk, ret == 0);
+   sd_revalidate_disk(sdkp->disk);
 }
 
 static int sd_ioctl(struct block_device *bdev, fmode_t mode,
@@ -3266,7 +3264,7 @@ static int sd_revalidate_disk(struct gendisk *disk)
sdkp->first_scan = 0;
 
set_capacity_revalidate_and_notify(disk,
-   logical_to_sectors(sdp, sdkp->capacity), false);
+   logical_to_sectors(sdp, sdkp->capacity), true);
sd_config_write_same(sdkp);
kfree(buffer);
 
@@ -3276,7 +3274,7 @@ static int sd_revalidate_disk(struct gendisk *disk)
 * capacity to 0.
 */
if (sd_zbc_revalidate_zones(sdkp))
-   set_capacity_revalidate_and_notify(disk, 0, false);
+   set_capacity_revalidate_and_notify(disk, 0, true);
 
  out:
return 0;
-- 
2.28.0

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

[Christoph Hellwig]

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
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2053,7 +2053,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
capacity = 0;
}
 
-   set_capacity_revalidate_and_notify(disk, capacity, false);
+   set_capacity_revalidate_and_notify(disk, capacity, true);
 
nvme_config_discard(disk, ns);
nvme_config_write_zeroes(disk, ns);
@@ -2136,7 +2136,6 @@ static int nvme_update_ns_info(struct nvme_ns *ns, struct 
nvme_id_ns *id)
blk_stack_limits(>head->disk->queue->limits,
 >queue->limits, 0);
blk_queue_update_readahead(ns->head->disk->queue);
-   nvme_update_bdev_size(ns->head->disk);
blk_mq_unfreeze_queue(ns->head->disk->queue);
}
 #endif
@@ -3965,8 +3964,6 @@ static void nvme_validate_ns(struct nvme_ns *ns, struct 
nvme_ns_ids *ids)
 */
if (ret && ret != -ENOMEM && !(ret > 0 && !(ret & NVME_SC_DNR)))
nvme_ns_remove(ns);
-   else
-   revalidate_disk_size(ns->disk, true);
 }
 
 static void nvme_validate_or_alloc_ns(struct nvme_ctrl *ctrl, unsigned nsid)
-- 
2.28.0

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

[Christoph Hellwig]

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 +
 drivers/block/loop.c | 11 +--
 drivers/block/virtio_blk.c   |  2 +-
 drivers/block/xen-blkfront.c |  2 +-
 drivers/nvme/host/core.c |  2 +-
 drivers/scsi/sd.c|  5 ++---
 include/linux/genhd.h|  3 +--
 7 files changed, 16 insertions(+), 22 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index 0a273211fec283..d8d9d6c1c916e1 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -46,17 +46,15 @@ static void disk_del_events(struct gendisk *disk);
 static void disk_release_events(struct gendisk *disk);
 
 /*
- * Set disk capacity and notify if the size is not currently
- * zero and will not be set to zero
+ * Set disk capacity and notify if the size is not currently zero and will not
+ * be set to zero.
  */
-void set_capacity_revalidate_and_notify(struct gendisk *disk, sector_t size,
-   bool update_bdev)
+void set_capacity_and_notify(struct gendisk *disk, sector_t size)
 {
sector_t capacity = get_capacity(disk);
 
set_capacity(disk, size);
-   if (update_bdev)
-   revalidate_disk_size(disk, true);
+   revalidate_disk_size(disk, true);
 
if (capacity != size && capacity != 0 && size != 0) {
char *envp[] = { "RESIZE=1", NULL };
@@ -64,8 +62,7 @@ void set_capacity_revalidate_and_notify(struct gendisk *disk, 
sector_t size,
kobject_uevent_env(_to_dev(disk)->kobj, KOBJ_CHANGE, envp);
}
 }
-
-EXPORT_SYMBOL_GPL(set_capacity_revalidate_and_notify);
+EXPORT_SYMBOL_GPL(set_capacity_and_notify);
 
 /*
  * Format the device name of the indicated disk into the supplied buffer and
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 86eb7e0691eef5..77937b760ee0fc 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1146,8 +1146,7 @@ static int loop_configure(struct loop_device *lo, fmode_t 
mode,
loop_update_dio(lo);
loop_sysfs_init(lo);
 
-   set_capacity_revalidate_and_notify(lo->lo_disk, get_loop_size(lo, file),
-   true);
+   set_capacity_and_notify(lo->lo_disk, get_loop_size(lo, file));
set_blocksize(bdev, S_ISBLK(inode->i_mode) ?
  block_size(inode->i_bdev) : PAGE_SIZE);
 
@@ -1383,9 +1382,9 @@ loop_set_status(struct loop_device *lo, const struct 
loop_info64 *info)
lo->lo_flags |= prev_lo_flags & ~LOOP_SET_STATUS_CLEARABLE_FLAGS;
 
if (size_changed) {
-   set_capacity_revalidate_and_notify(lo->lo_disk,
+   set_capacity_and_notify(lo->lo_disk,
get_size(lo->lo_offset, lo->lo_sizelimit,
-lo->lo_backing_file), true);
+lo->lo_backing_file));
}
 
loop_config_discard(lo);
@@ -1563,8 +1562,8 @@ static int loop_set_capacity(struct loop_device *lo)
 {
if (unlikely(lo->lo_state != Lo_bound))
return -ENXIO;
-   set_capacity_revalidate_and_notify(lo->lo_disk,
-   get_loop_size(lo, lo->lo_backing_file), true);
+   set_capacity_and_notify(lo->lo_disk,
+   get_loop_size(lo, lo->lo_backing_file));
return 0;
 }
 
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index a314b9382442b6..3e812b4c32e669 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -470,7 +470,7 @@ static void virtblk_update_capacity(struct virtio_blk 
*vblk, bool resize)
   cap_str_10,
   cap_str_2);
 
-   set_capacity_revalidate_and_notify(vblk->disk, capacity, true);
+   set_capacity_and_notify(vblk->disk, capacity);
 }
 
 static void virtblk_config_changed_work(struct work_struct *work)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 48629d3433b4c3..79521e33d30ed5 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2370,7 +2370,7 @@ static void blkfront_connect(struct blkfront_info *info)
return;
printk(KERN_INFO "Setting capacity to %Lu\n",
   sectors);
-   set_capacity_revalidate_and_notify(info->gd, sectors, true);
+   set_capacity_and_notify(info->gd, sectors);
 
return;
case BLKIF_STATE_SUSPENDED:
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 4e86c9aafd88a7..aa6e27c2eec945 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2053,7 +2053,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
capacity = 0;
}
 
-   

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

[Christoph Hellwig]

__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 many people use partitions, for which no
invalidation was performed anyway.

Signed-off-by: Christoph Hellwig 
---
 fs/block_dev.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 9e84b1928b9401..66ebf594c97f47 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1334,12 +1334,6 @@ static void check_disk_size_change(struct gendisk *disk,
i_size_write(bdev->bd_inode, disk_size);
}
spin_unlock(>bd_size_lock);
-
-   if (bdev_size > disk_size) {
-   if (__invalidate_device(bdev, false))
-   pr_warn("VFS: busy inodes on resized disk %s\n",
-   disk->disk_name);
-   }
 }
 
 /**
-- 
2.28.0

[PATCH 02/24] loop: remove loop_set_size

[Christoph Hellwig]

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 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index cb1191d6e945f2..86eb7e0691eef5 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -241,23 +241,6 @@ loop_validate_block_size(unsigned short bsize)
return 0;
 }
 
-/**
- * loop_set_size() - sets device size and notifies userspace
- * @lo: struct loop_device to set the size for
- * @size: new size of the loop device
- *
- * Callers must validate that the size passed into this function fits into
- * a sector_t, eg using loop_validate_size()
- */
-static void loop_set_size(struct loop_device *lo, loff_t size)
-{
-   struct block_device *bdev = lo->lo_device;
-
-   bd_set_nr_sectors(bdev, size);
-
-   set_capacity_revalidate_and_notify(lo->lo_disk, size, false);
-}
-
 static inline int
 lo_do_transfer(struct loop_device *lo, int cmd,
   struct page *rpage, unsigned roffs,
@@ -1076,7 +1059,6 @@ static int loop_configure(struct loop_device *lo, fmode_t 
mode,
struct address_space *mapping;
struct block_device *claimed_bdev = NULL;
int error;
-   loff_t  size;
boolpartscan;
unsigned short  bsize;
 
@@ -1164,9 +1146,8 @@ static int loop_configure(struct loop_device *lo, fmode_t 
mode,
loop_update_dio(lo);
loop_sysfs_init(lo);
 
-   size = get_loop_size(lo, file);
-   loop_set_size(lo, size);
-
+   set_capacity_revalidate_and_notify(lo->lo_disk, get_loop_size(lo, file),
+   true);
set_blocksize(bdev, S_ISBLK(inode->i_mode) ?
  block_size(inode->i_bdev) : PAGE_SIZE);
 
@@ -1402,9 +1383,9 @@ loop_set_status(struct loop_device *lo, const struct 
loop_info64 *info)
lo->lo_flags |= prev_lo_flags & ~LOOP_SET_STATUS_CLEARABLE_FLAGS;
 
if (size_changed) {
-   loff_t new_size = get_size(lo->lo_offset, lo->lo_sizelimit,
-  lo->lo_backing_file);
-   loop_set_size(lo, new_size);
+   set_capacity_revalidate_and_notify(lo->lo_disk,
+   get_size(lo->lo_offset, lo->lo_sizelimit,
+lo->lo_backing_file), true);
}
 
loop_config_discard(lo);
@@ -1580,14 +1561,10 @@ loop_get_status64(struct loop_device *lo, struct 
loop_info64 __user *arg) {
 
 static int loop_set_capacity(struct loop_device *lo)
 {
-   loff_t size;
-
if (unlikely(lo->lo_state != Lo_bound))
return -ENXIO;
-
-   size = get_loop_size(lo, lo->lo_backing_file);
-   loop_set_size(lo, size);
-
+   set_capacity_revalidate_and_notify(lo->lo_disk,
+   get_loop_size(lo, lo->lo_backing_file), true);
return 0;
 }
 
-- 
2.28.0

cleanup updating the size of block devices

[Christoph Hellwig]

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 +-
 drivers/block/drbd/drbd_main.c |6 --
 drivers/block/loop.c   |   36 ++--
 drivers/block/nbd.c|   88 +
 drivers/block/pktcdvd.c|3 -
 drivers/block/rbd.c|3 -
 drivers/block/rnbd/rnbd-clt.c  |3 -
 drivers/block/virtio_blk.c |3 -
 drivers/block/xen-blkfront.c   |2 
 drivers/block/zram/zram_drv.c  |7 ---
 drivers/md/dm-raid.c   |3 -
 drivers/md/dm.c|3 -
 drivers/md/md-cluster.c|8 ---
 drivers/md/md-linear.c |3 -
 drivers/md/md.c|   24 ---
 drivers/nvme/host/core.c   |   18 
 drivers/scsi/sd.c  |9 +---
 fs/block_dev.c |7 ---
 include/linux/genhd.h  |3 -
 20 files changed, 76 insertions(+), 184 deletions(-)

[linux-linus test] 156462: regressions - FAIL

[osstest service owner]

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
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-xsm7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332
 test-amd64-i386-examine   6 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt   7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-coresched-i386-xl  7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-libvirt-xsm   7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332
 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 
152332
 test-amd64-i386-xl-raw7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-pvshim 7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-freebsd10-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-shadow 7 xen-install  fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332
 test-amd64-i386-freebsd10-i386  7 xen-installfail REGR. vs. 152332
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-install   fail REGR. vs. 152332
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. 
vs. 152332
 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332
 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-installfail REGR. vs. 152332
 test-arm64-arm64-examine 13 examine-iommufail REGR. vs. 152332
 test-amd64-amd64-amd64-pvgrub 20 guest-stop  fail REGR. vs. 152332
 test-amd64-amd64-i386-pvgrub 20 guest-stop   fail REGR. vs. 152332
 test-armhf-armhf-libvirt  8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-xl-credit1   8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-xl-multivcpu  8 xen-bootfail REGR. vs. 152332
 test-armhf-armhf-xl-vhd   8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-libvirt-raw  8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-xl-cubietruck  8 xen-boot   fail REGR. vs. 152332
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 152332
 test-armhf-armhf-xl-credit2   8 xen-boot fail REGR. vs. 152332
 test-armhf-armhf-xl   8 xen-boot fail REGR. vs. 152332
 test-arm64-arm64-xl-credit2 10 host-ping-check-xen fail in 156390 REGR. vs. 
152332
 test-arm64-arm64-xl-xsm  12 debian-install fail in 156390 REGR. vs. 152332
 test-arm64-arm64-xl  12 debian-install fail in 156402 REGR. vs. 152332
 build-i386-xsm6 xen-build  fail in 156402 REGR. vs. 152332
 build-i3866 xen-build  fail in 156402 REGR. vs. 152332
 build-armhf   6 xen-build  fail in 156402 REGR. vs. 152332

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-xl-credit1   8 xen-boot fail in 156390 pass in 156462
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 
156390 pass in 156462
 test-arm64-arm64-libvirt-xsm  8 xen-boot fail in 156402 pass in 156462
 test-arm64-arm64-examine  8 reboot   fail in 156402 pass in 156462
 test-arm64-arm64-xl-credit2   8 xen-boot   fail pass in 156390
 test-arm64-arm64-xl-xsm   8 xen-boot   fail pass in 156390
 test-arm64-arm64-xl   8 xen-boot   fail pass in 156402
 test-arm64-arm64-xl-seattle   8 xen-boot   fail pass in 156402

Regressions which are regarded as 

[ovmf test] 156467: all pass - PUSHED

[osstest service owner]

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 8d5708833509ece6ac63084dc07c8ac53c4d4c1a

Last test of basis   156400  2020-11-04 12:10:58 Z2 days
Testing same since   156407  2020-11-05 09:30:19 Z1 days2 attempts


People who touched revisions under test:
  Bob Feng 
  Jeff Brasen 
  Liming Gao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   8d57088335..09af9bd9be  09af9bd9be2d3e31bba979f8cf6446017b0b863e -> 
xen-tested-master

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

[Wei Liu]

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

[Wei Liu]

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 build.
> > Like libxl__build_pv, libxl__build_hvm should set state->vuart_gfn to
> > dom->vuart_gfn.
> > 
> > Without this change, xl console cannot connect to the vuart console (-t
> > vuart), see https://marc.info/?l=xen-devel=160402342101366.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index f8661e90d4..36fe8915e7 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -1184,6 +1184,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
> >  LOG(ERROR, "hvm build set params failed");
> >  goto out;
> >  }
> > +state->vuart_gfn = dom->vuart_gfn;
> >  
> >  rc = hvm_build_set_xs_values(gc, domid, dom, info);
> >  if (rc != 0) {
> 
> Reviewed-by: Anthony PERARD 

This patch is based on an old tree. I have ported it to staging. Please
check the code and shout if it is not done correctly.

Wei.

> 
> Thanks,
> 
> -- 
> Anthony PERARD

[libvirt test] 156509: regressions - FAIL

[osstest service owner]

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-libvirt6 libvirt-buildfail REGR. vs. 151777
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 151777
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 151777

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  8f0f6ff08211ace1dabc2c6a93befe60edaa97e1
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  119 days
Failing since151818  2020-07-11 04:18:52 Z  118 days  113 attempts
Testing same since   156509  2020-11-06 04:19:18 Z0 days1 attempts


People who touched revisions under test:
  Adolfo Jayme Barrientos 
  Aleksandr Alekseev 
  Andika Triwidada 
  Andrea Bolognani 
  Balázs Meskó 
  Bastien Orivel 
  Bihong Yu 
  Binfeng Wu 
  Boris Fiuczynski 
  Brian Turek 
  Christian Ehrhardt 
  Christian Schoenebeck 
  Cole Robinson 
  Collin Walling 
  Cornelia Huck 
  Côme Borsoi 
  Daniel Henrique Barboza 
  Daniel Letai 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  Erik Skultety 
  Fabian Freyer 
  Fangge Jin 
  Fedora Weblate Translation 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Ian Wienand 
  Jamie Strandboge 
  Jamie Strandboge 
  Jean-Baptiste Holcroft 
  Jianan Gao 
  Jim Fehlig 
  Jin Yan 
  Jiri Denemark 
  Jonathon Jongsma 
  Julio Faracco 
  Ján Tomko 
  Kashyap Chamarthy 
  Kevin Locke 
  Laine Stump 
  Liao Pingfang 
  Lin Ma 
  Lin Ma 
  Marc Hartmayer 
  Marek Marczykowski-Górecki 
  Markus Schade 
  Martin Kletzander 
  Masayoshi Mizuma 
  Matt Coleman 
  Matt Coleman 
  Mauro Matteo Cascella 
  Michal Privoznik 
  Michał Smyk 
  Milo Casagrande 
  Neal Gompa 
  Nico Pache 
  Nikolay Shirokovskiy 
  Olesya Gerasimenko 
  Orion Poplawski 
  Patrick Magauran 
  Paulo de Rezende Pinatti 
  Pavel Hrdina 
  Peter Krempa 
  Pino Toscano 
  Pino Toscano 
  Piotr Drąg 
  Prathamesh Chavan 
  Roman Bogorodskiy 
  Roman Bolshakov 
  Ryan Schmidt 
  Sam Hartman 
  Scott Shambarger 
  Sebastian Mitterle 
  Simon Gaiser 
  Stefan Bader 
  Stefan Berger 
  Szymon Scholz 
  Thomas Huth 
  Tim Wiederhake 
  Tomáš Golembiovský 
  Wang Xin 
  Weblate 
  Yang Hang 
  Yanqiu Zhang 
  Yi Li 
  Yi Wang 
  Yuri Chornoivan 
  Zheng Chuan 
  zhenwei pi 
  Zhenyu Zheng 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm   

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

[Wei Liu]

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 used only for determining what to convert 'x' to (but not
> to e.g. validate '1' settings), the effect of this change is identical
> for guests with (suitable) "cpuid=" settings to that of the changes
> separating default from max and then converting (e.g.) MPX from being
> part of default to only being part of max for guests without (affected)
> "cpuid=" settings.
> 
> Signed-off-by: Jan Beulich 

I will defer this to Andrew.

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

[osstest service owner]

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 are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  10 host-ping-check-xen fail in 156404 pass in 156460
 test-armhf-armhf-xl-vhd  20 leak-check/check   fail pass in 156404

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-pair  1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
in 156404 n/a
 test-amd64-coresched-i386-xl  1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 156404 n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)blocked in 156404 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)blocked in 156404 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1) blocked in 156404 n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)blocked in 156404 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
156404 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)blocked in 156404 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 156404 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)blocked in 156404 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1) blocked in 156404 n/a
 test-amd64-i386-xl1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1) blocked in 156404 n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)blocked in 156404 n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked in 156404 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 
156404 n/a
 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail in 156404 like 
156394
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 156394
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 156394
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 156394
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 156394
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 156394
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 156394
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 156394
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 156394
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 156394
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 156394
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 156394
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-check   

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

[Wei Liu]

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

[Wei Liu]

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 Gross 

Acked-by: Wei Liu 

Re: Xen 4.13.2 released

[George Dunlap]

> 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
 immediately from its git repository
 http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.13
 (tag RELEASE-4.13.2) or from the XenProject download page
 https://xenproject.org/downloads/xen-project-archives/xen-project-4-13-series/xen-project-4-13-2/
 (where a list of changes can also be found).
>>> 
>>> Is the entry for XSA-335 correct on the download page? That was a qemu 
>>> patch but I don't think it was included in 4.13.2.
>> 
>> Interesting, thanks for pointing this out. The qemu-trad part,
>> albeit "just" a SUPPORT.md update, didn't even make it into
>> staging yet afaics. While this can perhaps be viewed as benign,
>> I'm concerned that the qemuu fix also doesn't look to have
>> landed in any of the branches yet, despite the version bump on
>> the staging/master branches just 5 days ago. Anthony, Stefano?
> 
> I've pushed the fix now, to qemu-xen trees.
> 
> Maybe George's script could check qemu-xen trees as well? Or someone in
> the security team could push the patchs or tell me about XSAs involving
> QEMU, otherwise that's going to happen again.

Making a script you could put into a cron job to tell you when a QEMU XSA comes 
out should be fairly easy.  (Although, of course in this case it wouldn’t have 
worked because xsa.json didn’t have the correct information.)

Checking that it’s been applied would be a bit more work; it’s on my list of 
things to do.

It’s all in Go, so maybe I should publish the packages; then maybe you could 
send me a PR. :-)

 -George

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

[Jan Beulich]

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 that by adding the appropriate tests.
>>>
>>> Signed-off-by: Juergen Gross 
>>
>> Wouldn't it be better to convert the parameter types to unsigned int?
> 
> Those are official library interfaces. Can we just change them?

Oh, I didn't expect such helpers to be available to users of the
library.

Jan

Re: [PATCH] libxl: set vuart_gfn in libxl__build_hvm

[Anthony PERARD]

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
> dom->vuart_gfn.
> 
> Without this change, xl console cannot connect to the vuart console (-t
> vuart), see https://marc.info/?l=xen-devel=160402342101366.
> 
> Signed-off-by: Stefano Stabellini 
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index f8661e90d4..36fe8915e7 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -1184,6 +1184,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
>  LOG(ERROR, "hvm build set params failed");
>  goto out;
>  }
> +state->vuart_gfn = dom->vuart_gfn;
>  
>  rc = hvm_build_set_xs_values(gc, domid, dom, info);
>  if (rc != 0) {

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

[Rahul Singh]

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 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, Julien!
>>> 
>>> On 10/30/20 7:18 PM, Julien Grall wrote:
 Hi Oleksandr,
 
 On 30/10/2020 10:44, Oleksandr Andrushchenko wrote:
> On 10/20/20 6:25 PM, Rahul Singh wrote:
>> Add support for ARM architected SMMUv3 implementations. It is based 
>> on
>> the Linux SMMUv3 driver.
>> 
>> Major differences between the Linux driver are as follows:
>> 1. Only Stage-2 translation is supported as compared to the Linux 
>> driver
>>  that supports both Stage-1 and Stage-2 translations.
> First of all thank you for the efforts!
> 
> I tried the patch with QEMU and would like to know if my 
> understanding correct
> 
> that this combination will not work as of now:
> 
> (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
> (XEN) Data Abort Trap. Syndrome=0x1940010
> (XEN) Walking Hypervisor VA 0x40031000 on CPU0 via TTBR 
> 0xb8469000
> (XEN) 0TH[0x0] = 0xb8468f7f
> 
> [snip]
> 
> If this is expected then is there any plan to make QEMU work as well?
> 
> I see [1] says that "Only stage 1 and AArch64 PTW are supported." on 
> QEMU side.
 Just for clarication, you are trying to boot Xen on QEMU, right?
>>> Exactly
 You might be able to use the stage-1 page-tables to isolate each 
 device in Xen. However, I don't think you will be able to share the 
 P2M because the page-tables layout between stage-1 and stage-2 is 
 different.
>>> So, it is even more work then
>> Overall it would make more sense to spend some time adding proper 
>> support in Qemu then trying to modify the driver to support Qemu right 
>> now.
>> 
> We are interested in QEMU/SMMUv3 as a flexible platform for PCI 
> passthrough
> 
> implementation, so it could allow testing different setups and 
> configurations with QEMU.
 I would recommend to get the SMMU supporting supporting stage-2 
 page-tables.
>>> You mean in QEMU?
>> See before.
>> 
 Regardless that, I think Xen should be able to say the SMMU is not 
 supported rather than crashing.
>>> Yes, that would be nice
>> Fully agree and we will look into that.
>> 
>> Anything you could share so that we could quickly reproduce your setup 
>> would be more then great.
> Nothing special,
> 
> qemu/aarch64-softmmu/qemu-system-aarch64 -machine type=virt -machine 
> virt,gic-version=2 \
> 
> -machine virtualization=true -cpu cortex-a57 -smp 4 -m 2048 -nic 
> user,hostfwd=tcp:127.0.0.1:-:22 \
> 
> -nographic -serial mon:stdio [..snip..]
> 
> I also set iommu to smmuv3 in my tests, QEMU emulator version 4.2.1
 I just checked and confirmed that QEMU is booting with XEN SMMUv3 patch 
 and XEN is able to say SMMU translation is not supported. As XEN supports 
 Stage-2 translation and QEMU supports Stage-1 only.
 
 
 (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
 (XEN) SMMUv3: /smmuv3@905: IDR0.COHACC overridden by FW configuration 
 (false)
 (XEN) SMMUv3: /smmuv3@905: no translation support!
 (XEN) I/O virtualisation disabled
 
 Only difference I observed is that you have to add option "-machine 
 virt,iommu=smmuv3 “ when launching the QEMU.
>>> I do use the option
>> I used "-machine virt,iommu=smmuv3 “  option while creating the virt-dtb and 
>> while launching the QEMU.
>> I also observed the same error what you observed if I am not using the 
>> "-machine virt,iommu=smmuv3 “ options when launching the QEMU so I thought 
>> this might be case for you also but anyways you have use the options it 
>> might be other issue.
> 
> Hm, probably that was on my side as now I can see:
> 
> (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
> (XEN) SMMUv3: /smmuv3@905: IDR0.COHACC overridden by FW configuration 
> (false)
> (XEN) SMMUv3: /smmuv3@905: no translation support!
> (XEN) I/O virtualisation disabled
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) Couldn't configure correctly all the IOMMUs.
> (XEN) 

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

[Andrew Cooper]

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.
>>
>> Signed-off-by: Juergen Gross 
> Wouldn't it be better to convert the parameter types to unsigned int?

Yes, except their in the API, so immutable.

(whether they should be in the API is a different question...)

~Andrew

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

[Jürgen Groß]

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: Juergen Gross 


Wouldn't it be better to convert the parameter types to unsigned int?


Those are official library interfaces. Can we just change them?


Juergen

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

[Jan Beulich]

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 better to convert the parameter types to unsigned int?

Jan

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

[Oleksandr Andrushchenko]

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:

 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 Oleksandr,
>>>
>>> On 30/10/2020 10:44, Oleksandr Andrushchenko wrote:
 On 10/20/20 6:25 PM, Rahul Singh wrote:
> Add support for ARM architected SMMUv3 implementations. It is based on
> the Linux SMMUv3 driver.
>
> Major differences between the Linux driver are as follows:
> 1. Only Stage-2 translation is supported as compared to the Linux 
> driver
>   that supports both Stage-1 and Stage-2 translations.
 First of all thank you for the efforts!

 I tried the patch with QEMU and would like to know if my understanding 
 correct

 that this combination will not work as of now:

 (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
 (XEN) Data Abort Trap. Syndrome=0x1940010
 (XEN) Walking Hypervisor VA 0x40031000 on CPU0 via TTBR 
 0xb8469000
 (XEN) 0TH[0x0] = 0xb8468f7f

 [snip]

 If this is expected then is there any plan to make QEMU work as well?

 I see [1] says that "Only stage 1 and AArch64 PTW are supported." on 
 QEMU side.
>>> Just for clarication, you are trying to boot Xen on QEMU, right?
>> Exactly
>>> You might be able to use the stage-1 page-tables to isolate each device 
>>> in Xen. However, I don't think you will be able to share the P2M 
>>> because the page-tables layout between stage-1 and stage-2 is different.
>> So, it is even more work then
> Overall it would make more sense to spend some time adding proper support 
> in Qemu then trying to modify the driver to support Qemu right now.
>
 We are interested in QEMU/SMMUv3 as a flexible platform for PCI 
 passthrough

 implementation, so it could allow testing different setups and 
 configurations with QEMU.
>>> I would recommend to get the SMMU supporting supporting stage-2 
>>> page-tables.
>> You mean in QEMU?
> See before.
>
>>> Regardless that, I think Xen should be able to say the SMMU is not 
>>> supported rather than crashing.
>> Yes, that would be nice
> Fully agree and we will look into that.
>
> Anything you could share so that we could quickly reproduce your setup 
> would be more then great.
 Nothing special,

 qemu/aarch64-softmmu/qemu-system-aarch64 -machine type=virt -machine 
 virt,gic-version=2 \

 -machine virtualization=true -cpu cortex-a57 -smp 4 -m 2048 -nic 
 user,hostfwd=tcp:127.0.0.1:-:22 \

 -nographic -serial mon:stdio [..snip..]

 I also set iommu to smmuv3 in my tests, QEMU emulator version 4.2.1
>>> I just checked and confirmed that QEMU is booting with XEN SMMUv3 patch and 
>>> XEN is able to say SMMU translation is not supported. As XEN supports 
>>> Stage-2 translation and QEMU supports Stage-1 only.
>>>
>>>
>>> (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
>>> (XEN) SMMUv3: /smmuv3@905: IDR0.COHACC overridden by FW configuration 
>>> (false)
>>> (XEN) SMMUv3: /smmuv3@905: no translation support!
>>> (XEN) I/O virtualisation disabled
>>>
>>> Only difference I observed is that you have to add option "-machine 
>>> virt,iommu=smmuv3 “ when launching the QEMU.
>> I do use the option
> I used "-machine virt,iommu=smmuv3 “  option while creating the virt-dtb and 
> while launching the QEMU.
> I also observed the same error what you observed if I am not using the 
> "-machine virt,iommu=smmuv3 “ options when launching the QEMU so I thought 
> this might be case for you also but anyways you have use the options it might 
> be other issue.

Hm, probably that was on my side as now I can see:

(XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
(XEN) SMMUv3: /smmuv3@905: IDR0.COHACC overridden by FW configuration 
(false)
(XEN) SMMUv3: /smmuv3@905: no translation support!
(XEN) I/O virtualisation disabled
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Couldn't configure correctly all the IOMMUs.
(XEN) 
(XEN)
(XEN) Manual reset required ('noreboot' specified)

So, sorry for the noise, I might have misconfigured something it seems

When you say "Xen is booting" do you mean you see the same panic?

Thank you,

Oleksandr

>
>>> Please let me know if it also works 

[xen-unstable test] 156443: tolerable FAIL

[osstest service owner]

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
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 156401
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 156401
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 156401
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 156401
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 156401
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 156401
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 156401
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 156401
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 156401
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 156401
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  9ff9705647646aa937b5f5c1426a64c69a62b3bd
baseline version:
 xen  9ff9705647646aa937b5f5c1426a64c69a62b3bd

Last test of basis   156443  2020-11-05 15:47:13 Z0 days
Testing same since  (not found) 0 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-arm64

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

[Juergen Gross]

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 insertions(+), 3 deletions(-)

diff --git a/tools/libs/light/libxl_utils.c b/tools/libs/light/libxl_utils.c
index b039143b8a..4699c4a0a3 100644
--- a/tools/libs/light/libxl_utils.c
+++ b/tools/libs/light/libxl_utils.c
@@ -688,21 +688,21 @@ int libxl_bitmap_is_empty(const libxl_bitmap *bitmap)
 
 int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit)
 {
-if (bit >= bitmap->size * 8)
+if (bit >= bitmap->size * 8 || bit < 0)
 return 0;
 return (bitmap->map[bit / 8] & (1 << (bit & 7))) ? 1 : 0;
 }
 
 void libxl_bitmap_set(libxl_bitmap *bitmap, int bit)
 {
-if (bit >= bitmap->size * 8)
+if (bit >= bitmap->size * 8 || bit < 0)
 return;
 bitmap->map[bit / 8] |= 1 << (bit & 7);
 }
 
 void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit)
 {
-if (bit >= bitmap->size * 8)
+if (bit >= bitmap->size * 8 || bit < 0)
 return;
 bitmap->map[bit / 8] &= ~(1 << (bit & 7));
 }
-- 
2.26.2

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

[Rahul Singh]

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 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 Oleksandr,
>> 
>> On 30/10/2020 10:44, Oleksandr Andrushchenko wrote:
>>> On 10/20/20 6:25 PM, Rahul Singh wrote:
 Add support for ARM architected SMMUv3 implementations. It is based on
 the Linux SMMUv3 driver.
 
 Major differences between the Linux driver are as follows:
 1. Only Stage-2 translation is supported as compared to the Linux 
 driver
  that supports both Stage-1 and Stage-2 translations.
>>> First of all thank you for the efforts!
>>> 
>>> I tried the patch with QEMU and would like to know if my understanding 
>>> correct
>>> 
>>> that this combination will not work as of now:
>>> 
>>> (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
>>> (XEN) Data Abort Trap. Syndrome=0x1940010
>>> (XEN) Walking Hypervisor VA 0x40031000 on CPU0 via TTBR 
>>> 0xb8469000
>>> (XEN) 0TH[0x0] = 0xb8468f7f
>>> 
>>> [snip]
>>> 
>>> If this is expected then is there any plan to make QEMU work as well?
>>> 
>>> I see [1] says that "Only stage 1 and AArch64 PTW are supported." on 
>>> QEMU side.
>> Just for clarication, you are trying to boot Xen on QEMU, right?
> Exactly
>> You might be able to use the stage-1 page-tables to isolate each device 
>> in Xen. However, I don't think you will be able to share the P2M because 
>> the page-tables layout between stage-1 and stage-2 is different.
> So, it is even more work then
 Overall it would make more sense to spend some time adding proper support 
 in Qemu then trying to modify the driver to support Qemu right now.
 
>>> We are interested in QEMU/SMMUv3 as a flexible platform for PCI 
>>> passthrough
>>> 
>>> implementation, so it could allow testing different setups and 
>>> configurations with QEMU.
>> I would recommend to get the SMMU supporting supporting stage-2 
>> page-tables.
> You mean in QEMU?
 See before.
 
>> Regardless that, I think Xen should be able to say the SMMU is not 
>> supported rather than crashing.
> Yes, that would be nice
 Fully agree and we will look into that.
 
 Anything you could share so that we could quickly reproduce your setup 
 would be more then great.
>>> Nothing special,
>>> 
>>> qemu/aarch64-softmmu/qemu-system-aarch64 -machine type=virt -machine 
>>> virt,gic-version=2 \
>>> 
>>> -machine virtualization=true -cpu cortex-a57 -smp 4 -m 2048 -nic 
>>> user,hostfwd=tcp:127.0.0.1:-:22 \
>>> 
>>> -nographic -serial mon:stdio [..snip..]
>>> 
>>> I also set iommu to smmuv3 in my tests, QEMU emulator version 4.2.1
>> I just checked and confirmed that QEMU is booting with XEN SMMUv3 patch and 
>> XEN is able to say SMMU translation is not supported. As XEN supports 
>> Stage-2 translation and QEMU supports Stage-1 only.
>> 
>> 
>> (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
>> (XEN) SMMUv3: /smmuv3@905: IDR0.COHACC overridden by FW configuration 
>> (false)
>> (XEN) SMMUv3: /smmuv3@905: no translation support!
>> (XEN) I/O virtualisation disabled
>> 
>> Only difference I observed is that you have to add option "-machine 
>> virt,iommu=smmuv3 “ when launching the QEMU.
> I do use the option

I used "-machine virt,iommu=smmuv3 “  option while creating the virt-dtb and 
while launching the QEMU.
I also observed the same error what you observed if I am not using the 
"-machine virt,iommu=smmuv3 “ options when launching the QEMU so I thought this 
might be case for you also but anyways you have use the options it might be 
other issue.

>> 
>> Please let me know if it also works for you.
> 
> Well, I should have reported that earlier that I do not use the staging Xen 
> at the moment,
> 
> it is 4.14.0. So, can this be a problem with that Xen version?

I don’t think so this is the problem with the XEN version.
> 
> Anyways, if it works with the staging then everything looks ok
> 
> Thank you,
> 
> Oleksandr
> 
>> 
 Regards
 Bertrand
 
>> Cheers,
>> 
> Thank you,
> 
> Oleksandr

Regards,
Rahul

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

[Julien Grall]

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 +1,12 @@

config HAS_PCI
bool
+
+config PCI_ATS
+   bool "PCI ATS support"
+   default y
+   depends on X86 && HAS_PCI
+   ---help---
+Enable PCI Address Translation Services.
+
+If unsure, say Y.


Support for "---help---" having gone away in Linux, I think we'd
better not add new instances. Also indentation of help content
typically is by a tab and two spaces. With these two adjusted

Reviewed-by: Jan Beulich 


Initially I wanted to merely reply indicating I'd be fine making
these changes while committing, but there are two more things
(and I withdraw my R-b): For one, isn't strict pci_dev's ats
field now unused when !PCI_ATS? If so, if should get an #ifdef
added.


Yes, I tried to #ifdef ats field in struct pci_dev but after doing that I found 
that I have to modify the
code related to x86  iotlb flush, as I have limited knowledge about how iotlb 
flush works for
x86 so I decided not to modify that part of the code.

I already compiled the x86 with !PCI_ATS and is having same behaviour as command 
line options "ats=false” with unused struct pci_dev ats field.


And then, what exactly is it in ats.c that's x86-specific?
Shouldn't the whole file instead be moved one level up, and be
usable by Arm right away?


Yes, you are right ats.c file is not x86 specific, but not tested for ARM so I 
thought we will move the ats.c file to common code once ATS code is 
tested/implemented for ARM.

disable_ats_device() is referenced in common "passthrough/pci.c" file  and defined in 
"x86/ats.c" therefore I decided to introduce the PCI_ATS option for X86.
As I am not sure on ARM how the ATS functionality is going to be implemented.

There are three ways to fix the compilation error for ARM related to 
disable_ats_device() function.

1. Introduce the PCI_ATS config option for x86 and enabled it by default for X86 and 
having same behaviour as  command line options for !PCi_ATS  as "ats=false”


I'll be happy to see the config option retained, but that's
orthogonal to the goals here.


2. disable_ats_device() is called by iommu_dev_iotlb_flush_timeout () that is 
as per my understanding is x86 specific ( not sure please confirm).
Move iommu_dev_iotlb_flush_timeout () to "passthrough/x86/iommu.c” now and move 
the ats.c file to common code once ATS code is tested for ARM.


While the function is currently used by VT-d code only, I again
don't see what's x86-specific about it. Hence ...

The ATS code looks arch-agnostic. So I agree with this statement.




3. Move x86/ats.c file one level up , fixed compilation error now and if on ARM 
platforms going to implement the ATS functionality different from
x86 we have to move ats.c file back to x86 directory


... I view this as the only "option" among the ones you name.


+1.

Cheers,

--
Julien Grall

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

[Olaf Hering]

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
@@ -1357,7 +1357,7 @@ All the specified CPUs that can be added to the cpupool 
will be added
 to it. If some CPU can't (e.g., because they're already part of another
 cpupool), an error is reported about each one of them.
 
-=item B I
+=item B I I
 
 Removes one or more CPUs or NUMA nodes from I. CPUs and NUMA
 nodes can be specified as single CPU/node IDs or as ranges, using the

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

[Oleksandr Andrushchenko]

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, Julien!

 On 10/30/20 7:18 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 30/10/2020 10:44, Oleksandr Andrushchenko wrote:
>> On 10/20/20 6:25 PM, Rahul Singh wrote:
>>> Add support for ARM architected SMMUv3 implementations. It is based on
>>> the Linux SMMUv3 driver.
>>>
>>> Major differences between the Linux driver are as follows:
>>> 1. Only Stage-2 translation is supported as compared to the Linux driver
>>>   that supports both Stage-1 and Stage-2 translations.
>> First of all thank you for the efforts!
>>
>> I tried the patch with QEMU and would like to know if my understanding 
>> correct
>>
>> that this combination will not work as of now:
>>
>> (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
>> (XEN) Data Abort Trap. Syndrome=0x1940010
>> (XEN) Walking Hypervisor VA 0x40031000 on CPU0 via TTBR 
>> 0xb8469000
>> (XEN) 0TH[0x0] = 0xb8468f7f
>>
>> [snip]
>>
>> If this is expected then is there any plan to make QEMU work as well?
>>
>> I see [1] says that "Only stage 1 and AArch64 PTW are supported." on 
>> QEMU side.
> Just for clarication, you are trying to boot Xen on QEMU, right?
 Exactly
> You might be able to use the stage-1 page-tables to isolate each device 
> in Xen. However, I don't think you will be able to share the P2M because 
> the page-tables layout between stage-1 and stage-2 is different.
 So, it is even more work then
>>> Overall it would make more sense to spend some time adding proper support 
>>> in Qemu then trying to modify the driver to support Qemu right now.
>>>
>> We are interested in QEMU/SMMUv3 as a flexible platform for PCI 
>> passthrough
>>
>> implementation, so it could allow testing different setups and 
>> configurations with QEMU.
> I would recommend to get the SMMU supporting supporting stage-2 
> page-tables.
 You mean in QEMU?
>>> See before.
>>>
> Regardless that, I think Xen should be able to say the SMMU is not 
> supported rather than crashing.
 Yes, that would be nice
>>> Fully agree and we will look into that.
>>>
>>> Anything you could share so that we could quickly reproduce your setup 
>>> would be more then great.
>> Nothing special,
>>
>> qemu/aarch64-softmmu/qemu-system-aarch64 -machine type=virt -machine 
>> virt,gic-version=2 \
>>
>> -machine virtualization=true -cpu cortex-a57 -smp 4 -m 2048 -nic 
>> user,hostfwd=tcp:127.0.0.1:-:22 \
>>
>> -nographic -serial mon:stdio [..snip..]
>>
>> I also set iommu to smmuv3 in my tests, QEMU emulator version 4.2.1
> I just checked and confirmed that QEMU is booting with XEN SMMUv3 patch and 
> XEN is able to say SMMU translation is not supported. As XEN supports Stage-2 
> translation and QEMU supports Stage-1 only.
>
>
> (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
> (XEN) SMMUv3: /smmuv3@905: IDR0.COHACC overridden by FW configuration 
> (false)
> (XEN) SMMUv3: /smmuv3@905: no translation support!
> (XEN) I/O virtualisation disabled
>
> Only difference I observed is that you have to add option "-machine 
> virt,iommu=smmuv3 “ when launching the QEMU.
I do use the option
>
> Please let me know if it also works for you.

Well, I should have reported that earlier that I do not use the staging Xen at 
the moment,

it is 4.14.0. So, can this be a problem with that Xen version?

Anyways, if it works with the staging then everything looks ok

Thank you,

Oleksandr

>   
>>> Regards
>>> Bertrand
>>>
> Cheers,
>
 Thank you,

 Oleksandr

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

[Rahul Singh]

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 Oleksandr,
 
 On 30/10/2020 10:44, Oleksandr Andrushchenko wrote:
> On 10/20/20 6:25 PM, Rahul Singh wrote:
>> Add support for ARM architected SMMUv3 implementations. It is based on
>> the Linux SMMUv3 driver.
>> 
>> Major differences between the Linux driver are as follows:
>> 1. Only Stage-2 translation is supported as compared to the Linux driver
>>  that supports both Stage-1 and Stage-2 translations.
> First of all thank you for the efforts!
> 
> I tried the patch with QEMU and would like to know if my understanding 
> correct
> 
> that this combination will not work as of now:
> 
> (XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
> (XEN) Data Abort Trap. Syndrome=0x1940010
> (XEN) Walking Hypervisor VA 0x40031000 on CPU0 via TTBR 0xb8469000
> (XEN) 0TH[0x0] = 0xb8468f7f
> 
> [snip]
> 
> If this is expected then is there any plan to make QEMU work as well?
> 
> I see [1] says that "Only stage 1 and AArch64 PTW are supported." on QEMU 
> side.
 Just for clarication, you are trying to boot Xen on QEMU, right?
>>> Exactly
 You might be able to use the stage-1 page-tables to isolate each device in 
 Xen. However, I don't think you will be able to share the P2M because the 
 page-tables layout between stage-1 and stage-2 is different.
>>> So, it is even more work then
>> Overall it would make more sense to spend some time adding proper support in 
>> Qemu then trying to modify the driver to support Qemu right now.
>> 
> 
> We are interested in QEMU/SMMUv3 as a flexible platform for PCI 
> passthrough
> 
> implementation, so it could allow testing different setups and 
> configurations with QEMU.
 I would recommend to get the SMMU supporting supporting stage-2 
 page-tables.
>>> You mean in QEMU?
>> See before.
>> 
 Regardless that, I think Xen should be able to say the SMMU is not 
 supported rather than crashing.
>>> Yes, that would be nice
>> Fully agree and we will look into that.
>> 
>> Anything you could share so that we could quickly reproduce your setup would 
>> be more then great.
> 
> Nothing special,
> 
> qemu/aarch64-softmmu/qemu-system-aarch64 -machine type=virt -machine 
> virt,gic-version=2 \
> 
> -machine virtualization=true -cpu cortex-a57 -smp 4 -m 2048 -nic 
> user,hostfwd=tcp:127.0.0.1:-:22 \
> 
> -nographic -serial mon:stdio [..snip..]
> 
> I also set iommu to smmuv3 in my tests, QEMU emulator version 4.2.1

I just checked and confirmed that QEMU is booting with XEN SMMUv3 patch and XEN 
is able to say SMMU translation is not supported. As XEN supports Stage-2 
translation and QEMU supports Stage-1 only.


(XEN) SMMUv3: /smmuv3@905: SMMUv3: DT value = eventq
(XEN) SMMUv3: /smmuv3@905: IDR0.COHACC overridden by FW configuration 
(false)
(XEN) SMMUv3: /smmuv3@905: no translation support!
(XEN) I/O virtualisation disabled

Only difference I observed is that you have to add option "-machine 
virt,iommu=smmuv3 “ when launching the QEMU.

Please let me know if it also works for you.
 
> 
>> 
>> Regards
>> Bertrand
>> 
 Cheers,
 
>>> Thank you,
>>> 
>>> Oleksandr

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

[Jan Beulich]

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 @@

 config HAS_PCI
bool
 +
 +config PCI_ATS
 +  bool "PCI ATS support"
 +  default y
 +  depends on X86 && HAS_PCI
 +  ---help---
 +   Enable PCI Address Translation Services.
 +
 +   If unsure, say Y.
>>>
>>> Support for "---help---" having gone away in Linux, I think we'd
>>> better not add new instances. Also indentation of help content
>>> typically is by a tab and two spaces. With these two adjusted
>>>
>>> Reviewed-by: Jan Beulich 
>>
>> Initially I wanted to merely reply indicating I'd be fine making
>> these changes while committing, but there are two more things
>> (and I withdraw my R-b): For one, isn't strict pci_dev's ats
>> field now unused when !PCI_ATS? If so, if should get an #ifdef
>> added.
> 
> Yes, I tried to #ifdef ats field in struct pci_dev but after doing that I 
> found that I have to modify the 
> code related to x86  iotlb flush, as I have limited knowledge about how iotlb 
> flush works for 
> x86 so I decided not to modify that part of the code. 
> 
> I already compiled the x86 with !PCI_ATS and is having same behaviour as 
> command line options "ats=false” with unused struct pci_dev ats field.
> 
>> And then, what exactly is it in ats.c that's x86-specific?
>> Shouldn't the whole file instead be moved one level up, and be
>> usable by Arm right away?
> 
> Yes, you are right ats.c file is not x86 specific, but not tested for ARM so 
> I thought we will move the ats.c file to common code once ATS code is 
> tested/implemented for ARM.
> 
> disable_ats_device() is referenced in common "passthrough/pci.c" file  and 
> defined in "x86/ats.c" therefore I decided to introduce the PCI_ATS option 
> for X86. 
> As I am not sure on ARM how the ATS functionality is going to be implemented. 
> 
> There are three ways to fix the compilation error for ARM related to 
> disable_ats_device() function.
> 
> 1. Introduce the PCI_ATS config option for x86 and enabled it by default for 
> X86 and having same behaviour as  command line options for !PCi_ATS  as 
> "ats=false”

I'll be happy to see the config option retained, but that's
orthogonal to the goals here.

> 2. disable_ats_device() is called by iommu_dev_iotlb_flush_timeout () that is 
> as per my understanding is x86 specific ( not sure please confirm).
> Move iommu_dev_iotlb_flush_timeout () to "passthrough/x86/iommu.c” now and 
> move the ats.c file to common code once ATS code is tested for ARM.

While the function is currently used by VT-d code only, I again
don't see what's x86-specific about it. Hence ...

> 3. Move x86/ats.c file one level up , fixed compilation error now and if on 
> ARM platforms going to implement the ATS functionality different from
> x86 we have to move ats.c file back to x86 directory 

... I view this as the only "option" among the ones you name.

Jan

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

[osstest service owner]

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  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  2a5f9f6a6932214fda76b9b3c03e024772882d34
baseline version:
 xen  957708c2d1ae25d7375abd5e5e70c3043d64f1f1

Last test of basis   156502  2020-11-06 03:01:22 Z0 days
Testing same since   156523  2020-11-06 10:00:26 Z0 days1 attempts


People who touched revisions under test:
  Juergen Gross 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   957708c2d1..2a5f9f6a69  2a5f9f6a6932214fda76b9b3c03e024772882d34 -> smoke

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

[Rahul Singh]

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 PCI_ATS
>>> +   bool "PCI ATS support"
>>> +   default y
>>> +   depends on X86 && HAS_PCI
>>> +   ---help---
>>> +Enable PCI Address Translation Services.
>>> +
>>> +If unsure, say Y.
>> 
>> Support for "---help---" having gone away in Linux, I think we'd
>> better not add new instances. Also indentation of help content
>> typically is by a tab and two spaces. With these two adjusted
>> 
>> Reviewed-by: Jan Beulich 
> 
> Initially I wanted to merely reply indicating I'd be fine making
> these changes while committing, but there are two more things
> (and I withdraw my R-b): For one, isn't strict pci_dev's ats
> field now unused when !PCI_ATS? If so, if should get an #ifdef
> added.

Yes, I tried to #ifdef ats field in struct pci_dev but after doing that I found 
that I have to modify the 
code related to x86  iotlb flush, as I have limited knowledge about how iotlb 
flush works for 
x86 so I decided not to modify that part of the code. 

I already compiled the x86 with !PCI_ATS and is having same behaviour as 
command line options "ats=false” with unused struct pci_dev ats field.

> And then, what exactly is it in ats.c that's x86-specific?
> Shouldn't the whole file instead be moved one level up, and be
> usable by Arm right away?

Yes, you are right ats.c file is not x86 specific, but not tested for ARM so I 
thought we will move the ats.c file to common code once ATS code is 
tested/implemented for ARM.

disable_ats_device() is referenced in common "passthrough/pci.c" file  and 
defined in "x86/ats.c" therefore I decided to introduce the PCI_ATS option for 
X86. 
As I am not sure on ARM how the ATS functionality is going to be implemented. 

There are three ways to fix the compilation error for ARM related to 
disable_ats_device() function.

1. Introduce the PCI_ATS config option for x86 and enabled it by default for 
X86 and having same behaviour as  command line options for !PCi_ATS  as 
"ats=false”

2. disable_ats_device() is called by iommu_dev_iotlb_flush_timeout () that is 
as per my understanding is x86 specific ( not sure please confirm).
Move iommu_dev_iotlb_flush_timeout () to "passthrough/x86/iommu.c” now and move 
the ats.c file to common code once ATS code is tested for ARM.

3. Move x86/ats.c file one level up , fixed compilation error now and if on ARM 
platforms going to implement the ATS functionality different from
x86 we have to move ats.c file back to x86 directory 

Please suggest us how we can proceed further on this.

> 
> Jan

Regards,
Rahul

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

[Rahul Singh]

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 yes I will fix in next version.
> 
>> @@ -1418,12 +1417,7 @@ static int assign_device(struct domain *d, u16 seg, 
>> u8 bus, u8 devfn, u32 flag)
>> if ( !is_iommu_enabled(d) )
>> return 0;
>> 
>> -/* Prevent device assign if mem paging or mem sharing have been 
>> - * enabled for this domain */
>> -if ( d != dom_io &&
>> - unlikely(mem_sharing_enabled(d) ||
>> -  vm_event_check_ring(d->vm_event_paging) ||
>> -  p2m_get_hostp2m(d)->global_logdirty) )
>> +if( !arch_iommu_usable(d) )
>> return -EXDEV;
> 
> While iirc I did suggest this name, seeing it used here leaves me
> somewhat unhappy with the name, albeit I also can't think of any
> better alternative right now. Maybe arch_iommu_use_permitted()?

Ok I will modify as per your suggestion.
> 
>> @@ -315,6 +316,18 @@ int iommu_update_ire_from_msi(
>>? iommu_call(_ops, update_ire_from_msi, msi_desc, msg) : 0;
>> }
>> 
>> +bool_t arch_iommu_usable(struct domain *d)
> 
> Just bool please and I very much hope the parameter can be const.

Ok I will fix in next version.
> 
>> +{
>> +
>> +/* Prevent device assign if mem paging or mem sharing have been
>> + * enabled for this domain */
> 
> Please correct comment style as you move it.

Ok. 
> 
>> +if ( d != dom_io && unlikely(mem_sharing_enabled(d) ||
>> +vm_event_check_ring(d->vm_event_paging) ||
>> +p2m_get_hostp2m(d)->global_logdirty) )
> 
> You've screwed up indentation, and I don't see why ...

I will fix in next version.

> 
>> +return false;
>> +else
>> +return true;
>> +}
> 
> ... this can't be a simple single return statement anyway:
> 
>return d == dom_io ||
>   likely(!mem_sharing_enabled(d) &&
>  !vm_event_check_ring(d->vm_event_paging) &&
>  !p2m_get_hostp2m(d)->global_logdirty);
> 
> In the course of moving I'd also suggest dropping the use of
> likely() here: The way it's used (on an && expression) isn't
> normally having much effect anyway. If anything it should imo
> be
> 
>return d == dom_io ||
>   (likely(!mem_sharing_enabled(d)) &&
>likely(!vm_event_check_ring(d->vm_event_paging)) &&
>likely(!p2m_get_hostp2m(d)->global_logdirty));
> 
> Any transformation to this effect wants mentioning in the
> description, though.

Ok I will modify as per your suggestion.
> 
> Jan

Regards,
Rahul

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

[Ash Wilding]

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 as they are copying the
>> Linux versions wholesale into Xen.
>
> While I agree it would help the review, it would break Xen
> bisectability. Although, it should be feasible to fold all the patches
> in one on committing.
> 
> If you are going to split the patches then I would suggest the
> following split:
>1) Remove Xen atomic headers
>2) Add a verbatim copy of the Linux headers
>3) Modify them for Xen
> 
> With this approach, we can focus on just Xen changes rather than
> having to review the Linux code as well.

Ah-ha, yes, that would be better, I'll do that.


>
> We usually keep Linux coding style when a file mainly contains Linux
> code. This is making easier to port future fixes from Linux to Xen.

Understood, I'll drop those updates,


>
> Regarding the review, I have quite a bit of backlog for Xen at the
> moment. I will try to review the series in the next couple of weeks.
> I hope that's fine with you.

No problem at all, and actually that gives me a chance to find some
spare time to post an updated series with the approach you outlined
above (I'm probably not going to get a chance to work on this for at
least a week now).


Many thanks for the feedback :-)

Cheers,
Ash.

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

[Julien Grall]

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 easier to read seeing as they are copying the Linux
versions wholesale into Xen.


While I agree it would help the review, it would break Xen 
bisectability. Although, it should be feasible to fold all the patches 
in one on committing.


If you are going to split the patches then I would suggest the following 
split:

  1) Remove Xen atomic headers
  2) Add a verbatim copy of the Linux headers
  3) Modify them for Xen

With this approach, we can focus on just Xen changes rather than having 
to review the Linux code as well.




I'll do that for V1 when we get there, but for now to aid in readability
I've pasted the complete header files below. While doing this I also
spent some time last night tidying up them up to be in line with the Xen
coding style.


We usually keep Linux coding style when a file mainly contains Linux 
code. This is making easier to port future fixes from Linux to Xen.


Regarding the review, I have quite a bit of backlog for Xen at the 
moment. I will try to review the series in the next couple of weeks.

I hope that's fine with you.

Cheers,

--
Julien Grall

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

[Ash Wilding]

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 to aid in readability
I've pasted the complete header files below. While doing this I also
spent some time last night tidying up them up to be in line with the Xen
coding style.

Similar email incoming on patch #5 too.

Thanks,
Ash.



 xen/include/asm-arm/arm64/atomic.h 


/*
 * Taken from Linux 5.10-rc2 (last commit 3cea11cd5)
 *
 * Summary of changes:
 *  - Rename header include guard to reflect Xen directory structure
 *  - Drop redundant includes and redirect others to Xen equivalents
 *  - Rename declarations from arch_atomic_() to atomic_()
 *  - Drop atomic64_t helper declarations
 *  - Convert tabs to spaces in line with coding style
 *  - Tidy up indentations
 *  - Add Emacs file local variables
 *
 * Copyright (C) 1996 Russell King.
 * Copyright (C) 2002 Deep Blue Solutions Ltd.
 * Copyright (C) 2012 ARM Ltd.
 * SPDX-License-Identifier: GPL-2.0-only
 */
#ifndef __ASM_ARM_ARM64_ATOMIC_H
#define __ASM_ARM_ARM64_ATOMIC_H

#include 
#include 

#include "lse.h"
#include "cmpxchg.h"

#define ATOMIC_OP(op)   \
static inline void op(int i, atomic_t *v)   \
{   \
__lse_ll_sc_body(op, i, v); \
}

ATOMIC_OP(atomic_andnot)
ATOMIC_OP(atomic_or)
ATOMIC_OP(atomic_xor)
ATOMIC_OP(atomic_add)
ATOMIC_OP(atomic_and)
ATOMIC_OP(atomic_sub)

#undef ATOMIC_OP

#define ATOMIC_FETCH_OP(name, op)   \
static inline int op##name(int i, atomic_t *v)  \
{   \
return __lse_ll_sc_body(op##name, i, v);\
}

#define ATOMIC_FETCH_OPS(op)\
ATOMIC_FETCH_OP(_relaxed, op)   \
ATOMIC_FETCH_OP(_acquire, op)   \
ATOMIC_FETCH_OP(_release, op)   \
ATOMIC_FETCH_OP(, op)

ATOMIC_FETCH_OPS(atomic_fetch_andnot)
ATOMIC_FETCH_OPS(atomic_fetch_or)
ATOMIC_FETCH_OPS(atomic_fetch_xor)
ATOMIC_FETCH_OPS(atomic_fetch_add)
ATOMIC_FETCH_OPS(atomic_fetch_and)
ATOMIC_FETCH_OPS(atomic_fetch_sub)
ATOMIC_FETCH_OPS(atomic_add_return)
ATOMIC_FETCH_OPS(atomic_sub_return)

#undef ATOMIC_FETCH_OP
#undef ATOMIC_FETCH_OPS
#define atomic_read(v)  __READ_ONCE((v)->counter)
#define atomic_set(v, i)__WRITE_ONCE(((v)->counter), (i))

#define atomic_add_return_relaxed   atomic_add_return_relaxed
#define atomic_add_return_acquire   atomic_add_return_acquire
#define atomic_add_return_release   atomic_add_return_release
#define atomic_add_return   atomic_add_return

#define atomic_sub_return_relaxed   atomic_sub_return_relaxed
#define atomic_sub_return_acquire   atomic_sub_return_acquire
#define atomic_sub_return_release   atomic_sub_return_release
#define atomic_sub_return   atomic_sub_return

#define atomic_fetch_add_relaxedatomic_fetch_add_relaxed
#define atomic_fetch_add_acquireatomic_fetch_add_acquire
#define atomic_fetch_add_releaseatomic_fetch_add_release
#define atomic_fetch_addatomic_fetch_add

#define atomic_fetch_sub_relaxedatomic_fetch_sub_relaxed
#define atomic_fetch_sub_acquireatomic_fetch_sub_acquire
#define atomic_fetch_sub_releaseatomic_fetch_sub_release
#define atomic_fetch_subatomic_fetch_sub

#define atomic_fetch_and_relaxedatomic_fetch_and_relaxed
#define atomic_fetch_and_acquireatomic_fetch_and_acquire
#define atomic_fetch_and_releaseatomic_fetch_and_release
#define atomic_fetch_andatomic_fetch_and

#define atomic_fetch_andnot_relaxed atomic_fetch_andnot_relaxed
#define atomic_fetch_andnot_acquire atomic_fetch_andnot_acquire
#define atomic_fetch_andnot_release atomic_fetch_andnot_release
#define atomic_fetch_andnot atomic_fetch_andnot

#define atomic_fetch_or_relaxed atomic_fetch_or_relaxed
#define atomic_fetch_or_acquire atomic_fetch_or_acquire
#define atomic_fetch_or_release atomic_fetch_or_release
#define atomic_fetch_or atomic_fetch_or

#define atomic_fetch_xor_relaxedatomic_fetch_xor_relaxed
#define atomic_fetch_xor_acquireatomic_fetch_xor_acquire
#define atomic_fetch_xor_releaseatomic_fetch_xor_release
#define atomic_fetch_xoratomic_fetch_xor

#define atomic_xchg_relaxed(v, new) \
xchg_relaxed(&((v)->counter), (new))
#define atomic_xchg_acquire(v, new) \
xchg_acquire(&((v)->counter), (new))
#define atomic_xchg_release(v, 

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

[Ash Wilding]

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 for V1 when we get there, but for now to aid in readability
I've pasted the complete header files below.  While doing this I also
spent some time last night tidying up them up to be in line with the Xen
coding style.

Thanks,
Ash.



 xen/include/asm-arm/arm32/atomic.h 


/*
 * Taken from Linux 5.10-rc2 (last commit 3cea11cd5)
 *
 * Summary of changes:
 *  - Drop redundant includes and redirect others to Xen equivalents
 *  - Rename header include guard to reflect Xen directory structure
 *  - Drop atomic64_t helper declarations
 *  - Drop pre-Armv6 support
 *  - Redirect READ_ONCE/WRITE_ONCE to __* equivalents in compiler.h
 *  - Add explicit atomic_add_return() and atomic_sub_return() as
 *   Linux doesn't define these for arm32. Here we just sandwich
 *   the atomic__return_relaxed() calls with smp_mb()s.
 *  - Convert tabs to spaces in line with coding style
 *  - Tidy up indentations
 *  - Add Emacs file local variables
 *
 * Copyright (C) 1996 Russell King.
 * Copyright (C) 2002 Deep Blue Solutions Ltd.
 * SPDX-License-Identifier: GPL-2.0-only
 */
#ifndef __ASM_ARM_ARM32_ATOMIC_H
#define __ASM_ARM_ARM32_ATOMIC_H

#include 
#include 
#include 
#include "system.h"
#include "cmpxchg.h"

/*
 * On ARM, ordinary assignment (str instruction) doesn't clear the local
 * strex/ldrex monitor on some implementations. The reason we can use it for
 * atomic_set() is the clrex or dummy strex done on every exception return.
 */
#define atomic_read(v)  __READ_ONCE((v)->counter)
#define atomic_set(v,i) __WRITE_ONCE(((v)->counter), (i))

/*
 * ARMv6 UP and SMP safe atomic ops.  We use load exclusive and
 * store exclusive to ensure that these are atomic.  We may loop
 * to ensure that the update happens.
 */

#define ATOMIC_OP(op, c_op, asm_op) \
static inline void atomic_##op(int i, atomic_t *v)  \
{   \
unsigned long tmp;  \
int result; \
\
prefetchw(>counter); \
__asm__ __volatile__("@ atomic_" #op "\n"   \
"1:ldrex%0, [%3]\n" \
"" #asm_op "%0, %0, %4\n"   \
"strex%1, %0, [%3]\n"   \
"teq%1, #0\n"   \
"bne1b" \
: "=" (result), "=" (tmp), "+Qo" (v->counter)   \
: "r" (>counter), "Ir" (i)   \
: "cc");\
}   \

#define ATOMIC_OP_RETURN(op, c_op, asm_op)  \
static inline int atomic_##op##_return_relaxed(int i, atomic_t *v)  \
{   \
unsigned long tmp;  \
int result; \
\
prefetchw(>counter); \
\
__asm__ __volatile__("@ atomic_" #op "_return\n"\
"1:ldrex%0, [%3]\n" \
"" #asm_op "%0, %0, %4\n"   \
"strex%1, %0, [%3]\n"   \
"teq%1, #0\n"   \
"bne1b" \
: "=" (result), "=" (tmp), "+Qo" (v->counter)   \
: "r" (>counter), "Ir" (i)   \
: "cc");\
\
return result;  \
}

#define ATOMIC_FETCH_OP(op, c_op, asm_op)   \
static inline 

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

[Alex Bennée]

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 Mathieu-Daudé 
>
>> 
>> Signed-off-by: Alex Bennée 
>> ---
>>  stubs/xen-hw-stub.c | 4 
>>  1 file changed, 4 deletions(-)
>> 
>> diff --git a/stubs/xen-hw-stub.c b/stubs/xen-hw-stub.c
>> index 2ea8190921..15f3921a76 100644
>> --- a/stubs/xen-hw-stub.c
>> +++ b/stubs/xen-hw-stub.c
>> @@ -10,10 +10,6 @@
>>  #include "hw/xen/xen.h"
>>  #include "hw/xen/xen-x86.h"
>>  
>> -void xenstore_store_pv_console_info(int i, Chardev *chr)
>> -{
>> -}
>> -
>>  int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
>>  {
>>  return -1;
>> 


-- 
Alex Bennée

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

[Rahul Singh]

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 

Removed in this patch series 3/4
>> #include 
>> #include 

I will remove in next version.

>> #include 

It is required for PCI_VENDOR_ID_INTEL that is referenced in apply_quirks 
function.

> 
> I think this hunk wants dropping - struct domain continues to be used
> in this file, for example.
> 
>> @@ -847,71 +845,6 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
>> return ret;
>> }
>> 
>> -static int pci_clean_dpci_irq(struct domain *d,
>> -  struct hvm_pirq_dpci *pirq_dpci, void *arg)
>> -{
>> -struct dev_intx_gsi_link *digl, *tmp;
>> -
>> -pirq_guest_unbind(d, dpci_pirq(pirq_dpci));
>> -
>> -if ( pt_irq_need_timer(pirq_dpci->flags) )
>> -kill_timer(_dpci->timer);
>> -
>> -list_for_each_entry_safe ( digl, tmp, _dpci->digl_list, list )
>> -{
>> -list_del(>list);
>> -xfree(digl);
>> -}
>> -
>> -radix_tree_delete(>pirq_tree, dpci_pirq(pirq_dpci)->pirq);
>> -
>> -if ( !pt_pirq_softirq_active(pirq_dpci) )
>> -return 0;
>> -
>> -domain_get_irq_dpci(d)->pending_pirq_dpci = pirq_dpci;
>> -
>> -return -ERESTART;
>> -}
>> -
>> -static int pci_clean_dpci_irqs(struct domain *d)
>> -{
>> -struct hvm_irq_dpci *hvm_irq_dpci = NULL;
>> -
>> -if ( !is_iommu_enabled(d) )
>> -return 0;
>> -
>> -if ( !is_hvm_domain(d) )
>> -return 0;
>> -
>> -spin_lock(>event_lock);
>> -hvm_irq_dpci = domain_get_irq_dpci(d);
>> -if ( hvm_irq_dpci != NULL )
>> -{
>> -int ret = 0;
>> -
>> -if ( hvm_irq_dpci->pending_pirq_dpci )
>> -{
>> -if ( pt_pirq_softirq_active(hvm_irq_dpci->pending_pirq_dpci) )
>> - ret = -ERESTART;
>> -else
>> - hvm_irq_dpci->pending_pirq_dpci = NULL;
>> -}
>> -
>> -if ( !ret )
>> -ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
>> -if ( ret )
>> -{
>> -spin_unlock(>event_lock);
>> -return ret;
>> -}
>> -
>> -hvm_domain_irq(d)->dpci = NULL;
>> -free_hvm_irq_dpci(hvm_irq_dpci);
>> -}
>> -spin_unlock(>event_lock);
>> -return 0;
>> -}
> 
> If this code gets moved, I think it ought to move into
> xen/drivers/passthrough/io.c, as that's where all the companion code
> sits. (The file as a whole, getting built for x86/HVM only, may want
> moving to xen/drivers/passthrough/x86/ if the underlying model isn't
> suitable for Arm. Then it probably also would want to be named hvm.c,
> to express its limited purpose.)


Ok I will move the code to the file io.c and move that file to x86 directory 
and rename it hvm.c
> 
> Jan

Regards,
Rahul

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

[Jan Beulich]

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.

--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3084,6 +3084,7 @@ static void sh_unshadow_for_p2m_change(s
 mfn_t omfn = l1e_get_mfn(old);
 unsigned int oflags = l1e_get_flags(old);
 p2m_type_t p2mt = p2m_flags_to_type(oflags);
+bool flush = false;
 
 /*
  * If there are any shadows, update them.  But if shadow_teardown()
@@ -3108,7 +3109,7 @@ static void sh_unshadow_for_p2m_change(s
 {
 sh_remove_all_shadows_and_parents(d, omfn);
 if ( sh_remove_all_mappings(d, omfn, _gfn(gfn)) )
-guest_flush_tlb_mask(d, d->dirty_cpumask);
+flush = true;
 }
 break;
 
@@ -3124,12 +3125,9 @@ static void sh_unshadow_for_p2m_change(s
 if ( p2m_is_valid(p2mt) && mfn_valid(omfn) )
 {
 unsigned int i;
-cpumask_t flushmask;
 mfn_t nmfn = l1e_get_mfn(new);
 l1_pgentry_t *npte = NULL;
 
-cpumask_clear();
-
 /* If we're replacing a superpage with a normal L1 page, map it */
 if ( (l1e_get_flags(new) & _PAGE_PRESENT) &&
  !(l1e_get_flags(new) & _PAGE_PSE) &&
@@ -3147,11 +3145,10 @@ static void sh_unshadow_for_p2m_change(s
 /* This GFN->MFN mapping has gone away */
 sh_remove_all_shadows_and_parents(d, omfn);
 if ( sh_remove_all_mappings(d, omfn, _gfn(gfn + i)) )
-cpumask_or(, , d->dirty_cpumask);
+flush = true;
 }
 omfn = mfn_add(omfn, 1);
 }
-guest_flush_tlb_mask(d, );
 
 if ( npte )
 unmap_domain_page(npte);
@@ -3159,6 +3156,9 @@ static void sh_unshadow_for_p2m_change(s
 
 break;
 }
+
+if ( flush )
+guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_FAST_FAULT_PATH)

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

[Jan Beulich]

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 sh_unshadow_for_p2m_change(s
l1_pgentry_t old, l1_pgentry_t new,
unsigned int level)
 {
+mfn_t omfn = l1e_get_mfn(old);
 unsigned int oflags = l1e_get_flags(old);
+p2m_type_t p2mt = p2m_flags_to_type(oflags);
 
 /*
  * If there are any shadows, update them.  But if shadow_teardown()
@@ -3090,53 +3092,57 @@ static void sh_unshadow_for_p2m_change(s
 if ( unlikely(!d->arch.paging.shadow.total_pages) )
 return;
 
-/* The following assertion is to make sure we don't step on 1GB host
- * page support of HVM guest. */
-ASSERT(!(level > 2 && (oflags & _PAGE_PRESENT) && (oflags & _PAGE_PSE)));
-
-/* If we're removing an MFN from the p2m, remove it from the shadows too */
-if ( level == 1 )
+switch ( level )
 {
-mfn_t mfn = l1e_get_mfn(old);
-p2m_type_t p2mt = p2m_flags_to_type(oflags);
+default:
+/*
+ * The following assertion is to make sure we don't step on 1GB host
+ * page support of HVM guest.
+ */
+ASSERT(!((oflags & _PAGE_PRESENT) && (oflags & _PAGE_PSE)));
+break;
 
-if ( (p2m_is_valid(p2mt) || p2m_is_grant(p2mt)) && mfn_valid(mfn) )
+/* If we're removing an MFN from the p2m, remove it from the shadows too */
+case 1:
+if ( (p2m_is_valid(p2mt) || p2m_is_grant(p2mt)) && mfn_valid(omfn) )
 {
-sh_remove_all_shadows_and_parents(d, mfn);
-if ( sh_remove_all_mappings(d, mfn, _gfn(gfn)) )
+sh_remove_all_shadows_and_parents(d, omfn);
+if ( sh_remove_all_mappings(d, omfn, _gfn(gfn)) )
 guest_flush_tlb_mask(d, d->dirty_cpumask);
 }
-}
+break;
 
-/* If we're removing a superpage mapping from the p2m, we need to check
+/*
+ * If we're removing a superpage mapping from the p2m, we need to check
  * all the pages covered by it.  If they're still there in the new
- * scheme, that's OK, but otherwise they must be unshadowed. */
-if ( level == 2 && (oflags & _PAGE_PRESENT) && (oflags & _PAGE_PSE) )
-{
-unsigned int i;
-cpumask_t flushmask;
-mfn_t omfn = l1e_get_mfn(old);
-mfn_t nmfn = l1e_get_mfn(new);
-l1_pgentry_t *npte = NULL;
-p2m_type_t p2mt = p2m_flags_to_type(oflags);
+ * scheme, that's OK, but otherwise they must be unshadowed.
+ */
+case 2:
+if ( !(oflags & _PAGE_PRESENT) || !(oflags & _PAGE_PSE) )
+break;
 
 if ( p2m_is_valid(p2mt) && mfn_valid(omfn) )
 {
+unsigned int i;
+cpumask_t flushmask;
+mfn_t nmfn = l1e_get_mfn(new);
+l1_pgentry_t *npte = NULL;
+
 cpumask_clear();
 
 /* If we're replacing a superpage with a normal L1 page, map it */
-if ( (l1e_get_flags(new) & _PAGE_PRESENT)
- && !(l1e_get_flags(new) & _PAGE_PSE)
- && mfn_valid(nmfn) )
+if ( (l1e_get_flags(new) & _PAGE_PRESENT) &&
+ !(l1e_get_flags(new) & _PAGE_PSE) &&
+ mfn_valid(nmfn) )
 npte = map_domain_page(nmfn);
 
 gfn &= ~(L1_PAGETABLE_ENTRIES - 1);
 
 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
 {
-if ( !npte
- || !p2m_is_ram(p2m_flags_to_type(l1e_get_flags(npte[i])))
- || !mfn_eq(l1e_get_mfn(npte[i]), omfn) )
+if ( !npte ||
+ !p2m_is_ram(p2m_flags_to_type(l1e_get_flags(npte[i]))) ||
+ !mfn_eq(l1e_get_mfn(npte[i]), omfn) )
 {
 /* This GFN->MFN mapping has gone away */
 sh_remove_all_shadows_and_parents(d, omfn);
@@ -3150,6 +3156,8 @@ static void sh_unshadow_for_p2m_change(s
 if ( npte )
 unmap_domain_page(npte);
 }
+
+break;
 }
 }
 

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

[Jan Beulich]

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 function,
  moving the conditional into there,
- introduce a local variable holding the flags of the old entry.

Signed-off-by: Jan Beulich 
---
v2: New.

--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -135,7 +135,7 @@ static int write_p2m_entry(struct p2m_do
 paging_lock(d);
 
 if ( p2m->write_p2m_entry_pre && gfn != gfn_x(INVALID_GFN) )
-p2m->write_p2m_entry_pre(d, gfn, p, new, level);
+p2m->write_p2m_entry_pre(d, gfn, *p, new, level);
 
 oflags = l1e_get_flags(*p);
 omfn = l1e_get_mfn(*p);
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3078,19 +3078,28 @@ static int shadow_test_disable(struct do
  */
 
 static void sh_unshadow_for_p2m_change(struct domain *d, unsigned long gfn,
-   l1_pgentry_t *p, l1_pgentry_t new,
+   l1_pgentry_t old, l1_pgentry_t new,
unsigned int level)
 {
+unsigned int oflags = l1e_get_flags(old);
+
+/*
+ * If there are any shadows, update them.  But if shadow_teardown()
+ * has already been called then it's not safe to try.
+ */
+if ( unlikely(!d->arch.paging.shadow.total_pages) )
+return;
+
 /* The following assertion is to make sure we don't step on 1GB host
  * page support of HVM guest. */
-ASSERT(!(level > 2 && (l1e_get_flags(*p) & _PAGE_PRESENT) &&
- (l1e_get_flags(*p) & _PAGE_PSE)));
+ASSERT(!(level > 2 && (oflags & _PAGE_PRESENT) && (oflags & _PAGE_PSE)));
 
 /* If we're removing an MFN from the p2m, remove it from the shadows too */
 if ( level == 1 )
 {
-mfn_t mfn = l1e_get_mfn(*p);
-p2m_type_t p2mt = p2m_flags_to_type(l1e_get_flags(*p));
+mfn_t mfn = l1e_get_mfn(old);
+p2m_type_t p2mt = p2m_flags_to_type(oflags);
+
 if ( (p2m_is_valid(p2mt) || p2m_is_grant(p2mt)) && mfn_valid(mfn) )
 {
 sh_remove_all_shadows_and_parents(d, mfn);
@@ -3102,15 +3111,15 @@ static void sh_unshadow_for_p2m_change(s
 /* If we're removing a superpage mapping from the p2m, we need to check
  * all the pages covered by it.  If they're still there in the new
  * scheme, that's OK, but otherwise they must be unshadowed. */
-if ( level == 2 && (l1e_get_flags(*p) & _PAGE_PRESENT) &&
- (l1e_get_flags(*p) & _PAGE_PSE) )
+if ( level == 2 && (oflags & _PAGE_PRESENT) && (oflags & _PAGE_PSE) )
 {
 unsigned int i;
 cpumask_t flushmask;
-mfn_t omfn = l1e_get_mfn(*p);
+mfn_t omfn = l1e_get_mfn(old);
 mfn_t nmfn = l1e_get_mfn(new);
 l1_pgentry_t *npte = NULL;
-p2m_type_t p2mt = p2m_flags_to_type(l1e_get_flags(*p));
+p2m_type_t p2mt = p2m_flags_to_type(oflags);
+
 if ( p2m_is_valid(p2mt) && mfn_valid(omfn) )
 {
 cpumask_clear();
@@ -3144,16 +3153,6 @@ static void sh_unshadow_for_p2m_change(s
 }
 }
 
-static void
-sh_write_p2m_entry_pre(struct domain *d, unsigned long gfn, l1_pgentry_t *p,
-   l1_pgentry_t new, unsigned int level)
-{
-/* If there are any shadows, update them.  But if shadow_teardown()
- * has already been called then it's not safe to try. */
-if ( likely(d->arch.paging.shadow.total_pages != 0) )
- sh_unshadow_for_p2m_change(d, gfn, p, new, level);
-}
-
 #if (SHADOW_OPTIMIZATIONS & SHOPT_FAST_FAULT_PATH)
 static void
 sh_write_p2m_entry_post(struct p2m_domain *p2m, unsigned int oflags)
@@ -3178,7 +3177,7 @@ sh_write_p2m_entry_post(struct p2m_domai
 
 void shadow_p2m_init(struct p2m_domain *p2m)
 {
-p2m->write_p2m_entry_pre  = sh_write_p2m_entry_pre;
+p2m->write_p2m_entry_pre  = sh_unshadow_for_p2m_change;
 p2m->write_p2m_entry_post = sh_write_p2m_entry_post;
 }
 
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -274,7 +274,7 @@ struct p2m_domain {
 void   (*memory_type_changed)(struct p2m_domain *p2m);
 void   (*write_p2m_entry_pre)(struct domain *d,
   unsigned long gfn,
-  l1_pgentry_t *p,
+  l1_pgentry_t old,
   l1_pgentry_t new,
   unsigned int level);
 void   (*write_p2m_entry_post)(struct p2m_domain *p2m,

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

[Jan Beulich]

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) associated with any GFN. (The alternative to this change
would be to actually pass in a correct GFN, which can't be all the same
on every loop iteration.)

Signed-off-by: Jan Beulich 
---
v2: New.

--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -134,7 +134,7 @@ static int write_p2m_entry(struct p2m_do
 
 paging_lock(d);
 
-if ( p2m->write_p2m_entry_pre )
+if ( p2m->write_p2m_entry_pre && gfn != gfn_x(INVALID_GFN) )
 p2m->write_p2m_entry_pre(d, gfn, p, new, level);
 
 oflags = l1e_get_flags(*p);
@@ -290,7 +290,8 @@ p2m_next_level(struct p2m_domain *p2m, v
 {
 new_entry = l1e_from_pfn(pfn | (i << ((level - 1) * 
PAGETABLE_ORDER)),
  flags);
-rc = write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, level);
+rc = write_p2m_entry(p2m, gfn_x(INVALID_GFN), l1_entry + i,
+ new_entry, level);
 if ( rc )
 {
 unmap_domain_page(l1_entry);

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

[Jan Beulich]

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 p2m_flush_nestedp2m() is,
at least from an abstract perspective, also applicable in the shadow
case. Hence it doesn't get a 3rd hook put in place.

The initial comment that was in hap_write_p2m_entry() gets dropped: Its
placement was bogus, and looking back the the commit introducing it
(dd6de3ab9985 "Implement Nested-on-Nested") I can't see either what use
of a p2m it was meant to be associated with.

Signed-off-by: Jan Beulich 
Acked-by: Tim Deegan 
---
RFC: This is effectively the alternative to the suggestion in an earlier
 patch that we might do away with the hook altogether. Of course a
 hybrid approach would also be possible, by using direct calls here
 instead of splitting the hook into two.
---
I'm unsure whether p2m_init_nestedp2m() zapping the "pre" hook is
actually correct, or whether previously the sh_unshadow_for_p2m_change()
invocation was wrongly skipped.

--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -774,55 +774,18 @@ static void hap_update_paging_modes(stru
 put_gfn(d, cr3_gfn);
 }
 
-static int
-hap_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn, l1_pgentry_t *p,
-l1_pgentry_t new, unsigned int level)
+static void
+hap_write_p2m_entry_post(struct p2m_domain *p2m, unsigned int oflags)
 {
 struct domain *d = p2m->domain;
-uint32_t old_flags;
-mfn_t omfn;
-int rc;
 
-/* We know always use the host p2m here, regardless if the vcpu
- * is in host or guest mode. The vcpu can be in guest mode by
- * a hypercall which passes a domain and chooses mostly the first
- * vcpu. */
-
-paging_lock(d);
-old_flags = l1e_get_flags(*p);
-omfn = l1e_get_mfn(*p);
-
-rc = p2m_entry_modify(p2m, p2m_flags_to_type(l1e_get_flags(new)),
-  p2m_flags_to_type(old_flags), l1e_get_mfn(new),
-  omfn, level);
-if ( rc )
-{
-paging_unlock(d);
-return rc;
-}
-
-safe_write_pte(p, new);
-if ( old_flags & _PAGE_PRESENT )
+if ( oflags & _PAGE_PRESENT )
 guest_flush_tlb_mask(d, d->dirty_cpumask);
-
-paging_unlock(d);
-
-if ( nestedhvm_enabled(d) && (old_flags & _PAGE_PRESENT) &&
- !p2m_get_hostp2m(d)->defer_nested_flush &&
- /*
-  * We are replacing a valid entry so we need to flush nested p2ms,
-  * unless the only change is an increase in access rights.
-  */
- (!mfn_eq(omfn, l1e_get_mfn(new)) ||
-  !perms_strictly_increased(old_flags, l1e_get_flags(new))) )
-p2m_flush_nestedp2m(d);
-
-return 0;
 }
 
 void hap_p2m_init(struct p2m_domain *p2m)
 {
-p2m->write_p2m_entry = hap_write_p2m_entry;
+p2m->write_p2m_entry_post = hap_write_p2m_entry_post;
 }
 
 static unsigned long hap_gva_to_gfn_real_mode(
--- a/xen/arch/x86/mm/hap/nested_hap.c
+++ b/xen/arch/x86/mm/hap/nested_hap.c
@@ -71,24 +71,11 @@
 /*NESTED VIRT P2M FUNCTIONS */
 //
 
-int
-nestedp2m_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
-l1_pgentry_t *p, l1_pgentry_t new, unsigned int level)
+void
+nestedp2m_write_p2m_entry_post(struct p2m_domain *p2m, unsigned int oflags)
 {
-struct domain *d = p2m->domain;
-uint32_t old_flags;
-
-paging_lock(d);
-
-old_flags = l1e_get_flags(*p);
-safe_write_pte(p, new);
-
-if (old_flags & _PAGE_PRESENT)
-guest_flush_tlb_mask(d, p2m->dirty_cpumask);
-
-paging_unlock(d);
-
-return 0;
+if ( oflags & _PAGE_PRESENT )
+guest_flush_tlb_mask(p2m->domain, p2m->dirty_cpumask);
 }
 
 //
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -122,17 +122,55 @@ static int write_p2m_entry(struct p2m_do
 {
 struct domain *d = p2m->domain;
 struct vcpu *v = current;
-int rc = 0;
 
 if ( v->domain != d )
 v = d->vcpu ? d->vcpu[0] : NULL;
 if ( likely(v && paging_mode_enabled(d) && paging_get_hostmode(v)) ||
  p2m_is_nestedp2m(p2m) )
-rc = p2m->write_p2m_entry(p2m, gfn, p, new, level);
+{
+unsigned int oflags;
+mfn_t omfn;
+int rc;
+
+paging_lock(d);
+
+if ( p2m->write_p2m_entry_pre )
+p2m->write_p2m_entry_pre(d, gfn, p, new, level);
+
+oflags = l1e_get_flags(*p);
+omfn = l1e_get_mfn(*p);
+
+rc = p2m_entry_modify(p2m, p2m_flags_to_type(l1e_get_flags(new)),
+  p2m_flags_to_type(oflags), l1e_get_mfn(new),
+  omfn, level);
+if ( rc )
+{
+paging_unlock(d);
+return rc;
+}

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

[Jan Beulich]

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
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -780,7 +780,7 @@ hap_write_p2m_entry(struct p2m_domain *p
 {
 struct domain *d = p2m->domain;
 uint32_t old_flags;
-bool_t flush_nestedp2m = 0;
+mfn_t omfn;
 int rc;
 
 /* We know always use the host p2m here, regardless if the vcpu
@@ -790,21 +790,11 @@ hap_write_p2m_entry(struct p2m_domain *p
 
 paging_lock(d);
 old_flags = l1e_get_flags(*p);
-
-if ( nestedhvm_enabled(d) && (old_flags & _PAGE_PRESENT) 
- && !p2m_get_hostp2m(d)->defer_nested_flush ) {
-/* We are replacing a valid entry so we need to flush nested p2ms,
- * unless the only change is an increase in access rights. */
-mfn_t omfn = l1e_get_mfn(*p);
-mfn_t nmfn = l1e_get_mfn(new);
-
-flush_nestedp2m = !(mfn_eq(omfn, nmfn)
-&& perms_strictly_increased(old_flags, l1e_get_flags(new)) );
-}
+omfn = l1e_get_mfn(*p);
 
 rc = p2m_entry_modify(p2m, p2m_flags_to_type(l1e_get_flags(new)),
   p2m_flags_to_type(old_flags), l1e_get_mfn(new),
-  l1e_get_mfn(*p), level);
+  omfn, level);
 if ( rc )
 {
 paging_unlock(d);
@@ -817,7 +807,14 @@ hap_write_p2m_entry(struct p2m_domain *p
 
 paging_unlock(d);
 
-if ( flush_nestedp2m )
+if ( nestedhvm_enabled(d) && (old_flags & _PAGE_PRESENT) &&
+ !p2m_get_hostp2m(d)->defer_nested_flush &&
+ /*
+  * We are replacing a valid entry so we need to flush nested p2ms,
+  * unless the only change is an increase in access rights.
+  */
+ (!mfn_eq(omfn, l1e_get_mfn(new)) ||
+  !perms_strictly_increased(old_flags, l1e_get_flags(new))) )
 p2m_flush_nestedp2m(d);
 
 return 0;

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

[Jan Beulich]

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: Fix build with newer clang ("defined" may not be the result of a
macro expansion).
---
I wonder if !NDEBUG wouldn't better be replaced by CONFIG_DEBUG.

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1012,7 +1012,7 @@ long arch_do_domctl(
 break;
 #endif
 
-#if P2M_AUDIT && defined(CONFIG_HVM)
+#if P2M_AUDIT
 case XEN_DOMCTL_audit_p2m:
 if ( d == currd )
 ret = -EPERM;
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1260,7 +1260,9 @@ int ept_p2m_init(struct p2m_domain *p2m)
 p2m->change_entry_type_global = ept_change_entry_type_global;
 p2m->change_entry_type_range = ept_change_entry_type_range;
 p2m->memory_type_changed = ept_memory_type_changed;
+#if P2M_AUDIT
 p2m->audit_p2m = NULL;
+#endif
 p2m->tlb_flush = ept_tlb_flush;
 
 /* Set the memory type used when accessing EPT paging structures. */
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -971,8 +971,8 @@ static int p2m_pt_change_entry_type_rang
 return err;
 }
 
-#if P2M_AUDIT && defined(CONFIG_HVM)
-long p2m_pt_audit_p2m(struct p2m_domain *p2m)
+#if P2M_AUDIT
+static long p2m_pt_audit_p2m(struct p2m_domain *p2m)
 {
 unsigned long entry_count = 0, pmbad = 0;
 unsigned long mfn, gfn, m2pfn;
@@ -1120,8 +1120,6 @@ long p2m_pt_audit_p2m(struct p2m_domain
 
 return pmbad;
 }
-#else
-# define p2m_pt_audit_p2m NULL
 #endif /* P2M_AUDIT */
 
 /* Set up the p2m function pointers for pagetable format */
@@ -1141,8 +1139,6 @@ void p2m_pt_init(struct p2m_domain *p2m)
 
 #if P2M_AUDIT
 p2m->audit_p2m = p2m_pt_audit_p2m;
-#else
-p2m->audit_p2m = NULL;
 #endif
 }
 
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2435,7 +2435,7 @@ int p2m_altp2m_propagate_change(struct d
 
 /*** Audit ***/
 
-#if P2M_AUDIT && defined(CONFIG_HVM)
+#if P2M_AUDIT
 void audit_p2m(struct domain *d,
uint64_t *orphans,
 uint64_t *m2p_bad,
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -31,6 +31,14 @@
 #include 
 #include /* for pagetable_t */
 
+/* Debugging and auditing of the P2M code? */
+#if !defined(NDEBUG) && defined(CONFIG_HVM)
+#define P2M_AUDIT 1
+#else
+#define P2M_AUDIT 0
+#endif
+#define P2M_DEBUGGING 0
+
 extern bool_t opt_hap_1gb, opt_hap_2mb;
 
 /*
@@ -268,7 +276,9 @@ struct p2m_domain {
 int(*write_p2m_entry)(struct p2m_domain *p2m,
   unsigned long gfn, l1_pgentry_t *p,
   l1_pgentry_t new, unsigned int 
level);
+#if P2M_AUDIT
 long   (*audit_p2m)(struct p2m_domain *p2m);
+#endif
 
 /*
  * P2M updates may require TLBs to be flushed (invalidated).
@@ -758,14 +768,6 @@ extern void p2m_pt_init(struct p2m_domai
 void *map_domain_gfn(struct p2m_domain *p2m, gfn_t gfn, mfn_t *mfn,
  p2m_query_t q, uint32_t *pfec);
 
-/* Debugging and auditing of the P2M code? */
-#ifndef NDEBUG
-#define P2M_AUDIT 1
-#else
-#define P2M_AUDIT 0
-#endif
-#define P2M_DEBUGGING 0
-
 #if P2M_AUDIT
 extern void audit_p2m(struct domain *d,
   uint64_t *orphans,

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

[Jan Beulich]

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 practice this may not even be needed) making
sure we don't end up using safe_write_pte() for nested P2Ms.

Signed-off-by: Jan Beulich 
Acked-by: Tim Deegan 
---
Like for the possibly unnecessary p2m_is_nestedp2m() I'm not really sure
the paging_get_hostmode() check there is still needed either. But I
didn't want to alter more aspects than necessary here.

Of course with the p2m_is_nestedp2m() check there and with all three of
{hap,nestedp2m,shadow}_write_p2m_entry() now globally accessible, it's
certainly an option to do away with the indirect call there altogether.
In fact we may even be able to go further and fold the three functions:
They're relatively similar, and this would "seamlessly" address the
apparent bug of nestedp2m_write_p2m_entry() not making use of
p2m_entry_modify().

--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -823,6 +823,11 @@ hap_write_p2m_entry(struct p2m_domain *p
 return 0;
 }
 
+void hap_p2m_init(struct p2m_domain *p2m)
+{
+p2m->write_p2m_entry = hap_write_p2m_entry;
+}
+
 static unsigned long hap_gva_to_gfn_real_mode(
 struct vcpu *v, struct p2m_domain *p2m, unsigned long gva, uint32_t *pfec)
 {
@@ -846,7 +851,6 @@ static const struct paging_mode hap_pagi
 .p2m_ga_to_gfn  = hap_p2m_ga_to_gfn_real_mode,
 .update_cr3 = hap_update_cr3,
 .update_paging_modes= hap_update_paging_modes,
-.write_p2m_entry= hap_write_p2m_entry,
 .flush_tlb  = flush_tlb,
 .guest_levels   = 1
 };
@@ -858,7 +862,6 @@ static const struct paging_mode hap_pagi
 .p2m_ga_to_gfn  = hap_p2m_ga_to_gfn_2_levels,
 .update_cr3 = hap_update_cr3,
 .update_paging_modes= hap_update_paging_modes,
-.write_p2m_entry= hap_write_p2m_entry,
 .flush_tlb  = flush_tlb,
 .guest_levels   = 2
 };
@@ -870,7 +873,6 @@ static const struct paging_mode hap_pagi
 .p2m_ga_to_gfn  = hap_p2m_ga_to_gfn_3_levels,
 .update_cr3 = hap_update_cr3,
 .update_paging_modes= hap_update_paging_modes,
-.write_p2m_entry= hap_write_p2m_entry,
 .flush_tlb  = flush_tlb,
 .guest_levels   = 3
 };
@@ -882,7 +884,6 @@ static const struct paging_mode hap_pagi
 .p2m_ga_to_gfn  = hap_p2m_ga_to_gfn_4_levels,
 .update_cr3 = hap_update_cr3,
 .update_paging_modes= hap_update_paging_modes,
-.write_p2m_entry= hap_write_p2m_entry,
 .flush_tlb  = flush_tlb,
 .guest_levels   = 4
 };
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -126,8 +126,9 @@ static int write_p2m_entry(struct p2m_do
 
 if ( v->domain != d )
 v = d->vcpu ? d->vcpu[0] : NULL;
-if ( likely(v && paging_mode_enabled(d) && paging_get_hostmode(v)) )
-rc = paging_get_hostmode(v)->write_p2m_entry(p2m, gfn, p, new, level);
+if ( likely(v && paging_mode_enabled(d) && paging_get_hostmode(v)) ||
+ p2m_is_nestedp2m(p2m) )
+rc = p2m->write_p2m_entry(p2m, gfn, p, new, level);
 else
 safe_write_pte(p, new);
 
@@ -209,7 +210,7 @@ p2m_next_level(struct p2m_domain *p2m, v
 
 new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
 
-rc = p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
+rc = write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
 if ( rc )
 goto error;
 }
@@ -251,7 +252,7 @@ p2m_next_level(struct p2m_domain *p2m, v
 {
 new_entry = l1e_from_pfn(pfn | (i << ((level - 1) * 
PAGETABLE_ORDER)),
  flags);
-rc = p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, 
level);
+rc = write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, level);
 if ( rc )
 {
 unmap_domain_page(l1_entry);
@@ -262,8 +263,7 @@ p2m_next_level(struct p2m_domain *p2m, v
 unmap_domain_page(l1_entry);
 
 new_entry = l1e_from_mfn(mfn, P2M_BASE_FLAGS | _PAGE_RW);
-rc = p2m->write_p2m_entry(p2m, gfn, p2m_entry, new_entry,
-  level + 1);
+rc = write_p2m_entry(p2m, gfn, p2m_entry, new_entry, level + 1);
 if ( rc )
 goto error;
 }
@@ -335,7 +335,7 @@ static int p2m_pt_set_recalc_range(struc
 if ( (l1e_get_flags(e) & _PAGE_PRESENT) && !needs_recalc(l1, e) )
 {
 set_recalc(l1, e);
-err = p2m->write_p2m_entry(p2m, first_gfn, pent, e, level);
+err = write_p2m_entry(p2m, first_gfn, pent, e, level);
 

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

[Jan Beulich]

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 in the EPT case we wouldn't
risk mistakenly calling through the NULL hook pointer.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -108,6 +108,31 @@ static unsigned long p2m_type_to_flags(c
 }
 }
 
+/*
+ * Atomically write a P2M entry and update the paging-assistance state
+ * appropriately.
+ * Arguments: the domain in question, the GFN whose mapping is being updated,
+ * a pointer to the entry to be written, the MFN in which the entry resides,
+ * the new contents of the entry, and the level in the p2m tree at which
+ * we are writing.
+ */
+static int write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
+   l1_pgentry_t *p, l1_pgentry_t new,
+   unsigned int level)
+{
+struct domain *d = p2m->domain;
+struct vcpu *v = current;
+int rc = 0;
+
+if ( v->domain != d )
+v = d->vcpu ? d->vcpu[0] : NULL;
+if ( likely(v && paging_mode_enabled(d) && paging_get_hostmode(v)) )
+rc = paging_get_hostmode(v)->write_p2m_entry(p2m, gfn, p, new, level);
+else
+safe_write_pte(p, new);
+
+return rc;
+}
 
 // Find the next level's P2M entry, checking for out-of-range gfn's...
 // Returns NULL on error.
@@ -594,7 +619,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m,
 entry_content.l1 = l3e_content.l3;
 
 rc = p2m->write_p2m_entry(p2m, gfn, p2m_entry, entry_content, 3);
-/* NB: paging_write_p2m_entry() handles tlb flushes properly */
+/* NB: write_p2m_entry() handles tlb flushes properly */
 if ( rc )
 goto out;
 }
@@ -631,7 +656,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m,
 
 /* level 1 entry */
 rc = p2m->write_p2m_entry(p2m, gfn, p2m_entry, entry_content, 1);
-/* NB: paging_write_p2m_entry() handles tlb flushes properly */
+/* NB: write_p2m_entry() handles tlb flushes properly */
 if ( rc )
 goto out;
 }
@@ -666,7 +691,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m,
 entry_content.l1 = l2e_content.l2;
 
 rc = p2m->write_p2m_entry(p2m, gfn, p2m_entry, entry_content, 2);
-/* NB: paging_write_p2m_entry() handles tlb flushes properly */
+/* NB: write_p2m_entry() handles tlb flushes properly */
 if ( rc )
 goto out;
 }
@@ -1107,7 +1132,7 @@ void p2m_pt_init(struct p2m_domain *p2m)
 p2m->recalc = do_recalc;
 p2m->change_entry_type_global = p2m_pt_change_entry_type_global;
 p2m->change_entry_type_range = p2m_pt_change_entry_type_range;
-p2m->write_p2m_entry = paging_write_p2m_entry;
+p2m->write_p2m_entry = write_p2m_entry;
 #if P2M_AUDIT
 p2m->audit_p2m = p2m_pt_audit_p2m;
 #else
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -941,27 +941,7 @@ void paging_update_nestedmode(struct vcp
 v->arch.paging.nestedmode = NULL;
 hvm_asid_flush_vcpu(v);
 }
-#endif
 
-int paging_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
-   l1_pgentry_t *p, l1_pgentry_t new,
-   unsigned int level)
-{
-struct domain *d = p2m->domain;
-struct vcpu *v = current;
-int rc = 0;
-
-if ( v->domain != d )
-v = d->vcpu ? d->vcpu[0] : NULL;
-if ( likely(v && paging_mode_enabled(d) && paging_get_hostmode(v) != NULL) 
)
-rc = paging_get_hostmode(v)->write_p2m_entry(p2m, gfn, p, new, level);
-else
-safe_write_pte(p, new);
-
-return rc;
-}
-
-#ifdef CONFIG_HVM
 int __init paging_set_allocation(struct domain *d, unsigned int pages,
  bool *preempted)
 {
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -369,18 +369,6 @@ static inline void safe_write_pte(l1_pge
 *p = new;
 }
 
-/* Atomically write a P2M entry and update the paging-assistance state 
- * appropriately. 
- * Arguments: the domain in question, the GFN whose mapping is being updated, 
- * a pointer to the entry to be written, the MFN in which the entry resides, 
- * the new contents of the entry, and the level in the p2m tree at which 
- * we are writing. */
-struct p2m_domain;
-
-int paging_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
-   l1_pgentry_t *p, l1_pgentry_t new,
-   unsigned int level);
-
 /*
  * Called from the guest to indicate that the a process is being
  * torn down and its pagetables will soon be discarded.

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

[Jan Beulich]

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 rid of that one unnecessary layer of indirect calls.

v2 has a build fix for clang in patch 3 and a few new patches.

1: p2m: paging_write_p2m_entry() is a private function
2: p2m: collapse the two ->write_p2m_entry() hooks
3: p2m: suppress audit_p2m hook when possible
4: HAP: move nested-P2M flush calculations out of locked region
5: p2m: split write_p2m_entry() hook
6: p2m: avoid unnecessary calls of write_p2m_entry_pre() hook
7: p2m: pass old PTE directly to write_p2m_entry_pre() hook
8: shadow: cosmetics to sh_unshadow_for_p2m_change()
9: shadow: adjust TLB flushing in sh_unshadow_for_p2m_change()

Jan

[qemu-mainline test] 156424: regressions - FAIL

[osstest service owner]

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 be run:
 test-arm64-arm64-libvirt-xsm 14 guest-start  fail REGR. vs. 152631
 test-armhf-armhf-xl-vhd  12 debian-di-installfail REGR. vs. 152631
 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
152631
 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
 test-armhf-armhf-libvirt-raw 12 debian-di-installfail REGR. vs. 152631
 test-amd64-amd64-xl-qcow2   21 guest-start/debian.repeat fail REGR. vs. 152631
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 152631
 test-armhf-armhf-libvirt 14 guest-start  fail REGR. vs. 152631

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu3c8c36c9087da957f580a9bb5ebf7814a753d1c6
baseline version:
 qemuu1d806cef0e38b5db8347a8e12f214d543204a314

Last test of basis   152631  2020-08-20 09:07:46 Z   78 days
Failing since152659  2020-08-21 14:07:39 Z   76 days  171 attempts
Testing same since   156403  2020-11-04 22:20:29 Z1 days2 attempts


People who touched revisions under test:
Aaron Lindsay 
  Alberto Garcia 
  Aleksandar Markovic 
  Alex Bennée 
  Alex Chen 
  Alex Williamson 
  Alexander Bulekov 
  AlexChen 
  Alexey Kirillov 
  Alistair Francis 
  Alistair Francis 
  Amey Narkhede 
  Ana Pazos 
  Andreas Gustafsson 
  Andrew Jones 
  Andrey Konovalov 
  Andrey Shinkevich 
  Ani Sinha 
  Anthony PERARD 
  

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

[Jan Beulich]

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 seg, u8 
> bus, u8 devfn, u32 flag)
>  if ( !is_iommu_enabled(d) )
>  return 0;
>  
> -/* Prevent device assign if mem paging or mem sharing have been 
> - * enabled for this domain */
> -if ( d != dom_io &&
> - unlikely(mem_sharing_enabled(d) ||
> -  vm_event_check_ring(d->vm_event_paging) ||
> -  p2m_get_hostp2m(d)->global_logdirty) )
> +if( !arch_iommu_usable(d) )
>  return -EXDEV;

While iirc I did suggest this name, seeing it used here leaves me
somewhat unhappy with the name, albeit I also can't think of any
better alternative right now. Maybe arch_iommu_use_permitted()?

> @@ -315,6 +316,18 @@ int iommu_update_ire_from_msi(
> ? iommu_call(_ops, update_ire_from_msi, msi_desc, msg) : 0;
>  }
>  
> +bool_t arch_iommu_usable(struct domain *d)

Just bool please and I very much hope the parameter can be const.

> +{
> +
> +/* Prevent device assign if mem paging or mem sharing have been
> + * enabled for this domain */

Please correct comment style as you move it.

> +if ( d != dom_io && unlikely(mem_sharing_enabled(d) ||
> +vm_event_check_ring(d->vm_event_paging) ||
> +p2m_get_hostp2m(d)->global_logdirty) )

You've screwed up indentation, and I don't see why ...

> +return false;
> +else
> +return true;
> +}

... this can't be a simple single return statement anyway:

return d == dom_io ||
   likely(!mem_sharing_enabled(d) &&
  !vm_event_check_ring(d->vm_event_paging) &&
  !p2m_get_hostp2m(d)->global_logdirty);

In the course of moving I'd also suggest dropping the use of
likely() here: The way it's used (on an && expression) isn't
normally having much effect anyway. If anything it should imo
be

return d == dom_io ||
   (likely(!mem_sharing_enabled(d)) &&
likely(!vm_event_check_ring(d->vm_event_paging)) &&
likely(!p2m_get_hostp2m(d)->global_logdirty));

Any transformation to this effect wants mentioning in the
description, though.

Jan

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

[Jan Beulich]

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 - struct domain continues to be used
in this file, for example.

> @@ -847,71 +845,6 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
>  return ret;
>  }
>  
> -static int pci_clean_dpci_irq(struct domain *d,
> -  struct hvm_pirq_dpci *pirq_dpci, void *arg)
> -{
> -struct dev_intx_gsi_link *digl, *tmp;
> -
> -pirq_guest_unbind(d, dpci_pirq(pirq_dpci));
> -
> -if ( pt_irq_need_timer(pirq_dpci->flags) )
> -kill_timer(_dpci->timer);
> -
> -list_for_each_entry_safe ( digl, tmp, _dpci->digl_list, list )
> -{
> -list_del(>list);
> -xfree(digl);
> -}
> -
> -radix_tree_delete(>pirq_tree, dpci_pirq(pirq_dpci)->pirq);
> -
> -if ( !pt_pirq_softirq_active(pirq_dpci) )
> -return 0;
> -
> -domain_get_irq_dpci(d)->pending_pirq_dpci = pirq_dpci;
> -
> -return -ERESTART;
> -}
> -
> -static int pci_clean_dpci_irqs(struct domain *d)
> -{
> -struct hvm_irq_dpci *hvm_irq_dpci = NULL;
> -
> -if ( !is_iommu_enabled(d) )
> -return 0;
> -
> -if ( !is_hvm_domain(d) )
> -return 0;
> -
> -spin_lock(>event_lock);
> -hvm_irq_dpci = domain_get_irq_dpci(d);
> -if ( hvm_irq_dpci != NULL )
> -{
> -int ret = 0;
> -
> -if ( hvm_irq_dpci->pending_pirq_dpci )
> -{
> -if ( pt_pirq_softirq_active(hvm_irq_dpci->pending_pirq_dpci) )
> - ret = -ERESTART;
> -else
> - hvm_irq_dpci->pending_pirq_dpci = NULL;
> -}
> -
> -if ( !ret )
> -ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
> -if ( ret )
> -{
> -spin_unlock(>event_lock);
> -return ret;
> -}
> -
> -hvm_domain_irq(d)->dpci = NULL;
> -free_hvm_irq_dpci(hvm_irq_dpci);
> -}
> -spin_unlock(>event_lock);
> -return 0;
> -}

If this code gets moved, I think it ought to move into
xen/drivers/passthrough/io.c, as that's where all the companion code
sits. (The file as a whole, getting built for x86/HVM only, may want
moving to xen/drivers/passthrough/x86/ if the underlying model isn't
suitable for Arm. Then it probably also would want to be named hvm.c,
to express its limited purpose.)

Jan

Re: preparations for 4.14.1

[Jan Beulich]

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 no tools side backports needed here.)
> 
> Would it be possible to consider the backport mentioned [1]? For 
> convenience, this is:
> 
> d25cc3ec93eb "libxl: workaround gcc 10.2 maybe-uninitialized warning"
> 
> In addition, I would like to request a backport for:
> 
> fff1b7f50e75 "libxl: fix -Werror=stringop-truncation in
> libxl__prepare_sockaddr_un"
> 
> Both patches are necessary to get Xen building with newer GCC.

While I support the request, it really should have gone to Ian.
Ian - please consider.

Jan

Re: preparations for 4.14.1

[Julien Grall]

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 here.)


Would it be possible to consider the backport mentioned [1]? For 
convenience, this is:


d25cc3ec93eb "libxl: workaround gcc 10.2 maybe-uninitialized warning"

In addition, I would like to request a backport for:

fff1b7f50e75 "libxl: fix -Werror=stringop-truncation in
libxl__prepare_sockaddr_un"

Both patches are necessary to get Xen building with newer GCC.



Julien, Stefano, on the Arm side I'd like to ask for

5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics helpers

just like I did when sending the respective 4.13.2 / 4.12.4
mail. Is there a particular reason it wasn't put in?

Jan



Cheers,

[1] <54fcf6ea-f400-c96a-cde6-4f55f909c...@xen.org>

--
Julien Grall

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

[Jan Beulich]

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
bool
 +
 +config PCI_ATS
 +  bool "PCI ATS support"
 +  default y
 +  depends on X86 && HAS_PCI
 +  ---help---
 +   Enable PCI Address Translation Services.
 +
 +   If unsure, say Y.
>>>
>>> Support for "---help---" having gone away in Linux, I think we'd
>>> better not add new instances. Also indentation of help content
>>> typically is by a tab and two spaces. With these two adjusted
>>>
>>> Reviewed-by: Jan Beulich 
>>
>> Initially I wanted to merely reply indicating I'd be fine making
>> these changes while committing, but there are two more things
>> (and I withdraw my R-b): For one, isn't strict pci_dev's ats
>> field now unused when !PCI_ATS? If so, if should get an #ifdef
>> added. And then, what exactly is it in ats.c that's x86-specific?
>> Shouldn't the whole file instead be moved one level up, and be
>> usable by Arm right away?
> 
> If the issue is that ATS wouldn't work on ARM straight away, then I
> think it would be best to make this a silent option like we did in patch
> #1: if x86 && HAS_PCI -> automatically enable, otherwise disable.

Taking the opportunity to make this a non-silent option was actually
a request of mine. As long as the code builds and isn't obviously
broken for Arm, I think it shouldn't have an X86 dependency (and it
then should be moved up in the tree). Arguably it could then
default to off for Arm, but when asking for this option to gain a
prompt I also indicated that I wonder whether the default shouldn't
be off on x86 as well, seeing that the controlling command line
option also defaults to off.

Jan