Re: [PATCH] xen/public: fix flexible array definitions

[Jan Beulich]

On 25.07.2023 18:59, Andrew Cooper wrote:
> On 25/07/2023 5:16 pm, Jan Beulich wrote:
>> On 25.07.2023 15:55, Juergen Gross wrote:
>>> Flexible arrays in public headers can be problematic with some
>>> compilers.
>>>
>>> Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
>>> errors.
>>>
>>> This includes arrays defined as "arr[1]", as seen with a recent Linux
>>> kernel [1].
>>>
>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217693
>>>
>>> Signed-off-by: Juergen Gross 
>> I think we need to be careful here: What if someone somewhere applies
>> sizeof() to any of the types you alter?
> 
> Then the code was most likely wrong already.

That's possible to judge only when seeing the code in question.

>>  The resulting value would
>> change with the changes you propose, which we cannot allow to happen
>> in a stable interface. Therefore imo it can only be an opt-in feature
>> to have these arrays no longer be one-element ones.
> 
> I don't consider this an issue.
> 
> If people take an update to the headers and their code stops compiling,
> then of course they fix the compilation issue.  That's normal.

The code may continue to compile fine, and even appear to work initially.

> It's unreasonable to take opt-in features to a set of headers intended
> to be vendored in the first place, to work around a corner case that's
> likely buggy already.

The original intention clearly was to allow use of these headers as is.
Anyway, I've voiced my view, yet if there are enough people agreeing
with you, then so be it.

Jan

Re: [XEN PATCH v2] xen/spinlock: mechanically rename parameter name 'debug'

[Jan Beulich]

On 25.07.2023 22:28, Nicola Vetrini wrote:
> 
> 
> On 25/07/23 21:37, Stefano Stabellini wrote:
>> On Tue, 25 Jul 2023, Jan Beulich wrote:
>>> On 25.07.2023 11:17, Nicola Vetrini wrote:
 Rule 5.3 has the following headline:
 "An identifier declared in an inner scope shall not hide an
 identifier declared in an outer scope"

 To avoid any confusion resulting from the parameter 'debug'
 hiding the homonymous function declared at
 'xen/arch/x86/include/asm/processor.h:428'
 the rename of parameters s/debug/lkdbg/ is performed.

 Signed-off-by: Nicola Vetrini 
 ---
 Changes in v2:
 - s/dbg/lkdbg/
>>>
>>> But only in some of the cases. E.g. ...
>>>
 -static void check_barrier(union lock_debug *debug)
 +static void check_barrier(union lock_debug *dbg)
>>>
>>> ... not here (there are a few more).
>>
>> I agree with Jan: these are all union lock_debug parameters, so it would
>> make sense to me to use lkdbg everywhere in this patch.
> 
> Yes, indeed, that's unintentional. Can this be done on commit or should 
> I send a v3?

This wants to be a v3, but I'd suggest to wait a little with this until
we've decided whether to go the alternative route and rename the entry
point symbol that's colliding here. I would prefer this in general, but
even more so if sooner or later we'd rename most of them anyway.

Jan

[ovmf test] 182018: all pass - PUSHED

[osstest service owner]

flight 182018 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182018/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 25a6745fe886e88fe175a50dcab4562c65b7cea3
baseline version:
 ovmf dcf05f958eb409095bf330cf8b8f12fe4c940880

Last test of basis   181988  2023-07-24 04:10:50 Z2 days
Testing same since   182018  2023-07-26 01:10:45 Z0 days1 attempts


People who touched revisions under test:
  Nickle Wang 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   dcf05f958e..25a6745fe8  25a6745fe886e88fe175a50dcab4562c65b7cea3 -> 
xen-tested-master

Re: Fwd: UBSAN: index 1 is out of range for type 'xen_netif_rx_sring_entry [1]'

[Kees Cook]

On Tue, Jul 25, 2023 at 03:34:26PM +0200, Juergen Gross wrote:
> On 25.07.23 15:24, Juergen Gross wrote:
> > On 23.07.23 02:06, Nathan Chancellor wrote:
> > > On Sat, Jul 22, 2023 at 07:21:05AM +0700, Bagas Sanjaya wrote:
> > > > Hi,
> > > > 
> > > > I notice a regression report on Bugzilla [1]. Quoting from it:
> > > > 
> > > > > Hi Kernel Team,
> > > > > 
> > > > > I rebuild today latest version from mainline repo.
> > > > > And i notice issue regarding xen-netfront.c.
> > > > > 
> > > > > Error:
> > > > > [    3.477400] 
> > > > > 
> > > > > [    3.477633] UBSAN: array-index-out-of-bounds in
> > > > > drivers/net/xen-netfront.c:1291:3
> > > > > [    3.477858] index 1 is out of range for type 
> > > > > 'xen_netif_rx_sring_entry [1]'
> > > > > [    3.478085] CPU: 0 PID: 700 Comm: NetworkManager Not
> > > > > tainted 6.5.0-rc2-1-generation1 #3
> > > > > [    3.478088] Hardware name: Intel Corporation
> > > > > W2600CR/W2600CR, BIOS SE5C600.86B.02.06.0007.082420181029
> > > > > 01/13/2022
> > > > > [    3.478090] Call Trace:
> > > > > [    3.478092]  
> > > > > [    3.478097]  dump_stack_lvl+0x48/0x70
> > > > > [    3.478105]  dump_stack+0x10/0x20
> > > > > [    3.478107]  __ubsan_handle_out_of_bounds+0xc6/0x110
> > > > > [    3.478114]  xennet_poll+0xa94/0xac0
> > > > > [    3.478118]  ? generic_smp_call_function_single_interrupt+0x13/0x20
> > > > > [    3.478125]  __napi_poll+0x33/0x200
> > > > > [    3.478131]  net_rx_action+0x181/0x2e0
> > > > > [    3.478135]  __do_softirq+0xd9/0x346
> > > > > [    3.478139]  do_softirq.part.0+0x41/0x80
> > > > > [    3.478144]  
> > > > > [    3.478145]  
> > > > > [    3.478146]  __local_bh_enable_ip+0x72/0x80
> > > > > [    3.478149]  _raw_spin_unlock_bh+0x1d/0x30
> > > > > [    3.478151]  xennet_open+0x75/0x160
> > > > > [    3.478154]  __dev_open+0x105/0x1d0
> > > > > [    3.478156]  __dev_change_flags+0x1b5/0x230
> > > > > [    3.478158]  dev_change_flags+0x27/0x80
> > > > > [    3.478160]  do_setlink+0x3d2/0x12b0
> > > > > [    3.478164]  ? __nla_validate_parse+0x5b/0xdb0
> > > > > [    3.478169]  __rtnl_newlink+0x6f6/0xb10
> > > > > [    3.478173]  ? rtnl_newlink+0x2f/0x80
> > > > > [    3.478177]  rtnl_newlink+0x48/0x80
> > > > > [    3.478180]  rtnetlink_rcv_msg+0x170/0x430
> > > > > [    3.478183]  ? fib6_clean_node+0xad/0x190
> > > > > [    3.478188]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
> > > > > [    3.478191]  netlink_rcv_skb+0x5d/0x110
> > > > > [    3.478195]  rtnetlink_rcv+0x15/0x30
> > > > > [    3.478198]  netlink_unicast+0x247/0x390
> > > > > [    3.478200]  netlink_sendmsg+0x25e/0x4e0
> > > > > [    3.478202]  sock_sendmsg+0xaf/0xc0
> > > > > [    3.478204]  sys_sendmsg+0x2a9/0x350
> > > > > [    3.478206]  ___sys_sendmsg+0x9a/0xf0
> > > > > [    3.478212]  ? _copy_from_iter+0x80/0x4a0
> > > > > [    3.478217]  __sys_sendmsg+0x89/0xf0
> > > > > [    3.478220]  __x64_sys_sendmsg+0x1d/0x30
> > > > > [    3.478222]  do_syscall_64+0x5c/0x90
> > > > > [    3.478226]  ? do_syscall_64+0x68/0x90
> > > > > [    3.478228]  ? ksys_write+0xe6/0x100
> > > > > [    3.478232]  ? exit_to_user_mode_prepare+0x49/0x220
> > > > > [    3.478236]  ? syscall_exit_to_user_mode+0x1b/0x50
> > > > > [    3.478240]  ? do_syscall_64+0x68/0x90
> > > > > [    3.478242]  ? do_syscall_64+0x68/0x90
> > > > > [    3.478243]  ? irqentry_exit_to_user_mode+0x9/0x30
> > > > > [    3.478246]  ? irqentry_exit+0x43/0x50
> > > > > [    3.478248]  ? sysvec_xen_hvm_callback+0x4b/0xd0
> > > > > [    3.478250]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> > > > > [    3.478253] RIP: 0033:0x7f973c244e4d
> > > > > [    3.478268] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24
> > > > > 08 e8 ca ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c
> > > > > 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89
> > > > > c7 48 89 44 24 08 e8 fe ee ff ff 48
> > > > > [    3.478270] RSP: 002b:7fff4777f470 EFLAGS: 0293
> > > > > ORIG_RAX: 002e
> > > > > [    3.478273] RAX: ffda RBX: 5583087c6480
> > > > > RCX: 7f973c244e4d
> > > > > [    3.478274] RDX:  RSI: 7fff4777f4c0
> > > > > RDI: 000c
> > > > > [    3.478276] RBP: 7fff4777f4c0 R08: 
> > > > > R09: 
> > > > > [    3.478277] R10:  R11: 0293
> > > > > R12: 5583087c6480
> > > > > [    3.478279] R13: 7fff4777f668 R14: 7fff4777f65c
> > > > > R15: 
> > > > > [    3.478283]  
> > > > > [    3.478284] 
> > > > > 
> > > > > [    3.685513] 
> > > > > 
> > > > > [    3.685751] UBSAN: array-index-out-of-bounds in
> > > > > drivers/net/xen-netfront.c:485:7
> > > > > [    3.686111] index 1 is out of range for type 
> > > > > 'xen_netif_tx_sring_entry [1]'
> > 

[xen-4.16-testing test] 181998: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 19 guest-localmigrate/x10 fail pass in 
182017-retest

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop   fail blocked in 181882
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 181882
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 181882
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 181882
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 181882
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 181882
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 181882
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 181882
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 181882
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   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  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-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  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-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-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 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
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt   16 saverestore-support-check fail starved in 181882
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail starved in 
181882
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail starved in 
181882

version targeted for testing:
 xen  82c5ab6be04a1f5544e38ed5198e79b91cecac45
baseline version:
 xen  78f53920f406fe973bb70011ae36d6a53abf6942

Last test of basis   181882  

Re: [PATCH v8 04/13] vpci: add hooks for PCI device assign/de-assign

[Volodymyr Babchuk]

Hi Roger,

Roger Pau Monné  writes:

> On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
>> From: Oleksandr Andrushchenko 
>> 
>> When a PCI device gets assigned/de-assigned some work on vPCI side needs
>> to be done for that device. Introduce a pair of hooks so vPCI can handle
>> that.
>> 
>> Signed-off-by: Oleksandr Andrushchenko 
>> ---
>> Since v8:
>> - removed vpci_deassign_device
>> Since v6:
>> - do not pass struct domain to vpci_{assign|deassign}_device as
>>   pdev->domain can be used
>> - do not leave the device assigned (pdev->domain == new domain) in case
>>   vpci_assign_device fails: try to de-assign and if this also fails, then
>>   crash the domain
>> Since v5:
>> - do not split code into run_vpci_init
>> - do not check for is_system_domain in vpci_{de}assign_device
>> - do not use vpci_remove_device_handlers_locked and re-allocate
>>   pdev->vpci completely
>> - make vpci_deassign_device void
>> Since v4:
>>  - de-assign vPCI from the previous domain on device assignment
>>  - do not remove handlers in vpci_assign_device as those must not
>>exist at that point
>> Since v3:
>>  - remove toolstack roll-back description from the commit message
>>as error are to be handled with proper cleanup in Xen itself
>>  - remove __must_check
>>  - remove redundant rc check while assigning devices
>>  - fix redundant CONFIG_HAS_VPCI check for CONFIG_HAS_VPCI_GUEST_SUPPORT
>>  - use REGISTER_VPCI_INIT machinery to run required steps on device
>>init/assign: add run_vpci_init helper
>> Since v2:
>> - define CONFIG_HAS_VPCI_GUEST_SUPPORT so dead code is not compiled
>>   for x86
>> Since v1:
>>  - constify struct pci_dev where possible
>>  - do not open code is_system_domain()
>>  - extended the commit message
>> ---
>>  xen/drivers/Kconfig   |  4 
>>  xen/drivers/passthrough/pci.c | 21 +
>>  xen/drivers/vpci/vpci.c   | 18 ++
>>  xen/include/xen/vpci.h| 15 +++
>>  4 files changed, 58 insertions(+)
>> 
>> diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
>> index db94393f47..780490cf8e 100644
>> --- a/xen/drivers/Kconfig
>> +++ b/xen/drivers/Kconfig
>> @@ -15,4 +15,8 @@ source "drivers/video/Kconfig"
>>  config HAS_VPCI
>>  bool
>>  
>> +config HAS_VPCI_GUEST_SUPPORT
>> +bool
>> +depends on HAS_VPCI
>> +
>>  endmenu
>> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
>> index 6f8692cd9c..265d359704 100644
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -885,6 +885,10 @@ static int deassign_device(struct domain *d, uint16_t 
>> seg, uint8_t bus,
>>  if ( ret )
>>  goto out;
>>  
>> +write_lock(>domain->pci_lock);
>> +vpci_deassign_device(pdev);
>> +write_unlock(>domain->pci_lock);
>> +
>>  if ( pdev->domain == hardware_domain  )
>>  pdev->quarantine = false;
>>  
>> @@ -1484,6 +1488,10 @@ static int assign_device(struct domain *d, u16 seg, 
>> u8 bus, u8 devfn, u32 flag)
>>  if ( pdev->broken && d != hardware_domain && d != dom_io )
>>  goto done;
>>  
>> +write_lock(>domain->pci_lock);
>> +vpci_deassign_device(pdev);
>> +write_unlock(>domain->pci_lock);
>> +
>>  rc = pdev_msix_assign(d, pdev);
>>  if ( rc )
>>  goto done;
>> @@ -1509,6 +1517,19 @@ static int assign_device(struct domain *d, u16 seg, 
>> u8 bus, u8 devfn, u32 flag)
>>  rc = iommu_call(hd->platform_ops, assign_device, d, devfn,
>>  pci_to_dev(pdev), flag);
>>  }
>> +if ( rc )
>> +goto done;
>> +
>> +devfn = pdev->devfn;
>> +write_lock(>domain->pci_lock);
>> +rc = vpci_assign_device(pdev);
>> +write_unlock(>domain->pci_lock);
>> +if ( rc && deassign_device(d, seg, bus, devfn) )
>> +{
>> +printk(XENLOG_ERR "%pd: %pp was left partially assigned\n",
>> +   d, _SBDF(seg, bus, devfn));
>
> >sbdf?  Then you can get of the devfn usage above.

Yes, thanks.

>> +domain_crash(d);
>
> This seems like a bit different from the other error paths in the
> function, isn't it fine to return an error and let the caller handle
> the deassign?

I believe, intention was to not leave device in an unknown state: we
failed both assign_device() and deassign_device() call, so what to do
now? But yes, I think you are right and it is better to let caller to
decide what to do next.

>
> Also, if we really need to call deassign_device() we must do so for
> all possible phantom devices, see the above loop around
> iommu_call(..., assing_device, ...);

But deassign_device() has the loop for all phantom devices that already
does all the work. Unless I miss something, of course.

>> +}
>>  
>>   done:
>>  if ( rc )
>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>> index a6d2cf8660..a97710a806 100644
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
>> @@ -107,6 +107,24 @@ int 

Re: [PATCH v8 02/13] vpci: use per-domain PCI lock to protect vpci structure

[Volodymyr Babchuk]

Hi Roger,

Roger Pau Monné  writes:

> On Thu, Jul 20, 2023 at 12:32:31AM +, Volodymyr Babchuk wrote:
>> From: Oleksandr Andrushchenko 
>> 
>> Use a previously introduced per-domain read/write lock to check
>> whether vpci is present, so we are sure there are no accesses to the
>> contents of the vpci struct if not. This lock can be used (and in a
>> few cases is used right away) so that vpci removal can be performed
>> while holding the lock in write mode. Previously such removal could
>> race with vpci_read for example.
>
> This I think needs to state the locking order of the per-domain
> pci_lock wrt the vpci->lock.  AFAICT that's d->pci_lock first, then
> vpci->lock.

Will add, thanks.

>> 1. Per-domain's pci_rwlock is used to protect pdev->vpci structure
>> from being removed.
>> 
>> 2. Writing the command register and ROM BAR register may trigger
>> modify_bars to run, which in turn may access multiple pdevs while
>> checking for the existing BAR's overlap. The overlapping check, if
>> done under the read lock, requires vpci->lock to be acquired on both
>> devices being compared, which may produce a deadlock. It is not
>> possible to upgrade read lock to write lock in such a case. So, in
>> order to prevent the deadlock, use d->pci_lock instead. To prevent
>> deadlock while locking both hwdom->pci_lock and dom_xen->pci_lock,
>> always lock hwdom first.
>> 
>> All other code, which doesn't lead to pdev->vpci destruction and does
>> not access multiple pdevs at the same time, can still use a
>> combination of the read lock and pdev->vpci->lock.
>> 
>> 3. Drop const qualifier where the new rwlock is used and this is
>> appropriate.
>> 
>> 4. Do not call process_pending_softirqs with any locks held. For that
>> unlock prior the call and re-acquire the locks after. After
>> re-acquiring the lock there is no need to check if pdev->vpci exists:
>>  - in apply_map because of the context it is called (no race condition
>>possible)
>>  - for MSI/MSI-X debug code because it is called at the end of
>>pdev->vpci access and no further access to pdev->vpci is made
>
> I assume that's vpci_msix_arch_print(): there are further accesses to
> pdev->vpci, but those use the msix local variable, which holds a copy
> of the pointer in pdev->vpci->msix, so that last sentence is not true
> I'm afraid.

Yes, I see. I am wondering if we can memorize sbdf and call pci_get_pdev()
after re-acquiring the lock. Of course, there is a slight chance that we
will get another pdev with the same sbdf...

> However the code already try to cater for the pdev going away, and
> hence it's IMO fine.  IOW: your change doesn't make this any better or
> worse.
>
>> 
>> 5. Introduce pcidevs_trylock, so there is a possibility to try locking
>> the pcidev's lock.
>
> I'm confused by this addition, the more that's no used anywhere.  Can
> you defer the addition until the patch that makes use of it?
>

Yup. This is another rebasing artifact. There were users for this
function it the previous version of the patch.

>> 
>> 6. Use d->pci_lock around for_each_pdev and pci_get_pdev_by_domain
>> while accessing pdevs in vpci code.
>> 
>> Suggested-by: Roger Pau Monné 
>> Suggested-by: Jan Beulich 
>> Signed-off-by: Oleksandr Andrushchenko 
>> Signed-off-by: Volodymyr Babchuk 
>> 
>> ---
>> 
>> Changes in v8:
>>  - changed d->vpci_lock to d->pci_lock
>>  - introducing d->pci_lock in a separate patch
>>  - extended locked region in vpci_process_pending
>>  - removed pcidevs_lockis vpci_dump_msi()
>>  - removed some changes as they are not needed with
>>the new locking scheme
>>  - added handling for hwdom && dom_xen case
>> ---
>>  xen/arch/x86/hvm/vmsi.c   |  4 +++
>>  xen/drivers/passthrough/pci.c |  7 +
>>  xen/drivers/vpci/header.c | 18 
>>  xen/drivers/vpci/msi.c| 14 --
>>  xen/drivers/vpci/msix.c   | 52 ++-
>>  xen/drivers/vpci/vpci.c   | 46 +--
>>  xen/include/xen/pci.h |  1 +
>>  7 files changed, 129 insertions(+), 13 deletions(-)
>> 
>> diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
>> index 3cd4923060..8c1bd66b9c 100644
>> --- a/xen/arch/x86/hvm/vmsi.c
>> +++ b/xen/arch/x86/hvm/vmsi.c
>> @@ -895,6 +895,8 @@ int vpci_msix_arch_print(const struct vpci_msix *msix)
>>  {
>>  unsigned int i;
>>  
>> +ASSERT(rw_is_locked(>pdev->domain->pci_lock));
>> +
>>  for ( i = 0; i < msix->max_entries; i++ )
>>  {
>>  const struct vpci_msix_entry *entry = >entries[i];
>> @@ -913,7 +915,9 @@ int vpci_msix_arch_print(const struct vpci_msix *msix)
>>  struct pci_dev *pdev = msix->pdev;
>>  
>>  spin_unlock(>pdev->vpci->lock);
>> +read_unlock(>domain->pci_lock);
>>  process_pending_softirqs();
>> +read_lock(>domain->pci_lock);
>
> This should be a read_trylock(), much like the spin_trylock() below.

vpci_dump_msi() expects that 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  1f8a6a99b225d34cf608f47b2938092e310f9e03
baseline version:
 xen  0b1171be87698bc7d14760383c0770aeb6e41dd4

Last test of basis   182009  2023-07-25 07:00:31 Z0 days
Testing same since   182015  2023-07-25 22:02:06 Z0 days1 attempts


People who touched revisions under test:
  Federico Serafini 
  Jan Beulich 
  Leo Yan 
  Nicola Vetrini 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   0b1171be87..1f8a6a99b2  1f8a6a99b225d34cf608f47b2938092e310f9e03 -> smoke

Re: [XEN PATCH 3/4] automation: Add ECLAIR pipelines

[Simone Ballarin]

Il giorno mar 25 lug 2023 alle ore 22:04 Stefano Stabellini <
sstabell...@kernel.org> ha scritto:

> How do I access "gl-code-quality-report.json" or otherwise any other
> meaningful ECLAIR output? If I browse the job artifacts I see all the
> various logs but no gl-code-quality-report.json.
>

gl-code-quality-report.json is a GitLab-specific artifact that GitLab
exploits
to provide some features called Code Quality (
https://docs.gitlab.com/ee/ci/testing/code_quality.html).
The file is not supposed to be used outside of the context of the Code
Quality
features.

ECLAIR can produce stand-alone artifacts in various formats and
we can decide to store some of them in the job artifacts (see
https://www.bugseng.com/eclair/reports for an exhaustive list).

Scrolling up from the bottom of the job console output I see:
>
> Browse analysis:
> https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp2/ARM64/4732041018/index.html
>
> And if I click on the link, I can access a web interface with the
> results. Is that the intended way to access the job output?
>

The link in the console is just a way to access the analysis results.
Typically the most
convenient one is the message written by the integration in the commit
thread,
see here an example:
https://eclairit.com:8444/swquality/eclair_demo/-/commit/0d312f8ebca6c4e98eabbeaf9b0fcb8b4a4344d9
.
To enable this feature you have to provide an impersonation token to the
integration,
you can find more information on the commit message.

If so, would it be possible to print out the message "Browse
> analysis:..." as the very last message to make it easier to spot? After
> it at the moment I can see:
>
> From https://gitlab.com:443/xen-project/xen
>  * [new branch]4.10.0-shim-comet   ->
> autoPRRemote/4.10.0-shim-comet
>  [...]
>
> The long list of branch names hides the "Browse analysis" link.
>
> Ok. I will try also to remove the warnings.

>
> BTW I really like the graphics output, e.g.:
>
> https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp2/ARM64/4732041018/PROJECT.ecd;/by_service.html#service/first_file
>
> Very nice and clear!
>
>

-- 
Simone Ballarin, M.Sc.

Field Application Engineer, BUGSENG (https://bugseng.com
)

Re: [PATCH mm-unstable v7 12/31] powerpc: Convert various functions to use ptdescs

[kernel test robot]

Hi Vishal,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on next-20230725]
[cannot apply to powerpc/next powerpc/fixes s390/features geert-m68k/for-next 
geert-m68k/for-linus linus/master v6.5-rc3]
[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/Vishal-Moola-Oracle/mm-Add-PAGE_TYPE_OP-folio-functions/20230725-122458
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git 
mm-everything
patch link:
https://lore.kernel.org/r/20230725042051.36691-13-vishal.moola%40gmail.com
patch subject: [PATCH mm-unstable v7 12/31] powerpc: Convert various functions 
to use ptdescs
config: powerpc-randconfig-r034-20230725 
(https://download.01.org/0day-ci/archive/20230726/202307260706.qnpjsnjr-...@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 
4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce: 
(https://download.01.org/0day-ci/archive/20230726/202307260706.qnpjsnjr-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202307260706.qnpjsnjr-...@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/powerpc/mm/pgtable-frag.c:12:
   In file included from include/linux/hardirq.h:11:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:672:
   arch/powerpc/include/asm/io-defs.h:45:1: error: performing pointer 
arithmetic on a null pointer has undefined behavior 
[-Werror,-Wnull-pointer-arithmetic]
  45 | DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c),
 | ^~~
  46 |  (p, b, c), pio, p)
 |  ~~
   arch/powerpc/include/asm/io.h:669:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
 669 | __do_##name al; \
 | ^~
   :40:1: note: expanded from here
  40 | __do_insw
 | ^
   arch/powerpc/include/asm/io.h:610:56: note: expanded from macro '__do_insw'
 610 | #define __do_insw(p, b, n)  readsw((PCI_IO_ADDR)_IO_BASE+(p), 
(b), (n))
 |~^
   In file included from arch/powerpc/mm/pgtable-frag.c:12:
   In file included from include/linux/hardirq.h:11:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:672:
   arch/powerpc/include/asm/io-defs.h:47:1: error: performing pointer 
arithmetic on a null pointer has undefined behavior 
[-Werror,-Wnull-pointer-arithmetic]
  47 | DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c),
 | ^~~
  48 |  (p, b, c), pio, p)
 |  ~~
   arch/powerpc/include/asm/io.h:669:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
 669 | __do_##name al; \
 | ^~
   :42:1: note: expanded from here
  42 | __do_insl
 | ^
   arch/powerpc/include/asm/io.h:611:56: note: expanded from macro '__do_insl'
 611 | #define __do_insl(p, b, n)  readsl((PCI_IO_ADDR)_IO_BASE+(p), 
(b), (n))
 |~^
   In file included from arch/powerpc/mm/pgtable-frag.c:12:
   In file included from include/linux/hardirq.h:11:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:672:
   arch/powerpc/include/asm/io-defs.h:49:1: error: performing pointer 
arithmetic on a null pointer has undefined behavior 
[-Werror,-Wnull-pointer-arithmetic]
  49 | DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned 
long c),
 | 
^~
  50 |  (p, b, c), pio, p)
 |  ~~
   arch/powerpc/include/asm/io.h:669:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
 669 | __do_##n

[xen-4.17-testing test] 181997: tolerable FAIL - PUSHED

[osstest service owner]

flight 181997 xen-4.17-testing real [real]
flight 182014 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181997/
http://logs.test-lab.xenproject.org/osstest/logs/182014/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-migrupgrade 11 xen-install/dst_host fail in 182014 pass in 
181997
 test-amd64-i386-migrupgrade 10 xen-install/src_host fail pass in 182014-retest

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

version targeted for testing:
 xen  3141a0b85c37b76e069ec7dcb906ff202f5c4075
baseline version:
 xen  

[PATCH] x86/cpu-policy: Advertise MSR_ARCH_CAPS to guests by default

[Andrew Cooper]

With xl/libxl now able to control the policy bits for MSR_ARCH_CAPS, it is
safe to advertise to guests by default.  In turn, we don't need the special
case to expose details to dom0.

This advertises MSR_ARCH_CAPS to guests on *all* Intel hardware, even if the
register content ends up being empty.  This is necessary in order to safely
level two hosts which cross the Broadwell/Skylake divide.

On Cascade Lake and later hardware, guests can now see RDCL_NO (not vulnerable
to Meltdown) amongst others.  This causes substantial performance
improvements, as guests are no longer applying software mitigations in cases
where they don't need to.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 

Not to go in before Roger's libxl changes...
---
 xen/arch/x86/cpu-policy.c   | 11 ---
 xen/include/public/arch-x86/cpufeatureset.h |  2 +-
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index f40eeb8be8dc..1f954d4e5940 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -888,17 +888,6 @@ void __init init_dom0_cpuid_policy(struct domain *d)
 if ( cpu_has_itsc )
 p->extd.itsc = true;
 
