[xen-4.14-testing test] 179840: tolerable trouble: fail/pass/starved - PUSHED

[osstest service owner]

flight 179840 xen-4.14-testing real [real]
flight 179857 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179840/
http://logs.test-lab.xenproject.org/osstest/logs/179857/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-install   fail pass in 179857-retest
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 179857-retest

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 178273
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 178273
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 178273
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 178273
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 178273
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 178273
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 178273
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 178273
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 178273
 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  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 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-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail 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-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-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-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-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 build-armhf-libvirt   1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   starved  n/a
 build-armhf   2 hosts-allocate   starved  n/a

version targeted for testing:
 xen  e49571868d67944b9f4a546ade130e0b6e506b65
baseline version:
 xen  c267abfaf2d8176371eda037f9b9152458e0656d

Last test of basis   178273  2023-02-23 19:26:18 Z   26 days
Testing same since   179840  2023-03-21 12:36:28 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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

Re: [PATCH v5] ACPI: processor: Fix evaluating _PDC method when running as Xen dom0

[kernel test robot]

Hi Roger,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on rafael-pm/linux-next linus/master v6.3-rc3 
next-20230321]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Roger-Pau-Monne/ACPI-processor-Fix-evaluating-_PDC-method-when-running-as-Xen-dom0/20230321-221950
base:   https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
patch link:
https://lore.kernel.org/r/20230321141904.49177-1-roger.pau%40citrix.com
patch subject: [PATCH v5] ACPI: processor: Fix evaluating _PDC method when 
running as Xen dom0
config: arm64-randconfig-r013-20230319 
(https://download.01.org/0day-ci/archive/20230322/202303221107.hgkqazl0-...@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project 
67409911353323ca5edf2049ef0df54132fa1ca7)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# 
https://github.com/intel-lab-lkp/linux/commit/4232c8b37a0415e1e828fef4ce522c93a0b925fc
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Roger-Pau-Monne/ACPI-processor-Fix-evaluating-_PDC-method-when-running-as-Xen-dom0/20230321-221950
git checkout 4232c8b37a0415e1e828fef4ce522c93a0b925fc
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=arm64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=arm64 SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Link: 
https://lore.kernel.org/oe-kbuild-all/202303221107.hgkqazl0-...@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/arm64/xen/../../arm/xen/enlighten.c:2:
>> include/xen/xen.h:79:2: error: call to undeclared function 'BUG'; ISO C99 
>> and later do not support implicit function declarations 
>> [-Wimplicit-function-declaration]
   BUG();
   ^
   In file included from arch/arm64/xen/../../arm/xen/enlighten.c:4:
   In file included from include/xen/grant_table.h:48:
   In file included from include/xen/page.h:28:
   In file included from arch/arm64/include/asm/xen/page.h:1:
   In file included from include/xen/arm/page.h:9:
   In file included from include/linux/dma-mapping.h:7:
   In file included from include/linux/device.h:32:
   In file included from include/linux/device/driver.h:21:
   In file included from include/linux/module.h:19:
   In file included from include/linux/elf.h:6:
   In file included from arch/arm64/include/asm/elf.h:141:
   In file included from include/linux/fs.h:33:
   In file included from include/linux/percpu-rwsem.h:7:
   In file included from include/linux/rcuwait.h:6:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:97:11: warning: array index 3 is past the end of the 