-/*
- * Expose the "hardware speculation behaviour" bits of ARCH_CAPS to dom0,
- * so dom0 can turn off workarounds as appropriate.  Temporary, until the
- * domain policy logic gains a better understanding of MSRs.
- */
-if ( is_hardware_domain(d) && cpu_has_arch_caps )
-{
-p->feat.arch_caps = true;
-p->arch_caps.raw = host_cpu_policy.arch_caps.raw;
-}
-
 /* Apply dom0-cpuid= command line settings, if provided. */
 if ( dom0_cpuid_cmdline )
 {
diff --git a/xen/include/public/arch-x86/cpufeatureset.h 
b/xen/include/public/arch-x86/cpufeatureset.h
index ce7407d6a10c..6d20810cb9d1 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -271,7 +271,7 @@ XEN_CPUFEATURE(AVX512_FP16,   9*32+23) /*A  AVX512 FP16 
instructions */
 XEN_CPUFEATURE(IBRSB, 9*32+26) /*A  IBRS and IBPB support (used by 
Intel) */
 XEN_CPUFEATURE(STIBP, 9*32+27) /*A  STIBP */
 XEN_CPUFEATURE(L1D_FLUSH, 9*32+28) /*S  MSR_FLUSH_CMD and L1D flush. */
-XEN_CPUFEATURE(ARCH_CAPS, 9*32+29) /*!a IA32_ARCH_CAPABILITIES MSR */
+XEN_CPUFEATURE(ARCH_CAPS, 9*32+29) /*!A IA32_ARCH_CAPABILITIES MSR */
 XEN_CPUFEATURE(CORE_CAPS, 9*32+30) /*   IA32_CORE_CAPABILITIES MSR */
 XEN_CPUFEATURE(SSBD,  9*32+31) /*A  MSR_SPEC_CTRL.SSBD available */
 
-- 
2.30.2

Re: [XEN PATCH v3] xen/spinlock: mechanically rename parameter name 'debug'

[Stefano Stabellini]

On Tue, 25 Jul 2023, Nicola Vetrini wrote:
> Rule 5.3 has the following headline:
> "An identifier declared in an inner scope shall not hide an
> identifier declared in an outer scope"
> 
> To avoid any confusion resulting from the parameter 'debug'
> hiding the homonymous function declared at
> 'xen/arch/x86/include/asm/processor.h:428'
> the rename of parameters s/debug/lkdbg/ is performed.
> 
> Signed-off-by: Nicola Vetrini 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v2:
> - s/dbg/lkdbg/
> Changes in v3:
> - Added missing renames for consistency
> ---
>  xen/common/spinlock.c  | 38 +++---
>  xen/include/xen/spinlock.h |  6 +++---
>  2 files changed, 22 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
> index 7f453234a9..d4088f910d 100644
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -78,7 +78,7 @@ static int __init cf_check lockdebug_init(void)
>  }
>  presmp_initcall(lockdebug_init);
>  
> -void check_lock(union lock_debug *debug, bool try)
> +void check_lock(union lock_debug *lkdbg, bool try)
>  {
>  bool irq_safe = !local_irq_is_enabled();
>  unsigned int cpu = smp_processor_id();
> @@ -118,12 +118,12 @@ void check_lock(union lock_debug *debug, bool try)
>  if ( try && irq_safe )
>  return;
>  
> -if ( unlikely(debug->irq_safe != irq_safe) )
> +if ( unlikely(lkdbg->irq_safe != irq_safe) )
>  {
>  union lock_debug seen, new = { 0 };
>  
>  new.irq_safe = irq_safe;
> -seen.val = cmpxchg(>val, LOCK_DEBUG_INITVAL, new.val);
> +seen.val = cmpxchg(>val, LOCK_DEBUG_INITVAL, new.val);
>  
>  if ( !seen.unseen && seen.irq_safe == !irq_safe )
>  {
> @@ -137,14 +137,14 @@ void check_lock(union lock_debug *debug, bool try)
>  return;
>  
>  for ( i = 0; i < nr_taken; i++ )
> -if ( taken[i] == debug )
> +if ( taken[i] == lkdbg )
>  {
> -printk("CHECKLOCK FAILURE: lock at %p taken recursively\n", 
> debug);
> +printk("CHECKLOCK FAILURE: lock at %p taken recursively\n", 
> lkdbg);
>  BUG();
>  }
>  }
>  
> -static void check_barrier(union lock_debug *debug)
> +static void check_barrier(union lock_debug *lkdbg)
>  {
>  if ( unlikely(atomic_read(_debug) <= 0) )
>  return;
> @@ -160,10 +160,10 @@ static void check_barrier(union lock_debug *debug)
>   * However, if we spin on an IRQ-unsafe lock with IRQs disabled then that
>   * is clearly wrong, for the same reason outlined in check_lock() above.
>   */
> -BUG_ON(!local_irq_is_enabled() && !debug->irq_safe);
> +BUG_ON(!local_irq_is_enabled() && !lkdbg->irq_safe);
>  }
>  
> -void lock_enter(const union lock_debug *debug)
> +void lock_enter(const union lock_debug *lkdbg)
>  {
>  unsigned int cpu = smp_processor_id();
>  const union lock_debug **taken = per_cpu(locks_taken, cpu);
> @@ -176,7 +176,7 @@ void lock_enter(const union lock_debug *debug)
>  local_irq_save(flags);
>  
>  if ( *nr_taken < lock_depth_size )
> -taken[(*nr_taken)++] = debug;
> +taken[(*nr_taken)++] = lkdbg;
>  else if ( !max_depth_reached )
>  {
>  max_depth_reached = true;
> @@ -187,7 +187,7 @@ void lock_enter(const union lock_debug *debug)
>  local_irq_restore(flags);
>  }
>  
> -void lock_exit(const union lock_debug *debug)
> +void lock_exit(const union lock_debug *lkdbg)
>  {
>  unsigned int cpu = smp_processor_id();
>  const union lock_debug **taken = per_cpu(locks_taken, cpu);
> @@ -202,7 +202,7 @@ void lock_exit(const union lock_debug *debug)
>  
>  for ( i = *nr_taken; i > 0; i-- )
>  {
> -if ( taken[i - 1] == debug )
> +if ( taken[i - 1] == lkdbg )
>  {
>  memmove(taken + i - 1, taken + i,
>  (*nr_taken - i) * sizeof(*taken));
> @@ -217,28 +217,28 @@ void lock_exit(const union lock_debug *debug)
>  
>  if ( !max_depth_reached )
>  {
> -printk("CHECKLOCK released lock at %p not recorded!\n", debug);
> +printk("CHECKLOCK released lock at %p not recorded!\n", lkdbg);
>  WARN();
>  }
>  
>  local_irq_restore(flags);
>  }
>  
> -static void got_lock(union lock_debug *debug)
> +static void got_lock(union lock_debug *lkdbg)
>  {
> -debug->cpu = smp_processor_id();
> +lkdbg->cpu = smp_processor_id();
>  
> -lock_enter(debug);
> +lock_enter(lkdbg);
>  }
>  
> -static void rel_lock(union lock_debug *debug)
> +static void rel_lock(union lock_debug *lkdbg)
>  {
>  if ( atomic_read(_debug) > 0 )
> -BUG_ON(debug->cpu != smp_processor_id());
> +BUG_ON(lkdbg->cpu != smp_processor_id());
>  
> -lock_exit(debug);
> +lock_exit(lkdbg);
>  
> -debug->cpu = SPINLOCK_NO_CPU;
> +lkdbg->cpu = SPINLOCK_NO_CPU;
>  }
>  
>  void spin_debug_enable(void)
> diff --git a/xen/include/xen/spinlock.h 

[XEN PATCH v3] xen/spinlock: mechanically rename parameter name 'debug'

[Nicola Vetrini]

Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"

To avoid any confusion resulting from the parameter 'debug'
hiding the homonymous function declared at
'xen/arch/x86/include/asm/processor.h:428'
the rename of parameters s/debug/lkdbg/ is performed.

Signed-off-by: Nicola Vetrini 
---
Changes in v2:
- s/dbg/lkdbg/
Changes in v3:
- Added missing renames for consistency
---
 xen/common/spinlock.c  | 38 +++---
 xen/include/xen/spinlock.h |  6 +++---
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 7f453234a9..d4088f910d 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -78,7 +78,7 @@ static int __init cf_check lockdebug_init(void)
 }
 presmp_initcall(lockdebug_init);
 
-void check_lock(union lock_debug *debug, bool try)
+void check_lock(union lock_debug *lkdbg, bool try)
 {
 bool irq_safe = !local_irq_is_enabled();
 unsigned int cpu = smp_processor_id();
@@ -118,12 +118,12 @@ void check_lock(union lock_debug *debug, bool try)
 if ( try && irq_safe )
 return;
 
-if ( unlikely(debug->irq_safe != irq_safe) )
+if ( unlikely(lkdbg->irq_safe != irq_safe) )
 {
 union lock_debug seen, new = { 0 };
 
 new.irq_safe = irq_safe;
-seen.val = cmpxchg(>val, LOCK_DEBUG_INITVAL, new.val);
+seen.val = cmpxchg(>val, LOCK_DEBUG_INITVAL, new.val);
 
 if ( !seen.unseen && seen.irq_safe == !irq_safe )
 {
@@ -137,14 +137,14 @@ void check_lock(union lock_debug *debug, bool try)
 return;
 
 for ( i = 0; i < nr_taken; i++ )
-if ( taken[i] == debug )
+if ( taken[i] == lkdbg )
 {
-printk("CHECKLOCK FAILURE: lock at %p taken recursively\n", debug);
+printk("CHECKLOCK FAILURE: lock at %p taken recursively\n", lkdbg);
 BUG();
 }
 }
 
-static void check_barrier(union lock_debug *debug)
+static void check_barrier(union lock_debug *lkdbg)
 {
 if ( unlikely(atomic_read(_debug) <= 0) )
 return;
@@ -160,10 +160,10 @@ static void check_barrier(union lock_debug *debug)
  * However, if we spin on an IRQ-unsafe lock with IRQs disabled then that
  * is clearly wrong, for the same reason outlined in check_lock() above.
  */
-BUG_ON(!local_irq_is_enabled() && !debug->irq_safe);
+BUG_ON(!local_irq_is_enabled() && !lkdbg->irq_safe);
 }
 
-void lock_enter(const union lock_debug *debug)
+void lock_enter(const union lock_debug *lkdbg)
 {
 unsigned int cpu = smp_processor_id();
 const union lock_debug **taken = per_cpu(locks_taken, cpu);
@@ -176,7 +176,7 @@ void lock_enter(const union lock_debug *debug)
 local_irq_save(flags);
 
 if ( *nr_taken < lock_depth_size )
-taken[(*nr_taken)++] = debug;
+taken[(*nr_taken)++] = lkdbg;
 else if ( !max_depth_reached )
 {
 max_depth_reached = true;
@@ -187,7 +187,7 @@ void lock_enter(const union lock_debug *debug)
 local_irq_restore(flags);
 }
 
-void lock_exit(const union lock_debug *debug)
+void lock_exit(const union lock_debug *lkdbg)
 {
 unsigned int cpu = smp_processor_id();
 const union lock_debug **taken = per_cpu(locks_taken, cpu);
@@ -202,7 +202,7 @@ void lock_exit(const union lock_debug *debug)
 
 for ( i = *nr_taken; i > 0; i-- )
 {
-if ( taken[i - 1] == debug )
+if ( taken[i - 1] == lkdbg )
 {
 memmove(taken + i - 1, taken + i,
 (*nr_taken - i) * sizeof(*taken));
@@ -217,28 +217,28 @@ void lock_exit(const union lock_debug *debug)
 
 if ( !max_depth_reached )
 {
-printk("CHECKLOCK released lock at %p not recorded!\n", debug);
+printk("CHECKLOCK released lock at %p not recorded!\n", lkdbg);
 WARN();
 }
 
 local_irq_restore(flags);
 }
 
-static void got_lock(union lock_debug *debug)
+static void got_lock(union lock_debug *lkdbg)
 {
-debug->cpu = smp_processor_id();
+lkdbg->cpu = smp_processor_id();
 
-lock_enter(debug);
+lock_enter(lkdbg);
 }
 
-static void rel_lock(union lock_debug *debug)
+static void rel_lock(union lock_debug *lkdbg)
 {
 if ( atomic_read(_debug) > 0 )
-BUG_ON(debug->cpu != smp_processor_id());
+BUG_ON(lkdbg->cpu != smp_processor_id());
 
-lock_exit(debug);
+lock_exit(lkdbg);
 
-debug->cpu = SPINLOCK_NO_CPU;
+lkdbg->cpu = SPINLOCK_NO_CPU;
 }
 
 void spin_debug_enable(void)
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 0a02a527dc..464af705eb 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -22,9 +22,9 @@ union lock_debug {
 };
 };
 #define _LOCK_DEBUG { LOCK_DEBUG_INITVAL }
-void check_lock(union lock_debug *debug, bool try);
-void lock_enter(const union lock_debug *debug);
-void lock_exit(const union lock_debug *debug);
+void 

Re: [XEN PATCH v2] xen/spinlock: mechanically rename parameter name 'debug'

[Stefano Stabellini]

On Tue, 25 Jul 2023, Nicola Vetrini wrote:
> On 25/07/23 21:37, Stefano Stabellini wrote:
> > On Tue, 25 Jul 2023, Jan Beulich wrote:
> > > On 25.07.2023 11:17, Nicola Vetrini wrote:
> > > > Rule 5.3 has the following headline:
> > > > "An identifier declared in an inner scope shall not hide an
> > > > identifier declared in an outer scope"
> > > > 
> > > > To avoid any confusion resulting from the parameter 'debug'
> > > > hiding the homonymous function declared at
> > > > 'xen/arch/x86/include/asm/processor.h:428'
> > > > the rename of parameters s/debug/lkdbg/ is performed.
> > > > 
> > > > Signed-off-by: Nicola Vetrini 
> > > > ---
> > > > Changes in v2:
> > > > - s/dbg/lkdbg/
> > > 
> > > But only in some of the cases. E.g. ...
> > > 
> > > > -static void check_barrier(union lock_debug *debug)
> > > > +static void check_barrier(union lock_debug *dbg)
> > > 
> > > ... not here (there are a few more).
> > 
> > I agree with Jan: these are all union lock_debug parameters, so it would
> > make sense to me to use lkdbg everywhere in this patch.
> 
> Yes, indeed, that's unintentional. Can this be done on commit or should I send
> a v3?

Please send an update if possible

Re: [XEN PATCH v2] xen/spinlock: mechanically rename parameter name 'debug'

[Nicola Vetrini]

On 25/07/23 21:37, Stefano Stabellini wrote:

On Tue, 25 Jul 2023, Jan Beulich wrote:

On 25.07.2023 11:17, Nicola Vetrini wrote:

Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"

To avoid any confusion resulting from the parameter 'debug'
hiding the homonymous function declared at
'xen/arch/x86/include/asm/processor.h:428'
the rename of parameters s/debug/lkdbg/ is performed.

Signed-off-by: Nicola Vetrini 
---
Changes in v2:
- s/dbg/lkdbg/


But only in some of the cases. E.g. ...


-static void check_barrier(union lock_debug *debug)
+static void check_barrier(union lock_debug *dbg)


... not here (there are a few more).


I agree with Jan: these are all union lock_debug parameters, so it would
make sense to me to use lkdbg everywhere in this patch.


Yes, indeed, that's unintentional. Can this be done on commit or should 
I send a v3?


Regards,

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [RFC PATCH 0/4] fix some issues related to MISRA C:2012 Rule 9.1

[Stefano Stabellini]

For the record, as I mentioned during the call today, I asked to
postpone the 9.1 work for later, because it is going to take a lot of
work and discussions to figure out a good way forward for all these
cases. There are at least 3-5 different sub-classes for this issues. So
I think it would be better for the Xen community to make more progress
with other rules and violations fixes first.


On Fri, 14 Jul 2023, Nicola Vetrini wrote:
> This patch series is aimed at discussing different categories of
> patterns concerning local variables that are possibly not
> initialized in all code paths, which results in hard-to-prove
> correctness. The main categories are as follows:
> 
> 1. Variables initialized by passing a pointer to them to a function.
>Many such functions are coupled with error handling which results
>in the variable not being initialized.
> 
> 2. Some variables are used in switch statements and the control flow
>ensures that all code paths do initialize them, but due to the
>presence of goto statements, the flow is harder to follow.
> 
> I emphasize that, as far as I can tell, the code is already
> compliant with the rule, but there is room for improvement, especially
> on the side of allowing automatic checks to be more effective.
> 
> Nicola Vetrini (4):
>   xen/arm: justify or initialize conditionally uninitialized variables
>   xen/arm64: bitops: justify uninitialized variable inside a macro
>   xen/arm: initialize conditionally uninitialized local variables
>   xen/arm: initialize conditionally uninitialized local variables
> 
>  docs/misra/safe.json| 24 +++
>  xen/arch/arm/arm64/lib/bitops.c |  3 ++
>  xen/arch/arm/arm64/lib/find_next_bit.c  |  1 +
>  xen/arch/arm/bootfdt.c  |  6 
>  xen/arch/arm/cpuerrata.c|  6 ++--
>  xen/arch/arm/decode.c   |  2 ++
>  xen/arch/arm/dm.c   |  2 +-
>  xen/arch/arm/domain_build.c | 29 ++
>  xen/arch/arm/domctl.c   |  8 ++---
>  xen/arch/arm/efi/efi-boot.h |  6 ++--
>  xen/arch/arm/gic-v3-its.c   |  9 +++---
>  xen/arch/arm/gic-v3-lpi.c   | 17 ++-
>  xen/arch/arm/guest_walk.c   | 12 
>  xen/arch/arm/include/asm/guest_atomics.h|  3 ++
>  xen/arch/arm/include/asm/p2m.h  | 10 ---
>  xen/arch/arm/mm.c   |  1 +
>  xen/arch/arm/p2m.c  | 33 -
>  xen/arch/arm/platforms/xilinx-zynqmp-eemi.c | 10 ++-
>  xen/arch/arm/psci.c | 10 +++
>  xen/drivers/char/pl011.c|  2 +-
>  20 files changed, 129 insertions(+), 65 deletions(-)
> 
> --
> 2.34.1
> 

Re: [XEN PATCH 4/4] maintainers: Add ECLAIR reviewer

[Stefano Stabellini]

On Tue, 25 Jul 2023, Simone Ballarin wrote:
> Signed-off-by: Simone Ballarin 
> 
> --
> Changes in v3:
> - split maintainer add in a separate patch;
> - substitute blanks with tabs;
> - fix file paths;
> - change role from maintainer to reviewer.
> 
> Changes in v2:
> - add ECLAIR configuration files (before they were fetched from a separate
>   repository);
> - now the pipeline fails if there are new violations of guidelines tagged
>   with clean:added.
> ---
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 180e57dac4..66ff0ed710 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -305,6 +305,12 @@ F:   xen/include/xen/libfdt/
>  F:   xen/include/xen/device_tree.h
>  F:   xen/drivers/passthrough/device_tree.c
>  
> +ECLAIR
> +R:   Simone Ballarin 
> +S:   Supported
> +F:   automation/eclair_analysis/
> +F:   automation/scripts/eclair

There is still a whitespace problem: it is supposed to be only tabs, not
1 space then 1 tab. However, it can be fixed on commit:

Acked-by: Stefano Stabellini 



>  EFI
>  M:   Jan Beulich 
>  S:   Supported
> -- 
> 2.34.1
> 

Re: [XEN PATCH 3/4] automation: Add ECLAIR pipelines

[Stefano Stabellini]

On Tue, 25 Jul 2023, Simone Ballarin wrote:
> Add two pipelines that analyze an ARM64 and a X86_64 build with the
> ECLAIR static analyzer on the guidelines contained in Set1.
> 
> The analysis configuration is stored in automation/eclair_analysis.
> 
> All commits on the xen-project/xen:staging branch will be analyzed
> and their artifacts will be stored indefinitely; the integration will
> report differential information with respect to the previous analysis.
> 
> All commits on other branches or repositories will be analyzed and
> only the last ten artifacts will be kept; the integration will report
> differential information with respect to the analysis done on the common
> ancestor with xen-project/xen:staging (if available).
> 
> Currently the pipeline variable ENABLE_ECLAIR_BOT is set to "n".
> Doing so disables the generation of comments with the analysis summary
> on the commit threads. The variable can be set to "y" if the a masked
> variable named ECLAIR_BOT_TOKEN is set with the impersonation token of
> an account with enough privileges to write on all repositories.
> 
> Additionaly any repository should be able to read a masked variable
> named WTOKEN with the token provided by BUGSENG.
> 
> The analysis fails if it contains violations of guidelines tagged as
> clean:added. The list of clean guidelines are maintained in
> automation/eclair_analysis/ECLAIR/tagging.ecl.
> 
> Signed-off-by: Simone Ballarin 

This patch looks good to me, just one question before I give my
acked-by.


> --
> Changes in v3:
> - split definitions of the ECLAIR pipelines in a separate patch;
> - if the WTOKEN variable is missing now the analysis fails immediately.
> 
> Changes in v2:
> - add ECLAIR configuration files (before they were fetched from a separate
> repository);
> - now the pipeline fails if there are new violations of guidelines tagged
> with clean:added.
> ---
>  .gitlab-ci.yml|  2 ++
>  automation/gitlab-ci/analyze.yaml | 38 +++
>  automation/gitlab-ci/build.yaml   |  1 +
>  automation/scripts/eclair | 34 +++
>  4 files changed, 75 insertions(+)
>  create mode 100644 automation/gitlab-ci/analyze.yaml
>  create mode 100755 automation/scripts/eclair
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index c8bd7519d5..ee5430b8b7 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -1,7 +1,9 @@
>  stages:
> +  - analyze
>- build
>- test
>  
>  include:
> +  - 'automation/gitlab-ci/analyze.yaml'
>- 'automation/gitlab-ci/build.yaml'
>- 'automation/gitlab-ci/test.yaml'
> diff --git a/automation/gitlab-ci/analyze.yaml 
> b/automation/gitlab-ci/analyze.yaml
> new file mode 100644
> index 00..3d8166572b
> --- /dev/null
> +++ b/automation/gitlab-ci/analyze.yaml
> @@ -0,0 +1,38 @@
> +.eclair-analysis:
> +  stage: analyze
> +  tags:
> +- eclair-analysis
> +  variables:
> +ECLAIR_OUTPUT_DIR: "ECLAIR_out"
> +ANALYSIS_KIND: "normal"
> +ENABLE_ECLAIR_BOT: "n"
> +AUTO_PR_BRANCH: "staging"
> +AUTO_PR_REPOSITORY: "xen-project/xen"
> +  artifacts:
> +when: always
> +paths:
> +  - "${ECLAIR_OUTPUT_DIR}/*.log"
> +  - "${ECLAIR_OUTPUT_DIR}/*.txt"
> +  - '*.log'
> +reports:
> +  codequality: gl-code-quality-report.json

How do I access "gl-code-quality-report.json" or otherwise any other
meaningful ECLAIR output? If I browse the job artifacts I see all the
various logs but no gl-code-quality-report.json.

Scrolling up from the bottom of the job console output I see:

Browse analysis: 
https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp2/ARM64/4732041018/index.html

And if I click on the link, I can access a web interface with the
results. Is that the intended way to access the job output?

If so, would it be possible to print out the message "Browse
analysis:..." as the very last message to make it easier to spot? After
it at the moment I can see:

>From https://gitlab.com:443/xen-project/xen
 * [new branch]4.10.0-shim-comet   -> autoPRRemote/4.10.0-shim-comet
 [...]

The long list of branch names hides the "Browse analysis" link.


BTW I really like the graphics output, e.g.:
https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/people/sstabellini/xen/ECLAIR_normal/ppp2/ARM64/4732041018/PROJECT.ecd;/by_service.html#service/first_file

Very nice and clear!


> +eclair-x86_64:
> +  extends: .eclair-analysis
> +  variables:
> +LOGFILE: "eclair-x86_64.log"
> +VARIANT: "X86_64"
> +RULESET: "Set1"
> +  script:
> +- ./automation/scripts/eclair 2>&1 | tee "${LOGFILE}"
> +  allow_failure: true
> +
> +eclair-ARM64:
> +  extends: .eclair-analysis
> +  variables:
> +LOGFILE: "eclair-ARM64.log"
> +VARIANT: "ARM64"
> +RULESET: "Set1"
> +  script:
> +- ./automation/scripts/eclair 2>&1 | tee "${LOGFILE}"
> +  allow_failure: true
> diff 

Re: [XEN PATCH 2/4] automation: Add xen builds for the ECLAIR analyses

[Stefano Stabellini]

On Tue, 25 Jul 2023, Simone Ballarin wrote:
> This patch defines an ARM64 and a X86_64 build for the
> ECLAIR pipelines.
> 
> These files are used by the analyze.sh script in
> automation/eclair_analysis: it initially calls prepare.sh,
> then runs into an ECLAIR environment build.sh.
> 
> Only the toolchain invocations triggered by build.sh
> are analyzed; the prepare.sh script is instead intended
> to perform all the required operations for building xen
> that are not supposed to be analyzed: e.g. dependencies
> build.
> 
> Signed-off-by: Simone Ballarin 

Reviewed-by: Stefano Stabellini 


> --
> Changes in v3:
> - split build definitions in a separate patch.
> 
> Changes in v2:
> - add ECLAIR configuration files (before they were fetched from a separate
>   repository);
> - now the pipeline fails if there are new violations of guidelines tagged
>   with clean:added.
> ---
>  automation/eclair_analysis/Makefile.prepare |   6 +
>  automation/eclair_analysis/build.sh |  44 ++
>  automation/eclair_analysis/prepare.sh   |  42 ++
>  automation/eclair_analysis/xen_arm_config   | 147 +++
>  automation/eclair_analysis/xen_x86_config   | 152 
>  5 files changed, 391 insertions(+)
>  create mode 100644 automation/eclair_analysis/Makefile.prepare
>  create mode 100755 automation/eclair_analysis/build.sh
>  create mode 100755 automation/eclair_analysis/prepare.sh
>  create mode 100644 automation/eclair_analysis/xen_arm_config
>  create mode 100644 automation/eclair_analysis/xen_x86_config
> 
> diff --git a/automation/eclair_analysis/Makefile.prepare 
> b/automation/eclair_analysis/Makefile.prepare
> new file mode 100644
> index 00..90f4a31172
> --- /dev/null
> +++ b/automation/eclair_analysis/Makefile.prepare
> @@ -0,0 +1,6 @@
> +include Makefile
> +prepare:
> + $(Q)$(MAKE) $(build)=tools
> + $(Q)$(MAKE) $(build)=. include/xen/compile.h
> + $(Q)$(MAKE) $(build)=include all
> + $(Q)$(MAKE) $(build)=arch/$(SRCARCH) include
> diff --git a/automation/eclair_analysis/build.sh 
> b/automation/eclair_analysis/build.sh
> new file mode 100755
> index 00..ec087dd822
> --- /dev/null
> +++ b/automation/eclair_analysis/build.sh
> @@ -0,0 +1,44 @@
> +#!/bin/bash
> +# Stop immediately if any executed command has exit status different from 0.
> +set -e
> +
> +script_name="$(basename "$0")"
> +
> +fatal() {
> +  echo "${script_name}: $*" >&2
> +  exit 1
> +}
> +
> +usage() {
> +  fatal "Usage: ${script_name} "
> +}
> +
> +if [ $# -ne 1 ]; then
> +  usage
> +fi
> +
> +if [ "$1" = "X86_64" ]; then
> +  export CROSS_COMPILE=
> +  export XEN_TARGET_ARCH=x86_64
> +elif [ "$1" = "ARM64" ]; then
> +  export CROSS_COMPILE=aarch64-linux-gnu-
> +  export XEN_TARGET_ARCH=arm64
> +else
> +  fatal "Unknown configuration: $1"
> +fi
> +
> +if [[ -f /proc/cpuinfo ]]; then
> +  PROCESSORS=$(grep -c ^processor /proc/cpuinfo)
> +else
> +  PROCESSORS=6
> +fi
> +
> +(
> +  cd xen
> +
> +  make "-j${PROCESSORS}" "-l${PROCESSORS}.0"\
> +   "CROSS_COMPILE=${CROSS_COMPILE}" \
> +   "CC=${CROSS_COMPILE}gcc-12"  \
> +   "CXX=${CROSS_COMPILE}g++-12" \
> +   "XEN_TARGET_ARCH=${XEN_TARGET_ARCH}"
> +)
> diff --git a/automation/eclair_analysis/prepare.sh 
> b/automation/eclair_analysis/prepare.sh
> new file mode 100755
> index 00..275a1a3f51
> --- /dev/null
> +++ b/automation/eclair_analysis/prepare.sh
> @@ -0,0 +1,42 @@
> +#!/bin/bash
> +# Stop immediately if any executed command has exit status different from 0.
> +set -e
> +
> +script_name="$(basename "$0")"
> +script_dir="$(
> +  cd "$(dirname "$0")"
> +  echo "${PWD}"
> +)"
> +
> +fatal() {
> +  echo "${script_name}: $*" >&2
> +  exit 1
> +}
> +
> +usage() {
> +  fatal "Usage: ${script_name}"
> +}
> +
> +if [ $# -ne 1 ]; then
> +  usage
> +  exit 1
> +fi
> +
> +export XEN_TARGET_ARCH
> +
> +if [ "$1" = "X86_64" ]; then
> +  CONFIG_FILE="${script_dir}/xen_x86_config"
> +  XEN_TARGET_ARCH=x86_64
> +elif [ "$1" = "ARM64" ]; then
> +  CONFIG_FILE="${script_dir}/xen_arm_config"
> +  XEN_TARGET_ARCH=arm64
> +else
> +  fatal "Unknown configuration: $1"
> +fi
> +
> +(
> +cd xen
> +cp "${CONFIG_FILE}" .config
> +make clean
> +make -f ${script_dir}/Makefile.prepare prepare
> +)
> diff --git a/automation/eclair_analysis/xen_arm_config 
> b/automation/eclair_analysis/xen_arm_config
> new file mode 100644
> index 00..82102b889e
> --- /dev/null
> +++ b/automation/eclair_analysis/xen_arm_config
> @@ -0,0 +1,147 @@
> +# File provided in
> +# Re: Xen MISRA C: Source files in scope and out of scope
> +# from:  Stefano Stabellini 
> +# date:  6 giu 2023, 02:53
> +
> +#
> +# Automatically generated file; DO NOT EDIT.
> +# Xen/arm 4.18-unstable Configuration
> +#
> +CONFIG_CC_IS_GCC=y
> +CONFIG_GCC_VERSION=90400
> +CONFIG_CLANG_VERSION=0
> +CONFIG_LD_IS_GNU=y
> +CONFIG_CC_HAS_VISIBILITY_ATTRIBUTE=y
> +CONFIG_ARM_64=y
> +CONFIG_ARM=y
> 

Re: [XEN PATCH 1/4] automation: Add ECLAIR utilities and settings

[Stefano Stabellini]

On Tue, 25 Jul 2023, Simone Ballarin wrote:
> The files with extension ecl are ECLAIR configurations that
> are loaded during the analysis phase or during the report
> generation phase: analysis.ecl is the main file for the analysis
> phase, while reports.ecl is the one for the report phase.
> All other ecl files are included by one of the two main ones.
> 
> The actions* scripts implement the integration with the CI server,
> they are completely general and can be amended to work with any CI
> server. Their presence in xen.git is recommended so that maintainance
> would be easier.
> 
> analyze.sh is the script that actually triggers the analysis.
> 
> Signed-off-by: Simone Ballarin 

Acked-by: Stefano Stabellini 


> --
> Changes in v3:
> - split ECLAIR configurations and scripts in a separate patch;
> - remove references to "Task (a): Xen Coding Guidelines v1.0".
> 
> Changes in v2:
> - add ECLAIR configuration files (before they were fetched from a separate
> repository);
> - now the pipeline fails if there are new violations of guidelines tagged
> with clean:added.
> ---
>  automation/eclair_analysis/ECLAIR/Set1.ecl|  59 
>  automation/eclair_analysis/ECLAIR/Set2.ecl|  25 ++
>  automation/eclair_analysis/ECLAIR/Set3.ecl|  67 
>  .../eclair_analysis/ECLAIR/action.helpers | 193 
>  .../eclair_analysis/ECLAIR/action.settings| 172 ++
>  .../ECLAIR/action_clean_added.sh  |  36 +++
>  .../eclair_analysis/ECLAIR/action_log.sh  |  15 +
>  .../ECLAIR/action_pull_request.sh |  57 
>  .../eclair_analysis/ECLAIR/action_push.sh |  95 ++
>  .../ECLAIR/action_upload_sarif.sh |  31 ++
>  .../eclair_analysis/ECLAIR/analysis.ecl   |  25 ++
>  automation/eclair_analysis/ECLAIR/analyze.sh  | 106 +++
>  .../ECLAIR/call_properties.ecl| 106 +++
>  .../eclair_analysis/ECLAIR/deviations.ecl | 298 ++
>  .../eclair_analysis/ECLAIR/out_of_scope.ecl   | 127 
>  .../ECLAIR/print_analyzed_files.sh|  66 
>  .../eclair_analysis/ECLAIR/public_APIs.ecl|   6 +
>  automation/eclair_analysis/ECLAIR/report.ecl  |   4 +
>  automation/eclair_analysis/ECLAIR/tagging.ecl |  34 ++
>  .../eclair_analysis/ECLAIR/toolchain.ecl  | 275 
>  20 files changed, 1797 insertions(+)
>  create mode 100644 automation/eclair_analysis/ECLAIR/Set1.ecl
>  create mode 100644 automation/eclair_analysis/ECLAIR/Set2.ecl
>  create mode 100644 automation/eclair_analysis/ECLAIR/Set3.ecl
>  create mode 100644 automation/eclair_analysis/ECLAIR/action.helpers
>  create mode 100644 automation/eclair_analysis/ECLAIR/action.settings
>  create mode 100755 automation/eclair_analysis/ECLAIR/action_clean_added.sh
>  create mode 100755 automation/eclair_analysis/ECLAIR/action_log.sh
>  create mode 100644 automation/eclair_analysis/ECLAIR/action_pull_request.sh
>  create mode 100755 automation/eclair_analysis/ECLAIR/action_push.sh
>  create mode 100755 automation/eclair_analysis/ECLAIR/action_upload_sarif.sh
>  create mode 100644 automation/eclair_analysis/ECLAIR/analysis.ecl
>  create mode 100755 automation/eclair_analysis/ECLAIR/analyze.sh
>  create mode 100644 automation/eclair_analysis/ECLAIR/call_properties.ecl
>  create mode 100644 automation/eclair_analysis/ECLAIR/deviations.ecl
>  create mode 100644 automation/eclair_analysis/ECLAIR/out_of_scope.ecl
>  create mode 100755 automation/eclair_analysis/ECLAIR/print_analyzed_files.sh
>  create mode 100644 automation/eclair_analysis/ECLAIR/public_APIs.ecl
>  create mode 100644 automation/eclair_analysis/ECLAIR/report.ecl
>  create mode 100644 automation/eclair_analysis/ECLAIR/tagging.ecl
>  create mode 100644 automation/eclair_analysis/ECLAIR/toolchain.ecl
> 
> diff --git a/automation/eclair_analysis/ECLAIR/Set1.ecl 
> b/automation/eclair_analysis/ECLAIR/Set1.ecl
> new file mode 100644
> index 00..86b8e7e772
> --- /dev/null
> +++ b/automation/eclair_analysis/ECLAIR/Set1.ecl
> @@ -0,0 +1,59 @@
> +-doc_begin="Set 1 of Xen MISRA C guidelines"
> +-enable=MC3R1.R9.1
> +-enable=MC3R1.R12.5
> +-enable=MC3R1.R17.3
> +-enable=MC3R1.R17.4
> +-enable=MC3R1.R17.6
> +-enable=MC3R1.R19.1
> +-enable=MC3R1.R21.13
> +-enable=MC3R1.R21.17
> +-enable=MC3R1.R21.18
> +-enable=MC3R1.R21.19
> +-enable=MC3R1.R21.20
> +-enable=MC3R1.R21.21
> +-enable=MC3R1.R22.2
> +-enable=MC3R1.R22.4
> +-enable=MC3R1.R22.5
> +-enable=MC3R1.R22.6
> +-enable=MC3R1.D1.1
> +-enable=MC3R1.D2.1
> +-enable=MC3R1.D4.1
> +-enable=MC3R1.D4.3
> +-enable=MC3R1.D4.7
> +-enable=MC3R1.D4.10
> +-enable=MC3R1.D4.11
> +-enable=MC3R1.D4.14
> +-enable=MC3R1.R1.1
> +-enable=MC3R1.R1.3
> +-enable=MC3R1.R1.4
> +-enable=MC3R1.R2.1
> +-enable=MC3R1.R2.2
> +-enable=MC3R1.R3.1
> +-enable=MC3R1.R3.2
> +-enable=MC3R1.R4.1
> +-enable=MC3R1.R5.1
> +-enable=MC3R1.R5.2
> +-enable=MC3R1.R5.3
> +-enable=MC3R1.R5.4
> +-enable=MC3R1.R5.6
> +-enable=MC3R1.R6.1
> +-enable=MC3R1.R6.2
> 

Re: [PATCH] xen: Drop the (almost) unused extern start[]

[Stefano Stabellini]

On Tue, 25 Jul 2023, Andrew Cooper wrote:
> This global variable is shadowed by plenty local variables, violating MISRA
> rule 5.3.  Some architectures happen to have a symbol by the name of start in
> their head.S's, but it's not a useful symbol to reference from C.
> 
> In fact, the single use of the global start[] in RISC-V is wrong and means to
> use _start[] as the linker symbol at the beginning of the .text section, not
> the function which happens to be in the same location.
> 
> Fix RISC-V to use the right symbol for it's calculation, and drop the extern.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Stefano Stabellini 


> ---
> CC: Jan Beulich 
> CC: Roger Pau Monné 
> CC: Wei Liu 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Volodymyr Babchuk 
> CC: Bertrand Marquis 
> CC: Bob Eshleman 
> CC: Alistair Francis 
> CC: Connor Davis 
> CC: Oleksii Kurochko 
> CC: Roberto Bagnara 
> 
> I'm expecting:
> 
>   https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/945105609
> 
> to come back and show green, but Gitlab is very backed up right now.  I've
> compiled each architecture locally.
> ---
>  xen/arch/riscv/mm.c  | 2 +-
>  xen/include/xen/kernel.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> index fddb3cd0bdeb..99ed5e9623cc 100644
> --- a/xen/arch/riscv/mm.c
> +++ b/xen/arch/riscv/mm.c
> @@ -148,7 +148,7 @@ static bool __init check_pgtbl_mode_support(struct 
> mmu_desc *mmu_desc,
>  
>  unsigned long aligned_load_start = load_start & level_map_mask;
>  unsigned long aligned_page_size = XEN_PT_LEVEL_SIZE(page_table_level);
> -unsigned long xen_size = (unsigned long)(_end - start);
> +unsigned long xen_size = (unsigned long)(_end - _start);
>  
>  if ( (load_start + xen_size) > (aligned_load_start + aligned_page_size) )
>  {
> diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
> index 9ac2694dc7b1..46b3c9c02625 100644
> --- a/xen/include/xen/kernel.h
> +++ b/xen/include/xen/kernel.h
> @@ -66,7 +66,7 @@
>  })
>  
>  /* SAF-0-safe */
> -extern char _start[], _end[], start[];
> +extern char _start[], _end[];
>  #define is_kernel(p) ({ \
>  char *__p = (char *)(unsigned long)(p); \
>  (__p >= _start) && (__p < _end);\
> 
> base-commit: 0b1171be87698bc7d14760383c0770aeb6e41dd4
> -- 
> 2.30.2
> 

Re: [XEN PATCH v2] xen/spinlock: mechanically rename parameter name 'debug'

[Stefano Stabellini]

On Tue, 25 Jul 2023, Jan Beulich wrote:
> On 25.07.2023 11:17, Nicola Vetrini wrote:
> > Rule 5.3 has the following headline:
> > "An identifier declared in an inner scope shall not hide an
> > identifier declared in an outer scope"
> > 
> > To avoid any confusion resulting from the parameter 'debug'
> > hiding the homonymous function declared at
> > 'xen/arch/x86/include/asm/processor.h:428'
> > the rename of parameters s/debug/lkdbg/ is performed.
> > 
> > Signed-off-by: Nicola Vetrini 
> > ---
> > Changes in v2:
> > - s/dbg/lkdbg/
> 
> But only in some of the cases. E.g. ...
> 
> > -static void check_barrier(union lock_debug *debug)
> > +static void check_barrier(union lock_debug *dbg)
> 
> ... not here (there are a few more).

I agree with Jan: these are all union lock_debug parameters, so it would
make sense to me to use lkdbg everywhere in this patch.

Re: [XEN PATCH 2/3] xen/arm: irq: address violations of MISRA C: 2012 Rules 8.2 and 8.3

[Federico Serafini]

Hello Stefano,

On 25/07/23 00:55, Stefano Stabellini wrote:

  int request_irq(unsigned int irq, unsigned int irqflags,
-void (*handler)(int, void *, struct cpu_user_regs *),
+void (*handler)(int irq, void *dev_id,
+struct cpu_user_regs *regs),


We have an inconsistency where the handler functions on x86 typically
call it void *data, while on arm they typically use void *dev_id
(see xen/arch/x86/irq.c:request_irq and
xen/arch/x86/hpet.c:hpet_interrupt_handler). I think we should be
consistent. Or, if this is not a MISRA requirement because this is just
a function pointer rather than a proper function, then I would leave it
alone.


This is an inconsistency but it is not a violation of the rule 8.3.

Regards
--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)

Re: [XEN PATCH 2/3] xen/arm: irq: address violations of MISRA C: 2012 Rules 8.2 and 8.3

[Stefano Stabellini]

On Tue, 25 Jul 2023, Jan Beulich wrote:
> On 24.07.2023 19:50, Federico Serafini wrote:
> > @@ -182,7 +182,8 @@ void irq_set_affinity(struct irq_desc *desc, const 
> > cpumask_t *cpu_mask)
> >  }
> >  
> >  int request_irq(unsigned int irq, unsigned int irqflags,
> > -void (*handler)(int, void *, struct cpu_user_regs *),
> > +void (*handler)(int irq, void *dev_id,
> > +struct cpu_user_regs *regs),
> >  const char *devname, void *dev_id)
> >  {
> 
> Before we accept patches, don't we need to first settle on whether to
> apply the rule(s) also to function type declarations (and not just
> ordinary prototypes)?

Yes, in retrospect we should have found agreement on this issue this
morning but I forgot to bring it up :-(  Ooops.

(I think the agreement was to change the function type declarations too,
that's why docs/misra/rules.rst doesn't have a note about this, but I
don't want to make assumptions as I am not certain.)

Re: [XEN PATCH v3] device_tree: address violations of MISRA C:2012 Rules 8.2 and 8.3

[Stefano Stabellini]

On Tue, 25 Jul 2023, Federico Serafini wrote:
> Give a name to unnamed parameters thus addressing violations of
> MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
> named parameters").
> Keep consistency between parameter names and types used in function
> declarations and the ones used in the corresponding function
> definitions, thus addressing violations of MISRA C:2012 Rule 8.3
> ("All declarations of an object or function shall use the same names
> and type qualifiers").
> 
> No functional changes.
> 
> Signed-off-by: Federico Serafini 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v3:
>   - use parameter name 'dev' instead of 'device'.
> ---
> Changes in v2:
>   - improved consistency in parameter renaming.
> ---
>  xen/common/device_tree.c  | 16 
>  xen/include/xen/device_tree.h | 20 ++--
>  2 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 0677193ab3..0522fdf976 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -85,11 +85,11 @@ struct dt_bus
>  unsigned int (*get_flags)(const __be32 *addr);
>  };
>  
> -void dt_get_range(const __be32 **cell, const struct dt_device_node *np,
> +void dt_get_range(const __be32 **cellp, const struct dt_device_node *np,
>u64 *address, u64 *size)
>  {
> -*address = dt_next_cell(dt_n_addr_cells(np), cell);
> -*size = dt_next_cell(dt_n_size_cells(np), cell);
> +*address = dt_next_cell(dt_n_addr_cells(np), cellp);
> +*size = dt_next_cell(dt_n_size_cells(np), cellp);
>  }
>  
>  void dt_set_cell(__be32 **cellp, int size, u64 val)
> @@ -993,9 +993,9 @@ int dt_device_get_paddr(const struct dt_device_node *dev, 
> unsigned int index,
>  }
>  
>  int dt_for_each_range(const struct dt_device_node *dev,
> -  int (*cb)(const struct dt_device_node *,
> +  int (*cb)(const struct dt_device_node *dev,
>  uint64_t addr, uint64_t length,
> -void *),
> +void *data),
>void *data)
>  {
>  const struct dt_device_node *parent = NULL;
> @@ -1197,9 +1197,9 @@ unsigned int dt_number_of_address(const struct 
> dt_device_node *dev)
>  }
>  
>  int dt_for_each_irq_map(const struct dt_device_node *dev,
> -int (*cb)(const struct dt_device_node *,
> -  const struct dt_irq *,
> -  void *),
> +int (*cb)(const struct dt_device_node *dev,
> +  const struct dt_irq *dt_irq,
> +  void *data),
>  void *data)
>  {
>  const struct dt_device_node *ipar, *tnode, *old = NULL;
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index c2eada7489..1d79e23b28 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -538,7 +538,7 @@ bool_t dt_machine_is_compatible(const char *compat);
>   * Returns a node pointer with refcount incremented, use
>   * of_node_put() on it when done.
>   */
> -struct dt_device_node *dt_find_node_by_name(struct dt_device_node *node,
> +struct dt_device_node *dt_find_node_by_name(struct dt_device_node *from,
>  const char *name);
>  
>  /**
> @@ -622,12 +622,12 @@ unsigned int dt_number_of_irq(const struct 
> dt_device_node *device);
>  
>  /**
>   * dt_number_of_address - Get the number of addresses for a device
> - * @device: the device whose number of address is to be retrieved
> + * @dev: the device whose number of address is to be retrieved
>   *
>   * Return the number of address for this device or 0 if there is no
>   * address or an error occurred.
>   */
> -unsigned int dt_number_of_address(const struct dt_device_node *device);
> +unsigned int dt_number_of_address(const struct dt_device_node *dev);
>  
>  /**
>   * dt_device_get_irq - Resolve an interrupt for a device
> @@ -639,7 +639,7 @@ unsigned int dt_number_of_address(const struct 
> dt_device_node *device);
>   * device-tree node. It's the high level pendant to dt_device_get_raw_irq().
>   */
>  int dt_device_get_irq(const struct dt_device_node *device, unsigned int 
> index,
> -  struct dt_irq *irq);
> +  struct dt_irq *out_irq);
>  
>  /**
>   * dt_device_get_raw_irq - Resolve an interrupt for a device without 
> translation
> @@ -652,7 +652,7 @@ int dt_device_get_irq(const struct dt_device_node 
> *device, unsigned int index,
>   */
>  int dt_device_get_raw_irq(const struct dt_device_node *device,
>unsigned int index,
> -  struct dt_raw_irq *irq);
> +  struct dt_raw_irq *out_irq);
>  
>  /**
>   * dt_irq_translate - Translate an irq
> @@ 

[xen-unstable test] 182000: regressions - FAIL

[osstest service owner]

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

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. 181987

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 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-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 181987
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 181987
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 181987
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 181987
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 181987
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 181987
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 181987
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 181987
 test-amd64-i386-xl-vhd   21 guest-start/debian.repeatfail  like 181987
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 181987
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 181987
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 181987
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 181987
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   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-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass

version targeted for testing:
 xen  3a4e6f67bc689365680cd544d05c8772f56b7a91
baseline version:
 xen  0c53c638e16278078371ce028c74693841d7738a

Last test of basis   181987  2023-07-24 01:53:36 Z1 days
Testing same since   182000  2023-07-24 17:07:02 Z1 days1 attempts


People who touched revisions under test:
  Federico Serafini 
  George Dunlap 
  Jan Beulich 
  Shawn Anastasio 
  Viresh Kumar 

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

[PATCH] xen: Drop the (almost) unused extern start[]

[Andrew Cooper]

This global variable is shadowed by plenty local variables, violating MISRA
rule 5.3.  Some architectures happen to have a symbol by the name of start in
their head.S's, but it's not a useful symbol to reference from C.

In fact, the single use of the global start[] in RISC-V is wrong and means to
use _start[] as the linker symbol at the beginning of the .text section, not
the function which happens to be in the same location.

Fix RISC-V to use the right symbol for it's calculation, and drop the extern.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Bob Eshleman 
CC: Alistair Francis 
CC: Connor Davis 
CC: Oleksii Kurochko 
CC: Roberto Bagnara 

I'm expecting:

  https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/945105609

to come back and show green, but Gitlab is very backed up right now.  I've
compiled each architecture locally.
---
 xen/arch/riscv/mm.c  | 2 +-
 xen/include/xen/kernel.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index fddb3cd0bdeb..99ed5e9623cc 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -148,7 +148,7 @@ static bool __init check_pgtbl_mode_support(struct mmu_desc 
*mmu_desc,
 
 unsigned long aligned_load_start = load_start & level_map_mask;
 unsigned long aligned_page_size = XEN_PT_LEVEL_SIZE(page_table_level);
-unsigned long xen_size = (unsigned long)(_end - start);
+unsigned long xen_size = (unsigned long)(_end - _start);
 
 if ( (load_start + xen_size) > (aligned_load_start + aligned_page_size) )
 {
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index 9ac2694dc7b1..46b3c9c02625 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -66,7 +66,7 @@
 })
 
 /* SAF-0-safe */
-extern char _start[], _end[], start[];
+extern char _start[], _end[];
 #define is_kernel(p) ({ \
 char *__p = (char *)(unsigned long)(p); \
 (__p >= _start) && (__p < _end);\

base-commit: 0b1171be87698bc7d14760383c0770aeb6e41dd4
-- 
2.30.2

[PATCH RESEND] tools/xl_parse: remove message for tsc mode string

[Elliott Mitchell]

Normal behavior is to be silent.  Generating a message for the preferred
input can be mistaken for an error.  As such remove this message to match
other conditions.

Signed-off-by: Elliott Mitchell 
---
This looks like a bit of printf()-debugging which never got removed.  The
message serves to discourage use of the named tsc_mode values.  I suspect
this is the ooposite of the desired result and therefore should be
purged.
---
 tools/xl/xl_parse.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index f036e56fc2..7b1369f098 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1658,7 +1658,6 @@ void parse_config_data(const char *config_source,
 }
 b_info->tsc_mode = l;
 } else if (!xlu_cfg_get_string(config, "tsc_mode", , 0)) {
-fprintf(stderr, "got a tsc mode string: \"%s\"\n", buf);
 if (libxl_tsc_mode_from_string(buf, _info->tsc_mode)) {
 fprintf(stderr, "ERROR: invalid value \"%s\" for \"tsc_mode\"\n",
 buf);
-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Re: [PATCH] xen/public: fix flexible array definitions

[Andrew Cooper]

On 25/07/2023 5:16 pm, Jan Beulich wrote:
> On 25.07.2023 15:55, Juergen Gross wrote:
>> Flexible arrays in public headers can be problematic with some
>> compilers.
>>
>> Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
>> errors.
>>
>> This includes arrays defined as "arr[1]", as seen with a recent Linux
>> kernel [1].
>>
>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217693
>>
>> Signed-off-by: Juergen Gross 
> I think we need to be careful here: What if someone somewhere applies
> sizeof() to any of the types you alter?

Then the code was most likely wrong already.

>  The resulting value would
> change with the changes you propose, which we cannot allow to happen
> in a stable interface. Therefore imo it can only be an opt-in feature
> to have these arrays no longer be one-element ones.

I don't consider this an issue.

If people take an update to the headers and their code stops compiling,
then of course they fix the compilation issue.  That's normal.

It's unreasonable to take opt-in features to a set of headers intended
to be vendored in the first place, to work around a corner case that's
likely buggy already.

~Andrew

[xen-4.14-testing test] 181996: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  64b40594f589c9069fb8cf3899d4aac59c86d4f1
baseline version:
 xen  98ec8ad2eeb96eb9d4b7f9bfd1ef3a994c63af17

Last test of basis   180425  2023-04-26 07:39:28 Z   90 days
Testing same since   181996  2023-07-24 16:37:10 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Roger Pau Monné 

jobs:
 

Re: [XEN PATCH v2] xen/sched: mechanical renaming to address MISRA C:2012 Rule 5.3

[Nicola Vetrini]

On 25/07/23 16:52, Jan Beulich wrote:

On 25.07.2023 11:08, Nicola Vetrini wrote:

@@ -99,14 +99,15 @@ static void sched_set_affinity(
  struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft);
  
  static struct sched_resource *cf_check

-sched_idle_res_pick(const struct scheduler *ops, const struct sched_unit *unit)
+sched_idle_res_pick(
+const struct scheduler *ops, const struct sched_unit *unit)
  {
  return unit->res;
  }
  
  static void *cf_check

-sched_idle_alloc_udata(const struct scheduler *ops, struct sched_unit *unit,
-   void *dd)
+sched_idle_alloc_udata(
+const struct scheduler *ops, struct sched_unit *unit, void *dd)
  {
  /* Any non-NULL pointer is fine here. */
  return ZERO_BLOCK_PTR;


These look like stray changes, presumably resulting from you not fully
undoing earlier changes.



You're right, they were the byproduct of an earlier edit to this patch.


--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -3809,7 +3809,8 @@ csched2_dump(const struct scheduler *ops)
  struct list_head *iter_sdom;
  struct csched2_private *prv = csched2_priv(ops);
  unsigned long flags;
-unsigned int j, loop;
+unsigned int loop;
+int j;


This looks like a stray change too, just that it's unclear where it is
coming from.



I thought I added a note to the commit, but I probably did some mistake.
That's why I changed it:

Note: local variable 'j' in xen/common/sched/credit2.c:3888' should
probably be unsigned as well, but I saw while editing the patch
that it's used as a parameter to 'dump_pcpu', which takes an int.
Changing the types of parameters used in these calls is
probably a good target for another patch, as it's not relevant
to Rule 5.3


@@ -3884,7 +3885,7 @@ csched2_dump(const struct scheduler *ops)
  list_for_each_entry ( rqd, >rql, rql )
  {
  struct list_head *iter, *runq = >runq;
-int loop = 0;
+loop = 0;
  
  /* We need the lock to scan the runqueue. */

  spin_lock(>lock);


With the switch from declaration to statement, a blank line wants
inserting (to separate the remaining declaration from the
statements).



Ok

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [PATCH] xen/public: fix flexible array definitions

[Jan Beulich]

On 25.07.2023 15:55, Juergen Gross wrote:
> Flexible arrays in public headers can be problematic with some
> compilers.
> 
> Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
> errors.
> 
> This includes arrays defined as "arr[1]", as seen with a recent Linux
> kernel [1].
> 
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217693
> 
> Signed-off-by: Juergen Gross 

I think we need to be careful here: What if someone somewhere applies
sizeof() to any of the types you alter? The resulting value would
change with the changes you propose, which we cannot allow to happen
in a stable interface. Therefore imo it can only be an opt-in feature
to have these arrays no longer be one-element ones.

Jan

Re: [PATCH v3 08/25] tools/xenstore: make hashtable key and value parameters const

[Julien Grall]

Hi,

On 24/07/2023 12:02, Juergen Gross wrote:

The key and value are never modified by hashtable code, so they should
be marked as const.


You wrote this but...



Signed-off-by: Juergen Gross 
---
V3:
- make value const, too.
---
  tools/xenstore/hashtable.c | 7 ---
  tools/xenstore/hashtable.h | 4 ++--
  2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/hashtable.c b/tools/xenstore/hashtable.c
index 11f6bf8f15..670dc01003 100644
--- a/tools/xenstore/hashtable.c
+++ b/tools/xenstore/hashtable.c
@@ -11,7 +11,8 @@
  
  struct entry

  {
-void *k, *v;
+const void *k;
+void *v;



... this is not const and ...


  unsigned int h;
  struct entry *next;
  };
@@ -140,7 +141,7 @@ static int hashtable_expand(struct hashtable *h)
  return 0;
  }
  
-int hashtable_add(struct hashtable *h, void *k, void *v)

+int hashtable_add(struct hashtable *h, const void *k, const void *v)
  {
  /* This method allows duplicate keys - but they shouldn't be used */
  unsigned int index;
@@ -164,7 +165,7 @@ int hashtable_add(struct hashtable *h, void *k, void *v)
  e->k = k;
  if (h->flags & HASHTABLE_FREE_KEY)
  talloc_steal(e, k);
-e->v = v;
+e->v = (void *)v;


... you cast-away the const here. I think this is a pretty bad idea.

Can you clarify why you are doing like that?

Cheers,

--
Julien Grall

Re: [PATCH v4 3/6] libxl: introduce MSR data in libxl_cpuid_policy

[Roger Pau Monné]

On Tue, Jul 25, 2023 at 03:44:29PM +0100, Anthony PERARD wrote:
> On Tue, Jul 25, 2023 at 03:05:55PM +0200, Roger Pau Monne wrote:
> > diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
> > index 3c8b2a72c0b8..dd97699bbde7 100644
> > --- a/tools/libs/light/libxl_cpuid.c
> > +++ b/tools/libs/light/libxl_cpuid.c
> > @@ -592,17 +641,32 @@ int libxl__cpuid_policy_list_parse_json(libxl__gc *gc,
> >  {
> >  int i, size;
> >  struct xc_xend_cpuid *l;
> > +struct xc_msr *msr;
> > +const libxl__json_object *co;
> >  flexarray_t *array;
> > +bool cpuid_only = false;
> > +
> > +if (libxl__json_object_is_array(o)) {
> 
> I think a comment here would useful to point out that we are parsing the
> format from previous version of Xen.
> 
> > +co = o;
> > +cpuid_only = true;
> > +goto parse_cpuid;
> > +}
> 
> Otherwise, the patch looks good now:
> Reviewed-by: Anthony PERARD 

Thanks, will add and send just v5 for this patch, as a reply to v4.

Regards, Roger.

Re: [PATCH] xen/public: fix flexible array definitions

[Andrew Cooper]

On 25/07/2023 2:55 pm, Juergen Gross wrote:
> Flexible arrays in public headers can be problematic with some
> compilers.
>
> Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
> errors.
>
> This includes arrays defined as "arr[1]", as seen with a recent Linux
> kernel [1].
>
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217693
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Andrew Cooper 

Re: [PATCH v3 01/25] tools/xenstore: explicitly specify create or modify for tdb_store()

[Julien Grall]

Hi Juergen,

On 24/07/2023 12:02, Juergen Gross wrote:

Instead of using TDB_REPLACE for either creating or modifying a TDB
entry, use either TDB_INSERT or TDB_MODIFY when calling tdb_store().

At higher function levels use the abstract mode values NODE_CREATE
and NODE_MODIFY.

This is for preparing to get rid of TDB, even if it is beneficial
while using TDB, too.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v3 1/2] tools/xenstore: add const to the return type of canonicalize()

[Julien Grall]

Hi Juergen,

On 24/07/2023 11:33, Juergen Gross wrote:

The return type of canonicalize() can be modified to const char *.
This avoids the need to cast the const away from the input parameter.

There need to be quite some other functions modified to take const
parameters in order to avoid further casts.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v5 2/2] xl: Add escape character argument to xl console

[Anthony PERARD]

On Wed, Jul 12, 2023 at 11:29:17AM +0100, Peter Hoyes wrote:
> @@ -1968,9 +1979,12 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, 
> int cons_num,
>   * guests using pygrub.
>   * If notify_fd is not -1, xenconsole will write 0x00 to it to nofity
>   * the caller that it has connected to the guest console.
> + * If escape_character is not NULL, the provided value is used to exit
> + * the guest console.
>   */
>  int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm,
> -   int notify_fd);
> +   int notify_fd,
> +   char* escape_character);
>  
>  #if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040800
>  
> @@ -1989,6 +2003,25 @@ static inline int 
> libxl_primary_console_exec_0x040700(libxl_ctx *ctx,
>  }
>  #define libxl_primary_console_exec libxl_primary_console_exec_0x040700
>  
> +#elif defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x041800
> +
> +static inline int libxl_console_exec_0x041800(libxl_ctx *ctx, uint32_t domid,

Is is preferred to name these compatibility function with the version of
Xen that last presented this API, so could you rename it to
"libxl_console_exec_0x041700" ?

> +  int cons_num,
> +  libxl_console_type type,
> +  int notify_fd)
> +{
> +return libxl_console_exec(ctx, domid, cons_num, type, notify_fd, NULL);
> +}
> +#define libxl_console_exec libxl_console_exec_0x041800
> +
> +static inline int libxl_primary_console_exec_0x041800(libxl_ctx *ctx,

Same thing here.

> +  uint32_t domid_vm,
> +  int notify_fd)
> +{
> +return libxl_primary_console_exec(ctx, domid_vm, notify_fd, NULL);
> +}
> +#define libxl_primary_console_exec libxl_primary_console_exec_0x041800
> +

Also, could you add the extra NULL argument in the function call of both
"libxl_console_exec_0x040700()" and
"libxl_primary_console_exec_0x040700()" ?

Thanks,

-- 
Anthony PERARD

Re: [PATCH v3] xen/arm: Move TEE mediators in a kconfig submenu

[Julien Grall]

Hi Bertrand,

On 25/07/2023 16:42, Bertrand Marquis wrote:

Rework TEE mediators to put them under a submenu in Kconfig.
The submenu is only visible if UNSUPPORTED is activated as all currently
existing mediators are UNSUPPORTED.

While there rework a bit the configuration so that OP-TEE and FF-A
mediators are selecting the generic TEE interface instead of depending
on it.
Make the TEE option hidden as it is of no interest for anyone to select
it without one of the mediators so having them select it instead should
be enough.

Signed-off-by: Bertrand Marquis 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

[PATCH v3] xen/arm: Move TEE mediators in a kconfig submenu

[Bertrand Marquis]

Rework TEE mediators to put them under a submenu in Kconfig.
The submenu is only visible if UNSUPPORTED is activated as all currently
existing mediators are UNSUPPORTED.

While there rework a bit the configuration so that OP-TEE and FF-A
mediators are selecting the generic TEE interface instead of depending
on it.
Make the TEE option hidden as it is of no interest for anyone to select
it without one of the mediators so having them select it instead should
be enough.

Signed-off-by: Bertrand Marquis 
---
Changes in v3:
- automatically compile in tee instead of using CONFIG_TEE for it
  (Makefile is only included if CONFIG_TEE is selected)
- remove commit message paragraph on Makefile inclusion which was not
  true anymore
Changes in v2:
- only included tee subdirectory in makefile if CONFIG_TEE is selected
  (reverts to state before patch)
- remove help in hidden TEE config
- rebase on top of staging
---
 xen/arch/arm/Kconfig |  7 ---
 xen/arch/arm/tee/Kconfig | 17 ++---
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 439cc94f3344..fd57a82dd284 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -175,13 +175,6 @@ config ARM64_BTI
  Branch Target Identification support.
  This feature is not supported in Xen.
 
-config TEE
-   bool "Enable TEE mediators support (UNSUPPORTED)" if UNSUPPORTED
-   default n
-   help
- This option enables generic TEE mediators support. It allows guests
- to access real TEE via one of TEE mediators implemented in XEN.
-
 source "arch/arm/tee/Kconfig"
 
 config STATIC_SHM
diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
index db3ea78f..c5b0f88d7522 100644
--- a/xen/arch/arm/tee/Kconfig
+++ b/xen/arch/arm/tee/Kconfig
@@ -1,7 +1,14 @@
+menu "TEE mediators"
+   visible if UNSUPPORTED
+
+config TEE
+   bool
+   default n
+
 config OPTEE
-   bool "Enable OP-TEE mediator"
+   bool "Enable OP-TEE mediator (UNSUPPORTED)" if UNSUPPORTED
default n
-   depends on TEE
+   select TEE
help
  Enable the OP-TEE mediator. It allows guests to access
  OP-TEE running on your platform. This requires
@@ -12,10 +19,14 @@ config OPTEE
 config FFA
bool "Enable FF-A mediator support (UNSUPPORTED)" if UNSUPPORTED
default n
-   depends on ARM_64 && TEE
+   depends on ARM_64
+   select TEE
help
  This option enables a minimal FF-A mediator. The mediator is
  generic as it follows the FF-A specification [1], but it only
  implements a small subset of the specification.
 
  [1] https://developer.arm.com/documentation/den0077/latest
+
+endmenu
+
-- 
2.39.2 (Apple Git-143)

Re: [PATCH v5 1/2] tools/console: Add escape argument to configure escape character

[Anthony PERARD]

On Wed, Jul 12, 2023 at 11:29:16AM +0100, Peter Hoyes wrote:
> From: Peter Hoyes 
> 
> Dom0 may be accessed via telnet, meaning the default escape character
> (which is the same as telnet's) cannot be directly used to exit the
> console. It would be helpful to make the escape character customizable
> in such use cases.
> 
> Add --escape argument to console tool for this purpose.
> 
> Add argument to getopt options, parse and validate the escape character
> and pass value to console_loop.
> 
> If --escape is not specified, it falls back to the existing behavior
> using DEFAULT_ESCAPE_SEQUENCE.
> 
> Signed-off-by: Peter Hoyes 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

[XEN PATCH 4/4] maintainers: Add ECLAIR reviewer

[Simone Ballarin]

Signed-off-by: Simone Ballarin 

--
Changes in v3:
- split maintainer add in a separate patch;
- substitute blanks with tabs;
- fix file paths;
- change role from maintainer to reviewer.

Changes in v2:
- add ECLAIR configuration files (before they were fetched from a separate
  repository);
- now the pipeline fails if there are new violations of guidelines tagged
  with clean:added.
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 180e57dac4..66ff0ed710 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -305,6 +305,12 @@ F: xen/include/xen/libfdt/
 F: xen/include/xen/device_tree.h
 F: xen/drivers/passthrough/device_tree.c
 
+ECLAIR
+R: Simone Ballarin 
+S: Supported
+F: automation/eclair_analysis/
+F: automation/scripts/eclair
+
 EFI
 M: Jan Beulich 
 S: Supported
-- 
2.34.1

[XEN PATCH 3/4] automation: Add ECLAIR pipelines

[Simone Ballarin]

Add two pipelines that analyze an ARM64 and a X86_64 build with the
ECLAIR static analyzer on the guidelines contained in Set1.

The analysis configuration is stored in automation/eclair_analysis.

All commits on the xen-project/xen:staging branch will be analyzed
and their artifacts will be stored indefinitely; the integration will
report differential information with respect to the previous analysis.

All commits on other branches or repositories will be analyzed and
only the last ten artifacts will be kept; the integration will report
differential information with respect to the analysis done on the common
ancestor with xen-project/xen:staging (if available).

Currently the pipeline variable ENABLE_ECLAIR_BOT is set to "n".
Doing so disables the generation of comments with the analysis summary
on the commit threads. The variable can be set to "y" if the a masked
variable named ECLAIR_BOT_TOKEN is set with the impersonation token of
an account with enough privileges to write on all repositories.

Additionaly any repository should be able to read a masked variable
named WTOKEN with the token provided by BUGSENG.

The analysis fails if it contains violations of guidelines tagged as
clean:added. The list of clean guidelines are maintained in
automation/eclair_analysis/ECLAIR/tagging.ecl.

Signed-off-by: Simone Ballarin 

--
Changes in v3:
- split definitions of the ECLAIR pipelines in a separate patch;
- if the WTOKEN variable is missing now the analysis fails immediately.

Changes in v2:
- add ECLAIR configuration files (before they were fetched from a separate
repository);
- now the pipeline fails if there are new violations of guidelines tagged
with clean:added.
---
 .gitlab-ci.yml|  2 ++
 automation/gitlab-ci/analyze.yaml | 38 +++
 automation/gitlab-ci/build.yaml   |  1 +
 automation/scripts/eclair | 34 +++
 4 files changed, 75 insertions(+)
 create mode 100644 automation/gitlab-ci/analyze.yaml
 create mode 100755 automation/scripts/eclair

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index c8bd7519d5..ee5430b8b7 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,7 +1,9 @@
 stages:
+  - analyze
   - build
   - test
 
 include:
+  - 'automation/gitlab-ci/analyze.yaml'
   - 'automation/gitlab-ci/build.yaml'
   - 'automation/gitlab-ci/test.yaml'
diff --git a/automation/gitlab-ci/analyze.yaml 
b/automation/gitlab-ci/analyze.yaml
new file mode 100644
index 00..3d8166572b
--- /dev/null
+++ b/automation/gitlab-ci/analyze.yaml
@@ -0,0 +1,38 @@
+.eclair-analysis:
+  stage: analyze
+  tags:
+- eclair-analysis
+  variables:
+ECLAIR_OUTPUT_DIR: "ECLAIR_out"
+ANALYSIS_KIND: "normal"
+ENABLE_ECLAIR_BOT: "n"
+AUTO_PR_BRANCH: "staging"
+AUTO_PR_REPOSITORY: "xen-project/xen"
+  artifacts:
+when: always
+paths:
+  - "${ECLAIR_OUTPUT_DIR}/*.log"
+  - "${ECLAIR_OUTPUT_DIR}/*.txt"
+  - '*.log'
+reports:
+  codequality: gl-code-quality-report.json
+
+eclair-x86_64:
+  extends: .eclair-analysis
+  variables:
+LOGFILE: "eclair-x86_64.log"
+VARIANT: "X86_64"
+RULESET: "Set1"
+  script:
+- ./automation/scripts/eclair 2>&1 | tee "${LOGFILE}"
+  allow_failure: true
+
+eclair-ARM64:
+  extends: .eclair-analysis
+  variables:
+LOGFILE: "eclair-ARM64.log"
+VARIANT: "ARM64"
+RULESET: "Set1"
+  script:
+- ./automation/scripts/eclair 2>&1 | tee "${LOGFILE}"
+  allow_failure: true
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index c401f62d61..f01e2c32bb 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -11,6 +11,7 @@
   - '*.log'
   - '*/*.log'
 when: always
+  needs: []
   except:
 - master
 - smoke
diff --git a/automation/scripts/eclair b/automation/scripts/eclair
new file mode 100755
index 00..55888617b3
--- /dev/null
+++ b/automation/scripts/eclair
@@ -0,0 +1,34 @@
+#!/bin/sh -eu
+
+ECLAIR_ANALYSIS_DIR=automation/eclair_analysis
+ECLAIR_DIR="${ECLAIR_ANALYSIS_DIR}/ECLAIR"
+ECLAIR_OUTPUT_DIR=$(realpath "${ECLAIR_OUTPUT_DIR}")
+
+if [ -z "${WTOKEN:-}" ]; then
+echo "Failure: the WTOKEN variable is not defined." >&2
+exit 1
+fi
+
+"${ECLAIR_ANALYSIS_DIR}/prepare.sh" "${VARIANT}"
+
+ex=0
+"${ECLAIR_DIR}/analyze.sh" "${VARIANT}" "${RULESET}" || ex=$?
+"${ECLAIR_DIR}/action_log.sh" ANALYSIS_LOG \
+ "ECLAIR analysis log" \
+ "${ECLAIR_OUTPUT_DIR}/ANALYSIS.log" \
+ "${ex}"
+"${ECLAIR_DIR}/action_log.sh" REPORT_LOG \
+ "ECLAIR report log" \
+ "${ECLAIR_OUTPUT_DIR}/REPORT.log" \
+ "${ex}"
+[ "${ex}" = 0 ] || exit "${ex}"
+"${ECLAIR_DIR}/action_push.sh" "${WTOKEN}" "${ECLAIR_OUTPUT_DIR}"
+
+# Fail in case of new reports
+"${ECLAIR_DIR}/action_clean_added.sh" "${ECLAIR_OUTPUT_DIR}" || ex=$?

[XEN PATCH 2/4] automation: Add xen builds for the ECLAIR analyses

[Simone Ballarin]

This patch defines an ARM64 and a X86_64 build for the
ECLAIR pipelines.

These files are used by the analyze.sh script in
automation/eclair_analysis: it initially calls prepare.sh,
then runs into an ECLAIR environment build.sh.

Only the toolchain invocations triggered by build.sh
are analyzed; the prepare.sh script is instead intended
to perform all the required operations for building xen
that are not supposed to be analyzed: e.g. dependencies
build.

Signed-off-by: Simone Ballarin 

--
Changes in v3:
- split build definitions in a separate patch.

Changes in v2:
- add ECLAIR configuration files (before they were fetched from a separate
  repository);
- now the pipeline fails if there are new violations of guidelines tagged
  with clean:added.
---
 automation/eclair_analysis/Makefile.prepare |   6 +
 automation/eclair_analysis/build.sh |  44 ++
 automation/eclair_analysis/prepare.sh   |  42 ++
 automation/eclair_analysis/xen_arm_config   | 147 +++
 automation/eclair_analysis/xen_x86_config   | 152 
 5 files changed, 391 insertions(+)
 create mode 100644 automation/eclair_analysis/Makefile.prepare
 create mode 100755 automation/eclair_analysis/build.sh
 create mode 100755 automation/eclair_analysis/prepare.sh
 create mode 100644 automation/eclair_analysis/xen_arm_config
 create mode 100644 automation/eclair_analysis/xen_x86_config

diff --git a/automation/eclair_analysis/Makefile.prepare 
b/automation/eclair_analysis/Makefile.prepare
new file mode 100644
index 00..90f4a31172
--- /dev/null
+++ b/automation/eclair_analysis/Makefile.prepare
@@ -0,0 +1,6 @@
+include Makefile
+prepare:
+   $(Q)$(MAKE) $(build)=tools
+   $(Q)$(MAKE) $(build)=. include/xen/compile.h
+   $(Q)$(MAKE) $(build)=include all
+   $(Q)$(MAKE) $(build)=arch/$(SRCARCH) include
diff --git a/automation/eclair_analysis/build.sh 
b/automation/eclair_analysis/build.sh
new file mode 100755
index 00..ec087dd822
--- /dev/null
+++ b/automation/eclair_analysis/build.sh
@@ -0,0 +1,44 @@
+#!/bin/bash
+# Stop immediately if any executed command has exit status different from 0.
+set -e
+
+script_name="$(basename "$0")"
+
+fatal() {
+  echo "${script_name}: $*" >&2
+  exit 1
+}
+
+usage() {
+  fatal "Usage: ${script_name} "
+}
+
+if [ $# -ne 1 ]; then
+  usage
+fi
+
+if [ "$1" = "X86_64" ]; then
+  export CROSS_COMPILE=
+  export XEN_TARGET_ARCH=x86_64
+elif [ "$1" = "ARM64" ]; then
+  export CROSS_COMPILE=aarch64-linux-gnu-
+  export XEN_TARGET_ARCH=arm64
+else
+  fatal "Unknown configuration: $1"
+fi
+
+if [[ -f /proc/cpuinfo ]]; then
+  PROCESSORS=$(grep -c ^processor /proc/cpuinfo)
+else
+  PROCESSORS=6
+fi
+
+(
+  cd xen
+
+  make "-j${PROCESSORS}" "-l${PROCESSORS}.0"\
+   "CROSS_COMPILE=${CROSS_COMPILE}" \
+   "CC=${CROSS_COMPILE}gcc-12"  \
+   "CXX=${CROSS_COMPILE}g++-12" \
+   "XEN_TARGET_ARCH=${XEN_TARGET_ARCH}"
+)
diff --git a/automation/eclair_analysis/prepare.sh 
b/automation/eclair_analysis/prepare.sh
new file mode 100755
index 00..275a1a3f51
--- /dev/null
+++ b/automation/eclair_analysis/prepare.sh
@@ -0,0 +1,42 @@
+#!/bin/bash
+# Stop immediately if any executed command has exit status different from 0.
+set -e
+
+script_name="$(basename "$0")"
+script_dir="$(
+  cd "$(dirname "$0")"
+  echo "${PWD}"
+)"
+
+fatal() {
+  echo "${script_name}: $*" >&2
+  exit 1
+}
+
+usage() {
+  fatal "Usage: ${script_name}"
+}
+
+if [ $# -ne 1 ]; then
+  usage
+  exit 1
+fi
+
+export XEN_TARGET_ARCH
+
+if [ "$1" = "X86_64" ]; then
+  CONFIG_FILE="${script_dir}/xen_x86_config"
+  XEN_TARGET_ARCH=x86_64
+elif [ "$1" = "ARM64" ]; then
+  CONFIG_FILE="${script_dir}/xen_arm_config"
+  XEN_TARGET_ARCH=arm64
+else
+  fatal "Unknown configuration: $1"
+fi
+
+(
+cd xen
+cp "${CONFIG_FILE}" .config
+make clean
+make -f ${script_dir}/Makefile.prepare prepare
+)
diff --git a/automation/eclair_analysis/xen_arm_config 
b/automation/eclair_analysis/xen_arm_config
new file mode 100644
index 00..82102b889e
--- /dev/null
+++ b/automation/eclair_analysis/xen_arm_config
@@ -0,0 +1,147 @@
+# File provided in
+# Re: Xen MISRA C: Source files in scope and out of scope
+# from:Stefano Stabellini 
+# date:6 giu 2023, 02:53
+
+#
+# Automatically generated file; DO NOT EDIT.
+# Xen/arm 4.18-unstable Configuration
+#
+CONFIG_CC_IS_GCC=y
+CONFIG_GCC_VERSION=90400
+CONFIG_CLANG_VERSION=0
+CONFIG_LD_IS_GNU=y
+CONFIG_CC_HAS_VISIBILITY_ATTRIBUTE=y
+CONFIG_ARM_64=y
+CONFIG_ARM=y
+CONFIG_ARCH_DEFCONFIG="arch/arm/configs/arm64_defconfig"
+
+# UBSAN
+CONFIG_UBSAN=n
+
+#
+# Architecture Features
+#
+CONFIG_ARM64_SVE=n
+CONFIG_64BIT=y
+CONFIG_NR_CPUS=4
+# CONFIG_ACPI is not set
+CONFIG_ARM_EFI=y
+CONFIG_GICV3=y
+CONFIG_HAS_ITS=y
+CONFIG_HVM=y
+# CONFIG_NEW_VGIC is not set
+CONFIG_SBSA_VUART_CONSOLE=y
+CONFIG_ARM_SSBD=y
+CONFIG_HARDEN_BRANCH_PREDICTOR=y
+# CONFIG_TEE is not set
+# CONFIG_STATIC_SHM is not 

[XEN PATCH 1/4] automation: Add ECLAIR utilities and settings

[Simone Ballarin]

The files with extension ecl are ECLAIR configurations that
are loaded during the analysis phase or during the report
generation phase: analysis.ecl is the main file for the analysis
phase, while reports.ecl is the one for the report phase.
All other ecl files are included by one of the two main ones.

The actions* scripts implement the integration with the CI server,
they are completely general and can be amended to work with any CI
server. Their presence in xen.git is recommended so that maintainance
would be easier.

analyze.sh is the script that actually triggers the analysis.

Signed-off-by: Simone Ballarin 

--
Changes in v3:
- split ECLAIR configurations and scripts in a separate patch;
- remove references to "Task (a): Xen Coding Guidelines v1.0".

Changes in v2:
- add ECLAIR configuration files (before they were fetched from a separate
repository);
- now the pipeline fails if there are new violations of guidelines tagged
with clean:added.
---
 automation/eclair_analysis/ECLAIR/Set1.ecl|  59 
 automation/eclair_analysis/ECLAIR/Set2.ecl|  25 ++
 automation/eclair_analysis/ECLAIR/Set3.ecl|  67 
 .../eclair_analysis/ECLAIR/action.helpers | 193 
 .../eclair_analysis/ECLAIR/action.settings| 172 ++
 .../ECLAIR/action_clean_added.sh  |  36 +++
 .../eclair_analysis/ECLAIR/action_log.sh  |  15 +
 .../ECLAIR/action_pull_request.sh |  57 
 .../eclair_analysis/ECLAIR/action_push.sh |  95 ++
 .../ECLAIR/action_upload_sarif.sh |  31 ++
 .../eclair_analysis/ECLAIR/analysis.ecl   |  25 ++
 automation/eclair_analysis/ECLAIR/analyze.sh  | 106 +++
 .../ECLAIR/call_properties.ecl| 106 +++
 .../eclair_analysis/ECLAIR/deviations.ecl | 298 ++
 .../eclair_analysis/ECLAIR/out_of_scope.ecl   | 127 
 .../ECLAIR/print_analyzed_files.sh|  66 
 .../eclair_analysis/ECLAIR/public_APIs.ecl|   6 +
 automation/eclair_analysis/ECLAIR/report.ecl  |   4 +
 automation/eclair_analysis/ECLAIR/tagging.ecl |  34 ++
 .../eclair_analysis/ECLAIR/toolchain.ecl  | 275 
 20 files changed, 1797 insertions(+)
 create mode 100644 automation/eclair_analysis/ECLAIR/Set1.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/Set2.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/Set3.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/action.helpers
 create mode 100644 automation/eclair_analysis/ECLAIR/action.settings
 create mode 100755 automation/eclair_analysis/ECLAIR/action_clean_added.sh
 create mode 100755 automation/eclair_analysis/ECLAIR/action_log.sh
 create mode 100644 automation/eclair_analysis/ECLAIR/action_pull_request.sh
 create mode 100755 automation/eclair_analysis/ECLAIR/action_push.sh
 create mode 100755 automation/eclair_analysis/ECLAIR/action_upload_sarif.sh
 create mode 100644 automation/eclair_analysis/ECLAIR/analysis.ecl
 create mode 100755 automation/eclair_analysis/ECLAIR/analyze.sh
 create mode 100644 automation/eclair_analysis/ECLAIR/call_properties.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/deviations.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/out_of_scope.ecl
 create mode 100755 automation/eclair_analysis/ECLAIR/print_analyzed_files.sh
 create mode 100644 automation/eclair_analysis/ECLAIR/public_APIs.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/report.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/tagging.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/toolchain.ecl

diff --git a/automation/eclair_analysis/ECLAIR/Set1.ecl 
b/automation/eclair_analysis/ECLAIR/Set1.ecl
new file mode 100644
index 00..86b8e7e772
--- /dev/null
+++ b/automation/eclair_analysis/ECLAIR/Set1.ecl
@@ -0,0 +1,59 @@
+-doc_begin="Set 1 of Xen MISRA C guidelines"
+-enable=MC3R1.R9.1
+-enable=MC3R1.R12.5
+-enable=MC3R1.R17.3
+-enable=MC3R1.R17.4
+-enable=MC3R1.R17.6
+-enable=MC3R1.R19.1
+-enable=MC3R1.R21.13
+-enable=MC3R1.R21.17
+-enable=MC3R1.R21.18
+-enable=MC3R1.R21.19
+-enable=MC3R1.R21.20
+-enable=MC3R1.R21.21
+-enable=MC3R1.R22.2
+-enable=MC3R1.R22.4
+-enable=MC3R1.R22.5
+-enable=MC3R1.R22.6
+-enable=MC3R1.D1.1
+-enable=MC3R1.D2.1
+-enable=MC3R1.D4.1
+-enable=MC3R1.D4.3
+-enable=MC3R1.D4.7
+-enable=MC3R1.D4.10
+-enable=MC3R1.D4.11
+-enable=MC3R1.D4.14
+-enable=MC3R1.R1.1
+-enable=MC3R1.R1.3
+-enable=MC3R1.R1.4
+-enable=MC3R1.R2.1
+-enable=MC3R1.R2.2
+-enable=MC3R1.R3.1
+-enable=MC3R1.R3.2
+-enable=MC3R1.R4.1
+-enable=MC3R1.R5.1
+-enable=MC3R1.R5.2
+-enable=MC3R1.R5.3
+-enable=MC3R1.R5.4
+-enable=MC3R1.R5.6
+-enable=MC3R1.R6.1
+-enable=MC3R1.R6.2
+-enable=MC3R1.R7.1
+-enable=MC3R1.R7.2
+-enable=MC3R1.R7.3
+-enable=MC3R1.R7.4
+-enable=MC3R1.R8.1
+-enable=MC3R1.R8.2
+-enable=MC3R1.R8.3
+-enable=MC3R1.R8.4
+-enable=MC3R1.R8.5
+-enable=MC3R1.R8.6
+-enable=MC3R1.R8.8
+-enable=MC3R1.R8.10
+-enable=MC3R1.R8.12
+-enable=MC3R1.R8.14
+-enable=MC3R1.R9.2

[XEN PATCH 0/4] automation: Add ECLAIR pipelines

[Simone Ballarin]

This patch series adds two pipelines that analyze an ARM64 and a X86_64
build with the ECLAIR static analyzer on the guidelines contained in Set1.
The builds analyzed are the ones triggered by 
automation/eclair_analysis/build.sh.

automation/eclair_analysis/ECLAIR contains the ECLAIR configuration files
(.ecl files) and scripts that implement the integration (action* scripts).

All commits on the xen-project/xen:staging branch will be analyzed
and their artifacts will be stored indefinitely; the integration will
report differential information with respect to the previous analysis.

All commits on other branches or repositories will be analyzed and
only the last ten artifacts will be kept; the integration will report
differential information with respect to the analysis done on the common
ancestor with xen-project/xen:staging (if available).

Additionaly any repository should be able to read a masked variable
named WTOKEN with the token provided by BUGSENG, otherwise the pipeline
will fail.

The analysis fails if it contains violations of guidelines tagged as
clean:added. The list of clean guidelines are maintained in
automation/eclair_analysis/ECLAIR/tagging.ecl.

Simone Ballarin (4):
  automation: Add ECLAIR utilities and settings
  automation: Add xen builds for the ECLAIR analyses
  automation: Add ECLAIR pipelines
  maintainers: Add ECLAIR reviewer

 .gitlab-ci.yml|   2 +
 MAINTAINERS   |   6 +
 automation/eclair_analysis/ECLAIR/Set1.ecl|  59 
 automation/eclair_analysis/ECLAIR/Set2.ecl|  25 ++
 automation/eclair_analysis/ECLAIR/Set3.ecl|  67 
 .../eclair_analysis/ECLAIR/action.helpers | 193 
 .../eclair_analysis/ECLAIR/action.settings| 172 ++
 .../ECLAIR/action_clean_added.sh  |  36 +++
 .../eclair_analysis/ECLAIR/action_log.sh  |  15 +
 .../ECLAIR/action_pull_request.sh |  57 
 .../eclair_analysis/ECLAIR/action_push.sh |  95 ++
 .../ECLAIR/action_upload_sarif.sh |  31 ++
 .../eclair_analysis/ECLAIR/analysis.ecl   |  25 ++
 automation/eclair_analysis/ECLAIR/analyze.sh  | 106 +++
 .../ECLAIR/call_properties.ecl| 106 +++
 .../eclair_analysis/ECLAIR/deviations.ecl | 298 ++
 .../eclair_analysis/ECLAIR/out_of_scope.ecl   | 127 
 .../ECLAIR/print_analyzed_files.sh|  66 
 .../eclair_analysis/ECLAIR/public_APIs.ecl|   6 +
 automation/eclair_analysis/ECLAIR/report.ecl  |   4 +
 automation/eclair_analysis/ECLAIR/tagging.ecl |  34 ++
 .../eclair_analysis/ECLAIR/toolchain.ecl  | 275 
 automation/eclair_analysis/Makefile.prepare   |   6 +
 automation/eclair_analysis/build.sh   |  44 +++
 automation/eclair_analysis/prepare.sh |  42 +++
 automation/eclair_analysis/xen_arm_config | 147 +
 automation/eclair_analysis/xen_x86_config | 152 +
 automation/gitlab-ci/analyze.yaml |  38 +++
 automation/gitlab-ci/build.yaml   |   1 +
 automation/scripts/eclair |  34 ++
 30 files changed, 2269 insertions(+)
 create mode 100644 automation/eclair_analysis/ECLAIR/Set1.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/Set2.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/Set3.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/action.helpers
 create mode 100644 automation/eclair_analysis/ECLAIR/action.settings
 create mode 100755 automation/eclair_analysis/ECLAIR/action_clean_added.sh
 create mode 100755 automation/eclair_analysis/ECLAIR/action_log.sh
 create mode 100644 automation/eclair_analysis/ECLAIR/action_pull_request.sh
 create mode 100755 automation/eclair_analysis/ECLAIR/action_push.sh
 create mode 100755 automation/eclair_analysis/ECLAIR/action_upload_sarif.sh
 create mode 100644 automation/eclair_analysis/ECLAIR/analysis.ecl
 create mode 100755 automation/eclair_analysis/ECLAIR/analyze.sh
 create mode 100644 automation/eclair_analysis/ECLAIR/call_properties.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/deviations.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/out_of_scope.ecl
 create mode 100755 automation/eclair_analysis/ECLAIR/print_analyzed_files.sh
 create mode 100644 automation/eclair_analysis/ECLAIR/public_APIs.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/report.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/tagging.ecl
 create mode 100644 automation/eclair_analysis/ECLAIR/toolchain.ecl
 create mode 100644 automation/eclair_analysis/Makefile.prepare
 create mode 100755 automation/eclair_analysis/build.sh
 create mode 100755 automation/eclair_analysis/prepare.sh
 create mode 100644 automation/eclair_analysis/xen_arm_config
 create mode 100644 automation/eclair_analysis/xen_x86_config
 create mode 100644 automation/gitlab-ci/analyze.yaml
 create mode 100755 automation/scripts/eclair

-- 
2.34.1

Re: [XEN PATCH] xen/cpu: change parameter name in __cpu_up() declaration

[Jan Beulich]

On 25.07.2023 16:43, Federico Serafini wrote:
> Change parameter name from 'cpunum' to 'cpu' to keep consistency with
> the name used in the corresponding definitions thus addressing a
> violation of MISRA C:2012 Rule 8.3: "All declarations of an object or
> function shall use the same names and type qualifiers".
> 
> No functional changes.
> 
> Signed-off-by: Federico Serafini 

Acked-by: Jan Beulich 

Re: [XEN PATCH v2] xen/spinlock: mechanically rename parameter name 'debug'

[Jan Beulich]

On 25.07.2023 11:17, Nicola Vetrini wrote:
> Rule 5.3 has the following headline:
> "An identifier declared in an inner scope shall not hide an
> identifier declared in an outer scope"
> 
> To avoid any confusion resulting from the parameter 'debug'
> hiding the homonymous function declared at
> 'xen/arch/x86/include/asm/processor.h:428'
> the rename of parameters s/debug/lkdbg/ is performed.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> Changes in v2:
> - s/dbg/lkdbg/

But only in some of the cases. E.g. ...

> -static void check_barrier(union lock_debug *debug)
> +static void check_barrier(union lock_debug *dbg)

... not here (there are a few more).

Jan

Re: [XEN PATCH v2] xen/sched: mechanical renaming to address MISRA C:2012 Rule 5.3

[Jan Beulich]

On 25.07.2023 11:08, Nicola Vetrini wrote:
> @@ -99,14 +99,15 @@ static void sched_set_affinity(
>  struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft);
>  
>  static struct sched_resource *cf_check
> -sched_idle_res_pick(const struct scheduler *ops, const struct sched_unit 
> *unit)
> +sched_idle_res_pick(
> +const struct scheduler *ops, const struct sched_unit *unit)
>  {
>  return unit->res;
>  }
>  
>  static void *cf_check
> -sched_idle_alloc_udata(const struct scheduler *ops, struct sched_unit *unit,
> -   void *dd)
> +sched_idle_alloc_udata(
> +const struct scheduler *ops, struct sched_unit *unit, void *dd)
>  {
>  /* Any non-NULL pointer is fine here. */
>  return ZERO_BLOCK_PTR;

These look like stray changes, presumably resulting from you not fully
undoing earlier changes.

> --- a/xen/common/sched/credit2.c
> +++ b/xen/common/sched/credit2.c
> @@ -3809,7 +3809,8 @@ csched2_dump(const struct scheduler *ops)
>  struct list_head *iter_sdom;
>  struct csched2_private *prv = csched2_priv(ops);
>  unsigned long flags;
> -unsigned int j, loop;
> +unsigned int loop;
> +int j;

This looks like a stray change too, just that it's unclear where it is
coming from.

> @@ -3884,7 +3885,7 @@ csched2_dump(const struct scheduler *ops)
>  list_for_each_entry ( rqd, >rql, rql )
>  {
>  struct list_head *iter, *runq = >runq;
> -int loop = 0;
> +loop = 0;
>  
>  /* We need the lock to scan the runqueue. */
>  spin_lock(>lock);

With the switch from declaration to statement, a blank line wants
inserting (to separate the remaining declaration from the
statements).

Jan

Re: [PATCH v6 12/15] xen: Add SET_CPUFREQ_HWP xen_sysctl_pm_op

[Jan Beulich]

On 24.07.2023 14:58, Jason Andryuk wrote:
> Add SET_CPUFREQ_HWP xen_sysctl_pm_op to set HWP parameters.  The sysctl
> supports setting multiple values simultaneously as indicated by the
> set_params bits.  This allows atomically applying new HWP configuration
> via a single wrmsr.
> 
> XEN_SYSCTL_HWP_SET_PRESET_BALANCE/PERFORMANCE/POWERSAVE provide three
> common presets.  Setting them depends on hardware limits which the
> hypervisor is already caching.  So using them allows skipping a
> hypercall to query the limits (lowest/highest) to then set those same
> values.  The code is organized to allow a preset to be refined with
> additional parameters if desired.
> 
> "most_efficient" and "guaranteed" could be additional presets in the
> future, but the are not added now.  Those levels can change at runtime,
> but we don't have code in place to monitor and update for those events.
> 
> Since activity window may not be supported by all hardware, omit writing
> it when not supported, and return that fact to userspace by updating
> set_params.
> 
> CPPC parameter checking disallows setting reserved bytes and ensure
> values are only non-zero when the corresponding set_params bit is set.
> There is no range checking (0-255 is allowed) since hardware is
> documented to clip internally.
> 
> Signed-off-by: Jason Andryuk 

Reviewed-by: Jan Beulich 
with one last nit taken care of:

> @@ -539,6 +543,103 @@ int get_hwp_para(unsigned int cpu,
>  return 0;
>  }
>  
> +int set_hwp_para(struct cpufreq_policy *policy,
> + struct xen_set_cppc_para *set_cppc)
> +{
> +unsigned int cpu = policy->cpu;
> +struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu);
> +bool cleared_act_window = false;
> +
> +if ( data == NULL )
> +return -ENOENT;
> +
> +/* Validate all parameters - Disallow reserved bits. */
> +if ( set_cppc->minimum > 255 ||
> + set_cppc->maximum > 255 ||
> + set_cppc->desired > 255 ||
> + set_cppc->energy_perf > 255 ||
> + (set_cppc->set_params & ~XEN_SYSCTL_CPPC_SET_PARAM_MASK) ||
> + (set_cppc->activity_window & ~XEN_SYSCTL_CPPC_ACT_WINDOW_MASK) )
> +return -EINVAL;
> +
> +/* Only allow values if params bit is set. */
> +if ( (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_DESIRED) &&
> +  set_cppc->desired) ||
> + (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MINIMUM) &&
> +  set_cppc->minimum) ||
> + (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_MAXIMUM) &&
> +  set_cppc->maximum) ||
> + (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ENERGY_PERF) &&
> +  set_cppc->energy_perf) ||
> + (!(set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW) &&
> +  set_cppc->activity_window) )
> +return -EINVAL;
> +
> +/* Clear out activity window if lacking HW supported. */
> +if ( (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW) &&
> + !feature_hwp_activity_window ) {

Yet another misplaced brace.

Jan

Re: [PATCH v4 3/6] libxl: introduce MSR data in libxl_cpuid_policy

[Anthony PERARD]

On Tue, Jul 25, 2023 at 03:05:55PM +0200, Roger Pau Monne wrote:
> diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
> index 3c8b2a72c0b8..dd97699bbde7 100644
> --- a/tools/libs/light/libxl_cpuid.c
> +++ b/tools/libs/light/libxl_cpuid.c
> @@ -592,17 +641,32 @@ int libxl__cpuid_policy_list_parse_json(libxl__gc *gc,
>  {
>  int i, size;
>  struct xc_xend_cpuid *l;
> +struct xc_msr *msr;
> +const libxl__json_object *co;
>  flexarray_t *array;
> +bool cpuid_only = false;
> +
> +if (libxl__json_object_is_array(o)) {

I think a comment here would useful to point out that we are parsing the
format from previous version of Xen.

> +co = o;
> +cpuid_only = true;
> +goto parse_cpuid;
> +}

Otherwise, the patch looks good now:
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

[XEN PATCH] xen/cpu: change parameter name in __cpu_up() declaration

[Federico Serafini]

Change parameter name from 'cpunum' to 'cpu' to keep consistency with
the name used in the corresponding definitions thus addressing a
violation of MISRA C:2012 Rule 8.3: "All declarations of an object or
function shall use the same names and type qualifiers".

No functional changes.

Signed-off-by: Federico Serafini 
---
 xen/include/xen/cpu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/cpu.h b/xen/include/xen/cpu.h
index e8eeb217a0..e1d4eb5967 100644
--- a/xen/include/xen/cpu.h
+++ b/xen/include/xen/cpu.h
@@ -69,7 +69,7 @@ int disable_nonboot_cpus(void);
 void enable_nonboot_cpus(void);
 
 /* Private arch-dependent helpers for CPU hotplug. */
-int __cpu_up(unsigned int cpunum);
+int __cpu_up(unsigned int cpu);
 void __cpu_disable(void);
 void __cpu_die(unsigned int cpu);
 
-- 
2.34.1

Re: [PATCH v2 2/5] x86/ioapic: RTE modifications must use ioapic_write_entry

[Jan Beulich]

On 25.07.2023 15:30, Roger Pau Monné wrote:
> On Tue, Jul 18, 2023 at 05:40:18PM +0200, Jan Beulich wrote:
>> On 18.07.2023 14:43, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/io_apic.c
>>> +++ b/xen/arch/x86/io_apic.c
>>> @@ -584,16 +585,16 @@ set_ioapic_affinity_irq(struct irq_desc *desc, const 
>>> cpumask_t *mask)
>>>  dest = SET_APIC_LOGICAL_ID(dest);
>>>  entry = irq_2_pin + irq;
>>>  for (;;) {
>>> -unsigned int data;
>>> +struct IO_APIC_route_entry rte;
>>> +
>>>  pin = entry->pin;
>>>  if (pin == -1)
>>>  break;
>>>  
>>> -io_apic_write(entry->apic, 0x10 + 1 + pin*2, dest);
>>> -data = io_apic_read(entry->apic, 0x10 + pin*2);
>>> -data &= ~IO_APIC_REDIR_VECTOR_MASK;
>>> -data |= MASK_INSR(desc->arch.vector, 
>>> IO_APIC_REDIR_VECTOR_MASK);
>>> -io_apic_modify(entry->apic, 0x10 + pin*2, data);
>>> +rte = __ioapic_read_entry(entry->apic, pin, false);
>>> +rte.dest.dest32 = dest;
>>> +rte.vector = desc->arch.vector;
>>> +__ioapic_write_entry(entry->apic, pin, false, rte);
>>
>> ... this makes me wonder whether there shouldn't be an
>> __ioapic_modify_entry() capable of suppressing one of the two
>> writes (but still being handed the full RTE).
> 
> I've wondered about this, and I'm not sure how often can one of the
> two writes be suppressed here, as we modify both the low (for the
> vector) and the high part of the RTE (for the destination).  It's
> unlikely that the same vector could be used on both destinations, and
> IMO such case doesn't warrant the introduction of the extra logic
> required in order to suppress one of the writes.
> 
> Am I overlooking something?

Oh, no, that was me seeing the io_apic_modify() without paying attention
to the earlier io_apic_write() (both in the code you replace).

Jan

Re: [PATCH v6 06/15] cpufreq: Add Hardware P-State (HWP) driver

[Jan Beulich]

On 25.07.2023 15:26, Jason Andryuk wrote:
> On Tue, Jul 25, 2023 at 2:27 AM Jan Beulich  wrote:
>>
>> On 24.07.2023 21:49, Jason Andryuk wrote:
>>> On Mon, Jul 24, 2023 at 12:15 PM Jan Beulich  wrote:
 On 24.07.2023 14:58, Jason Andryuk wrote:
> --- /dev/null
> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c
> +#define hwp_err(cpu, fmt, ...) \
> +printk(XENLOG_ERR "HWP: CPU%u error: " fmt, cpu, ##__VA_ARGS__)
> +#define hwp_info(fmt, ...)printk(XENLOG_INFO "HWP: " fmt, 
> ##__VA_ARGS__)

 I'm not convinced ", ##__VA_ARGS__" is a good construct to use. I notice
 we have a few instances (mainly in code inherited from elsewhere), but I
 think it ought to either be plain C99 style (without the ##) or purely
 the gcc extension form (not using __VA_ARGS__).
>>>
>>> Using plain __VA_ARGS__ doesn't work for the cases without arguments:
>>> arch/x86/acpi/cpufreq/hwp.c:78:53: error: expected expression before ‘)’ 
>>> token
>>>78 | printk(XENLOG_DEBUG "HWP: " fmt, __VA_ARGS__);  \
>>>   | ^
>>> arch/x86/acpi/cpufreq/hwp.c:201:9: note: in expansion of macro ‘hwp_verbose’
>>>   201 | hwp_verbose("disabled: No energy/performance
>>> preference available");
>>>   | ^~~
>>
>> Of course.
>>
>>> I can use "__VA_OPT__(,) __VA_ARGS__" though.
>>
>> __VA_OPT__ is yet newer than C99, so this is an option only if all
>> compilers we continue to support actually know of this.
> 
> Right, sorry.
> 
>> We have no
>> uses of it in the codebase so far, which suggests you might best go
>> with the longstanding gcc extension here.
> 
> FTAOD, "##__VA_ARGS__" is the longstanding extension?

No. But you've apparently found it ...

>  It's the only
> one I've been able to get to compile.  I'm reading
> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html and it
> mentions a few different extensions.
> 
> This part seemed promising:
> """
> This has been fixed in C++20, and GNU CPP also has a pair of
> extensions which deal with this problem.
> 
> First, in GNU CPP, and in C++ beginning in C++20, you are allowed to
> leave the variable argument out entirely:
> 
> eprintf ("success!\n")
>  → fprintf(stderr, "success!\n", );
> """
> 
> However, it doesn't seem to actually work for me.  I still get an
> error like the one above for plain __VA_ARGS__.  That is for:
> 
> #define hwp_err(cpu, fmt, args...) \
> printk(XENLOG_ERR "HWP: CPU%u error: " fmt, cpu, args)

..., just that you're missing the ##:

#define hwp_err(cpu, fmt, args...) \
printk(XENLOG_ERR "HWP: CPU%u error: " fmt, cpu, ## args)

Jan

Re: [PATCH 6/8] mm/pdx: Standardize region validation wrt pdx compression

[Jan Beulich]

On 25.07.2023 16:27, Julien Grall wrote:
> Hi,
> 
> On 25/07/2023 07:51, Jan Beulich wrote:
>> On 24.07.2023 20:20, Julien Grall wrote:
>>> On 24/07/2023 13:18, Alejandro Vallejo wrote:
 On Fri, Jul 21, 2023 at 06:05:51PM +0100, Julien Grall wrote:
> Hi Alejandro,
>
> On 17/07/2023 17:03, Alejandro Vallejo wrote:
>> +bool pdx_is_region_compressible(unsigned long smfn, unsigned long emfn)
>
> For newer interface, I would rather prefer if we use start + size. It is
> easier to reason (you don't have to wonder whether 'emfn' is inclusive or
> not) and avoid issue in the case you are trying to handle a region right 
> at
> the end of the address space as emfn would be 0 in the non-inclusive case
> (not much a concern for MFNs as the last one should be invalid, but it 
> makes
> harder to reason).
 I could agree on this, but every single caller is based on (smfn, emfn),
 so it needlessly forces every caller to perform conversions where the
 callee can do it just once.
>>>
>>> That's indeed one way to see it. The problem is that...
>>>
 That said, I think your point makes sense and
 it ought to be done. Probably as as part of a bigger refactor where
 (smfn, emfn)-based functions are turned into (base, len) variants.
>>>
>>> ... clean-up tends to be put in the back-burner and we just continue to
>>> add new use. This makes the task to remove every use a lot more
>>> difficult. So there is a point when one has to say no more.
>>>
>>> Therefore, I would strongly prefer if each callers are doing the
>>> computation. The rest can be removed leisurely.
>>>
>>> Let see what the opinion of the other maintainers.
>>
>> I think [a,b] ranges are fine to pass, and may even be preferable over
>> passing a size. I'm specifically using that term that you also used:
>> "size" (or "length") is ambiguous when talking about page granular
>> items - is it in bytes or number of pages?
> 
> I was referring to the number of pages. I don't think it make sense to 
> have it in bytes given the start is a frame.
> 
>> Especially in the former
>> case calculations at the call sites would be quite a bit more cumbersome.
>> I could agree with (mfn,nr) tuples
> 
> Ok. So your objection of my proposal is just about the name, right? If 
> so, I didn't put too much thought behind the naming when I sent my 
> original e-mail. I am open to any.

Something like "nr" would be fine with me, for example.

> , but as said I think inclusive
>> ranges are also fine to use (and would be less of a problem at the call
>> sites here, afaics).
> 
> The problem with range is that it can lead to confusion on whether the 
> end is inclusive or exclusive. We had one bug recently in the Arm PCI 
> code because of that.

It's a matter of properly writing it down, I would say.

> So I would like to get rid of any use of range in new functions.

Hmm, seems to need further input from other maintainers / committers
then.

Jan

Re: [PATCH] xen/arm: Move TEE mediators in a kconfig submenu

[Julien Grall]

Hi,

On 21/07/2023 15:34, Bertrand Marquis wrote:

On 21 Jul 2023, at 16:24, Jan Beulich  wrote:

On 21.07.2023 16:07, Bertrand Marquis wrote:

On 21 Jul 2023, at 15:08, Jan Beulich  wrote:
On 21.07.2023 14:27, Bertrand Marquis wrote:

So what should i keep or remove here ?


My understanding so far was that "visibility" merely hides all prompts
underneath (but then I use the command line version of the tool, not
menuconfig), so it largely is shorthand for adding "if" to all enclosed
prompts. Therefore I think all the "if UNSUPPORTED" are redundant and
could be dropped. But then I'm also working from the understanding that
"depends on" would behave somewhat differently ...


If that is ok with you I would rather keep them so that making one of them
SUPPORTED one day will not end up in wrongly making the other one
supported to. The visible if i added was more to "beautify" a bit when
unsupported is not selected so that we do not have an empty menu.


You're the maintainer, so you judge what is best. If I was maintainer, the
primary thing I would ask for is that there be no redundancy. IOW here
either no "if"s or no "visibility".


In this case i do think that the "if UNSUPPORTED" per entry is important
so that it clear per config entry which ones are unsupported.

So if other arm maintainers agree with your point, i would remove the
"visibility" and keep an empty menu.
But my vote is to keep both.

@julien and Stefano: Any view on that ?


I agree with keeping both.

Cheers,

--
Julien Grall

Re: [PATCH 6/8] mm/pdx: Standardize region validation wrt pdx compression

[Julien Grall]

Hi,

On 25/07/2023 07:51, Jan Beulich wrote:

On 24.07.2023 20:20, Julien Grall wrote:

On 24/07/2023 13:18, Alejandro Vallejo wrote:

On Fri, Jul 21, 2023 at 06:05:51PM +0100, Julien Grall wrote:

Hi Alejandro,

On 17/07/2023 17:03, Alejandro Vallejo wrote:

+bool pdx_is_region_compressible(unsigned long smfn, unsigned long emfn)


For newer interface, I would rather prefer if we use start + size. It is
easier to reason (you don't have to wonder whether 'emfn' is inclusive or
not) and avoid issue in the case you are trying to handle a region right at
the end of the address space as emfn would be 0 in the non-inclusive case
(not much a concern for MFNs as the last one should be invalid, but it makes
harder to reason).

I could agree on this, but every single caller is based on (smfn, emfn),
so it needlessly forces every caller to perform conversions where the
callee can do it just once.


That's indeed one way to see it. The problem is that...


That said, I think your point makes sense and
it ought to be done. Probably as as part of a bigger refactor where
(smfn, emfn)-based functions are turned into (base, len) variants.


... clean-up tends to be put in the back-burner and we just continue to
add new use. This makes the task to remove every use a lot more
difficult. So there is a point when one has to say no more.

Therefore, I would strongly prefer if each callers are doing the
computation. The rest can be removed leisurely.

Let see what the opinion of the other maintainers.


I think [a,b] ranges are fine to pass, and may even be preferable over
passing a size. I'm specifically using that term that you also used:
"size" (or "length") is ambiguous when talking about page granular
items - is it in bytes or number of pages?


I was referring to the number of pages. I don't think it make sense to 
have it in bytes given the start is a frame.



Especially in the former
case calculations at the call sites would be quite a bit more cumbersome.
I could agree with (mfn,nr) tuples


Ok. So your objection of my proposal is just about the name, right? If 
so, I didn't put too much thought behind the naming when I sent my 
original e-mail. I am open to any.


, but as said I think inclusive

ranges are also fine to use (and would be less of a problem at the call
sites here, afaics).


The problem with range is that it can lead to confusion on whether the 
end is inclusive or exclusive. We had one bug recently in the Arm PCI 
code because of that.


So I would like to get rid of any use of range in new functions.

Cheers,

--
Julien Grall

[XEN PATCH v3] device_tree: address violations of MISRA C:2012 Rules 8.2 and 8.3

[Federico Serafini]

Give a name to unnamed parameters thus addressing violations of
MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
named parameters").
Keep consistency between parameter names and types used in function
declarations and the ones used in the corresponding function
definitions, thus addressing violations of MISRA C:2012 Rule 8.3
("All declarations of an object or function shall use the same names
and type qualifiers").

No functional changes.

Signed-off-by: Federico Serafini 
---
Changes in v3:
  - use parameter name 'dev' instead of 'device'.
---
Changes in v2:
  - improved consistency in parameter renaming.
---
 xen/common/device_tree.c  | 16 
 xen/include/xen/device_tree.h | 20 ++--
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0677193ab3..0522fdf976 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -85,11 +85,11 @@ struct dt_bus
 unsigned int (*get_flags)(const __be32 *addr);
 };
 
-void dt_get_range(const __be32 **cell, const struct dt_device_node *np,
+void dt_get_range(const __be32 **cellp, const struct dt_device_node *np,
   u64 *address, u64 *size)
 {
-*address = dt_next_cell(dt_n_addr_cells(np), cell);
-*size = dt_next_cell(dt_n_size_cells(np), cell);
+*address = dt_next_cell(dt_n_addr_cells(np), cellp);
+*size = dt_next_cell(dt_n_size_cells(np), cellp);
 }
 
 void dt_set_cell(__be32 **cellp, int size, u64 val)
@@ -993,9 +993,9 @@ int dt_device_get_paddr(const struct dt_device_node *dev, 
unsigned int index,
 }
 
 int dt_for_each_range(const struct dt_device_node *dev,
-  int (*cb)(const struct dt_device_node *,
+  int (*cb)(const struct dt_device_node *dev,
 uint64_t addr, uint64_t length,
-void *),
+void *data),
   void *data)
 {
 const struct dt_device_node *parent = NULL;
@@ -1197,9 +1197,9 @@ unsigned int dt_number_of_address(const struct 
dt_device_node *dev)
 }
 
 int dt_for_each_irq_map(const struct dt_device_node *dev,
-int (*cb)(const struct dt_device_node *,
-  const struct dt_irq *,
-  void *),
+int (*cb)(const struct dt_device_node *dev,
+  const struct dt_irq *dt_irq,
+  void *data),
 void *data)
 {
 const struct dt_device_node *ipar, *tnode, *old = NULL;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index c2eada7489..1d79e23b28 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -538,7 +538,7 @@ bool_t dt_machine_is_compatible(const char *compat);
  * Returns a node pointer with refcount incremented, use
  * of_node_put() on it when done.
  */
-struct dt_device_node *dt_find_node_by_name(struct dt_device_node *node,
+struct dt_device_node *dt_find_node_by_name(struct dt_device_node *from,
 const char *name);
 
 /**
@@ -622,12 +622,12 @@ unsigned int dt_number_of_irq(const struct dt_device_node 
*device);
 
 /**
  * dt_number_of_address - Get the number of addresses for a device
- * @device: the device whose number of address is to be retrieved
+ * @dev: the device whose number of address is to be retrieved
  *
  * Return the number of address for this device or 0 if there is no
  * address or an error occurred.
  */
-unsigned int dt_number_of_address(const struct dt_device_node *device);
+unsigned int dt_number_of_address(const struct dt_device_node *dev);
 
 /**
  * dt_device_get_irq - Resolve an interrupt for a device
@@ -639,7 +639,7 @@ unsigned int dt_number_of_address(const struct 
dt_device_node *device);
  * device-tree node. It's the high level pendant to dt_device_get_raw_irq().
  */
 int dt_device_get_irq(const struct dt_device_node *device, unsigned int index,
-  struct dt_irq *irq);
+  struct dt_irq *out_irq);
 
 /**
  * dt_device_get_raw_irq - Resolve an interrupt for a device without 
translation
@@ -652,7 +652,7 @@ int dt_device_get_irq(const struct dt_device_node *device, 
unsigned int index,
  */
 int dt_device_get_raw_irq(const struct dt_device_node *device,
   unsigned int index,
-  struct dt_raw_irq *irq);
+  struct dt_raw_irq *out_irq);
 
 /**
  * dt_irq_translate - Translate an irq
@@ -668,9 +668,9 @@ int dt_irq_translate(const struct dt_raw_irq *raw, struct 
dt_irq *out_irq);
  * @data: Caller data passed to callback
  */
 int dt_for_each_irq_map(const struct dt_device_node *dev,
-int (*cb)(const struct dt_device_node *,
-  const struct dt_irq *,
- 

[PATCH] xen/public: fix flexible array definitions

[Juergen Gross]

Flexible arrays in public headers can be problematic with some
compilers.

Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
errors.

This includes arrays defined as "arr[1]", as seen with a recent Linux
kernel [1].

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217693

Signed-off-by: Juergen Gross 
---
 xen/include/public/io/cameraif.h | 2 +-
 xen/include/public/io/displif.h  | 2 +-
 xen/include/public/io/fsif.h | 4 ++--
 xen/include/public/io/pvcalls.h  | 2 +-
 xen/include/public/io/ring.h | 4 ++--
 xen/include/public/io/sndif.h| 2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/include/public/io/cameraif.h b/xen/include/public/io/cameraif.h
index 13763abef9..d6c69d6e1c 100644
--- a/xen/include/public/io/cameraif.h
+++ b/xen/include/public/io/cameraif.h
@@ -763,7 +763,7 @@ struct xencamera_buf_create_req {
  */
 struct xencamera_page_directory {
 grant_ref_t gref_dir_next_page;
-grant_ref_t gref[1]; /* Variable length */
+grant_ref_t gref[XEN_FLEX_ARRAY_DIM];
 };
 
 /*
diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
index 73d0cbdf15..4b9a27e960 100644
--- a/xen/include/public/io/displif.h
+++ b/xen/include/public/io/displif.h
@@ -537,7 +537,7 @@ struct xendispl_dbuf_create_req {
 
 struct xendispl_page_directory {
 grant_ref_t gref_dir_next_page;
-grant_ref_t gref[1]; /* Variable length */
+grant_ref_t gref[XEN_FLEX_ARRAY_DIM];
 };
 
 /*
diff --git a/xen/include/public/io/fsif.h b/xen/include/public/io/fsif.h
index ec57850233..0e1fba994a 100644
--- a/xen/include/public/io/fsif.h
+++ b/xen/include/public/io/fsif.h
@@ -40,7 +40,7 @@ struct fsif_read_request {
 int32_t pad;
 uint64_t len;
 uint64_t offset;
-grant_ref_t grefs[1];  /* Variable length */
+grant_ref_t grefs[XEN_FLEX_ARRAY_DIM];
 };
 
 struct fsif_write_request {
@@ -48,7 +48,7 @@ struct fsif_write_request {
 int32_t pad;
 uint64_t len;
 uint64_t offset;
-grant_ref_t grefs[1];  /* Variable length */
+grant_ref_t grefs[XEN_FLEX_ARRAY_DIM];
 };
 
 struct fsif_stat_request {
diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h
index 230b0719e3..c8c7602470 100644
--- a/xen/include/public/io/pvcalls.h
+++ b/xen/include/public/io/pvcalls.h
@@ -30,7 +30,7 @@ struct pvcalls_data_intf {
 uint8_t pad2[52];
 
 RING_IDX ring_order;
-grant_ref_t ref[];
+grant_ref_t ref[XEN_FLEX_ARRAY_DIM];
 };
 DEFINE_XEN_FLEX_RING(pvcalls);
 
diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 0cae4367be..fa43396318 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -110,7 +110,7 @@ struct __name##_sring { 
\
 uint8_t pvt_pad[4]; \
 } pvt;  \
 uint8_t __pad[44];  \
-union __name##_sring_entry ring[1]; /* variable-length */   \
+union __name##_sring_entry ring[XEN_FLEX_ARRAY_DIM];\
 };  \
 \
 /* "Front" end's private variables */   \
@@ -479,7 +479,7 @@ struct name##_data_intf {   
  \
 uint8_t pad2[56]; \
   \
 RING_IDX ring_order;  \
-grant_ref_t ref[];\
+grant_ref_t ref[XEN_FLEX_ARRAY_DIM];  \
 };\
 DEFINE_XEN_FLEX_RING(name)
 
diff --git a/xen/include/public/io/sndif.h b/xen/include/public/io/sndif.h
index 4234a47c87..32f1fde4d6 100644
--- a/xen/include/public/io/sndif.h
+++ b/xen/include/public/io/sndif.h
@@ -659,7 +659,7 @@ struct xensnd_open_req {
 
 struct xensnd_page_directory {
 grant_ref_t gref_dir_next_page;
-grant_ref_t gref[1]; /* Variable length */
+grant_ref_t gref[XEN_FLEX_ARRAY_DIM];
 };
 
 /*
-- 
2.35.3

[xen-4.15-testing test] 181995: tolerable trouble: fail/pass/starved - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  faa4e2b1cf8022497a7b60c5b50a3bd280a5fc65
baseline version:
 xen  87cb0fd8757542893336aa2ffce3947451adf144

Last test of basis   180426  2023-04-26 07:39:28 Z   90 days
Testing same since   181995  2023-07-24 16:37:09 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Roger Pau Monné 

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

Re: Fwd: UBSAN: index 1 is out of range for type 'xen_netif_rx_sring_entry [1]'

[Juergen Gross]

On 25.07.23 15:24, Juergen Gross wrote:

On 23.07.23 02:06, Nathan Chancellor wrote:

On Sat, Jul 22, 2023 at 07:21:05AM +0700, Bagas Sanjaya wrote:

Hi,

I notice a regression report on Bugzilla [1]. Quoting from it:


Hi Kernel Team,

I rebuild today latest version from mainline repo.
And i notice issue regarding xen-netfront.c.

Error:
[    3.477400] 

[    3.477633] UBSAN: array-index-out-of-bounds in 
drivers/net/xen-netfront.c:1291:3

[    3.477858] index 1 is out of range for type 'xen_netif_rx_sring_entry [1]'
[    3.478085] CPU: 0 PID: 700 Comm: NetworkManager Not tainted 
6.5.0-rc2-1-generation1 #3
[    3.478088] Hardware name: Intel Corporation W2600CR/W2600CR, BIOS 
SE5C600.86B.02.06.0007.082420181029 01/13/2022

[    3.478090] Call Trace:
[    3.478092]  
[    3.478097]  dump_stack_lvl+0x48/0x70
[    3.478105]  dump_stack+0x10/0x20
[    3.478107]  __ubsan_handle_out_of_bounds+0xc6/0x110
[    3.478114]  xennet_poll+0xa94/0xac0
[    3.478118]  ? generic_smp_call_function_single_interrupt+0x13/0x20
[    3.478125]  __napi_poll+0x33/0x200
[    3.478131]  net_rx_action+0x181/0x2e0
[    3.478135]  __do_softirq+0xd9/0x346
[    3.478139]  do_softirq.part.0+0x41/0x80
[    3.478144]  
[    3.478145]  
[    3.478146]  __local_bh_enable_ip+0x72/0x80
[    3.478149]  _raw_spin_unlock_bh+0x1d/0x30
[    3.478151]  xennet_open+0x75/0x160
[    3.478154]  __dev_open+0x105/0x1d0
[    3.478156]  __dev_change_flags+0x1b5/0x230
[    3.478158]  dev_change_flags+0x27/0x80
[    3.478160]  do_setlink+0x3d2/0x12b0
[    3.478164]  ? __nla_validate_parse+0x5b/0xdb0
[    3.478169]  __rtnl_newlink+0x6f6/0xb10
[    3.478173]  ? rtnl_newlink+0x2f/0x80
[    3.478177]  rtnl_newlink+0x48/0x80
[    3.478180]  rtnetlink_rcv_msg+0x170/0x430
[    3.478183]  ? fib6_clean_node+0xad/0x190
[    3.478188]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[    3.478191]  netlink_rcv_skb+0x5d/0x110
[    3.478195]  rtnetlink_rcv+0x15/0x30
[    3.478198]  netlink_unicast+0x247/0x390
[    3.478200]  netlink_sendmsg+0x25e/0x4e0
[    3.478202]  sock_sendmsg+0xaf/0xc0
[    3.478204]  sys_sendmsg+0x2a9/0x350
[    3.478206]  ___sys_sendmsg+0x9a/0xf0
[    3.478212]  ? _copy_from_iter+0x80/0x4a0
[    3.478217]  __sys_sendmsg+0x89/0xf0
[    3.478220]  __x64_sys_sendmsg+0x1d/0x30
[    3.478222]  do_syscall_64+0x5c/0x90
[    3.478226]  ? do_syscall_64+0x68/0x90
[    3.478228]  ? ksys_write+0xe6/0x100
[    3.478232]  ? exit_to_user_mode_prepare+0x49/0x220
[    3.478236]  ? syscall_exit_to_user_mode+0x1b/0x50
[    3.478240]  ? do_syscall_64+0x68/0x90
[    3.478242]  ? do_syscall_64+0x68/0x90
[    3.478243]  ? irqentry_exit_to_user_mode+0x9/0x30
[    3.478246]  ? irqentry_exit+0x43/0x50
[    3.478248]  ? sysvec_xen_hvm_callback+0x4b/0xd0
[    3.478250]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[    3.478253] RIP: 0033:0x7f973c244e4d
[    3.478268] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 ca ee ff 
ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 
3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 fe ee ff ff 48
[    3.478270] RSP: 002b:7fff4777f470 EFLAGS: 0293 ORIG_RAX: 
002e
[    3.478273] RAX: ffda RBX: 5583087c6480 RCX: 
7f973c244e4d
[    3.478274] RDX:  RSI: 7fff4777f4c0 RDI: 
000c
[    3.478276] RBP: 7fff4777f4c0 R08:  R09: 

[    3.478277] R10:  R11: 0293 R12: 
5583087c6480
[    3.478279] R13: 7fff4777f668 R14: 7fff4777f65c R15: 


[    3.478283]  
[    3.478284] 

[    3.685513] 

[    3.685751] UBSAN: array-index-out-of-bounds in 
drivers/net/xen-netfront.c:485:7

[    3.686111] index 1 is out of range for type 'xen_netif_tx_sring_entry [1]'
[    3.686379] CPU: 1 PID: 697 Comm: avahi-daemon Not tainted 
6.5.0-rc2-1-generation1 #3
[    3.686381] Hardware name: Intel Corporation W2600CR/W2600CR, BIOS 
SE5C600.86B.02.06.0007.082420181029 01/13/2022

[    3.686385] Call Trace:
[    3.686388]  
[    3.686391]  dump_stack_lvl+0x48/0x70
[    3.686399]  dump_stack+0x10/0x20
[    3.686399]  __ubsan_handle_out_of_bounds+0xc6/0x110
[    3.686403]  xennet_tx_setup_grant+0x1f7/0x230
[    3.686403]  ? __pfx_xennet_tx_setup_grant+0x10/0x10
[    3.686403]  gnttab_foreach_grant_in_range+0x5c/0x100
[    3.686415]  xennet_start_xmit+0x428/0x990
[    3.686415]  ? kmem_cache_alloc_node+0x1b1/0x3b0
[    3.686415]  dev_hard_start_xmit+0x68/0x1e0
[    3.686415]  sch_direct_xmit+0x10b/0x350
[    3.686415]  __dev_queue_xmit+0x512/0xda0
[    3.686439]  ? ___neigh_create+0x6cb/0x970
[    3.686439]  neigh_resolve_output+0x118/0x1e0
[    3.686446]  ip_finish_output2+0x181/0x540
[    3.686450]  ? netif_rx_internal+0x46/0x140
[    3.686456]  

Re: [PATCH v2 2/5] x86/ioapic: RTE modifications must use ioapic_write_entry

[Roger Pau Monné]

On Tue, Jul 18, 2023 at 05:40:18PM +0200, Jan Beulich wrote:
> On 18.07.2023 14:43, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/io_apic.c
> > +++ b/xen/arch/x86/io_apic.c
> > @@ -584,16 +585,16 @@ set_ioapic_affinity_irq(struct irq_desc *desc, const 
> > cpumask_t *mask)
> >  dest = SET_APIC_LOGICAL_ID(dest);
> >  entry = irq_2_pin + irq;
> >  for (;;) {
> > -unsigned int data;
> > +struct IO_APIC_route_entry rte;
> > +
> >  pin = entry->pin;
> >  if (pin == -1)
> >  break;
> >  
> > -io_apic_write(entry->apic, 0x10 + 1 + pin*2, dest);
> > -data = io_apic_read(entry->apic, 0x10 + pin*2);
> > -data &= ~IO_APIC_REDIR_VECTOR_MASK;
> > -data |= MASK_INSR(desc->arch.vector, 
> > IO_APIC_REDIR_VECTOR_MASK);
> > -io_apic_modify(entry->apic, 0x10 + pin*2, data);
> > +rte = __ioapic_read_entry(entry->apic, pin, false);
> > +rte.dest.dest32 = dest;
> > +rte.vector = desc->arch.vector;
> > +__ioapic_write_entry(entry->apic, pin, false, rte);
> 
> ... this makes me wonder whether there shouldn't be an
> __ioapic_modify_entry() capable of suppressing one of the two
> writes (but still being handed the full RTE).

I've wondered about this, and I'm not sure how often can one of the
two writes be suppressed here, as we modify both the low (for the
vector) and the high part of the RTE (for the destination).  It's
unlikely that the same vector could be used on both destinations, and
IMO such case doesn't warrant the introduction of the extra logic
required in order to suppress one of the writes.

Am I overlooking something?

Thanks, Roger.

Re: [PATCH v6 06/15] cpufreq: Add Hardware P-State (HWP) driver

[Jason Andryuk]

On Tue, Jul 25, 2023 at 2:27 AM Jan Beulich  wrote:
>
> On 24.07.2023 21:49, Jason Andryuk wrote:
> > On Mon, Jul 24, 2023 at 12:15 PM Jan Beulich  wrote:
> >> On 24.07.2023 14:58, Jason Andryuk wrote:
> >>> --- /dev/null
> >>> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c
> >>> +#define hwp_err(cpu, fmt, ...) \
> >>> +printk(XENLOG_ERR "HWP: CPU%u error: " fmt, cpu, ##__VA_ARGS__)
> >>> +#define hwp_info(fmt, ...)printk(XENLOG_INFO "HWP: " fmt, 
> >>> ##__VA_ARGS__)
> >>
> >> I'm not convinced ", ##__VA_ARGS__" is a good construct to use. I notice
> >> we have a few instances (mainly in code inherited from elsewhere), but I
> >> think it ought to either be plain C99 style (without the ##) or purely
> >> the gcc extension form (not using __VA_ARGS__).
> >
> > Using plain __VA_ARGS__ doesn't work for the cases without arguments:
> > arch/x86/acpi/cpufreq/hwp.c:78:53: error: expected expression before ‘)’ 
> > token
> >78 | printk(XENLOG_DEBUG "HWP: " fmt, __VA_ARGS__);  \
> >   | ^
> > arch/x86/acpi/cpufreq/hwp.c:201:9: note: in expansion of macro ‘hwp_verbose’
> >   201 | hwp_verbose("disabled: No energy/performance
> > preference available");
> >   | ^~~
>
> Of course.
>
> > I can use "__VA_OPT__(,) __VA_ARGS__" though.
>
> __VA_OPT__ is yet newer than C99, so this is an option only if all
> compilers we continue to support actually know of this.

Right, sorry.

> We have no
> uses of it in the codebase so far, which suggests you might best go
> with the longstanding gcc extension here.

FTAOD, "##__VA_ARGS__" is the longstanding extension?  It's the only
one I've been able to get to compile.  I'm reading
https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html and it
mentions a few different extensions.

This part seemed promising:
"""
This has been fixed in C++20, and GNU CPP also has a pair of
extensions which deal with this problem.

First, in GNU CPP, and in C++ beginning in C++20, you are allowed to
leave the variable argument out entirely:

eprintf ("success!\n")
 → fprintf(stderr, "success!\n", );
"""

However, it doesn't seem to actually work for me.  I still get an
error like the one above for plain __VA_ARGS__.  That is for:

#define hwp_err(cpu, fmt, args...) \
printk(XENLOG_ERR "HWP: CPU%u error: " fmt, cpu, args)

I can drop "fmt" from hwp_info() and hwp_verbose() to just use
__VA_ARGS__, but that doesn't work for hwp_err() since we want to
re-order fmt and cpu inside the macro.

Thanks,
Jason

Re: Fwd: UBSAN: index 1 is out of range for type 'xen_netif_rx_sring_entry [1]'

[Juergen Gross]

On 23.07.23 02:06, Nathan Chancellor wrote:

On Sat, Jul 22, 2023 at 07:21:05AM +0700, Bagas Sanjaya wrote:

Hi,

I notice a regression report on Bugzilla [1]. Quoting from it:


Hi Kernel Team,

I rebuild today latest version from mainline repo.
And i notice issue regarding xen-netfront.c.

Error:
[3.477400] 

[3.477633] UBSAN: array-index-out-of-bounds in 
drivers/net/xen-netfront.c:1291:3
[3.477858] index 1 is out of range for type 'xen_netif_rx_sring_entry [1]'
[3.478085] CPU: 0 PID: 700 Comm: NetworkManager Not tainted 
6.5.0-rc2-1-generation1 #3
[3.478088] Hardware name: Intel Corporation W2600CR/W2600CR, BIOS 
SE5C600.86B.02.06.0007.082420181029 01/13/2022
[3.478090] Call Trace:
[3.478092]  
[3.478097]  dump_stack_lvl+0x48/0x70
[3.478105]  dump_stack+0x10/0x20
[3.478107]  __ubsan_handle_out_of_bounds+0xc6/0x110
[3.478114]  xennet_poll+0xa94/0xac0
[3.478118]  ? generic_smp_call_function_single_interrupt+0x13/0x20
[3.478125]  __napi_poll+0x33/0x200
[3.478131]  net_rx_action+0x181/0x2e0
[3.478135]  __do_softirq+0xd9/0x346
[3.478139]  do_softirq.part.0+0x41/0x80
[3.478144]  
[3.478145]  
[3.478146]  __local_bh_enable_ip+0x72/0x80
[3.478149]  _raw_spin_unlock_bh+0x1d/0x30
[3.478151]  xennet_open+0x75/0x160
[3.478154]  __dev_open+0x105/0x1d0
[3.478156]  __dev_change_flags+0x1b5/0x230
[3.478158]  dev_change_flags+0x27/0x80
[3.478160]  do_setlink+0x3d2/0x12b0
[3.478164]  ? __nla_validate_parse+0x5b/0xdb0
[3.478169]  __rtnl_newlink+0x6f6/0xb10
[3.478173]  ? rtnl_newlink+0x2f/0x80
[3.478177]  rtnl_newlink+0x48/0x80
[3.478180]  rtnetlink_rcv_msg+0x170/0x430
[3.478183]  ? fib6_clean_node+0xad/0x190
[3.478188]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[3.478191]  netlink_rcv_skb+0x5d/0x110
[3.478195]  rtnetlink_rcv+0x15/0x30
[3.478198]  netlink_unicast+0x247/0x390
[3.478200]  netlink_sendmsg+0x25e/0x4e0
[3.478202]  sock_sendmsg+0xaf/0xc0
[3.478204]  sys_sendmsg+0x2a9/0x350
[3.478206]  ___sys_sendmsg+0x9a/0xf0
[3.478212]  ? _copy_from_iter+0x80/0x4a0
[3.478217]  __sys_sendmsg+0x89/0xf0
[3.478220]  __x64_sys_sendmsg+0x1d/0x30
[3.478222]  do_syscall_64+0x5c/0x90
[3.478226]  ? do_syscall_64+0x68/0x90
[3.478228]  ? ksys_write+0xe6/0x100
[3.478232]  ? exit_to_user_mode_prepare+0x49/0x220
[3.478236]  ? syscall_exit_to_user_mode+0x1b/0x50
[3.478240]  ? do_syscall_64+0x68/0x90
[3.478242]  ? do_syscall_64+0x68/0x90
[3.478243]  ? irqentry_exit_to_user_mode+0x9/0x30
[3.478246]  ? irqentry_exit+0x43/0x50
[3.478248]  ? sysvec_xen_hvm_callback+0x4b/0xd0
[3.478250]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[3.478253] RIP: 0033:0x7f973c244e4d
[3.478268] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 ca ee ff ff 8b 54 
24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff 
ff 77 33 44 89 c7 48 89 44 24 08 e8 fe ee ff ff 48
[3.478270] RSP: 002b:7fff4777f470 EFLAGS: 0293 ORIG_RAX: 
002e
[3.478273] RAX: ffda RBX: 5583087c6480 RCX: 7f973c244e4d
[3.478274] RDX:  RSI: 7fff4777f4c0 RDI: 000c
[3.478276] RBP: 7fff4777f4c0 R08:  R09: 
[3.478277] R10:  R11: 0293 R12: 5583087c6480
[3.478279] R13: 7fff4777f668 R14: 7fff4777f65c R15: 
[3.478283]  
[3.478284] 

[3.685513] 

[3.685751] UBSAN: array-index-out-of-bounds in 
drivers/net/xen-netfront.c:485:7
[3.686111] index 1 is out of range for type 'xen_netif_tx_sring_entry [1]'
[3.686379] CPU: 1 PID: 697 Comm: avahi-daemon Not tainted 
6.5.0-rc2-1-generation1 #3
[3.686381] Hardware name: Intel Corporation W2600CR/W2600CR, BIOS 
SE5C600.86B.02.06.0007.082420181029 01/13/2022
[3.686385] Call Trace:
[3.686388]  
[3.686391]  dump_stack_lvl+0x48/0x70
[3.686399]  dump_stack+0x10/0x20
[3.686399]  __ubsan_handle_out_of_bounds+0xc6/0x110
[3.686403]  xennet_tx_setup_grant+0x1f7/0x230
[3.686403]  ? __pfx_xennet_tx_setup_grant+0x10/0x10
[3.686403]  gnttab_foreach_grant_in_range+0x5c/0x100
[3.686415]  xennet_start_xmit+0x428/0x990
[3.686415]  ? kmem_cache_alloc_node+0x1b1/0x3b0
[3.686415]  dev_hard_start_xmit+0x68/0x1e0
[3.686415]  sch_direct_xmit+0x10b/0x350
[3.686415]  __dev_queue_xmit+0x512/0xda0
[3.686439]  ? ___neigh_create+0x6cb/0x970
[3.686439]  neigh_resolve_output+0x118/0x1e0
[3.686446]  ip_finish_output2+0x181/0x540
[3.686450]  ? netif_rx_internal+0x46/0x140
[3.686456]  __ip_finish_output+0xb6/0x180
[3.686456]  ? 

Re: [XEN PATCH v2] device_tree: address violations of MISRA C:2012 Rules 8.2 and 8.3

[Federico Serafini]

Hello Julien,

On 25/07/23 12:02, Julien Grall wrote:

-unsigned int dt_number_of_address(const struct dt_device_node *dev)
+unsigned int dt_number_of_address(const struct dt_device_node *device)
We have a structure called 'device', so wouldn't this result to violate 
another MISRA rule because identifiers are re-used?


In any case, I would prefer if we keep the shorter version (i.e. 'dev') 
as this is more common within device_tree.c. We can replace the other 
'device' at a leisure pace.


If you refer to the rule 5.3 ("An identifier declared in an inner scope
shall not hide an identifier declared in an outer scope") then no,
it is not a violation because there is no hiding.
To my knowledge, this does not cause violations of any other MISRA rule.

However, I agree with you,
the parameter name 'device' is not the best choice.
I will propose a v2.

Regards
--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)

[PATCH v4 6/6] libxl: add support for parsing MSR features

[Roger Pau Monne]

Introduce support for handling MSR features in
libxl_cpuid_parse_config().  The MSR policies are added to the
libxl_cpuid_policy like the CPUID one, which gets passed to
xc_cpuid_apply_policy().

This allows existing users of libxl to provide MSR related features as
key=value pairs to libxl_cpuid_parse_config() without requiring the
usage of a different API.

Signed-off-by: Roger Pau Monné 
Acked-by: Anthony PERARD 
---
Changes since v2:
 - Add some braces.
---
 tools/libs/light/libxl_cpuid.c | 64 +-
 1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index 0daa564abb81..46dd2ce5f9e3 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -157,6 +157,60 @@ static int cpuid_add(libxl_cpuid_policy_list *policy,
 return 0;
 }
 
+static struct xc_msr *msr_find_match(libxl_cpuid_policy_list *pl, uint32_t 
index)
+{
+unsigned int i = 0;
+libxl_cpuid_policy_list policy = *pl;
+
+if (policy == NULL)
+policy = *pl = calloc(1, sizeof(*policy));
+
+if (policy->msr != NULL) {
+for (i = 0; policy->msr[i].index != XC_MSR_INPUT_UNUSED; i++) {
+if (policy->msr[i].index == index) {
+return >msr[i];
+}
+}
+}
+
+policy->msr = realloc(policy->msr, sizeof(struct xc_msr) * (i + 2));
+policy->msr[i].index = index;
+memset(policy->msr[i].policy, 'x', ARRAY_SIZE(policy->msr[0].policy) - 1);
+policy->msr[i].policy[ARRAY_SIZE(policy->msr[0].policy) - 1] = '\0';
+policy->msr[i + 1].index = XC_MSR_INPUT_UNUSED;
+
+return >msr[i];
+}
+
+static int msr_add(libxl_cpuid_policy_list *policy, uint32_t index, unsigned 
int bit,
+   const char *val)
+{
+struct xc_msr *entry = msr_find_match(policy, index);
+
+/* Only allow options taking a character for MSRs, no values allowed. */
+if (strlen(val) != 1)
+return 3;
+
+switch (val[0]) {
+case '0':
+case '1':
+case 'x':
+case 'k':
+entry->policy[63 - bit] = val[0];
+break;
+
+case 's':
+/* Translate s -> k as xc_msr doesn't support the deprecated 's'. */
+entry->policy[63 - bit] = 'k';
+break;
+
+default:
+return 3;
+}
+
+return 0;
+}
+
 struct feature_name {
 const char *name;
 unsigned int bit;
@@ -336,7 +390,15 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*policy, const char* str)
 }
 
 case FEAT_MSR:
-return 2;
+{
+unsigned int bit = feat->bit % 32;
+
+if (feature_to_policy[feat->bit / 32].msr.reg == CPUID_REG_EDX)
+bit += 32;
+
+return msr_add(policy, feature_to_policy[feat->bit / 32].msr.index,
+   bit, val);
+}
 }
 
 return 2;
-- 
2.41.0

[PATCH v4 5/6] libxl: use the cpuid feature names from cpufeatureset.h

[Roger Pau Monne]

The current implementation in libxl_cpuid_parse_config() requires
keeping a list of cpuid feature bits that should be mostly in sync
with the contents of cpufeatureset.h.

Avoid such duplication by using the automatically generated list of
cpuid features in INIT_FEATURE_NAMES in order to map feature names to
featureset bits, and then translate from featureset bits into cpuid
leaf, subleaf, register tuple.

Note that the full contents of the previous cpuid translation table
can't be removed.  That's because some feature names allowed by libxl
are not described in the featuresets, or because naming has diverged
and the previous nomenclature is preserved for compatibility reasons.

Should result in no functional change observed by callers, albeit some
new cpuid features will be available as a result of the change.

While there constify cpuid_flags name field.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Anthony PERARD 
---
Changes since v1:
 - const unnamed structure cast.
 - Declare struct feature_name outside the function.
 - Use strcmp.
 - Fix indentation.
 - Add back missing feature name options.
 - Return ERROR_NOMEM if allocation fails.
 - Improve xl.cfg documentation about how to reference the features
   described in the public header.
---
 docs/man/xl.cfg.5.pod.in   |  24 +--
 tools/libs/light/libxl_cpuid.c | 267 -
 tools/xl/xl_parse.c|   3 +
 3 files changed, 107 insertions(+), 187 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 3979be2a590a..55161856f4c7 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2010,24 +2010,16 @@ proccount procpkg stepping
 
 =back
 
-List of keys taking a character:
+List of keys taking a character can be found in the public header file
+Lhttps://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,arch-x86,cpufeatureset.h.html>
 
-=over 4
-
-3dnow 3dnowext 3dnowprefetch abm acpi adx aes altmovcr8 apic arat avx avx2
-avx512-4fmaps avx512-4vnniw avx512bw avx512cd avx512dq avx512er avx512f
-avx512ifma avx512pf avx512vbmi avx512vl bmi1 bmi2 clflushopt clfsh clwb cmov
-cmplegacy cmpxchg16 cmpxchg8 cmt cntxid dca de ds dscpl dtes64 erms est extapic
-f16c ffxsr fma fma4 fpu fsgsbase fxsr hle htt hypervisor ia64 ibs invpcid
-invtsc lahfsahf lm lwp mca mce misalignsse mmx mmxext monitor movbe mpx msr
-mtrr nodeid nx ospke osvw osxsave pae page1gb pat pbe pcid pclmulqdq pdcm
-perfctr_core perfctr_nb pge pku popcnt pse pse36 psn rdrand rdseed rdtscp rtm
-sha skinit smap smep smx ss sse sse2 sse3 sse4.1 sse4.2 sse4_1 sse4_2 sse4a
-ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate
-svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc tsc-deadline tsc_adjust
-umip vme vmx wdt x2apic xop xsave xtpr
+The feature names described in C should be specified in all
+lowercase letters, and with underscores converted to hyphens.  For example in
+order to reference feature C the string C should be used.
 
-=back
+Note that C is described as an option that takes a value, and that
+takes precedence over the C flag in C.  The feature
+flag must be referenced as C.
 
 =back
 
diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index f04b192c0e44..0daa564abb81 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -14,6 +14,8 @@
 
 #include "libxl_internal.h"
 
+#include 
+
 int libxl__cpuid_policy_is_empty(libxl_cpuid_policy_list *pl)
 {
 return !*pl || (!libxl_cpuid_policy_list_length(pl) && !(*pl)->msr);
@@ -60,7 +62,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *pl)
  * Used for the static structure describing all features.
  */
 struct cpuid_flags {
-char* name;
+const char *name;
 uint32_t leaf;
 uint32_t subleaf;
 int reg;
@@ -153,7 +155,19 @@ static int cpuid_add(libxl_cpuid_policy_list *policy,
 entry->policy[flag->reg - 1] = resstr;
 
 return 0;
+}
+
+struct feature_name {
+const char *name;
+unsigned int bit;
+};
+
+static int search_feature(const void *a, const void *b)
+{
+const char *key = a;
+const char *feat = ((const struct feature_name *)b)->name;
 
+return strcmp(key, feat);
 }
 
 /* parse a single key=value pair and translate it into the libxc
@@ -176,208 +190,42 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*policy, const char* str)
 {"proccount",0x0001, NA, CPUID_REG_EBX, 16,  8},
 {"localapicid",  0x0001, NA, CPUID_REG_EBX, 24,  8},
 
-{"sse3", 0x0001, NA, CPUID_REG_ECX,  0,  1},
-{"pclmulqdq",0x0001, NA, CPUID_REG_ECX,  1,  1},
-{"dtes64",   0x0001, NA, CPUID_REG_ECX,  2,  1},
-{"monitor",  0x0001, NA, CPUID_REG_ECX,  3,  1},
-{"dscpl",0x0001, NA, CPUID_REG_ECX,  4,  1},
-{"vmx",  0x0001, NA, CPUID_REG_ECX,  5,  1},
-{"smx",  0x0001, NA, CPUID_REG_ECX,  6,  

[PATCH v4 2/6] libxl: change the type of libxl_cpuid_policy_list

[Roger Pau Monne]

Currently libxl_cpuid_policy_list is an opaque type to the users of
libxl, and internally it's an array of xc_xend_cpuid objects.

Change the type to instead be a structure that contains one array for
CPUID policies, in preparation for it also holding another array for
MSR policies.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Anthony PERARD 
---
Changes since v2:
 - Add braces in the inner loop.
 - Do not set the policy to NULL.
---
 tools/include/libxl.h |  8 +--
 tools/libs/light/libxl_cpuid.c| 87 ---
 tools/libs/light/libxl_internal.h |  4 ++
 3 files changed, 63 insertions(+), 36 deletions(-)

diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index cac641a7eba2..f3975ecc021f 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -1455,12 +1455,8 @@ typedef struct {
 void libxl_bitmap_init(libxl_bitmap *map);
 void libxl_bitmap_dispose(libxl_bitmap *map);
 
-/*
- * libxl_cpuid_policy is opaque in the libxl ABI.  Users of both libxl and
- * libxc may not make assumptions about xc_xend_cpuid.
- */
-typedef struct xc_xend_cpuid libxl_cpuid_policy;
-typedef libxl_cpuid_policy * libxl_cpuid_policy_list;
+struct libxl__cpu_policy;
+typedef struct libxl__cpu_policy *libxl_cpuid_policy_list;
 void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list);
 int libxl_cpuid_policy_list_length(const libxl_cpuid_policy_list *l);
 void libxl_cpuid_policy_list_copy(libxl_ctx *ctx,
diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index c96aeb3bce46..3c8b2a72c0b8 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -19,22 +19,29 @@ int libxl__cpuid_policy_is_empty(libxl_cpuid_policy_list 
*pl)
 return !libxl_cpuid_policy_list_length(pl);
 }
 
-void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
+void libxl_cpuid_dispose(libxl_cpuid_policy_list *pl)
 {
-int i, j;
-libxl_cpuid_policy_list cpuid_list = *p_cpuid_list;
+libxl_cpuid_policy_list policy = *pl;
 
-if (cpuid_list == NULL)
+if (policy == NULL)
 return;
-for (i = 0; cpuid_list[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
-for (j = 0; j < 4; j++)
-if (cpuid_list[i].policy[j] != NULL) {
-free(cpuid_list[i].policy[j]);
-cpuid_list[i].policy[j] = NULL;
+
+if (policy->cpuid) {
+unsigned int i, j;
+struct xc_xend_cpuid *cpuid_list = policy->cpuid;
+
+for (i = 0; cpuid_list[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
+for (j = 0; j < 4; j++) {
+if (cpuid_list[i].policy[j] != NULL) {
+free(cpuid_list[i].policy[j]);
+}
 }
+}
+free(policy->cpuid);
 }
-free(cpuid_list);
-*p_cpuid_list = NULL;
+
+free(policy);
+*pl = NULL;
 return;
 }
 
@@ -62,11 +69,17 @@ struct cpuid_flags {
 /* go through the dynamic array finding the entry for a specified leaf.
  * if no entry exists, allocate one and return that.
  */
-static libxl_cpuid_policy_list cpuid_find_match(libxl_cpuid_policy_list *list,
-  uint32_t leaf, uint32_t subleaf)
+static struct xc_xend_cpuid *cpuid_find_match(libxl_cpuid_policy_list *pl,
+  uint32_t leaf, uint32_t subleaf)
 {
+libxl_cpuid_policy_list policy = *pl;
+struct xc_xend_cpuid **list;
 int i = 0;
 
+if (policy == NULL)
+policy = *pl = calloc(1, sizeof(*policy));
+
+list = >cpuid;
 if (*list != NULL) {
 for (i = 0; (*list)[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
 if ((*list)[i].input[0] == leaf && (*list)[i].input[1] == subleaf)
@@ -86,7 +99,7 @@ static libxl_cpuid_policy_list 
cpuid_find_match(libxl_cpuid_policy_list *list,
  * Will overwrite earlier entries and thus can be called multiple
  * times.
  */
-int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str)
+int libxl_cpuid_parse_config(libxl_cpuid_policy_list *policy, const char* str)
 {
 #define NA XEN_CPUID_INPUT_UNUSED
 static const struct cpuid_flags cpuid_flags[] = {
@@ -345,7 +358,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*cpuid, const char* str)
 if (flag->name == NULL) {
 return 2;
 }
-entry = cpuid_find_match(cpuid, flag->leaf, flag->subleaf);
+entry = cpuid_find_match(policy, flag->leaf, flag->subleaf);
 resstr = entry->policy[flag->reg - 1];
 num = strtoull(val, , 0);
 flags[flag->length] = 0;
@@ -400,7 +413,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*cpuid, const char* str)
  * the strings for each register were directly exposed to the user.
  * Used for maintaining compatibility with older config files
  */
-int libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list *cpuid,
+int libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list *policy,
   const char* str)
 {
  

[PATCH v4 1/6] libs/guest: introduce support for setting guest MSRs

[Roger Pau Monne]

Like it's done with CPUID, introduce support for passing MSR values to
xc_cpuid_apply_policy().  The chosen format for expressing MSR policy
data matches the current one used for CPUID.  Note that existing
callers of xc_cpuid_apply_policy() can pass NULL as the value for the
newly introduced 'msr' parameter in order to preserve the same
functionality, and in fact that's done in libxl on this patch.

Signed-off-by: Roger Pau Monné 
Acked-by: Anthony PERARD 
---
Changes since v2:
 - Some code adjustment, no functional change.
---
 tools/include/xenctrl.h |  21 +++-
 tools/libs/guest/xg_cpuid_x86.c | 169 +++-
 tools/libs/light/libxl_cpuid.c  |   2 +-
 3 files changed, 188 insertions(+), 4 deletions(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index dba33d5d0f39..faec1dd82453 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -1822,6 +1822,21 @@ struct xc_xend_cpuid {
 char *policy[4];
 };
 
+/*
+ * MSR policy data.
+ *
+ * The format of the policy string is the following:
+ *   '1' -> force to 1
+ *   '0' -> force to 0
+ *   'x' -> we don't care (use default)
+ *   'k' -> pass through host value
+ */
+struct xc_msr {
+uint32_t index;
+char policy[65];
+};
+#define XC_MSR_INPUT_UNUSED 0xu
+
 /*
  * Make adjustments to the CPUID settings for a domain.
  *
@@ -1833,13 +1848,15 @@ struct xc_xend_cpuid {
  * Either pass a full new @featureset (and @nr_features), or adjust individual
  * features (@pae, @itsc, @nested_virt).
  *
- * Then (optionally) apply legacy XEND overrides (@xend) to the result.
+ * Then (optionally) apply legacy XEND CPUID overrides (@xend) or MSR (@msr)
+ * to the result.
  */
 int xc_cpuid_apply_policy(xc_interface *xch,
   uint32_t domid, bool restore,
   const uint32_t *featureset,
   unsigned int nr_features, bool pae, bool itsc,
-  bool nested_virt, const struct xc_xend_cpuid *xend);
+  bool nested_virt, const struct xc_xend_cpuid *xend,
+  const struct xc_msr *msr);
 int xc_mca_op(xc_interface *xch, struct xen_mc *mc);
 int xc_mca_op_inject_v2(xc_interface *xch, unsigned int flags,
 xc_cpumap_t cpumap, unsigned int nr_cpus);
diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c
index 5b035223f4f5..f2b1e809011d 100644
--- a/tools/libs/guest/xg_cpuid_x86.c
+++ b/tools/libs/guest/xg_cpuid_x86.c
@@ -423,10 +423,170 @@ static int xc_cpuid_xend_policy(
 return rc;
 }
 
+static int compare_msr(const void *l, const void *r)
+{
+const xen_msr_entry_t *lhs = l;
+const xen_msr_entry_t *rhs = r;
+
+if ( lhs->idx == rhs->idx )
+return 0;
+
+return lhs->idx < rhs->idx ? -1 : 1;
+}
+
+static xen_msr_entry_t *find_msr(
+xen_msr_entry_t *msrs, unsigned int nr_msrs,
+uint32_t index)
+{
+const xen_msr_entry_t key = { .idx = index };
+
+return bsearch(, msrs, nr_msrs, sizeof(*msrs), compare_msr);
+}
+
+
+static int xc_msr_policy(xc_interface *xch, domid_t domid,
+ const struct xc_msr *msr)
+{
+int rc;
+bool hvm;
+xc_domaininfo_t di;
+unsigned int nr_leaves, nr_msrs;
+uint32_t err_leaf = -1, err_subleaf = -1, err_msr = -1;
+/*
+ * Three full policies.  The host, default for the domain type,
+ * and domain current.
+ */
+xen_msr_entry_t *host = NULL, *def = NULL, *cur = NULL;
+unsigned int nr_host, nr_def, nr_cur;
+
+if ( (rc = xc_domain_getinfo_single(xch, domid, )) < 0 )
+{
+PERROR("Failed to obtain d%d info", domid);
+rc = -errno;
+goto out;
+}
+hvm = di.flags & XEN_DOMINF_hvm_guest;
+
+rc = xc_cpu_policy_get_size(xch, _leaves, _msrs);
+if ( rc )
+{
+PERROR("Failed to obtain policy info size");
+rc = -errno;
+goto out;
+}
+
+if ( (host = calloc(nr_msrs, sizeof(*host))) == NULL ||
+ (def  = calloc(nr_msrs, sizeof(*def)))  == NULL ||
+ (cur  = calloc(nr_msrs, sizeof(*cur)))  == NULL )
+{
+ERROR("Unable to allocate memory for %u CPUID leaves", nr_leaves);
+rc = -ENOMEM;
+goto out;
+}
+
+/* Get the domain's current policy. */
+nr_leaves = 0;
+nr_cur = nr_msrs;
+rc = get_domain_cpu_policy(xch, domid, _leaves, NULL, _cur, cur);
+if ( rc )
+{
+PERROR("Failed to obtain d%d current policy", domid);
+rc = -errno;
+goto out;
+}
+
+/* Get the domain type's default policy. */
+nr_leaves = 0;
+nr_def = nr_msrs;
+rc = get_system_cpu_policy(xch, hvm ? XEN_SYSCTL_cpu_policy_hvm_default
+: XEN_SYSCTL_cpu_policy_pv_default,
+   _leaves, NULL, _def, def);
+if ( rc )
+{
+PERROR("Failed to obtain %s def policy", hvm ? "hvm" : "pv");
+rc = 

[PATCH v4 3/6] libxl: introduce MSR data in libxl_cpuid_policy

[Roger Pau Monne]

Add a new array field to libxl_cpuid_policy in order to store the MSR
policies.

Adding the MSR data in the libxl_cpuid_policy_list type is done so
that existing users can seamlessly pass MSR features as part of the
CPUID data, without requiring the introduction of a separate
domain_build_info field, and a new set of handlers functions.

Note that support for parsing the old JSON format is kept, as that's
required in order to restore domains or received migrations from
previous tool versions.  Differentiation between the old and the new
formats is done based on whether the contents of the 'cpuid' field is
an array or a map JSON object.

Signed-off-by: Roger Pau Monné 
---
Changes since v3:
 - Keep support for the old json format in the parse function.

Changes since v2:
 - Unconditionally call free().
 - Implement the JSON marshaling functions.
---
 tools/libs/light/libxl_cpuid.c| 152 ++
 tools/libs/light/libxl_internal.h |   1 +
 tools/libs/light/libxl_types.idl  |   2 +-
 3 files changed, 138 insertions(+), 17 deletions(-)

diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index 3c8b2a72c0b8..dd97699bbde7 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -16,7 +16,7 @@
 
 int libxl__cpuid_policy_is_empty(libxl_cpuid_policy_list *pl)
 {
-return !libxl_cpuid_policy_list_length(pl);
+return !*pl || (!libxl_cpuid_policy_list_length(pl) && !(*pl)->msr);
 }
 
 void libxl_cpuid_dispose(libxl_cpuid_policy_list *pl)
@@ -40,6 +40,8 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *pl)
 free(policy->cpuid);
 }
 
+free(policy->msr);
+
 free(policy);
 *pl = NULL;
 return;
@@ -516,7 +518,8 @@ int libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, 
bool restore,
 
 r = xc_cpuid_apply_policy(ctx->xch, domid, restore, NULL, 0,
   pae, itsc, nested_virt,
-  info->cpuid ? info->cpuid->cpuid : NULL, NULL);
+  info->cpuid ? info->cpuid->cpuid : NULL,
+  info->cpuid ? info->cpuid->msr : NULL);
 if (r)
 LOGEVD(ERROR, -r, domid, "Failed to apply CPUID policy");
 
@@ -528,16 +531,22 @@ static const char *input_names[2] = { "leaf", "subleaf" };
 static const char *policy_names[4] = { "eax", "ebx", "ecx", "edx" };
 /*
  * Aiming for:
- * [
- * { 'leaf':'val-eax',
- *   'subleaf': 'val-ecx',
- *   'eax': 'filter',
- *   'ebx': 'filter',
- *   'ecx': 'filter',
- *   'edx': 'filter' },
- * { 'leaf':'val-eax', ..., 'eax': 'filter', ... },
- * ... etc ...
- * ]
+ * {   'cpuid': [
+ *  { 'leaf':'val-eax',
+ *'subleaf': 'val-ecx',
+ *'eax': 'filter',
+ *'ebx': 'filter',
+ *'ecx': 'filter',
+ *'edx': 'filter' },
+ *  { 'leaf':'val-eax', ..., 'eax': 'filter', ... },
+ *  ... etc ...
+ * ],
+ * 'msr': [
+ *{ 'index': 'val-index',
+ *  'policy': 'filter', },
+ *  ... etc ...
+ * ],
+ * }
  */
 
 yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
@@ -545,9 +554,16 @@ yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen 
hand,
 {
 libxl_cpuid_policy_list policy = *pl;
 struct xc_xend_cpuid *cpuid;
+const struct xc_msr *msr;
 yajl_gen_status s;
 int i, j;
 
+s = yajl_gen_map_open(hand);
+if (s != yajl_gen_status_ok) goto out;
+
+s = libxl__yajl_gen_asciiz(hand, "cpuid");
+if (s != yajl_gen_status_ok) goto out;
+
 s = yajl_gen_array_open(hand);
 if (s != yajl_gen_status_ok) goto out;
 
@@ -582,6 +598,39 @@ yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen 
hand,
 
 empty:
 s = yajl_gen_array_close(hand);
+if (s != yajl_gen_status_ok) goto out;
+
+s = libxl__yajl_gen_asciiz(hand, "msr");
+if (s != yajl_gen_status_ok) goto out;
+
+s = yajl_gen_array_open(hand);
+if (s != yajl_gen_status_ok) goto out;
+
+if (!policy || !policy->msr) goto done;
+msr = policy->msr;
+
+for (i = 0; msr[i].index != XC_MSR_INPUT_UNUSED; i++) {
+s = yajl_gen_map_open(hand);
+if (s != yajl_gen_status_ok) goto out;
+
+s = libxl__yajl_gen_asciiz(hand, "index");
+if (s != yajl_gen_status_ok) goto out;
+s = yajl_gen_integer(hand, msr[i].index);
+if (s != yajl_gen_status_ok) goto out;
+s = libxl__yajl_gen_asciiz(hand, "policy");
+if (s != yajl_gen_status_ok) goto out;
+s = yajl_gen_string(hand,
+(const unsigned char *)msr[i].policy, 64);
+if (s != yajl_gen_status_ok) goto out;
+
+s = yajl_gen_map_close(hand);
+if (s != yajl_gen_status_ok) goto out;
+}
+
+done:
+s = yajl_gen_array_close(hand);
+if (s != yajl_gen_status_ok) goto out;
+s = 

[PATCH v4 4/6] libxl: split logic to parse user provided CPUID features

[Roger Pau Monne]

Move the CPUID value parsers out of libxl_cpuid_parse_config() into a
newly created cpuid_add() local helper.  This is in preparation for
also adding MSR feature parsing support.

No functional change intended.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Anthony PERARD 
---
Changes since v3:
 - Fix UB and use strtoul.
---
 tools/libs/light/libxl_cpuid.c | 120 +
 1 file changed, 63 insertions(+), 57 deletions(-)

diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
index dd97699bbde7..f04b192c0e44 100644
--- a/tools/libs/light/libxl_cpuid.c
+++ b/tools/libs/light/libxl_cpuid.c
@@ -96,6 +96,66 @@ static struct xc_xend_cpuid 
*cpuid_find_match(libxl_cpuid_policy_list *pl,
 return *list + i;
 }
 
+static int cpuid_add(libxl_cpuid_policy_list *policy,
+ const struct cpuid_flags *flag, const char *val)
+{
+struct xc_xend_cpuid *entry = cpuid_find_match(policy, flag->leaf,
+   flag->subleaf);
+unsigned long num;
+char flags[33], *resstr, *endptr;
+unsigned int i;
+
+resstr = entry->policy[flag->reg - 1];
+num = strtoul(val, , 0);
+flags[flag->length] = 0;
+if (endptr != val) {
+/* if this was a valid number, write the binary form into the string */
+for (i = 0; i < flag->length; i++) {
+flags[flag->length - 1 - i] = "01"[(num >> i) & 1];
+}
+} else {
+switch(val[0]) {
+case 'x': case 'k': case 's':
+memset(flags, val[0], flag->length);
+break;
+default:
+return 3;
+}
+}
+
+if (resstr == NULL) {
+resstr = strdup("");
+}
+
+/* the family and model entry is potentially split up across
+ * two fields in Fn_0001_EAX, so handle them here separately.
+ */
+if (!strcmp(flag->name, "family")) {
+if (num < 16) {
+memcpy(resstr + (32 - 4) - flag->bit, flags + 4, 4);
+memcpy(resstr + (32 - 8) - 20, "", 8);
+} else {
+num -= 15;
+memcpy(resstr + (32 - 4) - flag->bit, "", 4);
+for (i = 0; i < 7; i++) {
+flags[7 - i] = "01"[num & 1];
+num >>= 1;
+}
+memcpy(resstr + (32 - 8) - 20, flags, 8);
+}
+} else if (!strcmp(flag->name, "model")) {
+memcpy(resstr + (32 - 4) - 16, flags, 4);
+memcpy(resstr + (32 - 4) - flag->bit, flags + 4, 4);
+} else {
+memcpy(resstr + (32 - flag->length) - flag->bit, flags,
+   flag->length);
+}
+entry->policy[flag->reg - 1] = resstr;
+
+return 0;
+
+}
+
 /* parse a single key=value pair and translate it into the libxc
  * used interface using 32-characters strings for each register.
  * Will overwrite earlier entries and thus can be called multiple
@@ -340,12 +400,8 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*policy, const char* str)
 {NULL, 0, NA, CPUID_REG_INV, 0, 0}
 };
 #undef NA
-char *sep, *val, *endptr;
-int i;
+const char *sep, *val;
 const struct cpuid_flags *flag;
-struct xc_xend_cpuid *entry;
-unsigned long num;
-char flags[33], *resstr;
 
 sep = strchr(str, '=');
 if (sep == NULL) {
@@ -355,60 +411,10 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*policy, const char* str)
 }
 for (flag = cpuid_flags; flag->name != NULL; flag++) {
 if(!strncmp(str, flag->name, sep - str) && flag->name[sep - str] == 0)
-break;
-}
-if (flag->name == NULL) {
-return 2;
-}
-entry = cpuid_find_match(policy, flag->leaf, flag->subleaf);
-resstr = entry->policy[flag->reg - 1];
-num = strtoull(val, , 0);
-flags[flag->length] = 0;
-if (endptr != val) {
-/* if this was a valid number, write the binary form into the string */
-for (i = 0; i < flag->length; i++) {
-flags[flag->length - 1 - i] = "01"[!!(num & (1 << i))];
-}
-} else {
-switch(val[0]) {
-case 'x': case 'k': case 's':
-memset(flags, val[0], flag->length);
-break;
-default:
-return 3;
-}
-}
-
-if (resstr == NULL) {
-resstr = strdup("");
+return cpuid_add(policy, flag, val);
 }
 
-/* the family and model entry is potentially split up across
- * two fields in Fn_0001_EAX, so handle them here separately.
- */
-if (!strncmp(str, "family", sep - str)) {
-if (num < 16) {
-memcpy(resstr + (32 - 4) - flag->bit, flags + 4, 4);
-memcpy(resstr + (32 - 8) - 20, "", 8);
-} else {
-num -= 15;
-memcpy(resstr + (32 - 4) - flag->bit, "", 4);
-for (i = 0; i < 7; i++) {
-flags[7 - i] = "01"[num & 1];
- 

[PATCH v4 0/6] lib{xc,xl}: support for guest MSR features

[Roger Pau Monne]

Hello,

The following series adds support for handling guest MSR features as
defined in arch-x86/cpufeatureset.h.

The end result is the user being able to use such features with the
xl.cfg(5) cpuid option.  This also involves adding support to all the
underlying layers, so both libxl and libxc also get new functionality in
order to properly parse those.

Thanks, Roger.

Roger Pau Monne (6):
  libs/guest: introduce support for setting guest MSRs
  libxl: change the type of libxl_cpuid_policy_list
  libxl: introduce MSR data in libxl_cpuid_policy
  libxl: split logic to parse user provided CPUID features
  libxl: use the cpuid feature names from cpufeatureset.h
  libxl: add support for parsing MSR features

 docs/man/xl.cfg.5.pod.in  |  24 +-
 tools/include/libxl.h |   8 +-
 tools/include/xenctrl.h   |  21 +-
 tools/libs/guest/xg_cpuid_x86.c   | 169 +++-
 tools/libs/light/libxl_cpuid.c| 672 ++
 tools/libs/light/libxl_internal.h |   5 +
 tools/libs/light/libxl_types.idl  |   2 +-
 tools/xl/xl_parse.c   |   3 +
 8 files changed, 612 insertions(+), 292 deletions(-)

-- 
2.41.0

Re: [PATCH v6 1/3] x86/microcode: Ignore microcode loading interface for revision = -1

[Alejandro Vallejo]

On Tue, Jul 25, 2023 at 08:40:31AM +0200, Jan Beulich wrote:
> On 24.07.2023 18:52, Alejandro Vallejo wrote:
> > Some hypervisors report ~0 as the microcode revision to mean "don't issue
> > microcode updates". Ignore the microcode loading interface in that case.
> > 
> > Signed-off-by: Alejandro Vallejo 
> > Reviewed-by: Jan Beulich 
> 
> Hmm.
> 
> > --- a/xen/arch/x86/cpu/microcode/core.c
> > +++ b/xen/arch/x86/cpu/microcode/core.c
> > @@ -867,10 +867,23 @@ int __init early_microcode_init(unsigned long 
> > *module_map,
> >  return -ENODEV;
> >  }
> >  
> > -microcode_grab_module(module_map, mbi);
> > -
> >  ucode_ops.collect_cpu_info();
> >  
> > +/*
> > + * Some hypervisors deliberately report a microcode revision of -1 to
> > + * mean that they will not accept microcode updates. We take the hint
> > + * and ignore the microcode interface in that case.
> > + */
> > +if ( this_cpu(cpu_sig).rev == ~0 )
> > +{
> > +printk(XENLOG_INFO "Microcode loading disabled due to: %s",
> 
> While we have tentatively agreed to adjust what _will_ be emitted by
> default (subject to suitable justification in that change's
> description), such a patch is yet to be sent.
Ugh, that was indeed mistagged. Sorry about that. I touched several parts
of this patch shortly before sending it and it crept in by mistake.

> As it stands this message
> will be invisible by default.
Arguably, that's not necessarily a bad thing. The fact that microcode
cannot be updated is expected behaviour and it makes little sense to warn
about it. If only because they should already be aware of it through their
agreement with their provider.

The case I can think of where a warning would be sensible is where the
system has a microcode blob more recent than the currently installed
revision. This is something the admin may want to be aware of in order to
pester their provider for updates. In the common case the machine won't
even need such an update, so sending unconditional warnings per boot seems
unwarranted.

> 
> > +   "HW toggle");
> 
> With the comment talking about hypervisors, what is this string supposed
> to tell an observer of the message in a log file?
> 
> Jan
Nothing good. As you noticed later, that's the wrong substring off the last
patch and should've been "rev = ~0"

Thanks,
Alejandro

Re: [PATCH v4 2/2] xen/riscv: introduce identity mapping

[Oleksii]

On Tue, 2023-07-25 at 10:16 +0200, Jan Beulich wrote:
> On 24.07.2023 18:00, Oleksii wrote:
> > On Mon, 2023-07-24 at 16:11 +0200, Jan Beulich wrote:
> > > On 24.07.2023 11:42, Oleksii Kurochko wrote:
> > > > +void __init remove_identity_mapping(void)
> > > > +{
> > > > +    static pte_t *pgtbl = stage1_pgtbl_root;
> > > > +    static unsigned long load_start = XEN_VIRT_START;
> > > > +    static unsigned int pt_level = CONFIG_PAGING_LEVELS - 1;
> > > 
> > > These all want to be __initdata, but personally I find this way
> > > of
> > > recursing a little odd. Let's see what the maintainers say.
> > I'm not completely happy either. Initially I thought that it would
> > be
> > better to pass all this stuff as function's arguments.
> > 
> > But then it is needed to provide an access to stage1_pgtbl_root (
> > get_root_pt() function ? ). So remove_identity_mapping() will be
> > called
> > as remove_identity_mapping(get_root_pt(), _start,
> > CONFIG_PAGING_LELVELS
> > -1 ) or remove_identity_mapping(NULL, _start, CONFIG_PAGING_LELVELS
> > -1
> > ) and then check if first argument is NULL then initialize it with
> > stage1_pgtbl_root.
> > Also I am not sure that an 'user' should provide all this
> > information
> > to such function.
> > 
> > Could you recommend something better?
> 
> Well, to avoid the mess you are describing I would consider making
> remove_identity_mapping() itself a thin wrapper around the actual
> function which then invokes itself recursively. That'll keep the
> top-level call site tidy, and all the technical details confined to
> the (then) two functions.
Thanks a lot for the recommendation.

> 
> > > > +    unsigned long load_end = LINK_TO_LOAD(_end);
> > > > +    unsigned long xen_size;
> > > > +    unsigned long pt_level_size = XEN_PT_LEVEL_SIZE(pt_level);
> > > > +    unsigned long pte_nums;
> > > > +
> > > > +    unsigned long virt_indx = pt_index(pt_level,
> > > > XEN_VIRT_START);
> > > > +    unsigned long indx;
> > > > +
> > > > +    if ( load_start == XEN_VIRT_START )
> > > > +    load_start = LINK_TO_LOAD(_start);
> > > > +
> > > > +    xen_size = load_end - load_start;
> > > 
> > > When you come here recursively, don't you need to limit this
> > > instance of the function to a single page table's worth of
> > > address
> > > space (at the given level), using load_end only if that's yet
> > > lower?
> > Do you mean a case when load_start > load_end? If yes then I missed
> > that.
> 
> No, my concern is with the page table presently acted upon covering
> only a limited part of the address space. That "limited" is the full
> address space only for the top level table. You won't observe this
> though unless the Xen image crosses a 2Mb boundary. But if it does
> (and it may help if you arranged for big enough an image just for
> the purpose of debugging, simply by inserting enough dead code or
> data), and if all mappings are 4k ones, you'd run past the first L1
> table's worth of mappings on the first invocation of this function
> with a L1 table. (Of course hitting the condition may further
> require Xen and 1:1 mappings to be sufficiently close to one another,
> so that the zapping doesn't already occur at higher levels. But then
> the same situation could arise at higher levels when the image
> crosses a 1Gb or 512Gb boundary.)
In this case, all should be fine.

If we put identity and non-identity mapping as closely as possible.
I tested with the following input:
   XEN_VIRT_START = 0x8067
   load start = 0x8020
   Xen size = 4648960

So now pte on L2 level is shared, so we will go to L1, and calculate
the amount of pte nums on the L1 level. In the current one case, it is
3, so it will delete the first two L1's ptes ( as they have different
index from index of XEN_VIRT_START at L1 level so we are sure that
these ptes are used only for identity mapping and can be removed ),
move load_start += 4 MB, and for the last one L1's ptes which is shared
with non-identity mapping it will go to L0 table, calculate a number of
ptes needed to be cleaned based on 'new' load start and page level ( it
is 0x6f in the current case ) to finish removing of identity mapping.

I added some prints inside:
if ( virt_indx != indx )
{ 
And received the expected output I described above:
(level number) '-' means removed

(1) -
(1) -
(0) -
... 0x6f times
(0) -

> 
> > > > +    pte_nums = ROUNDUP(xen_size, pt_level_size) /
> > > > pt_level_size;
> > > > +
> > > > +    while ( pte_nums-- )
> > > > +    {
> > > > +    indx = pt_index(pt_level, load_start);
> > > >  
> > > > -    switch_stack_and_jump((unsigned long)cpu0_boot_stack +
> > > > STACK_SIZE,
> > > > -  cont_after_mmu_is_enabled);
> > > > +    if ( virt_indx != indx )
> > > > +    {
> > > > +    pgtbl[indx].pte = 0;
> > > > +    load_start += XEN_PT_LEVEL_SIZE(pt_level);
> > > > +    }
> > > > +    else
> > > > +    {
> > > > +    pgtbl =  (pte_t
> > > > 

[PATCH V4] xen: privcmd: Add support for irqfd

[Viresh Kumar]

Xen provides support for injecting interrupts to the guests via the
HYPERVISOR_dm_op() hypercall. The same is used by the Virtio based
device backend implementations, in an inefficient manner currently.

Generally, the Virtio backends are implemented to work with the Eventfd
based mechanism. In order to make such backends work with Xen, another
software layer needs to poll the Eventfds and raise an interrupt to the
guest using the Xen based mechanism. This results in an extra context
switch.

This is not a new problem in Linux though. It is present with other
hypervisors like KVM, etc. as well. The generic solution implemented in
the kernel for them is to provide an IOCTL call to pass the interrupt
details and eventfd, which lets the kernel take care of polling the
eventfd and raising of the interrupt, instead of handling this in user
space (which involves an extra context switch).

This patch adds support to inject a specific interrupt to guest using
the eventfd mechanism, by preventing the extra context switch.

Inspired by existing implementations for KVM, etc..

Signed-off-by: Viresh Kumar 
---
V3->V4
- Drop the imported definitions to hvm/dm_op.h.
- Make the caller pass a pointer to pre-filled "struct xen_dm_op" instance and
  get rid of irq and level fields.
- Enable the irqfd feature under a new Kconfig entry.

V2->V3
- Select EVENTFD from Kconfig

V1->V2:
- Improve error handling.
- Remove the unnecessary usage of list_for_each_entry_safe().
- Restrict the use of XEN_DMOP_set_irq_level to only ARM64.
- Import definitions from Xen to hvm/dm_op.h.

 drivers/xen/Kconfig|   8 ++
 drivers/xen/privcmd.c  | 286 -
 include/uapi/xen/privcmd.h |  14 ++
 3 files changed, 306 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d5d7c402b651..c7fabfab4c20 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -269,6 +269,14 @@ config XEN_PRIVCMD
  disaggregated Xen setups this driver might be needed for other
  domains, too.
 
+config XEN_PRIVCMD_IRQFD
+   bool "Xen irqfd support"
+   depends on XEN_PRIVCMD && XEN_VIRTIO && EVENTFD
+   default m
+   help
+ irqfd is a mechanism to inject a specific interrupt to a User VM using
+ a decoupled eventfd mechanism.
+
 config XEN_ACPI_PROCESSOR
tristate "Xen ACPI processor"
depends on XEN && XEN_PV_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index e2f580e30a86..584c8de56c5e 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -9,11 +9,16 @@
 
 #define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt
 
+#include 
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -833,6 +838,267 @@ static long privcmd_ioctl_mmap_resource(struct file *file,
return rc;
 }
 
+#ifdef CONFIG_XEN_PRIVCMD_IRQFD
+/* Irqfd support */
+static struct workqueue_struct *irqfd_cleanup_wq;
+static DEFINE_MUTEX(irqfds_lock);
+static LIST_HEAD(irqfds_list);
+
+struct privcmd_kernel_irqfd {
+   struct xen_dm_op_buf xbufs;
+   domid_t dom;
+   bool error;
+   struct eventfd_ctx *eventfd;
+   struct work_struct shutdown;
+   wait_queue_entry_t wait;
+   struct list_head list;
+   poll_table pt;
+};
+
+static void irqfd_deactivate(struct privcmd_kernel_irqfd *kirqfd)
+{
+   lockdep_assert_held(_lock);
+
+   list_del_init(>list);
+   queue_work(irqfd_cleanup_wq, >shutdown);
+}
+
+static void irqfd_shutdown(struct work_struct *work)
+{
+   struct privcmd_kernel_irqfd *kirqfd =
+   container_of(work, struct privcmd_kernel_irqfd, shutdown);
+   u64 cnt;
+
+   eventfd_ctx_remove_wait_queue(kirqfd->eventfd, >wait, );
+   eventfd_ctx_put(kirqfd->eventfd);
+   kfree(kirqfd);
+}
+
+static void irqfd_inject(struct privcmd_kernel_irqfd *kirqfd)
+{
+   u64 cnt;
+   long rc;
+
+   eventfd_ctx_do_read(kirqfd->eventfd, );
+
+   xen_preemptible_hcall_begin();
+   rc = HYPERVISOR_dm_op(kirqfd->dom, 1, >xbufs);
+   xen_preemptible_hcall_end();
+
+   /* Don't repeat the error message for consecutive failures */
+   if (rc && !kirqfd->error) {
+   pr_err("Failed to configure irq for guest domain: %d\n",
+  kirqfd->dom);
+   }
+
+   kirqfd->error = !!rc;
+}
+
+static int
+irqfd_wakeup(wait_queue_entry_t *wait, unsigned int mode, int sync, void *key)
+{
+   struct privcmd_kernel_irqfd *kirqfd =
+   container_of(wait, struct privcmd_kernel_irqfd, wait);
+   __poll_t flags = key_to_poll(key);
+
+   if (flags & EPOLLIN)
+   irqfd_inject(kirqfd);
+
+   if (flags & EPOLLHUP) {
+   mutex_lock(_lock);
+   irqfd_deactivate(kirqfd);
+   mutex_unlock(_lock);
+   }
+
+   return 0;
+}
+
+static void

[xen-unstable-smoke test] 182009: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   8 xen-boot fail in 182002 pass in 182009
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 18 guest-localmigrate/x10 fail pass 
in 182002

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0b1171be87698bc7d14760383c0770aeb6e41dd4
baseline version:
 xen  f91c5ea970675637721bb7f18adaa189837eb783

Last test of basis   181999  2023-07-24 17:02:22 Z0 days
Testing same since   182002  2023-07-25 01:03:53 Z0 days2 attempts


People who touched revisions under test:
  Jan Beulich 
  Nicola Vetrini 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64fail
 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
   f91c5ea970..0b1171be87  0b1171be87698bc7d14760383c0770aeb6e41dd4 -> smoke

[linux-linus test] 181994: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit1   8 xen-boot fail REGR. vs. 180278
 test-arm64-arm64-libvirt-raw 13 guest-start  fail REGR. vs. 180278
 test-arm64-arm64-xl-vhd  13 guest-start  fail REGR. vs. 180278

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-shadow 20 guest-localmigrate/x10 fail in 181989 pass in 
181994
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 
181989 pass in 181994
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 18 guest-localmigrate/x10 
fail in 181989 pass in 181994
 test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail in 181989 pass in 
181994
 test-amd64-amd64-xl-multivcpu  8 xen-boot  fail pass in 181989
 test-amd64-amd64-xl  20 guest-localmigrate/x10 fail pass in 181989
 test-amd64-coresched-amd64-xl 20 guest-localmigrate/x10fail pass in 181989
 test-amd64-amd64-freebsd11-amd64 17 guest-localmigrate fail pass in 181989
 test-amd64-amd64-xl-vhd  21 guest-start/debian.repeat  fail pass in 181989

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds22 guest-start/debian.repeat fail REGR. vs. 180278

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-examine  8 reboot   fail  like 180278
 test-armhf-armhf-xl-arndale   8 xen-boot fail  like 180278
 test-armhf-armhf-libvirt-raw  8 xen-boot fail  like 180278
 test-armhf-armhf-xl-credit2   8 xen-boot fail  like 180278
 test-armhf-armhf-xl   8 xen-boot fail  like 180278
 test-armhf-armhf-libvirt  8 xen-boot fail  like 180278
 test-armhf-armhf-xl-multivcpu  8 xen-boot fail like 180278
 test-armhf-armhf-xl-rtds  8 xen-boot fail  like 180278
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180278
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180278
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 180278
 test-armhf-armhf-xl-vhd   8 xen-boot fail  like 180278
 test-armhf-armhf-libvirt-qcow2  8 xen-bootfail like 180278
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 180278
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 180278
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass

version targeted for testing:
 linux6eaae198076080886b9e7d57f4ae06fa782f90ef
baseline version:
 linux6c538e1adbfc696ac4747fb10d63e704344f763d

Last test of basis   180278  2023-04-16 19:41:46 Z   99 days
Failing since180281  2023-04-17 06:24:36 Z   99 days  188 attempts
Testing same since   181989  2023-07-24 04:22:26 Z1 days2 attempts


3818 people touched revisions under test,
not listing them all

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

Re: [XEN PATCH v2] device_tree: address violations of MISRA C:2012 Rules 8.2 and 8.3

[Julien Grall]

Hi Federico,

On 24/07/2023 09:40, Federico Serafini wrote:

Give a name to unnamed parameters thus addressing violations of
MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
named parameters").
Keep consistency between parameter names and types used in function
declarations and the ones used in the corresponding function
definitions, thus addressing violations of MISRA C:2012 Rule 8.3
("All declarations of an object or function shall use the same names
and type qualifiers").

No functional changes.

Signed-off-by: Federico Serafini 
---
Changes in v2:
   - improved consistency in parameter renaming.
---
  xen/common/device_tree.c  | 24 
  xen/include/xen/device_tree.h | 16 
  2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0677193ab3..d52531dc9f 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -85,11 +85,11 @@ struct dt_bus
  unsigned int (*get_flags)(const __be32 *addr);
  };
  
-void dt_get_range(const __be32 **cell, const struct dt_device_node *np,

+void dt_get_range(const __be32 **cellp, const struct dt_device_node *np,
u64 *address, u64 *size)
  {
-*address = dt_next_cell(dt_n_addr_cells(np), cell);
-*size = dt_next_cell(dt_n_size_cells(np), cell);
+*address = dt_next_cell(dt_n_addr_cells(np), cellp);
+*size = dt_next_cell(dt_n_size_cells(np), cellp);
  }
  
  void dt_set_cell(__be32 **cellp, int size, u64 val)

@@ -993,9 +993,9 @@ int dt_device_get_paddr(const struct dt_device_node *dev, 
unsigned int index,
  }
  
  int dt_for_each_range(const struct dt_device_node *dev,

-  int (*cb)(const struct dt_device_node *,
+  int (*cb)(const struct dt_device_node *dev,
  uint64_t addr, uint64_t length,
-void *),
+void *data),
void *data)
  {
  const struct dt_device_node *parent = NULL;
@@ -1164,7 +1164,7 @@ unsigned int dt_number_of_irq(const struct dt_device_node 
*device)
  return (intlen / intsize);
  }
  
-unsigned int dt_number_of_address(const struct dt_device_node *dev)

+unsigned int dt_number_of_address(const struct dt_device_node *device)
We have a structure called 'device', so wouldn't this result to violate 
another MISRA rule because identifiers are re-used?


In any case, I would prefer if we keep the shorter version (i.e. 'dev') 
as this is more common within device_tree.c. We can replace the other 
'device' at a leisure pace.


Cheers,

--
Julien Grall

Re: [PATCH v2 03/47] mm: shrinker: add infrastructure for dynamically allocating shrinker

[Qi Zheng]

Hi Muchun,

On 2023/7/25 17:02, Muchun Song wrote:



On 2023/7/24 17:43, Qi Zheng wrote:

Currently, the shrinker instances can be divided into the following three
types:

a) global shrinker instance statically defined in the kernel, such as
    workingset_shadow_shrinker.

b) global shrinker instance statically defined in the kernel modules, 
such

    as mmu_shrinker in x86.

c) shrinker instance embedded in other structures.

For case a, the memory of shrinker instance is never freed. For case b,
the memory of shrinker instance will be freed after synchronize_rcu() 
when

the module is unloaded. For case c, the memory of shrinker instance will
be freed along with the structure it is embedded in.

In preparation for implementing lockless slab shrink, we need to
dynamically allocate those shrinker instances in case c, then the memory
can be dynamically freed alone by calling kfree_rcu().

So this commit adds the following new APIs for dynamically allocating
shrinker, and add a private_data field to struct shrinker to record and
get the original embedded structure.

1. shrinker_alloc()

Used to allocate shrinker instance itself and related memory, it will
return a pointer to the shrinker instance on success and NULL on failure.

2. shrinker_free_non_registered()

Used to destroy the non-registered shrinker instance.


At least I don't like this name. I know you want to tell others
this function only should be called when shrinker has not been
registed but allocated. Maybe shrinker_free() is more simple.
And and a comment to tell the users when to use it.


OK, if no one else objects, I will change it to shrinker_free() in
the next version.





3. shrinker_register()

Used to register the shrinker instance, which is same as the current
register_shrinker_prepared().

4. shrinker_unregister()

Used to unregister and free the shrinker instance.

In order to simplify shrinker-related APIs and make shrinker more
independent of other kernel mechanisms, subsequent submissions will use
the above API to convert all shrinkers (including case a and b) to
dynamically allocated, and then remove all existing APIs.

This will also have another advantage mentioned by Dave Chinner:

```
The other advantage of this is that it will break all the existing
out of tree code and third party modules using the old API and will
no longer work with a kernel using lockless slab shrinkers. They
need to break (both at the source and binary levels) to stop bad
things from happening due to using uncoverted shrinkers in the new
setup.
```

Signed-off-by: Qi Zheng 
---
  include/linux/shrinker.h |   6 +++
  mm/shrinker.c    | 113 +++
  2 files changed, 119 insertions(+)

diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index 961cb84e51f5..296f5e163861 100644
--- a/include/linux/shrinker.h
+++ b/include/linux/shrinker.h
@@ -70,6 +70,8 @@ struct shrinker {
  int seeks;    /* seeks to recreate an obj */
  unsigned flags;
+    void *private_data;
+
  /* These are for internal use */
  struct list_head list;
  #ifdef CONFIG_MEMCG
@@ -98,6 +100,10 @@ struct shrinker {
  unsigned long shrink_slab(gfp_t gfp_mask, int nid, struct mem_cgroup 
*memcg,

    int priority);
+struct shrinker *shrinker_alloc(unsigned int flags, const char *fmt, 
...);

+void shrinker_free_non_registered(struct shrinker *shrinker);
+void shrinker_register(struct shrinker *shrinker);
+void shrinker_unregister(struct shrinker *shrinker);
  extern int __printf(2, 3) prealloc_shrinker(struct shrinker *shrinker,
  const char *fmt, ...);
diff --git a/mm/shrinker.c b/mm/shrinker.c
index 0a32ef42f2a7..d820e4cc5806 100644
--- a/mm/shrinker.c
+++ b/mm/shrinker.c
@@ -548,6 +548,119 @@ unsigned long shrink_slab(gfp_t gfp_mask, int 
nid, struct mem_cgroup *memcg,

  return freed;
  }
+struct shrinker *shrinker_alloc(unsigned int flags, const char *fmt, 
...)

+{
+    struct shrinker *shrinker;
+    unsigned int size;
+    va_list __maybe_unused ap;
+    int err;
+
+    shrinker = kzalloc(sizeof(struct shrinker), GFP_KERNEL);
+    if (!shrinker)
+    return NULL;
+
+#ifdef CONFIG_SHRINKER_DEBUG
+    va_start(ap, fmt);
+    shrinker->name = kvasprintf_const(GFP_KERNEL, fmt, ap);
+    va_end(ap);
+    if (!shrinker->name)
+    goto err_name;
+#endif


So why not introduce another helper to handle this and declare it
as a void function when !CONFIG_SHRINKER_DEBUG? Something like the
following:

#ifdef CONFIG_SHRINKER_DEBUG
static int shrinker_debugfs_name_alloc(struct shrinker *shrinker, const 
char *fmt,

                                    va_list vargs)

{
     shrinker->name = kvasprintf_const(GFP_KERNEL, fmt, vargs);
     return shrinker->name ? 0 : -ENOMEM;
}
#else
static int shrinker_debugfs_name_alloc(struct shrinker *shrinker, const 
char *fmt,

                                    va_list vargs)
{
     return 0;
}
#endif


Will do in the next 

Re: [PATCH v2 09/47] f2fs: dynamically allocate the f2fs-shrinker

[Muchun Song]

> On Jul 24, 2023, at 17:43, Qi Zheng  wrote:
> 
> Use new APIs to dynamically allocate the f2fs-shrinker.
> 
> Signed-off-by: Qi Zheng 

Reviewed-by: Muchun Song 

Thanks.

Re: [PATCH v2 08/47] erofs: dynamically allocate the erofs-shrinker

[Muchun Song]

> On Jul 24, 2023, at 17:43, Qi Zheng  wrote:
> 
> Use new APIs to dynamically allocate the erofs-shrinker.
> 
> Signed-off-by: Qi Zheng 

Reviewed-by: Muchun Song 

Thanks.

Re: [PATCH v2 07/47] xenbus/backend: dynamically allocate the xen-backend shrinker

[Muchun Song]

> On Jul 24, 2023, at 17:43, Qi Zheng  wrote:
> 
> Use new APIs to dynamically allocate the xen-backend shrinker.
> 
> Signed-off-by: Qi Zheng 

Reviewed-by: Muchun Song 

Thanks.

Re: [PATCH v2 06/47] drm/ttm: dynamically allocate the drm-ttm_pool shrinker

[Muchun Song]

> On Jul 24, 2023, at 17:43, Qi Zheng  wrote:
> 
> Use new APIs to dynamically allocate the drm-ttm_pool shrinker.
> 
> Signed-off-by: Qi Zheng 

Reviewed-by: Muchun Song 

Thanks.

[XEN PATCH v2] xen/spinlock: mechanically rename parameter name 'debug'

[Nicola Vetrini]

Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"

To avoid any confusion resulting from the parameter 'debug'
hiding the homonymous function declared at
'xen/arch/x86/include/asm/processor.h:428'
the rename of parameters s/debug/lkdbg/ is performed.

Signed-off-by: Nicola Vetrini 
---
Changes in v2:
- s/dbg/lkdbg/
---
 xen/common/spinlock.c  | 38 +++---
 xen/include/xen/spinlock.h |  6 +++---
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 7f453234a9..56813d4594 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -78,7 +78,7 @@ static int __init cf_check lockdebug_init(void)
 }
 presmp_initcall(lockdebug_init);
 
-void check_lock(union lock_debug *debug, bool try)
+void check_lock(union lock_debug *lkdbg, bool try)
 {
 bool irq_safe = !local_irq_is_enabled();
 unsigned int cpu = smp_processor_id();
@@ -118,12 +118,12 @@ void check_lock(union lock_debug *debug, bool try)
 if ( try && irq_safe )
 return;
 
-if ( unlikely(debug->irq_safe != irq_safe) )
+if ( unlikely(lkdbg->irq_safe != irq_safe) )
 {
 union lock_debug seen, new = { 0 };
 
 new.irq_safe = irq_safe;
-seen.val = cmpxchg(>val, LOCK_DEBUG_INITVAL, new.val);
+seen.val = cmpxchg(>val, LOCK_DEBUG_INITVAL, new.val);
 
 if ( !seen.unseen && seen.irq_safe == !irq_safe )
 {
@@ -137,14 +137,14 @@ void check_lock(union lock_debug *debug, bool try)
 return;
 
 for ( i = 0; i < nr_taken; i++ )
-if ( taken[i] == debug )
+if ( taken[i] == lkdbg )
 {
-printk("CHECKLOCK FAILURE: lock at %p taken recursively\n", debug);
+printk("CHECKLOCK FAILURE: lock at %p taken recursively\n", lkdbg);
 BUG();
 }
 }
 
-static void check_barrier(union lock_debug *debug)
+static void check_barrier(union lock_debug *dbg)
 {
 if ( unlikely(atomic_read(_debug) <= 0) )
 return;
@@ -160,10 +160,10 @@ static void check_barrier(union lock_debug *debug)
  * However, if we spin on an IRQ-unsafe lock with IRQs disabled then that
  * is clearly wrong, for the same reason outlined in check_lock() above.
  */
-BUG_ON(!local_irq_is_enabled() && !debug->irq_safe);
+BUG_ON(!local_irq_is_enabled() && !dbg->irq_safe);
 }
 
-void lock_enter(const union lock_debug *debug)
+void lock_enter(const union lock_debug *lkdbg)
 {
 unsigned int cpu = smp_processor_id();
 const union lock_debug **taken = per_cpu(locks_taken, cpu);
@@ -176,7 +176,7 @@ void lock_enter(const union lock_debug *debug)
 local_irq_save(flags);
 
 if ( *nr_taken < lock_depth_size )
-taken[(*nr_taken)++] = debug;
+taken[(*nr_taken)++] = lkdbg;
 else if ( !max_depth_reached )
 {
 max_depth_reached = true;
@@ -187,7 +187,7 @@ void lock_enter(const union lock_debug *debug)
 local_irq_restore(flags);
 }
 
-void lock_exit(const union lock_debug *debug)
+void lock_exit(const union lock_debug *lkdbg)
 {
 unsigned int cpu = smp_processor_id();
 const union lock_debug **taken = per_cpu(locks_taken, cpu);
@@ -202,7 +202,7 @@ void lock_exit(const union lock_debug *debug)
 
 for ( i = *nr_taken; i > 0; i-- )
 {
-if ( taken[i - 1] == debug )
+if ( taken[i - 1] == lkdbg )
 {
 memmove(taken + i - 1, taken + i,
 (*nr_taken - i) * sizeof(*taken));
@@ -217,28 +217,28 @@ void lock_exit(const union lock_debug *debug)
 
 if ( !max_depth_reached )
 {
-printk("CHECKLOCK released lock at %p not recorded!\n", debug);
+printk("CHECKLOCK released lock at %p not recorded!\n", lkdbg);
 WARN();
 }
 
 local_irq_restore(flags);
 }
 
-static void got_lock(union lock_debug *debug)
+static void got_lock(union lock_debug *dbg)
 {
-debug->cpu = smp_processor_id();
+dbg->cpu = smp_processor_id();
 
-lock_enter(debug);
+lock_enter(dbg);
 }
 
-static void rel_lock(union lock_debug *debug)
+static void rel_lock(union lock_debug *dbg)
 {
 if ( atomic_read(_debug) > 0 )
-BUG_ON(debug->cpu != smp_processor_id());
+BUG_ON(dbg->cpu != smp_processor_id());
 
-lock_exit(debug);
+lock_exit(dbg);
 
-debug->cpu = SPINLOCK_NO_CPU;
+dbg->cpu = SPINLOCK_NO_CPU;
 }
 
 void spin_debug_enable(void)
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index 0a02a527dc..464af705eb 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -22,9 +22,9 @@ union lock_debug {
 };
 };
 #define _LOCK_DEBUG { LOCK_DEBUG_INITVAL }
-void check_lock(union lock_debug *debug, bool try);
-void lock_enter(const union lock_debug *debug);
-void lock_exit(const union lock_debug *debug);
+void check_lock(union lock_debug *lkdbg, bool try);
+void lock_enter(const union 

Re: [PATCH v2 04/47] kvm: mmu: dynamically allocate the x86-mmu shrinker

[Muchun Song]

> On Jul 24, 2023, at 17:43, Qi Zheng  wrote:
> 
> Use new APIs to dynamically allocate the x86-mmu shrinker.
> 
> Signed-off-by: Qi Zheng 

Reviewed-by: Muchun Song 

Thanks.

[XEN PATCH v2] xen/sched: mechanical renaming to address MISRA C:2012 Rule 5.3

[Nicola Vetrini]

Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"

The renaming s/sched_id/scheduler_id/ of the function defined in
'xen/common/sched/core.c' prevents any hiding of that function
by the instances of homonymous function parameters that
are defined in inner scopes.

Similarly, the renames
- s/ops/operations/ for the static variable in 'xen/common/sched/core.c'
- s/do_softirq/needs_softirq/
are introduced for variables, to avoid any conflict with homonymous
parameters or function identifiers.

Moreover, the variable 'loop' defined at 'xen/common/sched/credit2.c:3887'
has been dropped, in favour of the homonymous variable declared in the
outer scope. This in turn requires a modification of the printk call that
involves it.

Signed-off-by: Nicola Vetrini 
---
Changes in v2:
- s/softirq/needs_softirq/
- Dropped local variable 'it'
- Renamed the 'ops' static variable instead of function parameters
in the idle scheduler for coherence.
---
 xen/common/sched/core.c| 35 ++-
 xen/common/sched/credit2.c |  9 +
 xen/common/sysctl.c|  2 +-
 xen/include/xen/sched.h|  2 +-
 4 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 022f548652..ed977ddfd5 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -91,7 +91,7 @@ extern const struct scheduler *__start_schedulers_array[], 
*__end_schedulers_arr
 #define NUM_SCHEDULERS (__end_schedulers_array - __start_schedulers_array)
 #define schedulers __start_schedulers_array
 
-static struct scheduler __read_mostly ops;
+static struct scheduler __read_mostly operations;
 
 static bool scheduler_active;
 
@@ -99,14 +99,15 @@ static void sched_set_affinity(
 struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft);
 
 static struct sched_resource *cf_check
-sched_idle_res_pick(const struct scheduler *ops, const struct sched_unit *unit)
+sched_idle_res_pick(
+const struct scheduler *ops, const struct sched_unit *unit)
 {
 return unit->res;
 }
 
 static void *cf_check
-sched_idle_alloc_udata(const struct scheduler *ops, struct sched_unit *unit,
-   void *dd)
+sched_idle_alloc_udata(
+const struct scheduler *ops, struct sched_unit *unit, void *dd)
 {
 /* Any non-NULL pointer is fine here. */
 return ZERO_BLOCK_PTR;
@@ -171,7 +172,7 @@ static inline struct scheduler *dom_scheduler(const struct 
domain *d)
  * is the default scheduler that has been, choosen at boot.
  */
 ASSERT(is_idle_domain(d));
-return 
+return 
 }
 
 static inline struct scheduler *unit_scheduler(const struct sched_unit *unit)
@@ -2040,10 +2041,10 @@ long do_set_timer_op(s_time_t timeout)
 return 0;
 }
 
-/* sched_id - fetch ID of current scheduler */
-int sched_id(void)
+/* scheduler_id - fetch ID of current scheduler */
+int scheduler_id(void)
 {
-return ops.sched_id;
+return operations.sched_id;
 }
 
 /* Adjust scheduling parameter for a given domain. */
@@ -2579,7 +2580,7 @@ static void cf_check sched_slave(void)
 struct sched_unit*prev = vprev->sched_unit, *next;
 s_time_t  now;
 spinlock_t   *lock;
-bool  do_softirq = false;
+bool  needs_softirq = false;
 unsigned int  cpu = smp_processor_id();
 
 ASSERT_NOT_IN_ATOMIC();
@@ -2604,7 +2605,7 @@ static void cf_check sched_slave(void)
 return;
 }
 
-do_softirq = true;
+needs_softirq = true;
 }
 
 if ( !prev->rendezvous_in_cnt )
@@ -2614,7 +2615,7 @@ static void cf_check sched_slave(void)
 rcu_read_unlock(_res_rculock);
 
 /* Check for failed forced context switch. */
-if ( do_softirq )
+if ( needs_softirq )
 raise_softirq(SCHEDULE_SOFTIRQ);
 
 return;
@@ -3016,14 +3017,14 @@ void __init scheduler_init(void)
 BUG_ON(!scheduler);
 printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
 }
-ops = *scheduler;
+operations = *scheduler;
 
 if ( cpu_schedule_up(0) )
 BUG();
 register_cpu_notifier(_schedule_nfb);
 
-printk("Using scheduler: %s (%s)\n", ops.name, ops.opt_name);
-if ( sched_init() )
+printk("Using scheduler: %s (%s)\n", operations.name, operations.opt_name);
+if ( sched_init() )
 panic("scheduler returned error on init\n");
 
 if ( sched_ratelimit_us &&
@@ -3363,7 +3364,7 @@ int schedule_cpu_rm(unsigned int cpu, struct cpu_rm_data 
*data)
 
 struct scheduler *scheduler_get_default(void)
 {
-return 
+return 
 }
 
 struct scheduler *scheduler_alloc(unsigned int sched_id)
@@ -3392,7 +3393,7 @@ struct scheduler *scheduler_alloc(unsigned int sched_id)
 
 void scheduler_free(struct scheduler *sched)
 {
-BUG_ON(sched == );
+BUG_ON(sched == );
 sched_deinit(sched);
 

Re: [PATCH v2 03/47] mm: shrinker: add infrastructure for dynamically allocating shrinker

[Muchun Song]

On 2023/7/24 17:43, Qi Zheng wrote:

Currently, the shrinker instances can be divided into the following three
types:

a) global shrinker instance statically defined in the kernel, such as
workingset_shadow_shrinker.

b) global shrinker instance statically defined in the kernel modules, such
as mmu_shrinker in x86.

c) shrinker instance embedded in other structures.

For case a, the memory of shrinker instance is never freed. For case b,
the memory of shrinker instance will be freed after synchronize_rcu() when
the module is unloaded. For case c, the memory of shrinker instance will
be freed along with the structure it is embedded in.

In preparation for implementing lockless slab shrink, we need to
dynamically allocate those shrinker instances in case c, then the memory
can be dynamically freed alone by calling kfree_rcu().

So this commit adds the following new APIs for dynamically allocating
shrinker, and add a private_data field to struct shrinker to record and
get the original embedded structure.

1. shrinker_alloc()

Used to allocate shrinker instance itself and related memory, it will
return a pointer to the shrinker instance on success and NULL on failure.

2. shrinker_free_non_registered()

Used to destroy the non-registered shrinker instance.


At least I don't like this name. I know you want to tell others
this function only should be called when shrinker has not been
registed but allocated. Maybe shrinker_free() is more simple.
And and a comment to tell the users when to use it.



3. shrinker_register()

Used to register the shrinker instance, which is same as the current
register_shrinker_prepared().

4. shrinker_unregister()

Used to unregister and free the shrinker instance.

In order to simplify shrinker-related APIs and make shrinker more
independent of other kernel mechanisms, subsequent submissions will use
the above API to convert all shrinkers (including case a and b) to
dynamically allocated, and then remove all existing APIs.

This will also have another advantage mentioned by Dave Chinner:

```
The other advantage of this is that it will break all the existing
out of tree code and third party modules using the old API and will
no longer work with a kernel using lockless slab shrinkers. They
need to break (both at the source and binary levels) to stop bad
things from happening due to using uncoverted shrinkers in the new
setup.
```

Signed-off-by: Qi Zheng 
---
  include/linux/shrinker.h |   6 +++
  mm/shrinker.c| 113 +++
  2 files changed, 119 insertions(+)

diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index 961cb84e51f5..296f5e163861 100644
--- a/include/linux/shrinker.h
+++ b/include/linux/shrinker.h
@@ -70,6 +70,8 @@ struct shrinker {
int seeks;  /* seeks to recreate an obj */
unsigned flags;
  
+	void *private_data;

+
/* These are for internal use */
struct list_head list;
  #ifdef CONFIG_MEMCG
@@ -98,6 +100,10 @@ struct shrinker {
  
  unsigned long shrink_slab(gfp_t gfp_mask, int nid, struct mem_cgroup *memcg,

  int priority);
+struct shrinker *shrinker_alloc(unsigned int flags, const char *fmt, ...);
+void shrinker_free_non_registered(struct shrinker *shrinker);
+void shrinker_register(struct shrinker *shrinker);
+void shrinker_unregister(struct shrinker *shrinker);
  
  extern int __printf(2, 3) prealloc_shrinker(struct shrinker *shrinker,

const char *fmt, ...);
diff --git a/mm/shrinker.c b/mm/shrinker.c
index 0a32ef42f2a7..d820e4cc5806 100644
--- a/mm/shrinker.c
+++ b/mm/shrinker.c
@@ -548,6 +548,119 @@ unsigned long shrink_slab(gfp_t gfp_mask, int nid, struct 
mem_cgroup *memcg,
return freed;
  }
  
+struct shrinker *shrinker_alloc(unsigned int flags, const char *fmt, ...)

+{
+   struct shrinker *shrinker;
+   unsigned int size;
+   va_list __maybe_unused ap;
+   int err;
+
+   shrinker = kzalloc(sizeof(struct shrinker), GFP_KERNEL);
+   if (!shrinker)
+   return NULL;
+
+#ifdef CONFIG_SHRINKER_DEBUG
+   va_start(ap, fmt);
+   shrinker->name = kvasprintf_const(GFP_KERNEL, fmt, ap);
+   va_end(ap);
+   if (!shrinker->name)
+   goto err_name;
+#endif


So why not introduce another helper to handle this and declare it
as a void function when !CONFIG_SHRINKER_DEBUG? Something like the
following:

#ifdef CONFIG_SHRINKER_DEBUG
static int shrinker_debugfs_name_alloc(struct shrinker *shrinker, const 
char *fmt,

                                   va_list vargs)

{
    shrinker->name = kvasprintf_const(GFP_KERNEL, fmt, vargs);
    return shrinker->name ? 0 : -ENOMEM;
}
#else
static int shrinker_debugfs_name_alloc(struct shrinker *shrinker, const 
char *fmt,

                                   va_list vargs)
{
    return 0;
}
#endif


+   shrinker->flags = flags;
+
+   if (flags & SHRINKER_MEMCG_AWARE) {
+ 

Re: [PATCH v3 3/6] libxl: introduce MSR data in libxl_cpuid_policy

[Roger Pau Monné]

On Mon, Jul 24, 2023 at 06:26:42PM +0100, Anthony PERARD wrote:
> On Thu, Jul 20, 2023 at 10:25:37AM +0200, Roger Pau Monne wrote:
> > ---
> > It would be nice to rename the json output field to 'cpu_policy'
> > instead of 'cpuid', so that it looks like:
> > 
> > "cpu_policy": {
> > "cpuid": [
> > {
> > "leaf": 7,
> > "subleaf": 0,
> > "edx": "xx1x"
> > },
> > {
> > "leaf": 1,
> > "ebx": "0001"
> > }
> > }
> > }
> > ],
> > "msr": [
> > {
> > "index": 266,
> > "policy": 
> > "xx1xx1x1"
> > }
> > ]
> > },
> > 
> > Sadly I have no idea how to do that, and can be done in a followup
> > change anyway.
> 
> I don't think that would be possible. I think that would mean renaming
> the field in "struct libxl_domain_build_info", and changing a fields
> name seems complicated.

I did wonder whether it would be possible to change the json field
name without changing the libxl_domain_build_info field name, but that
would need a lot of special casing AFAICT.

> > diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
> > index 3c8b2a72c0b8..68b797886642 100644
> > --- a/tools/libs/light/libxl_cpuid.c
> > +++ b/tools/libs/light/libxl_cpuid.c
> > @@ -592,17 +641,24 @@ int libxl__cpuid_policy_list_parse_json(libxl__gc *gc,
> >  {
> >  int i, size;
> >  struct xc_xend_cpuid *l;
> > +struct xc_msr *msr;
> > +const libxl__json_object *co;
> >  flexarray_t *array;
> >  
> > -if (!libxl__json_object_is_array(o))
> > +if (!libxl__json_object_is_map(o))
> >  return ERROR_FAIL;
> 
> We still need to be able to migrate a VM from a previous release of Xen,
> and we are going to have an array instead of a map. Could you try to
> handle both the old and new format of "cpuid"? If we don't then the
> scenario "migrate then reboot" is going to fail to use the expected cpu
> policy.
> 
> > diff --git a/tools/libs/light/libxl_types.idl 
> > b/tools/libs/light/libxl_types.idl
> > index 9e48bb772646..887824fdd828 100644
> > --- a/tools/libs/light/libxl_types.idl
> > +++ b/tools/libs/light/libxl_types.idl
> > @@ -19,7 +19,7 @@ libxl_mac = Builtin("mac", json_parse_type="JSON_STRING", 
> > passby=PASS_BY_REFEREN
> >  libxl_bitmap = Builtin("bitmap", json_parse_type="JSON_ARRAY", 
> > dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE,
> > check_default_fn="libxl_bitmap_is_empty", 
> > copy_fn="libxl_bitmap_copy_alloc")
> >  libxl_cpuid_policy_list = Builtin("cpuid_policy_list", 
> > dispose_fn="libxl_cpuid_dispose", passby=PASS_BY_REFERENCE,
> > -  json_parse_type="JSON_ARRAY", 
> > check_default_fn="libxl__cpuid_policy_is_empty",
> > +  json_parse_type="JSON_MAP", 
> > check_default_fn="libxl__cpuid_policy_is_empty",
> 
> Maybe we should have json_parse_type as either "JSON_ARRAY | JSON_MAP"
> or just "JSON_ANY" since nothing beside libxl is supposed to do
> something with it, and when migrating from a previous version, we are
> going to have an array.

Yeah, we need to use JSON_ANY and then guess the version by whether
the object is an array or a map.

That should be easy to arrange, let me prepare v4.

Thanks, Roger.

Re: [PATCH v3] ns16550: add support for polling mode when device tree is used

[Oleksii]

On Tue, 2023-07-25 at 10:18 +0200, Jan Beulich wrote:
> On 25.07.2023 10:15, Oleksii wrote:
> > On Mon, 2023-07-24 at 16:43 +0200, Jan Beulich wrote:
> > > On 24.07.2023 16:27, Oleksii Kurochko wrote:
> > > > @@ -1330,9 +1341,12 @@ pci_uart_config(struct ns16550 *uart,
> > > > bool_t
> > > > skip_amt, unsigned int idx)
> > > >   * as special only for X86.
> > > >   */
> > > >  if ( uart->irq == 0xff )
> > > > +    {
> > > >  uart->irq = 0;
> > > > +    uart->intr_works = polling;
> > > > +    }
> > > >  #endif
> > > > -    if ( !uart->irq )
> > > > +    if ( !uart->irq || (uart->intr_works ==
> > > > polling) )
> > > >  printk(XENLOG_INFO
> > > >     "ns16550: %pp: no legacy IRQ, using
> > > > poll mode\n",
> > > >     _SBDF(0, b, d, f));
> > > 
> > > Message and code (after your addition) continue to be out of
> > > sync.
> > > As said before, any condition that leads to polling mode wants to
> > > find itself expressed by uart->intr_works set to "polling".
> > Well. It looks like it would be better to set 'uart->intr_works =
> > polling' inside if ( !uart->irq ):
> >   if ( !uart->irq || (uart->intr_works == polling) )
> >   {
> >   uart->intr_works = polling;
> >   printk(XENLOG_INFO
> >  "ns16550: %pp: using poll mode\n",
> >  _SBDF(0, b, d, f));
> >   }
> > Then "uart->intr_works = polling;" can be removed from "if ( uart-
> > >irq
> > == 0xff )" as in that case 'uart->irq = 0' means polling mode for
> > X86.
> 
> I'm not fully convinced. Care needs to be taken that both the x86
> case
> and the general case continue to function as they did (unless proven
> to
> be buggy).
But it continues to work as it worked before ( when uart->intr_works !=
polling ) otherwise, if uart->intr_works = polling, then polling mode
is forced.

The only thing that I would probably add it is to force polling mode in
case of X86 when polling mode is forced by command line:
if ( ( uart->irq == 0xff ) || (uart->intr_works == polling) )
{
uart->irq = 0;
uart->intr_works = polling;
}
But this check looks a little bit unnecessary because if the polling
mode is forced or not will be checked later in the next if condition.

~ Oleksii

Re: [PATCH V3 2/2] xen: privcmd: Add support for irqfd

[Juergen Gross]

On 25.07.23 08:47, Viresh Kumar wrote:

Xen provides support for injecting interrupts to the guests via the
HYPERVISOR_dm_op() hypercall. The same is used by the Virtio based
device backend implementations, in an inefficient manner currently.

Generally, the Virtio backends are implemented to work with the Eventfd
based mechanism. In order to make such backends work with Xen, another
software layer needs to poll the Eventfds and raise an interrupt to the
guest using the Xen based mechanism. This results in an extra context
switch.

This is not a new problem in Linux though. It is present with other
hypervisors like KVM, etc. as well. The generic solution implemented in
the kernel for them is to provide an IOCTL call to pass the interrupt
details and eventfd, which lets the kernel take care of polling the
eventfd and raising of the interrupt, instead of handling this in user
space (which involves an extra context switch).

This patch adds support to inject a specific interrupt to guest using
the eventfd mechanism, by preventing the extra context switch.

Inspired by existing implementations for KVM, etc..

Signed-off-by: Viresh Kumar 
---
V2.1->V3
- No changes

V2->V2.1
- Select EVENTFD from Kconfig

V1->V2:
- Improve error handling.
- Remove the unnecessary usage of list_for_each_entry_safe().
- Restrict the use of XEN_DMOP_set_irq_level to only ARM64.

  drivers/xen/Kconfig|   1 +
  drivers/xen/privcmd.c  | 276 -
  include/uapi/xen/privcmd.h |  14 ++
  3 files changed, 289 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d5d7c402b651..7967393c55a4 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -261,6 +261,7 @@ config XEN_SCSI_BACKEND
  config XEN_PRIVCMD
tristate "Xen hypercall passthrough driver"
depends on XEN
+   select EVENTFD


I don't like this. Can we maybe add another bool config item depending on
XEN_PRIVCMD, EVENTFD and XEN_VIRTIO, which can then be used to guard the
code additions to privcmd.c?

This would avoid adding additional code for everyone.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v3] ns16550: add support for polling mode when device tree is used

[Jan Beulich]

On 25.07.2023 10:15, Oleksii wrote:
> On Mon, 2023-07-24 at 16:43 +0200, Jan Beulich wrote:
>> On 24.07.2023 16:27, Oleksii Kurochko wrote:
>>> @@ -1330,9 +1341,12 @@ pci_uart_config(struct ns16550 *uart, bool_t
>>> skip_amt, unsigned int idx)
>>>   * as special only for X86.
>>>   */
>>>  if ( uart->irq == 0xff )
>>> +    {
>>>  uart->irq = 0;
>>> +    uart->intr_works = polling;
>>> +    }
>>>  #endif
>>> -    if ( !uart->irq )
>>> +    if ( !uart->irq || (uart->intr_works == polling) )
>>>  printk(XENLOG_INFO
>>>     "ns16550: %pp: no legacy IRQ, using
>>> poll mode\n",
>>>     _SBDF(0, b, d, f));
>>
>> Message and code (after your addition) continue to be out of sync.
>> As said before, any condition that leads to polling mode wants to
>> find itself expressed by uart->intr_works set to "polling".
> Well. It looks like it would be better to set 'uart->intr_works =
> polling' inside if ( !uart->irq ):
>   if ( !uart->irq || (uart->intr_works == polling) )
>   {
>   uart->intr_works = polling;
>   printk(XENLOG_INFO
>  "ns16550: %pp: using poll mode\n",
>  _SBDF(0, b, d, f));
>   }
> Then "uart->intr_works = polling;" can be removed from "if ( uart->irq
> == 0xff )" as in that case 'uart->irq = 0' means polling mode for X86.

I'm not fully convinced. Care needs to be taken that both the x86 case
and the general case continue to function as they did (unless proven to
be buggy).

Jan

Re: [PATCH v4 2/2] xen/riscv: introduce identity mapping

[Jan Beulich]

On 24.07.2023 18:00, Oleksii wrote:
> On Mon, 2023-07-24 at 16:11 +0200, Jan Beulich wrote:
>> On 24.07.2023 11:42, Oleksii Kurochko wrote:
>>> +void __init remove_identity_mapping(void)
>>> +{
>>> +    static pte_t *pgtbl = stage1_pgtbl_root;
>>> +    static unsigned long load_start = XEN_VIRT_START;
>>> +    static unsigned int pt_level = CONFIG_PAGING_LEVELS - 1;
>>
>> These all want to be __initdata, but personally I find this way of
>> recursing a little odd. Let's see what the maintainers say.
> I'm not completely happy either. Initially I thought that it would be
> better to pass all this stuff as function's arguments.
> 
> But then it is needed to provide an access to stage1_pgtbl_root (
> get_root_pt() function ? ). So remove_identity_mapping() will be called
> as remove_identity_mapping(get_root_pt(), _start, CONFIG_PAGING_LELVELS
> -1 ) or remove_identity_mapping(NULL, _start, CONFIG_PAGING_LELVELS -1
> ) and then check if first argument is NULL then initialize it with
> stage1_pgtbl_root.
> Also I am not sure that an 'user' should provide all this information
> to such function.
> 
> Could you recommend something better?

Well, to avoid the mess you are describing I would consider making
remove_identity_mapping() itself a thin wrapper around the actual
function which then invokes itself recursively. That'll keep the
top-level call site tidy, and all the technical details confined to
the (then) two functions.

>>> +    unsigned long load_end = LINK_TO_LOAD(_end);
>>> +    unsigned long xen_size;
>>> +    unsigned long pt_level_size = XEN_PT_LEVEL_SIZE(pt_level);
>>> +    unsigned long pte_nums;
>>> +
>>> +    unsigned long virt_indx = pt_index(pt_level, XEN_VIRT_START);
>>> +    unsigned long indx;
>>> +
>>> +    if ( load_start == XEN_VIRT_START )
>>> +    load_start = LINK_TO_LOAD(_start);
>>> +
>>> +    xen_size = load_end - load_start;
>>
>> When you come here recursively, don't you need to limit this
>> instance of the function to a single page table's worth of address
>> space (at the given level), using load_end only if that's yet
>> lower?
> Do you mean a case when load_start > load_end? If yes then I missed
> that.

No, my concern is with the page table presently acted upon covering
only a limited part of the address space. That "limited" is the full
address space only for the top level table. You won't observe this
though unless the Xen image crosses a 2Mb boundary. But if it does
(and it may help if you arranged for big enough an image just for
the purpose of debugging, simply by inserting enough dead code or
data), and if all mappings are 4k ones, you'd run past the first L1
table's worth of mappings on the first invocation of this function
with a L1 table. (Of course hitting the condition may further
require Xen and 1:1 mappings to be sufficiently close to one another,
so that the zapping doesn't already occur at higher levels. But then
the same situation could arise at higher levels when the image
crosses a 1Gb or 512Gb boundary.)

>>> +    pte_nums = ROUNDUP(xen_size, pt_level_size) / pt_level_size;
>>> +
>>> +    while ( pte_nums-- )
>>> +    {
>>> +    indx = pt_index(pt_level, load_start);
>>>  
>>> -    switch_stack_and_jump((unsigned long)cpu0_boot_stack +
>>> STACK_SIZE,
>>> -  cont_after_mmu_is_enabled);
>>> +    if ( virt_indx != indx )
>>> +    {
>>> +    pgtbl[indx].pte = 0;
>>> +    load_start += XEN_PT_LEVEL_SIZE(pt_level);
>>> +    }
>>> +    else
>>> +    {
>>> +    pgtbl =  (pte_t
>>> *)LOAD_TO_LINK(pte_to_paddr(pgtbl[indx]));
>>
>> Nit: Stray double blank.
> Thanks.
>>
>>> +    pt_level--;
>>> +    remove_identity_mapping();
>>
>> Don't you need to restore pgtbl and pt_level here before the loop
>> can continue? And because of depending on load_start, which would
>> have moved, xen_size also needs suitably reducing, I think. Plus
>> pte_nums as well, since that in turn was calculated from xen_size.
> I forgot to restore pgtbl and pt_level because initially I used a
> function arguments to pass that information so it wasn't needed to
> restore them.
> 
> Regarding xen_size and pte_nums it looks like it is needed to init only
> once on each page table level.
> For example we have the following situation:
>   --
>non-identity-mapping
>identity-mapping
>   -- C
>identity-mapping
>   -- B
>identity-mapping
>   -- A
> So we calculated that we need to remove 3 ptes, for first two ptes ( as
> only identity mapping is there) are removed without any issue, then
> move load_addr to C and run recursion
> for the pte 'C' to go to next page table level.
> At new level we are calculating how many ptes are needed to be removed
> and remove only necessary amount of ptes.
> When we will back to prev page table level pte_num will be 1 then we
> will go to the head of the cycle, decrease pte_num to 

Re: [PATCH v3] ns16550: add support for polling mode when device tree is used

[Oleksii]

On Mon, 2023-07-24 at 16:43 +0200, Jan Beulich wrote:
> On 24.07.2023 16:27, Oleksii Kurochko wrote:
> > --- a/xen/drivers/char/console.c
> > +++ b/xen/drivers/char/console.c
> > @@ -993,6 +993,8 @@ void __init console_init_preirq(void)
> >  #endif
> >  else if ( !strncmp(p, "none", 4) )
> >  continue;
> > +    else if ( !strncmp(p, "polling", 7 )
> > +    continue;
> >  else if ( (sh = serial_parse_handle(p)) >= 0 )
> >  {
> >  sercon_handle = sh;
> 
> Looks like you mean the new option to go under "console=". Besides
> this being guesswork because of you not updating the command line
> doc, this also is wrong, as the property then applies to all
> consoles. What you mean is a control for a specific instance of a
> 16550 console, which can only possibly go under "com=". I would
> suggest to simply extend [|msi] there to [|msi|poll].
Thanks. It would be definitely better to go under "com"
> 
> > @@ -595,7 +601,9 @@ static void __init cf_check
> > ns16550_endboot(struct serial_port *port)
> >  static int __init cf_check ns16550_irq(struct serial_port *port)
> >  {
> >  struct ns16550 *uart = port->uart;
> > -    return ((uart->irq > 0) ? uart->irq : -1);
> > +
> > +    return ( uart->intr_works != polling ) ?
> > +    uart->irq : -1;
> >  }
> 
> Please don't corrupt previously correct style. You can keep things
> almost like they were (albeit there's no strict need for any of the
> parentheses):
> 
>     return ((uart->intr_works != polling) ? uart->irq : -1);
Thanks.
> 
> > @@ -1330,9 +1341,12 @@ pci_uart_config(struct ns16550 *uart, bool_t
> > skip_amt, unsigned int idx)
> >   * as special only for X86.
> >   */
> >  if ( uart->irq == 0xff )
> > +    {
> >  uart->irq = 0;
> > +    uart->intr_works = polling;
> > +    }
> >  #endif
> > -    if ( !uart->irq )
> > +    if ( !uart->irq || (uart->intr_works == polling) )
> >  printk(XENLOG_INFO
> >     "ns16550: %pp: no legacy IRQ, using
> > poll mode\n",
> >     _SBDF(0, b, d, f));
> 
> Message and code (after your addition) continue to be out of sync.
> As said before, any condition that leads to polling mode wants to
> find itself expressed by uart->intr_works set to "polling".
Well. It looks like it would be better to set 'uart->intr_works =
polling' inside if ( !uart->irq ):
  if ( !uart->irq || (uart->intr_works == polling) )
  {
  uart->intr_works = polling;
  printk(XENLOG_INFO
 "ns16550: %pp: using poll mode\n",
 _SBDF(0, b, d, f));
  }
Then "uart->intr_works = polling;" can be removed from "if ( uart->irq
== 0xff )" as in that case 'uart->irq = 0' means polling mode for X86.
  
> 
> > @@ -1552,6 +1566,7 @@ static bool __init parse_positional(struct
> > ns16550 *uart, char **str)
> >  conf += 3;
> >  uart->msi = true;
> >  uart->irq = 0;
> > +    uart->intr_works = polling;
> 
> How that? "msi" is specifically asking for interrupt driven mode,
> just that the IRQ number isn't known yet. (Seeing this I notice that
> parse_namevalue_pairs() offers no way of selecting MSI mode. But
> that's not something you need to sort out.)
I was confused by the code from ns16550_init_postirq():
if ( rc )
{
uart->irq = 0;
if ( msi_desc )
msi_free_irq(msi_desc);
else
destroy_irq(msi.irq);
}
where "uart->irq = 0;" means that polling mode should be used because
of the following code in the same function:
if ( uart->irq > 0 )
{
uart->irqaction.handler = ns16550_interrupt;
uart->irqaction.name= "ns16550";
uart->irqaction.dev_id  = port;
if ( (rc = setup_irq(uart->irq, 0, >irqaction)) != 0 )
printk("ERROR: Failed to allocate ns16550 IRQ %d\n", uart-
>irq);
}

~ Oleksii

Re: [PATCH V3 1/2] xen: Update dm_op.h from Xen public header

[Juergen Gross]

On 25.07.23 09:49, Jan Beulich wrote:

On 25.07.2023 09:42, Viresh Kumar wrote:

On 25-07-23, 09:18, Jan Beulich wrote:

I question that use, btw, but it is not up to me to decide whether to
accept such a layering violation in Linux. dm-op is, as its name says,
for device models to use. Your intended use doesn't fall in that
category, aiui. Imo the present contents of dm_op.h in Linux is indeed
all a kernel is supposed to know about, unless it was to gain in-kernel
device models.


Is there any other way by which an interrupt can be raised for the
guest VM ? I was only aware of this method and so implemented it like
this.

I am open to suggestions on this.


Well. I don't know your requirements. Generally I would suggest using
event channels, not interrupts, when talking about injecting events
into guests. If it strictly needs to be an interrupt, then I guess a
non-dm-op means would need introducing if none already exists.


I think the best way would be to let the user mode device model (i.e. the
backend) construct the dm-op parameters like qemu is doing it and pass it
via the ioctl to the privcmd driver as part of struct privcmd_irqfd. Then
it would be opaque to the kernel like every other dm-op.


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH V3 1/2] xen: Update dm_op.h from Xen public header

[Jan Beulich]

On 25.07.2023 09:42, Viresh Kumar wrote:
> On 25-07-23, 09:18, Jan Beulich wrote:
>> I question that use, btw, but it is not up to me to decide whether to
>> accept such a layering violation in Linux. dm-op is, as its name says,
>> for device models to use. Your intended use doesn't fall in that
>> category, aiui. Imo the present contents of dm_op.h in Linux is indeed
>> all a kernel is supposed to know about, unless it was to gain in-kernel
>> device models.
> 
> Is there any other way by which an interrupt can be raised for the
> guest VM ? I was only aware of this method and so implemented it like
> this.
> 
> I am open to suggestions on this.

Well. I don't know your requirements. Generally I would suggest using
event channels, not interrupts, when talking about injecting events
into guests. If it strictly needs to be an interrupt, then I guess a
non-dm-op means would need introducing if none already exists.

Jan

Re: [PATCH V3 1/2] xen: Update dm_op.h from Xen public header

[Viresh Kumar]

On 25-07-23, 09:18, Jan Beulich wrote:
> I question that use, btw, but it is not up to me to decide whether to
> accept such a layering violation in Linux. dm-op is, as its name says,
> for device models to use. Your intended use doesn't fall in that
> category, aiui. Imo the present contents of dm_op.h in Linux is indeed
> all a kernel is supposed to know about, unless it was to gain in-kernel
> device models.

Is there any other way by which an interrupt can be raised for the
guest VM ? I was only aware of this method and so implemented it like
this.

I am open to suggestions on this.

-- 
viresh

Re: [XEN PATCH] xen/sched: mechanical renaming to address MISRA C:2012 Rule 5.3

[Nicola Vetrini]

On 24/07/23 10:26, Jan Beulich wrote:

On 21.07.2023 17:31, Nicola Vetrini wrote:

Rule 5.3 has the following headline:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"

The renaming s/sched_id/scheduler_id of the function defined in
'xen/common/sched/core.c' prevents any hiding of that function
by the many instances of omonymous function parameters.

Similarly, the renames
- s/ops/operations
- s/do_softirq/exec_softirq
- s/loop/it
are introduced for parameter names, to avoid any conflict
with the homonymous variable or function defined in an enclosing
scope.

Signed-off-by: Nicola Vetrini 
---
  xen/common/sched/core.c| 18 +-
  xen/common/sched/credit2.c |  4 ++--
  xen/common/sysctl.c|  2 +-
  xen/include/xen/sched.h|  2 +-
  4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 022f548652..e74b1208bd 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -99,13 +99,13 @@ static void sched_set_affinity(
  struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft);
  
  static struct sched_resource *cf_check

-sched_idle_res_pick(const struct scheduler *ops, const struct sched_unit *unit)
+sched_idle_res_pick(const struct scheduler *operations, const struct 
sched_unit *unit)
  {
  return unit->res;
  }
  
  static void *cf_check

-sched_idle_alloc_udata(const struct scheduler *ops, struct sched_unit *unit,
+sched_idle_alloc_udata(const struct scheduler *operations, struct sched_unit 
*unit,
 void *dd)
  {
  /* Any non-NULL pointer is fine here. */
@@ -113,12 +113,12 @@ sched_idle_alloc_udata(const struct scheduler *ops, 
struct sched_unit *unit,
  }
  
  static void cf_check

-sched_idle_free_udata(const struct scheduler *ops, void *priv)
+sched_idle_free_udata(const struct scheduler *operations, void *priv)
  {
  }
  
  static void cf_check sched_idle_schedule(

-const struct scheduler *ops, struct sched_unit *unit, s_time_t now,
+const struct scheduler *operations, struct sched_unit *unit, s_time_t now,
  bool tasklet_work_scheduled)
  {
  const unsigned int cpu = smp_processor_id();


These renames bring the idle scheduler out of sync with all others. I
think it wants considering to rename the file scope variable instead.



That's ok, since the variable is static.


@@ -2579,7 +2579,7 @@ static void cf_check sched_slave(void)
  struct sched_unit*prev = vprev->sched_unit, *next;
  s_time_t  now;
  spinlock_t   *lock;
-bool  do_softirq = false;
+bool  exec_softirq = false;


As an alternative to Stefano's suggestion, maybe consider "need_softirq"?



I like it, especially since it's a local variable.


--- a/xen/common/sched/credit2.c
+++ b/xen/common/sched/credit2.c
@@ -3884,7 +3884,7 @@ csched2_dump(const struct scheduler *ops)
  list_for_each_entry ( rqd, >rql, rql )
  {
  struct list_head *iter, *runq = >runq;
-int loop = 0;
+int it = 0;


Instead of renaming, why can't we just drop this second variable, re-using
the outer scope one here (and at the same time doing away with a not really
appropriate use of plain "int")? (This may then want accompanying by ...


@@ -3901,7 +3901,7 @@ csched2_dump(const struct scheduler *ops)
  
  if ( svc )

  {
-printk("\t%3d: ", loop++);
+printk("\t%3d: ", it++);


... switching to %3u here.)



Good point.

I'll submit a v2 shortly with these changes.

Regards,

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [PATCH V3 1/2] xen: Update dm_op.h from Xen public header

[Jan Beulich]

On 25.07.2023 09:09, Viresh Kumar wrote:
> On 25-07-23, 09:04, Jan Beulich wrote:
>> On 25.07.2023 08:47, Viresh Kumar wrote:
>>> +struct xen_dm_op {
>>> +uint32_t op;
>>> +uint32_t pad;
>>> +union {
>>> +struct xen_dm_op_create_ioreq_server create_ioreq_server;
>>> +struct xen_dm_op_get_ioreq_server_info get_ioreq_server_info;
>>> +struct xen_dm_op_ioreq_server_range map_io_range_to_ioreq_server;
>>> +struct xen_dm_op_ioreq_server_range 
>>> unmap_io_range_from_ioreq_server;
>>> +struct xen_dm_op_set_ioreq_server_state set_ioreq_server_state;
>>> +struct xen_dm_op_destroy_ioreq_server destroy_ioreq_server;
>>> +struct xen_dm_op_track_dirty_vram track_dirty_vram;
>>> +struct xen_dm_op_set_pci_intx_level set_pci_intx_level;
>>> +struct xen_dm_op_set_isa_irq_level set_isa_irq_level;
>>> +struct xen_dm_op_set_irq_level set_irq_level;
>>> +struct xen_dm_op_set_pci_link_route set_pci_link_route;
>>> +struct xen_dm_op_modified_memory modified_memory;
>>> +struct xen_dm_op_set_mem_type set_mem_type;
>>> +struct xen_dm_op_inject_event inject_event;
>>> +struct xen_dm_op_inject_msi inject_msi;
>>> +struct xen_dm_op_map_mem_type_to_ioreq_server 
>>> map_mem_type_to_ioreq_server;
>>> +struct xen_dm_op_remote_shutdown remote_shutdown;
>>> +struct xen_dm_op_relocate_memory relocate_memory;
>>> +struct xen_dm_op_pin_memory_cacheattr pin_memory_cacheattr;
>>> +struct xen_dm_op_nr_vcpus nr_vcpus;
>>> +} u;
>>> +};
>>
>> Is sync-ing for the sake of sync-ing really useful? For example, are any
>> of the ioreq server elements halfway likely to ever be used in the kernel?
> 
> The only field, out of the union, I am using for now is:
> 
> struct xen_dm_op_set_irq_level set_irq_level;
> 
> I am not sure if some of the others are going to be used or not in the
> future.

I question that use, btw, but it is not up to me to decide whether to
accept such a layering violation in Linux. dm-op is, as its name says,
for device models to use. Your intended use doesn't fall in that
category, aiui. Imo the present contents of dm_op.h in Linux is indeed
all a kernel is supposed to know about, unless it was to gain in-kernel
device models.

Jan

Re: [XEN PATCH 3/3] x86/irq: address violations of MISRA C:2012 Rules 8.2 and 8.3

[Jan Beulich]

On 25.07.2023 01:08, Stefano Stabellini wrote:
> On Mon, 24 Jul 2023, Federico Serafini wrote:
>> @@ -893,10 +893,10 @@ void irq_set_affinity(struct irq_desc *desc, const 
>> cpumask_t *mask)
>>  desc->status |= IRQ_MOVE_PENDING;
>>  }
>>  
>> -void pirq_set_affinity(struct domain *d, int pirq, const cpumask_t *mask)
>> +void pirq_set_affinity(struct domain *d, int irq, const cpumask_t *mask)
> 
> I welcome feedback from the other maintainers on this but I would keep
> the original "pirq" parameter name here...

+2

We absolutely should not further increase the misnaming. Instead the goal
needs to be to uniformly use pirq when pIRQ (used in interfacing with
guests) is meant, and irq when a (Xen internal) IRQ is meant. Sadly this
isn't helped by Arm not knowing the concept of pIRQ (see "[PATCH v2 0/2]
new CONFIG_HAS_PIRQ and extra_guest_irqs adjustment").

Jan