array (that has type 'unsigned long[1]') [-Warray-bounds]
   return (set->sig[3] | set->sig[2] |
   ^~
   include/uapi/asm-generic/signal.h:62:2: note: array 'sig' declared here
   unsigned long sig[_NSIG_WORDS];
   ^
   In file included from arch/arm64/xen/../../arm/xen/enlighten.c:4:
   In file included from include/xen/grant_table.h:48:
   In file included from include/xen/page.h:28:
   In file included from arch/arm64/include/asm/xen/page.h:1:
   In file included from include/xen/arm/page.h:9:
   In file included from include/linux/dma-mapping.h:7:
   In file included from include/linux/device.h:32:
   In file included from include/linux/device/driver.h:21:
   In file included from include/linux/module.h:19:
   In file included from include/linux/elf.h:6:
   In file included from arch/arm64/include/asm/elf.h:141:
   In file included from include/linux/fs.h:33:
   In file included from include/linux/percpu-rwsem.h:7:
   In file included from include/linux/rcuwait.h:6:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:97:25: warning: array index 2 is past the end of the 
array (that has type 'unsigned long[1]') [-Warray-bounds]
   return (set->sig[3] | set->sig[2] |
 ^~
   include/uapi/asm-generic/signal.h:62:2: note: array 'sig' declared here
   unsigned long sig[_NSIG_WORDS];
   ^
   In file included fro

[xen-4.16-testing test] 179842: regressions - trouble: blocked/fail/pass/starved

[osstest service owner]

flight 179842 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179842/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 6 kernel-build fail REGR. vs. 179065

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 179065
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 179065
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 179065
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 179065
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 179065
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 179065
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 179065
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 179065
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 179065
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-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-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 build-armhf-libvirt   1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   starved  n/a
 build-armhf   2 hosts-allocate   starved  n/a

version targeted for testing:
 xen  3c924fe46b455834b5c04268db6b528b549668d1
baseline version:
 xen  84dfe7a56f04a7412fa4869b3e756c49e1cfbe75

Last test of basis   179065  2023-03-03 07:37:09 Z   18 days
Testing same since   179842  2023-03-21 12:36:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  starved 
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  starved 
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-arm64-pvopsfail
 build-armhf-pvopspass
 build-i386-pvops 

RE: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until the first access

[Henry Wang]

Hi Julien,

> -Original Message-
> From: Julien Grall 
> Subject: Re: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until
> the first access
>
> > gfn_to_gaddr(gfn) >= d->arch.vgic.cbase ||
> > gfn_to_gaddr(gfn) < d->arch.vgic.cbase + d->arch.vgic.csize
> 
> ... use the size in the check. With the || switch to &&, my preference
> would be to use:
> 
> ((d->arch.vgic.cbase - gfn_to_addr(gfn)) < d->arch.vgic.csize)
> 
> to avoid a potential overflow in the unlikely case the CPU interface is
> at the top of the address space.

Oh I like the idea of using the "minus approach" to avoid the overflow
very much. Thanks! I will keep this in mind in my future development.

One more question, since this "minus approach" is directly derived from
`gfn_to_gaddr(gfn) < d->arch.vgic.cbase + d->arch.vgic.csize`,
shouldn't it be
`(gfn_to_addr(gfn) - d->arch.vgic.cbase) < d->arch.vgic.csize` instead?

Otherwise I think `d->arch.vgic.cbase - gfn_to_addr(gfn)` will produce
a huge u64 and this check would always fail?

Kind regards,
Henry

> 
> Cheers,
> 
> --
> Julien Grall

RE: [PATCH v2 4/4] xen/arm: Clean-up in p2m_init() and p2m_final_teardown()

[Henry Wang]

Hi Julien,

> -Original Message-
> From: Julien Grall 
> Subject: Re: [PATCH v2 4/4] xen/arm: Clean-up in p2m_init() and
> p2m_final_teardown()
> 
> Hi Henry,
> 
> > ---
> > I am not entirely sure if I should also drop the "TODO" on top of
> > the p2m_set_entry(). Because although we are sure there is no
> > p2m pages populated in domain_create() stage now, but we are not
> > sure if anyone will add more in the future...Any comments?
> 
> I would keep it.

Sure.

> 
> > @@ -200,10 +200,6 @@ int p2m_init(struct domain *d);
> >*  - p2m_final_teardown() will be called when domain struct is been
> >*freed. This *cannot* be preempted and therefore one small
> 
> NIT: As you are touching the comment, would you mind to fix the typo
> s/one/only/.

I would be more than happy to fix it. Thanks for noticing this :)

> 
> > -BUG_ON(p2m_teardown(d, false));
> 
> With this change, I think we can also drop the second parameter of
> p2m_teardown(). Preferably with this change in the patch:

Yes indeed, I was also thinking of this when writing this patch but in
the end decided to do minimal change..

> 
> Acked-by: Julien Grall 

Thanks! I am not 100% comfortable to take this tag because I made
some extra code change, below is the diff to drop the second param
of p2m_teardown():

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
@@ -1030,7 +1030,7 @@ int domain_relinquish_resources(struct domain *d)
 p2m_clear_root_pages(>arch.p2m);

 PROGRESS(p2m):
-ret = p2m_teardown(d, true);
+ret = p2m_teardown(d);
 if ( ret )
 return ret;

diff --git a/xen/arch/arm/include/asm/p2m.h b/xen/arch/arm/include/asm/p2m.h
@@ -201,7 +201,7 @@ int p2m_init(struct domain *d);
  *freed. This *cannot* be preempted and therefore only small
  *resources should be freed here.
  */
-int p2m_teardown(struct domain *d, bool allow_preemption);
+int p2m_teardown(struct domain *d);
 void p2m_final_teardown(struct domain *d);

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
-int p2m_teardown(struct domain *d, bool allow_preemption)
+int p2m_teardown(struct domain *d)
 {
[...]
 /* Arbitrarily preempt every 512 iterations */
-if ( allow_preemption && !(count % 512) && hypercall_preempt_check() )
+if ( !(count % 512) && hypercall_preempt_check() )

If you are happy, I will take this acked-by. Same question to Michal for his
Reviewed-by.

Kind regards,
Henry

> 
> Preferably, I would like this to happen in this patch.
> 
> Cheers,
> 
> --
> Julien Grall

Re: [PATCH v5] ACPI: processor: Fix evaluating _PDC method when running as Xen dom0

[kernel test robot]

Hi Roger,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on rafael-pm/linux-next linus/master v6.3-rc3 
next-20230321]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Roger-Pau-Monne/ACPI-processor-Fix-evaluating-_PDC-method-when-running-as-Xen-dom0/20230321-221950
base:   https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
patch link:
https://lore.kernel.org/r/20230321141904.49177-1-roger.pau%40citrix.com
patch subject: [PATCH v5] ACPI: processor: Fix evaluating _PDC method when 
running as Xen dom0
config: x86_64-randconfig-a005 
(https://download.01.org/0day-ci/archive/20230322/202303221035.bfy5kyh1-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project 
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/4232c8b37a0415e1e828fef4ce522c93a0b925fc
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Roger-Pau-Monne/ACPI-processor-Fix-evaluating-_PDC-method-when-running-as-Xen-dom0/20230321-221950
git checkout 4232c8b37a0415e1e828fef4ce522c93a0b925fc
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=x86_64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=x86_64 SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Link: 
https://lore.kernel.org/oe-kbuild-all/202303221035.bfy5kyh1-...@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/x86/xen/suspend_hvm.c:4:
>> include/xen/xen.h:79:2: error: implicit declaration of function 'BUG' is 
>> invalid in C99 [-Werror,-Wimplicit-function-declaration]
   BUG();
   ^
   1 error generated.


vim +/BUG +79 include/xen/xen.h

73  
74  #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI) && 
defined(CONFIG_X86)
75  bool __init xen_processor_present(uint32_t acpi_id);
76  #else
77  static inline bool xen_processor_present(uint32_t acpi_id)
78  {
  > 79  BUG();
80  return false;
81  }
82  #endif
83  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests

Re: [BUG] x2apic broken with current AMD hardware

[Elliott Mitchell]

On Tue, Mar 21, 2023 at 08:13:15AM +0100, Jan Beulich wrote:
> On 21.03.2023 05:19, Elliott Mitchell wrote:
> 
> > The above appears about twice for each core, then I start seeing
> > "(XEN) CPU#: No irq handler for vector ?? (IRQ -2147483648, LAPIC)"
> > 
> > The core doesn't vary too much with this, but the vector varies some.
> > 
> > Upon looking "(XEN) Using APIC driver x2apic_cluster".  Unfortunately
> > I didn't try booting with x2apic_phys forced with this setting.
> 
> My guess is that this would also help. But the system should still work
> correctly in clustered mode. As a first step I guess debug key 'i', 'z',
> and 'M' output may provide some insight. But the request for a full log
> at maximum verbosity also remains (ideally with a debug hypervisor).

Needs a secure channel (PGP most likely) for everything, since there is
too much information in there.  Serial numbers and MAC addresses are a
potential source of attack (or faking returns).  Smaller segments can be
had more readily:

(XEN) SMBIOS 3.5 present.
(XEN) x2APIC mode is already enabled by BIOS.
(XEN) Using APIC driver x2apic_cluster
(XEN) ACPI: PM-Timer IO Port: 0x808 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:804,1:0], pm1x_evt[1:800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 785a3000/, 
using 32
(XEN) ACPI: wakeup_vec[785a300c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: IOAPIC (id[0x20] address[0xfec0] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 32, version 33, address 0xfec0, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x21] address[0xfec01000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 33, version 33, address 0xfec01000, GSI 24-55
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
(XEN) ACPI: HPET id: 0x base: 0xfed0
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 56 GSI, 6600 MSI/MSI-X
(XEN) AMD-Vi: IOMMU Extended Features:
(XEN) - Peripheral Page Service Request
(XEN) - x2APIC
(XEN) - NX bit
(XEN) - Guest APIC Physical Processor Interrupt
(XEN) - Invalidate All Command
(XEN) - Guest APIC
(XEN) - Performance Counters
(XEN) - Host Address Translation Size: 0x2
(XEN) - Guest Address Translation Size: 0
(XEN) - Guest CR3 Root Table Level: 0x1
(XEN) - Maximum PASID: 0xf
(XEN) - SMI Filter Register: 0x1
(XEN) - SMI Filter Register Count: 0x1
(XEN) - Guest Virtual APIC Modes: 0x1
(XEN) - Dual PPR Log: 0x2
(XEN) - Dual Event Log: 0x2
(XEN) - Secure ATS
(XEN) - User / Supervisor Page Protection
(XEN) - Device Table Segmentation: 0x3
(XEN) - PPR Log Overflow Early Warning
(XEN) - PPR Automatic Response
(XEN) - Memory Access Routing and Control: 0x1
(XEN) - Block StopMark Message
(XEN) - Performance Optimization
(XEN) - MSI Capability MMIO Access
(XEN) - Guest I/O Protection
(XEN) - Enhanced PPR Handling
(XEN) - Invalidate IOTLB Type
(XEN) - VM Table Size: 0x2
(XEN) - Guest Access Bit Update Disable
(XEN) AMD-Vi: Disabled HAP memory map sharing with IOMMU
(XEN) AMD-Vi: IOMMU 0 Enabled.

I'm a bit concerned how all the reports so far are ASUS motherboards.
This could mean people getting the latest, greatest and using Xen tend
towards ASUS motherboards.  This could also mean ASUS's engineering team
did something to their latest round.  Both are possible.

Could well be the latest round from AMD include more pieces from their
server processors, which trigger x2apic_cluster as default.  Yet didn't
bring some extra portion(s) which are required by x2apic_cluster.


> > So x2apic_cluster is looking like a  on recent AMD processors.
> > 
> > 
> > I'm unsure this qualifies as "Tested-by".  Certainly it IS an
> > improvement, but the problem certainly isn't 100% solved.
> 
> There simply are multiple problems; one looks to be solved now.

I agree with that assessment.  Just I'm unsure whether this step is
enough to include "Tested-by".  I'm concerned there could be a single
deeper problem which solves everything at once.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

[xen-unstable test] 179834: tolerable trouble: fail/pass/starved - PUSHED

[osstest service owner]

flight 179834 xen-unstable real [real]
flight 179851 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179834/
http://logs.test-lab.xenproject.org/osstest/logs/179851/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail pass in 
179851-retest
 test-amd64-i386-xl-vhd   22 guest-start.2   fail pass in 179851-retest

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 179820
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 179820
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 179820
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 179820
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 179820
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 179820
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 179820
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 179820
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 179820
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 build-armhf-libvirt   1 build-check(1)   starved  n/a
 test-armhf-armhf-examine  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   starved  n/a
 test-arm64-arm64-libvirt-xsm  3 hosts-allocate   starved  n/a
 build-armhf   2 hosts-allocate   starved  n/a
 test-arm64-arm64-libvirt-raw  3 hosts-allocate   starved  n/a
 test-arm64-arm64-xl-xsm   3 hosts-allocate   starved  n/a
 test-arm64-arm64-xl-credit1   3 hosts-allocate   starved  n/a
 test-arm64-arm64-xl-vhd   3 hosts-allocate   starved  n/a
 test-arm64-arm64-xl-credit2   3 hosts-allocate   starved  n/a
 test-arm64-arm64-xl   3 hosts-allocate   starved  n/a
 test-arm64-arm64-xl-thunderx  3 hosts-allocate   starved  n/a

version targeted for testing:
 xen  0bbf102d8794fb961cb103ada00999768547916e
baseline version:
 xen  c2581c58bec96afa450ebaca3fa2a33bcb0a9974

Last test of basis   179820  2023-03-20 19:12:14 Z1 days
Testing same since   179834  2023-03-21 07:48:16 Z0 days1 attempts


People who touched revisions under test:
  Jiamei Xie 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  starved 
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  starved 
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 

[linux-linus test] 179830: regressions - trouble: fail/pass/starved

[osstest service owner]

flight 179830 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179830/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit1  17 guest-saverestorefail REGR. vs. 178042
 test-amd64-amd64-freebsd12-amd64 13 guest-start  fail REGR. vs. 178042
 test-amd64-amd64-xl-shadow   18 guest-localmigrate   fail REGR. vs. 178042
 test-amd64-amd64-xl  14 guest-start  fail REGR. vs. 178042
 test-amd64-amd64-xl-xsm  17 guest-saverestorefail REGR. vs. 178042
 test-amd64-amd64-freebsd11-amd64 13 guest-start  fail REGR. vs. 178042
 test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 178042
 test-amd64-amd64-xl-pvhv2-amd 17 guest-saverestore   fail REGR. vs. 178042
 test-amd64-amd64-dom0pvh-xl-amd 14 guest-start   fail REGR. vs. 178042
 test-amd64-amd64-libvirt-xsm 14 guest-start  fail REGR. vs. 178042
 test-amd64-amd64-libvirt-pair 27 guest-migrate/dst_host/src_host fail REGR. 
vs. 178042
 test-arm64-arm64-xl-thunderx 14 guest-start  fail REGR. vs. 178042
 test-arm64-arm64-xl-xsm  14 guest-start  fail REGR. vs. 178042
 test-arm64-arm64-xl-credit1  14 guest-start  fail REGR. vs. 178042
 test-arm64-arm64-libvirt-xsm 14 guest-start  fail REGR. vs. 178042
 test-amd64-amd64-xl-credit2  21 guest-stop   fail REGR. vs. 178042
 test-arm64-arm64-xl-credit2  17 guest-stop   fail REGR. vs. 178042
 test-arm64-arm64-xl 18 guest-start/debian.repeat fail REGR. vs. 178042
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 18 
guest-start/debianhvm.repeat fail REGR. vs. 178042
 test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail REGR. vs. 178042
 test-amd64-amd64-libvirt 14 guest-start  fail REGR. vs. 178042
 test-amd64-coresched-amd64-xl 14 guest-start fail REGR. vs. 178042
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
178042
 test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 
178042
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail 
REGR. vs. 178042
 test-amd64-amd64-xl-qemut-debianhvm-amd64 12 debian-hvm-install fail REGR. vs. 
178042
 build-i386-pvops  6 kernel-build fail REGR. vs. 178042
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install 
fail REGR. vs. 178042
 test-amd64-amd64-pair25 guest-start/debian   fail REGR. vs. 178042
 test-amd64-amd64-qemuu-nested-amd 12 debian-hvm-install  fail REGR. vs. 178042
 test-amd64-amd64-xl-multivcpu 14 guest-start fail REGR. vs. 178042
 test-amd64-amd64-xl-pvshim   14 guest-start  fail REGR. vs. 178042
 test-amd64-amd64-xl-pvhv2-intel 14 guest-start   fail REGR. vs. 178042
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 178042
 test-amd64-amd64-xl-vhd  12 debian-di-installfail REGR. vs. 178042
 test-amd64-amd64-pygrub  12 debian-di-installfail REGR. vs. 178042
 test-amd64-amd64-libvirt-raw 12 debian-di-installfail REGR. vs. 178042
 test-amd64-amd64-libvirt-qcow2 12 debian-di-install  fail REGR. vs. 178042
 test-arm64-arm64-xl-vhd  12 debian-di-installfail REGR. vs. 178042
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 178042
 test-arm64-arm64-libvirt-raw 12 debian-di-installfail REGR. vs. 178042

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 16 guest-localmigrate fail REGR. 
vs. 178042
 test-amd64-amd64-xl-rtds 17 guest-saverestorefail REGR. vs. 178042

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 178042
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 178042
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 178042
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 178042
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail 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-armhf-armhf-examine  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl   1 build-check(1)   starved  n/a
 

Re: [PATCH] xen/arm: irq: Constify the first parameter of platform_get_irq_byname()

[Stefano Stabellini]

On Tue, 20 Mar 2023, Michal Orzel wrote:
> Hi Julien,
> 
> On 21/03/2023 18:17, Julien Grall wrote:
> > 
> > 
> > From: Julien Grall 
> > 
> > platform_get_irq_byname() is not meant to modify the parameter 'np'. So
> > constify it.
> > 
> > Signed-off-by: Julien Grall 
> Reviewed-by: Michal Orzel 
 
Acked-by: Stefano Stabellini 

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

[Christian König]

Am 17.03.23 um 15:45 schrieb Alex Deucher:

On Thu, Mar 16, 2023 at 7:09 PM Stefano Stabellini
 wrote:

On Thu, 16 Mar 2023, Juergen Gross wrote:

On 16.03.23 14:53, Alex Deucher wrote:

On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross  wrote:

On 16.03.23 14:45, Alex Deucher wrote:

On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich  wrote:

On 16.03.2023 00:25, Stefano Stabellini wrote:

On Wed, 15 Mar 2023, Jan Beulich wrote:

On 15.03.2023 01:52, Stefano Stabellini wrote:

On Mon, 13 Mar 2023, Jan Beulich wrote:

On 12.03.2023 13:01, Huang Rui wrote:

Xen PVH is the paravirtualized mode and takes advantage of
hardware
virtualization support when possible. It will using the
hardware IOMMU
support instead of xen-swiotlb, so disable swiotlb if
current domain is
Xen PVH.

But the kernel has no way (yet) to drive the IOMMU, so how can
it get
away without resorting to swiotlb in certain cases (like I/O
to an
address-restricted device)?

I think Ray meant that, thanks to the IOMMU setup by Xen, there
is no
need for swiotlb-xen in Dom0. Address translations are done by
the IOMMU
so we can use guest physical addresses instead of machine
addresses for
DMA. This is a similar case to Dom0 on ARM when the IOMMU is
available
(see include/xen/arm/swiotlb-xen.h:xen_swiotlb_detect, the
corresponding
case is XENFEAT_not_direct_mapped).

But how does Xen using an IOMMU help with, as said,
address-restricted
devices? They may still need e.g. a 32-bit address to be
programmed in,
and if the kernel has memory beyond the 4G boundary not all I/O
buffers
may fulfill this requirement.

In short, it is going to work as long as Linux has guest physical
addresses (not machine addresses, those could be anything) lower
than
4GB.

If the address-restricted device does DMA via an IOMMU, then the
device
gets programmed by Linux using its guest physical addresses (not
machine
addresses).

The 32-bit restriction would be applied by Linux to its choice of
guest
physical address to use to program the device, the same way it does
on
native. The device would be fine as it always uses Linux-provided
<4GB
addresses. After the IOMMU translation (pagetable setup by Xen), we
could get any address, including >4GB addresses, and that is
expected to
work.

I understand that's the "normal" way of working. But whatever the
swiotlb
is used for in baremetal Linux, that would similarly require its use
in
PVH (or HVM) aiui. So unconditionally disabling it in PVH would look
to
me like an incomplete attempt to disable its use altogether on x86.
What
difference of PVH vs baremetal am I missing here?

swiotlb is not usable for GPUs even on bare metal.  They often have
hundreds or megs or even gigs of memory mapped on the device at any
given time.  Also, AMD GPUs support 44-48 bit DMA masks (depending on
the chip family).

But the swiotlb isn't per device, but system global.

Sure, but if the swiotlb is in use, then you can't really use the GPU.
So you get to pick one.

The swiotlb is used only for buffers which are not within the DMA mask of a
device (see dma_direct_map_page()). So an AMD GPU supporting a 44 bit DMA mask
won't use the swiotlb unless you have a buffer above guest physical address of
16TB (so basically never).

Disabling swiotlb in such a guest would OTOH mean, that a device with only
32 bit DMA mask passed through to this guest couldn't work with buffers
above 4GB.

I don't think this is acceptable.

 From the Xen subsystem in Linux point of view, the only thing we need to
do is to make sure *not* to enable swiotlb_xen (yes "swiotlb_xen", not
the global swiotlb) on PVH because it is not needed anyway.

I think we should leave the global "swiotlb" setting alone. The global
swiotlb is not relevant to Xen anyway, and surely baremetal Linux has to
have a way to deal with swiotlb/GPU incompatibilities.

We just have to avoid making things worse on Xen, and for that we just
need to avoid unconditionally enabling swiotlb-xen. If the Xen subsystem
doesn't enable swiotlb_xen/swiotlb, and no other subsystem enables
swiotlb, then we have a good Linux configuration capable of handling the
GPU properly.

Alex, please correct me if I am wrong. How is x86_swiotlb_enable set to
false on native (non-Xen) x86?

In most cases we have an IOMMU enabled and IIRC, TTM has slightly
different behavior for memory allocation depending on whether swiotlb
would be needed or not.


Well "slightly different" is an understatement. We need to disable quite 
a bunch of features to make swiotlb work with GPUs.


Especially userptr and inter device sharing won't work any more.

Regards,
Christian.



Alex

Re: [XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

[Ayan Kumar Halder]

Hi Jan,

On 21/03/2023 16:53, Jan Beulich wrote:

On 21.03.2023 17:15, Ayan Kumar Halder wrote:

On 21/03/2023 14:22, Jan Beulich wrote:

On 21.03.2023 15:03, Ayan Kumar Halder wrote:

--- a/xen/arch/Kconfig
+++ b/xen/arch/Kconfig
@@ -1,6 +1,12 @@
   config 64BIT
bool
   
+config PHYS_ADDR_T_32

+   bool
+
+config PHYS_ADDR_T_64
+   bool

Do we really need both?

I was thinking the same. I am assuming that in future we may have

PHYS_ADDR_T_16,

Really? What contemporary system would be able to run in just 64k?
Certainly not Xen, let alone any Dom0 on top of it.


PHYS_ADDR_T_128. So, I am hoping that defining them explicitly might help.

Yes, 128-bit addresses may appear at some point. Then (and only then)
we'll need two controls, and we can then think about how to represent
them properly without risking issues.


Also, the user cannot select these configs directly.

Sure, but at some point some strange combination of options might that
randconfig manages to construct.


If so, what guards against both being selected
at the same time?

At present, we rely on "select".

You mean 'we rely on there being only one "select"'?

Yes, that was what I meant.

Else I'm afraid I
don't understand your reply.


Them being put in common code I consider it an at least latent issue
that you add "select"s ...


--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -9,6 +9,7 @@ config ARM_64
select 64BIT
select ARM_EFI
select HAS_FAST_MULTIPLY
+   select PHYS_ADDR_T_64
   
   config ARM

def_bool y
@@ -19,13 +20,48 @@ config ARM
select HAS_PMAP
select IOMMU_FORCE_PT_SHARE
   
+menu "Architecture Features"

+
+choice
+   prompt "Physical address space size" if ARM_32
+   default ARM_PA_BITS_48 if ARM_64
+   default ARM_PA_BITS_40 if ARM_32
+   help
+ User can choose to represent the width of physical address. This can
+ sometimes help in optimizing the size of image when user chooses a
+ smaller size to represent physical address.
+
+config ARM_PA_BITS_32
+   bool "32-bit"
+   help
+ On platforms where any physical address can be represented within 32 
bits
+ , user should choose this option. This will help is reduced size of 
the
+ binary.
+   select PHYS_ADDR_T_32
+   depends on ARM_32
+
+config ARM_PA_BITS_40
+   bool "40-bit"
+   select PHYS_ADDR_T_64
+   depends on ARM_32
+
+config ARM_PA_BITS_48
+   bool "40-bit"
+   select PHYS_ADDR_T_64
+   depends on ARM_48
+endchoice

... only for Arm. You get away with this only because ...


--- a/xen/arch/arm/include/asm/types.h
+++ b/xen/arch/arm/include/asm/types.h
@@ -34,9 +34,15 @@ typedef signed long long s64;
   typedef unsigned long long u64;
   typedef u32 vaddr_t;
   #define PRIvaddr PRIx32in
+#if defined(CONFIG_PHYS_ADDR_T_32)
+typedef unsigned long paddr_t;
+#define INVALID_PADDR (~0UL)
+#define PRIpaddr "08lx"
+#else
   typedef u64 paddr_t;
   #define INVALID_PADDR (~0ULL)
   #define PRIpaddr "016llx"
+#endif
   typedef u32 register_t;
   #define PRIregister "08x"
   #elif defined (CONFIG_ARM_64)

... you tweak things here, when we're in the process of moving stuff
out of asm/types.h.

Are you suggesting not to add anything to asm/types.h ? IOW, the above
snippet should

be added to xen/include/xen/types.h.

It's not your snippet alone, but the definition of paddr_t in general
which should imo be moved (as a follow-on to "common: move standard C
fixed width type declarations to common header"). If your patch in its
present shape landed first, that movement would become more
complicated - first and foremost "select"ing the appropriate
PHYS_ADDR_T_* on x86 and RISC-V would then need to be done there, when
it really doesn't belong there.


I understand your point. I am assuming that as PHYS_ADDR_T_* is now 
introduced at xen/arch/Kconfig, so x86 or RISC-V should be able to 
select the option.


As I see today, for :-

RISCV defines PADDR_BITS to 56. Thus, it will select PHYS_ADDR_T_64 only.

X86 defines PADDR_BITS to 52. Thus, it will also select PHYS_ADDR_T_64 only.

For Arm, there will be at least two configurations 1. which selects 
PHYS_ADDR_T_64   2. not select PHYS_ADDR_T_64 (ie for 32 bit physical 
address).





(Using "unsigned long" for a 32-bit paddr_t is of
course suspicious as well - this ought to be uint32_t.)

The problem with using uint32_t for paddr_t is that there are instances
where the paddr_t is modified with PAGE_MASK or PAGE_ALIGN.

For eg , handle_passthrough_prop()

      printk(XENLOG_ERR "Unable to permit to dom%d access to"
     " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
     kinfo->d->domain_id,
     mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);

And in xen/include/xen/page-size.h,

#define PAGE_SIZE   (_AC(1,L) << PAGE_SHIFT)
#define PAGE_MASK   (~(PAGE_SIZE-1))

Thus, the resulting types are 

Re: [PATCH v2 1/3] xen/riscv: introduce setup_initial_pages

[Julien Grall]

Hi,

I will try to not repeat the comment already made.

On 16/03/2023 16:43, Oleksii Kurochko wrote:

Mostly the code for setup_initial_pages was taken from Bobby's
repo except for the following changes:
* Use only a minimal part of the code enough to enable MMU
* rename {_}setup_initial_pagetables functions
* add an argument for setup_initial_mapping to have
   an opportunity to make set PTE flags.
* update setup_initial_pagetables function to map sections
   with correct PTE flags.
* introduce separate enable_mmu() to be able for proper
   handling the case when load start address isn't equal to
   linker start address.
* map linker addresses range to load addresses range without
   1:1 mapping.
* add safety checks such as:
   * Xen size is less than page size
   * linker addresses range doesn't overlap load addresses
 range
* Rework macros {THIRD,SECOND,FIRST,ZEROETH}_{SHIFT,MASK}
* change PTE_LEAF_DEFAULT to RX instead of RWX.
* Remove phys_offset as it isn't used now.
* Remove alignment  of {map, pa}_start &= XEN_PT_LEVEL_MAP_MASK(0); in
   setup_inital_mapping() as they should be already aligned.
* Remove clear_pagetables() as initial pagetables will be
   zeroed during bss initialization
* Remove __attribute__((section(".entry")) for setup_initial_pagetables()
   as there is no such section in xen.lds.S
* Update the argument of pte_is_valid() to "const pte_t *p"

Origin: https://gitlab.com/xen-on-risc-v/xen/-/tree/riscv-rebase 4af165b468af
Signed-off-by: Oleksii Kurochko 
---
Changes in V2:
  * update the commit message:
  * Remove {ZEROETH,FIRST,...}_{SHIFT,MASK, SIZE,...} and
introduce instead of them XEN_PT_LEVEL_*() and LEVEL_*
  * Rework pt_linear_offset() and pt_index based on  XEN_PT_LEVEL_*()
  * Remove clear_pagetables() functions as pagetables were zeroed during
.bss initialization
  * Rename _setup_initial_pagetables() to setup_initial_mapping()
  * Make PTE_DEFAULT equal to RX.
  * Update prototype of setup_initial_mapping(..., bool writable) ->
setup_initial_mapping(..., UL flags)
  * Update calls of setup_initial_mapping according to new prototype
  * Remove unnecessary call of:
_setup_initial_pagetables(..., load_addr_start, load_addr_end, 
load_addr_start, ...)
  * Define index* in the loop of setup_initial_mapping
  * Remove attribute "__attribute__((section(".entry")))" for 
setup_initial_pagetables()
as we don't have such section
  * make arguments of paddr_to_pte() and pte_is_valid() as const.
  * make xen_second_pagetable static.
  * use  instead of declaring extern unsigned long _stext, 
0etext, _srodata, _erodata
  * update  'extern unsigned long __init_begin' to 'extern unsigned long 
__init_begin[]'
  * use aligned() instead of "__attribute__((__aligned__(PAGE_SIZE)))"
  * set __section(".bss.page_aligned") for page tables arrays
  * fix identatations
  * Change '__attribute__((section(".entry")))' to '__init'
  * Remove phys_offset as it isn't used now.
  * Remove alignment  of {map, pa}_start &= XEN_PT_LEVEL_MAP_MASK(0); in
setup_inital_mapping() as they should be already aligned.
  * Remove clear_pagetables() as initial pagetables will be
zeroed during bss initialization
  * Remove __attribute__((section(".entry")) for setup_initial_pagetables()
as there is no such section in xen.lds.S
  * Update the argument of pte_is_valid() to "const pte_t *p"
---
  xen/arch/riscv/Makefile   |   1 +
  xen/arch/riscv/include/asm/mm.h   |   8 ++
  xen/arch/riscv/include/asm/page.h |  67 +
  xen/arch/riscv/mm.c   | 121 ++
  xen/arch/riscv/riscv64/head.S |  65 
  xen/arch/riscv/xen.lds.S  |   2 +
  6 files changed, 264 insertions(+)
  create mode 100644 xen/arch/riscv/include/asm/mm.h
  create mode 100644 xen/arch/riscv/include/asm/page.h
  create mode 100644 xen/arch/riscv/mm.c

diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 443f6bf15f..956ceb02df 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,5 +1,6 @@
  obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
  obj-y += entry.o
+obj-y += mm.o
  obj-$(CONFIG_RISCV_64) += riscv64/
  obj-y += sbi.o
  obj-y += setup.o
diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
new file mode 100644
index 00..3cc98fe45b
--- /dev/null
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -0,0 +1,8 @@
+#ifndef _ASM_RISCV_MM_H
+#define _ASM_RISCV_MM_H
+
+void setup_initial_pagetables(void);
+
+extern void enable_mmu(void);
+
+#endif /* _ASM_RISCV_MM_H */
diff --git a/xen/arch/riscv/include/asm/page.h 
b/xen/arch/riscv/include/asm/page.h
new file mode 100644
index 00..fb8329a191
--- /dev/null
+++ b/xen/arch/riscv/include/asm/page.h
@@ -0,0 +1,67 @@
+#ifndef _ASM_RISCV_PAGE_H
+#define _ASM_RISCV_PAGE_H
+
+#include 
+#include 
+
+#define PAGE_ENTRIES(1 << PAGETABLE_ORDER)
+#define VPN_MASK((unsigned long)(PAGE_ENTRIES - 1))
+

Re: [PATCH] xen/arm: irq: Constify the first parameter of platform_get_irq_byname()

[Michal Orzel]

Hi Julien,

On 21/03/2023 18:17, Julien Grall wrote:
> 
> 
> From: Julien Grall 
> 
> platform_get_irq_byname() is not meant to modify the parameter 'np'. So
> constify it.
> 
> Signed-off-by: Julien Grall 
Reviewed-by: Michal Orzel 

~Michal

Re: [PATCH v5 5/7] xen/riscv: introduce trap_init()

[Julien Grall]

Hi Oleksii,

On 16/03/2023 14:39, Oleksii Kurochko wrote:

Signed-off-by: Oleksii Kurochko 
Reviewed-by: Alistair Francis 
---
Changes in V5:
   - Nothing changed
---
Changes in V4:
   - Nothing changed
---
Changes in V3:
   - Nothing changed
---
Changes in V2:
   - Rename setup_trap_handler() to trap_init().
   - Add Reviewed-by to the commit message.
---
  xen/arch/riscv/include/asm/traps.h | 1 +
  xen/arch/riscv/setup.c | 5 +
  xen/arch/riscv/traps.c | 7 +++
  3 files changed, 13 insertions(+)

diff --git a/xen/arch/riscv/include/asm/traps.h 
b/xen/arch/riscv/include/asm/traps.h
index f3fb6b25d1..f1879294ef 100644
--- a/xen/arch/riscv/include/asm/traps.h
+++ b/xen/arch/riscv/include/asm/traps.h
@@ -7,6 +7,7 @@
  
  void do_trap(struct cpu_user_regs *cpu_regs);

  void handle_trap(void);
+void trap_init(void);
  
  #endif /* __ASSEMBLY__ */
  
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c

index 36556eb779..b44d105b5f 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -3,7 +3,9 @@
  #include 
  
  #include 

+#include 
  #include 
+#include 
  
  /* Xen stack for bringing up the first CPU. */

  unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
@@ -32,7 +34,10 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
  
  fill_boot_info();
  
+trap_init();

+
  early_printk("All set up\n");
+
  for ( ;; )
  asm volatile ("wfi");
  
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c

index 8a1529e0c5..581f34efbc 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -13,6 +13,13 @@
  #include 
  #include 
  
+void trap_init(void)

+{
+unsigned long addr = (unsigned long)_trap;


It is not super clear to me whether this is going to store the virtual 
or physical address.


Depending on the answer, the next would be whether the value would still 
be valid after the MMU is turned on?



+
+csr_write(CSR_STVEC, addr);
+}
+
  static const char *decode_trap_cause(unsigned long cause)
  {
  static const char *const trap_causes[] = {


Cheers,

--
Julien Grall

[PATCH v6 5/5] Automation and CI: Replace git:// and http:// with https://

[Demi Marie Obenour]

Obtaining code over an insecure transport is a terrible idea for
blatently obvious reasons.  Even for non-executable data, insecure
transports are considered deprecated.

This patch enforces the use of secure transports in automation and CI.
All URLs are known to work.

Signed-off-by: Demi Marie Obenour 
---
 README  | 4 ++--
 automation/build/debian/stretch-llvm-8.list | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/README b/README
index 
755b3d8eaf8f7a58a945b7594e68a3fe455a7bdf..f8cc426f78d690f37e013242e81d4e440556c330
 100644
--- a/README
+++ b/README
@@ -181,7 +181,7 @@ Python Runtime Libraries
 Various tools, such as pygrub, have the following runtime dependencies:
 
 * Python 2.6 or later.
-  URL:http://www.python.org/
+  URL:https://www.python.org/
   Debian: python
 
 Note that the build system expects `python` to be available. If your system
@@ -197,7 +197,7 @@ Intel(R) Trusted Execution Technology Support
 Intel's technology for safer computing, Intel(R) Trusted Execution Technology
 (Intel(R) TXT), defines platform-level enhancements that provide the building
 blocks for creating trusted platforms.  For more information, see
-http://www.intel.com/technology/security/.
+https://www.intel.com/technology/security/.
 
 Intel(R) TXT support is provided by the Trusted Boot (tboot) module in
 conjunction with minimal logic in the Xen hypervisor.
diff --git a/automation/build/debian/stretch-llvm-8.list 
b/automation/build/debian/stretch-llvm-8.list
index 
09fe843fb2a31ae38f752d7c8c71cf97f5b14513..590001ca81e826ab624ba9185423adf4b0c51a21
 100644
--- a/automation/build/debian/stretch-llvm-8.list
+++ b/automation/build/debian/stretch-llvm-8.list
@@ -1,3 +1,3 @@
 # Strech LLVM 8 repos
-deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main
-deb-src http://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main
+deb https://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main
+deb-src https://apt.llvm.org/stretch/ llvm-toolchain-stretch-8 main
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[PATCH v6 4/5] Build system: Replace git:// and http:// with https://

[Demi Marie Obenour]

Obtaining code over an insecure transport is a terrible idea for
blatently obvious reasons.  Even for non-executable data, insecure
transports are considered deprecated.

This patch enforces the use of secure transports in the build system.
Some URLs returned 301 or 302 redirects, so I replaced them with the
URLs that were redirected to.

Signed-off-by: Demi Marie Obenour 
---
 stubdom/configure | 12 ++--
 stubdom/configure.ac  | 12 ++--
 tools/firmware/etherboot/Makefile |  6 +-
 3 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/stubdom/configure b/stubdom/configure
index 
4ea95baa9192f3b319349ac2a14a3055a21ce705..540e9cd331888449b0e24c1aa974bc22c5bcab54
 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -3545,7 +3545,7 @@ if test "x$LIBPCI_URL" = "x"; then :
if test "x$extfiles" = "xy"; then :
   LIBPCI_URL=\$\(XEN_EXTFILES_URL\)
 else
-  LIBPCI_URL="http://www.kernel.org/pub/software/utils/pciutils;
+  LIBPCI_URL="https://mirrors.edge.kernel.org/pub/software/utils/pciutils;
 fi
 
 fi
@@ -3560,7 +3560,7 @@ if test "x$NEWLIB_URL" = "x"; then :
if test "x$extfiles" = "xy"; then :
   NEWLIB_URL=\$\(XEN_EXTFILES_URL\)
 else
-  NEWLIB_URL="ftp://sources.redhat.com/pub/newlib;
+  NEWLIB_URL="https://sourceware.org/ftp/newlib;
 fi
 
 fi
@@ -3575,7 +3575,7 @@ if test "x$LWIP_URL" = "x"; then :
if test "x$extfiles" = "xy"; then :
   LWIP_URL=\$\(XEN_EXTFILES_URL\)
 else
-  LWIP_URL="http://download.savannah.gnu.org/releases/lwip;
+  LWIP_URL="https://download.savannah.gnu.org/releases/lwip;
 fi
 
 fi
@@ -3590,7 +3590,7 @@ if test "x$GRUB_URL" = "x"; then :
if test "x$extfiles" = "xy"; then :
   GRUB_URL=\$\(XEN_EXTFILES_URL\)
 else
-  GRUB_URL="http://alpha.gnu.org/gnu/grub;
+  GRUB_URL="https://alpha.gnu.org/gnu/grub;
 fi
 
 fi
@@ -3602,7 +3602,7 @@ GRUB_VERSION="0.97"
 
 if test "x$OCAML_URL" = "x"; then :
 
-   OCAML_URL="http://caml.inria.fr/pub/distrib/ocaml-4.02;
+   OCAML_URL="https://caml.inria.fr/pub/distrib/ocaml-4.02;
 
 fi
 OCAML_VERSION="4.02.0"
@@ -3616,7 +3616,7 @@ if test "x$GMP_URL" = "x"; then :
if test "x$extfiles" = "xy"; then :
   GMP_URL=\$\(XEN_EXTFILES_URL\)
 else
-  GMP_URL="ftp://ftp.gmplib.org/pub/gmp-4.3.2;
+  GMP_URL="https://gmplib.org/download/gmp/archive;
 fi
 
 fi
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index 
c648b1602c227ed5fe63b9fbdf3fa52fd2e1654b..471e371e14a82aedc10314c95bcaf39ce9f89f90
 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -56,12 +56,12 @@ AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake])
 
 # Stubdom libraries version and url setup
 AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3])
-AX_STUBDOM_LIB([LIBPCI], [libpci], [2.2.9], 
[http://www.kernel.org/pub/software/utils/pciutils])
-AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], 
[ftp://sources.redhat.com/pub/newlib])
-AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], 
[http://download.savannah.gnu.org/releases/lwip])
-AX_STUBDOM_LIB([GRUB], [grub], [0.97], [http://alpha.gnu.org/gnu/grub])
-AX_STUBDOM_LIB_NOEXT([OCAML], [ocaml], [4.02.0], 
[http://caml.inria.fr/pub/distrib/ocaml-4.02])
-AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [ftp://ftp.gmplib.org/pub/gmp-4.3.2])
+AX_STUBDOM_LIB([LIBPCI], [libpci], [2.2.9], 
[https://mirrors.edge.kernel.org/pub/software/utils/pciutils])
+AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], 
[https://sourceware.org/ftp/newlib])
+AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], 
[https://download.savannah.gnu.org/releases/lwip])
+AX_STUBDOM_LIB([GRUB], [grub], [0.97], [https://alpha.gnu.org/gnu/grub])
+AX_STUBDOM_LIB_NOEXT([OCAML], [ocaml], [4.02.0], 
[https://caml.inria.fr/pub/distrib/ocaml-4.02])
+AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], 
[https://gmplib.org/download/gmp/archive])
 AX_STUBDOM_LIB([POLARSSL], [polarssl], [1.1.4])
 AX_STUBDOM_LIB([TPMEMU], [berlios tpm emulator], [0.7.4])
 
diff --git a/tools/firmware/etherboot/Makefile 
b/tools/firmware/etherboot/Makefile
index 
4bc3633ba3d67ff9f52a9cb7923afea73c861da9..6ab9e5bc6b4cc750f2e802128fbc71e9150397b1
 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -4,11 +4,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 include Config
 
-ifeq ($(GIT_HTTP),y)
-IPXE_GIT_URL ?= http://git.ipxe.org/ipxe.git
-else
-IPXE_GIT_URL ?= git://git.ipxe.org/ipxe.git
-endif
+IPXE_GIT_URL ?= https://github.com/ipxe/ipxe.git
 
 # put an updated tar.gz on xenbits after changes to this variable
 IPXE_GIT_TAG := 3c040ad387099483102708bb1839110bc788cefb
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[PATCH v6 3/5] Build system: Do not try to use broken links

[Demi Marie Obenour]

The upstream URLs for zlib, PolarSSL, and the TPM emulator do not work
anymore, so do not attempt to use them.

Signed-off-by: Demi Marie Obenour 
---
 m4/stubdom.m4|  5 +++--
 stubdom/configure| 21 +++--
 stubdom/configure.ac |  6 +++---
 3 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/m4/stubdom.m4 b/m4/stubdom.m4
index 
6aa488b8e229dabbe107cfe115b5f2ac7e5ae824..26f10595d1c1250b1dc8a5be626142325e8d4673
 100644
--- a/m4/stubdom.m4
+++ b/m4/stubdom.m4
@@ -78,10 +78,11 @@ done
 AC_DEFUN([AX_STUBDOM_LIB], [
 AC_ARG_VAR([$1_URL], [Download url for $2])
 AS_IF([test "x$$1_URL" = "x"], [
-   AS_IF([test "x$extfiles" = "xy"],
+   m4_if([$#],[3],[$1_URL=\@S|@\@{:@XEN_EXTFILES_URL\@:}@],
+ [$#],[4],[AS_IF([test "x$extfiles" = "xy"],
[$1_URL=\@S|@\@{:@XEN_EXTFILES_URL\@:}@],
[$1_URL="$4"])
-   ])
+],[m4_fatal([AX_STUBDOM_LIB expects 3 or 4 arguments, not $#])])])
 $1_VERSION="$3"
 AC_SUBST($1_URL)
 AC_SUBST($1_VERSION)
diff --git a/stubdom/configure b/stubdom/configure
index 
b8bffceafdd46181e26a79b85405aefb8bc3ff7d..4ea95baa9192f3b319349ac2a14a3055a21ce705
 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -3532,12 +3532,7 @@ fi
 
 if test "x$ZLIB_URL" = "x"; then :
 
-   if test "x$extfiles" = "xy"; then :
-  ZLIB_URL=\$\(XEN_EXTFILES_URL\)
-else
-  ZLIB_URL="http://www.zlib.net;
-fi
-
+   ZLIB_URL=\$\(XEN_EXTFILES_URL\)
 fi
 ZLIB_VERSION="1.2.3"
 
@@ -3633,12 +3628,7 @@ GMP_VERSION="4.3.2"
 
 if test "x$POLARSSL_URL" = "x"; then :
 
-   if test "x$extfiles" = "xy"; then :
-  POLARSSL_URL=\$\(XEN_EXTFILES_URL\)
-else
-  POLARSSL_URL="http://polarssl.org/code/releases;
-fi
-
+   POLARSSL_URL=\$\(XEN_EXTFILES_URL\)
 fi
 POLARSSL_VERSION="1.1.4"
 
@@ -3648,12 +3638,7 @@ POLARSSL_VERSION="1.1.4"
 
 if test "x$TPMEMU_URL" = "x"; then :
 
-   if test "x$extfiles" = "xy"; then :
-  TPMEMU_URL=\$\(XEN_EXTFILES_URL\)
-else
-  TPMEMU_URL="http://download.berlios.de/tpm-emulator;
-fi
-
+   TPMEMU_URL=\$\(XEN_EXTFILES_URL\)
 fi
 TPMEMU_VERSION="0.7.4"
 
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index 
e20d99edac0da88098f4806333edde9f31dbc1a7..c648b1602c227ed5fe63b9fbdf3fa52fd2e1654b
 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -55,15 +55,15 @@ AC_PROG_INSTALL
 AX_DEPENDS_PATH_PROG([vtpm], [CMAKE], [cmake])
 
 # Stubdom libraries version and url setup
-AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3], [http://www.zlib.net])
+AX_STUBDOM_LIB([ZLIB], [zlib], [1.2.3])
 AX_STUBDOM_LIB([LIBPCI], [libpci], [2.2.9], 
[http://www.kernel.org/pub/software/utils/pciutils])
 AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], 
[ftp://sources.redhat.com/pub/newlib])
 AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], 
[http://download.savannah.gnu.org/releases/lwip])
 AX_STUBDOM_LIB([GRUB], [grub], [0.97], [http://alpha.gnu.org/gnu/grub])
 AX_STUBDOM_LIB_NOEXT([OCAML], [ocaml], [4.02.0], 
[http://caml.inria.fr/pub/distrib/ocaml-4.02])
 AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [ftp://ftp.gmplib.org/pub/gmp-4.3.2])
-AX_STUBDOM_LIB([POLARSSL], [polarssl], [1.1.4], 
[http://polarssl.org/code/releases])
-AX_STUBDOM_LIB([TPMEMU], [berlios tpm emulator], [0.7.4], 
[http://download.berlios.de/tpm-emulator])
+AX_STUBDOM_LIB([POLARSSL], [polarssl], [1.1.4])
+AX_STUBDOM_LIB([TPMEMU], [berlios tpm emulator], [0.7.4])
 
 #These stubdoms should be enabled if the dependent one is
 AX_STUBDOM_AUTO_DEPENDS([vtpmmgr], [vtpm])
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[PATCH v6 2/5] Change remaining xenbits.xen.org link to HTTPS

[Demi Marie Obenour]

Obtaining code over an insecure transport is a terrible idea for
blatently obvious reasons.  Even for non-executable data, insecure
transports are considered deprecated.

This patch enforces the use of secure transports for all xenbits.xen.org
URLs.  All altered links have been tested and are known to work.

Signed-off-by: Demi Marie Obenour 
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 
75f1975e5e78af44d36c2372cba6e89b425267a5..b2bef45b059976d5a6320eabada6073004eb22ee
 100644
--- a/Config.mk
+++ b/Config.mk
@@ -191,7 +191,7 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 EMBEDDED_EXTRA_CFLAGS := -fno-pie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions -fno-asynchronous-unwind-tables
 
-XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
+XEN_EXTFILES_URL ?= https://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
 # the internet.  The original download URL is preserved as a comment
 # near the place in the Xen Makefiles where the file is used.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[PATCH v6 1/5] Use HTTPS for all xenbits.xen.org Git repos

[Demi Marie Obenour]

Obtaining code over an insecure transport is a terrible idea for
blatently obvious reasons.  Even for non-executable data, insecure
transports are considered deprecated.

This patch enforces the use of secure transports for all xenbits.xen.org
Git repositories.  It was generated with the following shell script:

git ls-files -z |
xargs -0 -- sed -Ei -- 
's@(git://xenbits\.xen\.org|http://xenbits\.xen\.org/git-http)/@https://xenbits.xen.org/git-http/@g'

All altered links have been tested and are known to work.

Signed-off-by: Demi Marie Obenour 
---
 Config.mk  | 18 +-
 docs/misc/livepatch.pandoc |  2 +-
 docs/process/xen-release-management.pandoc |  2 +-
 scripts/get_maintainer.pl  |  2 +-
 4 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/Config.mk b/Config.mk
index 
10eb443b17d85381b2d1e2282f8965c3e99767e0..75f1975e5e78af44d36c2372cba6e89b425267a5
 100644
--- a/Config.mk
+++ b/Config.mk
@@ -215,19 +215,11 @@ ifneq (,$(QEMU_TAG))
 QEMU_TRADITIONAL_REVISION ?= $(QEMU_TAG)
 endif
 
-ifeq ($(GIT_HTTP),y)
-OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git
-QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-xen.git
-QEMU_TRADITIONAL_URL ?= 
http://xenbits.xen.org/git-http/qemu-xen-traditional.git
-SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
-MINIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/mini-os.git
-else
-OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git
-QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-xen.git
-QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-traditional.git
-SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
-MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
-endif
+OVMF_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/ovmf.git
+QEMU_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/qemu-xen.git
+QEMU_TRADITIONAL_URL ?= 
https://xenbits.xen.org/git-http/qemu-xen-traditional.git
+SEABIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/seabios.git
+MINIOS_UPSTREAM_URL ?= https://xenbits.xen.org/git-http/mini-os.git
 OVMF_UPSTREAM_REVISION ?= 7b4a99be8a39c12d3a7fc4b8db9f0eab4ac688d5
 QEMU_UPSTREAM_REVISION ?= master
 MINIOS_UPSTREAM_REVISION ?= 5bcb28aaeba1c2506a82fab0cdad0201cd9b54b3
diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc
index 
d38e4ce074b399946aecdaedb4cb6fe5b8043b66..a94fb57eb568e85a25c93bf6a988f123d4e48443
 100644
--- a/docs/misc/livepatch.pandoc
+++ b/docs/misc/livepatch.pandoc
@@ -993,7 +993,7 @@ The design of that is not discussed in this design.
 This is implemented in a seperate tool which lives in a seperate
 GIT repo.
 
-Currently it resides at git://xenbits.xen.org/livepatch-build-tools.git
+Currently it resides at 
https://xenbits.xen.org/git-http/livepatch-build-tools.git
 
 ### Exception tables and symbol tables growth
 
diff --git a/docs/process/xen-release-management.pandoc 
b/docs/process/xen-release-management.pandoc
index 
8f80d61d2f1aa9e63da9b1e61b77a67c826efe6f..7826419dad563a3b70c3c97fc4c0fb5339bd58e9
 100644
--- a/docs/process/xen-release-management.pandoc
+++ b/docs/process/xen-release-management.pandoc
@@ -271,7 +271,7 @@ Hi all,
 
 Xen X.Y rcZ is tagged. You can check that out from xen.git:
 
-git://xenbits.xen.org/xen.git X.Y.0-rcZ
+https://xenbits.xen.org/git-http/xen.git X.Y.0-rcZ
 
 For your convenience there is also a tarball at:
 https://downloads.xenproject.org/release/xen/X.Y.0-rcZ/xen-X.Y.0-rcZ.tar.gz
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 
48e07370e8d462ced70a1de13ec8134b4eed65ba..cf629cdf3c44e4abe67214378c49a3a9d858d9b5
 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -1457,7 +1457,7 @@ sub vcs_exists {
warn("$P: No supported VCS found.  Add --nogit to options?\n");
warn("Using a git repository produces better results.\n");
warn("Try latest git repository using:\n");
-   warn("git clone git://xenbits.xen.org/xen.git\n");
+   warn("git clone https://xenbits.xen.org/git-http/xen.git\n;);
$printed_novcs = 1;
 }
 return 0;
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[PATCH v6 0/5] Stop using insecure transports

[Demi Marie Obenour]

Obtaining code over an insecure transport is a terrible idea for
blatently obvious reasons.  Even for non-executable data, insecure
transports are considered deprecated.

Changes since v5:

- Rebase on top of the staging branch.

- Do not replace a xenbits.xenproject.org link with a xenbits.xen.org
  link.

Changes since v4:

- Remove known-broken links entirely.  They only mislead users into
  believing the code can be obtained there when it cannot.

Changes since v3:

- Drop patch 4, which is an unrelated removal of unused code.

- Do not fail with an error if one tries to build the I/O emulator,
  vTPM, or vTPM manager stubdomains and passes --enable-extfiles.  The
  user may have provided alternate download URLs via environment
  variables.

Changes since v2:

- Drop patches 5 and 6, which changed links not used by automated tools.
  These patches are the least urgent and hardest to review.

- Ensure that no links are broken, and fail with an error instead of
  trying to use links that *are* broken.

Demi Marie Obenour (5):
  Use HTTPS for all xenbits.xen.org Git repos
  Change remaining xenbits.xen.org link to HTTPS
  Build system: Do not try to use broken links
  Build system: Replace git:// and http:// with https://
  Automation and CI: Replace git:// and http:// with https://

 Config.mk   | 20 -
 README  |  4 +--
 automation/build/debian/stretch-llvm-8.list |  4 +--
 docs/misc/livepatch.pandoc  |  2 +-
 docs/process/xen-release-management.pandoc  |  2 +-
 m4/stubdom.m4   |  5 ++--
 scripts/get_maintainer.pl   |  2 +-
 stubdom/configure   | 33 ++---
 stubdom/configure.ac| 18 +--
 tools/firmware/etherboot/Makefile   |  6 +---
 10 files changed, 35 insertions(+), 61 deletions(-)

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Re: [PATCH v5 4/7] xen/riscv: introduce decode_cause() stuff

[Julien Grall]

Hi Oleksii,

On 16/03/2023 14:39, Oleksii Kurochko wrote:

The patch introduces stuff needed to decode a reason of an
exception.

Signed-off-by: Oleksii Kurochko 
---
Changes in V5:
   - Remove  from riscv/traps/c as nothing would require
 inclusion.
   - decode_reserved_interrupt_cause(), decode_interrupt_cause(), decode_cause, 
do_unexpected_trap()
 were made as static they are expected to be used only in traps.c
   - use LINK_TO_LOAD() for addresses which can be linker time relative.
---
Changes in V4:
   - fix string in decode_reserved_interrupt_cause()
---
Changes in V3:
   - Nothing changed
---
Changes in V2:
   - Make decode_trap_cause() more optimization friendly.
   - Merge the pathc which introduces do_unexpected_trap() to the current one.
---
  xen/arch/riscv/traps.c | 87 +-
  1 file changed, 86 insertions(+), 1 deletion(-)

diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index ccd3593f5a..8a1529e0c5 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -4,10 +4,95 @@
   *
   * RISC-V Trap handlers
   */
+
+#include 
+
+#include 
+#include 
+#include 
  #include 
  #include 
  
-void do_trap(struct cpu_user_regs *cpu_regs)

+static const char *decode_trap_cause(unsigned long cause)
+{
+static const char *const trap_causes[] = {
+[CAUSE_MISALIGNED_FETCH] = "Instruction Address Misaligned",
+[CAUSE_FETCH_ACCESS] = "Instruction Access Fault",
+[CAUSE_ILLEGAL_INSTRUCTION] = "Illegal Instruction",
+[CAUSE_BREAKPOINT] = "Breakpoint",
+[CAUSE_MISALIGNED_LOAD] = "Load Address Misaligned",
+[CAUSE_LOAD_ACCESS] = "Load Access Fault",
+[CAUSE_MISALIGNED_STORE] = "Store/AMO Address Misaligned",
+[CAUSE_STORE_ACCESS] = "Store/AMO Access Fault",
+[CAUSE_USER_ECALL] = "Environment Call from U-Mode",
+[CAUSE_SUPERVISOR_ECALL] = "Environment Call from S-Mode",
+[CAUSE_MACHINE_ECALL] = "Environment Call from M-Mode",
+[CAUSE_FETCH_PAGE_FAULT] = "Instruction Page Fault",
+[CAUSE_LOAD_PAGE_FAULT] = "Load Page Fault",
+[CAUSE_STORE_PAGE_FAULT] = "Store/AMO Page Fault",
+[CAUSE_FETCH_GUEST_PAGE_FAULT] = "Instruction Guest Page Fault",
+[CAUSE_LOAD_GUEST_PAGE_FAULT] = "Load Guest Page Fault",
+[CAUSE_VIRTUAL_INST_FAULT] = "Virtualized Instruction Fault",
+[CAUSE_STORE_GUEST_PAGE_FAULT] = "Guest Store/AMO Page Fault",
+};
+
+if ( cause < ARRAY_SIZE(trap_causes) && trap_causes[cause] )
+return trap_causes[cause];
+return "UNKNOWN";
+}
+
+static const char *decode_reserved_interrupt_cause(unsigned long irq_cause)
+{
+switch ( irq_cause )
+{
+case IRQ_M_SOFT:
+return "M-mode Software Interrupt";
+case IRQ_M_TIMER:
+return "M-mode TIMER Interrupt";
+case IRQ_M_EXT:
+return "M-mode External Interrupt";
+default:
+return "UNKNOWN IRQ type";
+}
+}
+
+static const char *decode_interrupt_cause(unsigned long cause)
+{
+unsigned long irq_cause = cause & ~CAUSE_IRQ_FLAG;
+
+switch ( irq_cause )
+{
+case IRQ_S_SOFT:
+return "Supervisor Software Interrupt";
+case IRQ_S_TIMER:
+return "Supervisor Timer Interrupt";
+case IRQ_S_EXT:
+return "Supervisor External Interrupt";
+default:
+return decode_reserved_interrupt_cause(irq_cause);
+}
+}
+
+static const char *decode_cause(unsigned long cause)
+{
+if ( cause & CAUSE_IRQ_FLAG )
+return decode_interrupt_cause(cause);
+
+return decode_trap_cause(cause);
+}
+
+static void do_unexpected_trap(const struct cpu_user_regs *regs)
  {
+unsigned long cause = csr_read(CSR_SCAUSE);
+
+early_printk("Unhandled exception: ");
+early_printk(LINK_TO_LOAD(decode_cause(cause)));


The use of LINK_TO_LOAD is the sort of things that is worth documenting 
because this would raise quite a few questions.


The comment on top of LINK_TO_LOAD suggests the macro can only be used 
while the MMU is off. But I would expect do_unexpected_trap() to be used 
also after the MMU is on. Isn't it going to be the case?


Furthermore, AFAICT LINK_TO_LOAD() assumes that a runtime address is 
given. While I believe this could be true for pointer returned by 
decode_trap_cause() (I remember seen on Arm that an array of string 
would store the runtime address), I am not convinced this is the case 
for pointer returned by decode_interrupt_cause().


Lastly, I think you will want to document what functions can be used 
when the MMU is off and possibly splitting the code. So it is easier for 
someone to figure out in which context the function and if this is safe 
to use.


Cheers,

--
Julien Grall

[libvirt test] 179829: tolerable trouble: pass/starved - PUSHED

[osstest service owner]

flight 179829 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179829/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  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-amd64-libvirt 15 migrate-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-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 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-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 build-armhf-libvirt   1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   starved  n/a
 build-armhf   2 hosts-allocate   starved  n/a

version targeted for testing:
 libvirt  4be3ba0226ec2816ba202e9aac1e4ad049c7e818
baseline version:
 libvirt  27d8bcc337c45f08af56211deccf8f77d9561888

Last test of basis   179746  2023-03-18 04:30:36 Z3 days
Testing same since   179829  2023-03-21 04:18:50 Z0 days1 attempts


People who touched revisions under test:
  Ján Tomko 
  Shaleen Bathla 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  starved 
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  starved 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt starved 
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-qcow2   starved 
 test-arm64-arm64-libvirt-raw pass
 test-armhf-armhf-libvirt-raw starved 
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-libvirt-vhd 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

Re: [PATCH v5 3/7] xen/riscv: introduce dummy

[Julien Grall]

Hi Oleksii,

On 16/03/2023 14:39, Oleksii Kurochko wrote:

 will be used in the patch "xen/riscv: introduce
decode_cause() stuff" and requires 

Signed-off-by: Oleksii Kurochko 
---
Changes in V5:
  * the patch was introduced in the current patch series (V5)
---
  xen/arch/riscv/include/asm/bug.h | 10 ++
  1 file changed, 10 insertions(+)
  create mode 100644 xen/arch/riscv/include/asm/bug.h

diff --git a/xen/arch/riscv/include/asm/bug.h b/xen/arch/riscv/include/asm/bug.h
new file mode 100644
index 00..e8b1e40823
--- /dev/null
+++ b/xen/arch/riscv/include/asm/bug.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2012 Regents of the University of California
+ * Copyright (C) 2021-2023 Vates


I am a bit puzzled with those copyright given the header is empty.

But is there any reason this can't be folded in #6 or part of #6 moved 
forward?



+ *


NIT: Drop the line.


+ */
+#ifndef _ASM_RISCV_BUG_H
+#define _ASM_RISCV_BUG_H
+
+#endif /* _ASM_RISCV_BUG_H */


--
Julien Grall

Re: [PATCH v3 1/4] tools: rename xen-tools/libs.h file to common-macros.h

[Anthony PERARD]

On Mon, Mar 06, 2023 at 08:21:37AM +0100, Juergen Gross wrote:
> In order to better reflect the contents of the header and to make it
> more appropriate to use it for different runtime environments like
> programs, libraries, and firmware, rename the libs.h include file to
> common-macros.h. Additionally add a comment pointing out the need to be
> self-contained.
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Juergen Gross 
> Acked-by: Marek Marczykowski-Górecki  # 
> tools/python/xen/lowlevel/xc/xc.c
> Acked-by: Christian Lindig 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

[PATCH] xen/arm: irq: Constify the first parameter of platform_get_irq_byname()

[Julien Grall]

From: Julien Grall 

platform_get_irq_byname() is not meant to modify the parameter 'np'. So
constify it.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/include/asm/irq.h | 2 +-
 xen/arch/arm/irq.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h
index af94f41994f1..11bc85d1110c 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -89,7 +89,7 @@ int irq_set_type(unsigned int irq, unsigned int type);
 
 int platform_get_irq(const struct dt_device_node *device, int index);
 
-int platform_get_irq_byname(struct dt_device_node *np, const char *name);
+int platform_get_irq_byname(const struct dt_device_node *np, const char *name);
 
 void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
 
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index ded495792b7c..16e56f8945a8 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -718,7 +718,7 @@ int platform_get_irq(const struct dt_device_node *device, 
int index)
 return irq;
 }
 
-int platform_get_irq_byname(struct dt_device_node *np, const char *name)
+int platform_get_irq_byname(const struct dt_device_node *np, const char *name)
 {
int index;
 
-- 
2.39.2

Re: [PATCH v3 2/2] arch/arm: time: Add support for parsing interrupts by names

[Julien Grall]

Hi,

On 13/03/2023 13:08, Andrei Cherechesu (OSS) wrote:

From: Andrei Cherechesu 

Added support for parsing the ARM generic timer interrupts DT
node by the "interrupt-names" property, if it is available.

If not available, the usual parsing based on the expected
IRQ order is performed.

Also treated returning 0 as an error case for the
platform_get_irq() calls, since it is not a valid PPI ID and
treating it as a valid case would only cause Xen to BUG() later,
when trying to reserve vIRQ being SGI.

Added the "hyp-virt" PPI to the timer PPI list, even
though it's currently not in use. If the "hyp-virt" PPI is
not found, the hypervisor won't panic.


I know this was already merged. But it would have been nice to explain 
why this is added. As this stands, it looks unnecessary dead code which 
would have been okay if ...




Signed-off-by: Andrei Cherechesu 
---
  xen/arch/arm/include/asm/time.h |  3 ++-
  xen/arch/arm/time.c | 26 ++
  2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/include/asm/time.h b/xen/arch/arm/include/asm/time.h
index 4b401c1110..49ad8c1a6d 100644
--- a/xen/arch/arm/include/asm/time.h
+++ b/xen/arch/arm/include/asm/time.h
@@ -82,7 +82,8 @@ enum timer_ppi
  TIMER_PHYS_NONSECURE_PPI = 1,
  TIMER_VIRT_PPI = 2,
  TIMER_HYP_PPI = 3,
-MAX_TIMER_PPI = 4,
+TIMER_HYP_VIRT_PPI = 4,
+MAX_TIMER_PPI = 5,
  };
  
  /*

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 433d7be909..0b482d7db3 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -149,15 +149,33 @@ static void __init init_dt_xen_time(void)
  {
  int res;
  unsigned int i;
+bool has_names;
+static const char * const timer_irq_names[MAX_TIMER_PPI] __initconst = {
+[TIMER_PHYS_SECURE_PPI] = "sec-phys",
+[TIMER_PHYS_NONSECURE_PPI] = "phys",
+[TIMER_VIRT_PPI] = "virt",
+[TIMER_HYP_PPI] = "hyp-phys",
+[TIMER_HYP_VIRT_PPI] = "hyp-virt",
+};
+
+has_names = dt_property_read_bool(timer, "interrupt-names");
  
  /* Retrieve all IRQs for the timer */

  for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
  {
-res = platform_get_irq(timer, i);
-
-if ( res < 0 )
+if ( has_names )
+res = platform_get_irq_byname(timer, timer_irq_names[i]);
+else
+res = platform_get_irq(timer, i);
+
+if ( res > 0 )
+timer_irq[i] = res;
+/*
+ * Do not panic if "hyp-virt" PPI is not found, since it's not
+ * currently used.
+ */
+else if ( i != TIMER_HYP_VIRT_PPI )
  panic("Timer: Unable to retrieve IRQ %u from the device tree\n", 
i);


... this wasn't necessary.


-timer_irq[i] = res;
  }
  }
  


Cheers,

--
Julien Grall

Re: [PATCH v2 2/3] xen/riscv: setup initial pagetables

[Oleksii]

On Mon, 2023-03-20 at 18:03 +0100, Jan Beulich wrote:
> On 16.03.2023 17:43, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko 
> > ---
> > Changes in V2:
> >  * Update the commit message
> 
> Odd: It's empty. Since it's not part of the title, you could at least
> say that you're also enabling the MMU. (Most of the time entirely
> empty descriptions are suspicious.)
I thought that 'setup' includes 'enable' too.
Probably I have to reword the commit message.

~ Oleksii

Re: [PATCH v2 1/3] xen/riscv: introduce setup_initial_pages

[Oleksii]

On Mon, 2023-03-20 at 17:41 +0100, Jan Beulich wrote:
> On 16.03.2023 17:43, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/mm.h
> > @@ -0,0 +1,8 @@
> > +#ifndef _ASM_RISCV_MM_H
> > +#define _ASM_RISCV_MM_H
> > +
> > +void setup_initial_pagetables(void);
> > +
> > +extern void enable_mmu(void);
> 
> Nit: At least within a single header you probably want to be
> consistent
> about the use of "extern". Personally I think it would better be
> omitted
> from function declarations.
Agree. It would be better to remove extern.

> 
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/page.h
> > @@ -0,0 +1,67 @@
> > +#ifndef _ASM_RISCV_PAGE_H
> > +#define _ASM_RISCV_PAGE_H
> > +
> > +#include 
> > +#include 
> > +
> > +#define PAGE_ENTRIES    (1 << PAGETABLE_ORDER)
> > +#define VPN_MASK    ((unsigned long)(PAGE_ENTRIES
> > - 1))
> > +
> > +#define PAGE_ORDER  (12)
> 
> DYM PAGE_SHIFT here, as used elsewhere in Xen?
yes, PAGE_SHIFT is meant here.

> 
> Also are you aware of page-bits.h, where I think some of these
> constants
> should go?
I'll move some constants to page-bits.h

> 
> > +#ifdef CONFIG_RISCV_64
> > +#define PAGETABLE_ORDER (9)
> > +#else /* CONFIG_RISCV_32 */
> > +#define PAGETABLE_ORDER (10)
> > +#endif
> > +
> > +#define LEVEL_ORDER(lvl)    (lvl * PAGETABLE_ORDER)
> > +#define LEVEL_SHIFT(lvl)    (LEVEL_ORDER(lvl) +
> > PAGE_ORDER)
> > +#define LEVEL_SIZE(lvl) (_AT(paddr_t, 1) <<
> > LEVEL_SHIFT(lvl))
> > +
> > +#define XEN_PT_LEVEL_SHIFT(lvl) LEVEL_SHIFT(lvl)
> > +#define XEN_PT_LEVEL_ORDER(lvl) LEVEL_ORDER(lvl)
> > +#define XEN_PT_LEVEL_SIZE(lvl)  LEVEL_SIZE(lvl)
> 
> Mind me asking what these are good for? Doesn't one set of macros
> suffice?
Do you mean XEN_PT_LEVEL_{SHIFT...}? it can be used only one pair of
macros. I'll check how they are used in ARM ( I copied that macros from
there ).
> 
> > +#define XEN_PT_LEVEL_MAP_MASK(lvl)  (~(XEN_PT_LEVEL_SIZE(lvl) -
> > 1))
> > +#define XEN_PT_LEVEL_MASK(lvl)  (VPN_MASK <<
> > XEN_PT_LEVEL_SHIFT(lvl))
> > +
> > +#define PTE_SHIFT   10
> 
> What does this describe? According to its single use here it may
> simply require a better name.
If look at Sv39 page table entry in riscv-priviliged.pdf. It has the
following description:
  63 62 61  6054  53  28 27  19 18  10 9 8 7 6 5 4 3 2 1 0
  N  PBMT   Rererved  PPN[2] PPN[1] PPN[0] RSW D A G U X W R V
So 10 it means the 0-9 bits.

> 
> > +#define PTE_VALID   BIT(0, UL)
> > +#define PTE_READABLE    BIT(1, UL)
> > +#define PTE_WRITABLE    BIT(2, UL)
> > +#define PTE_EXECUTABLE  BIT(3, UL)
> > +#define PTE_USER    BIT(4, UL)
> > +#define PTE_GLOBAL  BIT(5, UL)
> > +#define PTE_ACCESSED    BIT(6, UL)
> > +#define PTE_DIRTY   BIT(7, UL)
> > +#define PTE_RSW (BIT(8, UL) | BIT(9, UL))
> > +
> > +#define PTE_LEAF_DEFAULT    (PTE_VALID | PTE_READABLE |
> > PTE_EXECUTABLE)
> > +#define PTE_TABLE   (PTE_VALID)
> > +
> > +/* Calculate the offsets into the pagetables for a given VA */
> > +#define pt_linear_offset(lvl, va)   ((va) >>
> > XEN_PT_LEVEL_SHIFT(lvl))
> > +
> > +#define pt_index(lvl, va)   pt_linear_offset(lvl, (va) &
> > XEN_PT_LEVEL_MASK(lvl))
> > +
> > +/* Page Table entry */
> > +typedef struct {
> > +    uint64_t pte;
> > +} pte_t;
> 
> Not having read the respective spec (yet) I'm wondering if this
> really
> is this way also for RV32 (despite the different PAGETABLE_ORDER).
RISC-V architecture support several MMU mode to translate VA to PA.
The following mode can be: Sv32, Sv39, Sv48, Sv57 and PAGESIZE is equal
to 8 in all cases except Sv32 ( it is equal to 4 ). but I looked at
different big projects who have RISC-V support and no one supports
Sv32.

So it will be correct for RV32 as it supports the same Sv32 and Sv39
modes too.
> 
> > --- /dev/null
> > +++ b/xen/arch/riscv/mm.c
> > @@ -0,0 +1,121 @@
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/*
> > + * xen_second_pagetable is indexed with the VPN[2] page table
> > entry field
> > + * xen_first_pagetable is accessed from the VPN[1] page table
> > entry field
> > + * xen_zeroeth_pagetable is accessed from the VPN[0] page table
> > entry field
> > + */
> > +pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > +    xen_second_pagetable[PAGE_ENTRIES];
> > +static pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > +    xen_first_pagetable[PAGE_ENTRIES];
> > +static pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > +    xen_zeroeth_pagetable[PAGE_ENTRIES];
> 
> I would assume Andrew's comment on the earlier version also extended
> to
> the names used here (and then also to 

Re: [PATCH v2] x86: use POPCNT for hweight() when available

[Roger Pau Monné]

On Tue, Mar 21, 2023 at 05:41:52PM +0100, Jan Beulich wrote:
> On 21.03.2023 17:31, Roger Pau Monné wrote:
> > On Tue, Mar 21, 2023 at 04:35:54PM +0100, Jan Beulich wrote:
> >> On 21.03.2023 15:57, Roger Pau Monné wrote:
> >>> On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote:
>  On 17.03.2023 13:26, Andrew Cooper wrote:
> > On 17/03/2023 11:22 am, Roger Pau Monné wrote:
> >> On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
> >>> This is faster than using the software implementation, and the insn is
> >>> available on all half-way recent hardware. Therefore convert
> >>> generic_hweight() to out-of-line functions (without affecting Arm)
> >>> and use alternatives patching to replace the function calls.
> >>>
> >>> Note that the approach doesn#t work for clang, due to it not 
> >>> recognizing
> >>> -ffixed-*.
> >> I've been giving this a look, and I wonder if it would be fine to
> >> simply push and pop the scratch registers in the 'call' path of the
> >> alternative, as that won't require any specific compiler option.
> 
>  Hmm, ...
> 
> > It's been a long while, and in that time I've learnt a lot more about
> > performance, but my root objection to the approach taken here still
> > stands - it is penalising the common case to optimise some pointless
> > corner cases.
> >
> > Yes - on the call path, an extra push/pop pair (or few) to get temp
> > registers is basically free.
> 
>  ... what is "a few"? We'd need to push/pop all call-clobbered registers
>  except %rax, i.e. a total of eight. I consider this too much. Unless,
>  as you suggest further down, we wrote the fallback in assembly. Which I
>  have to admit I'm surprised you propose when we strive to reduce the
>  amount of assembly we have to maintain.
> >>>
> >>> AMD added popcnt in 2007 and Intel in 2008.  While we shouldn't
> >>> mandate popcnt support, I think we also shouldn't overly worry about
> >>> the non-popcnt path.
> >>
> >> We agree here.
> >>
> >>> Also, how can you assert that the code generated without the scratch
> >>> registers being usable won't be worse than the penalty of pushing and
> >>> popping such registers on the stack and letting the routines use all
> >>> registers freely?
> >>
> >> Irrespective of the -ffixed-* the compiler can make itself sufficiently
> >> many registers available to use, by preserving just the ones it actually
> >> uses. So that's pretty certainly not more PUSH/POP than when we would
> >> blindly preserve all which may need preserving (no matter whether
> >> they're actually used).
> >>
> >> Yet then both this question and ...
> >>
> >>> I very much prefer to have a non-optimal non-popcnt path, but have
> >>> popcnt support for both gcc and clang, and without requiring any
> >>> compiler options.
> >>
> >> ... this makes me wonder whether we're thinking of fundamentally
> >> different generated code that we would end up with. Since the
> >> (apparently agreed upon) goal is to optimize for the "popcnt
> >> available" case, mainline code should be not significantly longer that
> >> what's needed for the single instruction itself, or alternatively a
> >> CALL insn. Adding pushes/pops of all call clobbered registers around
> >> the CALL would grow mainline code too much (for my taste), i.e.
> >> irrespective of these PUSH/POP all getting NOP-ed out by alternatives
> >> patching. (As an aside I consider fiddling with the stack pointer in
> >> inline asm() risky, and hence I would prefer to avoid such whenever
> >> possible.
> > 
> > Is this because we are likely to not end up with a proper trace if we
> > mess up with the stack pointer before a function call?
> 
> That's a related issue, but not what I was thinking about.
> 
> >  I would like
> > to better understand your concerns with the stack pointer and inline
> > asm().
> 
> You can't use local variables anymore with "m" or "rm" constraints, as
> they might be accessed via %rsp.
> 
> > Other options would be using no_caller_saved_registers, but that's not
> > available in all supported gcc versions, likely the same with clang,
> > but I wouldn't mind upping the minimal clang version.
> 
> Right, you did suggest using this attribute before. But we continue to
> support older gcc.

FWIW, I would be fine with not enabling the optimization if the
attribute is not available, but then again this means adding more
logic.  At the end this is just an optimization, so I think it's fine
to request a version of gcc greater than the supported baseline.

> > What about allocating the size of the registers that need saving as an
> > on-stack variable visible to the compiler and then moving to/from
> > there in the inline asm()?
> 
> That would address the fiddling-with-%rsp concern, but would further
> grow mainline code size.

I'm fine with such growth, unless you can prove the growth in code
size shadows the performance 

Re: [PATCH] move {,vcpu_}show_execution_state() declarations to common header

[Jan Beulich]

On 21.03.2023 17:44, Julien Grall wrote:
> On 16/03/2023 11:55, Jan Beulich wrote:
>> These are used from common code, so their signatures should be
>> consistent across architectures. This is achieved / guaranteed easiest
>> when their declarations are in a common header.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> There's no really good header to put the decls, imo; I wanted to avoid
>> the already overcrowded sched.h. show_execution_state_nonconst(), being
>> there solely for dump_execution_state(), could of course live in the
>> upcoming xen/bug.h ...
>>
>> Is there a reason that Arm (still) expands dump_execution_state() to
>> WARN()? Without that moving x86's show_execution_state_nonconst()
>> definition to common code would also make sense (it could be done
>> anyway, but then at the expense of introducing dead code to Arm),
>> perhaps (see also above) into the upcoming common/bug.c.
> 
> run_in_exception_handler() was only properly implemented a couple of 
> years ago on Arm and we didn't switch dump_execution_state() to use it.
> 
> That said, the current implementation of run_in_exception_handler() 
> would not be correct for dump_execution_state() because it clobbers 
> x0/r0 on Arm.
> 
> This should be addressed with Oleksandr work to consolidate the bug 
> infrastructure. So it would be fine to move the helper to common code now.

Well, Oleksii's work hasn't landed yet. I'll try to remember to follow
up once it has.

> Alternatively this can be left as a clean-up because 
> dump_executation_state() could now be common.
> 
> Anyway:
> 
> Acked-by: Julien Grall 

Thanks.

Jan

Re: [PATCH v3 1/2] arch/arm: irq: Add platform_get_irq_byname() implementation

[Julien Grall]

Hi Andrei,

I realized this has already been merged. But I would like to point out a 
few things for future series.


On 13/03/2023 13:08, Andrei Cherechesu (OSS) wrote:

From: Andrei Cherechesu 

Moved implementation for the function which parses the IRQs of a DT
node by the "interrupt-names" property from the SMMU-v3 driver
to the IRQ core code and made it non-static to be used as helper.

Also changed it to receive a "struct dt_device_node*" as parameter,
like its counterpart, platform_get_irq(). Updated its usage inside
the SMMU-v3 driver accordingly.

Signed-off-by: Andrei Cherechesu 
Reviewed-by: Bertrand Marquis 
---
  xen/arch/arm/include/asm/irq.h|  2 ++
  xen/arch/arm/irq.c| 14 +++
  xen/drivers/passthrough/arm/smmu-v3.c | 35 +--
  3 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h
index 245f49dcba..af94f41994 100644
--- a/xen/arch/arm/include/asm/irq.h
+++ b/xen/arch/arm/include/asm/irq.h
@@ -89,6 +89,8 @@ int irq_set_type(unsigned int irq, unsigned int type);
  
  int platform_get_irq(const struct dt_device_node *device, int index);
  
+int platform_get_irq_byname(struct dt_device_node *np, const char *name);

+
  void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
  
  /*

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 79718f68e7..ded495792b 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -718,6 +718,20 @@ int platform_get_irq(const struct dt_device_node *device, 
int index)
  return irq;
  }
  
+int platform_get_irq_byname(struct dt_device_node *np, const char *name)


You are changing the name but don't really explain why. "np" also ought 
to be const as this is not meant to be modified.



+{
+   int index;
+
+   if ( unlikely(!name) )
+   return -EINVAL;
+
+   index = dt_property_match_string(np, "interrupt-names", name);
+   if ( index < 0 )
+   return index;
+
+   return platform_get_irq(np, index);


The existing helper was returning -ENODEV when there is an error. But 
here, you went differently. This is the sort of thing that ought to be 
explained in the commit message because it is not obvious why you 
changed it *and* that you actually checked the callers are OK with that.


Thankfully they are all.

Cheers,

--
Julien Grall

Re: [XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

[Jan Beulich]

On 21.03.2023 17:15, Ayan Kumar Halder wrote:
> On 21/03/2023 14:22, Jan Beulich wrote:
>> On 21.03.2023 15:03, Ayan Kumar Halder wrote:
>>> --- a/xen/arch/Kconfig
>>> +++ b/xen/arch/Kconfig
>>> @@ -1,6 +1,12 @@
>>>   config 64BIT
>>> bool
>>>   
>>> +config PHYS_ADDR_T_32
>>> +   bool
>>> +
>>> +config PHYS_ADDR_T_64
>>> +   bool
>> Do we really need both?
> I was thinking the same. I am assuming that in future we may have
> 
> PHYS_ADDR_T_16,

Really? What contemporary system would be able to run in just 64k?
Certainly not Xen, let alone any Dom0 on top of it.

> PHYS_ADDR_T_128. So, I am hoping that defining them explicitly might help.

Yes, 128-bit addresses may appear at some point. Then (and only then)
we'll need two controls, and we can then think about how to represent
them properly without risking issues.

> Also, the user cannot select these configs directly.

Sure, but at some point some strange combination of options might that
randconfig manages to construct.

>> If so, what guards against both being selected
>> at the same time?
> At present, we rely on "select".

You mean 'we rely on there being only one "select"'? Else I'm afraid I
don't understand your reply.

>> Them being put in common code I consider it an at least latent issue
>> that you add "select"s ...
>>
>>> --- a/xen/arch/arm/Kconfig
>>> +++ b/xen/arch/arm/Kconfig
>>> @@ -9,6 +9,7 @@ config ARM_64
>>> select 64BIT
>>> select ARM_EFI
>>> select HAS_FAST_MULTIPLY
>>> +   select PHYS_ADDR_T_64
>>>   
>>>   config ARM
>>> def_bool y
>>> @@ -19,13 +20,48 @@ config ARM
>>> select HAS_PMAP
>>> select IOMMU_FORCE_PT_SHARE
>>>   
>>> +menu "Architecture Features"
>>> +
>>> +choice
>>> +   prompt "Physical address space size" if ARM_32
>>> +   default ARM_PA_BITS_48 if ARM_64
>>> +   default ARM_PA_BITS_40 if ARM_32
>>> +   help
>>> + User can choose to represent the width of physical address. This can
>>> + sometimes help in optimizing the size of image when user chooses a
>>> + smaller size to represent physical address.
>>> +
>>> +config ARM_PA_BITS_32
>>> +   bool "32-bit"
>>> +   help
>>> + On platforms where any physical address can be represented within 32 
>>> bits
>>> + , user should choose this option. This will help is reduced size of 
>>> the
>>> + binary.
>>> +   select PHYS_ADDR_T_32
>>> +   depends on ARM_32
>>> +
>>> +config ARM_PA_BITS_40
>>> +   bool "40-bit"
>>> +   select PHYS_ADDR_T_64
>>> +   depends on ARM_32
>>> +
>>> +config ARM_PA_BITS_48
>>> +   bool "40-bit"
>>> +   select PHYS_ADDR_T_64
>>> +   depends on ARM_48
>>> +endchoice
>> ... only for Arm. You get away with this only because ...
>>
>>> --- a/xen/arch/arm/include/asm/types.h
>>> +++ b/xen/arch/arm/include/asm/types.h
>>> @@ -34,9 +34,15 @@ typedef signed long long s64;
>>>   typedef unsigned long long u64;
>>>   typedef u32 vaddr_t;
>>>   #define PRIvaddr PRIx32in
>>> +#if defined(CONFIG_PHYS_ADDR_T_32)
>>> +typedef unsigned long paddr_t;
>>> +#define INVALID_PADDR (~0UL)
>>> +#define PRIpaddr "08lx"
>>> +#else
>>>   typedef u64 paddr_t;
>>>   #define INVALID_PADDR (~0ULL)
>>>   #define PRIpaddr "016llx"
>>> +#endif
>>>   typedef u32 register_t;
>>>   #define PRIregister "08x"
>>>   #elif defined (CONFIG_ARM_64)
>> ... you tweak things here, when we're in the process of moving stuff
>> out of asm/types.h.
> 
> Are you suggesting not to add anything to asm/types.h ? IOW, the above 
> snippet should
> 
> be added to xen/include/xen/types.h.

It's not your snippet alone, but the definition of paddr_t in general
which should imo be moved (as a follow-on to "common: move standard C
fixed width type declarations to common header"). If your patch in its
present shape landed first, that movement would become more
complicated - first and foremost "select"ing the appropriate
PHYS_ADDR_T_* on x86 and RISC-V would then need to be done there, when
it really doesn't belong there.

>> (Using "unsigned long" for a 32-bit paddr_t is of
>> course suspicious as well - this ought to be uint32_t.)
> 
> The problem with using uint32_t for paddr_t is that there are instances 
> where the paddr_t is modified with PAGE_MASK or PAGE_ALIGN.
> 
> For eg , handle_passthrough_prop()
> 
>      printk(XENLOG_ERR "Unable to permit to dom%d access to"
>     " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
>     kinfo->d->domain_id,
>     mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
> 
> And in xen/include/xen/page-size.h,
> 
> #define PAGE_SIZE   (_AC(1,L) << PAGE_SHIFT)
> #define PAGE_MASK   (~(PAGE_SIZE-1))
> 
> Thus, the resulting types are unsigned long. This cannot be printed 
> using %u for PRIpaddr.

Is there anything wrong with making PAGE_SIZE expand to (1 << PAGE_SHIFT)
when physical addresses are only 32 bits wide?

> I remember some discussion (or comment) that the physical addresses 
> should be represented using 'unsigned long'.

A reference would be 

Re: [PATCH] move {,vcpu_}show_execution_state() declarations to common header

[Julien Grall]

Hi Jan,

On 16/03/2023 11:55, Jan Beulich wrote:

These are used from common code, so their signatures should be
consistent across architectures. This is achieved / guaranteed easiest
when their declarations are in a common header.

Signed-off-by: Jan Beulich 
---
There's no really good header to put the decls, imo; I wanted to avoid
the already overcrowded sched.h. show_execution_state_nonconst(), being
there solely for dump_execution_state(), could of course live in the
upcoming xen/bug.h ...

Is there a reason that Arm (still) expands dump_execution_state() to
WARN()? Without that moving x86's show_execution_state_nonconst()
definition to common code would also make sense (it could be done
anyway, but then at the expense of introducing dead code to Arm),
perhaps (see also above) into the upcoming common/bug.c.


run_in_exception_handler() was only properly implemented a couple of 
years ago on Arm and we didn't switch dump_execution_state() to use it.


That said, the current implementation of run_in_exception_handler() 
would not be correct for dump_execution_state() because it clobbers 
x0/r0 on Arm.


This should be addressed with Oleksandr work to consolidate the bug 
infrastructure. So it would be fine to move the helper to common code now.


Alternatively this can be left as a clean-up because 
dump_executation_state() could now be common.


Anyway:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v2] x86: use POPCNT for hweight() when available

[Jan Beulich]

On 21.03.2023 17:31, Roger Pau Monné wrote:
> On Tue, Mar 21, 2023 at 04:35:54PM +0100, Jan Beulich wrote:
>> On 21.03.2023 15:57, Roger Pau Monné wrote:
>>> On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote:
 On 17.03.2023 13:26, Andrew Cooper wrote:
> On 17/03/2023 11:22 am, Roger Pau Monné wrote:
>> On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
>>> This is faster than using the software implementation, and the insn is
>>> available on all half-way recent hardware. Therefore convert
>>> generic_hweight() to out-of-line functions (without affecting Arm)
>>> and use alternatives patching to replace the function calls.
>>>
>>> Note that the approach doesn#t work for clang, due to it not recognizing
>>> -ffixed-*.
>> I've been giving this a look, and I wonder if it would be fine to
>> simply push and pop the scratch registers in the 'call' path of the
>> alternative, as that won't require any specific compiler option.

 Hmm, ...

> It's been a long while, and in that time I've learnt a lot more about
> performance, but my root objection to the approach taken here still
> stands - it is penalising the common case to optimise some pointless
> corner cases.
>
> Yes - on the call path, an extra push/pop pair (or few) to get temp
> registers is basically free.

 ... what is "a few"? We'd need to push/pop all call-clobbered registers
 except %rax, i.e. a total of eight. I consider this too much. Unless,
 as you suggest further down, we wrote the fallback in assembly. Which I
 have to admit I'm surprised you propose when we strive to reduce the
 amount of assembly we have to maintain.
>>>
>>> AMD added popcnt in 2007 and Intel in 2008.  While we shouldn't
>>> mandate popcnt support, I think we also shouldn't overly worry about
>>> the non-popcnt path.
>>
>> We agree here.
>>
>>> Also, how can you assert that the code generated without the scratch
>>> registers being usable won't be worse than the penalty of pushing and
>>> popping such registers on the stack and letting the routines use all
>>> registers freely?
>>
>> Irrespective of the -ffixed-* the compiler can make itself sufficiently
>> many registers available to use, by preserving just the ones it actually
>> uses. So that's pretty certainly not more PUSH/POP than when we would
>> blindly preserve all which may need preserving (no matter whether
>> they're actually used).
>>
>> Yet then both this question and ...
>>
>>> I very much prefer to have a non-optimal non-popcnt path, but have
>>> popcnt support for both gcc and clang, and without requiring any
>>> compiler options.
>>
>> ... this makes me wonder whether we're thinking of fundamentally
>> different generated code that we would end up with. Since the
>> (apparently agreed upon) goal is to optimize for the "popcnt
>> available" case, mainline code should be not significantly longer that
>> what's needed for the single instruction itself, or alternatively a
>> CALL insn. Adding pushes/pops of all call clobbered registers around
>> the CALL would grow mainline code too much (for my taste), i.e.
>> irrespective of these PUSH/POP all getting NOP-ed out by alternatives
>> patching. (As an aside I consider fiddling with the stack pointer in
>> inline asm() risky, and hence I would prefer to avoid such whenever
>> possible.
> 
> Is this because we are likely to not end up with a proper trace if we
> mess up with the stack pointer before a function call?

That's a related issue, but not what I was thinking about.

>  I would like
> to better understand your concerns with the stack pointer and inline
> asm().

You can't use local variables anymore with "m" or "rm" constraints, as
they might be accessed via %rsp.

> Other options would be using no_caller_saved_registers, but that's not
> available in all supported gcc versions, likely the same with clang,
> but I wouldn't mind upping the minimal clang version.

Right, you did suggest using this attribute before. But we continue to
support older gcc.

> What about allocating the size of the registers that need saving as an
> on-stack variable visible to the compiler and then moving to/from
> there in the inline asm()?

That would address the fiddling-with-%rsp concern, but would further
grow mainline code size.

>> Yes, it can be written so it's independent of what the
>> compiler thinks the stack pointer points at, but such constructs are
>> fragile as soon as one wants to change them a little later on.)
>>
>> Are you perhaps thinking of indeed having the PUSH/POP in mainline
>> code? Or some entirely different model?
>>
>> What I could see us doing to accommodate Clang is to have wrappers
>> around the actual functions which do as you suggest and preserve all
>> relevant registers, no matter whether they're used. That'll still be
>> assembly code to maintain, but imo less of a concern than in Andrew's
>> model of writing 

Re: [PATCH v2] x86: use POPCNT for hweight() when available

[Roger Pau Monné]

On Tue, Mar 21, 2023 at 04:35:54PM +0100, Jan Beulich wrote:
> On 21.03.2023 15:57, Roger Pau Monné wrote:
> > On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote:
> >> On 17.03.2023 13:26, Andrew Cooper wrote:
> >>> On 17/03/2023 11:22 am, Roger Pau Monné wrote:
>  On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
> > This is faster than using the software implementation, and the insn is
> > available on all half-way recent hardware. Therefore convert
> > generic_hweight() to out-of-line functions (without affecting Arm)
> > and use alternatives patching to replace the function calls.
> >
> > Note that the approach doesn#t work for clang, due to it not recognizing
> > -ffixed-*.
>  I've been giving this a look, and I wonder if it would be fine to
>  simply push and pop the scratch registers in the 'call' path of the
>  alternative, as that won't require any specific compiler option.
> >>
> >> Hmm, ...
> >>
> >>> It's been a long while, and in that time I've learnt a lot more about
> >>> performance, but my root objection to the approach taken here still
> >>> stands - it is penalising the common case to optimise some pointless
> >>> corner cases.
> >>>
> >>> Yes - on the call path, an extra push/pop pair (or few) to get temp
> >>> registers is basically free.
> >>
> >> ... what is "a few"? We'd need to push/pop all call-clobbered registers
> >> except %rax, i.e. a total of eight. I consider this too much. Unless,
> >> as you suggest further down, we wrote the fallback in assembly. Which I
> >> have to admit I'm surprised you propose when we strive to reduce the
> >> amount of assembly we have to maintain.
> > 
> > AMD added popcnt in 2007 and Intel in 2008.  While we shouldn't
> > mandate popcnt support, I think we also shouldn't overly worry about
> > the non-popcnt path.
> 
> We agree here.
> 
> > Also, how can you assert that the code generated without the scratch
> > registers being usable won't be worse than the penalty of pushing and
> > popping such registers on the stack and letting the routines use all
> > registers freely?
> 
> Irrespective of the -ffixed-* the compiler can make itself sufficiently
> many registers available to use, by preserving just the ones it actually
> uses. So that's pretty certainly not more PUSH/POP than when we would
> blindly preserve all which may need preserving (no matter whether
> they're actually used).
> 
> Yet then both this question and ...
> 
> > I very much prefer to have a non-optimal non-popcnt path, but have
> > popcnt support for both gcc and clang, and without requiring any
> > compiler options.
> 
> ... this makes me wonder whether we're thinking of fundamentally
> different generated code that we would end up with. Since the
> (apparently agreed upon) goal is to optimize for the "popcnt
> available" case, mainline code should be not significantly longer that
> what's needed for the single instruction itself, or alternatively a
> CALL insn. Adding pushes/pops of all call clobbered registers around
> the CALL would grow mainline code too much (for my taste), i.e.
> irrespective of these PUSH/POP all getting NOP-ed out by alternatives
> patching. (As an aside I consider fiddling with the stack pointer in
> inline asm() risky, and hence I would prefer to avoid such whenever
> possible.

Is this because we are likely to not end up with a proper trace if we
mess up with the stack pointer before a function call?  I would like
to better understand your concerns with the stack pointer and inline
asm().

Other options would be using no_caller_saved_registers, but that's not
available in all supported gcc versions, likely the same with clang,
but I wouldn't mind upping the minimal clang version.

What about allocating the size of the registers that need saving as an
on-stack variable visible to the compiler and then moving to/from
there in the inline asm()?

> Yes, it can be written so it's independent of what the
> compiler thinks the stack pointer points at, but such constructs are
> fragile as soon as one wants to change them a little later on.)
> 
> Are you perhaps thinking of indeed having the PUSH/POP in mainline
> code? Or some entirely different model?
> 
> What I could see us doing to accommodate Clang is to have wrappers
> around the actual functions which do as you suggest and preserve all
> relevant registers, no matter whether they're used. That'll still be
> assembly code to maintain, but imo less of a concern than in Andrew's
> model of writing hweight() themselves in assembly (provided I
> understood him correctly), for being purely mechanical operations.

If possible I would prefer to use the same model for both gcc and
clang, or else things tend to get more complicated than strictly
needed.

I also wonder whether we could also get away without disabling of
coverage and ubsan for the hweight object file.  But I assume as long
ass we do the function call in inline asm() (and thus kind 

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

[Jan Beulich]

On 21.03.2023 15:51, Andrew Cooper wrote:
> On 20/03/2023 9:24 am, Jan Beulich wrote:
>> On 17.03.2023 12:39, Roger Pau Monné wrote:
>>> On Tue, May 26, 2020 at 06:40:16PM +0200, Jan Beulich wrote:
 On 26.05.2020 17:01, Andrew Cooper wrote:
> On 26/05/2020 14:35, Jan Beulich wrote:
>> On 26.05.2020 13:17, Andrew Cooper wrote:
>>> On 26/05/2020 07:49, Jan Beulich wrote:
 Respective Core Gen10 processor lines are affected, too.

 Signed-off-by: Jan Beulich 

 --- a/xen/arch/x86/mm.c
 +++ b/xen/arch/x86/mm.c
 @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
  case 0x000506e0: /* errata SKL167 / SKW159 */
  case 0x000806e0: /* erratum KBL??? */
  case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
 +case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
 +case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */
>>> This is marred in complexity.
>>>
>>> The enumeration of MSR_TSX_CTRL (from the TAA fix, but architectural
>>> moving forwards on any TSX-enabled CPU) includes a confirmation that HLE
>>> no longer exists/works.  This applies to IceLake systems, but possibly
>>> not their initial release configuration (hence, via a later microcode
>>> update).
>>>
>>> HLE is also disabled in microcode on all older parts for errata reasons,
>>> so in practice it doesn't exist anywhere now.
>>>
>>> I think it is safe to drop this workaround, and this does seem a more
>>> simple option than encoding which microcode turned HLE off (which sadly
>>> isn't covered by the spec updates, as even when turned off, HLE is still
>>> functioning according to its spec of "may speed things up, may do
>>> nothing"), or the interactions with the CPUID hiding capabilities of
>>> MSR_TSX_CTRL.
>> I'm afraid I don't fully follow: For one, does what you say imply HLE is
>> no longer enumerated in CPUID?
> No - sadly not.  For reasons of "not repeating the Haswell/Broadwell
> microcode fiasco", the HLE bit will continue to exist and be set. 
> (Although on CascadeLake and later, you can turn it off with 
> MSR_TSX_CTRL.)
>
> It was always a weird CPUID bit.  You were supposed to put
> XACQUIRE/XRELEASE prefixes on your legacy locking, and it would be a nop
> on old hardware and go faster on newer hardware.
>
> There is nothing runtime code needs to look at the HLE bit for, except
> perhaps for UI reporting purposes.
 Do you know of some public Intel doc I could reference for all of this,
 which I would kind of need in the description of a patch ...

>> But then this
>> erratum does not have the usual text effectively meaning that an ucode
>> update is or will be available to address the issue; instead it says
>> that BIOS or VMM can reserve the respective address range.
> This is not surprising at all.  Turning off HLE was an unrelated
> activity, and I bet the link went unnoticed.
>
>> This - assuming the alternative you describe is indeed viable - then is 
>> surely
>> a much more intrusive workaround than needed. Which I wouldn't assume
>> they would suggest in such a case.
> My suggestion was to drop the workaround, not to complicated it with a
> microcode revision matrix.
 ... doing this? I don't think I've seen any of this in writing so far,
 except by you. (I don't understand how this reply of yours relates to
 what I was saying about the spec update. I understand what you are
 suggesting. I merely tried to express that I'd have expected Intel to
 point out the much easier workaround, rather than just a pretty involved
 one.) Otherwise, may I suggest you make such a patch, to make sure it
 has an adequate description?
>>> Seeing as there seems to be some data missing to justify the commit -
>>> was has Linux done with those erratas?
>> While they deal with the SNB erratum in a similar way, I'm afraid I'm
>> unaware of Linux having or having had a workaround for the errata here.
>> Which, granted, is a little surprising when we did actually even issue
>> an XSA for this.
>>
>> In fact I find Andrew's request even more surprising with that fact (us
>> having issued XSA-282 for it) in mind, which originally I don't think I
>> had paid attention to (nor recalled).
> 
> No - I'm aware of it.  It probably was the right move at the time.
> 
> But, Intel have subsequently killed HLE in microcode updates update in
> all CPUs it ever existed in (to fix a memory ordering erratum), and
> removed it from the architecture moving forwards (the enumeration of
> TSX_CTRL means HLE architecturally doesn't exist even if it is enumerated).
> 
> These errata no longer exist when you've got up to date microcode, and
> if you've not got up to date microcode on these CPUs, you've got far
> worse security 

[xen-unstable-smoke test] 179845: tolerable trouble: pass/starved - PUSHED

[osstest service owner]

flight 179845 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179845/

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   1 build-check(1)   starved  n/a
 build-armhf   2 hosts-allocate   starved  n/a

version targeted for testing:
 xen  245d030f4aa79f766e575684127f86748c63bb32
baseline version:
 xen  f71f8e95c34fedb0d9ae21a100bfa9f012543abf

Last test of basis   179838  2023-03-21 11:01:58 Z0 days
Testing same since   179845  2023-03-21 14:02:09 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  starved 
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  starved 
 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
   f71f8e95c3..245d030f4a  245d030f4aa79f766e575684127f86748c63bb32 -> smoke

Re: [PATCH v1 1/3] xen/riscv: introduce setup_initial_pages

[Julien Grall]

On 05/03/2023 16:25, Oleksii wrote:

Hi Julien,


Hi,

Sorry for the late answer. I was away for the past couple of weeks.


On Mon, 2023-02-27 at 17:36 +, Julien Grall wrote:

Hi Oleksii,

On 27/02/2023 16:52, Oleksii wrote:

On Sat, 2023-02-25 at 17:53 +, Julien Grall wrote:

+/*
+ * WARNING: load_addr() and linker_addr() are to be called
only
when the MMU is
+ * disabled and only when executed by the primary CPU.  They
cannot refer to
+ * any global variable or functions.


I find interesting you are saying when
_setup_initial_pagetables() is
called from setup_initial_pagetables(). Would you be able to
explain
how
this is different?

I am not sure that I understand your question correctly but
_setup_initial_pagetables() was introduced to map some addresses
with
write/read flag. Probably I have to rename it to something that is
more
clear.


So the comment suggests that you code cannot refer to global
functions/variables when the MMU is off. So I have multiple
questions:
    * Why only global? IOW, why static would be OK?
    * setup_initial_pagetables() has a call to
_setup_initial_pagetables() (IOW referring to another function). Why
is
it fine?
    * You have code in the next patch referring to global variables
(mainly _start and _end). How is this different?




+ */
+
+/*
+ * Convert an addressed layed out at link time to the address
where it was loaded


Typo: s/addressed/address/ ?

Yes, it should be address. and 'layed out' should be changed to
'laid
out'...



+ * by the bootloader.
+ */


Looking at the implementation, you seem to consider that any
address
not
in the range [linker_addr_start, linker_addr_end[ will have a 1:1
mappings.

I am not sure this is what you want. So I would consider to throw
an
error if such address is passed.

I thought that at this stage and if no relocation was done it is
1:1
except the case when load_addr_start != linker_addr_start.


The problem is what you try to map one to one may clash with the
linked
region for Xen. So it is not always possible to map the region 1:1.

Therefore, I don't see any use for the else part here.

Got it. Thanks.

I am curious than what is the correct approach in general to handle
this situation?
There are multiple approach to handle it and I don't know which one 
would be best :). Relocation is one...



I mean that throw an error it is one option but if I would like to do
that w/o throwing an error. Should it done some relocation in that
case?
... solution. For Arm, I decided to avoid relocation it requires more 
work in assembly.


Let me describe what we did and you can decide what you want to do in 
RISC-V.


For Arm64, as we have plenty of virtual address space, I decided to 
reshuffle the layout so Xen is running a very high address (so it is 
unlikely to clash).


For Arm32, we have a smaller address space (4GB) so instead we are going 
through a temporary area to enable the MMU when the load and runtime 
region clash. The sequence is:


  1) Map Xen to a temporary area
  2) Enable the MMU and jump to the temporary area
  3) Map Xen to the runtime area
  4) Jump to the runtime area
  5) Remove the temporary area

[...]


Hmmm... I would actually expect the address to be properly
aligned
and
therefore not require an alignment here.

Otherwise, this raise the question of what happen if you have
region
using the same page?

That map_start &=  ZEROETH_MAP_MASK is needed to page number of
address
w/o page offset.


My point is why would the page offset be non-zero?

I checked a linker script and addresses that passed to
setup_initial_mapping() and they are really always aligned so there is
no any sense in additional alignment.


Ok. I would suggest to add some ASSERT()/BUG_ON() in order to confirm 
this is always the case.


[...]




+
+    /*
+ * Create a mapping of the load time address range to...
the
load time address range.


Same about the line length here.


+ * This mapping is used at boot time only.
+ */
+    _setup_initial_pagetables(second, first, zeroeth,


This can only work if Xen is loaded at its linked address. So you
need a
separate set of L0, L1 tables for the identity mapping.

That said, this would not be sufficient because:
     1) Xen may not be loaded at a 2M boundary (you can control
with
U-boot, but not with EFI). So this may cross a boundary and
therefore
need multiple pages.
     2) The load region may overlap the link address

While I think it would be good to handle those cases from the
start,
I
would understand why are not easy to solve. So I think the
minimum is
to
throw some errors if you are in a case you can't support.

Do you mean to throw some error in load_addr()/linkder_addr()?


In this case, I meant to check if load_addr != linker_addr, then
throw
an error.

I am not sure that it is needed now and it is easier to throw an error
but is option exist to handler situation when load_addr != linker_addr
except throwing an error? relocate?


I believe I answered this above.

Re: [XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

[Ayan Kumar Halder]

Hi Jan,

On 21/03/2023 14:22, Jan Beulich wrote:

On 21.03.2023 15:03, Ayan Kumar Halder wrote:

--- a/xen/arch/Kconfig
+++ b/xen/arch/Kconfig
@@ -1,6 +1,12 @@
  config 64BIT
bool
  
+config PHYS_ADDR_T_32

+   bool
+
+config PHYS_ADDR_T_64
+   bool

Do we really need both?

I was thinking the same. I am assuming that in future we may have

PHYS_ADDR_T_16, PHYS_ADDR_T_128. So, I am hoping that defining them explicitly 
might help.
Also, the user cannot select these configs directly.

However, I am open to defining only one of them if it makes sense.


If so, what guards against both being selected
at the same time?

At present, we rely on "select".


Them being put in common code I consider it an at least latent issue
that you add "select"s ...


--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -9,6 +9,7 @@ config ARM_64
select 64BIT
select ARM_EFI
select HAS_FAST_MULTIPLY
+   select PHYS_ADDR_T_64
  
  config ARM

def_bool y
@@ -19,13 +20,48 @@ config ARM
select HAS_PMAP
select IOMMU_FORCE_PT_SHARE
  
+menu "Architecture Features"

+
+choice
+   prompt "Physical address space size" if ARM_32
+   default ARM_PA_BITS_48 if ARM_64
+   default ARM_PA_BITS_40 if ARM_32
+   help
+ User can choose to represent the width of physical address. This can
+ sometimes help in optimizing the size of image when user chooses a
+ smaller size to represent physical address.
+
+config ARM_PA_BITS_32
+   bool "32-bit"
+   help
+ On platforms where any physical address can be represented within 32 
bits
+ , user should choose this option. This will help is reduced size of 
the
+ binary.
+   select PHYS_ADDR_T_32
+   depends on ARM_32
+
+config ARM_PA_BITS_40
+   bool "40-bit"
+   select PHYS_ADDR_T_64
+   depends on ARM_32
+
+config ARM_PA_BITS_48
+   bool "40-bit"
+   select PHYS_ADDR_T_64
+   depends on ARM_48
+endchoice

... only for Arm. You get away with this only because ...


--- a/xen/arch/arm/include/asm/types.h
+++ b/xen/arch/arm/include/asm/types.h
@@ -34,9 +34,15 @@ typedef signed long long s64;
  typedef unsigned long long u64;
  typedef u32 vaddr_t;
  #define PRIvaddr PRIx32in
+#if defined(CONFIG_PHYS_ADDR_T_32)
+typedef unsigned long paddr_t;
+#define INVALID_PADDR (~0UL)
+#define PRIpaddr "08lx"
+#else
  typedef u64 paddr_t;
  #define INVALID_PADDR (~0ULL)
  #define PRIpaddr "016llx"
+#endif
  typedef u32 register_t;
  #define PRIregister "08x"
  #elif defined (CONFIG_ARM_64)

... you tweak things here, when we're in the process of moving stuff
out of asm/types.h.


Are you suggesting not to add anything to asm/types.h ? IOW, the above 
snippet should


be added to xen/include/xen/types.h.


(Using "unsigned long" for a 32-bit paddr_t is of
course suspicious as well - this ought to be uint32_t.)


The problem with using uint32_t for paddr_t is that there are instances 
where the paddr_t is modified with PAGE_MASK or PAGE_ALIGN.


For eg , handle_passthrough_prop()

    printk(XENLOG_ERR "Unable to permit to dom%d access to"
   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
   kinfo->d->domain_id,
   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);

And in xen/include/xen/page-size.h,

#define PAGE_SIZE   (_AC(1,L) << PAGE_SHIFT)
#define PAGE_MASK   (~(PAGE_SIZE-1))

Thus, the resulting types are unsigned long. This cannot be printed 
using %u for PRIpaddr.


I remember some discussion (or comment) that the physical addresses 
should be represented using 'unsigned long'.


- Ayan




Jan

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

[Andrew Cooper]

On 21/03/2023 3:59 pm, Roger Pau Monné wrote:
> On Tue, Mar 21, 2023 at 02:51:30PM +, Andrew Cooper wrote:
>> On 20/03/2023 9:24 am, Jan Beulich wrote:
>>> On 17.03.2023 12:39, Roger Pau Monné wrote:
 On Tue, May 26, 2020 at 06:40:16PM +0200, Jan Beulich wrote:
> On 26.05.2020 17:01, Andrew Cooper wrote:
>> On 26/05/2020 14:35, Jan Beulich wrote:
>>> On 26.05.2020 13:17, Andrew Cooper wrote:
 On 26/05/2020 07:49, Jan Beulich wrote:
> Respective Core Gen10 processor lines are affected, too.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
>  case 0x000506e0: /* errata SKL167 / SKW159 */
>  case 0x000806e0: /* erratum KBL??? */
>  case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
> +case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
> +case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */
 This is marred in complexity.

 The enumeration of MSR_TSX_CTRL (from the TAA fix, but architectural
 moving forwards on any TSX-enabled CPU) includes a confirmation that 
 HLE
 no longer exists/works.  This applies to IceLake systems, but possibly
 not their initial release configuration (hence, via a later microcode
 update).

 HLE is also disabled in microcode on all older parts for errata 
 reasons,
 so in practice it doesn't exist anywhere now.

 I think it is safe to drop this workaround, and this does seem a more
 simple option than encoding which microcode turned HLE off (which sadly
 isn't covered by the spec updates, as even when turned off, HLE is 
 still
 functioning according to its spec of "may speed things up, may do
 nothing"), or the interactions with the CPUID hiding capabilities of
 MSR_TSX_CTRL.
>>> I'm afraid I don't fully follow: For one, does what you say imply HLE is
>>> no longer enumerated in CPUID?
>> No - sadly not.  For reasons of "not repeating the Haswell/Broadwell
>> microcode fiasco", the HLE bit will continue to exist and be set. 
>> (Although on CascadeLake and later, you can turn it off with 
>> MSR_TSX_CTRL.)
>>
>> It was always a weird CPUID bit.  You were supposed to put
>> XACQUIRE/XRELEASE prefixes on your legacy locking, and it would be a nop
>> on old hardware and go faster on newer hardware.
>>
>> There is nothing runtime code needs to look at the HLE bit for, except
>> perhaps for UI reporting purposes.
> Do you know of some public Intel doc I could reference for all of this,
> which I would kind of need in the description of a patch ...
>
>>> But then this
>>> erratum does not have the usual text effectively meaning that an ucode
>>> update is or will be available to address the issue; instead it says
>>> that BIOS or VMM can reserve the respective address range.
>> This is not surprising at all.  Turning off HLE was an unrelated
>> activity, and I bet the link went unnoticed.
>>
>>> This - assuming the alternative you describe is indeed viable - then is 
>>> surely
>>> a much more intrusive workaround than needed. Which I wouldn't assume
>>> they would suggest in such a case.
>> My suggestion was to drop the workaround, not to complicated it with a
>> microcode revision matrix.
> ... doing this? I don't think I've seen any of this in writing so far,
> except by you. (I don't understand how this reply of yours relates to
> what I was saying about the spec update. I understand what you are
> suggesting. I merely tried to express that I'd have expected Intel to
> point out the much easier workaround, rather than just a pretty involved
> one.) Otherwise, may I suggest you make such a patch, to make sure it
> has an adequate description?
 Seeing as there seems to be some data missing to justify the commit -
 was has Linux done with those erratas?
>>> While they deal with the SNB erratum in a similar way, I'm afraid I'm
>>> unaware of Linux having or having had a workaround for the errata here.
>>> Which, granted, is a little surprising when we did actually even issue
>>> an XSA for this.
>>>
>>> In fact I find Andrew's request even more surprising with that fact (us
>>> having issued XSA-282 for it) in mind, which originally I don't think I
>>> had paid attention to (nor recalled).
>> No - I'm aware of it.  It probably was the right move at the time.
>>
>> But, Intel have subsequently killed HLE in microcode updates update in
>> all CPUs it ever existed in (to fix a memory ordering erratum), and
>> removed it from the architecture moving forwards (the enumeration of
>> TSX_CTRL means HLE architecturally doesn't exist even if it 

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

[Jan Beulich]

On 21.03.2023 16:58, Roger Pau Monné wrote:
> On Tue, Mar 21, 2023 at 04:51:43PM +0100, Jan Beulich wrote:
>> On 21.03.2023 15:42, Roger Pau Monné wrote:
>>> On Tue, May 26, 2020 at 08:49:52AM +0200, Jan Beulich wrote:
 Respective Core Gen10 processor lines are affected, too.

 Signed-off-by: Jan Beulich 

 --- a/xen/arch/x86/mm.c
 +++ b/xen/arch/x86/mm.c
 @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
  case 0x000506e0: /* errata SKL167 / SKW159 */
  case 0x000806e0: /* erratum KBL??? */
  case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
 +case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
 +case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */
>>>
>>> I think this is errata CML101, I would add that at the end of the
>>> comment.
>>
>> Indeed in the current version of the document CML prefix exist. The older
>> document I've been looking at has no such letter acronyms in front of the
>> errata numbers. I can certainly update.
>>
>>> Also you seem to be missing the '806ec' model (806e0 case)? (listed as
>>> 'U 4+2 V1')
>>
>> Isn't that pre-existing (see 2nd line of context above)?
> 
> Oh, indeed.  Would you mind also adding a reference to CML101 for
> 0x000806e0 then?

Already done. Provided there'll be a v2 in the first place, considering
Andrew's comments (which I still need to properly consume).

Jan

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

[Roger Pau Monné]

On Tue, Mar 21, 2023 at 02:51:30PM +, Andrew Cooper wrote:
> On 20/03/2023 9:24 am, Jan Beulich wrote:
> > On 17.03.2023 12:39, Roger Pau Monné wrote:
> >> On Tue, May 26, 2020 at 06:40:16PM +0200, Jan Beulich wrote:
> >>> On 26.05.2020 17:01, Andrew Cooper wrote:
>  On 26/05/2020 14:35, Jan Beulich wrote:
> > On 26.05.2020 13:17, Andrew Cooper wrote:
> >> On 26/05/2020 07:49, Jan Beulich wrote:
> >>> Respective Core Gen10 processor lines are affected, too.
> >>>
> >>> Signed-off-by: Jan Beulich 
> >>>
> >>> --- a/xen/arch/x86/mm.c
> >>> +++ b/xen/arch/x86/mm.c
> >>> @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
> >>>  case 0x000506e0: /* errata SKL167 / SKW159 */
> >>>  case 0x000806e0: /* erratum KBL??? */
> >>>  case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
> >>> +case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
> >>> +case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */
> >> This is marred in complexity.
> >>
> >> The enumeration of MSR_TSX_CTRL (from the TAA fix, but architectural
> >> moving forwards on any TSX-enabled CPU) includes a confirmation that 
> >> HLE
> >> no longer exists/works.  This applies to IceLake systems, but possibly
> >> not their initial release configuration (hence, via a later microcode
> >> update).
> >>
> >> HLE is also disabled in microcode on all older parts for errata 
> >> reasons,
> >> so in practice it doesn't exist anywhere now.
> >>
> >> I think it is safe to drop this workaround, and this does seem a more
> >> simple option than encoding which microcode turned HLE off (which sadly
> >> isn't covered by the spec updates, as even when turned off, HLE is 
> >> still
> >> functioning according to its spec of "may speed things up, may do
> >> nothing"), or the interactions with the CPUID hiding capabilities of
> >> MSR_TSX_CTRL.
> > I'm afraid I don't fully follow: For one, does what you say imply HLE is
> > no longer enumerated in CPUID?
>  No - sadly not.  For reasons of "not repeating the Haswell/Broadwell
>  microcode fiasco", the HLE bit will continue to exist and be set. 
>  (Although on CascadeLake and later, you can turn it off with 
>  MSR_TSX_CTRL.)
> 
>  It was always a weird CPUID bit.  You were supposed to put
>  XACQUIRE/XRELEASE prefixes on your legacy locking, and it would be a nop
>  on old hardware and go faster on newer hardware.
> 
>  There is nothing runtime code needs to look at the HLE bit for, except
>  perhaps for UI reporting purposes.
> >>> Do you know of some public Intel doc I could reference for all of this,
> >>> which I would kind of need in the description of a patch ...
> >>>
> > But then this
> > erratum does not have the usual text effectively meaning that an ucode
> > update is or will be available to address the issue; instead it says
> > that BIOS or VMM can reserve the respective address range.
>  This is not surprising at all.  Turning off HLE was an unrelated
>  activity, and I bet the link went unnoticed.
> 
> > This - assuming the alternative you describe is indeed viable - then is 
> > surely
> > a much more intrusive workaround than needed. Which I wouldn't assume
> > they would suggest in such a case.
>  My suggestion was to drop the workaround, not to complicated it with a
>  microcode revision matrix.
> >>> ... doing this? I don't think I've seen any of this in writing so far,
> >>> except by you. (I don't understand how this reply of yours relates to
> >>> what I was saying about the spec update. I understand what you are
> >>> suggesting. I merely tried to express that I'd have expected Intel to
> >>> point out the much easier workaround, rather than just a pretty involved
> >>> one.) Otherwise, may I suggest you make such a patch, to make sure it
> >>> has an adequate description?
> >> Seeing as there seems to be some data missing to justify the commit -
> >> was has Linux done with those erratas?
> > While they deal with the SNB erratum in a similar way, I'm afraid I'm
> > unaware of Linux having or having had a workaround for the errata here.
> > Which, granted, is a little surprising when we did actually even issue
> > an XSA for this.
> >
> > In fact I find Andrew's request even more surprising with that fact (us
> > having issued XSA-282 for it) in mind, which originally I don't think I
> > had paid attention to (nor recalled).
> 
> No - I'm aware of it.  It probably was the right move at the time.
> 
> But, Intel have subsequently killed HLE in microcode updates update in
> all CPUs it ever existed in (to fix a memory ordering erratum), and
> removed it from the architecture moving forwards (the enumeration of
> TSX_CTRL means HLE architecturally doesn't exist even if it is enumerated).

Should we then check for TSX_CTRL 

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

[Roger Pau Monné]

On Tue, Mar 21, 2023 at 04:51:43PM +0100, Jan Beulich wrote:
> On 21.03.2023 15:42, Roger Pau Monné wrote:
> > On Tue, May 26, 2020 at 08:49:52AM +0200, Jan Beulich wrote:
> >> Respective Core Gen10 processor lines are affected, too.
> >>
> >> Signed-off-by: Jan Beulich 
> >>
> >> --- a/xen/arch/x86/mm.c
> >> +++ b/xen/arch/x86/mm.c
> >> @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
> >>  case 0x000506e0: /* errata SKL167 / SKW159 */
> >>  case 0x000806e0: /* erratum KBL??? */
> >>  case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
> >> +case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
> >> +case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */
> > 
> > I think this is errata CML101, I would add that at the end of the
> > comment.
> 
> Indeed in the current version of the document CML prefix exist. The older
> document I've been looking at has no such letter acronyms in front of the
> errata numbers. I can certainly update.
> 
> > Also you seem to be missing the '806ec' model (806e0 case)? (listed as
> > 'U 4+2 V1')
> 
> Isn't that pre-existing (see 2nd line of context above)?

Oh, indeed.  Would you mind also adding a reference to CML101 for
0x000806e0 then?

Thanks, Roger.

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

[Jan Beulich]

On 21.03.2023 15:42, Roger Pau Monné wrote:
> On Tue, May 26, 2020 at 08:49:52AM +0200, Jan Beulich wrote:
>> Respective Core Gen10 processor lines are affected, too.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
>>  case 0x000506e0: /* errata SKL167 / SKW159 */
>>  case 0x000806e0: /* erratum KBL??? */
>>  case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
>> +case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
>> +case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */
> 
> I think this is errata CML101, I would add that at the end of the
> comment.

Indeed in the current version of the document CML prefix exist. The older
document I've been looking at has no such letter acronyms in front of the
errata numbers. I can certainly update.

> Also you seem to be missing the '806ec' model (806e0 case)? (listed as
> 'U 4+2 V1')

Isn't that pre-existing (see 2nd line of context above)?

Jan

Re: [PATCH v2 4/4] xen/arm: Clean-up in p2m_init() and p2m_final_teardown()

[Julien Grall]

Hi Henry,

On 30/01/2023 04:06, Henry Wang wrote:

With the change in previous patch, the initial 16 pages in the P2M
pool is not necessary anymore. Drop them for code simplification.

Also the call to p2m_teardown() from arch_domain_destroy() is not
necessary anymore since the movement of the P2M allocation out of
arch_domain_create(). Drop the code and the above in-code comment
mentioning it.

Signed-off-by: Henry Wang 
Reviewed-by: Michal Orzel 
---
I am not entirely sure if I should also drop the "TODO" on top of
the p2m_set_entry(). Because although we are sure there is no
p2m pages populated in domain_create() stage now, but we are not
sure if anyone will add more in the future...Any comments?


I would keep it.


v1 -> v2:
1. Add Reviewed-by tag from Michal.
---
  xen/arch/arm/include/asm/p2m.h |  4 
  xen/arch/arm/p2m.c | 20 +---
  2 files changed, 1 insertion(+), 23 deletions(-)

diff --git a/xen/arch/arm/include/asm/p2m.h b/xen/arch/arm/include/asm/p2m.h
index bf5183e53a..cf06d3cc21 100644
--- a/xen/arch/arm/include/asm/p2m.h
+++ b/xen/arch/arm/include/asm/p2m.h
@@ -200,10 +200,6 @@ int p2m_init(struct domain *d);
   *  - p2m_final_teardown() will be called when domain struct is been
   *freed. This *cannot* be preempted and therefore one small


NIT: As you are touching the comment, would you mind to fix the typo 
s/one/only/.



   *resources should be freed here.
- *  Note that p2m_final_teardown() will also call p2m_teardown(), to properly
- *  free the P2M when failures happen in the domain creation with P2M pages
- *  already in use. In this case p2m_teardown() is called non-preemptively and
- *  p2m_teardown() will always return 0.
   */
  int p2m_teardown(struct domain *d, bool allow_preemption);
  void p2m_final_teardown(struct domain *d);
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f1ccd7efbd..46406a9eb1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1750,13 +1750,9 @@ void p2m_final_teardown(struct domain *d)
  /*
   * No need to call relinquish_p2m_mapping() here because
   * p2m_final_teardown() is called either after 
domain_relinquish_resources()
- * where relinquish_p2m_mapping() has been called, or from failure path of
- * domain_create()/arch_domain_create() where mappings that require
- * p2m_put_l3_page() should never be created. For the latter case, also see
- * comment on top of the p2m_set_entry() for more info.
+ * where relinquish_p2m_mapping() has been called.
   */
  
-BUG_ON(p2m_teardown(d, false));


With this change, I think we can also drop the second parameter of 
p2m_teardown(). Preferably with this change in the patch:


Acked-by: Julien Grall 

Preferably, I would like this to happen in this patch.

Cheers,

--
Julien Grall

Re: [PATCH v2] x86: use POPCNT for hweight() when available

[Juergen Gross]

On 21.03.23 16:35, Jan Beulich wrote:

On 21.03.2023 15:57, Roger Pau Monné wrote:

On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote:

On 17.03.2023 13:26, Andrew Cooper wrote:

On 17/03/2023 11:22 am, Roger Pau Monné wrote:

On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:

This is faster than using the software implementation, and the insn is
available on all half-way recent hardware. Therefore convert
generic_hweight() to out-of-line functions (without affecting Arm)
and use alternatives patching to replace the function calls.

Note that the approach doesn#t work for clang, due to it not recognizing
-ffixed-*.

I've been giving this a look, and I wonder if it would be fine to
simply push and pop the scratch registers in the 'call' path of the
alternative, as that won't require any specific compiler option.


Hmm, ...


It's been a long while, and in that time I've learnt a lot more about
performance, but my root objection to the approach taken here still
stands - it is penalising the common case to optimise some pointless
corner cases.

Yes - on the call path, an extra push/pop pair (or few) to get temp
registers is basically free.


... what is "a few"? We'd need to push/pop all call-clobbered registers
except %rax, i.e. a total of eight. I consider this too much. Unless,
as you suggest further down, we wrote the fallback in assembly. Which I
have to admit I'm surprised you propose when we strive to reduce the
amount of assembly we have to maintain.


AMD added popcnt in 2007 and Intel in 2008.  While we shouldn't
mandate popcnt support, I think we also shouldn't overly worry about
the non-popcnt path.


We agree here.


Also, how can you assert that the code generated without the scratch
registers being usable won't be worse than the penalty of pushing and
popping such registers on the stack and letting the routines use all
registers freely?


Irrespective of the -ffixed-* the compiler can make itself sufficiently
many registers available to use, by preserving just the ones it actually
uses. So that's pretty certainly not more PUSH/POP than when we would
blindly preserve all which may need preserving (no matter whether
they're actually used).

Yet then both this question and ...


I very much prefer to have a non-optimal non-popcnt path, but have
popcnt support for both gcc and clang, and without requiring any
compiler options.


... this makes me wonder whether we're thinking of fundamentally
different generated code that we would end up with. Since the
(apparently agreed upon) goal is to optimize for the "popcnt
available" case, mainline code should be not significantly longer that
what's needed for the single instruction itself, or alternatively a
CALL insn. Adding pushes/pops of all call clobbered registers around
the CALL would grow mainline code too much (for my taste), i.e.
irrespective of these PUSH/POP all getting NOP-ed out by alternatives
patching. (As an aside I consider fiddling with the stack pointer in
inline asm() risky, and hence I would prefer to avoid such whenever
possible. Yes, it can be written so it's independent of what the
compiler thinks the stack pointer points at, but such constructs are
fragile as soon as one wants to change them a little later on.)

Are you perhaps thinking of indeed having the PUSH/POP in mainline
code? Or some entirely different model?

What I could see us doing to accommodate Clang is to have wrappers
around the actual functions which do as you suggest and preserve all
relevant registers, no matter whether they're used.


You could just copy the PV_CALLEE_SAVE_REGS_THUNK() macro from the Linux
kernel, which is doing exactly that.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2] vpci/msix: handle accesses adjacent to the MSI-X table

[Jan Beulich]

On 21.03.2023 16:31, Roger Pau Monné wrote:
> On Mon, Mar 20, 2023 at 01:08:48PM +0100, Jan Beulich wrote:
>> On 16.03.2023 13:07, Roger Pau Monne wrote:
>>>  {
>>> -struct vpci *vpci = msix->pdev->vpci;
>>> -unsigned int idx = addr - vmsix_table_addr(vpci, VPCI_MSIX_PBA);
>>> -const void __iomem *pba = get_pba(vpci);
>>> +unsigned int i;
>>> +
>>> +gprintk(XENLOG_DEBUG, "%pp: unaligned read to MSI-X related 
>>> page\n",
>>> +>pdev->sbdf);
>>>  
>>>  /*
>>> - * Access to PBA.
>>> + * Split unaligned accesses into byte sized ones. Shouldn't happen 
>>> in
>>> + * the first place, but devices shouldn't have registers in the 
>>> same 4K
>>> + * page as the MSIX tables either.
>>>   *
>>> - * TODO: note that this relies on having the PBA identity mapped 
>>> to the
>>> - * guest address space. If this changes the address will need to be
>>> - * translated.
>>> + * It's unclear whether this could cause issues if a guest expects 
>>> a
>>> + * registers to be accessed atomically, it better use an aligned 
>>> access
>>> + * if it has such expectations.
>>>   */
>>> -if ( !pba )
>>> -{
>>> -gprintk(XENLOG_WARNING,
>>> -"%pp: unable to map MSI-X PBA, report all pending\n",
>>> ->pdev->sbdf);
>>> -return X86EMUL_OKAY;
>>> -}
>>>  
>>> -switch ( len )
>>> +for ( i = 0; i < len; i++ )
>>>  {
>>> -case 4:
>>> -*data = readl(pba + idx);
>>> -break;
>>> +unsigned long partial = ~0ul;
>>
>> Pointless initializer (~0ul is written first thing above, i.e. also in
>> the recursive invocation). Then again that setting is also redundant
>> with msix_read()'s. So I guess the initializer wants to stay but the
>> setting at the top of the function can be dropped.
> 
> I'm always extra cautious with variables on the stack that contain
> data to be returned to the guest.  All your points are valid and
> correct, but I like to explicitly initialize them so that further
> changes in the functions don't end up leaking them.  If you don't mind
> that much I would rather leave it as-is.

Well, such extra code always raises the question "Why is this here?"
But no, I won't insist if you prefer to keep the redundancy.

Jan

Re: [PATCH] tools: use libxenlight for writing xenstore-stubdom console nodes

[Juergen Gross]

On 21.03.23 16:02, Anthony PERARD wrote:

On Wed, Mar 15, 2023 at 04:42:26PM +0100, Juergen Gross wrote:

@@ -1982,6 +1987,13 @@ int libxl_console_get_tty(libxl_ctx *ctx, uint32_t 
domid, int cons_num,
   */
  int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char 
**path);
  
+/* libxl_console_add_xenstore writes the Xenstore entries for a domain's

+ * primary console based on domid, event channel port and the guest frame
+ * number of the PV console's ring page.
+ */
+int libxl_console_add_xenstore(libxl_ctx *ctx, uint32_t domid, uint32_t 
backend,
+   int evtch, uint64_t gfn);


Could you make this function async, by adding "const libxl_asyncop_how
*ao_how" parameter in last position?

You can follow libxl_domain_pause() example has to write an async
function that is actually synchronous (AO_CREATE, libxl__ao_complete,
AO_INPROGRESS, AO_CREATE_FAIL).

Adding the async capability now means that we won't need to change the
API if the function actually need to be async one day.


Okay.




+
  /* May be called with info_r == NULL to check for domain's existence.
   * Returns ERROR_DOMAIN_NOTFOUND if domain does not exist (used to return
   * ERROR_INVAL for this scenario). */
diff --git a/tools/libs/light/libxl_console.c b/tools/libs/light/libxl_console.c
index d8b2bc5465..ce3de100cc 100644
--- a/tools/libs/light/libxl_console.c
+++ b/tools/libs/light/libxl_console.c
@@ -346,6 +346,26 @@ out:
  return rc;
  }
  
+int libxl_console_add_xenstore(libxl_ctx *ctx, uint32_t domid, uint32_t backend,

+   int evtch, uint64_t gfn)
+{
+GC_INIT(ctx);
+int rc;
+libxl__device_console console = { .backend_domid = backend,
+  .output = "pty",
+  .consback = 
LIBXL__CONSOLE_BACKEND_XENCONSOLED,
+};
+libxl__domain_build_state state = { .console_port = evtch,


`console_port` is "uint32_t", shouldn't `evtchn` be the same type, or at
least also be unsigned?


I can switch the type to unsigned int.




+.console_mfn = gfn,


I wonder if we should check if `gfn` fit in `console_mfn`, as it could
be smaller when building the toolstack on 32bit platform.


I'll make console_mfn "unsigned long" just like in the build state.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2] x86: use POPCNT for hweight() when available

[Jan Beulich]

On 21.03.2023 15:57, Roger Pau Monné wrote:
> On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote:
>> On 17.03.2023 13:26, Andrew Cooper wrote:
>>> On 17/03/2023 11:22 am, Roger Pau Monné wrote:
 On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
> This is faster than using the software implementation, and the insn is
> available on all half-way recent hardware. Therefore convert
> generic_hweight() to out-of-line functions (without affecting Arm)
> and use alternatives patching to replace the function calls.
>
> Note that the approach doesn#t work for clang, due to it not recognizing
> -ffixed-*.
 I've been giving this a look, and I wonder if it would be fine to
 simply push and pop the scratch registers in the 'call' path of the
 alternative, as that won't require any specific compiler option.
>>
>> Hmm, ...
>>
>>> It's been a long while, and in that time I've learnt a lot more about
>>> performance, but my root objection to the approach taken here still
>>> stands - it is penalising the common case to optimise some pointless
>>> corner cases.
>>>
>>> Yes - on the call path, an extra push/pop pair (or few) to get temp
>>> registers is basically free.
>>
>> ... what is "a few"? We'd need to push/pop all call-clobbered registers
>> except %rax, i.e. a total of eight. I consider this too much. Unless,
>> as you suggest further down, we wrote the fallback in assembly. Which I
>> have to admit I'm surprised you propose when we strive to reduce the
>> amount of assembly we have to maintain.
> 
> AMD added popcnt in 2007 and Intel in 2008.  While we shouldn't
> mandate popcnt support, I think we also shouldn't overly worry about
> the non-popcnt path.

We agree here.

> Also, how can you assert that the code generated without the scratch
> registers being usable won't be worse than the penalty of pushing and
> popping such registers on the stack and letting the routines use all
> registers freely?

Irrespective of the -ffixed-* the compiler can make itself sufficiently
many registers available to use, by preserving just the ones it actually
uses. So that's pretty certainly not more PUSH/POP than when we would
blindly preserve all which may need preserving (no matter whether
they're actually used).

Yet then both this question and ...

> I very much prefer to have a non-optimal non-popcnt path, but have
> popcnt support for both gcc and clang, and without requiring any
> compiler options.

... this makes me wonder whether we're thinking of fundamentally
different generated code that we would end up with. Since the
(apparently agreed upon) goal is to optimize for the "popcnt
available" case, mainline code should be not significantly longer that
what's needed for the single instruction itself, or alternatively a
CALL insn. Adding pushes/pops of all call clobbered registers around
the CALL would grow mainline code too much (for my taste), i.e.
irrespective of these PUSH/POP all getting NOP-ed out by alternatives
patching. (As an aside I consider fiddling with the stack pointer in
inline asm() risky, and hence I would prefer to avoid such whenever
possible. Yes, it can be written so it's independent of what the
compiler thinks the stack pointer points at, but such constructs are
fragile as soon as one wants to change them a little later on.)

Are you perhaps thinking of indeed having the PUSH/POP in mainline
code? Or some entirely different model?

What I could see us doing to accommodate Clang is to have wrappers
around the actual functions which do as you suggest and preserve all
relevant registers, no matter whether they're used. That'll still be
assembly code to maintain, but imo less of a concern than in Andrew's
model of writing hweight() themselves in assembly (provided I
understood him correctly), for being purely mechanical operations.

Jan

Re: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until the first access

[Julien Grall]

On 21/03/2023 03:57, Henry Wang wrote:

Hi Julien,


Hi Henry,


-Original Message-
From: Julien Grall 
Subject: Re: [PATCH v2 3/4] xen/arm: Defer GICv2 CPU interface mapping until
the first access

Hi Henry,

On 30/01/2023 04:06, Henry Wang wrote:

Since the hardware domain (Dom0) has an unlimited size P2M pool, the
gicv2_map_hwdom_extra_mappings() is also not touched by this patch.


I didn't notice this in the previous version. The fact that dom0 has
unlimited size P2M pool doesn't matter here (this could also change in
the future). Even if the P2M pool was limited, then it would be fine
because the extra mappings happen after domain_create(). So there is no
need to map them on-demand as the code could be order the way we want.

So this paragraph needs to be reworded.


Sure, I've reworded this paragraph to below:
"Since gicv2_map_hwdom_extra_mappings() happens after domain_create(),
so there is no need to map the extra mappings on-demand, and therefore
keep the hwdom extra mappings as untouched."


Looks good to me.






+/*
+ * Map the GICv2 virtual CPU interface in the GIC CPU interface
+ * region of the guest on the first access of the MMIO region.
+ */
+if ( d->arch.vgic.version == GIC_V2 &&
+ gfn_eq(gfn, gaddr_to_gfn(d->arch.vgic.cbase)) )


The CPU interface size is 8KB (bigger in some cases) but here you only
check for the access to be in the first 4KB.


Yeah indeed, gfn might fall into the range between 4KB and 8KB, sorry
about that.

Considering that the CPU interface is continuous (I suppose), I have two
ways of rewriting the gfn check, we can do either:

gfn_eq(gfn, gaddr_to_gfn(d->arch.vgic.cbase)) ||
gfn_eq(gfn, gfn_add(gaddr_to_gfn(d->arch.vgic.cbase), 1))


This check is incorrect as you are making the assumption that the size 
is 8KB. As I hinted in the previous e-mail, the size could be bigger. 
For instance, for dom0, it could be up to 128KB when the GICC is aliased.


So you want to...



or

gfn_to_gaddr(gfn) >= d->arch.vgic.cbase ||
gfn_to_gaddr(gfn) < d->arch.vgic.cbase + d->arch.vgic.csize


... use the size in the check. With the || switch to &&, my preference 
would be to use:


((d->arch.vgic.cbase - gfn_to_addr(gfn)) < d->arch.vgic.csize)

to avoid a potential overflow in the unlikely case the CPU interface is 
at the top of the address space.


Cheers,

--
Julien Grall

Re: [PATCH v2] vpci/msix: handle accesses adjacent to the MSI-X table

[Roger Pau Monné]

On Mon, Mar 20, 2023 at 01:08:48PM +0100, Jan Beulich wrote:
> On 16.03.2023 13:07, Roger Pau Monne wrote:
> > --- a/xen/drivers/vpci/msix.c
> > +++ b/xen/drivers/vpci/msix.c
> > @@ -27,6 +27,11 @@
> >  ((addr) >= vmsix_table_addr(vpci, nr) &&  \
> >   (addr) < vmsix_table_addr(vpci, nr) + vmsix_table_size(vpci, nr))
> >  
> > +#define VMSIX_ADDR_SAME_PAGE(addr, vpci, nr)  \
> > +(PFN_DOWN(addr) >= PFN_DOWN(vmsix_table_addr(vpci, nr)) &&\
> > + PFN_DOWN((addr)) < PFN_UP(vmsix_table_addr(vpci, nr) +   \
> > +   vmsix_table_size(vpci, nr) - 1))
> 
> Looks like this would be better in line with get_slot() (and slightly
> cheaper) if the 2nd comparison was ... <= PFN_DOWN().

Can adjust, I don't have a strong opinion.

> 
> > @@ -149,7 +154,7 @@ static struct vpci_msix *msix_find(const struct domain 
> > *d, unsigned long addr)
> >  
> >  for ( i = 0; i < ARRAY_SIZE(msix->tables); i++ )
> >  if ( bars[msix->tables[i] & PCI_MSIX_BIRMASK].enabled &&
> > - VMSIX_ADDR_IN_RANGE(addr, msix->pdev->vpci, i) )
> > + VMSIX_ADDR_SAME_PAGE(addr, msix->pdev->vpci, i) )
> >  return msix;
> >  }
> >  
> > @@ -182,93 +187,201 @@ static struct vpci_msix_entry *get_entry(struct 
> > vpci_msix *msix,
> >  return >entries[(addr - start) / PCI_MSIX_ENTRY_SIZE];
> >  }
> >  
> > -static void __iomem *get_pba(struct vpci *vpci)
> > +static void __iomem *get_table(struct vpci *vpci, unsigned int slot)
> >  {
> >  struct vpci_msix *msix = vpci->msix;
> >  /*
> > - * PBA will only be unmapped when the device is deassigned, so access 
> > it
> > - * without holding the vpci lock.
> > + * Regions will only be unmapped when the device is deassigned, so 
> > access
> > + * them without holding the vpci lock.
> >   */
> > -void __iomem *pba = read_atomic(>pba);
> > +void __iomem *table = read_atomic(>table[slot]);
> > +paddr_t addr = 0;
> >  
> > -if ( likely(pba) )
> > -return pba;
> > +if ( likely(table) )
> > +return table;
> >  
> > -pba = ioremap(vmsix_table_addr(vpci, VPCI_MSIX_PBA),
> > -  vmsix_table_size(vpci, VPCI_MSIX_PBA));
> > -if ( !pba )
> > -return read_atomic(>pba);
> > +switch ( slot )
> > +{
> > +case VPCI_MSIX_TBL_TAIL:
> > +addr = vmsix_table_size(vpci, VPCI_MSIX_TABLE);
> > +fallthrough;
> > +case VPCI_MSIX_TBL_HEAD:
> > +addr += vmsix_table_addr(vpci, VPCI_MSIX_TABLE);
> > +break;
> > +
> > +case VPCI_MSIX_PBA_TAIL:
> > +addr = vmsix_table_size(vpci, VPCI_MSIX_PBA);
> > +fallthrough;
> > +case VPCI_MSIX_PBA_HEAD:
> > +addr += vmsix_table_addr(vpci, VPCI_MSIX_PBA);
> > +break;
> 
> Hmm, wasn't the plan to stop special-casing the PBA, including its
> special treatment wrt the p2m?

I had a pre-patch to do that, but TBH I'm not sure it's worth handling
dom0 vs domU different here, the more that PBA accesses aren't that
common anyway.

> Reading on I realize you need this for
> the (future) DomU case (to enforce r/o-ness, albeit having looked at
> the spec again the other day I'm not really convinced anymore we
> really need to squash writes), but we should be able to avoid the
> extra overhead for Dom0? (Granted it may make sense to leave this to
> a separate patch, if we want to keep the DomU handling despite not
> presently needing it.)

I can indeed avoid the trapping for dom0, it's just a 2 line change to
vpci_make_msix_hole() IIRC.  Since I've already done the code, let's
try to get the handling done for both dom0 and domU, and I can submit
the improvement for dom0 as a separate patch.

> > +}
> > +
> > +table = ioremap(round_pgdown(addr), PAGE_SIZE);
> > +if ( !table )
> > +return read_atomic(>table[slot]);
> >  
> >  spin_lock(>lock);
> > -if ( !msix->pba )
> > +if ( !msix->table[slot] )
> >  {
> > -write_atomic(>pba, pba);
> > +write_atomic(>table[slot], table);
> >  spin_unlock(>lock);
> >  }
> >  else
> >  {
> >  spin_unlock(>lock);
> > -iounmap(pba);
> > +iounmap(table);
> >  }
> >  
> > -return read_atomic(>pba);
> > +return read_atomic(>table[slot]);
> >  }
> >  
> > -static int cf_check msix_read(
> > -struct vcpu *v, unsigned long addr, unsigned int len, unsigned long 
> > *data)
> > +unsigned int get_slot(const struct vpci *vpci, unsigned long addr)
> >  {
> > -const struct domain *d = v->domain;
> > -struct vpci_msix *msix = msix_find(d, addr);
> > -const struct vpci_msix_entry *entry;
> > -unsigned int offset;
> > +unsigned long pfn = PFN_DOWN(addr);
> >  
> > -*data = ~0ul;
> > +/*
> > + * The logic below relies on having the tables identity mapped to the 
> > guest
> > + * 

Re: [XEN PATCH v1 1/1] x86/domctl: add gva_to_gfn command

[Ковалёв Сергей]

Thanks to all for suggestions and notes.

Though as Andrew Cooper noticed current approach is too over simplified.
As Tams K Lengyel noticed the effect could be too negligible and some
OS specific logic should be present.

So as for today we could drop the patch.

20.03.2023 19:32, Ковалёв Сергей пишет:

gva_to_gfn command used for fast address translation in LibVMI project.
With such a command it is possible to perform address translation in
single call instead of series of queries to get every page table.

Thanks to Dmitry Isaykin for involvement.

Signed-off-by: Sergey Kovalev 

---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: "Roger Pau Monné" 
Cc: Wei Liu 
Cc: George Dunlap 
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Tamas K Lengyel 
Cc: xen-devel@lists.xenproject.org
---

---
  xen/arch/x86/domctl.c   | 17 +
  xen/include/public/domctl.h | 13 +
  2 files changed, 30 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 2118fcad5d..0c9706ea0a 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1364,6 +1364,23 @@ long arch_do_domctl(
  copyback = true;
  break;

+    case XEN_DOMCTL_gva_to_gfn:
+    {
+    uint64_t ga = domctl->u.gva_to_gfn.addr;
+    uint64_t cr3 = domctl->u.gva_to_gfn.cr3;
+    struct vcpu* v = d->vcpu[0];
+    uint32_t pfec = PFEC_page_present;
+    unsigned int page_order;
+
+    uint64_t gfn = paging_ga_to_gfn_cr3(v, cr3, ga, , 
_order);

+    domctl->u.gva_to_gfn.addr = gfn;
+    domctl->u.gva_to_gfn.page_order = page_order;
+    if ( __copy_to_guest(u_domctl, domctl, 1) )
+    ret = -EFAULT;
+
+    break;
+    }
+
  default:
  ret = -ENOSYS;
  break;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 51be28c3de..628dfc68fd 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -948,6 +948,17 @@ struct xen_domctl_paging_mempool {
  uint64_aligned_t size; /* Size in bytes. */
  };

+/*
+ * XEN_DOMCTL_gva_to_gfn.
+ *
+ * Get the guest virtual to guest physicall address translated.
+ */
+struct xen_domctl_gva_to_gfn {
+    uint64_aligned_t addr;
+    uint64_aligned_t cr3;
+    uint64_aligned_t page_order;
+};
+
  #if defined(__i386__) || defined(__x86_64__)
  struct xen_domctl_vcpu_msr {
  uint32_t index;
@@ -1278,6 +1289,7 @@ struct xen_domctl {
  #define XEN_DOMCTL_vmtrace_op    84
  #define XEN_DOMCTL_get_paging_mempool_size   85
  #define XEN_DOMCTL_set_paging_mempool_size   86
+#define XEN_DOMCTL_gva_to_gfn    87
  #define XEN_DOMCTL_gdbsx_guestmemio    1000
  #define XEN_DOMCTL_gdbsx_pausevcpu 1001
  #define XEN_DOMCTL_gdbsx_unpausevcpu   1002
@@ -1340,6 +1352,7 @@ struct xen_domctl {
  struct xen_domctl_vuart_op  vuart_op;
  struct xen_domctl_vmtrace_op    vmtrace_op;
  struct xen_domctl_paging_mempool    paging_mempool;
+    struct xen_domctl_gva_to_gfn    gva_to_gfn;
  uint8_t pad[128];
  } u;
  };


--
Best regards,
Sergey Kovalev

Re: [PATCH] tools: use libxenlight for writing xenstore-stubdom console nodes

[Anthony PERARD]

On Wed, Mar 15, 2023 at 04:42:26PM +0100, Juergen Gross wrote:
> @@ -1982,6 +1987,13 @@ int libxl_console_get_tty(libxl_ctx *ctx, uint32_t 
> domid, int cons_num,
>   */
>  int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm, char 
> **path);
>  
> +/* libxl_console_add_xenstore writes the Xenstore entries for a domain's
> + * primary console based on domid, event channel port and the guest frame
> + * number of the PV console's ring page.
> + */
> +int libxl_console_add_xenstore(libxl_ctx *ctx, uint32_t domid, uint32_t 
> backend,
> +   int evtch, uint64_t gfn);

Could you make this function async, by adding "const libxl_asyncop_how
*ao_how" parameter in last position?

You can follow libxl_domain_pause() example has to write an async
function that is actually synchronous (AO_CREATE, libxl__ao_complete,
AO_INPROGRESS, AO_CREATE_FAIL).

Adding the async capability now means that we won't need to change the
API if the function actually need to be async one day.

> +
>  /* May be called with info_r == NULL to check for domain's existence.
>   * Returns ERROR_DOMAIN_NOTFOUND if domain does not exist (used to return
>   * ERROR_INVAL for this scenario). */
> diff --git a/tools/libs/light/libxl_console.c 
> b/tools/libs/light/libxl_console.c
> index d8b2bc5465..ce3de100cc 100644
> --- a/tools/libs/light/libxl_console.c
> +++ b/tools/libs/light/libxl_console.c
> @@ -346,6 +346,26 @@ out:
>  return rc;
>  }
>  
> +int libxl_console_add_xenstore(libxl_ctx *ctx, uint32_t domid, uint32_t 
> backend,
> +   int evtch, uint64_t gfn)
> +{
> +GC_INIT(ctx);
> +int rc;
> +libxl__device_console console = { .backend_domid = backend,
> +  .output = "pty",
> +  .consback = 
> LIBXL__CONSOLE_BACKEND_XENCONSOLED,
> +};
> +libxl__domain_build_state state = { .console_port = evtch,

`console_port` is "uint32_t", shouldn't `evtchn` be the same type, or at
least also be unsigned?

> +.console_mfn = gfn,

I wonder if we should check if `gfn` fit in `console_mfn`, as it could
be smaller when building the toolstack on 32bit platform.


Thanks,

-- 
Anthony PERARD

Re: [PATCH v2] x86: use POPCNT for hweight() when available

[Roger Pau Monné]

On Mon, Mar 20, 2023 at 10:48:45AM +0100, Jan Beulich wrote:
> On 17.03.2023 13:26, Andrew Cooper wrote:
> > On 17/03/2023 11:22 am, Roger Pau Monné wrote:
> >> On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
> >>> This is faster than using the software implementation, and the insn is
> >>> available on all half-way recent hardware. Therefore convert
> >>> generic_hweight() to out-of-line functions (without affecting Arm)
> >>> and use alternatives patching to replace the function calls.
> >>>
> >>> Note that the approach doesn#t work for clang, due to it not recognizing
> >>> -ffixed-*.
> >> I've been giving this a look, and I wonder if it would be fine to
> >> simply push and pop the scratch registers in the 'call' path of the
> >> alternative, as that won't require any specific compiler option.
> 
> Hmm, ...
> 
> > It's been a long while, and in that time I've learnt a lot more about
> > performance, but my root objection to the approach taken here still
> > stands - it is penalising the common case to optimise some pointless
> > corner cases.
> > 
> > Yes - on the call path, an extra push/pop pair (or few) to get temp
> > registers is basically free.
> 
> ... what is "a few"? We'd need to push/pop all call-clobbered registers
> except %rax, i.e. a total of eight. I consider this too much. Unless,
> as you suggest further down, we wrote the fallback in assembly. Which I
> have to admit I'm surprised you propose when we strive to reduce the
> amount of assembly we have to maintain.

AMD added popcnt in 2007 and Intel in 2008.  While we shouldn't
mandate popcnt support, I think we also shouldn't overly worry about
the non-popcnt path.

Also, how can you assert that the code generated without the scratch
registers being usable won't be worse than the penalty of pushing and
popping such registers on the stack and letting the routines use all
registers freely?

I very much prefer to have a non-optimal non-popcnt path, but have
popcnt support for both gcc and clang, and without requiring any
compiler options.

Thanks, Roger.

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

[Andrew Cooper]

On 20/03/2023 9:24 am, Jan Beulich wrote:
> On 17.03.2023 12:39, Roger Pau Monné wrote:
>> On Tue, May 26, 2020 at 06:40:16PM +0200, Jan Beulich wrote:
>>> On 26.05.2020 17:01, Andrew Cooper wrote:
 On 26/05/2020 14:35, Jan Beulich wrote:
> On 26.05.2020 13:17, Andrew Cooper wrote:
>> On 26/05/2020 07:49, Jan Beulich wrote:
>>> Respective Core Gen10 processor lines are affected, too.
>>>
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
>>>  case 0x000506e0: /* errata SKL167 / SKW159 */
>>>  case 0x000806e0: /* erratum KBL??? */
>>>  case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
>>> +case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
>>> +case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */
>> This is marred in complexity.
>>
>> The enumeration of MSR_TSX_CTRL (from the TAA fix, but architectural
>> moving forwards on any TSX-enabled CPU) includes a confirmation that HLE
>> no longer exists/works.  This applies to IceLake systems, but possibly
>> not their initial release configuration (hence, via a later microcode
>> update).
>>
>> HLE is also disabled in microcode on all older parts for errata reasons,
>> so in practice it doesn't exist anywhere now.
>>
>> I think it is safe to drop this workaround, and this does seem a more
>> simple option than encoding which microcode turned HLE off (which sadly
>> isn't covered by the spec updates, as even when turned off, HLE is still
>> functioning according to its spec of "may speed things up, may do
>> nothing"), or the interactions with the CPUID hiding capabilities of
>> MSR_TSX_CTRL.
> I'm afraid I don't fully follow: For one, does what you say imply HLE is
> no longer enumerated in CPUID?
 No - sadly not.  For reasons of "not repeating the Haswell/Broadwell
 microcode fiasco", the HLE bit will continue to exist and be set. 
 (Although on CascadeLake and later, you can turn it off with MSR_TSX_CTRL.)

 It was always a weird CPUID bit.  You were supposed to put
 XACQUIRE/XRELEASE prefixes on your legacy locking, and it would be a nop
 on old hardware and go faster on newer hardware.

 There is nothing runtime code needs to look at the HLE bit for, except
 perhaps for UI reporting purposes.
>>> Do you know of some public Intel doc I could reference for all of this,
>>> which I would kind of need in the description of a patch ...
>>>
> But then this
> erratum does not have the usual text effectively meaning that an ucode
> update is or will be available to address the issue; instead it says
> that BIOS or VMM can reserve the respective address range.
 This is not surprising at all.  Turning off HLE was an unrelated
 activity, and I bet the link went unnoticed.

> This - assuming the alternative you describe is indeed viable - then is 
> surely
> a much more intrusive workaround than needed. Which I wouldn't assume
> they would suggest in such a case.
 My suggestion was to drop the workaround, not to complicated it with a
 microcode revision matrix.
>>> ... doing this? I don't think I've seen any of this in writing so far,
>>> except by you. (I don't understand how this reply of yours relates to
>>> what I was saying about the spec update. I understand what you are
>>> suggesting. I merely tried to express that I'd have expected Intel to
>>> point out the much easier workaround, rather than just a pretty involved
>>> one.) Otherwise, may I suggest you make such a patch, to make sure it
>>> has an adequate description?
>> Seeing as there seems to be some data missing to justify the commit -
>> was has Linux done with those erratas?
> While they deal with the SNB erratum in a similar way, I'm afraid I'm
> unaware of Linux having or having had a workaround for the errata here.
> Which, granted, is a little surprising when we did actually even issue
> an XSA for this.
>
> In fact I find Andrew's request even more surprising with that fact (us
> having issued XSA-282 for it) in mind, which originally I don't think I
> had paid attention to (nor recalled).

No - I'm aware of it.  It probably was the right move at the time.

But, Intel have subsequently killed HLE in microcode updates update in
all CPUs it ever existed in (to fix a memory ordering erratum), and
removed it from the architecture moving forwards (the enumeration of
TSX_CTRL means HLE architecturally doesn't exist even if it is enumerated).

These errata no longer exist when you've got up to date microcode, and
if you've not got up to date microcode on these CPUs, you've got far
worse security problems.

~Andrew

[qemu-mainline test] 179824: regressions - trouble: fail/pass/starved

[osstest service owner]

flight 179824 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179824/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  14 guest-start  fail REGR. vs. 179518
 test-amd64-i386-libvirt-xsm  14 guest-start  fail REGR. vs. 179518
 test-amd64-i386-libvirt-pair 25 guest-start/debian   fail REGR. vs. 179518
 test-arm64-arm64-libvirt-xsm 14 guest-start  fail REGR. vs. 179518
 test-amd64-amd64-xl-qcow212 debian-di-installfail REGR. vs. 179518
 test-amd64-amd64-libvirt-vhd 12 debian-di-installfail REGR. vs. 179518
 test-amd64-i386-xl-vhd   12 debian-di-installfail REGR. vs. 179518
 test-amd64-i386-libvirt-raw  12 debian-di-installfail REGR. vs. 179518
 test-amd64-amd64-libvirt 14 guest-start  fail REGR. vs. 179518
 test-amd64-amd64-libvirt-xsm 14 guest-start  fail REGR. vs. 179518
 test-arm64-arm64-libvirt-raw 12 debian-di-installfail REGR. vs. 179518
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 179518
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install 
fail REGR. vs. 179518
 test-arm64-arm64-xl-vhd  12 debian-di-installfail REGR. vs. 179518
 test-amd64-amd64-libvirt-pair 25 guest-start/debian  fail REGR. vs. 179518

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 179518
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 179518
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 179518
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 179518
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 179518
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-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-credit2  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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   starved  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   starved  n/a
 build-armhf-libvirt   1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   starved  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   starved  n/a
 build-armhf   2 hosts-allocate   starved  n/a

version targeted for testing:
 qemuuaa9e7fa4689d1becb2faf67f65aafcbcf664f1ce
baseline version:
 qemuu7b0f0aa55fd292fa3489755a3a896e496c51ea86

Last test of basis   179518  2023-03-09 10:37:19 Z   12 days
Failing since179526  2023-03-10 01:53:40 Z   11 days   20 attempts
Testing same since   179824  2023-03-21 00:40:21 Z0 days1 attempts


People who touched revisions under test:
  Akihiko Odaki 
  Albert Esteve 
  Alex Bennée 
  Alex Williamson 
  Alistair Francis 
  Andreas Schwab 
  Anton Johansson 
  Avihai Horon 
  BALATON Zoltan 
  Bernhard Beschow 
  Carlos López 
  Cédric Le Goater 
  Cédric Le Goater 
  Damien Hedde 
  Daniel P. Berrangé 
  David Hildenbrand 
  David Woodhouse 
  David Woodhouse 
  Dr. David Alan Gilbert 
  Eugenio Pérez 
  Fabiano Rosas 
  Fan Ni 
  fanwenjie 
  fa...@mail.ustc.edu.cn 
  Fiona Ebner 
  Gal Hammer 
  Gerd Hoffmann 
  Hanna Czenczek 
  Helge Deller 
  Idan Horowitz 
  Igor Mammedov 
  Ilya Leoshkevich 
  Ivan Klokov 
  Jared Rossi 
  Jason Wang 
  Jiaxun Yang 
  Joao 

Re: [PATCH v8 1/5] xen: introduce CONFIG_GENERIC_BUG_FRAME

[Oleksii]

On Tue, 2023-03-21 at 14:35 +0100, Jan Beulich wrote:
> On 21.03.2023 12:18, Oleksii wrote:
> > On Mon, 2023-03-20 at 13:36 +0200, Oleksii wrote:
> > > On Fri, 2023-03-17 at 15:59 +0100, Jan Beulich wrote:
> > > > On 17.03.2023 10:23, Oleksii wrote:
> > > > > On Thu, 2023-03-16 at 12:26 +0100, Jan Beulich wrote:
> > > > > > On 15.03.2023 18:21, Oleksii Kurochko wrote:
> > > > > > > --- /dev/null
> > > > > > > +++ b/xen/common/bug.c
> > > > > > > @@ -0,0 +1,108 @@
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +
> > > > > > > +#include 
> > > > > > 
> > > > > > I actually meant to also ask: What is this needed for?
> > > > > > Glancing
> > > > > > over
> > > > > > the
> > > > > > code ...
> > > > > > 
> > > > > > > +/*
> > > > > > > + * Returns a negative value in case of an error
> > > > > > > otherwise
> > > > > > > + * BUGFRAME_{run_fn, warn, bug, assert}
> > > > > > > + */
> > > > > > > +int do_bug_frame(struct cpu_user_regs *regs, unsigned
> > > > > > > long
> > > > > > > pc)
> > > > > > > +{
> > > > > > > +    const struct bug_frame *bug = NULL;
> > > > > > > +    const struct virtual_region *region;
> > > > > > > +    const char *prefix = "", *filename, *predicate;
> > > > > > > +    unsigned long fixup;
> > > > > > > +    unsigned int id, lineno;
> > > > > > > +
> > > > > > > +    region = find_text_region(pc);
> > > > > > > +    if ( !region )
> > > > > > > +    return -EINVAL;
> > > > > > > +
> > > > > > > +    for ( id = 0; id < BUGFRAME_NR; id++ )
> > > > > > > +    {
> > > > > > > +    const struct bug_frame *b;
> > > > > > > +    size_t i;
> > > > > > > +
> > > > > > > +    for ( i = 0, b = region->frame[id].bugs;
> > > > > > > +  i < region->frame[id].n_bugs; b++, i++ )
> > > > > > > +    {
> > > > > > > +    if ( bug_loc(b) == pc )
> > > > > > > +    {
> > > > > > > +    bug = b;
> > > > > > > +    goto found;
> > > > > > > +    }
> > > > > > > +    }
> > > > > > > +    }
> > > > > > > +
> > > > > > > + found:
> > > > > > > +    if ( !bug )
> > > > > > > +    return -ENOENT;
> > > > > > > +
> > > > > > > +    if ( id == BUGFRAME_run_fn )
> > > > > > > +    {
> > > > > > > +    void (*fn)(struct cpu_user_regs *) =
> > > > > > > bug_ptr(bug);
> > > > > > > +
> > > > > > > +    fn(regs);
> > > > > > > +
> > > > > > > +    /* Re-enforce consistent types, because of the
> > > > > > > casts
> > > > > > > involved. */
> > > > > > > +    if ( false )
> > > > > > > +    run_in_exception_handler(fn);
> > > > > > > +
> > > > > > > +    return id;
> > > > > > > +    }
> > > > > > > +
> > > > > > > +    /* WARN, BUG or ASSERT: decode the filename pointer
> > > > > > > and
> > > > > > > line
> > > > > > > number. */
> > > > > > > +    filename = bug_ptr(bug);
> > > > > > > +    if ( !is_kernel(filename) && !is_patch(filename) )
> > > > > > > +    return -EINVAL;
> > > > > > > +    fixup = strlen(filename);
> > > > > > > +    if ( fixup > 50 )
> > > > > > > +    {
> > > > > > > +    filename += fixup - 47;
> > > > > > > +    prefix = "...";
> > > > > > > +    }
> > > > > > > +    lineno = bug_line(bug);
> > > > > > > +
> > > > > > > +    switch ( id )
> > > > > > > +    {
> > > > > > > +    case BUGFRAME_warn:
> > > > > > > +    printk("Xen WARN at %s%s:%d\n", prefix,
> > > > > > > filename,
> > > > > > > lineno);
> > > > > > > +    show_execution_state(regs);
> > > > > > > +
> > > > > > > +    break;
> > > > > > > +
> > > > > > > +    case BUGFRAME_bug:
> > > > > > > +    printk("Xen BUG at %s%s:%d\n", prefix, filename,
> > > > > > > lineno);
> > > > > > > +
> > > > > > > +    if ( BUG_DEBUGGER_TRAP_FATAL(regs) )
> > > > > > > +    break;
> > > > > > > +
> > > > > > > +    show_execution_state(regs);
> > > > > > > +    panic("Xen BUG at %s%s:%d\n", prefix, filename,
> > > > > > > lineno);
> > > > > > > +
> > > > > > > +    case BUGFRAME_assert:
> > > > > > > +    /* ASSERT: decode the predicate string pointer.
> > > > > > > */
> > > > > > > +    predicate = bug_msg(bug);
> > > > > > > +    if ( !is_kernel(predicate) &&
> > > > > > > !is_patch(predicate) )
> > > > > > > +    predicate = "";
> > > > > > > +
> > > > > > > +    printk("Assertion '%s' failed at %s%s:%d\n",
> > > > > > > +   predicate, prefix, filename, lineno);
> > > > > > > +
> > > > > > > +    if ( BUG_DEBUGGER_TRAP_FATAL(regs) )
> > > > > > > +    break;
> > > > > > > +
> > > > > > > +    show_execution_state(regs);
> > > > > > > +    panic("Assertion '%s' failed at %s%s:%d\n",
> > > > > > > +  predicate, prefix, filename, lineno);
> > > > > > > +    }
> > > > > > > +
> > > > > > > +    return id;
> > > > > > > +}
> > > > > > 
> > > > > > ... I 

Re: [PATCH v5 2/7] xen/riscv: initialize boot_info structure

[Oleksii]

On Tue, 2023-03-21 at 12:27 +0100, Jan Beulich wrote:
> On 16.03.2023 15:39, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/setup.c
> > +++ b/xen/arch/riscv/setup.c
> > @@ -1,12 +1,16 @@
> >  #include 
> >  #include 
> > +#include 
> >  
> > +#include 
> >  #include 
> >  
> >  /* Xen stack for bringing up the first CPU. */
> >  unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
> >  __aligned(STACK_SIZE);
> >  
> > +struct boot_info boot_info = { (unsigned long)&_start, (unsigned
> > long)&_end, 0UL, 0UL };
> 
> You add no declaration in a header, in which case this wants to be
> static.
Sure.
> It may also want to be __initdata, depending on further planned uses.
I am going to use it only for initial page table initialization.
At least for now.
> I
> would also like to suggest using C99 dedicated initializers and in
> any
> event omit the 0UL initializer values (as that's what the compiler
> will
> use anyway). Yet even then I think the line is still too long and
> hence
> needs wrapping.
> 
> > @@ -15,11 +19,19 @@ unsigned char __initdata
> > cpu0_boot_stack[STACK_SIZE]
> >   */
> >  int dummy_bss __attribute__((unused));
> >  
> > +static void fill_boot_info(void)
> 
> __init?
Yes, should it be __init.
> 
> > +{
> > +    boot_info.load_start = (unsigned long)_start;
> > +    boot_info.load_end   = (unsigned long)_end;
> > +}
> 
> I'd like to understand how this is intended to work: _start and _end
> are known at compile time, and their value won't change (unless you
> process relocations alongside switching from 1:1 mapping to some
> other virtual memory layout). Therefore - why can't these be put in
> the initializer as well? Guessing that the values derived here are
> different because of being calculated in a PC-relative way, I think
> this really needs a comment. If, of course, this can be relied upon
> in the first place.
Your guessing is correct. In this case addresses of _start and _end
will be calculated in a PC-relative way.
So I'll add a comment.

> 
> Also please be consistent about the use of unary & when taking the
> address of arrays (or functions). Personally I prefer the & to be
> omitted in such cases, but what I consider relevant is that there
> be no mix (in new code at least).
Sure.

Thanks for the comments.
I'll fix that in the new version of the
patch.

~ Oleksii

Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

[Roger Pau Monné]

On Tue, May 26, 2020 at 08:49:52AM +0200, Jan Beulich wrote:
> Respective Core Gen10 processor lines are affected, too.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
>  case 0x000506e0: /* errata SKL167 / SKW159 */
>  case 0x000806e0: /* erratum KBL??? */
>  case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
> +case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
> +case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */

I think this is errata CML101, I would add that at the end of the
comment.

Also you seem to be missing the '806ec' model (806e0 case)? (listed as
'U 4+2 V1')

Thanks, Roger.

Re: [BUG] x2apic broken with current AMD hardware

[Neowutran]

> > >> I was taking a look at the BIOS manual for this motherboard and noticed
> > >> a mention of a "Local APIC Mode" setting.  Four values are listed
> > >> "Compatibility", "xAPIC", "x2APIC", and "Auto".
> 
> This does appear to be an improvement.  With this the system boots if
> the "Local APIC Mode" setting is "auto".  As you may have guessed,
> "(XEN) Switched to APIC driver x2apic_phys".
> 
> 
> 
> When I tried setting "Local APIC Mode" to "x2APIC" though things didn't
> go so well.  

I confirm what Elliott said, just tested the patch on my computer (ryzen 7000 series). 

Before, I was using the workaround "x2apic=false" in the xen boot
option. 

After applying the patch, when "Local APIC Mode" is set to "auto" ( or
at least not "x2APIC"), then it work without needing the "x2apic=false"
workaround. 
If "Local APIC Mode" is set to "X2APIC", then it is stuck waiting for
nvme 
information, like without the patch and without the "x2apic=false"
workaround. 


signature.asc
Description: PGP signature

Re: [PATCH v5 1/7] xen/riscv: introduce boot information structure

[Oleksii]

On Tue, 2023-03-21 at 12:17 +0100, Jan Beulich wrote:
> On 16.03.2023 15:39, Oleksii Kurochko wrote:
> > @@ -50,4 +51,6 @@ void asm_offsets(void)
> >  OFFSET(CPU_USER_REGS_SEPC, struct cpu_user_regs, sepc);
> >  OFFSET(CPU_USER_REGS_SSTATUS, struct cpu_user_regs, sstatus);
> >  OFFSET(CPU_USER_REGS_PREGS, struct cpu_user_regs, pregs);
> > +    OFFSET(BI_LINKER_START, struct boot_info, linker_start);
> > +    OFFSET(BI_LOAD_START, struct boot_info, load_start);
> >  }
> 
> May I suggest that you add BLANK(); and a blank line between separate
> groups of OFFSET() uses? This may not matter much right now, but
> it'll
> help readability and findability once the file further grows.
Sure. I'll update it in the next version of the patch.

~ Oleksii

preparations for 4.16.4 and 4.17.1

[Jan Beulich]

All,

the former release is due in a couple of weeks time, the latter a week
or two later. Note that with us following the 4 month cadence pretty
strictly this time, 4.16.4 isn't expected to be the last ordinary stable
release from the 4.16 branch, yet (unless, of course, we end up slipping
significantly).

Please point out backports you find missing from the respective staging
branch, but which you consider relevant. I have one change queued on top
of what I've pushed to the branches earlier today, simply because it
hasn't passed the push gate on master yet:

0d2686f6b66b AMD/IOMMU: without XT, x2APIC needs to be forced into physical mode

Jan

Re: [XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

[Jan Beulich]

On 21.03.2023 15:03, Ayan Kumar Halder wrote:
> --- a/xen/arch/Kconfig
> +++ b/xen/arch/Kconfig
> @@ -1,6 +1,12 @@
>  config 64BIT
>   bool
>  
> +config PHYS_ADDR_T_32
> + bool
> +
> +config PHYS_ADDR_T_64
> + bool

Do we really need both? If so, what guards against both being selected
at the same time?

Them being put in common code I consider it an at least latent issue
that you add "select"s ...

> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -9,6 +9,7 @@ config ARM_64
>   select 64BIT
>   select ARM_EFI
>   select HAS_FAST_MULTIPLY
> + select PHYS_ADDR_T_64
>  
>  config ARM
>   def_bool y
> @@ -19,13 +20,48 @@ config ARM
>   select HAS_PMAP
>   select IOMMU_FORCE_PT_SHARE
>  
> +menu "Architecture Features"
> +
> +choice
> + prompt "Physical address space size" if ARM_32
> + default ARM_PA_BITS_48 if ARM_64
> + default ARM_PA_BITS_40 if ARM_32
> + help
> +   User can choose to represent the width of physical address. This can
> +   sometimes help in optimizing the size of image when user chooses a
> +   smaller size to represent physical address.
> +
> +config ARM_PA_BITS_32
> + bool "32-bit"
> + help
> +   On platforms where any physical address can be represented within 32 
> bits
> +   , user should choose this option. This will help is reduced size of 
> the
> +   binary.
> + select PHYS_ADDR_T_32
> + depends on ARM_32
> +
> +config ARM_PA_BITS_40
> + bool "40-bit"
> + select PHYS_ADDR_T_64
> + depends on ARM_32
> +
> +config ARM_PA_BITS_48
> + bool "40-bit"
> + select PHYS_ADDR_T_64
> + depends on ARM_48
> +endchoice

... only for Arm. You get away with this only because ...

> --- a/xen/arch/arm/include/asm/types.h
> +++ b/xen/arch/arm/include/asm/types.h
> @@ -34,9 +34,15 @@ typedef signed long long s64;
>  typedef unsigned long long u64;
>  typedef u32 vaddr_t;
>  #define PRIvaddr PRIx32
> +#if defined(CONFIG_PHYS_ADDR_T_32)
> +typedef unsigned long paddr_t;
> +#define INVALID_PADDR (~0UL)
> +#define PRIpaddr "08lx"
> +#else
>  typedef u64 paddr_t;
>  #define INVALID_PADDR (~0ULL)
>  #define PRIpaddr "016llx"
> +#endif
>  typedef u32 register_t;
>  #define PRIregister "08x"
>  #elif defined (CONFIG_ARM_64)

... you tweak things here, when we're in the process of moving stuff
out of asm/types.h. (Using "unsigned long" for a 32-bit paddr_t is of
course suspicious as well - this ought to be uint32_t.)

Jan

[PATCH v5] ACPI: processor: Fix evaluating _PDC method when running as Xen dom0

[Roger Pau Monne]

In ACPI systems, the OS can direct power management, as opposed to the
firmware.  This OS-directed Power Management is called OSPM.  Part of
telling the firmware that the OS going to direct power management is
making ACPI "_PDC" (Processor Driver Capabilities) calls.  These _PDC
methods must be evaluated for every processor object.  If these _PDC
calls are not completed for every processor it can lead to
inconsistency and later failures in things like the CPU frequency
driver.

In a Xen system, the dom0 kernel is responsible for system-wide power
management.  The dom0 kernel is in charge of OSPM.  However, the
number of CPUs available to dom0 can be different than the number of
CPUs physically present on the system.

This leads to a problem: the dom0 kernel needs to evaluate _PDC for
all the processors, but it can't always see them.

In dom0 kernels, ignore the existing ACPI method for determining if a
processor is physically present because it might not be accurate.
Instead, ask the hypervisor for this information.

Fix this by introducing a custom function to use when running as Xen
dom0 in order to check whether a processor object matches a CPU that's
online.  Such checking is done using the existing information fetched
by the Xen pCPU subsystem, extending it to also store the ACPI ID.

This ensures that _PDC method gets evaluated for all physically online
CPUs, regardless of the number of CPUs made available to dom0.

Fixes: 5d554a7bb064 ('ACPI: processor: add internal 
processor_physically_present()')
Signed-off-by: Roger Pau Monné 
---
Changes since v4:
 - Move definition/declaration of xen_processor_present() to different
   header.
 - Fold subject edit.

Changes since v3:
 - Protect xen_processor_present() definition with CONFIG_ACPI.

Changes since v2:
 - Extend and use the existing pcpu functionality.

Changes since v1:
 - Reword commit message.
---
 drivers/acpi/processor_pdc.c | 11 +++
 drivers/xen/pcpu.c   | 20 
 include/xen/xen.h| 10 ++
 3 files changed, 41 insertions(+)

diff --git a/drivers/acpi/processor_pdc.c b/drivers/acpi/processor_pdc.c
index 8c3f82c9fff3..18fb04523f93 100644
--- a/drivers/acpi/processor_pdc.c
+++ b/drivers/acpi/processor_pdc.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 
+#include 
+
 #include "internal.h"
 
 static bool __init processor_physically_present(acpi_handle handle)
@@ -47,6 +49,15 @@ static bool __init processor_physically_present(acpi_handle 
handle)
return false;
}
 
+   if (xen_initial_domain())
+   /*
+* When running as a Xen dom0 the number of processors Linux
+* sees can be different from the real number of processors on
+* the system, and we still need to execute _PDC for all of
+* them.
+*/
+   return xen_processor_present(acpi_id);
+
type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
cpuid = acpi_get_cpuid(handle, type, acpi_id);
 
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index fd3a644b0855..1814f8762f54 100644
--- a/drivers/xen/pcpu.c
+++ b/drivers/xen/pcpu.c
@@ -58,6 +58,7 @@ struct pcpu {
struct list_head list;
struct device dev;
uint32_t cpu_id;
+   uint32_t acpi_id;
uint32_t flags;
 };
 
@@ -249,6 +250,7 @@ static struct pcpu *create_and_register_pcpu(struct 
xenpf_pcpuinfo *info)
 
INIT_LIST_HEAD(>list);
pcpu->cpu_id = info->xen_cpuid;
+   pcpu->acpi_id = info->acpi_id;
pcpu->flags = info->flags;
 
/* Need hold on xen_pcpu_lock before pcpu list manipulations */
@@ -381,3 +383,21 @@ static int __init xen_pcpu_init(void)
return ret;
 }
 arch_initcall(xen_pcpu_init);
+
+#ifdef CONFIG_ACPI
+bool __init xen_processor_present(uint32_t acpi_id)
+{
+   struct pcpu *pcpu;
+   bool online = false;
+
+   mutex_lock(_pcpu_lock);
+   list_for_each_entry(pcpu, _pcpus, list)
+   if (pcpu->acpi_id == acpi_id) {
+   online = pcpu->flags & XEN_PCPU_FLAGS_ONLINE;
+   break;
+   }
+   mutex_unlock(_pcpu_lock);
+
+   return online;
+}
+#endif
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 7adf59837c25..4410e74f3eb5 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -71,4 +71,14 @@ static inline void xen_free_unpopulated_pages(unsigned int 
nr_pages,
 }
 #endif
 
+#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI) && defined(CONFIG_X86)
+bool __init xen_processor_present(uint32_t acpi_id);
+#else
+static inline bool xen_processor_present(uint32_t acpi_id)
+{
+   BUG();
+   return false;
+}
+#endif
+
 #endif /* _XEN_XEN_H */
-- 
2.40.0

Re: [XEN v4 04/11] xen/drivers: ns16550: Use paddr_t for io_base/io_size

[Jan Beulich]

On 21.03.2023 15:03, Ayan Kumar Halder wrote:
> @@ -1163,10 +1163,16 @@ static const struct ns16550_config __initconst 
> uart_config[] =
>  },
>  };
>  
> +#define PARSE_ERR_RET(_f, _a...) \
> +do { \
> +printk( "ERROR: " _f "\n" , ## _a ); \
> +return false;\
> +} while ( 0 )

You can't really re-use this construct unchanged (and perhaps it's also
not worth changing for this single use that you need): Note the "return
false", which ...

>  static int __init
>  pci_uart_config(struct ns16550 *uart, bool_t skip_amt, unsigned int idx)

... for a function returning "int" is equivalent to "return 0", which
is kind of a success indicator here. Whatever adjustment you make
needs to be in line with (at least) the two callers checking the
return value (the other two not doing so is suspicious, but then the
way the return values are used is somewhat odd, too).

> @@ -1235,6 +1241,8 @@ pci_uart_config(struct ns16550 *uart, bool_t skip_amt, 
> unsigned int idx)
>  /* MMIO based */
>  if ( param->mmio && !(bar & PCI_BASE_ADDRESS_SPACE_IO) )
>  {
> +uint64_t pci_uart_io_base;
> +
>  pci_conf_write32(PCI_SBDF(0, b, d, f),
>   PCI_BASE_ADDRESS_0 + bar_idx*4, ~0u);
>  len = pci_conf_read32(PCI_SBDF(0, b, d, f),
> @@ -1259,8 +1267,14 @@ pci_uart_config(struct ns16550 *uart, bool_t skip_amt, 
> unsigned int idx)
>  else
>  size = len & PCI_BASE_ADDRESS_MEM_MASK;
>  
> -uart->io_base = ((u64)bar_64 << 32) |
> -(bar & PCI_BASE_ADDRESS_MEM_MASK);
> +pci_uart_io_base = ((u64)bar_64 << 32) |

As you touch this code, please be so kind and also switch to using
uint64_t here.

Also why do you change parse_positional() but not (also)
parse_namevalue_pairs()?

Jan

[XEN v4 10/11] xen/arm: p2m: Use the pa_range_info table to support Arm_32 and Arm_64

[Ayan Kumar Halder]

Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64.

Signed-off-by: Ayan Kumar Halder 
---
Changes from -

v3 - 1. New patch introduced in v4.
2. Restructure the code such that pa_range_info[] is used both by ARM_32 as
well as ARM_64.

 xen/arch/arm/p2m.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 948f199d84..f34b6e6f11 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -2265,22 +2265,16 @@ void __init setup_virt_paging(void)
 /* Setup Stage 2 address translation */
 register_t val = VTCR_RES1|VTCR_SH0_IS|VTCR_ORGN0_WBWA|VTCR_IRGN0_WBWA;
 
-#ifdef CONFIG_ARM_32
-if ( p2m_ipa_bits < 40 )
-panic("P2M: Not able to support %u-bit IPA at the moment\n",
-  p2m_ipa_bits);
-
-printk("P2M: 40-bit IPA\n");
-p2m_ipa_bits = 40;
-val |= VTCR_T0SZ(0x18); /* 40 bit IPA */
-val |= VTCR_SL0(0x1); /* P2M starts at first level */
-#else /* CONFIG_ARM_64 */
 static const struct {
 unsigned int pabits; /* Physical Address Size */
 unsigned int t0sz;   /* Desired T0SZ, minimum in comment */
 unsigned int root_order; /* Page order of the root of the p2m */
 unsigned int sl0;/* Desired SL0, maximum in comment */
 } pa_range_info[] __initconst = {
+#ifdef CONFIG_ARM_32
+[0] = { 40,  24/*24*/,  1,  1 },
+[1] = { 0 } /* Invalid */
+#else
 /* T0SZ minimum and SL0 maximum from ARM DDI 0487H.a Table D5-6 */
 /*  PA size, t0sz(min), root-order, sl0(max) */
 [0] = { 32,  32/*32*/,  0,  1 },
@@ -2291,11 +2285,13 @@ void __init setup_virt_paging(void)
 [5] = { 48,  16/*16*/,  0,  2 },
 [6] = { 52,  12/*12*/,  4,  2 },
 [7] = { 0 }  /* Invalid */
+#endif
 };
 
 unsigned int i;
 unsigned int pa_range = 0x10; /* Larger than any possible value */
 
+#ifdef CONFIG_ARM_64
 /*
  * Restrict "p2m_ipa_bits" if needed. As P2M table is always configured
  * with IPA bits == PA bits, compare against "pabits".
@@ -2309,6 +2305,9 @@ void __init setup_virt_paging(void)
  */
 if ( system_cpuinfo.mm64.vmid_bits == MM64_VMID_16_BITS_SUPPORT )
 max_vmid = MAX_VMID_16_BIT;
+#else
+p2m_ipa_bits = PADDR_BITS;
+#endif
 
 /* Choose suitable "pa_range" according to the resulted "p2m_ipa_bits". */
 for ( i = 0; i < ARRAY_SIZE(pa_range_info); i++ )
@@ -2324,14 +2323,13 @@ void __init setup_virt_paging(void)
 if ( pa_range >= ARRAY_SIZE(pa_range_info) || 
!pa_range_info[pa_range].pabits )
 panic("Unknown encoding of ID_AA64MMFR0_EL1.PARange %x\n", pa_range);
 
-val |= VTCR_PS(pa_range);
+#ifdef CONFIG_ARM_64
 val |= VTCR_TG0_4K;
+val |= VTCR_PS(pa_range);
 
 /* Set the VS bit only if 16 bit VMID is supported. */
 if ( MAX_VMID == MAX_VMID_16_BIT )
 val |= VTCR_VS;
-val |= VTCR_SL0(pa_range_info[pa_range].sl0);
-val |= VTCR_T0SZ(pa_range_info[pa_range].t0sz);
 
 p2m_root_order = pa_range_info[pa_range].root_order;
 p2m_root_level = 2 - pa_range_info[pa_range].sl0;
@@ -2342,6 +2340,10 @@ void __init setup_virt_paging(void)
pa_range_info[pa_range].pabits,
( MAX_VMID == MAX_VMID_16_BIT ) ? 16 : 8);
 #endif
+
+val |= VTCR_SL0(pa_range_info[pa_range].sl0);
+val |= VTCR_T0SZ(pa_range_info[pa_range].t0sz);
+
 printk("P2M: %d levels with order-%d root, VTCR 0x%"PRIregister"\n",
4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, val);
 
-- 
2.17.1

[XEN v4 09/11] xen/arm: Restrict zeroeth_table_offset for ARM_64

[Ayan Kumar Halder]

When 32 bit physical addresses are used (ie ARM_PA_32=y),
"va >> ZEROETH_SHIFT" causes an overflow.
Also, there is no zeroeth level page table on Arm 32-bit.

Also took the opportunity to clean up dump_pt_walk(). One could use
DECLARE_OFFSETS() macro instead of declaring the declaring an array
of page table offsets.

Acked-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Ayan Kumar Halder 
---
Changes from -

v1 - Removed the duplicate declaration for DECLARE_OFFSETS.

v2 - 1. Reworded the commit message. 
2. Use CONFIG_ARM_PA_32 to restrict zeroeth_table_offset.

v3 - 1. Added R-b and Ack.

 xen/arch/arm/include/asm/lpae.h | 4 
 xen/arch/arm/mm.c   | 7 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/include/asm/lpae.h b/xen/arch/arm/include/asm/lpae.h
index 3fdd5d0de2..0d40388f93 100644
--- a/xen/arch/arm/include/asm/lpae.h
+++ b/xen/arch/arm/include/asm/lpae.h
@@ -259,7 +259,11 @@ lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr);
 #define first_table_offset(va)  TABLE_OFFSET(first_linear_offset(va))
 #define second_table_offset(va) TABLE_OFFSET(second_linear_offset(va))
 #define third_table_offset(va)  TABLE_OFFSET(third_linear_offset(va))
+#ifdef CONFIG_ARM_PA_BITS_32
+#define zeroeth_table_offset(va)  0
+#else
 #define zeroeth_table_offset(va)  TABLE_OFFSET(zeroeth_linear_offset(va))
+#endif
 
 /*
  * Macros to define page-tables:
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index d8b43ef38c..41e0896b0f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -221,12 +221,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
 {
 static const char *level_strs[4] = { "0TH", "1ST", "2ND", "3RD" };
 const mfn_t root_mfn = maddr_to_mfn(ttbr);
-const unsigned int offsets[4] = {
-zeroeth_table_offset(addr),
-first_table_offset(addr),
-second_table_offset(addr),
-third_table_offset(addr)
-};
+DECLARE_OFFSETS(offsets, addr);
 lpae_t pte, *mapping;
 unsigned int level, root_table;
 
-- 
2.17.1

Re: [PATCH v4] x86: detect CMOS aliasing on ports other than 0x70/0x71

[Roger Pau Monné]

On Mon, Mar 20, 2023 at 09:32:26AM +0100, Jan Beulich wrote:
> ... in order to also intercept Dom0 accesses through the alias ports.

I'm trying to get some documentation about this aliasing, but so far I
haven't been able to find any.  Do you have any references of where I
might be able to find it?

> Also stop intercepting accesses to the CMOS ports if we won't ourselves
> use the CMOS RTC.

Could this create any concerns with the ability to disable NMIs if we
no longer filter accesses to the RTC?

Thanks, Roger.

[XEN v4 11/11] xen/arm: p2m: Enable support for 32bit IPA for ARM_32

[Ayan Kumar Halder]

The pabits, t0sz, root_order and sl0 values are the same as those for
ARM_64.

Signed-off-by: Ayan Kumar Halder 
---

Changes from -

v1 - New patch.

v2 - 1. Added Ack.

v3 - 1. Dropped Ack. 
2. Rebased the patch based on the previous change.

 xen/arch/arm/p2m.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f34b6e6f11..20beecc6e8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -2272,8 +2272,9 @@ void __init setup_virt_paging(void)
 unsigned int sl0;/* Desired SL0, maximum in comment */
 } pa_range_info[] __initconst = {
 #ifdef CONFIG_ARM_32
-[0] = { 40,  24/*24*/,  1,  1 },
-[1] = { 0 } /* Invalid */
+[0] = { 32,  32/*32*/,  0,  1 },
+[1] = { 40,  24/*24*/,  1,  1 },
+[2] = { 0 } /* Invalid */
 #else
 /* T0SZ minimum and SL0 maximum from ARM DDI 0487H.a Table D5-6 */
 /*  PA size, t0sz(min), root-order, sl0(max) */
-- 
2.17.1

[XEN v4 05/11] xen/arm: Introduce a wrapper for dt_device_get_address() to handle paddr_t

[Ayan Kumar Halder]

dt_device_get_address() can accept uint64_t only for address and size.
However, the address/size denotes physical addresses. Thus, they should
be represented by 'paddr_t'.
Consequently, we introduce a wrapper for dt_device_get_address() ie
dt_device_get_paddr() which accepts address/size as paddr_t and inturn
invokes dt_device_get_address() after converting address/size to
uint64_t.

The reason for introducing doing this is that in future 'paddr_t' may
be defined as uint32_t. Thus, we need an explicit wrapper to do the type
conversion and return an error in case of truncation.

With this, callers now invoke dt_device_get_paddr().
dt_device_get_address() is invoked by dt_device_get_paddr() only.

Signed-off-by: Ayan Kumar Halder 
---
Changes from -

v1 - 1. New patch.

v2 - 1. Extracted part of "[XEN v2 05/11] xen/arm: Use paddr_t instead of u64 
for address/size"
into this patch.

2. dt_device_get_address() callers now invoke dt_device_get_paddr() instead.

3. Logged error in case of truncation.

v3 - 1. Modified the truncation checks as "dt_addr != (paddr_t)dt_addr".
2. Some sanity fixes. 

 xen/arch/arm/domain_build.c| 10 +++---
 xen/arch/arm/gic-v2.c  | 10 +++---
 xen/arch/arm/gic-v3-its.c  |  4 +--
 xen/arch/arm/gic-v3.c  | 10 +++---
 xen/arch/arm/pci/pci-host-common.c |  6 ++--
 xen/arch/arm/platforms/brcm-raspberry-pi.c |  2 +-
 xen/arch/arm/platforms/brcm.c  |  4 +--
 xen/arch/arm/platforms/exynos5.c   | 32 -
 xen/arch/arm/platforms/sunxi.c |  2 +-
 xen/arch/arm/platforms/xgene-storm.c   |  2 +-
 xen/common/device_tree.c   | 40 --
 xen/drivers/char/cadence-uart.c|  4 +--
 xen/drivers/char/exynos4210-uart.c |  4 +--
 xen/drivers/char/imx-lpuart.c  |  4 +--
 xen/drivers/char/meson-uart.c  |  4 +--
 xen/drivers/char/mvebu-uart.c  |  4 +--
 xen/drivers/char/ns16550.c |  2 +-
 xen/drivers/char/omap-uart.c   |  4 +--
 xen/drivers/char/pl011.c   |  6 ++--
 xen/drivers/char/scif-uart.c   |  4 +--
 xen/drivers/passthrough/arm/ipmmu-vmsa.c   |  8 ++---
 xen/drivers/passthrough/arm/smmu-v3.c  |  2 +-
 xen/drivers/passthrough/arm/smmu.c |  8 ++---
 xen/include/xen/device_tree.h  |  6 ++--
 24 files changed, 109 insertions(+), 73 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6573d15302..b4ae6a2548 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1698,13 +1698,13 @@ static int __init find_memory_holes(const struct 
kernel_info *kinfo,
 dt_for_each_device_node( dt_host, np )
 {
 unsigned int naddr;
-u64 addr, size;
+paddr_t addr, size;
 
 naddr = dt_number_of_address(np);
 
 for ( i = 0; i < naddr; i++ )
 {
-res = dt_device_get_address(np, i, , );
+res = dt_device_get_paddr(np, i, , );
 if ( res )
 {
 printk(XENLOG_ERR "Unable to retrieve address %u for %s\n",
@@ -2478,7 +2478,7 @@ static int __init handle_device(struct domain *d, struct 
dt_device_node *dev,
 unsigned int naddr;
 unsigned int i;
 int res;
-u64 addr, size;
+paddr_t addr, size;
 bool own_device = !dt_device_for_passthrough(dev);
 /*
  * We want to avoid mapping the MMIO in dom0 for the following cases:
@@ -2533,7 +2533,7 @@ static int __init handle_device(struct domain *d, struct 
dt_device_node *dev,
 /* Give permission and map MMIOs */
 for ( i = 0; i < naddr; i++ )
 {
-res = dt_device_get_address(dev, i, , );
+res = dt_device_get_paddr(dev, i, , );
 if ( res )
 {
 printk(XENLOG_ERR "Unable to retrieve address %u for %s\n",
@@ -2964,7 +2964,7 @@ static int __init handle_passthrough_prop(struct 
kernel_info *kinfo,
 if ( res )
 {
 printk(XENLOG_ERR "Unable to permit to dom%d access to"
-   " 0x%"PRIx64" - 0x%"PRIx64"\n",
+   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
kinfo->d->domain_id,
mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
 return res;
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 5d4d298b86..6476ff4230 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -993,7 +993,7 @@ static void gicv2_extension_dt_init(const struct 
dt_device_node *node)
 continue;
 
 /* Get register frame resource from DT. */
-if ( dt_device_get_address(v2m, 0, , ) )
+if ( dt_device_get_paddr(v2m, 0, , ) )
 panic("GICv2: Cannot find a valid v2m frame address\n");
 
 /*
@@ -1018,19 +1018,19 @@ static void __init gicv2_dt_init(void)
 paddr_t vsize;
 const struct dt_device_node *node = 

[XEN v4 08/11] xen/arm: guest_walk: LPAE specific bits should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32"

[Ayan Kumar Halder]

As the previous patch introduces CONFIG_PHYS_ADDR_T_32 to support 32 bit
physical addresses, the code specific to "Large Physical Address Extension"
(ie LPAE) should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32".

Refer xen/arch/arm/include/asm/short-desc.h, "short_desc_l1_supersec_t"
unsigned int extbase1:4;/* Extended base address, PA[35:32] */
unsigned int extbase2:4;/* Extended base address, PA[39:36] */

Thus, extbase1 and extbase2 are not valid when 32 bit physical addresses
are supported.

Signed-off-by: Ayan Kumar Halder 
Acked-by: Stefano Stabellini 
---
Changes from -
v1 - 1. Extracted from "[XEN v1 8/9] xen/arm: Other adaptations required to 
support 32bit paddr".

v2 - 1. Reordered this patch so that it appears after CONFIG_ARM_PA_32 is
introduced (in 6/9).

v3 - 1. Updated the commit message.
2. Added Ack.

 xen/arch/arm/guest_walk.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
index 43d3215304..c80a0ce55b 100644
--- a/xen/arch/arm/guest_walk.c
+++ b/xen/arch/arm/guest_walk.c
@@ -154,8 +154,10 @@ static bool guest_walk_sd(const struct vcpu *v,
 mask = (1ULL << L1DESC_SUPERSECTION_SHIFT) - 1;
 *ipa = gva & mask;
 *ipa |= (paddr_t)(pte.supersec.base) << L1DESC_SUPERSECTION_SHIFT;
+#ifndef CONFIG_PHYS_ADDR_T_32
 *ipa |= (paddr_t)(pte.supersec.extbase1) << 
L1DESC_SUPERSECTION_EXT_BASE1_SHIFT;
 *ipa |= (paddr_t)(pte.supersec.extbase2) << 
L1DESC_SUPERSECTION_EXT_BASE2_SHIFT;
+#endif /* CONFIG_PHYS_ADDR_T_32 */
 }
 
 /* Set permissions so that the caller can check the flags by herself. 
*/
-- 
2.17.1

[XEN v4 07/11] xen/arm: Introduce choice to enable 64/32 bit physical addressing

[Ayan Kumar Halder]

Some Arm based hardware platforms which does not support LPAE
(eg Cortex-R52), uses 32 bit physical addresses.
Also, users may choose to use 32 bits to represent physical addresses
for optimization.

To support the above use cases, we have introduced arch independent
configs to choose if the physical address can be represented using
32 bits (PHYS_ADDR_T_32) or 64 bits (PHYS_ADDR_T_64).
For now only ARM_32 provides support to enable 32 bit physical
addressing.

When PHYS_ADDR_T_32 is defined, PADDR_BITS is set to 32.
When PHYS_ADDR_T_64 is defined with ARM_32, PADDR_BITS is set to 40.
When PHYS_ADDR_T_64 is defined with ARM_64, PADDR_BITS is set to 48.
The last two are same as the current configuration used today on Xen.

PADDR_BITS is also set to 48 when ARM_64 is defined. The reason being
the choice to select ARM_PA_BITS_32/ARM_PA_BITS_40/ARM_PA_BITS_48 is
currently allowed when ARM_32 is defined.

Signed-off-by: Ayan Kumar Halder 
---
Changes from -
v1 - 1. Extracted from "[XEN v1 8/9] xen/arm: Other adaptations required to 
support 32bit paddr".

v2 - 1. Introduced Kconfig choice. ARM_64 can select PHYS_ADDR_64 only whereas
ARM_32 can select PHYS_ADDR_32 or PHYS_ADDR_64.
2. For CONFIG_ARM_PA_32, paddr_t is defined as 'unsigned long'. 

v3 - 1. Allow user to define PADDR_BITS by selecting different config options
ARM_PA_BITS_32, ARM_PA_BITS_40 and ARM_PA_BITS_48.
2. Add the choice under "Architecture Features".

 xen/arch/Kconfig |  6 +
 xen/arch/arm/Kconfig | 40 ++--
 xen/arch/arm/include/asm/page-bits.h |  6 +
 xen/arch/arm/include/asm/types.h |  6 +
 xen/arch/arm/mm.c|  1 +
 5 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
index 7028f7b74f..89096c77a4 100644
--- a/xen/arch/Kconfig
+++ b/xen/arch/Kconfig
@@ -1,6 +1,12 @@
 config 64BIT
bool
 
+config PHYS_ADDR_T_32
+   bool
+
+config PHYS_ADDR_T_64
+   bool
+
 config NR_CPUS
int "Maximum number of CPUs"
range 1 4095
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 239d3aed3c..13e3a23911 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -9,6 +9,7 @@ config ARM_64
select 64BIT
select ARM_EFI
select HAS_FAST_MULTIPLY
+   select PHYS_ADDR_T_64
 
 config ARM
def_bool y
@@ -19,13 +20,48 @@ config ARM
select HAS_PMAP
select IOMMU_FORCE_PT_SHARE
 
+menu "Architecture Features"
+
+choice
+   prompt "Physical address space size" if ARM_32
+   default ARM_PA_BITS_48 if ARM_64
+   default ARM_PA_BITS_40 if ARM_32
+   help
+ User can choose to represent the width of physical address. This can
+ sometimes help in optimizing the size of image when user chooses a
+ smaller size to represent physical address.
+
+config ARM_PA_BITS_32
+   bool "32-bit"
+   help
+ On platforms where any physical address can be represented within 32 
bits
+ , user should choose this option. This will help is reduced size of 
the
+ binary.
+   select PHYS_ADDR_T_32
+   depends on ARM_32
+
+config ARM_PA_BITS_40
+   bool "40-bit"
+   select PHYS_ADDR_T_64
+   depends on ARM_32
+
+config ARM_PA_BITS_48
+   bool "40-bit"
+   select PHYS_ADDR_T_64
+   depends on ARM_48
+endchoice
+
+config PADDR_BITS
+   int
+   default 32 if ARM_PA_BITS_32
+   default 40 if ARM_PA_BITS_40
+   default 48 if ARM_PA_BITS_48 || ARM_64
+
 config ARCH_DEFCONFIG
string
default "arch/arm/configs/arm32_defconfig" if ARM_32
default "arch/arm/configs/arm64_defconfig" if ARM_64
 
-menu "Architecture Features"
-
 source "arch/Kconfig"
 
 config ACPI
diff --git a/xen/arch/arm/include/asm/page-bits.h 
b/xen/arch/arm/include/asm/page-bits.h
index 5d6477e599..deb381ceeb 100644
--- a/xen/arch/arm/include/asm/page-bits.h
+++ b/xen/arch/arm/include/asm/page-bits.h
@@ -3,10 +3,6 @@
 
 #define PAGE_SHIFT  12
 
-#ifdef CONFIG_ARM_64
-#define PADDR_BITS  48
-#else
-#define PADDR_BITS  40
-#endif
+#define PADDR_BITS  CONFIG_PADDR_BITS
 
 #endif /* __ARM_PAGE_SHIFT_H__ */
diff --git a/xen/arch/arm/include/asm/types.h b/xen/arch/arm/include/asm/types.h
index e218ed77bd..e3cfbbb060 100644
--- a/xen/arch/arm/include/asm/types.h
+++ b/xen/arch/arm/include/asm/types.h
@@ -34,9 +34,15 @@ typedef signed long long s64;
 typedef unsigned long long u64;
 typedef u32 vaddr_t;
 #define PRIvaddr PRIx32
+#if defined(CONFIG_PHYS_ADDR_T_32)
+typedef unsigned long paddr_t;
+#define INVALID_PADDR (~0UL)
+#define PRIpaddr "08lx"
+#else
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+#endif
 typedef u32 register_t;
 #define PRIregister "08x"
 #elif defined (CONFIG_ARM_64)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b99806af99..d8b43ef38c 100644
--- 

[XEN v4 06/11] xen/arm: smmu: Use writeq_relaxed_non_atomic() for writing to SMMU_CBn_TTBR0

[Ayan Kumar Halder]

Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9,
SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use
writeq_relaxed_non_atomic() to write to it instead of invoking
writel_relaxed() twice for lower half and upper half of the register.

This also helps us as p2maddr is 'paddr_t' (which may be u32 in future).
Thus, one can assign p2maddr to a 64 bit register and do the bit
manipulations on it, to generate the value for SMMU_CBn_TTBR0.

Reviewed-by: Stefano Stabellini 
Signed-off-by: Ayan Kumar Halder 
---
Changes from -

v1 - 1. Extracted the patch from "[XEN v1 8/9] xen/arm: Other adaptations 
required to support 32bit paddr".
Use writeq_relaxed_non_atomic() to write u64 register in a non-atomic
fashion.

v2 - 1. Added R-b.

v3 - 1. No changes.

 xen/drivers/passthrough/arm/smmu.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 79281075ba..c8ef2a925f 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -499,8 +499,7 @@ enum arm_smmu_s2cr_privcfg {
 #define ARM_SMMU_CB_SCTLR  0x0
 #define ARM_SMMU_CB_RESUME 0x8
 #define ARM_SMMU_CB_TTBCR2 0x10
-#define ARM_SMMU_CB_TTBR0_LO   0x20
-#define ARM_SMMU_CB_TTBR0_HI   0x24
+#define ARM_SMMU_CB_TTBR0  0x20
 #define ARM_SMMU_CB_TTBCR  0x30
 #define ARM_SMMU_CB_S1_MAIR0   0x38
 #define ARM_SMMU_CB_FSR0x58
@@ -1083,6 +1082,7 @@ static void arm_smmu_flush_pgtable(struct arm_smmu_device 
*smmu, void *addr,
 static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 {
u32 reg;
+   u64 reg64;
bool stage1;
struct arm_smmu_cfg *cfg = _domain->cfg;
struct arm_smmu_device *smmu = smmu_domain->smmu;
@@ -1177,12 +1177,13 @@ static void arm_smmu_init_context_bank(struct 
arm_smmu_domain *smmu_domain)
dev_notice(smmu->dev, "d%u: p2maddr 0x%"PRIpaddr"\n",
   smmu_domain->cfg.domain->domain_id, p2maddr);
 
-   reg = (p2maddr & ((1ULL << 32) - 1));
-   writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
-   reg = (p2maddr >> 32);
+   reg64 = p2maddr;
+
if (stage1)
-   reg |= ARM_SMMU_CB_ASID(cfg) << TTBRn_HI_ASID_SHIFT;
-   writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
+   reg64 |= (((uint64_t) (ARM_SMMU_CB_ASID(cfg) << 
TTBRn_HI_ASID_SHIFT))
+<< 32);
+
+   writeq_relaxed_non_atomic(reg64, cb_base + ARM_SMMU_CB_TTBR0);
 
/*
 * TTBCR
-- 
2.17.1

Re: [PATCH v4] acpi/processor: fix evaluating _PDC method when running as Xen dom0

[Rafael J. Wysocki]

On Tue, Mar 21, 2023 at 3:02 PM Roger Pau Monné  wrote:
>
> On Tue, Mar 21, 2023 at 02:47:46PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Mar 16, 2023 at 5:43 PM Roger Pau Monne  
> > wrote:
> > >
> > > In ACPI systems, the OS can direct power management, as opposed to the
> > > firmware.  This OS-directed Power Management is called OSPM.  Part of
> > > telling the firmware that the OS going to direct power management is
> > > making ACPI "_PDC" (Processor Driver Capabilities) calls.  These _PDC
> > > methods must be evaluated for every processor object.  If these _PDC
> > > calls are not completed for every processor it can lead to
> > > inconsistency and later failures in things like the CPU frequency
> > > driver.
> > >
> > > In a Xen system, the dom0 kernel is responsible for system-wide power
> > > management.  The dom0 kernel is in charge of OSPM.  However, the
> > > number of CPUs available to dom0 can be different than the number of
> > > CPUs physically present on the system.
> > >
> > > This leads to a problem: the dom0 kernel needs to evaluate _PDC for
> > > all the processors, but it can't always see them.
> > >
> > > In dom0 kernels, ignore the existing ACPI method for determining if a
> > > processor is physically present because it might not be accurate.
> > > Instead, ask the hypervisor for this information.
> > >
> > > Fix this by introducing a custom function to use when running as Xen
> > > dom0 in order to check whether a processor object matches a CPU that's
> > > online.  Such checking is done using the existing information fetched
> > > by the Xen pCPU subsystem, extending it to also store the ACPI ID.
> > >
> > > This ensures that _PDC method gets evaluated for all physically online
> > > CPUs, regardless of the number of CPUs made available to dom0.
> > >
> > > Fixes: 5d554a7bb064 ('ACPI: processor: add internal 
> > > processor_physically_present()')
> > > Signed-off-by: Roger Pau Monné 
> > > ---
> > > Changes since v3:
> > >  - Protect xen_processor_present() definition with CONFIG_ACPI.
> > >
> > > Changes since v2:
> > >  - Extend and use the existing pcpu functionality.
> > >
> > > Changes since v1:
> > >  - Reword commit message.
> > > ---
> > >  arch/x86/include/asm/xen/hypervisor.h | 10 ++
> > >  drivers/acpi/processor_pdc.c  | 11 +++
> > >  drivers/xen/pcpu.c| 21 +
> > >  3 files changed, 42 insertions(+)
> > >
> > > diff --git a/arch/x86/include/asm/xen/hypervisor.h 
> > > b/arch/x86/include/asm/xen/hypervisor.h
> > > index 5fc35f889cd1..990a1609677e 100644
> > > --- a/arch/x86/include/asm/xen/hypervisor.h
> > > +++ b/arch/x86/include/asm/xen/hypervisor.h
> > > @@ -63,4 +63,14 @@ void __init xen_pvh_init(struct boot_params 
> > > *boot_params);
> > >  void __init mem_map_via_hcall(struct boot_params *boot_params_p);
> > >  #endif
> > >
> > > +#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI)
> > > +bool __init xen_processor_present(uint32_t acpi_id);
> > > +#else
> > > +static inline bool xen_processor_present(uint32_t acpi_id)
> > > +{
> > > +   BUG();
> > > +   return false;
> > > +}
> > > +#endif
> > > +
> > >  #endif /* _ASM_X86_XEN_HYPERVISOR_H */
> > > diff --git a/drivers/acpi/processor_pdc.c b/drivers/acpi/processor_pdc.c
> > > index 8c3f82c9fff3..18fb04523f93 100644
> > > --- a/drivers/acpi/processor_pdc.c
> > > +++ b/drivers/acpi/processor_pdc.c
> > > @@ -14,6 +14,8 @@
> > >  #include 
> > >  #include 
> > >
> > > +#include 
> >
> > This along with the definition above is evidently insufficient for
> > xen_processor_present() to always be defined.  See
> > https://lore.kernel.org/linux-acpi/64198b60.bo+m9o5w+hd8hcf3%25...@intel.com/T/#u
> > for example.
> >
> > I'm dropping the patch now, please fix and resend.
>
> Hello,
>
> Sorry.  I've sent a followup fix:
>
> https://lore.kernel.org/xen-devel/20230321112522.46806-1-roger@citrix.com/T/#u
>
> Would you be fine with taking such followup, or would rather prefer
> for me to send the original fixed patch as v5?

Please fold the fix into the original patch and resend.

[XEN v4 04/11] xen/drivers: ns16550: Use paddr_t for io_base/io_size

[Ayan Kumar Halder]

io_base and io_size represent physical addresses. So they should use
paddr_t (instead of u64).

However in future, paddr_t may be defined as u32. So when typecasting
values from u64 to paddr_t, one should always check for any possible
truncation. If any truncation is discovered, Xen needs to return an
appropriate an error message for this.

Also moved the definition of PARSE_ERR_RET before its first usage.

Signed-off-by: Ayan Kumar Halder 
---
Changes from -
v1 - NA

v2 - 1. Extracted the patch from "[XEN v2 05/11] xen/arm: Use paddr_t instead 
of u64 for address/size"
into a separate patch of its own.

v3 - 1. Reduced the scope of pci_uart_io_base and uart_io_base definitions.
2. Instead of crashing, invoke PARSE_ERR_RET().
3. Moved PARSE_ERR_RET() so that it is defined before its first use.

 xen/drivers/char/ns16550.c | 41 ++
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 092f6b9c4b..2e8a9cfb24 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -42,8 +42,8 @@
 
 static struct ns16550 {
 int baud, clock_hz, data_bits, parity, stop_bits, fifo_size, irq;
-u64 io_base;   /* I/O port or memory-mapped I/O address. */
-u64 io_size;
+paddr_t io_base;   /* I/O port or memory-mapped I/O address. */
+paddr_t io_size;
 int reg_shift; /* Bits to shift register offset by */
 int reg_width; /* Size of access to use, the registers
 * themselves are still bytes */
@@ -1163,10 +1163,16 @@ static const struct ns16550_config __initconst 
uart_config[] =
 },
 };
 
+#define PARSE_ERR_RET(_f, _a...) \
+do { \
+printk( "ERROR: " _f "\n" , ## _a ); \
+return false;\
+} while ( 0 )
+
 static int __init
 pci_uart_config(struct ns16550 *uart, bool_t skip_amt, unsigned int idx)
 {
-u64 orig_base = uart->io_base;
+paddr_t orig_base = uart->io_base;
 unsigned int b, d, f, nextf, i;
 
 /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus 0. */
@@ -1235,6 +1241,8 @@ pci_uart_config(struct ns16550 *uart, bool_t skip_amt, 
unsigned int idx)
 /* MMIO based */
 if ( param->mmio && !(bar & PCI_BASE_ADDRESS_SPACE_IO) )
 {
+uint64_t pci_uart_io_base;
+
 pci_conf_write32(PCI_SBDF(0, b, d, f),
  PCI_BASE_ADDRESS_0 + bar_idx*4, ~0u);
 len = pci_conf_read32(PCI_SBDF(0, b, d, f),
@@ -1259,8 +1267,14 @@ pci_uart_config(struct ns16550 *uart, bool_t skip_amt, 
unsigned int idx)
 else
 size = len & PCI_BASE_ADDRESS_MEM_MASK;
 
-uart->io_base = ((u64)bar_64 << 32) |
-(bar & PCI_BASE_ADDRESS_MEM_MASK);
+pci_uart_io_base = ((u64)bar_64 << 32) |
+(bar & PCI_BASE_ADDRESS_MEM_MASK);
+
+/* Truncation detected while converting to paddr_t */
+if ( (pci_uart_io_base >> (PADDR_BITS - 1)) > 1 )
+PARSE_ERR_RET("Truncation detected for io_base 
address");
+
+uart->io_base = pci_uart_io_base;
 }
 /* IO based */
 else if ( !param->mmio && (bar & PCI_BASE_ADDRESS_SPACE_IO) )
@@ -1456,13 +1470,6 @@ static enum __init serial_param_type get_token(char 
*token, char **value)
 return;  \
 } while ( 0 )
 
-#define PARSE_ERR_RET(_f, _a...) \
-do { \
-printk( "ERROR: " _f "\n" , ## _a ); \
-return false;\
-} while ( 0 )
-
-
 static bool __init parse_positional(struct ns16550 *uart, char **str)
 {
 int baud;
@@ -1532,7 +1539,15 @@ static bool __init parse_positional(struct ns16550 
*uart, char **str)
 else
 #endif
 {
-uart->io_base = simple_strtoull(conf, , 0);
+uint64_t uart_io_base;
+
+uart_io_base = simple_strtoull(conf, , 0);
+
+/* Truncation detected while converting to paddr_t */
+if ( (uart_io_base >> (PADDR_BITS - 1)) > 1 )
+PARSE_ERR_RET("Truncation detected for uart_io_base address");
+
+uart->io_base = uart_io_base;
 }
 }
 
-- 
2.17.1

[XEN v4 03/11] xen/arm: Typecast the DT values into paddr_t

[Ayan Kumar Halder]

In future, we wish to support 32 bit physical address.
However, the current dt and fdt functions can only read u64 values.
We wish to make the DT functions read 32bit as well 64bit values
(depending on the width of physical address). Also, we wish to detect
if any truncation has occurred (ie while reading 32bit physical
addresses from 64bit values read from DT).

device_tree_get_reg() should now be able to return paddr_t. This is
invoked by various callers to get DT address and size.

For fdt_get_mem_rsv(), we have introduced wrapper ie
fdt_get_mem_rsv_paddr() while will invoke fdt_get_mem_rsv() and
translate uint64_t to paddr_t. The reason being we cannot modify
fdt_get_mem_rsv() as it has been imported from external source.

For dt_read_number(), we have also introduced a wrapper ie
dt_read_paddr() to read physical addresses. We chose not to modify the
original function as it been used in places where it needs to
specifically 64bit values from dt (For eg dt_property_read_u64()).

Xen prints an error when it detects a truncation (during typecast
between uint64_t and paddr_t). It is not possible to return an error in
all scenarios. So, it is user's responsibility to check the error logs.

Also, replaced u32/u64 with uint32_t/uint64_t in the functions touched
by the code changes.

Signed-off-by: Ayan Kumar Halder 
---

Changes from

v1 - 1. Dropped "[XEN v1 2/9] xen/arm: Define translate_dt_address_size() for 
the translation between u64 and paddr_t" and
"[XEN v1 4/9] xen/arm: Use translate_dt_address_size() to translate between 
device tree addr/size and paddr_t", instead
this approach achieves the same purpose.

2. No need to check for truncation while converting values from u64 to paddr_t.

v2 - 1. Use "( (dt_start >> (PADDR_SHIFT - 1)) > 1 )" to detect truncation.
2. Introduced libfdt_xen.h to implement fdt_get_mem_rsv_paddr
3. Logged error messages in case truncation is detected.

v3 - 1. Renamed libfdt_xen.h to libfdt-xen.h.
2. Replaced u32/u64 with uint32_t/uint64_t
3. Use "(paddr_t)val != val" to check for truncation.
4. Removed the alias "#define PADDR_SHIFT PADDR_BITS". 

 xen/arch/arm/bootfdt.c  | 41 ++-
 xen/arch/arm/domain_build.c |  2 +-
 xen/arch/arm/include/asm/setup.h|  4 +--
 xen/arch/arm/setup.c| 14 
 xen/arch/arm/smpboot.c  |  2 +-
 xen/include/xen/device_tree.h   | 21 
 xen/include/xen/libfdt/libfdt-xen.h | 52 +
 7 files changed, 116 insertions(+), 20 deletions(-)
 create mode 100644 xen/include/xen/libfdt/libfdt-xen.h

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 0085c28d74..33bef1c15e 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -52,11 +52,32 @@ static bool __init device_tree_node_compatible(const void 
*fdt, int node,
 return false;
 }
 
-void __init device_tree_get_reg(const __be32 **cell, u32 address_cells,
-u32 size_cells, u64 *start, u64 *size)
+void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
+uint32_t size_cells, paddr_t *start,
+paddr_t *size)
 {
-*start = dt_next_cell(address_cells, cell);
-*size = dt_next_cell(size_cells, cell);
+uint64_t dt_start, dt_size;
+
+/*
+ * dt_next_cell will return u64 whereas paddr_t may be u64 or u32. Thus,
+ * there is an implicit cast from u64 to paddr_t.
+ */
+dt_start = dt_next_cell(address_cells, cell);
+dt_size = dt_next_cell(size_cells, cell);
+
+if ( dt_start != (paddr_t)dt_start  )
+printk("Error: Physical address greater than max width supported\n");
+
+if ( dt_size != (paddr_t)dt_size )
+printk("Error: Physical size greater than max width supported\n");
+
+/*
+ * Note: It is user's responsibility to check for the error messages.
+ * Xen will sliently truncate in case if the address/size is greater than
+ * the max supported width.
+ */
+*start = dt_start;
+*size = dt_size;
 }
 
 static int __init device_tree_get_meminfo(const void *fdt, int node,
@@ -326,7 +347,7 @@ static int __init process_chosen_node(const void *fdt, int 
node,
 printk("linux,initrd-start property has invalid length %d\n", len);
 return -EINVAL;
 }
-start = dt_read_number((void *)>data, dt_size_to_cells(len));
+start = dt_read_paddr((void *)>data, dt_size_to_cells(len));
 
 prop = fdt_get_property(fdt, node, "linux,initrd-end", );
 if ( !prop )
@@ -339,7 +360,7 @@ static int __init process_chosen_node(const void *fdt, int 
node,
 printk("linux,initrd-end property has invalid length %d\n", len);
 return -EINVAL;
 }
-end = dt_read_number((void *)>data, dt_size_to_cells(len));
+end = dt_read_paddr((void *)>data, 

[XEN v4 02/11] xen/arm: domain_build: Track unallocated pages using the frame number

[Ayan Kumar Halder]

rangeset_{xxx}_range() functions are invoked with 'start' and 'size' as
arguments which are either 'uint64_t' or 'paddr_t'. However, the function
accepts 'unsigned long' for 'start' and 'size'. 'unsigned long' is 32 bits for
ARM_32. Thus, there is an implicit downcasting from 'uint64_t'/'paddr_t' to
'unsigned long' when invoking rangeset_{xxx}_range().

So, it may seem there is a possibility of lose of data due to truncation.

In reality, 'start' and 'size' are always page aligned. And ARM_32 currently
supports 40 bits as the width of physical address.
So if the addresses are page aligned, the last 12 bits contain zeroes.
Thus, we could instead pass page frame number which will contain 28 bits (40-12
on Arm_32) and this can be represented using 'unsigned long'.

On Arm_64, this change will not induce any adverse side effect as the width of
physical address is 48 bits. Thus, the width of 'mfn' (ie 48 - 12 = 36) can be
represented using 'unsigned long' (which is 64 bits wide).

Signed-off-by: Ayan Kumar Halder 
---
Changes from -

v3 - 1. Extracted the patch from 
https://lists.xenproject.org/archives/html/xen-devel/2023-02/msg00657.html
and added it to this series.
2. Modified add_ext_regions(). This accepts a frame number instead of physical
address.

 xen/arch/arm/domain_build.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 15fa88e977..24b12b7512 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1500,10 +1500,13 @@ static int __init make_resv_memory_node(const struct 
domain *d,
 return res;
 }
 
-static int __init add_ext_regions(unsigned long s, unsigned long e, void *data)
+static int __init add_ext_regions(unsigned long s_pfn, unsigned long e_pfn,
+  void *data)
 {
 struct meminfo *ext_regions = data;
 paddr_t start, size;
+paddr_t s = PFN_UP(s_pfn);
+paddr_t e = PFN_UP(e_pfn);
 
 if ( ext_regions->nr_banks >= ARRAY_SIZE(ext_regions->bank) )
 return 0;
@@ -1566,7 +1569,8 @@ static int __init find_unallocated_memory(const struct 
kernel_info *kinfo,
 {
 start = bootinfo.mem.bank[i].start;
 end = bootinfo.mem.bank[i].start + bootinfo.mem.bank[i].size;
-res = rangeset_add_range(unalloc_mem, start, end - 1);
+res = rangeset_add_range(unalloc_mem, PFN_DOWN(start),
+ PFN_DOWN(end - 1));
 if ( res )
 {
 printk(XENLOG_ERR "Failed to add: %#"PRIpaddr"->%#"PRIpaddr"\n",
@@ -1580,7 +1584,8 @@ static int __init find_unallocated_memory(const struct 
kernel_info *kinfo,
 {
 start = assign_mem->bank[i].start;
 end = assign_mem->bank[i].start + assign_mem->bank[i].size;
-res = rangeset_remove_range(unalloc_mem, start, end - 1);
+res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
+PFN_DOWN(end - 1));
 if ( res )
 {
 printk(XENLOG_ERR "Failed to remove: %#"PRIpaddr"->%#"PRIpaddr"\n",
@@ -1595,7 +1600,8 @@ static int __init find_unallocated_memory(const struct 
kernel_info *kinfo,
 start = bootinfo.reserved_mem.bank[i].start;
 end = bootinfo.reserved_mem.bank[i].start +
 bootinfo.reserved_mem.bank[i].size;
-res = rangeset_remove_range(unalloc_mem, start, end - 1);
+res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start),
+PFN_DOWN(end - 1));
 if ( res )
 {
 printk(XENLOG_ERR "Failed to remove: %#"PRIpaddr"->%#"PRIpaddr"\n",
@@ -1607,7 +1613,7 @@ static int __init find_unallocated_memory(const struct 
kernel_info *kinfo,
 /* Remove grant table region */
 start = kinfo->gnttab_start;
 end = kinfo->gnttab_start + kinfo->gnttab_size;
-res = rangeset_remove_range(unalloc_mem, start, end - 1);
+res = rangeset_remove_range(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end - 
1));
 if ( res )
 {
 printk(XENLOG_ERR "Failed to remove: %#"PRIpaddr"->%#"PRIpaddr"\n",
@@ -1617,7 +1623,7 @@ static int __init find_unallocated_memory(const struct 
kernel_info *kinfo,
 
 start = 0;
 end = (1ULL << p2m_ipa_bits) - 1;
-res = rangeset_report_ranges(unalloc_mem, start, end,
+res = rangeset_report_ranges(unalloc_mem, PFN_DOWN(start), PFN_DOWN(end),
  add_ext_regions, ext_regions);
 if ( res )
 ext_regions->nr_banks = 0;
@@ -1639,7 +1645,7 @@ static int __init handle_pci_range(const struct 
dt_device_node *dev,
 
 start = addr & PAGE_MASK;
 end = PAGE_ALIGN(addr + len);
-res = rangeset_remove_range(mem_holes, start, end - 1);
+res = rangeset_remove_range(mem_holes, PFN_DOWN(start), PFN_DOWN(end - 1));
 if ( res )
 {
 printk(XENLOG_ERR "Failed to remove: %#"PRIpaddr"->%#"PRIpaddr"\n",
@@ -1677,7 +1683,7 @@ static 

[XEN v4 01/11] xen/arm: Use the correct format specifier

[Ayan Kumar Halder]

1. One should use 'PRIpaddr' to display 'paddr_t' variables. However,
while creating nodes in fdt, the address (if present in the node name)
should be represented using 'PRIx64'. This is to be in conformance
with the following rule present in https://elinux.org/Device_Tree_Linux

. node names
"unit-address does not have leading zeros"

As 'PRIpaddr' introduces leading zeros, we cannot use it.

So, we have introduced a wrapper ie domain_fdt_begin_node() which will
represent physical address using 'PRIx64'.

2. One should use 'PRIx64' to display 'u64' in hex format. The current
use of 'PRIpaddr' for printing PTE is buggy as this is not a physical
address.

Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Stefano Stabellini 
Acked-by: Julien Grall 
---

Changes from -

v3 - 1. Extracted the patch from 
https://lists.xenproject.org/archives/html/xen-devel/2023-02/msg00655.html
and added to this series.
2. No changes done.

 xen/arch/arm/domain_build.c | 64 +++--
 xen/arch/arm/gic-v2.c   |  6 ++--
 xen/arch/arm/mm.c   |  2 +-
 3 files changed, 44 insertions(+), 28 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9707eb7b1b..15fa88e977 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1288,6 +1288,39 @@ static int __init fdt_property_interrupts(const struct 
kernel_info *kinfo,
 return res;
 }
 
+/*
+ * Wrapper to convert physical address from paddr_t to uint64_t and
+ * invoke fdt_begin_node(). This is required as the physical address
+ * provided as part of node name should not contain any leading
+ * zeroes. Thus, one should use PRIx64 (instead of PRIpaddr) to append
+ * unit (which contains the physical address) with name to generate a
+ * node name.
+ */
+static int __init domain_fdt_begin_node(void *fdt, const char *name,
+uint64_t unit)
+{
+/*
+ * The size of the buffer to hold the longest possible string (i.e.
+ * interrupt-controller@ + a 64-bit number + \0).
+ */
+char buf[38];
+int ret;
+
+/* ePAPR 3.4 */
+ret = snprintf(buf, sizeof(buf), "%s@%"PRIx64, name, unit);
+
+if ( ret >= sizeof(buf) )
+{
+printk(XENLOG_ERR
+   "Insufficient buffer. Minimum size required is %d\n",
+   (ret + 1));
+
+return -FDT_ERR_TRUNCATED;
+}
+
+return fdt_begin_node(fdt, buf);
+}
+
 static int __init make_memory_node(const struct domain *d,
void *fdt,
int addrcells, int sizecells,
@@ -1296,8 +1329,6 @@ static int __init make_memory_node(const struct domain *d,
 unsigned int i;
 int res, reg_size = addrcells + sizecells;
 int nr_cells = 0;
-/* Placeholder for memory@ + a 64-bit number + \0 */
-char buf[24];
 __be32 reg[NR_MEM_BANKS * 4 /* Worst case addrcells + sizecells */];
 __be32 *cells;
 
@@ -1314,9 +1345,7 @@ static int __init make_memory_node(const struct domain *d,
 
 dt_dprintk("Create memory node\n");
 
-/* ePAPR 3.4 */
-snprintf(buf, sizeof(buf), "memory@%"PRIx64, mem->bank[i].start);
-res = fdt_begin_node(fdt, buf);
+res = domain_fdt_begin_node(fdt, "memory", mem->bank[i].start);
 if ( res )
 return res;
 
@@ -1375,16 +1404,13 @@ static int __init make_shm_memory_node(const struct 
domain *d,
 {
 uint64_t start = mem->bank[i].start;
 uint64_t size = mem->bank[i].size;
-/* Placeholder for xen-shmem@ + a 64-bit number + \0 */
-char buf[27];
 const char compat[] = "xen,shared-memory-v1";
 /* Worst case addrcells + sizecells */
 __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
 __be32 *cells;
 unsigned int len = (addrcells + sizecells) * sizeof(__be32);
 
-snprintf(buf, sizeof(buf), "xen-shmem@%"PRIx64, mem->bank[i].start);
-res = fdt_begin_node(fdt, buf);
+res = domain_fdt_begin_node(fdt, "xen-shmem", mem->bank[i].start);
 if ( res )
 return res;
 
@@ -2716,12 +2742,9 @@ static int __init make_gicv2_domU_node(struct 
kernel_info *kinfo)
 __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
 __be32 *cells;
 const struct domain *d = kinfo->d;
-/* Placeholder for interrupt-controller@ + a 64-bit number + \0 */
-char buf[38];
 
-snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIx64,
- vgic_dist_base(>arch.vgic));
-res = fdt_begin_node(fdt, buf);
+res = domain_fdt_begin_node(fdt, "interrupt-controller",
+vgic_dist_base(>arch.vgic));
 if ( res )
 return res;
 
@@ -2771,14 +2794,10 @@ static int __init make_gicv3_domU_node(struct 
kernel_info *kinfo)
 int res = 0;
 __be32 *reg, *cells;
 const struct domain *d = kinfo->d;
-/* Placeholder for interrupt-controller@ + a 64-bit number + \0 */
-char 

[XEN v4 00/11] Add support for 32 bit physical address

[Ayan Kumar Halder]

Hi All,

Please have a look at 
https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html
for the context.

The benefits of using 32 bit physical addresses are as follows :-

1. It helps to use Xen on platforms (for eg R52) which supports 32 bit
physical addresses and has no support for large physical address extension.
On 32 bit MPU systems which supports flat-mapping (for eg R52), it helps
to translate 32 bit VA into 32 bit PA.

2. It also helps in code optimization when the underlying platform does not
use large physical address extension.

The current patch serie depends on :-
"[XEN v5] xen/arm: Use the correct format specifier"
https://lists.xenproject.org/archives/html/xen-devel/2023-01/msg01896.html
I did not send out the patch again as it has already been reviewed and acked and
is waiting to be committed to staging.

The following points are to be noted :-
1. Device tree always use u64 for address and size. The caller needs to
translate between u64 and u32 (when 32 bit physical addressing is used).
2. Currently, we have enabled this option for Arm_32 as the MMU for Arm_64
uses 48 bit physical addressing.
3. https://lists.xenproject.org/archives/html/xen-devel/2022-12/msg00117.html
has been added to this series.

Changes from :

v1 - 1. Reordered the patches such that the first three patches fixes issues in
the existing codebase. These can be applied independent of the remaining patches
in this serie,

2. Dropped translate_dt_address_size() for the address/size translation between
paddr_t and u64 (as parsed from the device tree). Also, dropped the check for
truncation (while converting u64 to paddr_t).
Instead now we have modified device_tree_get_reg() and typecasted the return for
dt_read_number(), to obtain paddr_t. Also, introduced wrappers for
fdt_get_mem_rsv() and dt_device_get_address() for the same purpose. These can be
found in patch 4/11 and patch 6/11.

3. Split "Other adaptations required to support 32bit paddr" into the following
individual patches for each adaptation :
  xen/arm: smmu: Use writeq_relaxed_non_atomic() for writing to
SMMU_CBn_TTBR0
  xen/arm: guest_walk: LPAE specific bits should be enclosed within
"ifndef CONFIG_ARM_PA_32"

4. Introduced "xen/arm: p2m: Enable support for 32bit IPA".

v2 - 1. Dropped patches 1/11, 2/11 and 3/11 from the v2 as it has already been
committed (except 2/11 - "[XEN v5] xen/arm: Use the correct format specifier"
which is waiting to be committed).

2. Introduced a new patch "xen/drivers: ns16550: Use paddr_t for 
io_base/io_size".

v3 - 1. Combined the patches from 
https://lists.xenproject.org/archives/html/xen-devel/2023-02/msg00656.html in 
this series.

Ayan Kumar Halder (11):
  xen/arm: Use the correct format specifier
  xen/arm: domain_build: Track unallocated pages using the frame number
  xen/arm: Typecast the DT values into paddr_t
  xen/drivers: ns16550: Use paddr_t for io_base/io_size
  xen/arm: Introduce a wrapper for dt_device_get_address() to handle
paddr_t
  xen/arm: smmu: Use writeq_relaxed_non_atomic() for writing to
SMMU_CBn_TTBR0
  xen/arm: Introduce choice to enable 64/32 bit physical addressing
  xen/arm: guest_walk: LPAE specific bits should be enclosed within
"ifndef CONFIG_PHYS_ADDR_T_32"
  xen/arm: Restrict zeroeth_table_offset for ARM_64
  xen/arm: p2m: Use the pa_range_info table to support Arm_32 and Arm_64
  xen/arm: p2m: Enable support for 32bit IPA for ARM_32

 xen/arch/Kconfig   |   6 ++
 xen/arch/arm/Kconfig   |  40 +++-
 xen/arch/arm/bootfdt.c |  41 ++--
 xen/arch/arm/domain_build.c| 103 +
 xen/arch/arm/gic-v2.c  |  16 ++--
 xen/arch/arm/gic-v3-its.c  |   4 +-
 xen/arch/arm/gic-v3.c  |  10 +-
 xen/arch/arm/guest_walk.c  |   2 +
 xen/arch/arm/include/asm/lpae.h|   4 +
 xen/arch/arm/include/asm/page-bits.h   |   6 +-
 xen/arch/arm/include/asm/setup.h   |   4 +-
 xen/arch/arm/include/asm/types.h   |   6 ++
 xen/arch/arm/mm.c  |  10 +-
 xen/arch/arm/p2m.c |  29 +++---
 xen/arch/arm/pci/pci-host-common.c |   6 +-
 xen/arch/arm/platforms/brcm-raspberry-pi.c |   2 +-
 xen/arch/arm/platforms/brcm.c  |   4 +-
 xen/arch/arm/platforms/exynos5.c   |  32 +++
 xen/arch/arm/platforms/sunxi.c |   2 +-
 xen/arch/arm/platforms/xgene-storm.c   |   2 +-
 xen/arch/arm/setup.c   |  14 +--
 xen/arch/arm/smpboot.c |   2 +-
 xen/common/device_tree.c   |  40 +++-
 xen/drivers/char/cadence-uart.c|   4 +-
 xen/drivers/char/exynos4210-uart.c |   4 +-
 xen/drivers/char/imx-lpuart.c  |   4 +-
 xen/drivers/char/meson-uart.c  |   4 +-
 xen/drivers/char/mvebu-uart.c  |   4 +-
 

Re: [PATCH v4] acpi/processor: fix evaluating _PDC method when running as Xen dom0

[Roger Pau Monné]

On Tue, Mar 21, 2023 at 02:47:46PM +0100, Rafael J. Wysocki wrote:
> On Thu, Mar 16, 2023 at 5:43 PM Roger Pau Monne  wrote:
> >
> > In ACPI systems, the OS can direct power management, as opposed to the
> > firmware.  This OS-directed Power Management is called OSPM.  Part of
> > telling the firmware that the OS going to direct power management is
> > making ACPI "_PDC" (Processor Driver Capabilities) calls.  These _PDC
> > methods must be evaluated for every processor object.  If these _PDC
> > calls are not completed for every processor it can lead to
> > inconsistency and later failures in things like the CPU frequency
> > driver.
> >
> > In a Xen system, the dom0 kernel is responsible for system-wide power
> > management.  The dom0 kernel is in charge of OSPM.  However, the
> > number of CPUs available to dom0 can be different than the number of
> > CPUs physically present on the system.
> >
> > This leads to a problem: the dom0 kernel needs to evaluate _PDC for
> > all the processors, but it can't always see them.
> >
> > In dom0 kernels, ignore the existing ACPI method for determining if a
> > processor is physically present because it might not be accurate.
> > Instead, ask the hypervisor for this information.
> >
> > Fix this by introducing a custom function to use when running as Xen
> > dom0 in order to check whether a processor object matches a CPU that's
> > online.  Such checking is done using the existing information fetched
> > by the Xen pCPU subsystem, extending it to also store the ACPI ID.
> >
> > This ensures that _PDC method gets evaluated for all physically online
> > CPUs, regardless of the number of CPUs made available to dom0.
> >
> > Fixes: 5d554a7bb064 ('ACPI: processor: add internal 
> > processor_physically_present()')
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Changes since v3:
> >  - Protect xen_processor_present() definition with CONFIG_ACPI.
> >
> > Changes since v2:
> >  - Extend and use the existing pcpu functionality.
> >
> > Changes since v1:
> >  - Reword commit message.
> > ---
> >  arch/x86/include/asm/xen/hypervisor.h | 10 ++
> >  drivers/acpi/processor_pdc.c  | 11 +++
> >  drivers/xen/pcpu.c| 21 +
> >  3 files changed, 42 insertions(+)
> >
> > diff --git a/arch/x86/include/asm/xen/hypervisor.h 
> > b/arch/x86/include/asm/xen/hypervisor.h
> > index 5fc35f889cd1..990a1609677e 100644
> > --- a/arch/x86/include/asm/xen/hypervisor.h
> > +++ b/arch/x86/include/asm/xen/hypervisor.h
> > @@ -63,4 +63,14 @@ void __init xen_pvh_init(struct boot_params 
> > *boot_params);
> >  void __init mem_map_via_hcall(struct boot_params *boot_params_p);
> >  #endif
> >
> > +#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI)
> > +bool __init xen_processor_present(uint32_t acpi_id);
> > +#else
> > +static inline bool xen_processor_present(uint32_t acpi_id)
> > +{
> > +   BUG();
> > +   return false;
> > +}
> > +#endif
> > +
> >  #endif /* _ASM_X86_XEN_HYPERVISOR_H */
> > diff --git a/drivers/acpi/processor_pdc.c b/drivers/acpi/processor_pdc.c
> > index 8c3f82c9fff3..18fb04523f93 100644
> > --- a/drivers/acpi/processor_pdc.c
> > +++ b/drivers/acpi/processor_pdc.c
> > @@ -14,6 +14,8 @@
> >  #include 
> >  #include 
> >
> > +#include 
> 
> This along with the definition above is evidently insufficient for
> xen_processor_present() to always be defined.  See
> https://lore.kernel.org/linux-acpi/64198b60.bo+m9o5w+hd8hcf3%25...@intel.com/T/#u
> for example.
> 
> I'm dropping the patch now, please fix and resend.

Hello,

Sorry.  I've sent a followup fix:

https://lore.kernel.org/xen-devel/20230321112522.46806-1-roger@citrix.com/T/#u

Would you be fine with taking such followup, or would rather prefer
for me to send the original fixed patch as v5?

Thanks, Roger.

[XEN PATCH v5] x86/monitor: Add new monitor event to catch I/O instructions

[Dmitry Isaykin]

Adds monitor support for I/O instructions.

Signed-off-by: Dmitry Isaykin 
Signed-off-by: Anton Belousov 
---
Changes in v5:
 * Rebase on staging

Changes in v4:
 * Avoid the use of fixed-width types
 * Document vm_event_io structure fields
 * Untie vm-event interface from ioreq one

Changes in v3:
 * Rebase on staging
 * Refactor branch logic on monitor_traps response

Changes in v2:
 * Handled INS and OUTS instructions too
 * Added I/O monitoring support for AMD
 * Rename functions and structures (remove "_instruction" part)
 * Reorder parameters of hvm_monitor_io to match handle_pio's order
 * Change type of string_ins parameter to bool
 * Change vm_event_io structure
 * Handle monitor_traps's return status
---
 tools/include/xenctrl.h|  1 +
 tools/libs/ctrl/xc_monitor.c   | 13 +
 xen/arch/x86/hvm/monitor.c | 21 +
 xen/arch/x86/hvm/svm/svm.c |  9 +
 xen/arch/x86/hvm/vmx/vmx.c |  7 +++
 xen/arch/x86/include/asm/domain.h  |  1 +
 xen/arch/x86/include/asm/hvm/monitor.h |  3 +++
 xen/arch/x86/include/asm/monitor.h |  3 ++-
 xen/arch/x86/monitor.c | 13 +
 xen/include/public/domctl.h|  1 +
 xen/include/public/vm_event.h  | 10 ++
 11 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 23037874d3..05967ecc92 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -2102,6 +2102,7 @@ int xc_monitor_emul_unimplemented(xc_interface *xch, 
uint32_t domain_id,
   bool enable);
 int xc_monitor_vmexit(xc_interface *xch, uint32_t domain_id, bool enable,
   bool sync);
+int xc_monitor_io(xc_interface *xch, uint32_t domain_id, bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libs/ctrl/xc_monitor.c b/tools/libs/ctrl/xc_monitor.c
index c5fa62ff30..3cb96f444f 100644
--- a/tools/libs/ctrl/xc_monitor.c
+++ b/tools/libs/ctrl/xc_monitor.c
@@ -261,6 +261,19 @@ int xc_monitor_vmexit(xc_interface *xch, uint32_t 
domain_id, bool enable,
 return do_domctl(xch, );
 }
 
+int xc_monitor_io(xc_interface *xch, uint32_t domain_id, bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_IO;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index a11cd76f4d..4f500beaf5 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -346,6 +346,27 @@ int hvm_monitor_vmexit(unsigned long exit_reason,
 return monitor_traps(curr, ad->monitor.vmexit_sync, );
 }
 
+int hvm_monitor_io(unsigned int port, unsigned int bytes,
+   bool in, bool str)
+{
+struct vcpu *curr = current;
+struct arch_domain *ad = >domain->arch;
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_IO_INSTRUCTION,
+.u.io.bytes = bytes,
+.u.io.port = port,
+.u.io.in = in,
+.u.io.str = str,
+};
+
+if ( !ad->monitor.io_enabled )
+return 0;
+
+set_npt_base(curr, );
+
+return monitor_traps(curr, true, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index bfe03316de..02563e4b70 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2939,6 +2939,15 @@ void svm_vmexit_handler(void)
 break;
 
 case VMEXIT_IOIO:
+rc = hvm_monitor_io(vmcb->ei.io.port,
+vmcb->ei.io.bytes,
+vmcb->ei.io.in,
+vmcb->ei.io.str);
+if ( rc < 0 )
+goto unexpected_exit_type;
+if ( rc )
+break;
+
 if ( !vmcb->ei.io.str )
 {
 if ( handle_pio(vmcb->ei.io.port,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 78ac9ece6f..bc7d36aa03 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4574,10 +4574,17 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 };
 } io_qual;
 unsigned int bytes;
+int rc;
 
 __vmread(EXIT_QUALIFICATION, _qual.raw);
 bytes = io_qual.size + 1;
 
+rc = hvm_monitor_io(io_qual.port, bytes, io_qual.in, io_qual.str);
+if ( rc < 0 )
+goto exit_and_crash;
+if ( rc )
+break;
+
 if ( io_qual.str )
 {
 if ( !hvm_emulate_one_insn(x86_insn_is_portio, "port I/O") )
diff --git a/xen/arch/x86/include/asm/domain.h 

Re: [PATCH v4] acpi/processor: fix evaluating _PDC method when running as Xen dom0

[Rafael J. Wysocki]

On Thu, Mar 16, 2023 at 5:43 PM Roger Pau Monne  wrote:
>
> In ACPI systems, the OS can direct power management, as opposed to the
> firmware.  This OS-directed Power Management is called OSPM.  Part of
> telling the firmware that the OS going to direct power management is
> making ACPI "_PDC" (Processor Driver Capabilities) calls.  These _PDC
> methods must be evaluated for every processor object.  If these _PDC
> calls are not completed for every processor it can lead to
> inconsistency and later failures in things like the CPU frequency
> driver.
>
> In a Xen system, the dom0 kernel is responsible for system-wide power
> management.  The dom0 kernel is in charge of OSPM.  However, the
> number of CPUs available to dom0 can be different than the number of
> CPUs physically present on the system.
>
> This leads to a problem: the dom0 kernel needs to evaluate _PDC for
> all the processors, but it can't always see them.
>
> In dom0 kernels, ignore the existing ACPI method for determining if a
> processor is physically present because it might not be accurate.
> Instead, ask the hypervisor for this information.
>
> Fix this by introducing a custom function to use when running as Xen
> dom0 in order to check whether a processor object matches a CPU that's
> online.  Such checking is done using the existing information fetched
> by the Xen pCPU subsystem, extending it to also store the ACPI ID.
>
> This ensures that _PDC method gets evaluated for all physically online
> CPUs, regardless of the number of CPUs made available to dom0.
>
> Fixes: 5d554a7bb064 ('ACPI: processor: add internal 
> processor_physically_present()')
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v3:
>  - Protect xen_processor_present() definition with CONFIG_ACPI.
>
> Changes since v2:
>  - Extend and use the existing pcpu functionality.
>
> Changes since v1:
>  - Reword commit message.
> ---
>  arch/x86/include/asm/xen/hypervisor.h | 10 ++
>  drivers/acpi/processor_pdc.c  | 11 +++
>  drivers/xen/pcpu.c| 21 +
>  3 files changed, 42 insertions(+)
>
> diff --git a/arch/x86/include/asm/xen/hypervisor.h 
> b/arch/x86/include/asm/xen/hypervisor.h
> index 5fc35f889cd1..990a1609677e 100644
> --- a/arch/x86/include/asm/xen/hypervisor.h
> +++ b/arch/x86/include/asm/xen/hypervisor.h
> @@ -63,4 +63,14 @@ void __init xen_pvh_init(struct boot_params *boot_params);
>  void __init mem_map_via_hcall(struct boot_params *boot_params_p);
>  #endif
>
> +#if defined(CONFIG_XEN_DOM0) && defined(CONFIG_ACPI)
> +bool __init xen_processor_present(uint32_t acpi_id);
> +#else
> +static inline bool xen_processor_present(uint32_t acpi_id)
> +{
> +   BUG();
> +   return false;
> +}
> +#endif
> +
>  #endif /* _ASM_X86_XEN_HYPERVISOR_H */
> diff --git a/drivers/acpi/processor_pdc.c b/drivers/acpi/processor_pdc.c
> index 8c3f82c9fff3..18fb04523f93 100644
> --- a/drivers/acpi/processor_pdc.c
> +++ b/drivers/acpi/processor_pdc.c
> @@ -14,6 +14,8 @@
>  #include 
>  #include 
>
> +#include 

This along with the definition above is evidently insufficient for
xen_processor_present() to always be defined.  See
https://lore.kernel.org/linux-acpi/64198b60.bo+m9o5w+hd8hcf3%25...@intel.com/T/#u
for example.

I'm dropping the patch now, please fix and resend.

> +
>  #include "internal.h"
>
>  static bool __init processor_physically_present(acpi_handle handle)
> @@ -47,6 +49,15 @@ static bool __init 
> processor_physically_present(acpi_handle handle)
> return false;
> }
>
> +   if (xen_initial_domain())
> +   /*
> +* When running as a Xen dom0 the number of processors Linux
> +* sees can be different from the real number of processors on
> +* the system, and we still need to execute _PDC for all of
> +* them.
> +*/
> +   return xen_processor_present(acpi_id);
> +
> type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
> cpuid = acpi_get_cpuid(handle, type, acpi_id);
>
> diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
> index fd3a644b0855..034d05e56507 100644
> --- a/drivers/xen/pcpu.c
> +++ b/drivers/xen/pcpu.c
> @@ -58,6 +58,7 @@ struct pcpu {
> struct list_head list;
> struct device dev;
> uint32_t cpu_id;
> +   uint32_t acpi_id;
> uint32_t flags;
>  };
>
> @@ -249,6 +250,7 @@ static struct pcpu *create_and_register_pcpu(struct 
> xenpf_pcpuinfo *info)
>
> INIT_LIST_HEAD(>list);
> pcpu->cpu_id = info->xen_cpuid;
> +   pcpu->acpi_id = info->acpi_id;
> pcpu->flags = info->flags;
>
> /* Need hold on xen_pcpu_lock before pcpu list manipulations */
> @@ -381,3 +383,22 @@ static int __init xen_pcpu_init(void)
> return ret;
>  }
>  arch_initcall(xen_pcpu_init);
> +
> +#ifdef CONFIG_ACPI
> +bool __init xen_processor_present(uint32_t acpi_id)
> +{
> +   struct pcpu *pcpu;
> +   

Re: [XEN PATCH v1 1/1] x86/domctl: add gva_to_gfn command

[Andrew Cooper]

On 21/03/2023 7:28 am, Jan Beulich wrote:
> On 20.03.2023 20:07, Andrew Cooper wrote:
>> On 20/03/2023 4:32 pm, Ковалёв Сергей wrote:
>>> gva_to_gfn command used for fast address translation in LibVMI project.
>>> With such a command it is possible to perform address translation in
>>> single call instead of series of queries to get every page table.
>>>
>>> Thanks to Dmitry Isaykin for involvement.
>>>
>>> Signed-off-by: Sergey Kovalev 
>> I fully appreciate why you want this hypercall, and I've said several
>> times that libvmi wants something better than it has, but...
> But is a domctl really the right vehicle? While not strictly intended for
> device models, a dm-op would seem more suitable to me. Considering you
> already brought altp2m into play, it could also be a sub-op of HVMOP_altp2m.

It definitely feels wrong to be using an altp2m op if you're not using
altp2m, and there introspection usecases that don't use altp2m.

dm-op would be the place to put this, if I wasn't pretty sure it would
be modified over time.

As I say - I can see why this might be useful, but pagewalking is more
complicated than the interface presented here.

~Andrew

Re: [PATCH v3 3/3] tools/xen-ucode: print information about currently loaded ucode

[Andrew Cooper]

On 21/03/2023 11:47 am, Sergey Dyasli wrote:
> Add an option to xen-ucode tool to print the currently loaded ucode
> version and also print it during usage info.  Print CPU signature and
> processor flags as well.  The raw data comes from XENPF_get_cpu_version
> and XENPF_get_ucode_version platform ops.
>
> Example output:
> Intel:
> Current CPU signature is: 06-55-04 (raw 0x50654)
> Current CPU microcode revision is: 0x2006e05
> Current CPU processor flags are: 0x1

It's platform flags, not processor flags.  (And sadly, doesn't actually
capture all the platform specific data these days either...)

>
> AMD:
> Current CPU signature is: fam19h (raw 0xa00f11)
> Current CPU microcode revision is: 0xa0011a8

This is unnecessarily verbose, and can fit into a single line.

CPU signature {XX-YY-ZZ / FamXXh} (raw X) {pf Y} revision Z.

> Signed-off-by: Sergey Dyasli 
> ---
>  tools/misc/xen-ucode.c | 66 ++
>  1 file changed, 66 insertions(+)
>
> diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c
> index ad32face2b..b9037ce6a1 100644
> --- a/tools/misc/xen-ucode.c
> +++ b/tools/misc/xen-ucode.c
> @@ -12,6 +12,65 @@
>  #include 
>  #include 
>  
> +static const char intel_id[] = "GenuineIntel";
> +static const char   amd_id[] = "AuthenticAMD";
> +
> +static void show_curr_cpu(FILE *f)
> +{
> +int ret;
> +xc_interface *xch;
> +struct xenpf_pcpu_version cpu_ver = { .xen_cpuid = 0 };
> +struct xenpf_ucode_version ucode_ver = { .xen_cpuid = 0 };
> +bool intel = false, amd = false;
> +
> +xch = xc_interface_open(0, 0, 0);

NULL, NULL, 0

but xch wants to be a global and opened once, rather than in each piece
of sub-functionality.

> +if ( xch == NULL )
> +return;
> +
> +ret = xc_get_cpu_version(xch, _ver);
> +if ( ret )
> +return;
> +
> +ret = xc_get_ucode_version(xch, _ver);
> +if ( ret )
> +return;

All 3 of these want to complain, rather than exiting silently.

See test-tsx/test-resource as examples.  It's fine to use err(1,
"message") to terminate fairly cleanly, and it renders errno to the user
which is far more useful than printing nothing and exiting success.

> +
> +if ( memcmp(cpu_ver.vendor_id, intel_id,
> +sizeof(cpu_ver.vendor_id)) == 0 )
> +intel = true;
> +else if ( memcmp(cpu_ver.vendor_id, amd_id,
> + sizeof(cpu_ver.vendor_id)) == 0 )
> +amd = true;

else some kind of error, again so we don't exit silently.

> +
> +/*
> + * Print signature in a form that allows to quickly identify which ucode
> + * blob to load, e.g.:
> + *
> + *  Intel:   /lib/firmware/intel-ucode/06-55-04
> + *  AMD: /lib/firmware/amd-ucode/microcode_amd_fam19h.bin

I'm not sure if this is relevant any more, but for Fam < 0x15,
everything is combined in microcode_amd.bin

In some copious free time (but not this patch), it might be nice to
support `xen-ucode --auto` to try and pick the right firmware file out
of the filesystem.  One less thing for end users to get wrong.

> + */
> +if ( intel )
> +{
> +fprintf(f, "Current CPU signature is: %02x-%02x-%02x (raw %#x)\n",
> +   cpu_ver.family, cpu_ver.model, cpu_ver.stepping,
> +   ucode_ver.cpu_signature);
> +}
> +else if ( amd )
> +{
> +fprintf(f, "Current CPU signature is: fam%xh (raw %#x)\n",
> +   cpu_ver.family, ucode_ver.cpu_signature);
> +}
> +
> +if ( intel || amd )
> +fprintf(f, "Current CPU microcode revision is: %#x\n",
> +   ucode_ver.ucode_revision);

For the two raw fields, and the revision field, it's important to use 0x08x.

They're all exactly 32bit quantities, and both vendors encode data in
the higher bits, so visually it's very useful to know if you're looking
at the top of penultimate nibble.

~Andrew

Re: [PATCH v8 1/5] xen: introduce CONFIG_GENERIC_BUG_FRAME

[Jan Beulich]

On 21.03.2023 12:18, Oleksii wrote:
> On Mon, 2023-03-20 at 13:36 +0200, Oleksii wrote:
>> On Fri, 2023-03-17 at 15:59 +0100, Jan Beulich wrote:
>>> On 17.03.2023 10:23, Oleksii wrote:
 On Thu, 2023-03-16 at 12:26 +0100, Jan Beulich wrote:
> On 15.03.2023 18:21, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/common/bug.c
>> @@ -0,0 +1,108 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>
> I actually meant to also ask: What is this needed for? Glancing
> over
> the
> code ...
>
>> +/*
>> + * Returns a negative value in case of an error otherwise
>> + * BUGFRAME_{run_fn, warn, bug, assert}
>> + */
>> +int do_bug_frame(struct cpu_user_regs *regs, unsigned long
>> pc)
>> +{
>> +    const struct bug_frame *bug = NULL;
>> +    const struct virtual_region *region;
>> +    const char *prefix = "", *filename, *predicate;
>> +    unsigned long fixup;
>> +    unsigned int id, lineno;
>> +
>> +    region = find_text_region(pc);
>> +    if ( !region )
>> +    return -EINVAL;
>> +
>> +    for ( id = 0; id < BUGFRAME_NR; id++ )
>> +    {
>> +    const struct bug_frame *b;
>> +    size_t i;
>> +
>> +    for ( i = 0, b = region->frame[id].bugs;
>> +  i < region->frame[id].n_bugs; b++, i++ )
>> +    {
>> +    if ( bug_loc(b) == pc )
>> +    {
>> +    bug = b;
>> +    goto found;
>> +    }
>> +    }
>> +    }
>> +
>> + found:
>> +    if ( !bug )
>> +    return -ENOENT;
>> +
>> +    if ( id == BUGFRAME_run_fn )
>> +    {
>> +    void (*fn)(struct cpu_user_regs *) = bug_ptr(bug);
>> +
>> +    fn(regs);
>> +
>> +    /* Re-enforce consistent types, because of the casts
>> involved. */
>> +    if ( false )
>> +    run_in_exception_handler(fn);
>> +
>> +    return id;
>> +    }
>> +
>> +    /* WARN, BUG or ASSERT: decode the filename pointer and
>> line
>> number. */
>> +    filename = bug_ptr(bug);
>> +    if ( !is_kernel(filename) && !is_patch(filename) )
>> +    return -EINVAL;
>> +    fixup = strlen(filename);
>> +    if ( fixup > 50 )
>> +    {
>> +    filename += fixup - 47;
>> +    prefix = "...";
>> +    }
>> +    lineno = bug_line(bug);
>> +
>> +    switch ( id )
>> +    {
>> +    case BUGFRAME_warn:
>> +    printk("Xen WARN at %s%s:%d\n", prefix, filename,
>> lineno);
>> +    show_execution_state(regs);
>> +
>> +    break;
>> +
>> +    case BUGFRAME_bug:
>> +    printk("Xen BUG at %s%s:%d\n", prefix, filename,
>> lineno);
>> +
>> +    if ( BUG_DEBUGGER_TRAP_FATAL(regs) )
>> +    break;
>> +
>> +    show_execution_state(regs);
>> +    panic("Xen BUG at %s%s:%d\n", prefix, filename,
>> lineno);
>> +
>> +    case BUGFRAME_assert:
>> +    /* ASSERT: decode the predicate string pointer. */
>> +    predicate = bug_msg(bug);
>> +    if ( !is_kernel(predicate) && !is_patch(predicate) )
>> +    predicate = "";
>> +
>> +    printk("Assertion '%s' failed at %s%s:%d\n",
>> +   predicate, prefix, filename, lineno);
>> +
>> +    if ( BUG_DEBUGGER_TRAP_FATAL(regs) )
>> +    break;
>> +
>> +    show_execution_state(regs);
>> +    panic("Assertion '%s' failed at %s%s:%d\n",
>> +  predicate, prefix, filename, lineno);
>> +    }
>> +
>> +    return id;
>> +}
>
> ... I can't really spot what it might be that comes from that
> header.
> Oh, on the N+1st run I've spotted it - it's
> show_execution_state().
> The declaration of which, already being used from common code
> ahead
> of this series, should imo be moved to a common header. I guess
> I'll
> make yet another patch ...
 As mentioned above. Not only show_execution_state() but also
 cpu_user_regs structure. ( at lest, for ARM & RISCV )
>>>
>>> Do we deref "regs" anywhere? I can't seem to be able to spot an
>>> instance.
>>> Without a deref (or alike) a forward decl is all that's needed for
>>> this
>>> code to compile.
>> You are there is no a deref so let's swich to a forward decl.
>>
>> I'll add it to a new version of the patch series.
> I just realized that show_execution_state() is declared in
> .

Not anymore with "move {,vcpu_}show_execution_state() declarations
to common header", which was specifically made ...

> So we have to leave an inclusion of the header or declare the function
> explicitly.

... to eliminate this 

Re: [PATCH v3 2/3] x86/platform: introduce XENPF_get_ucode_version

[Jan Beulich]

On 21.03.2023 12:47, Sergey Dyasli wrote:
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -640,6 +640,36 @@ ret_t do_platform_op(
>  }
>  break;
>  
> +case XENPF_get_ucode_version:
> +{
> +struct xenpf_ucode_version *ver = >u.ucode_version;
> +
> +if ( !get_cpu_maps() )
> +{
> +ret = -EBUSY;
> +break;
> +}
> +
> +if ( (ver->xen_cpuid >= nr_cpu_ids) || !cpu_online(ver->xen_cpuid) )
> +{
> +ret = -ENOENT;
> +}

Nit: Unnecessary braces.

> +else
> +{
> +const struct cpu_signature *sig = _cpu(cpu_sig, 
> ver->xen_cpuid);
> +
> +ver->cpu_signature = sig->sig;
> +ver->pf = sig->pf;
> +ver->ucode_revision = sig->rev;
> +}

While I don't mean to insist on making this work right in this patch, I'd
like to re-raise my earlier comment regarding it also being of possible
interest to know ucode revisions for parked CPUs (they are, after all, an
active entity in the system). Parked CPUs have their per-CPU data retained,
so getting at that data shouldn't be overly difficult (the main aspect
being to tell parked from fully offline CPUs).

Jan

[xen-unstable-smoke test] 179838: tolerable trouble: pass/starved - PUSHED

[osstest service owner]

flight 179838 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179838/

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   1 build-check(1)   starved  n/a
 build-armhf   2 hosts-allocate   starved  n/a

version targeted for testing:
 xen  f71f8e95c34fedb0d9ae21a100bfa9f012543abf
baseline version:
 xen  0d2686f6b66b4b1b3c72c3525083b0ce02830054

Last test of basis   179837  2023-03-21 09:16:50 Z0 days
Testing same since   179838  2023-03-21 11:01:58 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  starved 
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  starved 
 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
   0d2686f6b6..f71f8e95c3  f71f8e95c34fedb0d9ae21a100bfa9f012543abf -> smoke

Re: [XEN PATCH v1 1/1] x86/domctl: add gva_to_gfn command

[Tamas K Lengyel]

On Tue, Mar 21, 2023 at 3:49 AM Ковалёв Сергей  wrote:
>
>
>
> 21.03.2023 2:34, Tamas K Lengyel пишет:
> >
> >
> > On Mon, Mar 20, 2023 at 3:23 PM Ковалёв Сергей  > > wrote:
> >  >
> >  >
> >  >
> >  > 21.03.2023 1:51, Tamas K Lengyel wrote:
> >  > >
> >  > >
> >  > > On Mon, Mar 20, 2023 at 12:32 PM Ковалёв Сергей  > 
> >  > > >> wrote:
> >  > >  >
> >  > >  > gva_to_gfn command used for fast address translation in LibVMI
> > project.
> >  > >  > With such a command it is possible to perform address
translation in
> >  > >  > single call instead of series of queries to get every page
table.
> >  > >
> >  > > You have a couple assumptions here:
> >  > >   - Xen will always have a direct map of the entire guest memory -
> > there
> >  > > are already plans to move away from that. Without that this
approach
> >  > > won't have any advantage over doing the same mapping by LibVMI
> >  >
> >  > Thanks! I didn't know about the plan. Though I use this patch
> >  > back ported into 4.16.
> >  >
> >  > >   - LibVMI has to map every page for each page table for every
lookup -
> >  > > you have to do that only for the first, afterwards the pages on
which
> >  > > the pagetable is are kept in a cache and subsequent lookups would
be
> >  > > actually faster then having to do this domctl since you can keep
being
> >  > > in the same process instead of having to jump to Xen.
> >  >
> >  > Yes. I know about the page cache. But I have faced with several
issues
> >  > with cache like this one https://github.com/libvmi/libvmi/pull/1058
> >  .
> >  > So I had to disable the cache.
> >
> > The issue you linked to is an issue with a stale v2p cache, which is a
> > virtual TLB. The cache I talked about is the page cache, which is just
> > maintaining a list of the pages that were accessed by LibVMI for future
> > accesses. You can have one and not the other (ie. ./configure
> > --disable-address-cache --enable-page-cache).
> >
> > Tamas
>
> Thanks. I know about the page cache. Though I'm not familiar with
> it close enough.
>
> As far as I understand at the time the page cache implementation in
> LibVMI looks like this:
> 1. Call sequence: vmi_read > vmi_read_page > driver_read_page >
> xen_read_page > memory_cache_insert ..> get_memory_data >
> xen_get_memory > xen_get_memory_pfn > xc_map_foreign_range
> 2. This is perfectly valid while guest OS keeps page there. And
> physical pages are always there.
> 3. To renew cache the "age_limit" counter is used.
> 4. In Xen driver implementation in LibVMI the "age_limit" is
> disabled.
> 5. Also it is possible to invalidate cache with "xen_write" or
> "vmi_pagecache_flush". But it is not used.
> 6. Other way to avoid too big cache is cache size limit. So on
> every insert half of the cache is dropped on size overflow.
>
> So the only thing we should know is valid mapping of guest
> virtual address to guest physical address.
>
> And the slow paths are:
> 1. A first traversal of new page table set. E.g. for the new process.
> 2. Or new subset of page tables for known process.
> 3. Subsequent page access after cache clean on size overflow.
>
> Am I right?
>
> The main idea behind the patch:
> 1. For the very first time it would be done faster with hypercall.
> 2. For subsequent calls v2p translation cache could be used (used in
> my current work in LibVMI).
> 3. To avoid errors with stale cache v2p cache could be invalidated
> on every event (VMI_FLUSH_RATE = 1).

If you set a flush rate to 1 then you would effectively run without any
caching between events. It will still be costly. Yes, you save some
performance on having to map the pages because Xen already has them but
overall this is still a subpar solution.

IMHO you are not addressing the real issue, which is just the lack of hooks
into the OS that would tell you when the v2p cache actually needs to be
invalidated. The OS does TLB maintenance already when it updates its
pagetables. If you wrote logic to hook into that, you wouldn't have to
disable the caches or run with flush rate = 1. On the DRAKVUF side this has
been a TODO for a long time
https://github.com/tklengyel/drakvuf/blob/df2d274dfe349bbdacdb121229707f6c91449b38/src/libdrakvuf/private.h#L140.
If you had those hooks into the TLB maintenance logic you could just use
the existing page-cache and be done with it. Yes, the very first access may
still be slower than the hypercall but I doubt it would be noticeable in
the long run.

Tamas

Re: [PATCH v3 2/3] x86/platform: introduce XENPF_get_ucode_version

[Andrew Cooper]

On 21/03/2023 11:47 am, Sergey Dyasli wrote:
> Currently it's impossible to get CPU's microcode revision after late
> loading without looking into Xen logs which is not always convenient.

It's not impossible (you can do `modprobe msr; rdmsr 0x8b`), but it is
inconvenient for library code.

>
> Add a new platform op in order to get the required data from Xen and
> provide a wrapper for libxenctrl.
>
> Signed-off-by: Sergey Dyasli 
> ---
>  tools/include/xenctrl.h  |  2 ++
>  tools/libs/ctrl/xc_misc.c| 21 +
>  xen/arch/x86/platform_hypercall.c| 30 
>  xen/arch/x86/x86_64/platform_hypercall.c |  4 
>  xen/include/public/platform.h| 12 ++
>  xen/include/xlat.lst |  1 +
>  6 files changed, 70 insertions(+)
>
> diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
> index 8aa747dc2e..d3ef7a48a5 100644
> --- a/tools/include/xenctrl.h
> +++ b/tools/include/xenctrl.h
> @@ -1187,6 +1187,8 @@ int xc_cputopoinfo(xc_interface *xch, unsigned 
> *max_cpus,
> xc_cputopo_t *cputopo);
>  int xc_microcode_update(xc_interface *xch, const void *buf, size_t len);
>  int xc_get_cpu_version(xc_interface *xch, struct xenpf_pcpu_version 
> *cpu_ver);
> +int xc_get_ucode_version(xc_interface *xch,
> + struct xenpf_ucode_version *ucode_ver);

Throughout, we should use "revision" rather than "version" as that is
the terminology used by both Intel and AMD.

>  int xc_numainfo(xc_interface *xch, unsigned *max_nodes,
>  xc_meminfo_t *meminfo, uint32_t *distance);
>  int xc_pcitopoinfo(xc_interface *xch, unsigned num_devs,
> diff --git a/tools/libs/ctrl/xc_misc.c b/tools/libs/ctrl/xc_misc.c
> index f2f6e4348e..b93477d189 100644
> --- a/tools/libs/ctrl/xc_misc.c
> +++ b/tools/libs/ctrl/xc_misc.c
> @@ -246,6 +246,27 @@ int xc_get_cpu_version(xc_interface *xch, struct 
> xenpf_pcpu_version *cpu_ver)
>  return 0;
>  }
>  
> +int xc_get_ucode_version(xc_interface *xch,
> + struct xenpf_ucode_version *ucode_ver)
> +{
> +int ret;
> +DECLARE_PLATFORM_OP;
> +
> +if ( !xch || !ucode_ver )
> +return -1;
> +
> +platform_op.cmd = XENPF_get_ucode_version;
> +platform_op.u.ucode_version.xen_cpuid = ucode_ver->xen_cpuid;

Same notes as per patch 1.

> diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
> index 60caa5ce7e..232df79d5f 100644
> --- a/xen/include/public/platform.h
> +++ b/xen/include/public/platform.h
> @@ -614,6 +614,17 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_symdata_t);
>  typedef struct dom0_vga_console_info xenpf_dom0_console_t;
>  DEFINE_XEN_GUEST_HANDLE(xenpf_dom0_console_t);
>  
> +#define XENPF_get_ucode_version 65
> +struct xenpf_ucode_version {
> +uint32_t xen_cpuid;   /* IN:  CPU number to get the revision from.  
> */

We commonly call this just "cpu".  As a platform op pertaining to
microcode, it cannot plausibly be confused with vcpus.

> +uint32_t cpu_signature;   /* OUT: CPU signature (CPUID.1.EAX).  
> */

The cpu_ prefix can be dropped, as can ...

> +uint32_t pf;  /* OUT: Processor Flags.  
> */
> +  /*  Only applicable to Intel. 
> */
> +uint32_t ucode_revision;  /* OUT: Microcode Revision.   
> */

the ucode_ prefix here.

I'm tempted to say that I'm happy to fix all of this on commit as it's
all mechanical changes.

~Andrew

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

[Huang Rui]

On Tue, Mar 21, 2023 at 08:27:21PM +0800, Jan Beulich wrote:
> On 21.03.2023 12:49, Huang Rui wrote:
> > Thanks, but we found if dom0 is PV domain, the passthrough device will
> > access this function to write the real bar.
> 
> Can you please be quite a bit more detailed about this? The specific code
> paths taken (in upstream software) to result in such would of of interest.
> 

yes, please wait for a moment. let me capture a trace dump in my side.

Thanks,
Ray

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

[Huang Rui]

On Tue, Mar 21, 2023 at 08:20:53PM +0800, Roger Pau Monné wrote:
> On Tue, Mar 21, 2023 at 07:49:26PM +0800, Huang Rui wrote:
> > On Tue, Mar 21, 2023 at 06:20:03PM +0800, Jan Beulich wrote:
> > > On 21.03.2023 11:14, Huang Rui wrote:
> > > > On Tue, Mar 21, 2023 at 05:41:57PM +0800, Jan Beulich wrote:
> > > >> On 21.03.2023 10:36, Huang Rui wrote:
> > > >>> On Wed, Mar 15, 2023 at 12:02:35AM +0800, Jan Beulich wrote:
> > >  On 12.03.2023 08:54, Huang Rui wrote:
> > > > --- a/xen/drivers/vpci/header.c
> > > > +++ b/xen/drivers/vpci/header.c
> > > > @@ -392,7 +392,7 @@ static void cf_check bar_write(
> > > >   * Xen only cares whether the BAR is mapped into the p2m, so 
> > > > allow BAR
> > > >   * writes as long as the BAR is not mapped into the p2m.
> > > >   */
> > > > -if ( bar->enabled )
> > > > +if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & 
> > > > PCI_COMMAND_MEMORY )
> > > >  {
> > > >  /* If the value written is the current one avoid printing 
> > > > a warning. */
> > > >  if ( val != (uint32_t)(bar->addr >> (hi ? 32 : 0)) )
> > > 
> > >  ... bar->enabled doesn't properly reflect the necessary state? It
> > >  generally shouldn't be necessary to look at the physical device's
> > >  state here.
> > > 
> > >  Furthermore when you make a change in a case like this, the
> > >  accompanying comment also needs updating (which might have clarified
> > >  what, if anything, has been wrong).
> > > 
> > > >>>
> > > >>> That is the problem that we start domU at the first time, the enable 
> > > >>> flag
> > > >>> will be set while the passthrough device would like to write the real 
> > > >>> pcie
> > > >>> bar on the host.
> > > >>
> > > >> A pass-through device (i.e. one already owned by a DomU) should never
> > > >> be allowed to write to the real BAR. But it's not clear whether I'm not
> > > >> misinterpreting what you said ...
> > > >>
> > > > 
> > > > OK. Thanks to clarify this. May I know how does a passthrough device 
> > > > modify
> > > > pci bar with correct behavior on Xen?
> > > 
> > > A pass-through device may write to the virtual BAR, changing where in its
> > > own memory space the MMIO range appears. But it cannot (and may not) alter
> > > where in host memory space the (physical) MMIO range appears.
> > > 
> > 
> > Thanks, but we found if dom0 is PV domain, the passthrough device will
> > access this function to write the real bar.
> 
> I'm very confused now, are you trying to use vPCI with HVM domains?

We are using QEMU for passthrough at this moment.

> 
> As I understood it you are attempting to enable PCI passthrough for
> HVM guests from a PVH dom0, but now you say your dom0 is PV?
> 

Ah, sorry to make you confused, you're right. I am using PVH dom0 + HVM
domU. But we are comparing passthrough function on PV dom0 + HVM domU as a
reference.

Thanks,
Ray

Re: [PATCH v3 1/3] tools/xenctrl: add xc_get_cpu_version()

[Andrew Cooper]

On 21/03/2023 11:47 am, Sergey Dyasli wrote:
> diff --git a/tools/libs/ctrl/xc_misc.c b/tools/libs/ctrl/xc_misc.c
> index 265f15ec2d..f2f6e4348e 100644
> --- a/tools/libs/ctrl/xc_misc.c
> +++ b/tools/libs/ctrl/xc_misc.c
> @@ -226,6 +226,26 @@ int xc_microcode_update(xc_interface *xch, const void 
> *buf, size_t len)
>  return ret;
>  }
>  
> +int xc_get_cpu_version(xc_interface *xch, struct xenpf_pcpu_version *cpu_ver)
> +{
> +int ret;
> +DECLARE_PLATFORM_OP;
> +
> +if ( !xch || !cpu_ver )
> +return -1;

We don't check parameters like this anywhere else.  It's library code,
and the caller is required to DTRT.

Also, we're phasing out the use of the DECLARE macros.  This wants to
change to

struct xen_platform_op op = {
    .cmd = XENPF_get_cpu_version,
    .u.pcpu_version.xen_cpuid = cpu_ver->xen_cpuid,
};

Both can be fixed on commit, if you're happy.

~Andrew

Re: [RFC XEN PATCH 4/6] x86/pvh: PVH dom0 also need PHYSDEVOP_setup_gsi call

[Huang Rui]

On Thu, Mar 16, 2023 at 01:01:52AM +0800, Andrew Cooper wrote:
> On 14/03/2023 4:30 pm, Jan Beulich wrote:
> > On 12.03.2023 08:54, Huang Rui wrote:
> >> From: Chen Jiqian 
> > An empty description won't do here. First of all you need to address the 
> > Why?
> > As already hinted at in the reply to the earlier patch, it looks like you're
> > breaking the intended IRQ model for PVH.
> 
> I think this is rather unfair.
> 
> Until you can point to the document which describes how IRQs are
> intended to work in PVH, I'd say this series is pretty damn good attempt
> to make something that functions, in the absence of any guidance.
> 

Thank you, Andrew! This is the first time we submit Xen patches, any
comments are warm for us. :-)

Thanks,
Ray

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

[Jan Beulich]

On 21.03.2023 12:49, Huang Rui wrote:
> Thanks, but we found if dom0 is PV domain, the passthrough device will
> access this function to write the real bar.

Can you please be quite a bit more detailed about this? The specific code
paths taken (in upstream software) to result in such would of of interest.

Jan

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

[Jan Beulich]

On 21.03.2023 13:20, Roger Pau Monné wrote:
> On Tue, Mar 21, 2023 at 07:49:26PM +0800, Huang Rui wrote:
>> On Tue, Mar 21, 2023 at 06:20:03PM +0800, Jan Beulich wrote:
>>> On 21.03.2023 11:14, Huang Rui wrote:
 On Tue, Mar 21, 2023 at 05:41:57PM +0800, Jan Beulich wrote:
> On 21.03.2023 10:36, Huang Rui wrote:
>> On Wed, Mar 15, 2023 at 12:02:35AM +0800, Jan Beulich wrote:
>>> On 12.03.2023 08:54, Huang Rui wrote:
 --- a/xen/drivers/vpci/header.c
 +++ b/xen/drivers/vpci/header.c
 @@ -392,7 +392,7 @@ static void cf_check bar_write(
   * Xen only cares whether the BAR is mapped into the p2m, so 
 allow BAR
   * writes as long as the BAR is not mapped into the p2m.
   */
 -if ( bar->enabled )
 +if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & 
 PCI_COMMAND_MEMORY )
  {
  /* If the value written is the current one avoid printing a 
 warning. */
  if ( val != (uint32_t)(bar->addr >> (hi ? 32 : 0)) )
>>>
>>> ... bar->enabled doesn't properly reflect the necessary state? It
>>> generally shouldn't be necessary to look at the physical device's
>>> state here.
>>>
>>> Furthermore when you make a change in a case like this, the
>>> accompanying comment also needs updating (which might have clarified
>>> what, if anything, has been wrong).
>>>
>>
>> That is the problem that we start domU at the first time, the enable flag
>> will be set while the passthrough device would like to write the real 
>> pcie
>> bar on the host.
>
> A pass-through device (i.e. one already owned by a DomU) should never
> be allowed to write to the real BAR. But it's not clear whether I'm not
> misinterpreting what you said ...
>

 OK. Thanks to clarify this. May I know how does a passthrough device modify
 pci bar with correct behavior on Xen?
>>>
>>> A pass-through device may write to the virtual BAR, changing where in its
>>> own memory space the MMIO range appears. But it cannot (and may not) alter
>>> where in host memory space the (physical) MMIO range appears.
>>>
>>
>> Thanks, but we found if dom0 is PV domain, the passthrough device will
>> access this function to write the real bar.
> 
> I'm very confused now, are you trying to use vPCI with HVM domains?
> 
> As I understood it you are attempting to enable PCI passthrough for
> HVM guests from a PVH dom0, but now you say your dom0 is PV?

I didn't read it like this. Instead my way of understanding the reply
is that they try to mimic on PVH Dom0 what they observe on PV Dom0.

Jan

Re: [RFC XEN PATCH 4/6] x86/pvh: PVH dom0 also need PHYSDEVOP_setup_gsi call

[Huang Rui]

On Wed, Mar 15, 2023 at 12:30:21AM +0800, Jan Beulich wrote:
> On 12.03.2023 08:54, Huang Rui wrote:
> > From: Chen Jiqian 
> 
> An empty description won't do here. First of all you need to address the Why?
> As already hinted at in the reply to the earlier patch, it looks like you're
> breaking the intended IRQ model for PVH.
> 

Sorry, I used a wrong patch without commit message. Will fix in next
version.

Thanks,
Ray

Re: [RFC XEN PATCH 2/6] vpci: accept BAR writes if dom0 is PVH

[Roger Pau Monné]

On Tue, Mar 21, 2023 at 07:49:26PM +0800, Huang Rui wrote:
> On Tue, Mar 21, 2023 at 06:20:03PM +0800, Jan Beulich wrote:
> > On 21.03.2023 11:14, Huang Rui wrote:
> > > On Tue, Mar 21, 2023 at 05:41:57PM +0800, Jan Beulich wrote:
> > >> On 21.03.2023 10:36, Huang Rui wrote:
> > >>> On Wed, Mar 15, 2023 at 12:02:35AM +0800, Jan Beulich wrote:
> >  On 12.03.2023 08:54, Huang Rui wrote:
> > > --- a/xen/drivers/vpci/header.c
> > > +++ b/xen/drivers/vpci/header.c
> > > @@ -392,7 +392,7 @@ static void cf_check bar_write(
> > >   * Xen only cares whether the BAR is mapped into the p2m, so 
> > > allow BAR
> > >   * writes as long as the BAR is not mapped into the p2m.
> > >   */
> > > -if ( bar->enabled )
> > > +if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & 
> > > PCI_COMMAND_MEMORY )
> > >  {
> > >  /* If the value written is the current one avoid printing a 
> > > warning. */
> > >  if ( val != (uint32_t)(bar->addr >> (hi ? 32 : 0)) )
> > 
> >  ... bar->enabled doesn't properly reflect the necessary state? It
> >  generally shouldn't be necessary to look at the physical device's
> >  state here.
> > 
> >  Furthermore when you make a change in a case like this, the
> >  accompanying comment also needs updating (which might have clarified
> >  what, if anything, has been wrong).
> > 
> > >>>
> > >>> That is the problem that we start domU at the first time, the enable 
> > >>> flag
> > >>> will be set while the passthrough device would like to write the real 
> > >>> pcie
> > >>> bar on the host.
> > >>
> > >> A pass-through device (i.e. one already owned by a DomU) should never
> > >> be allowed to write to the real BAR. But it's not clear whether I'm not
> > >> misinterpreting what you said ...
> > >>
> > > 
> > > OK. Thanks to clarify this. May I know how does a passthrough device 
> > > modify
> > > pci bar with correct behavior on Xen?
> > 
> > A pass-through device may write to the virtual BAR, changing where in its
> > own memory space the MMIO range appears. But it cannot (and may not) alter
> > where in host memory space the (physical) MMIO range appears.
> > 
> 
> Thanks, but we found if dom0 is PV domain, the passthrough device will
> access this function to write the real bar.

I'm very confused now, are you trying to use vPCI with HVM domains?

As I understood it you are attempting to enable PCI passthrough for
HVM guests from a PVH dom0, but now you say your dom0 is PV?

Thanks, Roger.

Xen Security Advisory 429 v3 (CVE-2022-42331) - x86: speculative vulnerability in 32bit SYSCALL path

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42331 / XSA-429
   version 3

  x86: speculative vulnerability in 32bit SYSCALL path

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

Due to an oversight in the very original Spectre/Meltdown security work
(XSA-254), one entrypath performs its speculation-safety actions too
late.

In some configurations, there is an unprotected RET instruction which
can be attacked with a variety of speculative attacks.

IMPACT
==

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==

Xen versions 4.5 through 4.17 are vulnerable.  Older versions are not
vulnerable.

Only x86 CPUs are potentially vulnerable.  CPUs of other architectures
are not vulnerable.

The problematic codepath is only reachable on x86 CPUs which follow
AMD's behaviour with respect to SYSCALL instructions from compatibility
mode segments.  This means that AMD and Hygon CPUs are potentially
vulnerable, whereas Intel CPUs are not.  Other vendors have not been
checked.

Only PV guests can leverage the vulnerability.

On Xen 4.16 and later, the vulnerability is only present if 32bit PV
guest support is compiled in - i.e. CONFIG_PV32=y.  On Xen 4.15 and
older, all supported build configurations are vulnerable.

The vulnerability is only present when booting on hardware that supports
SMEP or SMAP (Supervisor Mode Execution/Access Prevention).  This is
believed to be some Family 0x16 models, and all later CPUs.

MITIGATION
==

Not running untrusted PV guests will avoid the issue.

CREDITS
===

This issue was discovered by Andrew Cooper of XenServer.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa429.patch   xen-unstable - Xen 4.16
xsa429-4.15.patch  Xen 4.15 - Xen 4.14

$ sha256sum xsa429*
2d7be90d917c475ab5217e657d2b44f5d8b107d9023dca034fcfb7feab07b2f0  xsa429.meta
36ed36dbfaad9e5df5fa87b9a3d9e9c531f476f97eeb2afe280aa238032a0540  xsa429.patch
7ac3d4182585e5d2d39231f10e7c0c9fcb972c82cf81cb884e95b628187de3a7  
xsa429-4.15.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmQZlWMMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZil4H/2b1DkLLz4RQqAgvaB8+SBeVLPqoZ7QxGLl8QXWT
AMjFdy+M5T1OtbrMvEYCZNYhZnGOJgmVagERUvg/yZbPYx28NIHjG4+u90Ot6OId
AQPqdrJ0wjEzN/ppNpnu1ALofAGbjsnAypEouGPh12gh5fcpcLQdT0rvpl2ff5f6
Qi4ShtUXhBiduBQcJ0TSneSCf5s7cq1+sMenntenK5Nrsvg7gu51YR45FyKyXdZc
raonkGDny9kmDAjdKkywS2Au2763ph9nHbW5TbD17s65AKUDTupzk+QlFPhJLIP+
/gxDoUjKFiD/eY0AABWMAFGGvHFRNvdhTfUd6ImmWhqdEeE=
=HxUJ
-END PGP SIGNATURE-


xsa429.meta
Description: Binary data


xsa429.patch
Description: Binary data


xsa429-4.15.patch
Description: Binary data

Xen Security Advisory 427 v2 (CVE-2022-42332) - x86 shadow plus log-dirty mode use-after-free

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2022-42332 / XSA-427
   version 2

 x86 shadow plus log-dirty mode use-after-free

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

In environments where host assisted address translation is necessary
but Hardware Assisted Paging (HAP) is unavailable, Xen will run guests
in so called shadow mode.  Shadow mode maintains a pool of memory used
for both shadow page tables as well as auxiliary data structures.  To
migrate or snapshot guests, Xen additionally runs them in so called
log-dirty mode.  The data structures needed by the log-dirty tracking
are part of aformentioned auxiliary data.

In order to keep error handling efforts within reasonable bounds, for
operations which may require memory allocations shadow mode logic
ensures up front that enough memory is available for the worst case
requirements.  Unfortunately, while page table memory is properly
accounted for on the code path requiring the potential establishing of
new shadows, demands by the log-dirty infrastructure were not taken into
consideration.  As a result, just established shadow page tables could
be freed again immediately, while other code is still accessing them on
the assumption that they would remain allocated.

IMPACT
==

Guests running in shadow mode and being subject to migration or
snapshotting may be able to cause Denial of Service and other problems,
including escalation of privilege.

VULNERABLE SYSTEMS
==

All Xen versions from at least 3.2 onwards are vulnerable.  Earlier
versions have not been inspected.

Only x86 systems are vulnerable.  The vulnerability is limited to
migration and snapshotting of guests, and only to PV ones as well as
HVM or PVH ones run with shadow paging.

MITIGATION
==

Not migrating or snapshotting guests will avoid the vulnerability.

Running only HVM or PVH guests and only in HAP (Hardware Assisted
Paging) mode will also avoid the vulnerability.

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa427.patch   xen-unstable - Xen 4.17.x
xsa427-4.16.patch  Xen 4.16.x
xsa427-4.15.patch  Xen 4.15.x
xsa427-4.14.patch  Xen 4.14.x

$ sha256sum xsa427*
5ebcdc495ba6f439e47be7e17dbb8fbdecf4de66d2fac560d460f6841bd3bef3  xsa427.meta
aa39316cbb81478c62b3d5c5aea7edfb6ade3bc5e6d0aa8c4677f9ea7bcc97a2  xsa427.patch
5ba679bc2170b0d9cd4c6ce139057e3287a6ee00434fa0e9a7a02441420030ff  
xsa427-4.14.patch
410ee6be28412841ab5aba1131f7dd7b84b9983f6c93974605f196fd278562e1  
xsa427-4.15.patch
76c1850eb9a274c1feb5a8645f61ecf394a0551278f4e40e123ec07ea307f101  
xsa427-4.16.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmQZlVkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZgRMH/RU6mB8M/feJeZDkYbrLPmT3yLiw6BpWroMTUTpv
5kIlixxlfQqyv8gqd25p5WMMKUsZlPZdLCT0iOlyMTNz6EUPRBME2Yb3ByiM7O7/
kFtlFDk5ZY5c/Vk1w0XuLm+YcABj0xnsn003YvgknmZfBJ2HWdR2iIayT/NjfQ+u
twErqUqa7il2Em5M8ZwHZeJjCUN9t+g2sv5sdI/rQeRge8ofjsquLubpgUVMGjiV
xwwUPCn3co0/2WArB4mHjWCNcoATk1NVZ3CTUyKGl5Mr+EvdmYWvzmlDa4wc8QPV
tNoASqXw0MbOOTy+RnZQHwappCDP371MirPq4IaTwiXy7eo=
=0flx
-END PGP SIGNATURE-


xsa427.meta
Description: Binary data


xsa427.patch
Description: Binary data


xsa427-4.14.patch
Description: Binary data


xsa427-4.15.patch
Description: Binary data


xsa427-4.16.patch
Description: Binary data