[ovmf test] 168793: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   22 days  229 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days   10 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

Re: [PATCH v3 2/5] xen: make evtchn_alloc_unbound public

[Jan Beulich]

On 23.03.2022 01:22, Stefano Stabellini wrote:
> On Tue, 15 Mar 2022, Daniel P. Smith wrote:
>> On 1/28/22 16:33, Stefano Stabellini wrote:
>>> From: Luca Miccio 
>>>
>>> The xenstore event channel will be allocated for dom0less domains. It is
>>> necessary to have access to the evtchn_alloc_unbound function to do
>>> that, so make evtchn_alloc_unbound public.
>>>
>>> Add a skip_xsm parameter to allow disabling the XSM check in
>>> evtchn_alloc_unbound (xsm_evtchn_unbound wouldn't work for a call
>>> originated from Xen before running any domains.)
>>>
>>> Signed-off-by: Luca Miccio 
>>> Signed-off-by: Stefano Stabellini 
>>> CC: Julien Grall 
>>> CC: Volodymyr Babchuk 
>>> CC: Bertrand Marquis 
>>> CC: Andrew Cooper 
>>> CC: George Dunlap 
>>> CC: Jan Beulich 
>>> CC: Wei Liu 
>>> ---
>>> Changes v3:
>>> - expose evtchn_alloc_unbound, assing a skip_xsm parameter
>>> ---
>>>  xen/common/event_channel.c | 13 -
>>>  xen/include/xen/event.h|  3 +++
>>>  2 files changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
>>> index da88ad141a..be57d00a15 100644
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -284,7 +284,7 @@ void evtchn_free(struct domain *d, struct evtchn *chn)
>>>  xsm_evtchn_close_post(chn);
>>>  }
>>>  
>>> -static int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
>>> +int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc, bool skip_xsm)
>>>  {
>>>  struct evtchn *chn;
>>>  struct domain *d;
>>> @@ -301,9 +301,12 @@ static int evtchn_alloc_unbound(evtchn_alloc_unbound_t 
>>> *alloc)
>>>  ERROR_EXIT_DOM(port, d);
>>>  chn = evtchn_from_port(d, port);
>>>  
>>> -rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, alloc->remote_dom);
>>> -if ( rc )
>>> -goto out;
>>> +if ( !skip_xsm )
>>> +{
>>> +rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, alloc->remote_dom);
>>> +if ( rc )
>>> +goto out;
>>> +}
>>
>> Please do not subvert the security framework because it causes an
>> inconvenience. As Jan recommended, work within the XSM check to allow
>> your access so that we may ensure it is done safely. If you need any
>> help making modifications to XSM, please do not hesitate to reach out as
>> I will gladly help.
> 
> Thank you!
> 
> First let me reply to Jan: this series is only introducing 1 more call
> to evtchn_alloc_unbound, which is to allocate the special xenstore event
> channel, the one configured via
> d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN].
> 
> It is not meant to be a generic function, and it is not meant to be
> called more than once. It could (should?) be __init.

How that? Its pre-existing use doesn't disappear, and requires it to be
non-__init.

> The existing XSM check in evtchn_alloc_unbound cannot work and should
> not work: it is based on the current domain having enough privileges to
> create the event channel. In this case, we have no current domain at
> all. The current domain is Xen itself.

And DOM_XEN cannot be given the appropriate permission, perhaps
explicitly when using a real policy and by default in dummy and SILO
modes?

Jan

> For these reasons, given [1], also not to subvert the security
> framework as Daniel pointed out, I think I should go back to my own
> implementation [2][3] based on get_free_port. That is my preference
> because:
> 
> - the Xen codebase doesn't gain much by reusing evtchn_alloc_unbound
> - adding skip_xsm introduces a component of risk (unless we make it
>   __init maybe?)
> - using get_free_port is trivial and doesn't pose the same issues
> 
> 
> Let's find all an agreement on how to move forward on this.
> 
> 
> [1] https://marc.info/?l=xen-devel&m=164194128922838
> [2] https://marc.info/?l=xen-devel&m=164203543615114
> [3] https://marc.info/?l=xen-devel&m=164203544615129 
> 

Re: [dm-devel] [PATCH 01/19] fs: remove mpage_alloc

[Christoph Hellwig]

On Wed, Mar 23, 2022 at 06:38:22AM +0900, Ryusuke Konishi wrote:
> This looks because the mask of GFP_KERNEL is removed along with
> the removal of mpage_alloc().
> 

> The default value of the gfp flag is set to GFP_HIGHUSER_MOVABLE by
> inode_init_always().
> So, __GFP_HIGHMEM hits the gfp warning at bio_alloc() that
> do_mpage_readpage() calls.

Yeah.  Let's try this to match the iomap code:

diff --git a/fs/mpage.c b/fs/mpage.c
index 9ed1e58e8d70b..d465883edf719 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -148,13 +148,11 @@ static struct bio *do_mpage_readpage(struct 
mpage_readpage_args *args)
int op = REQ_OP_READ;
unsigned nblocks;
unsigned relative_block;
-   gfp_t gfp;
+   gfp_t gfp = mapping_gfp_constraint(page->mapping, GFP_KERNEL);
 
if (args->is_readahead) {
op |= REQ_RAHEAD;
-   gfp = readahead_gfp_mask(page->mapping);
-   } else {
-   gfp = mapping_gfp_constraint(page->mapping, GFP_KERNEL);
+   gfp |= __GFP_NORETRY | __GFP_NOWARN;
}
 
if (page_has_buffers(page))

Re: [PATCH v2 3/3] Use g_new() & friends where that makes obvious sense

[Klaus Jensen]

On Mar 15 15:41, Markus Armbruster wrote:
> g_new(T, n) is neater than g_malloc(sizeof(T) * n).  It's also safer,
> for two reasons.  One, it catches multiplication overflowing size_t.
> Two, it returns T * rather than void *, which lets the compiler catch
> more type errors.
> 
> This commit only touches allocations with size arguments of the form
> sizeof(T).
> 
> Patch created mechanically with:
> 
> $ spatch --in-place --sp-file scripts/coccinelle/use-g_new-etc.cocci \
>--macro-file scripts/cocci-macro-file.h FILES...
> 
> Signed-off-by: Markus Armbruster 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Cédric Le Goater 
> Reviewed-by: Alex Bennée 
> Acked-by: Dr. David Alan Gilbert 
> ---
>  hw/nvme/ns.c |  2 +-

For hw/nvme,

Acked-by: Klaus Jensen 


signature.asc
Description: PGP signature

[PATCH] xen: don't hang when resuming PCI device

[Jakub Kądziołka]

If a xen domain with at least two VCPUs has a PCI device attached which
enters the D3hot state during suspend, the kernel may hang while
resuming, depending on the core on which an async resume task gets
scheduled.

The bug occurs because xen's do_suspend calls dpm_resume_start while
only the timer of the boot CPU has been resumed (when xen_suspend called
syscore_resume), before calling xen_arch_suspend to resume the timers of
the other CPUs. This breaks pci_dev_d3_sleep.

Thus this patch moves the call to xen_arch_resume before the call to
dpm_resume_start, eliminating the hangs and restoring the stack-like
structure of the suspend/restore procedure.

Signed-off-by: Jakub Kądziołka 
---
 drivers/xen/manage.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index 374d36de7f5a..3d5a384d65f7 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -141,6 +141,8 @@ static void do_suspend(void)
 
raw_notifier_call_chain(&xen_resume_notifier, 0, NULL);
 
+   xen_arch_resume();
+
dpm_resume_start(si.cancelled ? PMSG_THAW : PMSG_RESTORE);
 
if (err) {
@@ -148,8 +150,6 @@ static void do_suspend(void)
si.cancelled = 1;
}
 
-   xen_arch_resume();
-
 out_resume:
if (!si.cancelled)
xs_resume();
-- 
2.30.2

[linux-linus test] 168787: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl 22 guest-start/debian.repeat fail in 168768 pass in 168787
 test-armhf-armhf-xl-vhd 12 debian-di-install fail in 168768 pass in 168787
 test-arm64-arm64-xl-vhd  17 guest-start/debian.repeat  fail pass in 168768

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate   fail REGR. vs. 168760

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

version targeted for testing:
 linuxb47d5a4f6b8d42f8a8fbe891b36215e4fddc53be
baseline version:
 linuxeaa54b1458ca84092e513d554dd6d234245e6bef

Last test of basis   168760  2022-03-21 19:41:16 Z1 days
Testing same since   168768  2022-03-22 04:17:09 Z0 days2 attempts

--

[xen-unstable test] 168786: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. 
vs. 168763

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

[ovmf test] 168790: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   22 days  228 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days9 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

Re: [PATCH v3 5/5] tools: add example application to initialize dom0less PV drivers

[Stefano Stabellini]

On Sat, 29 Jan 2022, Julien Grall wrote:
> On 28/01/2022 21:33, Stefano Stabellini wrote:
> > From: Luca Miccio 
> > 
> > Add an example application that can be run in dom0 to complete the
> > dom0less domains initialization so that they can get access to xenstore
> > and use PV drivers.
> > 
> > Signed-off-by: Luca Miccio 
> > Signed-off-by: Stefano Stabellini 
> > CC: Wei Liu 
> > CC: Anthony PERARD 
> > CC: Juergen Gross 
> > ---
> > Changes in v3:
> > - handle xenstore errors
> > - add an in-code comment about xenstore entries
> > - less verbose output
> > - clean-up error path in main
> > 
> > Changes in v2:
> > - do not set HVM_PARAM_STORE_EVTCHN twice
> > - rename restore_xenstore to create_xenstore
> > - increase maxmem
> > ---
> >   tools/helpers/Makefile|  13 ++
> >   tools/helpers/init-dom0less.c | 269 ++
> 
> Should we document how this is meant to be used?

Good idea, I'll add it to docs/features/dom0less.pandoc


> >   2 files changed, 282 insertions(+)
> >   create mode 100644 tools/helpers/init-dom0less.c
> > 
> > diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
> > index 7f6c422440..8e42997052 100644
> > --- a/tools/helpers/Makefile
> > +++ b/tools/helpers/Makefile
> > @@ -10,6 +10,9 @@ ifeq ($(CONFIG_Linux),y)
> >   ifeq ($(CONFIG_X86),y)
> >   PROGS += init-xenstore-domain
> >   endif
> > +ifeq ($(CONFIG_ARM),y)
> > +PROGS += init-dom0less
> > +endif >   endif
> > XEN_INIT_DOM0_OBJS = xen-init-dom0.o init-dom-json.o
> > @@ -26,6 +29,13 @@ $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS +=
> > $(CFLAGS_libxenstore)
> >   $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += $(CFLAGS_libxenlight)
> >   $(INIT_XENSTORE_DOMAIN_OBJS): CFLAGS += -include
> > $(XEN_ROOT)/tools/config.h
> >   +INIT_DOM0LESS_OBJS = init-dom0less.o init-dom-json.o
> > +$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
> > +$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenstore)
> > +$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenlight)
> > +$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenctrl)
> > +$(INIT_DOM0LESS_OBJS): CFLAGS += $(CFLAGS_libxenevtchn)
> > +
> >   .PHONY: all
> >   all: $(PROGS)
> >   @@ -35,6 +45,9 @@ xen-init-dom0: $(XEN_INIT_DOM0_OBJS)
> >   init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
> > $(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS)
> > $(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl)
> > $(LDLIBS_libxenguest) $(LDLIBS_libxenlight) $(APPEND_LDFLAGS)
> >   +init-dom0less: $(INIT_DOM0LESS_OBJS)
> > +   $(CC) $(LDFLAGS) -o $@ $(INIT_DOM0LESS_OBJS) $(LDLIBS_libxenctrl)
> > $(LDLIBS_libxenevtchn) $(LDLIBS_libxentoollog) $(LDLIBS_libxenstore)
> > $(LDLIBS_libxenlight) $(LDLIBS_libxenguest)  $(APPEND_LDFLAGS)
> > +
> >   .PHONY: install
> >   install: all
> > $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
> > diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
> > new file mode 100644
> > index 00..b6a3831cb5
> > --- /dev/null
> > +++ b/tools/helpers/init-dom0less.c
> > @@ -0,0 +1,269 @@
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "init-dom-json.h"
> > +
> > +#define NR_MAGIC_PAGES 4
> 
> Why are we allocating 4 pages when only 2 (maybe 1) is necessary?

Good point, I think we can only allocate 1


> > +#define CONSOLE_PFN_OFFSET 0
> > +#define XENSTORE_PFN_OFFSET 1
> > +#define STR_MAX_LENGTH 64
> > +
> > +static int alloc_magic_pages(libxl_dominfo *info, struct xc_dom_image *dom)
> > +{
> > +int rc, i;
> > +const xen_pfn_t base = GUEST_MAGIC_BASE >> XC_PAGE_SHIFT;
> > +xen_pfn_t p2m[NR_MAGIC_PAGES];
> > +
> > +rc = xc_domain_setmaxmem(dom->xch, dom->guest_domid,
> > + info->max_memkb + NR_MAGIC_PAGES * 4);
> 
> Please don't rely on the fact the page size will be 4KB in Xen. Instead, use
> XC_PAGE_*.

OK


> > +if (rc < 0)
> > +return rc;
> > +
> > +for (i = 0; i < NR_MAGIC_PAGES; i++)
> > +p2m[i] = base + i;
> > +
> > +rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
> > +  NR_MAGIC_PAGES, 0, 0, p2m);
> > +if (rc < 0)
> > +return rc;
> > +
> > +dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
> > +
> > +xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
> 
> So you allocate 4 pages, use 2, but only clear 1. Can you explain why?

We only need the xenstore page, I'll fix it


> Also, should not you check the error return here and  ...
> 
> > +
> > +xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
> > + dom->xenstore_pfn);
> 
> here...?

Yes


> Also, in theory, as soon as you set xc_hvm_param_set(), the guest may be able
> to start using Xenstore. So wouldn't it be better to set it once you know
> everything is in place (i.e. just before calling xs_introduce_domain())?

Thi

Re: [PATCH v3 3/5] xen/arm: configure dom0less domain for enabling xenstore after boot

[Stefano Stabellini]

On Sat, 29 Jan 2022, Julien Grall wrote:
> On 28/01/2022 21:33, Stefano Stabellini wrote:
> > From: Luca Miccio 
> > 
> > If "xen,enhanced" is enabled, then add to dom0less domains:
> > 
> > - the hypervisor node in device tree
> > - the xenstore event channel
> > 
> > The xenstore event channel is also used for the first notification to
> > let the guest know that xenstore has become available.
> > 
> > Signed-off-by: Luca Miccio 
> > Signed-off-by: Stefano Stabellini 
> > Reviewed-by: Bertrand Marquis 
> > CC: Julien Grall 
> > CC: Volodymyr Babchuk 
> > CC: Bertrand Marquis 
> > 
> > ---
> > Changes in v3:
> > - use evtchn_alloc_unbound
> > 
> > Changes in v2:
> > - set HVM_PARAM_STORE_PFN to ~0ULL at domain creation
> > - in alloc_xenstore_evtchn do not call _evtchn_alloc_unbound
> > ---
> >   xen/arch/arm/domain_build.c | 41 +
> >   1 file changed, 41 insertions(+)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 9144d6c0b6..8e030a7f05 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -27,6 +27,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> > #include 
> >   #include 
> > @@ -2619,6 +2620,8 @@ static int __init prepare_dtb_domU(struct domain *d,
> > struct kernel_info *kinfo)
> >   int ret;
> > kinfo->phandle_gic = GUEST_PHANDLE_GIC;
> > +kinfo->gnttab_start = GUEST_GNTTAB_BASE;
> > +kinfo->gnttab_size = GUEST_GNTTAB_SIZE;
> > addrcells = GUEST_ROOT_ADDRESS_CELLS;
> >   sizecells = GUEST_ROOT_SIZE_CELLS;
> > @@ -2693,6 +2696,13 @@ static int __init prepare_dtb_domU(struct domain *d,
> > struct kernel_info *kinfo)
> >   goto err;
> >   }
> >   +if ( kinfo->dom0less_enhanced )
> > +{
> > +ret = make_hypervisor_node(d, kinfo, addrcells, sizecells);
> 
> Looking at the code, I think the extended regions will not work properly
> because we are looking at the host memory layout. In the case of domU, we want
> to use the guest layout. Please have a look how it was done in libxl.

Yeah you are right, I'll do that.


> > +if ( ret )
> > +goto err;
> > +}
> > +
> >   ret = fdt_end_node(kinfo->fdt);
> >   if ( ret < 0 )
> >   goto err;
> > @@ -2959,6 +2969,25 @@ static int __init construct_domain(struct domain *d,
> > struct kernel_info *kinfo)
> >   return 0;
> >   }
> >   +static int __init alloc_xenstore_evtchn(struct domain *d)
> > +{
> > +evtchn_alloc_unbound_t alloc;
> > +int rc;
> > +
> > +alloc.dom = d->domain_id;
> > +alloc.remote_dom = hardware_domain->domain_id;
> 
> The first thing evtchn_alloc_unbound() will do is looking up the domain. This
> seems a bit pointless given that we have the domain in hand. Shouldn't we
> extend evtchn_alloc_unbound() to pass the domain?

That's a good point, but I actually think it is better to go back to
[2]. The evtchn_alloc_unbound discussion is still ongoing but I'll keep
this suggestion in mind.

[2] https://marc.info/?l=xen-devel&m=164203543615114


> > +rc = evtchn_alloc_unbound(&alloc, true);
> > +if ( rc )
> > +{
> > +printk("Failed allocating event channel for domain\n");
> > +return rc;
> > +}
> > +
> > +d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN] = alloc.port;
> > +
> > +return 0;
> > +}
> > +
> >   static int __init construct_domU(struct domain *d,
> >const struct dt_device_node *node)
> >   {
> > @@ -3014,7 +3043,19 @@ static int __init construct_domU(struct domain *d,
> >   return rc;
> > if ( kinfo.vpl011 )
> > +{
> >   rc = domain_vpl011_init(d, NULL);
> > +if ( rc < 0 )
> > +return rc;
> > +}
> > +
> > +if ( kinfo.dom0less_enhanced )
> > +{
> > +rc = alloc_xenstore_evtchn(d);
> > +if ( rc < 0 )
> > +return rc;
> > +d->arch.hvm.params[HVM_PARAM_STORE_PFN] = ~0ULL;
> 
> I think it would be easy to allocate the page right now. So what prevent us to
> do it right now?

Because (as you noted as a comment to the following patch) as soon as
d->arch.hvm.params[HVM_PARAM_STORE_PFN] is set the guest can continue
with the initialization and will expect the right data to be set on the
page. In other words: it is not enough to have the pfn allocated, we
also need xenstore to initialize it. At that point, it is better to do
both later from init-dom0less.c.

Re: [PATCH v3 2/5] xen: make evtchn_alloc_unbound public

[Stefano Stabellini]

On Tue, 15 Mar 2022, Daniel P. Smith wrote:
> On 1/28/22 16:33, Stefano Stabellini wrote:
> > From: Luca Miccio 
> > 
> > The xenstore event channel will be allocated for dom0less domains. It is
> > necessary to have access to the evtchn_alloc_unbound function to do
> > that, so make evtchn_alloc_unbound public.
> > 
> > Add a skip_xsm parameter to allow disabling the XSM check in
> > evtchn_alloc_unbound (xsm_evtchn_unbound wouldn't work for a call
> > originated from Xen before running any domains.)
> > 
> > Signed-off-by: Luca Miccio 
> > Signed-off-by: Stefano Stabellini 
> > CC: Julien Grall 
> > CC: Volodymyr Babchuk 
> > CC: Bertrand Marquis 
> > CC: Andrew Cooper 
> > CC: George Dunlap 
> > CC: Jan Beulich 
> > CC: Wei Liu 
> > ---
> > Changes v3:
> > - expose evtchn_alloc_unbound, assing a skip_xsm parameter
> > ---
> >  xen/common/event_channel.c | 13 -
> >  xen/include/xen/event.h|  3 +++
> >  2 files changed, 11 insertions(+), 5 deletions(-)
> > 
> > diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> > index da88ad141a..be57d00a15 100644
> > --- a/xen/common/event_channel.c
> > +++ b/xen/common/event_channel.c
> > @@ -284,7 +284,7 @@ void evtchn_free(struct domain *d, struct evtchn *chn)
> >  xsm_evtchn_close_post(chn);
> >  }
> >  
> > -static int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
> > +int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc, bool skip_xsm)
> >  {
> >  struct evtchn *chn;
> >  struct domain *d;
> > @@ -301,9 +301,12 @@ static int evtchn_alloc_unbound(evtchn_alloc_unbound_t 
> > *alloc)
> >  ERROR_EXIT_DOM(port, d);
> >  chn = evtchn_from_port(d, port);
> >  
> > -rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, alloc->remote_dom);
> > -if ( rc )
> > -goto out;
> > +if ( !skip_xsm )
> > +{
> > +rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, alloc->remote_dom);
> > +if ( rc )
> > +goto out;
> > +}
> 
> Please do not subvert the security framework because it causes an
> inconvenience. As Jan recommended, work within the XSM check to allow
> your access so that we may ensure it is done safely. If you need any
> help making modifications to XSM, please do not hesitate to reach out as
> I will gladly help.

Thank you!

First let me reply to Jan: this series is only introducing 1 more call
to evtchn_alloc_unbound, which is to allocate the special xenstore event
channel, the one configured via
d->arch.hvm.params[HVM_PARAM_STORE_EVTCHN].

It is not meant to be a generic function, and it is not meant to be
called more than once. It could (should?) be __init.

The existing XSM check in evtchn_alloc_unbound cannot work and should
not work: it is based on the current domain having enough privileges to
create the event channel. In this case, we have no current domain at
all. The current domain is Xen itself.

For these reasons, given [1], also not to subvert the security
framework as Daniel pointed out, I think I should go back to my own
implementation [2][3] based on get_free_port. That is my preference
because:

- the Xen codebase doesn't gain much by reusing evtchn_alloc_unbound
- adding skip_xsm introduces a component of risk (unless we make it
  __init maybe?)
- using get_free_port is trivial and doesn't pose the same issues


Let's find all an agreement on how to move forward on this.


[1] https://marc.info/?l=xen-devel&m=164194128922838
[2] https://marc.info/?l=xen-devel&m=164203543615114
[3] https://marc.info/?l=xen-devel&m=164203544615129 

Re: [PATCH v3 1/5] xen: introduce xen,enhanced dom0less property

[Stefano Stabellini]

On Sat, 29 Jan 2022, Julien Grall wrote:
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 6931c022a2..9144d6c0b6 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2963,6 +2963,7 @@ static int __init construct_domU(struct domain *d,
> >const struct dt_device_node *node)
> >   {
> >   struct kernel_info kinfo = {};
> > +const char *dom0less_enhanced;
> >   int rc;
> >   u64 mem;
> >   @@ -2978,6 +2979,12 @@ static int __init construct_domU(struct domain *d,
> > kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
> >   +rc = dt_property_read_string(node, "xen,enhanced",
> > &dom0less_enhanced);
> > +if ( rc == -EILSEQ ||
> 
> I think the use an -EILSEQ wants an explanation. In a previous version, you
> wrote that the value would be returned when:
> 
> fdt set /chosen/domU0 xen,enhanced
> 
> But it is not clear why. Can you print pp->value, pp->length, strnlen(..) when
> this happens?

I added in dt_property_read_string:

printk("DEBUG %s %d value=%s value[0]=%d length=%u 
len=%lu\n",__func__,__LINE__,(char*)pp->value, *((char*)pp->value),pp->length, 
strlen(pp->value));

This is the output:
(XEN) DEBUG dt_property_read_string 205 value= value[0]=0 length=0 len=0

[qemu-mainline test] 168784: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 19 guest-saverestore.2  fail REGR. vs. 168765

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

version targeted for testing:
 qemuu5791de9d48743c7fde0c0d9b065f260056968e99
baseline version:
 qemuu330724977b10f5b92610817e8b7d1dfed122df87

Last test of basis   168765  2022-03-22 02:38:15 Z0 days
Testing same since   168784  2022-03-22 15:38:21 Z0 days1 attempts

---

[ovmf test] 168789: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  227 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days8 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

Re: [dm-devel] [PATCH 01/19] fs: remove mpage_alloc

[Ryusuke Konishi]

On Wed, Mar 23, 2022 at 6:19 AM Guenter Roeck  wrote:
>
> On Mon, Jan 24, 2022 at 10:10:49AM +0100, Christoph Hellwig wrote:
> > open code mpage_alloc in it's two callers and simplify the results
> > because of the context:
> >
> >  - __mpage_writepage always passes GFP_NOFS and can thus always sleep and
> > will never get a NULL return from bio_alloc at all.
> >  - do_mpage_readpage can only get a non-sleeping context for readahead
> >which never sets PF_MEMALLOC and thus doesn't need the retry loop
> >either.
> >
> > Both cases will never have __GFP_HIGH set.
> >
>
> With this patch in the tree, I get:
>
> [1.198134] Unexpected gfp: 0x2 (__GFP_HIGHMEM). Fixing up to gfp: 
> 0x1192888 
> (GFP_NOWAIT|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_MOVABLE|__GFP_SKIP_KASAN_POISON).
>  Fix your code!
> [1.198783] CPU: 0 PID: 1 Comm: init Not tainted 
> 5.17.0-01402-g8565d64430f8 #1
> [1.199165] Stack : 0042  0008 
> dae882cc7dea7ec4
> [1.199563] a800014f0c00  a8000146b2c8 
> 80d3a920
> [1.199750] a8000146b0e0 0001  
> 
> [1.199936] 0003087f  806d9f54 
> 
> [1.200121] a8000146b16f 80da 0001 
> 0119288a
> [1.200306] 80da  0119288a 
> 0119288a
> [1.200491] a80001416f00  80774d30 
> a0042718
> [1.200676] 80ec2158 a80001468000 a8000146b2c0 
> 
> [1.200861] 80b55730  a8000146b3f8 
> 80d3a920
> [1.201046] 0001 0119288a 80108fa0 
> dae882cc7dea7ec4
> [1.201236] ...
> [1.201548] Call Trace:
> [1.201622] [] show_stack+0x38/0x118
> [1.201960] [] dump_stack_lvl+0x50/0x6c
> [1.202105] [] kmalloc_fix_flags+0x60/0x88
> [1.202249] [] new_slab+0x2d8/0x320
> [1.202375] [] ___slab_alloc.constprop.0+0x33c/0x5e8
> [1.202528] [] __slab_alloc.constprop.0+0x34/0x50
> [1.202675] [] kmem_cache_alloc+0x320/0x368
> [1.202811] [] bvec_alloc+0x78/0x128
> [1.202936] [] bio_alloc_bioset+0x194/0x340
> [1.203073] [] do_mpage_readpage+0x540/0x6e0
> [1.203213] [] mpage_readahead+0xc0/0x198
> [1.203346] [] read_pages+0xc0/0x2e0
> [1.203472] [] page_cache_ra_unbounded+0x1cc/0x290
> [1.203622] [] filemap_fault+0x4f4/0x7e8
> [1.203753] [] __do_fault+0x44/0x190
> [1.203878] [] __handle_mm_fault+0x7e4/0xcd0
> [1.204015] [] handle_mm_fault+0x110/0x258
> [1.204149] [] do_page_fault+0x110/0x4f0
> [1.204278] [] tlb_do_page_fault_1+0x108/0x110
> [1.204421] [] padzero+0x64/0x98
> [1.204538] [] load_elf_binary+0x1808/0x18d0
> [1.204677] [] bprm_execve+0x240/0x5a8
> [1.204806] [] kernel_execve+0x144/0x200
> [1.204937] [] try_to_run_init_process+0x18/0x58
> [1.205085] [] kernel_init+0xb4/0x10c
> [1.205220] [] ret_from_kernel_thread+0x14/0x1c
>
> with some qemu emulations. Bisect log is attached.
>
> I can not easily revert the patch since an attempt to do so causes
> conflicts, so I can not test upstream without this patch.
>
> Guenter

This looks because the mask of GFP_KERNEL is removed along with
the removal of mpage_alloc().

-static struct bio *
-mpage_alloc(struct block_device *bdev,
-   sector_t first_sector, int nr_vecs,
-   gfp_t gfp_flags)
-{
-   struct bio *bio;
-
-   /* Restrict the given (page cache) mask for slab allocations */
-   gfp_flags &= GFP_KERNEL;
-   bio = bio_alloc(gfp_flags, nr_vecs);

In read ahead mode, do_mpage_readpage() uses the gfp flag of page->mapping.

if (args->is_readahead) {
op |= REQ_RAHEAD;
gfp = readahead_gfp_mask(page->mapping);
} else {
gfp = mapping_gfp_constraint(page->mapping, GFP_KERNEL);
}

The default value of the gfp flag is set to GFP_HIGHUSER_MOVABLE by
inode_init_always().
So, __GFP_HIGHMEM hits the gfp warning at bio_alloc() that
do_mpage_readpage() calls.


Ryusuke Konishi


>
> ---
> # bad: [8565d64430f8278bea38dab0a3ab60b4e11c71e4] Merge tag 
> 'bounds-fixes-v5.18-rc1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
> # good: [f443e374ae131c168a065ea1748feac6b2e76613] Linux 5.17
> git bisect start 'HEAD' 'v5.17'
> # good: [5628b8de1228436d47491c662dc521bc138a3d43] Merge tag 
> 'random-5.18-rc1-for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/crng/random
> git bisect good 5628b8de1228436d47491c662dc521bc138a3d43
> # bad: [69d1dea852b54eecd8ad2ec92a7fd371e9aec4bd] Merge tag 
> 'for-5.18/drivers-2022-03-18' of git://git.kernel.dk/linux-block
> git bisect bad 69d1dea852b54eecd8ad2ec92a7fd371e9aec4bd
> # good: [b080cee72ef3

Re: [dm-devel] [PATCH 01/19] fs: remove mpage_alloc

[Guenter Roeck]

On Mon, Jan 24, 2022 at 10:10:49AM +0100, Christoph Hellwig wrote:
> open code mpage_alloc in it's two callers and simplify the results
> because of the context:
> 
>  - __mpage_writepage always passes GFP_NOFS and can thus always sleep and
> will never get a NULL return from bio_alloc at all.
>  - do_mpage_readpage can only get a non-sleeping context for readahead
>which never sets PF_MEMALLOC and thus doesn't need the retry loop
>either.
> 
> Both cases will never have __GFP_HIGH set.
> 

With this patch in the tree, I get:

[1.198134] Unexpected gfp: 0x2 (__GFP_HIGHMEM). Fixing up to gfp: 0x1192888 
(GFP_NOWAIT|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_MOVABLE|__GFP_SKIP_KASAN_POISON).
 Fix your code!
[1.198783] CPU: 0 PID: 1 Comm: init Not tainted 5.17.0-01402-g8565d64430f8 
#1
[1.199165] Stack : 0042  0008 
dae882cc7dea7ec4
[1.199563] a800014f0c00  a8000146b2c8 
80d3a920
[1.199750] a8000146b0e0 0001  

[1.199936] 0003087f  806d9f54 

[1.200121] a8000146b16f 80da 0001 
0119288a
[1.200306] 80da  0119288a 
0119288a
[1.200491] a80001416f00  80774d30 
a0042718
[1.200676] 80ec2158 a80001468000 a8000146b2c0 

[1.200861] 80b55730  a8000146b3f8 
80d3a920
[1.201046] 0001 0119288a 80108fa0 
dae882cc7dea7ec4
[1.201236] ...
[1.201548] Call Trace:
[1.201622] [] show_stack+0x38/0x118
[1.201960] [] dump_stack_lvl+0x50/0x6c
[1.202105] [] kmalloc_fix_flags+0x60/0x88
[1.202249] [] new_slab+0x2d8/0x320
[1.202375] [] ___slab_alloc.constprop.0+0x33c/0x5e8
[1.202528] [] __slab_alloc.constprop.0+0x34/0x50
[1.202675] [] kmem_cache_alloc+0x320/0x368
[1.202811] [] bvec_alloc+0x78/0x128
[1.202936] [] bio_alloc_bioset+0x194/0x340
[1.203073] [] do_mpage_readpage+0x540/0x6e0
[1.203213] [] mpage_readahead+0xc0/0x198
[1.203346] [] read_pages+0xc0/0x2e0
[1.203472] [] page_cache_ra_unbounded+0x1cc/0x290
[1.203622] [] filemap_fault+0x4f4/0x7e8
[1.203753] [] __do_fault+0x44/0x190
[1.203878] [] __handle_mm_fault+0x7e4/0xcd0
[1.204015] [] handle_mm_fault+0x110/0x258
[1.204149] [] do_page_fault+0x110/0x4f0
[1.204278] [] tlb_do_page_fault_1+0x108/0x110
[1.204421] [] padzero+0x64/0x98
[1.204538] [] load_elf_binary+0x1808/0x18d0
[1.204677] [] bprm_execve+0x240/0x5a8
[1.204806] [] kernel_execve+0x144/0x200
[1.204937] [] try_to_run_init_process+0x18/0x58
[1.205085] [] kernel_init+0xb4/0x10c
[1.205220] [] ret_from_kernel_thread+0x14/0x1c

with some qemu emulations. Bisect log is attached.

I can not easily revert the patch since an attempt to do so causes
conflicts, so I can not test upstream without this patch.

Guenter

---
# bad: [8565d64430f8278bea38dab0a3ab60b4e11c71e4] Merge tag 
'bounds-fixes-v5.18-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
# good: [f443e374ae131c168a065ea1748feac6b2e76613] Linux 5.17
git bisect start 'HEAD' 'v5.17'
# good: [5628b8de1228436d47491c662dc521bc138a3d43] Merge tag 
'random-5.18-rc1-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/crng/random
git bisect good 5628b8de1228436d47491c662dc521bc138a3d43
# bad: [69d1dea852b54eecd8ad2ec92a7fd371e9aec4bd] Merge tag 
'for-5.18/drivers-2022-03-18' of git://git.kernel.dk/linux-block
git bisect bad 69d1dea852b54eecd8ad2ec92a7fd371e9aec4bd
# good: [b080cee72ef355669cbc52ff55dc513d37433600] Merge tag 
'for-5.18/io_uring-statx-2022-03-18' of git://git.kernel.dk/linux-block
git bisect good b080cee72ef355669cbc52ff55dc513d37433600
# bad: [22027a9811349de28f81e13e20e83299099acd3a] nvmet: replace 
ida_simple[get|remove] with the simler ida_[alloc|free]
git bisect bad 22027a9811349de28f81e13e20e83299099acd3a
# bad: [672fdcf0e7de3b1e39416ac85abf178f023271f1] block: partition 
include/linux/blk-cgroup.h
git bisect bad 672fdcf0e7de3b1e39416ac85abf178f023271f1
# bad: [b42c1fc3d55e077d36718ad9800d89100b2aff81] block: fix the kerneldoc for 
bio_end_io_acct
git bisect bad b42c1fc3d55e077d36718ad9800d89100b2aff81
# bad: [4b1dc86d1857f1007865cab759f2285280692eee] drbd: bio_alloc can't fail if 
it is allow to sleep
git bisect bad 4b1dc86d1857f1007865cab759f2285280692eee
# bad: [f0d911927b3c7cf5f9edb5941d0287144a602d0d] nilfs2: remove 
nilfs_alloc_seg_bio
git bisect bad f0d911927b3c7cf5f9edb5941d0287144a602d0d
# good: [e7243285c0fc87054990fcde630583586ff8ed5f] block: move 
blk_drop_partitions to blk.h
git bisect good e7243285c0fc87054990fcde630583586ff8ed5f
# bad: [d5f68a42da7a4516e7503c281a54a58727f07dc3] 

[PATCH v4 1/2] gitlab-ci: add qemu-system-arm to the existing tests-artifacts container

[Stefano Stabellini]

From: Stefano Stabellini 

Add qemu-system-arm to the existing test-artifacts qemu container (which
doesn't get build for every iteration but only updated once in a while.)

With qemu-system-arm available, we'll be able to run ARM32 tests.

This patch also bumps the QEMU version to v6.0.0 for both arm32 and
arm64 (the test-artifacts container is one, shared for both).

Signed-off-by: Stefano Stabellini 
Reviewed-by: Anthony PERARD 
---
 automation/gitlab-ci/build.yaml| 14 --
 automation/gitlab-ci/test.yaml |  4 ++--
 ...arm64v8.dockerfile => 6.0.0-arm64v8.dockerfile} |  5 +++--
 3 files changed, 17 insertions(+), 6 deletions(-)
 rename 
automation/tests-artifacts/qemu-system-aarch64/{5.2.0-arm64v8.dockerfile => 
6.0.0-arm64v8.dockerfile} (95%)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index cc36428cf5..72f2a317ac 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -591,9 +591,9 @@ kernel-5.9.9-arm64-export:
   tags:
 - arm64
 
-qemu-system-aarch64-5.2.0-arm64-export:
+qemu-system-aarch64-6.0.0-arm64-export:
   stage: build
-  image: 
registry.gitlab.com/xen-project/xen/tests-artifacts/qemu-system-aarch64:5.2.0-arm64v8
+  image: 
registry.gitlab.com/xen-project/xen/tests-artifacts/qemu-system-aarch64:6.0.0-arm64v8
   script:
 - mkdir binaries && cp /qemu-system-aarch64 binaries/qemu-system-aarch64
   artifacts:
@@ -602,6 +602,16 @@ qemu-system-aarch64-5.2.0-arm64-export:
   tags:
 - arm64
 
+qemu-system-aarch64-6.0.0-arm32-export:
+  stage: build
+  image: 
registry.gitlab.com/xen-project/xen/tests-artifacts/qemu-system-aarch64:6.0.0-arm64v8
+  script:
+- mkdir binaries && cp /qemu-system-arm binaries/qemu-system-arm
+  artifacts:
+paths:
+  - binaries/qemu-system-arm
+  tags:
+- arm64
 
 # x86_64 test artifacts
 
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index 47e8704df3..ec2a2e1607 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -33,7 +33,7 @@ qemu-alpine-arm64-gcc:
 - alpine-3.12-gcc-arm64
 - alpine-3.12-arm64-rootfs-export
 - kernel-5.9.9-arm64-export
-- qemu-system-aarch64-5.2.0-arm64-export
+- qemu-system-aarch64-6.0.0-arm64-export
   artifacts:
 paths:
   - smoke.serial
@@ -81,7 +81,7 @@ qemu-smoke-arm64-gcc:
   dependencies:
 - debian-unstable-gcc-arm64
 - kernel-5.9.9-arm64-export
-- qemu-system-aarch64-5.2.0-arm64-export
+- qemu-system-aarch64-6.0.0-arm64-export
   artifacts:
 paths:
   - smoke.serial
diff --git 
a/automation/tests-artifacts/qemu-system-aarch64/5.2.0-arm64v8.dockerfile 
b/automation/tests-artifacts/qemu-system-aarch64/6.0.0-arm64v8.dockerfile
similarity index 95%
rename from 
automation/tests-artifacts/qemu-system-aarch64/5.2.0-arm64v8.dockerfile
rename to 
automation/tests-artifacts/qemu-system-aarch64/6.0.0-arm64v8.dockerfile
index e105a1c636..793432d40b 100644
--- a/automation/tests-artifacts/qemu-system-aarch64/5.2.0-arm64v8.dockerfile
+++ b/automation/tests-artifacts/qemu-system-aarch64/6.0.0-arm64v8.dockerfile
@@ -3,7 +3,7 @@ LABEL maintainer.name="The Xen Project" \
   maintainer.email="xen-devel@lists.xenproject.org"
 
 ENV DEBIAN_FRONTEND=noninteractive
-ENV QEMU_VERSION=5.2.0
+ENV QEMU_VERSION=6.0.0
 ENV USER root
 
 RUN mkdir /build
@@ -25,7 +25,7 @@ RUN apt-get update && \
 tar xvJf qemu-"$QEMU_VERSION".tar.xz && \
 cd qemu-"$QEMU_VERSION" && \
 ./configure\
---target-list=aarch64-softmmu \
+--target-list=arm-softmmu,aarch64-softmmu \
 --enable-system\
 --disable-blobs\
 --disable-bsd-user \
@@ -68,6 +68,7 @@ RUN apt-get update && \
 && \
 make -j$(nproc) && \
 cp ./build/qemu-system-aarch64 / && \
+cp ./build/qemu-system-arm / && \
 cd /build && \
 rm -rf qemu-"$QEMU_VERSION"* && \
 apt-get autoremove -y && \
-- 
2.25.1

[PATCH v4 2/2] gitlab-ci: add an ARM32 qemu-based smoke test

[Stefano Stabellini]

Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
the test-artifacts qemu container. The minimal test simply boots Xen
(built from previous build stages) and Dom0.

The test needs a working kernel and minimal initrd for dom0. Instead of
building our own kernel and initrd, which would mean maintaining one or
two more builting scripts under automation/, we borrow a kernel and
initrd from distros.

For the kernel we pick the Debian Bullseye kernel, which has everything
we need already built-in. However, we cannot use the Debian Bullseye
initrd because it is 22MB and the large size causes QEMU to core dump.

Instead, use the tiny busybox-based rootfs provided by Alpine Linux,
which is really minimal: just 2.5MB. Note that we cannot use the Alpine
Linux kernel because that doesn't boot on Xen.

Signed-off-by: Stefano Stabellini 
---
Changes in v4:
- improve commit message
- use Debian Bullseye kernel
- use Alpine Linux initrd
---
 automation/gitlab-ci/test.yaml | 23 
 automation/scripts/qemu-smoke-arm32.sh | 81 ++
 2 files changed, 104 insertions(+)
 create mode 100755 automation/scripts/qemu-smoke-arm32.sh

diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index ec2a2e1607..42cd725a12 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -95,6 +95,29 @@ qemu-smoke-arm64-gcc:
 - /^coverity-tested\/.*/
 - /^stable-.*/
 
+qemu-smoke-arm32-gcc:
+  stage: test
+  image: registry.gitlab.com/xen-project/xen/${CONTAINER}
+  variables:
+CONTAINER: debian:unstable-arm64v8
+  script:
+- ./automation/scripts/qemu-smoke-arm32.sh 2>&1 | tee qemu-smoke-arm32.log
+  dependencies:
+- debian-unstable-gcc-arm32
+- qemu-system-aarch64-6.0.0-arm32-export
+  artifacts:
+paths:
+  - smoke.serial
+  - '*.log'
+when: always
+  tags:
+- arm64
+  except:
+- master
+- smoke
+- /^coverity-tested\/.*/
+- /^stable-.*/
+
 qemu-smoke-x86-64-gcc:
   stage: test
   image: registry.gitlab.com/xen-project/xen/${CONTAINER}
diff --git a/automation/scripts/qemu-smoke-arm32.sh 
b/automation/scripts/qemu-smoke-arm32.sh
new file mode 100755
index 00..d554de7939
--- /dev/null
+++ b/automation/scripts/qemu-smoke-arm32.sh
@@ -0,0 +1,81 @@
+#!/bin/bash
+
+set -ex
+
+export DEBIAN_FRONTENT=noninteractive
+apt-get -qy update
+apt-get -qy install --no-install-recommends device-tree-compiler \
+curl \
+cpio
+
+cd binaries
+# Use the kernel from Debian
+curl --fail --silent --show-error --location --output vmlinuz 
http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/netboot/vmlinuz
+# Use a tiny initrd based on busybox from Alpine Linux
+curl --fail --silent --show-error --location --output initrd.tar.gz 
https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/armhf/alpine-minirootfs-3.15.1-armhf.tar.gz
+
+mkdir rootfs
+cd rootfs
+tar xvzf ../initrd.tar.gz
+find . | cpio -H newc -o | gzip > ../initrd.gz
+cd ..
+
+kernel=`stat -L --printf="%s" vmlinuz`
+initrd=`stat -L --printf="%s" initrd.gz`
+
+# For Xen, we need a couple of more node. Dump the DT from QEMU and add them
+# XXX QEMU looks for "efi-virtio.rom" even if it is unneeded
+curl -fsSLO https://github.com/qemu/qemu/raw/v5.2.0/pc-bios/efi-virtio.rom
+./qemu-system-arm \
+   -machine virt-6.0 \
+   -machine virtualization=true \
+   -smp 4 \
+   -m 1024 \
+   -serial stdio \
+   -monitor none \
+   -display none \
+   -machine dumpdtb=virt.dtb
+
+dtc -I dtb -O dts virt.dtb > virt.dts
+
+cat >> virt.dts << EOF
+/ {
+   chosen {
+   #address-cells = <0x2>;
+   #size-cells = <0x2>;
+   stdout-path = "/pl011@900";
+xen,xen-bootargs = "console=dtuart dtuart=/pl011@900 dom0_mem=512M 
bootscrub=0";
+   xen,dom0-bootargs = "console=tty0 console=hvc0 earlyprintk 
clk_ignore_unused root=/dev/ram0 rdinit=/bin/sh init=/bin/sh";
+   dom0 {
+   compatible = "xen,linux-zimage", "xen,multiboot-module";
+   reg = <0x0 0x100 0x0 $kernel>;
+   };
+dom0-ramdisk {
+   compatible = "xen,linux-initrd", "xen,multiboot-module";
+   reg = <0x0 0x320 0x0 $initrd>;
+   };
+   };
+};
+EOF
+dtc -I dts -O dtb virt.dts > virt.dtb
+
+rm -f smoke.serial
+set +e
+timeout -k 1 240 \
+./qemu-system-arm \
+   -machine virt-6.0 \
+   -machine virtualization=true \
+   -smp 4 \
+   -m 1024 \
+   -serial stdio \
+   -monitor none \
+   -display none \
+   -dtb virt.dtb \
+   -no-reboot \
+   -kernel ./xen \
+   -device loader,file=./vmlinuz,addr=0x100 \
+   -device loader,file=./initrd.gz,addr=0x320 |& tee smoke.serial
+
+set -e
+(grep -q "^/ #" smoke.serial) || exit 1
+exit 0
-- 
2.25.1

[PATCH v4 0/2] automation: qemu32 smoke test

[Stefano Stabellini]

Hi all,

This small series adds a simple Xen + Dom0 boot arm32 test to gitlab-ci
using QEMU, similar to the existing tests for arm64 and x86.

Cheers,

Stefano

Stefano Stabellini (2):
  gitlab-ci: add qemu-system-arm to the existing tests-artifacts container
  gitlab-ci: add an ARM32 qemu-based smoke test

 automation/gitlab-ci/build.yaml| 14 +++-
 automation/gitlab-ci/test.yaml | 27 +++-
 automation/scripts/qemu-smoke-arm32.sh | 81 ++
 ...arm64v8.dockerfile => 6.0.0-arm64v8.dockerfile} |  5 +-
 4 files changed, 121 insertions(+), 6 deletions(-)
 create mode 100755 automation/scripts/qemu-smoke-arm32.sh
 rename 
automation/tests-artifacts/qemu-system-aarch64/{5.2.0-arm64v8.dockerfile => 
6.0.0-arm64v8.dockerfile} (95%)

[PATCH v2] xen/arm: set CPSR Z bit when creating aarch32 guests

[Stefano Stabellini]

From: Stefano Stabellini 

The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
kernel, certain versions of Linux will use an UNPREDICATABLE NOP
encoding, sometimes resulting in an unbootable kernel. Whether the
resulting kernel is bootable or not depends on the processor. See commit
a92882a4d270 in the Linux kernel for all the details.

All kernel releases starting from Linux 4.9 without commit a92882a4d270
are affected.

Fortunately there is a simple workaround: setting the "Z" bit in CPSR
make it so those invalid NOP instructions are never executed. That is
because the instruction is conditional (not equal). So, on QEMU at
least, the instruction will end up to be ignored and not generate an
exception. Setting the "Z" bit makes those kernel versions bootable
again and it is harmless in the other cases.

Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- improve commit message
- add in-code comment
- move PSR_Z to the beginning
---
 xen/include/public/arch-arm.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 94b31511dd..81cee95f14 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -361,6 +361,7 @@ typedef uint64_t xen_callback_t;
 #define PSR_DBG_MASK(1<<9)/* arm64: Debug Exception mask */
 #define PSR_IT_MASK (0x0600fc00)  /* Thumb If-Then Mask */
 #define PSR_JAZELLE (1<<24)   /* Jazelle Mode */
+#define PSR_Z   (1<<30)   /* Zero condition flag */
 
 /* 32 bit modes */
 #define PSR_MODE_USR 0x10
@@ -383,7 +384,12 @@ typedef uint64_t xen_callback_t;
 #define PSR_MODE_EL1t 0x04
 #define PSR_MODE_EL0t 0x00
 
-#define PSR_GUEST32_INIT  (PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC)
+/*
+ * We set PSR_Z to be able to boot Linux kernel versions with an invalid
+ * encoding of the first 8 NOP instructions. See commit a92882a4d270 in
+ * Linux.
+ */
+#define PSR_GUEST32_INIT  
(PSR_Z|PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC)
 #define PSR_GUEST64_INIT (PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_EL1h)
 
 #define SCTLR_GUEST_INITxen_mk_ullong(0x00c50078)
-- 
2.25.1

Re: [PATCH v4 08/11] xen: use generated prototypes for hypercall handlers

[Julien Grall]

Hi Juergen,

On 10/03/2022 07:34, Juergen Gross wrote:

Remove the hypercall handler's prototypes in the related header files
and use the generated ones instead.

Some handlers having been static before need to be made globally
visible.

Signed-off-by: Juergen Gross 
Acked-by: Jan Beulich 
---
  xen/arch/arm/include/asm/hypercall.h |   1 -


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v4 07/11] xen: generate hypercall interface related code

[Julien Grall]

Hi Juergen,

On 10/03/2022 07:34, Juergen Gross wrote:

+table: pv32 pv64 hvm32hvm64arm
+set_trap_table compat   do   ---
+mmu_update do:1 do:1 ---
+set_gdtcompat   do   ---
+stack_switch   do:2 do:2 ---
+set_callbacks  compat   do   ---
+fpu_taskswitch do   do   ---
+sched_op_compatdo   do   --dep
+#ifndef CONFIG_PV_SHIM_EXCLUSIVE
+platform_opcompat   do   compat   do   do
+#endif
+set_debugreg   do   do   ---
+get_debugreg   do   do   ---
+update_descriptor  compat   do   ---
+memory_op  compat   do   hvm  hvm  do
+multicall  compat:2 do:2 compat   do   do
+update_va_mapping  compat   do   ---
+set_timer_op   compat   do   compat   do   -
+event_channel_op_compatdo   do   --dep
+xen_versioncompat   do   compat   do   do
+console_io do   do   do   do   do
+physdev_op_compat  compat   do   --dep
+#if defined(CONFIG_GRANT_TABLE) || defined(CONFIG_PV_SHIM)
+grant_table_op compat   do   hvm  hvm  do
+#endif
+vm_assist  do   do   do   do   do
+update_va_mapping_otherdomain  compat   do   ---
+iret   compat:1 do:1 ---
+vcpu_opcompat   do   compat:1 do:1 do
+set_segment_base   do:2 do:2 ---
+#ifdef CONFIG_PV
+mmuext_op  compat:2 do:2 compat   do   -
+#endif
+xsm_op compat   do   compat   do   do
+nmi_op compat   do   ---
+sched_op   compat   do   compat   do   do
+callback_opcompat   do   ---
+#ifdef CONFIG_XENOPROF
+xenoprof_opcompat   do   ---
+#endif
+event_channel_op   do   do   do:1 do:1 do


On Arm, I expect this hypercall to be the most used one. So I would 
suggest to add ':1'.


Other than that the column for Arm looks good to me:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v4 05/11] xen: don't include asm/hypercall.h from C sources

[Julien Grall]

Hi Juergen,

On 10/03/2022 07:34, Juergen Gross wrote:

Instead of including asm/hypercall.h always use xen/hypercall.h.
Additionally include xen/hypercall.h from all sources containing a
hypercall handler.

This prepares for generating the handlers' prototypes at build time.

Add a guard in asm/hypercall.h to catch direct inclusion.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 


For Arm:

Acked-by: Julien Grall  # arm

Cheers,

--
Julien Grall

Re: [PATCH v4 02/11] xen: move do_vcpu_op() to arch specific code

[Julien Grall]

Hi Juergen,

On 10/03/2022 07:34, Juergen Gross wrote:

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 351029f8b2..f9de1be43c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1570,15 +1570,11 @@ int default_initialise_vcpu(struct vcpu *v, 
XEN_GUEST_HANDLE_PARAM(void) arg)
  return rc;
  }
  
-long cf_check do_vcpu_op(

-int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
+long common_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
  {
-struct domain *d = current->domain;
-struct vcpu *v;
  long rc = 0;
-
-if ( (v = domain_vcpu(d, vcpuid)) == NULL )
-return -ENOENT;
+struct domain *d = current->domain;


It feels a bit strange to use current when you already have the vcpu in 
hand. So how about using v->domain?


The rest of the patch looks good to me.

Cheers,

--
Julien Grall

Re: [PATCH v4 01/11] xen/arm: rename do_phydev_op() to do_arm_physdev_op()

[Julien Grall]

Hi Juergen,

On 10/03/2022 07:34, Juergen Gross wrote:

do_physdev_op() prototypes on Arm and x86 differ in their return type,
so rename the Arm one in order to prepare using a common generated
header file.

Signed-off-by: Juergen Gross 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH] xen: fix is_xen_pmu()

[Boris Ostrovsky]

On 3/22/22 11:50 AM, Juergen Gross wrote:

is_xen_pmu() is taking the cpu number as parameter, but it is not using
it. Instead it just tests whether the Xen PMU initialization on the
current cpu did succeed. As this test is done by checking a percpu
pointer, preemption needs to be disabled in order to avoid switching
the cpu while doing the test. While resuming from suspend() this seems
not to be the case:

[   88.082751] ACPI: PM: Low-level resume complete
[   88.087933] ACPI: EC: EC started
[   88.091464] ACPI: PM: Restoring platform NVS memory
[   88.097166] xen_acpi_processor: Uploading Xen processor PM info
[   88.103850] Enabling non-boot CPUs ...
[   88.108128] installing Xen timer for CPU 1
[   88.112763] BUG: using smp_processor_id() in preemptible [] code: 
systemd-sleep/7138
[   88.122256] caller is is_xen_pmu+0x12/0x30
[   88.126937] CPU: 0 PID: 7138 Comm: systemd-sleep Tainted: GW 
5.16.13-2.fc32.qubes.x86_64 #1
[   88.137939] Hardware name: Star Labs StarBook/StarBook, BIOS 7.97 03/21/2022
[   88.145930] Call Trace:
[   88.148757]  
[   88.151193]  dump_stack_lvl+0x48/0x5e
[   88.155381]  check_preemption_disabled+0xde/0xe0
[   88.160641]  is_xen_pmu+0x12/0x30
[   88.164441]  xen_smp_intr_init_pv+0x75/0x100



There is actually another PMU-related problem on restore which was caused (or, 
rather, highlighted) by ff083a2d972f56bebfd82409ca62e5dfce950961:


[  116.861637] [ cut here ]
[  116.861651] WARNING: CPU: 1 PID: 31 at kernel/events/core.c:6614 
perf_register_guest_info_callbacks+0x68/0x70
[  116.861673] Modules linked in:
[  116.861682] CPU: 1 PID: 31 Comm: xenwatch Not tainted 5.17.0-rc7ostr #103
[  116.861695] RIP: e030:perf_register_guest_info_callbacks+0x68/0x70
[  116.861706] Code: c7 c7 40 e1 86 82 e8 d7 e7 ff ff 48 8b 53 10 48 85 d2 74 14 48 
c7 c6 f0 0a c0 81 48 c7 c7 30 e1 86 82 5b e9 ba e7 ff ff 5b c3 <0f> 0b c3 0f 1f 
44 00 00 0f 1f 44 00 00 48 8b 05 54 fd 0b 02 48 39
[  116.861747] RSP: e02b:c9004016fe18 EFLAGS: 00010286
[  116.861758] RAX: 82432850 RBX: 0003 RCX: 888079c0
[  116.861768] RDX: 888079c0 RSI: c9004016fe30 RDI: 82432850
[  116.861778] RBP:  R08: 1600 R09: ea0ed340
[  116.861788] R10: 0758 R11:  R12: 888003b4d000
[  116.861797] R13: 0003 R14: 8162cf10 R15: 
[  116.861819] FS:  () GS:888079c8() 
knlGS:
[  116.861830] CS:  e030 DS:  ES:  CR0: 80050033
[  116.861839] CR2:  CR3: 062b6000 CR4: 00040660
[  116.861853] Call Trace:
[  116.861861]  
[  116.861866]  xen_pmu_init+0x187/0x280
[  116.861879]  xen_arch_resume+0x30/0x50
[  116.861888]  do_suspend.cold+0x132/0x147
[  116.861899]  shutdown_handler+0x12e/0x140
[  116.861910]  xenwatch_thread+0x94/0x180
[  116.861919]  ? finish_wait+0x80/0x80
[  116.861928]  kthread+0xe7/0x110
[  116.861938]  ? kthread_complete_and_exit+0x20/0x20
[  116.861948]  ret_from_fork+0x22/0x30
[  116.861959]  
[  116.861964] ---[ end trace  ]---


I was going to send a patch but I think yours can be slightly modified to take 
care of this problem as well.




@@ -542,6 +539,7 @@ void xen_pmu_init(int cpu)
per_cpu(xenpmu_shared, cpu).flags = 0;
  
  	if (cpu == 0) {



  if (!is_xen_pmu)



+   is_xen_pmu = true;
perf_register_guest_info_callbacks(&xen_guest_cbs);
xen_pmu_arch_init();
}
@@ -572,4 +570,7 @@ void xen_pmu_finish(int cpu)
  
  	free_pages((unsigned long)per_cpu(xenpmu_shared, cpu).xenpmu_data, 0);

per_cpu(xenpmu_shared, cpu).xenpmu_data = NULL;
+
+   if (cpu == 0)
+   is_xen_pmu = false;



And drop this hunk.


-boris

[ovmf test] 168788: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  226 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days7 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

[PATCH 3/3] x86/mem_sharing: make fork_reset more configurable

[Tamas K Lengyel]

Allow specify distinct parts of the fork VM to be reset. This is useful when a
fuzzing operation involves mapping in only a handful of pages that are known
ahead of time. Throwing these pages away just to be re-copied immediately is
expensive, thus allowing to specify partial resets can speed things up.

Also allow resetting to be initiated from vm_event responses as an
optiomization.

Signed-off-by: Tamas K Lengyel 
---
 tools/include/xenctrl.h|  3 ++-
 tools/libs/ctrl/xc_memshr.c|  7 ++-
 xen/arch/x86/include/asm/mem_sharing.h |  9 +
 xen/arch/x86/mm/mem_sharing.c  | 22 +-
 xen/common/vm_event.c  | 14 ++
 xen/include/public/memory.h|  4 +++-
 xen/include/public/vm_event.h  |  8 
 7 files changed, 59 insertions(+), 8 deletions(-)

diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 95bd5eca67..1b089a2c02 100644
--- a/tools/include/xenctrl.h
+++ b/tools/include/xenctrl.h
@@ -2290,7 +2290,8 @@ int xc_memshr_fork(xc_interface *xch,
  *
  * With VMs that have a lot of memory this call may block for a long time.
  */
-int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain);
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain,
+ bool reset_state, bool reset_memory);
 
 /* Debug calls: return the number of pages referencing the shared frame backing
  * the input argument. Should be one or greater.
diff --git a/tools/libs/ctrl/xc_memshr.c b/tools/libs/ctrl/xc_memshr.c
index a6cfd7dccf..a0d0b894e2 100644
--- a/tools/libs/ctrl/xc_memshr.c
+++ b/tools/libs/ctrl/xc_memshr.c
@@ -257,12 +257,17 @@ int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, 
uint32_t domid,
 return xc_memshr_memop(xch, domid, &mso);
 }
 
-int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid)
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid, bool reset_state,
+ bool reset_memory)
 {
 xen_mem_sharing_op_t mso;
 
 memset(&mso, 0, sizeof(mso));
 mso.op = XENMEM_sharing_op_fork_reset;
+if ( reset_state )
+mso.u.fork.flags |= XENMEM_FORK_RESET_STATE;
+if ( reset_memory )
+mso.u.fork.flags |= XENMEM_FORK_RESET_MEMORY;
 
 return xc_memshr_memop(xch, domid, &mso);
 }
diff --git a/xen/arch/x86/include/asm/mem_sharing.h 
b/xen/arch/x86/include/asm/mem_sharing.h
index b4a8e8795a..fca5ec8aeb 100644
--- a/xen/arch/x86/include/asm/mem_sharing.h
+++ b/xen/arch/x86/include/asm/mem_sharing.h
@@ -85,6 +85,9 @@ static inline bool mem_sharing_is_fork(const struct domain *d)
 int mem_sharing_fork_page(struct domain *d, gfn_t gfn,
   bool unsharing);
 
+int mem_sharing_fork_reset(struct domain *d, bool reset_state,
+   bool reset_memory);
+
 /*
  * If called by a foreign domain, possible errors are
  *   -EBUSY -> ring full
@@ -148,6 +151,12 @@ static inline int mem_sharing_fork_page(struct domain *d, 
gfn_t gfn, bool lock)
 return -EOPNOTSUPP;
 }
 
+static inline int mem_sharing_fork_reset(struct domain *d, bool reset_state,
+ bool reset_memory)
+{
+return -EOPNOTSUPP;
+}
+
 #endif
 
 #endif /* __MEM_SHARING_H__ */
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index a21c781452..bfa6082f13 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1892,15 +1892,19 @@ static int fork(struct domain *cd, struct domain *d, 
uint16_t flags)
  * footprints the hypercall continuation should be implemented (or if this
  * feature needs to be become "stable").
  */
-static int mem_sharing_fork_reset(struct domain *d)
+int mem_sharing_fork_reset(struct domain *d, bool reset_state,
+   bool reset_memory)
 {
-int rc;
+int rc = 0;
 struct domain *pd = d->parent;
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 struct page_info *page, *tmp;
 
 domain_pause(d);
 
+if ( !reset_memory )
+goto state;
+
 /* need recursive lock because we will free pages */
 spin_lock_recursive(&d->page_alloc_lock);
 page_list_for_each_safe(page, tmp, &d->page_list)
@@ -1933,7 +1937,9 @@ static int mem_sharing_fork_reset(struct domain *d)
 }
 spin_unlock_recursive(&d->page_alloc_lock);
 
-rc = copy_settings(d, pd, d->arch.hvm.mem_sharing.skip_special_pages);
+ state:
+if ( reset_state )
+rc = copy_settings(d, pd, d->arch.hvm.mem_sharing.skip_special_pages);
 
 domain_unpause(d);
 
@@ -2239,15 +2245,21 @@ int 
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 
 case XENMEM_sharing_op_fork_reset:
 {
+bool reset_state = mso.u.fork.flags & XENMEM_FORK_RESET_STATE;
+bool reset_memory = mso.u.fork.flags & XENMEM_FORK_RESET_MEMORY;
+
 rc = -EINVAL;
-if ( mso.u.fork.pad || mso.u.fork.flags )
+if ( mso.u.fork.pad || (!reset_stat

[PATCH 2/3] x86/mem_sharing: use dom_cow as placeholder parent until fork is complete

[Tamas K Lengyel]

For the duration of the fork memop set dom_cow as a placeholder parent. This
gets updated to the real parent when the fork operation completes, or to NULL
in case the fork failed. Doing this allows us to skip populating the physmap
with any entries until the fork operation successfully completes. Currently
bringing up vCPUs may inadvertantly map in some pages that can turn out to be
unecessary, like the CR3 gfn when paging is disabled.

Signed-off-by: Tamas K Lengyel 
---
 xen/arch/x86/include/asm/mem_sharing.h | 2 +-
 xen/arch/x86/mm/mem_sharing.c  | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/include/asm/mem_sharing.h 
b/xen/arch/x86/include/asm/mem_sharing.h
index cf7a12f4d2..b4a8e8795a 100644
--- a/xen/arch/x86/include/asm/mem_sharing.h
+++ b/xen/arch/x86/include/asm/mem_sharing.h
@@ -79,7 +79,7 @@ static inline int mem_sharing_unshare_page(struct domain *d,
 
 static inline bool mem_sharing_is_fork(const struct domain *d)
 {
-return d->parent;
+return d->parent && d->parent != dom_cow;
 }
 
 int mem_sharing_fork_page(struct domain *d, gfn_t gfn,
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 84c04ddfa3..a21c781452 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1850,7 +1850,9 @@ static int fork(struct domain *cd, struct domain *d, 
uint16_t flags)
 *cd->arch.cpuid = *d->arch.cpuid;
 *cd->arch.msr = *d->arch.msr;
 cd->vmtrace_size = d->vmtrace_size;
-cd->parent = d;
+
+/* use dom_cow as a placeholder until we are all done */
+cd->parent = dom_cow;
 }
 
 /* This is preemptible so it's the first to get done */
@@ -1862,6 +1864,7 @@ static int fork(struct domain *cd, struct domain *d, 
uint16_t flags)
 
 if ( !(rc = copy_settings(cd, d, skip_special_pages)) )
 {
+cd->parent = d;
 cd->arch.hvm.mem_sharing.block_interrupts = block_interrupts;
 cd->arch.hvm.mem_sharing.skip_special_pages = skip_special_pages;
 /* skip mapping the vAPIC page on unpause if skipping special pages */
-- 
2.25.1

[PATCH 1/3] x86/mem_sharing: option to skip populating special pages during fork

[Tamas K Lengyel]

Add option to the fork memop to skip populating the fork with special pages.
These special pages are only necessary when setting up forks to be fully
functional with a toolstack. For short-lived forks where no toolstack is active
these pages are uneccesary.

Signed-off-by: Tamas K Lengyel 
---
 xen/arch/x86/include/asm/hvm/domain.h |  4 +++-
 xen/arch/x86/mm/mem_sharing.c | 33 +--
 xen/include/public/memory.h   |  4 ++--
 3 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/include/asm/hvm/domain.h 
b/xen/arch/x86/include/asm/hvm/domain.h
index 698455444e..446cd06411 100644
--- a/xen/arch/x86/include/asm/hvm/domain.h
+++ b/xen/arch/x86/include/asm/hvm/domain.h
@@ -31,7 +31,9 @@
 #ifdef CONFIG_MEM_SHARING
 struct mem_sharing_domain
 {
-bool enabled, block_interrupts;
+bool enabled;
+bool block_interrupts;
+bool skip_special_pages;
 
 /*
  * When releasing shared gfn's in a preemptible manner, recall where
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 15e6a7ed81..84c04ddfa3 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1643,7 +1643,8 @@ static int bring_up_vcpus(struct domain *cd, struct 
domain *d)
 return 0;
 }
 
-static int copy_vcpu_settings(struct domain *cd, const struct domain *d)
+static int copy_vcpu_settings(struct domain *cd, const struct domain *d,
+  bool skip_special_pages)
 {
 unsigned int i;
 struct p2m_domain *p2m = p2m_get_hostp2m(cd);
@@ -1660,7 +1661,7 @@ static int copy_vcpu_settings(struct domain *cd, const 
struct domain *d)
 
 /* Copy & map in the vcpu_info page if the guest uses one */
 vcpu_info_mfn = d_vcpu->vcpu_info_mfn;
-if ( !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
+if ( !skip_special_pages && !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
 {
 mfn_t new_vcpu_info_mfn = cd_vcpu->vcpu_info_mfn;
 
@@ -1807,17 +1808,18 @@ static int copy_special_pages(struct domain *cd, struct 
domain *d)
 return 0;
 }
 
-static int copy_settings(struct domain *cd, struct domain *d)
+static int copy_settings(struct domain *cd, struct domain *d,
+ bool skip_special_pages)
 {
 int rc;
 
-if ( (rc = copy_vcpu_settings(cd, d)) )
+if ( (rc = copy_vcpu_settings(cd, d, skip_special_pages)) )
 return rc;
 
 if ( (rc = hvm_copy_context_and_params(cd, d)) )
 return rc;
 
-if ( (rc = copy_special_pages(cd, d)) )
+if ( !skip_special_pages && (rc = copy_special_pages(cd, d)) )
 return rc;
 
 copy_tsc(cd, d);
@@ -1826,9 +1828,11 @@ static int copy_settings(struct domain *cd, struct 
domain *d)
 return rc;
 }
 
-static int fork(struct domain *cd, struct domain *d)
+static int fork(struct domain *cd, struct domain *d, uint16_t flags)
 {
 int rc = -EBUSY;
+bool block_interrupts = flags & XENMEM_FORK_BLOCK_INTERRUPTS;
+bool skip_special_pages = flags & XENMEM_FORK_SKIP_SPECIAL_PAGES;
 
 if ( !cd->controller_pause_count )
 return rc;
@@ -1856,7 +1860,13 @@ static int fork(struct domain *cd, struct domain *d)
 if ( (rc = bring_up_vcpus(cd, d)) )
 goto done;
 
-rc = copy_settings(cd, d);
+if ( !(rc = copy_settings(cd, d, skip_special_pages)) )
+{
+cd->arch.hvm.mem_sharing.block_interrupts = block_interrupts;
+cd->arch.hvm.mem_sharing.skip_special_pages = skip_special_pages;
+/* skip mapping the vAPIC page on unpause if skipping special pages */
+cd->creation_finished = skip_special_pages;
+}
 
  done:
 if ( rc && rc != -ERESTART )
@@ -1920,7 +1930,7 @@ static int mem_sharing_fork_reset(struct domain *d)
 }
 spin_unlock_recursive(&d->page_alloc_lock);
 
-rc = copy_settings(d, pd);
+rc = copy_settings(d, pd, d->arch.hvm.mem_sharing.skip_special_pages);
 
 domain_unpause(d);
 
@@ -2190,7 +2200,8 @@ int 
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 if ( mso.u.fork.pad )
 goto out;
 if ( mso.u.fork.flags &
- ~(XENMEM_FORK_WITH_IOMMU_ALLOWED | XENMEM_FORK_BLOCK_INTERRUPTS) )
+ ~(XENMEM_FORK_WITH_IOMMU_ALLOWED | XENMEM_FORK_BLOCK_INTERRUPTS |
+   XENMEM_FORK_SKIP_SPECIAL_PAGES) )
 goto out;
 
 rc = rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_domain,
@@ -2212,14 +2223,12 @@ int 
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 goto out;
 }
 
-rc = fork(d, pd);
+rc = fork(d, pd, mso.u.fork.flags);
 
 if ( rc == -ERESTART )
 rc = hypercall_create_continuation(__HYPERVISOR_memory_op,
"lh", XENMEM_sharing_op,
arg);
-else if ( !rc && (mso.u.fork.flags & XENMEM_FORK_BLOCK_INTERRUPTS) )
-d->arch.hvm.mem_sha

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Stefano Stabellini]

On Tue, 22 Mar 2022, Luca Fancellu wrote:
> >> +- cpupool-sched (optional)
> >> +
> >> +Must be a string having the name of a Xen scheduler, it has no effect 
> >> when
> >> +used in conjunction of a cpupool-id equal to zero, in that case the
> >> +default Xen scheduler is selected (sched=<...> boot argument).
> >> +Check the sched=<...> boot argument for allowed values.
> > 
> > I am happy with this version of the device tree bindings, thanks for
> > your efforts to update them. Only one comment left: please update the
> > description not to include "cpupool-id" given that there is no
> > cpupool-id property anymore :-)
> > 
> 
> Hi Stefano,
> 
> Thank you for your review,
> 
> Yes I missed that! I will fix in the next serie.
> 
> >> 
> >> +/*
> >> + * pool_cpu_map:   Index is logical cpu number, content is cpupool id, 
> >> (-1) for
> >> + * unassigned.
> >> + * pool_sched_map: Index is cpupool id, content is scheduler id, (-1) for
> >> + * unassigned.
> >> + */
> >> +static int __initdata pool_cpu_map[NR_CPUS]   = { [0 ... NR_CPUS-1] = -1 
> >> };
> >> +static int __initdata pool_sched_map[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 
> >> };
> >> +static unsigned int __initdata next_pool_id;
> >> +
> >> +#ifdef CONFIG_HAS_DEVICE_TREE
> > 
> > BOOT_TIME_CPUPOOLS depends on HAS_DEVICE_TREE, so it is not possible to
> > have BOOT_TIME_CPUPOOLS but not HAS_DEVICE_TREE ?
> 
> Yes you are right, the ifdef is not needed at this stage since only arch with 
> device tree are
> using it, if x86 would like to implement a command line version then the code 
> will be ifdef-ined
> later.
> 
> > 
> > 
> >> +#define BTCPUPOOLS_DT_NODE_NO_REG (-1)
> >> +#define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
> >> +
> >> +static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
> >> +{
> >> +unsigned int i;
> >> +
> >> +for ( i = 0; i < nr_cpu_ids; i++ )
> >> +if ( cpu_physical_id(i) == hwid )
> >> +return i;
> >> +
> >> +return -1;
> >> +}
> > 
> > I wonder if there is a better way to implement this function but I am
> > not sure. Also, it might be better to avoid premature optimizations.
> > 
> > That said, we could check first the simple case where hwid==i. Looking
> > at various existing device tree, it seems to be the most common case.
> > 
> > This is not a requirement, just a hand-wavy suggestion. I think the
> > patch is also OK as is.
> > 
> 
> Not sure to understand here, at least on FVP (the first DT I have around), 
> hwid != i,
> Or maybe I didn’t understand what you mean

I am not surprised. In many boards hwid == i, but it is not a guarantee
at all.

To be honest mine was not really a concrete suggestion, more like the
beginning of a discussion on the subject. The goal would be to avoid
having to scan the __cpu_logical_map array every time without adding a
second data structure. I don't feel strongly about it but I thought I
would mention it anyway just in case you (or someone else) gets a better
idea on how to do this.

Re: [PATCH v3 5/6] arm/dom0less: assign dom0less guests to cpupools

[Luca Fancellu]

+ maintainer golang, libs, ocaml, python bindings

> On 18 Mar 2022, at 16:18, Julien Grall  wrote:
> 
> Hi,
> 
> On 18/03/2022 15:25, Luca Fancellu wrote:
>> Introduce domain-cpupool property of a xen,domain device tree node,
>> that specifies the cpupool device tree handle of a xen,cpupool node
>> that identifies a cpupool created at boot time where the guest will
>> be assigned on creation.
>> Add member to the xen_domctl_createdomain public interface so the
>> XEN_DOMCTL_INTERFACE_VERSION version is bumped.
>> Add public function to retrieve a pool id from the device tree
>> cpupool node.
>> Update documentation about the property.
>> Signed-off-by: Luca Fancellu 
>> ---
>> Changes in v3:
>> - Use explicitely sized integer for struct xen_domctl_createdomain
>>   cpupool_id member. (Stefano)
>> - Changed code due to previous commit code changes
>> Changes in v2:
>> - Moved cpupool_id from arch specific to common part (Juergen)
>> - Implemented functions to retrieve the cpupool id from the
>>   cpupool dtb node.
>> ---
>>  docs/misc/arm/device-tree/booting.txt |  5 +
>>  xen/arch/arm/domain_build.c   | 14 +-
>>  xen/common/boot_cpupools.c| 24 
>>  xen/common/domain.c   |  2 +-
>>  xen/include/public/domctl.h   |  4 +++-
>>  xen/include/xen/sched.h   |  9 +
> 
> This patch doesn't seem to contain any change in tools. So...
> 
>>  if ( (err = late_hwdom_init(d)) != 0 )
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index b85e6170b0aa..2f4cf56f438d 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -38,7 +38,7 @@
>>  #include "hvm/save.h"
>>  #include "memory.h"
>>  -#define XEN_DOMCTL_INTERFACE_VERSION 0x0014
>> +#define XEN_DOMCTL_INTERFACE_VERSION 0x0015
>>/*
>>   * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
>> @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
>>  /* Per-vCPU buffer size in bytes.  0 to disable. */
>>  uint32_t vmtrace_size;
>>  +uint32_t cpupool_id;
> 
> ... will the tools (e.g. golang bindings, libxl,..) always zero 
> xen_domctl_createdomain?
> 
> I also think we may need to regenerate the golang bindings.

I’ve checked the occurrences of struct xen_domctl_createdomain in tools/ and I 
see it is
always initialised using designated initializers so (correct me if I’m wrong) 
any non specified
field should be zero.

I tried to check if I need and how to regenerate the golang bindings, I didn’t 
find documentation
to do that, I’ve added some maintainer to this reply that hopefully can help me 
to understand
If I’ve missed something in this patch modifying struct xen_domctl_createdomain.

Cheers,
Luca

> 
> Cheers,
> 
> -- 
> Julien Grall

[ovmf test] 168785: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  225 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days6 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

Re: [PATCH v11 3/3] xen/arm64: io: Handle data abort due to cache maintenance instructions

[Julien Grall]

Hi,

On 22/03/2022 16:16, Ayan Kumar Halder wrote:

On 22/03/2022 13:22, Julien Grall wrote:
Furthermore, I think try_fwd_ioserv() need to be adapted because the 
function will use the fields SAS and SRT. From the Arm Arm they are 
RES0, so while they are 0 today, we should not rely on this.


Therefore, to be fully compliant with the Arm, we want to reorder a 
bit the code:


 * The field data could be set past ioreq_select_server().
 * The field size should be set to the cache line size.


I am assuming that we need to invoke  dcache_line_size() (from 
xen/arch/arm/arm64/cache.S ) to get the cache line size.


You would want to use dcache_line_bytes.



I think the cache line may be 32 or 64 bytes. In which case, this cannot 
be represented by SAS (as it can represent 1, 2, 4 and 8 bytes).


You are correct that this cannot be represented by SAS. However, I was 
referring to the field 'size' in the ioreq structure. It is a 32-bit 
integer and could therefore represent the size of the cache line.




Also, we are invoking ioreq_select_server() to determine if the address 
is emulated or not. So, can we use an assumed size (= 1 byte) ?


I thought about this. This is technically incorrect but would be OK if 
we cannot find the correct size.


Per above, I think the correct size could be found.

Cheers,

--
Julien Grall

[linux-linus test] 168768: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl 22 guest-start/debian.repeat fail REGR. vs. 168760

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd  12 debian-di-install   fail pass in 168782-retest

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate   fail REGR. vs. 168760

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

version targeted for testing:
 linuxb47d5a4f6b8d42f8a8fbe891b36215e4fddc53be
baseline version:
 linuxeaa54b1458ca84092e513d554dd6d234245e6bef

Last test of basis   168760  2022-03-21 19:41:16 Z0 days
Testing same since   168768  2022-03-2

Re: [PATCH v11 3/3] xen/arm64: io: Handle data abort due to cache maintenance instructions

[Ayan Kumar Halder]

Hi Julien,

On 22/03/2022 13:22, Julien Grall wrote:

Hi Ayan,

On 22/03/2022 12:38, Ayan Kumar Halder wrote:


On 22/03/2022 12:06, Ayan Kumar Halder wrote:


On 18/03/2022 18:26, Julien Grall wrote:

Hi Ayan,

Hi Julien,


On 17/03/2022 14:00, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/include/asm/mmio.h 
b/xen/arch/arm/include/asm/mmio.h

index ca259a79c2..79e64d9af8 100644
--- a/xen/arch/arm/include/asm/mmio.h
+++ b/xen/arch/arm/include/asm/mmio.h
@@ -35,6 +35,7 @@ enum instr_decode_state
   * instruction.
   */
  INSTR_LDR_STR_POSTINDEXING,
+    INSTR_CACHE,    /* Cache Maintenance instr */
  };
    typedef struct
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 6f458ee7fd..26c716b4a5 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -139,6 +139,17 @@ void try_decode_instruction(const struct 
cpu_user_regs *regs,

  return;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance, 
Xen should check
+ * if the address belongs to an emulated MMIO region or not. 
The behavior

+ * will differ accordingly.
+ */
+    if ( info->dabt.cache )
+    {
+    info->dabt_instr.state = INSTR_CACHE;
+    return;
+    }
+
  /*
   * Armv8 processor does not provide a valid syndrome for 
decoding some
   * instructions. So in order to process these instructions, 
Xen must
@@ -177,6 +188,13 @@ enum io_state try_handle_mmio(struct 
cpu_user_regs *regs,

  return rc;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance and 
the address
+ * belongs to an emulated region, Xen should ignore this 
instruction.

+ */
+    if ( info->dabt_instr.state == INSTR_CACHE )


Reading the Arm Arm, the ISS should be invalid for cache 
instructions. So, I think the check at the beginning of 
try_handle_mmio() would prevent us to reach this check.


Can you check that cache instructions on emulated region will 
effectively be ignored?


Yes, you are correct.

I tested with the following (dis)assembly snippet :-

0x3001000 is the base address of GIC Distributor base.

    __asm__ __volatile__("ldr x1, =0x3001000");
    4ca8:   58000301    ldr x1, 4d08 
    __asm __volatile__("DC CVAU, x1");
    4cac:   d50b7b21    dc  cvau, x1

This resulting in hitting the assertion :-

(XEN) Assertion 'unreachable' failed at arch/arm/io.c:178

I dumped the registers as follows, to determine that the fault is 
caused by the instruction at 4cac.


HSR=0x0092000147  regs->pc = 0x4cac info.gpa = 0x3001000


So, my patch needs to be modified as follows:-

@@ -172,7 +173,7 @@ enum io_state try_handle_mmio(struct 
cpu_user_regs *regs,


 ASSERT(info->dabt.ec == HSR_EC_DATA_ABORT_LOWER_EL);

-    if ( !info->dabt.valid )
+    if ( !(info->dabt.valid || (info->dabt_instr.state == 
INSTR_CACHE)) )


Actually this is not needed.

The following change is sufficient :-

@@ -146,7 +146,9 @@ void try_decode_instruction(const struct 
cpu_user_regs *regs,

   */
  if ( info->dabt.cache )
  {
  info->dabt_instr.state = INSTR_CACHE;
+    info->dabt.valid = 1;


To me, 'info->dabt.valid' indicates whether the syndrome is valid. We 
set to 1 for emulated instruction because the syndrome will be updated.


But this is not the case for the cache instructions. So I would prefer 
if it is kept as 0 and use your previous suggestion.


Furthermore, I think try_fwd_ioserv() need to be adapted because the 
function will use the fields SAS and SRT. From the Arm Arm they are 
RES0, so while they are 0 today, we should not rely on this.


Therefore, to be fully compliant with the Arm, we want to reorder a 
bit the code:


 * The field data could be set past ioreq_select_server().
 * The field size should be set to the cache line size.


I am assuming that we need to invoke  dcache_line_size() (from 
xen/arch/arm/arm64/cache.S ) to get the cache line size.


I think the cache line may be 32 or 64 bytes. In which case, this cannot 
be represented by SAS (as it can represent 1, 2, 4 and 8 bytes).


Also, we are invoking ioreq_select_server() to determine if the address 
is emulated or not. So, can we use an assumed size (= 1 byte) ?


If it is emulated, Xen will ignore the instruction. If it is not 
emulated, Xen will forward the abort to the guest.


Thus, Xen will never execute the instruction. So the correctness of the 
size should not matter here.


- Ayan



Cheers,

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

[osstest service owner]

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

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  69e46280937526db9cf78259cd8a0a9ec62dc847
baseline version:
 xen  8aa0e9d2d1a4815516607eabe9b2e850f284a2f8

Last test of basis   168750  2022-03-21 12:00:27 Z1 days
Testing same since   168778  2022-03-22 13:03:05 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 

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
   8aa0e9d2d1..69e4628093  69e46280937526db9cf78259cd8a0a9ec62dc847 -> smoke

Re: [PATCH v4 07/11] xen: generate hypercall interface related code

[Juergen Gross]

On 22.03.22 16:31, Anthony PERARD wrote:

On Thu, Mar 10, 2022 at 08:34:16AM +0100, Juergen Gross wrote:

diff --git a/xen/include/Makefile b/xen/include/Makefile
index a3c2511f5f..b52a2da40c 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -77,6 +77,18 @@ $(obj)/compat/xlat.h: $(addprefix 
$(obj)/compat/.xlat/,$(xlat-y)) $(obj)/config/
cat $(filter %.h,$^) >$@.new
mv -f $@.new $@
  
+quiet_cmd_genhyp = GEN $@

+define cmd_genhyp
+awk -f $(src)/../scripts/gen_hypercall.awk <$< >$@


You should use "$(srctree)" instead of "$(src)/..".

$(srctree) always point to the source tree of the hypervisor. ( $(src)
doesn't necessarily point to "include/" in the source tree. )


Okay.




+endef
+
+all: $(obj)/xen/hypercall-defs.h
+
+$(obj)/xen/hypercall-defs.h: $(obj)/hypercall-defs.i 
$(src)/../scripts/gen_hypercall.awk FORCE


Here as well, it would be better to use $(srctree) instead of $(src)/.. .


Thanks,


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[PATCH] xen: fix is_xen_pmu()

[Juergen Gross]

is_xen_pmu() is taking the cpu number as parameter, but it is not using
it. Instead it just tests whether the Xen PMU initialization on the
current cpu did succeed. As this test is done by checking a percpu
pointer, preemption needs to be disabled in order to avoid switching
the cpu while doing the test. While resuming from suspend() this seems
not to be the case:

[   88.082751] ACPI: PM: Low-level resume complete
[   88.087933] ACPI: EC: EC started
[   88.091464] ACPI: PM: Restoring platform NVS memory
[   88.097166] xen_acpi_processor: Uploading Xen processor PM info
[   88.103850] Enabling non-boot CPUs ...
[   88.108128] installing Xen timer for CPU 1
[   88.112763] BUG: using smp_processor_id() in preemptible [] code: 
systemd-sleep/7138
[   88.122256] caller is is_xen_pmu+0x12/0x30
[   88.126937] CPU: 0 PID: 7138 Comm: systemd-sleep Tainted: GW 
5.16.13-2.fc32.qubes.x86_64 #1
[   88.137939] Hardware name: Star Labs StarBook/StarBook, BIOS 7.97 03/21/2022
[   88.145930] Call Trace:
[   88.148757]  
[   88.151193]  dump_stack_lvl+0x48/0x5e
[   88.155381]  check_preemption_disabled+0xde/0xe0
[   88.160641]  is_xen_pmu+0x12/0x30
[   88.164441]  xen_smp_intr_init_pv+0x75/0x100

Fix that by replacing is_xen_pmu() by a simple boolean variable which
reflects the Xen PMU initialization state on cpu 0.

Modify xen_pmu_init() to return early in case it is being called for a
cpu other than cpu 0 and the boolean variable not being set.

Fixes: bf6dfb154d93 ("xen/PMU: PMU emulation code")
Reported-by: Marek Marczykowski-Górecki 
Signed-off-by: Juergen Gross 
---
 arch/x86/xen/pmu.c| 11 ++-
 arch/x86/xen/pmu.h|  3 ++-
 arch/x86/xen/smp_pv.c |  2 +-
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index 89dd6b1708b0..0efe452eb13e 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -506,10 +506,7 @@ irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id)
return ret;
 }
 
-bool is_xen_pmu(int cpu)
-{
-   return (get_xenpmu_data() != NULL);
-}
+bool is_xen_pmu;
 
 void xen_pmu_init(int cpu)
 {
@@ -520,7 +517,7 @@ void xen_pmu_init(int cpu)
 
BUILD_BUG_ON(sizeof(struct xen_pmu_data) > PAGE_SIZE);
 
-   if (xen_hvm_domain())
+   if (xen_hvm_domain() || (cpu != 0 && !is_xen_pmu))
return;
 
xenpmu_data = (struct xen_pmu_data *)get_zeroed_page(GFP_KERNEL);
@@ -542,6 +539,7 @@ void xen_pmu_init(int cpu)
per_cpu(xenpmu_shared, cpu).flags = 0;
 
if (cpu == 0) {
+   is_xen_pmu = true;
perf_register_guest_info_callbacks(&xen_guest_cbs);
xen_pmu_arch_init();
}
@@ -572,4 +570,7 @@ void xen_pmu_finish(int cpu)
 
free_pages((unsigned long)per_cpu(xenpmu_shared, cpu).xenpmu_data, 0);
per_cpu(xenpmu_shared, cpu).xenpmu_data = NULL;
+
+   if (cpu == 0)
+   is_xen_pmu = false;
 }
diff --git a/arch/x86/xen/pmu.h b/arch/x86/xen/pmu.h
index 0e83a160589b..65c58894fc79 100644
--- a/arch/x86/xen/pmu.h
+++ b/arch/x86/xen/pmu.h
@@ -4,6 +4,8 @@
 
 #include 
 
+extern bool is_xen_pmu;
+
 irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id);
 #ifdef CONFIG_XEN_HAVE_VPMU
 void xen_pmu_init(int cpu);
@@ -12,7 +14,6 @@ void xen_pmu_finish(int cpu);
 static inline void xen_pmu_init(int cpu) {}
 static inline void xen_pmu_finish(int cpu) {}
 #endif
-bool is_xen_pmu(int cpu);
 bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err);
 bool pmu_msr_write(unsigned int msr, uint32_t low, uint32_t high, int *err);
 int pmu_apic_update(uint32_t reg);
diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 4a6019238ee7..688aa8b6ae29 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -129,7 +129,7 @@ int xen_smp_intr_init_pv(unsigned int cpu)
per_cpu(xen_irq_work, cpu).irq = rc;
per_cpu(xen_irq_work, cpu).name = callfunc_name;
 
-   if (is_xen_pmu(cpu)) {
+   if (is_xen_pmu) {
pmu_name = kasprintf(GFP_KERNEL, "pmu%d", cpu);
rc = bind_virq_to_irqhandler(VIRQ_XENPMU, cpu,
 xen_pmu_irq_handler,
-- 
2.34.1

[ovmf test] 168783: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  224 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days5 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

Re: [PATCH v4 07/11] xen: generate hypercall interface related code

[Anthony PERARD]

On Thu, Mar 10, 2022 at 08:34:16AM +0100, Juergen Gross wrote:
> diff --git a/xen/include/Makefile b/xen/include/Makefile
> index a3c2511f5f..b52a2da40c 100644
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -77,6 +77,18 @@ $(obj)/compat/xlat.h: $(addprefix 
> $(obj)/compat/.xlat/,$(xlat-y)) $(obj)/config/
>   cat $(filter %.h,$^) >$@.new
>   mv -f $@.new $@
>  
> +quiet_cmd_genhyp = GEN $@
> +define cmd_genhyp
> +awk -f $(src)/../scripts/gen_hypercall.awk <$< >$@

You should use "$(srctree)" instead of "$(src)/..".

$(srctree) always point to the source tree of the hypervisor. ( $(src)
doesn't necessarily point to "include/" in the source tree. )

> +endef
> +
> +all: $(obj)/xen/hypercall-defs.h
> +
> +$(obj)/xen/hypercall-defs.h: $(obj)/hypercall-defs.i 
> $(src)/../scripts/gen_hypercall.awk FORCE

Here as well, it would be better to use $(srctree) instead of $(src)/.. .


> + $(call if_changed,genhyp)
> +
> +targets += xen/hypercall-defs.h
> +
>  ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
>  
>  all: $(obj)/headers.chk $(obj)/headers99.chk $(obj)/headers++.chk

Cheers,

-- 
Anthony PERARD

Re: [PATCH v4] x86/vmx: save guest non-register state in hvm_hw_cpu

[Tamas K Lengyel]

On Tue, Mar 22, 2022 at 11:11 AM Andrew Cooper
 wrote:
>
> On 21/03/2022 21:12, Tamas K Lengyel wrote:
> > During VM forking and resetting a failed vmentry has been observed due
> > to the guest non-register state going out-of-sync with the guest register
> > state. For example, a VM fork reset right after a STI instruction can 
> > trigger
> > the failed entry. This is due to the guest non-register state not being 
> > saved
> > from the parent VM, thus the reset operation only copies the register state.
> >
> > Fix this by including the guest non-register state in hvm_hw_cpu so that 
> > when
> > its copied from the parent VM the vCPU state remains in sync.
> >
> > SVM is not currently wired-in as VM forking is VMX only and saving 
> > non-register
> > state during normal save/restore/migration operation hasn't been needed. If
> > deemed necessary in the future it can be wired in by adding a 
> > svm-substructure
> > to hvm_hw_cpu.
>
> I disagree here.  This bug isn't really to do with fuzzing; it's to do
> with our APIs being able to get/set vCPU state correctly, and fuzzing is
> the example which demonstrated the breakage.
>
> This will also cause very subtle bugs for the guest-transparent
> migration work, and the live update work, both of which want to shift
> vcpu state behind a VM which hasn't actively entered Xen via hypercall.
>
> (Quick tangent.  Seriously, can the SDM be fixed so it actually
> enumerates the Activity States.)
>
> Xen doesn't currently support any situation where Intel's idea of
> Activity State is anything other than 0.  This in turn is buggy, because
> we don't encode VPF_blocked anywhere.  An activity state of hlt might
> not be best place to encode this, because notably absent from Intel's
> activity state is mwait.  We'll also terminate things like schedop_poll
> early.
>
> Next, AMD does have various fields from interruptibility.  If you want
> me to write the patch then fine, but they should not be excluded from a
> patch like this.  AMD do not have separate bits for STI and MovSS, due
> to microarchitectural differences, but the single INTERRUPT_SHADOW bit
> does need managing, as does the blocked-by-NMI bit which is emulated on
> SVM and older Intel CPUs.
>
> Minor tangent, blocked-by-SMI needs cross-linking with vm-entry
> controls, so I'm not sure it is something we ought to expose.
>
> Next, it turns out that MSR_DEBUGCTL isn't included anywhere (not even
> the MSR list).  It is important, because it forms part of the VMEntry
> cross-check with PENDING_DBG and TF.
>
> Next, we also don't preserve PDPTRs.  This is another area where Intel
> and AMD CPUs behave differently, but under Intel's architecture, the
> guest kernel can clobber the 32bit PAE block of pointers and everything
> will function correctly until the next mov into cr3.  There are
> definitely bugs in Xen's emulated pagewalk in this area.
>
> So there are a lot of errors with hvm_hw_cpu and I bet I haven't found
> them all.
>
> As discussed at multiple previous XenSummits, the current load/save mess
> needs moving out of Xen, and that would be the correct time to fix the
> other errors, but it probably is too much for this case.
>
>
> At a minimum, there shouldn't be a VMX specific union, because we are
> talking about architecture-agnostic properties of the vCPU.  It's fine
> for the format to follow Intel's bit layout for the subset of bits we
> tolerate saving/restoring, but this needs discussing in the header, and
> needs rejecting on set.  An extra check/reject is 0% overhead for
> forking, so I don't find that a credible argument against doing it.

Sure, during the fork itself it's negligible. It's during fork_reset,
which we do thousands of times per second where that sanity checking
is both unneeded (we know the setting is getting copied from the
parent) and will quickly add up if we need to do a bunch of bitshifts
to ensure only the valid bits are restored (plus converted in case the
format will be the non-vmx version).

> I'm not sure if we want to include the activity state at the moment
> without a better idea of how to encode VPF_blocked, but I think DEBUGCTL
> does need including.  This in turn involves transmitting the LBR MSRs too.

I don't really have much to add here. If there are concerns in regards
to the side-effect of this on the pre-existing save/restore/migration
route then what I can do is add only a Xen-internal function that will
allow the fork_reset to copy the non-register state from the parent
and not expose it via the public header. That works for me just as
well, my use-case doesn't have a requirement for these bits to be
exposed externally.

Tamas

[PATCH] build: provide and export ADDR2LINE

[Jan Beulich]

Now that x86'es check-endbr.sh script uses it, also make it available
consistently with other tool chain components.

Signed-off-by: Jan Beulich 

--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -10,6 +10,7 @@ endif
 LD_LTO = $(CROSS_COMPILE)ld
 endif
 CPP= $(CC) -E
+ADDR2LINE  = $(CROSS_COMPILE)addr2line
 AR = $(CROSS_COMPILE)ar
 RANLIB = $(CROSS_COMPILE)ranlib
 NM = $(CROSS_COMPILE)nm
--- a/config/SunOS.mk
+++ b/config/SunOS.mk
@@ -3,6 +3,7 @@ LD = $(CROSS_COMPILE)gld
 CC = $(CROSS_COMPILE)gcc
 CPP= $(CROSS_COMPILE)gcc -E
 CXX= $(CROSS_COMPILE)g++
+ADDR2LINE  = $(CROSS_COMPILE)gaddr2line
 AR = $(CROSS_COMPILE)gar
 RANLIB = $(CROSS_COMPILE)granlib
 NM = $(CROSS_COMPILE)gnm
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -55,7 +55,7 @@ export TARGET_ARCH := $(shell echo $
 # Allow someone to change their config file
 export KCONFIG_CONFIG ?= .config
 
-export CC CXX LD NM OBJCOPY OBJDUMP
+export CC CXX LD NM OBJCOPY OBJDUMP ADDR2LINE
 
 export TARGET := xen
 

[qemu-mainline test] 168765: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  8 xen-boot fail REGR. vs. 168712

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

version targeted for testing:
 qemuu330724977b10f5b92610817e8b7d1dfed122df87
baseline version:
 qemuu2058fdbe81e2985c226a026851dd26b146d3395c

Last test of basis   168712  2022-03-19 20:39:34 Z2 days
Failing since168756  2022-03-21 15:38:09 Z0 days2 attempts
Testing same since   168765  2022-03-22 02:38:15 Z0 days1 attempts


People who touched revisions under test

Re: [PATCH v4] x86/vmx: save guest non-register state in hvm_hw_cpu

[Andrew Cooper]

On 21/03/2022 21:12, Tamas K Lengyel wrote:
> During VM forking and resetting a failed vmentry has been observed due
> to the guest non-register state going out-of-sync with the guest register
> state. For example, a VM fork reset right after a STI instruction can trigger
> the failed entry. This is due to the guest non-register state not being saved
> from the parent VM, thus the reset operation only copies the register state.
>
> Fix this by including the guest non-register state in hvm_hw_cpu so that when
> its copied from the parent VM the vCPU state remains in sync.
>
> SVM is not currently wired-in as VM forking is VMX only and saving 
> non-register
> state during normal save/restore/migration operation hasn't been needed. If
> deemed necessary in the future it can be wired in by adding a svm-substructure
> to hvm_hw_cpu.

I disagree here.  This bug isn't really to do with fuzzing; it's to do
with our APIs being able to get/set vCPU state correctly, and fuzzing is
the example which demonstrated the breakage.

This will also cause very subtle bugs for the guest-transparent
migration work, and the live update work, both of which want to shift
vcpu state behind a VM which hasn't actively entered Xen via hypercall.

(Quick tangent.  Seriously, can the SDM be fixed so it actually
enumerates the Activity States.)

Xen doesn't currently support any situation where Intel's idea of
Activity State is anything other than 0.  This in turn is buggy, because
we don't encode VPF_blocked anywhere.  An activity state of hlt might
not be best place to encode this, because notably absent from Intel's
activity state is mwait.  We'll also terminate things like schedop_poll
early.

Next, AMD does have various fields from interruptibility.  If you want
me to write the patch then fine, but they should not be excluded from a
patch like this.  AMD do not have separate bits for STI and MovSS, due
to microarchitectural differences, but the single INTERRUPT_SHADOW bit
does need managing, as does the blocked-by-NMI bit which is emulated on
SVM and older Intel CPUs.

Minor tangent, blocked-by-SMI needs cross-linking with vm-entry
controls, so I'm not sure it is something we ought to expose.

Next, it turns out that MSR_DEBUGCTL isn't included anywhere (not even
the MSR list).  It is important, because it forms part of the VMEntry
cross-check with PENDING_DBG and TF.

Next, we also don't preserve PDPTRs.  This is another area where Intel
and AMD CPUs behave differently, but under Intel's architecture, the
guest kernel can clobber the 32bit PAE block of pointers and everything
will function correctly until the next mov into cr3.  There are
definitely bugs in Xen's emulated pagewalk in this area.

So there are a lot of errors with hvm_hw_cpu and I bet I haven't found
them all.

As discussed at multiple previous XenSummits, the current load/save mess
needs moving out of Xen, and that would be the correct time to fix the
other errors, but it probably is too much for this case.


At a minimum, there shouldn't be a VMX specific union, because we are
talking about architecture-agnostic properties of the vCPU.  It's fine
for the format to follow Intel's bit layout for the subset of bits we
tolerate saving/restoring, but this needs discussing in the header, and
needs rejecting on set.  An extra check/reject is 0% overhead for
forking, so I don't find that a credible argument against doing it.

I'm not sure if we want to include the activity state at the moment
without a better idea of how to encode VPF_blocked, but I think DEBUGCTL
does need including.  This in turn involves transmitting the LBR MSRs too.

~Andrew

Re: [PATCH v4 11/11] xen/x86: remove cf_check attribute from hypercall handlers

[Teo Couprie Diaz]

Hello,

On 3/10/22 02:34, Juergen Gross wrote:

Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.

Signed-off-by: Juergen Gross 


Tested-by: Téo Couprie Diaz 

I tested the latest patch series on Armv8 on the FVP and N1SDP platforms. Dom0 
and guests are booting, no issues with networking between guests and dom0: 
everything looks good.
Regards,
Téo

Re: "BUG: using smp_processor_id() in preemptible" on resume from S3

[Marek Marczykowski-Górecki]

On Tue, Mar 22, 2022 at 08:12:53AM +0100, Juergen Gross wrote:
> Hi Marek,
> 
> On 21.03.22 23:26, Marek Marczykowski-Górecki wrote:
> > Hi,
> > 
> > After updating from 5.14.15 dom0 kernel to 5.16.13 I started getting
> > this on resume from S3:
> > 
> > [   88.082751] ACPI: PM: Low-level resume complete
> > [   88.087933] ACPI: EC: EC started
> > [   88.091464] ACPI: PM: Restoring platform NVS memory
> > [   88.097166] xen_acpi_processor: Uploading Xen processor PM info
> > [   88.103850] Enabling non-boot CPUs ...
> > [   88.108128] installing Xen timer for CPU 1
> > [   88.112763] BUG: using smp_processor_id() in preemptible [] 
> > code: systemd-sleep/7138
> > [   88.122256] caller is is_xen_pmu+0x12/0x30
> > [   88.126937] CPU: 0 PID: 7138 Comm: systemd-sleep Tainted: GW 
> > 5.16.13-2.fc32.qubes.x86_64 #1
> > [   88.137939] Hardware name: Star Labs StarBook/StarBook, BIOS 7.97 
> > 03/21/2022
> > [   88.145930] Call Trace:
> > [   88.148757]  
> > [   88.151193]  dump_stack_lvl+0x48/0x5e
> > [   88.155381]  check_preemption_disabled+0xde/0xe0
> > [   88.160641]  is_xen_pmu+0x12/0x30
> > [   88.164441]  xen_smp_intr_init_pv+0x75/0x100
> > [   88.169311]  ? xen_read_cr0+0x20/0x20
> > [   88.173502]  xen_cpu_up_prepare_pv+0x3e/0x90
> 
> Thanks for the report.
> 
> Could you please test whether the attached patch is helping?

Yes, that helps, thanks!

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature

[ovmf test] 168780: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  223 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days4 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi,

On 22/03/2022 09:52, Luca Fancellu wrote:


Can you document why this is necessary on x86 but not on other architectures?

Hi Julien,
I received the warning by Juergen here: 
https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could 
be
some problems if cpu0 is not in cpupool0, I tested it on arm and it was working 
fine and I didn’t find any restriction.


What exactly did you test on Arm?



I have tested start/stop of some guest, moving cpus between cpupools, 
create/destroy cpupools, shutdown of Dom0


[ from your last mail ]


If dom0 must run on core0 and core0 is Little then you cannot build a system 
where dom0 is running on big cores.
If the limitation is not there, you can build such a configuration without any 
dependency to the boot core type.

This might not be completely clear so let me rephrase:
In the current system:
- dom0 must run on cpupool-0


I don't think we need this restriction. In fact, with this series it will 
become more a problem because the cpupool ID will based on how we parse the 
Device-Tree.

So for dom0, we need to specify explicitely the cpupool to be used.


- cpupool-0 must contain the boot core
- consequence: dom0 must run on the boot core
If boot core is little, you cannot build as system where dom0 runs only on the 
big cores.
Removing the second limitation (which is not required on arm) is making it 
possible.


IMHO removing the second restriction is a lot more risky than removing the 
first one.


I see your point, my concern about moving Dom0 on another cpupool, different 
from cpupool0, is that we give the
opportunity to destroy the cpupool0 (we can’t let that happen), or remove every 
cpu from cpupool0.


From my understanding a cpupool can only be destroyed when there are no 
more CPUs in the pool. Given that cpu0 has to be in pool0 then this 
should prevent the pool to be destroyed.


Now, it is quite possible that we don't have a check to prevent CPU0 to 
be removed from cpupool0. If so, then I would argue we should add the 
check otherwise it is pointless to prevent cpu0 to be initially added in 
another pool than pool0 but can be moved afterwards.


Cheers,

--
Julien Grall

Re: [PATCH] xen/arm: skip first 32 bytes of zimage32

[Julien Grall]

Hi,

On 21/03/2022 22:07, Stefano Stabellini wrote:

On Mon, 21 Mar 2022, Julien Grall wrote:

This is the list of kernels that I tried and failed:

- Debian Buster
- Debian Bullseye
- vanilla 4.9
- vanilla 4.10


Does this mean you where using v4.{9,10}.0 rather than the stable branch?

Note that AFAICT, 4.10 is not even supported by the kernel communinty (see
[1]).


Yeah... I was trying to bisect the Debian kernel failure. That is how I
discovered that CONFIG_EFI was causing it. So yes, I only tried the
vanilla, now unsupported, releases.



The latest Alpine Linux kernel also doesn't boot, but that one doesn't
boot even with the fix for other reason. (More in the other email.)


  From a Xen gitlab-ci perspective, we just need a kernel that works.
Ideally, we wouldn't rebuild our own but reuse an existing kernel
because that is one less things to maintain in the gitlab-ci build.

We have a couple of options to make progress on the QEMU32 gitlab-ci
test:

1) use Debian Jessie in gitlab-ci and do not commit the Xen-side fix,
 file a Debian bug and revisit the situation in a couple of months
 (Debian might get the fix in the meantime)


Why do we need to use Debian here? Couldn't we use Ubuntu (or any distros that
have a newer kernel)?


We could use something else but see below.



2) commit the Xen fix and use Debian Bullseye right now

3) do not commit the Xen fix and build our own kernel now


All of these options work. My preference is 1) or 2).

Between 1) and 2) I have a slight preference for 2) for this reason: I
know that in Open Source we try to fix bugs wherever they are (kernel
project, QEMU project, Debian project) rather than working around them,
but in this case it looks like there is a significant amount of binaries
out there that require an update before they can boot on Xen.


My problem here is the bug is not Xen specific. You would exactly have the
same problem if you were booting on baremetal. But as Andre wrote in his
commit message, this is only working by luck.

So we are setting another bad precendence by preserving the luck.

I appreciate we recently agreed to merge the code to emulate ldr/str. But this
was based on the fact the Arm Arm doesn't clearly forbid such access. This is
quite different here as the instructions are UNDEFINED.


Yeah, I understand your point and I also kind of agree.



So I am not willing to accept a lot of code in Xen just to workaround a
software bug (see more below).


I think it
is one of those times where it is worth considering the Xen fix, or
should I say workaround, if it is considered harmless.


The problem with your workaround is now the zImage will be loaded in a
different aligned. For instance, if the symbol  was 2MB aligned, now, it
will be aligned to 2MB - 32. See kernel_zimage_load().

The booting protocol (see Documentation/arm/booting.rst). Doesn't look to
impose an alignment. But I wouldn't be surprised if there is an assumption
here.

Furthermore, there are some problem if the kernel is expected to be loaded a
specific address.

I do expect the code to become more convoluted. This would also have to be
duplicated in the tools side. Overall, this will likely be more than I am
willing to accept for this issue.

Therefore I would like to suggest a more simple workaround. Per the commit
message of the Linux bug fix, U-boot and direct loading are not affected
because the bit "Z" is set.

So how about updating PSR_GUEST32_INIT to set Z?


That worked! Excellent suggestion and much safer than the 32 byte
workaround. I tested with the Debian Bullseye kernel.


I would not say it is safer because we will be relying on the processor 
(here QEMU) to check the condition and ignore the UNPREDICTABLE 
behavior. So, in theory, the issue could reappear on a new processor. 
Note that I haven't checked what the Arm Arm says here.


But the workaround is less intrusive. Hence, why I prefer this approach.



I think you might have a better suggestion for the commit message.

---
xen/arm: set CPSR Z bit when creating aarch32 guests

The first 32 bytes of zImage32 are NOPs. When CONFIG_EFI is enabled in


The format is zImage not zImage32.


the kernel, certain versions of Linux have a bug in the way the initial
NOP instructions gets encoded (invalid encoding), resulting in an
unbootable kernel.


This paragraph is a bit difficult to understand. I would say "certain 
version of Linux will use a UNPREDICATABLE NOP encoding".


Also, I would suggest make clear that the issue depends on the processor.

 See commit a92882a4d270 in the Linux kernel for all

the details.

All kernel releases starting from Linux 4.9 without commit a92882a4d270
are affected.

Fortunately there is a simple workaround: setting the "Z" bit in CPSR
make it so those invalid  NOP instructions are never executed.


I would say that the instruction is conditional (not equal). So, on QEMU 
at least, the instruction will end up to be ignored and not generate an 
UNDEFINED (XXX this

[ovmf test] 168779: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  222 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days3 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

Re: [PATCH v2 0/3] Use g_new() & friends where that makes obvious sense

[Michael S. Tsirkin]

On Tue, Mar 15, 2022 at 03:41:53PM +0100, Markus Armbruster wrote:
> g_new(T, n) is neater than g_malloc(sizeof(T) * n).  It's also safer,
> for two reasons.  One, it catches multiplication overflowing size_t.
> Two, it returns T * rather than void *, which lets the compiler catch
> more type errors.
> 
> This series only touches allocations with size arguments of the form
> sizeof(T).  It's mechanical, except for a tiny fix in PATCH 2.
> 
> PATCH 1 adds the Coccinelle script.
> 
> PATCH 2 cleans up the virtio-9p subsystem, and fixes a harmless typing
> error uncovered by the cleanup.
> 
> PATCH 3 cleans up everything else.  I started to split it up, but
> splitting is a lot of decisions, and I just can't see the value.

series:

Acked-by: Michael S. Tsirkin 


> For instance, MAINTAINERS tells me to split for subsystem "virtio",
> patching
> 
> hw/char/virtio-serial-bus.c
> hw/display/virtio-gpu.c
> hw/net/virtio-net.c
> hw/virtio/virtio-crypto.c
> hw/virtio/virtio-iommu.c
> hw/virtio/virtio.c
> 
> But it also tells me to split for subsystem "Character devices",
> patching
> 
> hw/char/parallel.c   |  2 +-
> hw/char/riscv_htif.c |  2 +-
> hw/char/virtio-serial-bus.c  |  6 +-
> 
> and for subsystem "Network devices", patching
> 
> hw/net/virtio-net.c
> 
> and for subsystem "virtio-gpu", patching
> 
> hw/display/virtio-gpu.c
> 
> I guess I'd go with "virtio".  Six files down, 103 to go.  Thanks, but
> no thanks.
> 
> Since the transformation is local to a function call, dropping is
> completely safe.  We can deal with conflicts by dropping conflicting
> hunks, with "git-pull -s recursive -X ours".  Or drop entire files
> with conflicts.
> 
> If you want me to split off certain parts, please tell me exactly what
> you want split off, and I'll gladly do the splitting.  I don't mind
> the splitting part, I do mind the *thinking* part.
> 
> I backed out two changes made by the Coccinelle script:
> scripts/coverity-scan/model.c, because that's special, and
> semihosting/config.c, because it has a typing error similar to the one
> fixed in PATCH 2, and Alex already posted a patch for it.
> 
> v2:
> * PATCH 3: Change to scripts/coverity-scan/model.c dropped [Eric]
> * PATCH 3: Change to semihosting/config.c dropped [Alex]
> * Commit messages tweaked
> 
> Markus Armbruster (3):
>   scripts/coccinelle: New use-g_new-etc.cocci
>   9pfs: Use g_new() & friends where that makes obvious sense
>   Use g_new() & friends where that makes obvious sense
> 
>  scripts/coccinelle/use-g_new-etc.cocci   | 75 
>  include/qemu/timer.h |  2 +-
>  accel/kvm/kvm-all.c  |  6 +-
>  accel/tcg/tcg-accel-ops-mttcg.c  |  2 +-
>  accel/tcg/tcg-accel-ops-rr.c |  4 +-
>  audio/audio.c|  4 +-
>  audio/audio_legacy.c |  6 +-
>  audio/dsoundaudio.c  |  2 +-
>  audio/jackaudio.c|  6 +-
>  audio/paaudio.c  |  4 +-
>  backends/cryptodev.c |  2 +-
>  contrib/vhost-user-gpu/vhost-user-gpu.c  |  2 +-
>  cpus-common.c|  4 +-
>  dump/dump.c  |  2 +-
>  hw/9pfs/9p-proxy.c   |  2 +-
>  hw/9pfs/9p-synth.c   |  4 +-
>  hw/9pfs/9p.c |  8 +--
>  hw/9pfs/codir.c  |  6 +-
>  hw/acpi/hmat.c   |  2 +-
>  hw/audio/intel-hda.c |  2 +-
>  hw/char/parallel.c   |  2 +-
>  hw/char/riscv_htif.c |  2 +-
>  hw/char/virtio-serial-bus.c  |  6 +-
>  hw/core/irq.c|  2 +-
>  hw/core/reset.c  |  2 +-
>  hw/display/pxa2xx_lcd.c  |  2 +-
>  hw/display/tc6393xb.c|  2 +-
>  hw/display/virtio-gpu.c  |  4 +-
>  hw/display/xenfb.c   |  4 +-
>  hw/dma/rc4030.c  |  4 +-
>  hw/i2c/core.c|  4 +-
>  hw/i2c/i2c_mux_pca954x.c |  2 +-
>  hw/i386/amd_iommu.c  |  4 +-
>  hw/i386/intel_iommu.c|  2 +-
>  hw/i386/xen/xen-hvm.c| 10 ++--
>  hw/i386/xen/xen-mapcache.c   | 14 ++---
>  hw/input/lasips2.c   |  2 +-
>  hw/input/pckbd.c |  2 +-
>  hw/input/ps2.c   |  4 +-
>  hw/input/pxa2xx_keypad.c |  2 +-
>  hw/input/tsc2005.c   |  3 +-
>  hw/intc/riscv_aclint.c   |  6 +-
>  hw/intc/xics.c   |  2 +-
>  hw/m68k/virt.c   |  2 +-
>  hw/mips/mipssim.c|  2 +-
>  hw/misc/applesmc.c   |  2 +-
> 

Re: [PATCH v11 3/3] xen/arm64: io: Handle data abort due to cache maintenance instructions

[Julien Grall]

Hi Ayan,

On 22/03/2022 12:38, Ayan Kumar Halder wrote:


On 22/03/2022 12:06, Ayan Kumar Halder wrote:


On 18/03/2022 18:26, Julien Grall wrote:

Hi Ayan,

Hi Julien,


On 17/03/2022 14:00, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/include/asm/mmio.h 
b/xen/arch/arm/include/asm/mmio.h

index ca259a79c2..79e64d9af8 100644
--- a/xen/arch/arm/include/asm/mmio.h
+++ b/xen/arch/arm/include/asm/mmio.h
@@ -35,6 +35,7 @@ enum instr_decode_state
   * instruction.
   */
  INSTR_LDR_STR_POSTINDEXING,
+    INSTR_CACHE,    /* Cache Maintenance instr */
  };
    typedef struct
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 6f458ee7fd..26c716b4a5 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -139,6 +139,17 @@ void try_decode_instruction(const struct 
cpu_user_regs *regs,

  return;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance, Xen 
should check
+ * if the address belongs to an emulated MMIO region or not. 
The behavior

+ * will differ accordingly.
+ */
+    if ( info->dabt.cache )
+    {
+    info->dabt_instr.state = INSTR_CACHE;
+    return;
+    }
+
  /*
   * Armv8 processor does not provide a valid syndrome for 
decoding some
   * instructions. So in order to process these instructions, 
Xen must
@@ -177,6 +188,13 @@ enum io_state try_handle_mmio(struct 
cpu_user_regs *regs,

  return rc;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance and 
the address
+ * belongs to an emulated region, Xen should ignore this 
instruction.

+ */
+    if ( info->dabt_instr.state == INSTR_CACHE )


Reading the Arm Arm, the ISS should be invalid for cache 
instructions. So, I think the check at the beginning of 
try_handle_mmio() would prevent us to reach this check.


Can you check that cache instructions on emulated region will 
effectively be ignored?


Yes, you are correct.

I tested with the following (dis)assembly snippet :-

0x3001000 is the base address of GIC Distributor base.

    __asm__ __volatile__("ldr x1, =0x3001000");
    4ca8:   58000301    ldr x1, 4d08 
    __asm __volatile__("DC CVAU, x1");
    4cac:   d50b7b21    dc  cvau, x1

This resulting in hitting the assertion :-

(XEN) Assertion 'unreachable' failed at arch/arm/io.c:178

I dumped the registers as follows, to determine that the fault is 
caused by the instruction at 4cac.


HSR=0x0092000147  regs->pc = 0x4cac info.gpa = 0x3001000


So, my patch needs to be modified as follows:-

@@ -172,7 +173,7 @@ enum io_state try_handle_mmio(struct cpu_user_regs 
*regs,


 ASSERT(info->dabt.ec == HSR_EC_DATA_ABORT_LOWER_EL);

-    if ( !info->dabt.valid )
+    if ( !(info->dabt.valid || (info->dabt_instr.state == 
INSTR_CACHE)) )


Actually this is not needed.

The following change is sufficient :-

@@ -146,7 +146,9 @@ void try_decode_instruction(const struct 
cpu_user_regs *regs,

   */
  if ( info->dabt.cache )
  {
  info->dabt_instr.state = INSTR_CACHE;
+    info->dabt.valid = 1;


To me, 'info->dabt.valid' indicates whether the syndrome is valid. We 
set to 1 for emulated instruction because the syndrome will be updated.


But this is not the case for the cache instructions. So I would prefer 
if it is kept as 0 and use your previous suggestion.


Furthermore, I think try_fwd_ioserv() need to be adapted because the 
function will use the fields SAS and SRT. From the Arm Arm they are 
RES0, so while they are 0 today, we should not rely on this.


Therefore, to be fully compliant with the Arm, we want to reorder a bit 
the code:


 * The field data could be set past ioreq_select_server().
 * The field size should be set to the cache line size.

Cheers,

--
Julien Grall

[ovmf test] 168777: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  221 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days2 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

[libvirt test] 168769: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 151777
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 151777
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 151777

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

version targeted for testing:
 libvirt  d31c39a83c1d911c478561aaf40729a529e3283e
baseline version:
 libvirt  2c846fa6bcc11929c9fb857a22430fb9945654ad

Last test of basis   151777  2020-07-10 04:19:19 Z  620 days
Failing since151818  2020-07-11 04:18:52 Z  619 days  601 attempts
Testing same since   168769  2022-03-22 04:18:58 Z0 days1 attempts


People who touched revisions under test:
Adolfo Jayme Barrientos 
  Aleksandr Alekseev 
  Aleksei Zakharov 
  Andika Triwidada 
  Andrea Bolognani 
  Ani Sinha 
  Balázs Meskó 
  Barrett Schonefeld 
  Bastian Germann 
  Bastien Orivel 
  BiaoXiang Ye 
  Bihong Yu 
  Binfeng Wu 
  Bjoern Walk 
  Boris Fiuczynski 
  Brad Laue 
  Brian Turek 
  Bruno Haible 
  Chris Mayo 
  Christian Borntraeger 
  Christian Ehrhardt 
  Christian Kirbach 
  Christian Schoenebeck 
  Christophe Fergeau 
  Cole Robinson 
  Collin Walling 
  Cornelia Huck 
  Cédric Bosdonnat 
  Côme Borsoi 
  Daniel Henrique Barboza 
  Daniel Letai 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  Didik Supriadi 
  dinglimin 
  Divya Garg 
  Dmitrii Shcherbakov 
  Dmytro Linkin 
  Eiichi Tsukata 
  Emilio Herrera 
  Eric Farman 
  Erik Skultety 
  Fabian Affolter 
  Fabian Freyer 
  Fabiano Fidêncio 
  Fangge Jin 
  Farhan Ali 
  Fedora Weblate Translation 
  Franck Ridel 
  Gavi Teitz 
  gongwei 
  Guoyi Tu
  Göran Uddeborg 
  Halil Pasic 
  Han Han 
  Hao Wang 
  Haonan Wang 
  Hela Basa 
  Helmut Grohne 
  Hiroki Narukawa 
  Hyman Huang(黄勇) 
  Ian Wienand 
  Ioanna Alifieraki 
  Ivan Teterevkov 
  Jakob Meng 
  Jamie Strandboge 
  Jamie Strandboge 
  Jan Kuparinen 
  jason lee 
  Jean-Baptiste Holcroft 
  Jia Zhou 
  Jianan Gao 
  Jim Fehlig 
  Jin Yan 
  Jing Qi 
  Jinsheng Zhang 
  Jiri Denemark 
  Joachim Falk 
  John Ferlan 
  Jonathan Watt 
  Jonathon Jongsma 
  Julio Faracco 
  Justin Gatzen 
  Ján Tomko 
  Kashyap Chamarthy 
  Kevin Locke 
  Kim InSoo 
  Koichi Murase 
  Kristina Hanicova 
  Laine Stump 
  Laszlo Ersek 
  Lee Yarwood 
  Lei Yang 
  Liao Pingfang 
  Lin Ma 
  Lin Ma 
  Lin Ma 
  Liu Yiding 
  Lubomir Rintel 
  Luke Yue 
  Luyao Zhong 
  Marc Hartmayer 
  Marc-André Lureau 
  Marek Marczykowski-Górecki 
  Markus Schade 
  Martin Kletzander 
  Martin Pitt 
  Masayoshi Mizuma 
  Matej Cepl 
  Matt Coleman 
  Matt Coleman 
  Mauro Matteo Cascella 
  Meina Li 
  Michal Privoznik 
  Michał Smyk 
  Milo Casagrande 
  Moshe Levi 
  Muha Aliss 
  Nathan 
  Neal Gompa 
  Nick Chevsky 
  Nick Shyrokovskiy 
  Nickys Music Group 
  Nico Pache 
  Nicolas Lécureuil 
  Nicolas Lécureuil 
  Nikolay Shirokovskiy 
  Olaf Hering 
  Olesya Gerasimenko 
  Or Ozeri 
  Orion Poplawski 
  Pany 
  Patrick Magauran 
  Paulo de Rezende Pinatti 
  Pavel Hrdina 
  Peng Liang 
  Peter Krempa 
  Pino Toscano 
  Pino Toscano 
  Piotr Drąg 
  Prathamesh Chavan 
  Praveen K Paladugu 
  Richard W.M. Jones 
  Ricky Tigg 
  Robin Lee 
  Rohit Kumar 
  Roman Bogorodskiy 
  Roman Bolshakov 
  Ryan Gahagan 
  Ryan Schmidt 
  Sam Hartman 
  Scott Shambarger 
  Sebastian Mitterle 
  SeongHyun Jo 
  S

Re: [PATCH v11 3/3] xen/arm64: io: Handle data abort due to cache maintenance instructions

[Ayan Kumar Halder]

On 22/03/2022 12:06, Ayan Kumar Halder wrote:


On 18/03/2022 18:26, Julien Grall wrote:

Hi Ayan,

Hi Julien,


On 17/03/2022 14:00, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/include/asm/mmio.h 
b/xen/arch/arm/include/asm/mmio.h

index ca259a79c2..79e64d9af8 100644
--- a/xen/arch/arm/include/asm/mmio.h
+++ b/xen/arch/arm/include/asm/mmio.h
@@ -35,6 +35,7 @@ enum instr_decode_state
   * instruction.
   */
  INSTR_LDR_STR_POSTINDEXING,
+    INSTR_CACHE,    /* Cache Maintenance instr */
  };
    typedef struct
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 6f458ee7fd..26c716b4a5 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -139,6 +139,17 @@ void try_decode_instruction(const struct 
cpu_user_regs *regs,

  return;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance, Xen 
should check
+ * if the address belongs to an emulated MMIO region or not. 
The behavior

+ * will differ accordingly.
+ */
+    if ( info->dabt.cache )
+    {
+    info->dabt_instr.state = INSTR_CACHE;
+    return;
+    }
+
  /*
   * Armv8 processor does not provide a valid syndrome for 
decoding some
   * instructions. So in order to process these instructions, 
Xen must
@@ -177,6 +188,13 @@ enum io_state try_handle_mmio(struct 
cpu_user_regs *regs,

  return rc;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance and 
the address
+ * belongs to an emulated region, Xen should ignore this 
instruction.

+ */
+    if ( info->dabt_instr.state == INSTR_CACHE )


Reading the Arm Arm, the ISS should be invalid for cache 
instructions. So, I think the check at the beginning of 
try_handle_mmio() would prevent us to reach this check.


Can you check that cache instructions on emulated region will 
effectively be ignored?


Yes, you are correct.

I tested with the following (dis)assembly snippet :-

0x3001000 is the base address of GIC Distributor base.

    __asm__ __volatile__("ldr x1, =0x3001000");
    4ca8:   58000301    ldr x1, 4d08 
    __asm __volatile__("DC CVAU, x1");
    4cac:   d50b7b21    dc  cvau, x1

This resulting in hitting the assertion :-

(XEN) Assertion 'unreachable' failed at arch/arm/io.c:178

I dumped the registers as follows, to determine that the fault is 
caused by the instruction at 4cac.


HSR=0x0092000147  regs->pc = 0x4cac info.gpa = 0x3001000


So, my patch needs to be modified as follows:-

@@ -172,7 +173,7 @@ enum io_state try_handle_mmio(struct cpu_user_regs 
*regs,


 ASSERT(info->dabt.ec == HSR_EC_DATA_ABORT_LOWER_EL);

-    if ( !info->dabt.valid )
+    if ( !(info->dabt.valid || (info->dabt_instr.state == 
INSTR_CACHE)) )


Actually this is not needed.

The following change is sufficient :-

@@ -146,7 +146,9 @@ void try_decode_instruction(const struct 
cpu_user_regs *regs,

  */
 if ( info->dabt.cache )
 {
 info->dabt_instr.state = INSTR_CACHE;
+    info->dabt.valid = 1;
 return;
 }

"info->dabt.valid == 1" means the instruction is valid or decoded 
successfully (this holds true for INSTR_CACHE as well).

[ovmf test] 168774: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf ec0b54849b23efa25caf0055b0eef8bf9b4dec98
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   22 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  220 attempts
Testing same since   168774  2022-03-22 08:40:31 Z0 days1 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 875 lines long.)

Re: [PATCH v11 3/3] xen/arm64: io: Handle data abort due to cache maintenance instructions

[Ayan Kumar Halder]

On 18/03/2022 18:26, Julien Grall wrote:

Hi Ayan,

Hi Julien,


On 17/03/2022 14:00, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/include/asm/mmio.h 
b/xen/arch/arm/include/asm/mmio.h

index ca259a79c2..79e64d9af8 100644
--- a/xen/arch/arm/include/asm/mmio.h
+++ b/xen/arch/arm/include/asm/mmio.h
@@ -35,6 +35,7 @@ enum instr_decode_state
   * instruction.
   */
  INSTR_LDR_STR_POSTINDEXING,
+    INSTR_CACHE,    /* Cache Maintenance instr */
  };
    typedef struct
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 6f458ee7fd..26c716b4a5 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -139,6 +139,17 @@ void try_decode_instruction(const struct 
cpu_user_regs *regs,

  return;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance, Xen 
should check
+ * if the address belongs to an emulated MMIO region or not. The 
behavior

+ * will differ accordingly.
+ */
+    if ( info->dabt.cache )
+    {
+    info->dabt_instr.state = INSTR_CACHE;
+    return;
+    }
+
  /*
   * Armv8 processor does not provide a valid syndrome for 
decoding some
   * instructions. So in order to process these instructions, Xen 
must
@@ -177,6 +188,13 @@ enum io_state try_handle_mmio(struct 
cpu_user_regs *regs,

  return rc;
  }
  +    /*
+ * When the data abort is caused due to cache maintenance and 
the address
+ * belongs to an emulated region, Xen should ignore this 
instruction.

+ */
+    if ( info->dabt_instr.state == INSTR_CACHE )


Reading the Arm Arm, the ISS should be invalid for cache instructions. 
So, I think the check at the beginning of try_handle_mmio() would 
prevent us to reach this check.


Can you check that cache instructions on emulated region will 
effectively be ignored?


Yes, you are correct.

I tested with the following (dis)assembly snippet :-

0x3001000 is the base address of GIC Distributor base.

    __asm__ __volatile__("ldr x1, =0x3001000");
    4ca8:   58000301    ldr x1, 4d08 
    __asm __volatile__("DC CVAU, x1");
    4cac:   d50b7b21    dc  cvau, x1

This resulting in hitting the assertion :-

(XEN) Assertion 'unreachable' failed at arch/arm/io.c:178

I dumped the registers as follows, to determine that the fault is caused 
by the instruction at 4cac.


HSR=0x0092000147  regs->pc = 0x4cac info.gpa = 0x3001000


So, my patch needs to be modified as follows:-

@@ -172,7 +173,7 @@ enum io_state try_handle_mmio(struct cpu_user_regs 
*regs,


 ASSERT(info->dabt.ec == HSR_EC_DATA_ABORT_LOWER_EL);

-    if ( !info->dabt.valid )
+    if ( !(info->dabt.valid || (info->dabt_instr.state == INSTR_CACHE)) )
 {
 ASSERT_UNREACHABLE();
 return IO_ABORT;

I will send a v12 patch with this change.

- Ayan



Cheers,

[XEN PATCH v10 7/7] build: adding out-of-tree support to the xen build

[Anthony PERARD]

This implement out-of-tree support, there's two ways to create an
out-of-tree build tree (after that, `make` in that new directory
works):
make O=build
mkdir build; cd build; make -f ../Makefile
also works with an absolute path for both.

This implementation only works if the source tree is clean, as we use
VPATH.

This patch copies most new code with handling out-of-tree build from
Linux v5.12.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
Reviewed-by: Daniel P. Smith 
Acked-by: Julien Grall 
Tested-by: Julien Grall 
---

Notes:
v10:
- rebased

v9:
- acked
- add "source -> ." symlink in the in-tree build as well. This allow to
  make relative symlink to the "common/efi/*.c" sources.
- also now, the "source" symlink is removed on `distclean`, add added to
  .gitignore.

v8:
- replace script/mkmakefile by cmd_makefile like it's been done in Linux
  5.13.
- fix GNU Make version, replace few 0.81 by 3.81.
- reorder include header path in CFLAGS ( -I ), to have the $(objtree)
  paths listed before the $(srctree) paths. This will be usefull later
  if we allow to build out-of-tree from a dirty source tree.
- make use of -iquote
- sometime, add -iquote path even when not necessary when building in-tree.
- extract code movement into a separate patch
- make use of the new "$(srcdir)" shortcut
- split command line in headers*.chk target into more lines

 .gitignore   |   1 +
 xen/Makefile | 143 +++
 xen/Rules.mk |  11 ++-
 xen/arch/x86/arch.mk |   5 +-
 xen/arch/x86/boot/Makefile   |   6 ++
 xen/common/efi/efi-common.mk |   3 +-
 xen/include/Makefile |  11 ++-
 xen/test/livepatch/Makefile  |   2 +
 xen/xsm/flask/Makefile   |   3 +-
 xen/xsm/flask/ss/Makefile|   1 +
 10 files changed, 164 insertions(+), 22 deletions(-)

diff --git a/.gitignore b/.gitignore
index d425be4bd9d7..c6d2c4b4f1e9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -325,6 +325,7 @@ xen/include/xen/*.new
 xen/include/xen/acm_policy.h
 xen/include/xen/compile.h
 xen/include/xen/lib/x86/cpuid-autogen.h
+xen/source
 xen/test/livepatch/config.h
 xen/test/livepatch/expect_config.h
 xen/test/livepatch/*.livepatch
diff --git a/xen/Makefile b/xen/Makefile
index 889d91c68a42..11057318e875 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -1,3 +1,7 @@
+# $(lastword,) for GNU Make older than 3.81
+lastword = $(word $(words $(1)),$(1))
+this-makefile := $(call lastword,$(MAKEFILE_LIST))
+
 # This is the correct place to edit the build version.
 # All other places this is stored (eg. compile.h) should be autogenerated.
 export XEN_VERSION   = 4
@@ -19,6 +23,13 @@ export PYTHON?= $(PYTHON_INTERPRETER)
 
 export CHECKPOLICY ?= checkpolicy
 
+$(if $(filter __%, $(MAKECMDGOALS)), \
+$(error targets prefixed with '__' are only for internal use))
+
+# That's our default target when none is given on the command line
+PHONY := __all
+__all:
+
 # Do not use make's built-in rules and variables
 MAKEFLAGS += -rR
 
@@ -37,9 +48,6 @@ export CC CXX LD NM OBJCOPY OBJDUMP
 
 export TARGET := xen
 
-.PHONY: default
-default: build
-
 .PHONY: dist
 dist: install
 
@@ -118,16 +126,88 @@ endif
 
 export quiet Q KBUILD_VERBOSE
 
+# $(realpath,) for GNU Make older than 3.81
+realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo 
"$$PWD/$(notdir $(file))")))
+
+ifeq ("$(origin O)", "command line")
+KBUILD_OUTPUT := $(O)
+endif
+
+ifneq ($(KBUILD_OUTPUT),)
+# Make's built-in functions such as $(abspath ...), $(realpath ...) cannot
+# expand a shell special character '~'. We use a somewhat tedious way here.
+abs_objtree := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) && pwd)
+$(if $(abs_objtree),, \
+ $(error failed to create output directory "$(KBUILD_OUTPUT)"))
+
+# $(realpath ...) resolves symlinks
+abs_objtree := $(call realpath,$(abs_objtree))
+else
 abs_objtree := $(CURDIR)
-abs_srctree := $(CURDIR)
+endif
+
+ifeq ($(abs_objtree),$(CURDIR))
+# Suppress "Entering directory ..." unless we are changing the work directory.
+MAKEFLAGS += --no-print-directory
+else
+need-sub-make := 1
+endif
+
+abs_srctree := $(call realpath,$(dir $(this-makefile)))
+
+ifneq ($(words $(subst :, ,$(abs_srctree))), 1)
+$(error source directory cannot contain spaces or colons)
+endif
+
+ifneq ($(abs_srctree),$(abs_objtree))
+# Look for make include files relative to root of kernel src
+#
+# This does not become effective immediately because MAKEFLAGS is re-parsed
+# once after the Makefile is read. We need to invoke sub-make.
+MAKEFLAGS += --include-dir=$(abs_srctree)
+need-sub-make := 1
+endif
 
 export abs_srctree abs_objtree
+export root-make-done := y
+
+ifeq ($(need-sub-make),1)
+
+PHONY += $(MAKECMDGOALS) __sub-make
+
+$(filter-out $(this-makefile), $(MAKECMDGOALS)) __all: __sub-make
+   @:
+
+# Invoke a second make in the

[XEN PATCH v10 6/7] build: shuffle main Makefile

[Anthony PERARD]

Reorganize a bit the Makefile ahead of patch
"build: adding out-of-tree support to the xen build"

We are going to want to calculate all the $(*srctree) and $(*objtree)
once, when we can calculate them. This can happen within the
"$(root-make-done)" guard, in an out-of-tree build scenario, so move
those variable there.

$(XEN_ROOT) is going to depends on the value of $(abs_srctree) so
needs to move as well. "Kbuild.include" also depends on $(srctree).

Next, "Config.mk" depends on $(XEN_ROOT) and $(TARGET_*ARCH) depends
on "Config.mk" so those needs to move as well.

This should only be code movement without functional changes.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---

Notes:
v10:
- acked

v9:
- add some explanation in the commit message about why the code movement
  is needed.

v8:
- new patch

 xen/Makefile | 46 +++---
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index b89db5e8ab37..889d91c68a42 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -19,17 +19,6 @@ export PYTHON?= $(PYTHON_INTERPRETER)
 
 export CHECKPOLICY ?= checkpolicy
 
-export XEN_ROOT := $(CURDIR)/..
-
-abs_objtree := $(CURDIR)
-abs_srctree := $(CURDIR)
-
-export abs_srctree abs_objtree
-
-srctree := .
-objtree := .
-export srctree objtree
-
 # Do not use make's built-in rules and variables
 MAKEFLAGS += -rR
 
@@ -41,16 +30,6 @@ SRCARCH=$(shell echo $(ARCH) | \
   -e s'/riscv.*/riscv/g')
 export ARCH SRCARCH
 
-# Don't break if the build process wasn't called from the top level
-# we need XEN_TARGET_ARCH to generate the proper config
-include $(XEN_ROOT)/Config.mk
-
-# Set ARCH/SUBARCH appropriately.
-export TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
-export TARGET_ARCH := $(shell echo $(XEN_TARGET_ARCH) | \
-sed -e 's/x86.*/x86/' -e s'/arm\(32\|64\)/arm/g' \
--e s'/riscv.*/riscv/g')
-
 # Allow someone to change their config file
 export KCONFIG_CONFIG ?= .config
 
@@ -64,8 +43,6 @@ default: build
 .PHONY: dist
 dist: install
 
-include scripts/Kbuild.include
-
 ifneq ($(root-make-done),y)
 # section to run before calling Rules.mk, but only once.
 
@@ -141,6 +118,17 @@ endif
 
 export quiet Q KBUILD_VERBOSE
 
+abs_objtree := $(CURDIR)
+abs_srctree := $(CURDIR)
+
+export abs_srctree abs_objtree
+
+srctree := .
+objtree := .
+export srctree objtree
+
+export XEN_ROOT := $(CURDIR)/..
+
 # To make sure we do not include .config for any of the *config targets
 # catch them early, and hand them over to tools/kconfig/Makefile
 
@@ -163,6 +151,18 @@ ifneq ($(filter %config,$(MAKECMDGOALS)),)
 config-build := y
 endif
 
+include scripts/Kbuild.include
+
+# Don't break if the build process wasn't called from the top level
+# we need XEN_TARGET_ARCH to generate the proper config
+include $(XEN_ROOT)/Config.mk
+
+# Set ARCH/SUBARCH appropriately.
+export TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
+export TARGET_ARCH := $(shell echo $(XEN_TARGET_ARCH) | \
+sed -e 's/x86.*/x86/' -e s'/arm\(32\|64\)/arm/g' \
+-e s'/riscv.*/riscv/g')
+
 export CONFIG_SHELL := $(SHELL)
 export YACC = $(if $(BISON),$(BISON),bison)
 export LEX = $(if $(FLEX),$(FLEX),flex)
-- 
Anthony PERARD

[XEN PATCH v10 5/7] build: specify source tree in include/ for prerequisite

[Anthony PERARD]

When doing an out-of-tree build, and thus setting VPATH,
GNU Make 3.81 on Ubuntu Trusty complains about Circular dependency of
include/Makefile and include/xlat.lst and drop them. The build fails
later due to headers malformed.

This might be due to bug #13529
"Incorrect circular dependancy"
https://savannah.gnu.org/bugs/?13529
which was fixed in 3.82.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---

Notes:
v10:
- acked

v9:
- add potential bug report link in commit message

v8:
- make use of the new "$(srcdir)" shortcut
- move the patch ahead of the problematic patch:
build: adding out-of-tree support to the xen build

 xen/include/Makefile | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index fddf5a575bf6..c8c4bcd93bd3 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -45,19 +45,19 @@ public-$(CONFIG_ARM) := $(wildcard 
$(srcdir)/public/arch-arm/*.h $(srcdir)/publi
 .PHONY: all
 all: $(addprefix $(obj)/,$(headers-y))
 
-$(obj)/compat/%.h: $(obj)/compat/%.i $(src)/Makefile 
$(srctree)/tools/compat-build-header.py
+$(obj)/compat/%.h: $(obj)/compat/%.i $(srcdir)/Makefile 
$(srctree)/tools/compat-build-header.py
$(PYTHON) $(srctree)/tools/compat-build-header.py <$< $(patsubst 
$(obj)/%,%,$@) >>$@.new; \
mv -f $@.new $@
 
-$(obj)/compat/%.i: $(obj)/compat/%.c $(src)/Makefile
+$(obj)/compat/%.i: $(obj)/compat/%.c $(srcdir)/Makefile
$(CPP) $(filter-out -Wa$(comma)% -include 
%/include/xen/config.h,$(XEN_CFLAGS)) $(cppflags-y) -o $@ $<
 
-$(obj)/compat/%.c: $(src)/public/%.h $(src)/xlat.lst $(src)/Makefile 
$(srctree)/tools/compat-build-source.py
+$(obj)/compat/%.c: $(src)/public/%.h $(srcdir)/xlat.lst $(srcdir)/Makefile 
$(srctree)/tools/compat-build-source.py
mkdir -p $(@D)
$(PYTHON) $(srctree)/tools/compat-build-source.py $(srcdir)/xlat.lst 
<$< >$@.new
mv -f $@.new $@
 
-$(obj)/compat/.xlat/%.h: $(obj)/compat/%.h $(obj)/compat/.xlat/%.lst 
$(srctree)/tools/get-fields.sh $(src)/Makefile
+$(obj)/compat/.xlat/%.h: $(obj)/compat/%.h $(obj)/compat/.xlat/%.lst 
$(srctree)/tools/get-fields.sh $(srcdir)/Makefile
export PYTHON=$(PYTHON); \
while read what name; do \
$(SHELL) $(srctree)/tools/get-fields.sh "$$what" compat_$$name 
$< || exit $$?; \
@@ -65,7 +65,7 @@ $(obj)/compat/.xlat/%.h: $(obj)/compat/%.h 
$(obj)/compat/.xlat/%.lst $(srctree)/
mv -f $@.new $@
 
 .PRECIOUS: $(obj)/compat/.xlat/%.lst
-$(obj)/compat/.xlat/%.lst: $(src)/xlat.lst $(src)/Makefile
+$(obj)/compat/.xlat/%.lst: $(srcdir)/xlat.lst $(srcdir)/Makefile
mkdir -p $(@D)
grep -v '^[[:blank:]]*#' $< | sed -ne 's,@arch@,$(compat-arch-y),g' -re 
's,[[:blank:]]+$*\.h[[:blank:]]*$$,,p' >$@.new
$(call move-if-changed,$@.new,$@)
@@ -73,7 +73,7 @@ $(obj)/compat/.xlat/%.lst: $(src)/xlat.lst $(src)/Makefile
 xlat-y := $(shell sed -ne 's,@arch@,$(compat-arch-y),g' -re 
's,^[?!][[:blank:]]+[^[:blank:]]+[[:blank:]]+,,p' $(srcdir)/xlat.lst | uniq)
 xlat-y := $(filter $(patsubst compat/%,%,$(headers-y)),$(xlat-y))
 
-$(obj)/compat/xlat.h: $(addprefix $(obj)/compat/.xlat/,$(xlat-y)) 
$(obj)/config/auto.conf $(src)/Makefile
+$(obj)/compat/xlat.h: $(addprefix $(obj)/compat/.xlat/,$(xlat-y)) 
$(obj)/config/auto.conf $(srcdir)/Makefile
cat $(filter %.h,$^) >$@.new
mv -f $@.new $@
 
@@ -102,7 +102,7 @@ PUBLIC_C99_HEADERS := $(call 
public-filter-headers,public-c99-headers)
 $(src)/public/io/9pfs.h-prereq := string
 $(src)/public/io/pvcalls.h-prereq := string
 
-$(obj)/headers.chk: $(PUBLIC_ANSI_HEADERS) $(src)/Makefile
+$(obj)/headers.chk: $(PUBLIC_ANSI_HEADERS) $(srcdir)/Makefile
for i in $(filter %.h,$^); do \
$(CC) -x c -ansi -Wall -Werror -include stdint.h \
  -S -o /dev/null $$i || exit 1; \
@@ -110,7 +110,7 @@ $(obj)/headers.chk: $(PUBLIC_ANSI_HEADERS) $(src)/Makefile
done >$@.new
mv $@.new $@
 
-$(obj)/headers99.chk: $(PUBLIC_C99_HEADERS) $(src)/Makefile
+$(obj)/headers99.chk: $(PUBLIC_C99_HEADERS) $(srcdir)/Makefile
rm -f $@.new
$(foreach i, $(filter %.h,$^),\
echo "#include "\"$(i)\"  \
@@ -120,7 +120,7 @@ $(obj)/headers99.chk: $(PUBLIC_C99_HEADERS) $(src)/Makefile
|| exit $$?; echo $(i) >> $@.new;)
mv $@.new $@
 
-$(obj)/headers++.chk: $(PUBLIC_HEADERS) $(src)/Makefile
+$(obj)/headers++.chk: $(PUBLIC_HEADERS) $(srcdir)/Makefile
rm -f $@.new
if ! $(CXX) -v >/dev/null 2>&1; then  \
touch $@.new; \
-- 
Anthony PERARD

[XEN PATCH v10 3/7] build: replace $(BASEDIR) and use $(srctree)

[Anthony PERARD]

$(srctree) is a better description for the source directory than
$(BASEDIR) that has been used for both source and build directory
(which where the same).

This adds $(srctree) to a few path where make's VPATH=$(srctree) won't
apply. And replace $(BASEDIR) by $(srctree).

Introduce "$(srcdir)" as a shortcut for "$(srctree)/$(src)" as the
later is used often enough.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
Reviewed-by: Daniel P. Smith  # XSM
---

Notes:
v10:
- rebased: use $(srctree) for ./tools/check-endbr.sh

v9:
- acked
- reword "# shortcut for $(srctree)/$(src)" into "# shortcuts" in both
  places.

v8:
- merge of two patchs from v7:
build: add $(srctree) in few key places
build: replace $(BASEDIR) by $(srctree)
  both patch were acked
- introduce $(srcdir) as a shortcut for $(srctree)/$(src)

 xen/Kconfig |  4 ++--
 xen/Makefile|  7 +++
 xen/Rules.mk|  9 ++---
 xen/arch/x86/Makefile   |  4 ++--
 xen/arch/x86/arch.mk|  2 +-
 xen/build.mk|  4 ++--
 xen/common/Makefile |  2 +-
 xen/common/libfdt/Makefile  |  2 +-
 xen/include/Makefile| 14 +++---
 xen/scripts/Kconfig.include |  2 +-
 xen/scripts/Makefile.clean  |  5 -
 xen/xsm/flask/Makefile  | 10 +-
 12 files changed, 35 insertions(+), 30 deletions(-)

diff --git a/xen/Kconfig b/xen/Kconfig
index d134397a0ba6..ec2bd9fbcfaa 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -14,14 +14,14 @@ config CC_IS_GCC
 
 config GCC_VERSION
int
-   default $(shell,$(BASEDIR)/scripts/gcc-version.sh $(CC))
+   default $(shell,$(srctree)/scripts/gcc-version.sh $(CC))
 
 config CC_IS_CLANG
def_bool $(success,$(CC) --version | head -n 1 | grep -q clang)
 
 config CLANG_VERSION
int
-   default $(shell,$(BASEDIR)/scripts/clang-version.sh $(CC))
+   default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
 
 # -fvisibility=hidden reduces -fpic cost, if it's available
 config CC_HAS_VISIBILITY_ATTRIBUTE
diff --git a/xen/Makefile b/xen/Makefile
index dec489f2a909..b89db5e8ab37 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -19,8 +19,7 @@ export PYTHON ?= $(PYTHON_INTERPRETER)
 
 export CHECKPOLICY ?= checkpolicy
 
-export BASEDIR := $(CURDIR)
-export XEN_ROOT := $(BASEDIR)/..
+export XEN_ROOT := $(CURDIR)/..
 
 abs_objtree := $(CURDIR)
 abs_srctree := $(CURDIR)
@@ -189,7 +188,7 @@ ifeq ($(TARGET_ARCH),x86)
 t1 = $(call as-insn,$(CC),".L0: .L1: .skip (.L1 - .L0)",,-no-integrated-as)
 
 # Check whether clang asm()-s support .include.
-t2 = $(call as-insn,$(CC) -I$(BASEDIR)/arch/x86/include,".include 
\"asm/asm-defns.h\"",,-no-integrated-as)
+t2 = $(call as-insn,$(CC) -I$(srctree)/arch/x86/include,".include 
\"asm/asm-defns.h\"",,-no-integrated-as)
 
 # Check whether clang keeps .macro-s between asm()-s:
 # https://bugs.llvm.org/show_bug.cgi?id=36110
@@ -326,7 +325,7 @@ ALL_OBJS-$(CONFIG_CRYPTO) += crypto/built_in.o
 
 ALL_LIBS-y:= lib/lib.a
 
-include $(BASEDIR)/arch/$(TARGET_ARCH)/arch.mk
+include $(srctree)/arch/$(TARGET_ARCH)/arch.mk
 
 # define new variables to avoid the ones defined in Config.mk
 export XEN_CFLAGS := $(CFLAGS)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 7712bfa063e0..57a029455586 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -9,13 +9,16 @@ endif
 
 src := $(obj)
 
+# shortcuts
+srcdir := $(srctree)/$(src)
+
 PHONY := __build
 __build:
 
 -include $(objtree)/include/config/auto.conf
 
 include $(XEN_ROOT)/Config.mk
-include $(BASEDIR)/scripts/Kbuild.include
+include $(srctree)/scripts/Kbuild.include
 
 # Initialise some variables
 obj-y :=
@@ -58,7 +61,7 @@ cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $< $@
 # binfile
 # use e.g. $(call if_changed,binfile,binary-file varname)
 quiet_cmd_binfile = BINFILE $@
-cmd_binfile = $(SHELL) $(BASEDIR)/tools/binfile $(BINFILE_FLAGS) $@ $(2)
+cmd_binfile = $(SHELL) $(srctree)/tools/binfile $(BINFILE_FLAGS) $@ $(2)
 
 # Figure out what we need to build from the various variables
 # ===
@@ -177,7 +180,7 @@ cpp_flags = $(filter-out -Wa$(comma)% -flto,$(1))
 c_flags = -MMD -MP -MF $(depfile) $(XEN_CFLAGS)
 a_flags = -MMD -MP -MF $(depfile) $(XEN_AFLAGS)
 
-include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
+include $(srctree)/arch/$(TARGET_ARCH)/Rules.mk
 
 c_flags += $(_c_flags)
 a_flags += $(_c_flags)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 7cea79ed2f8a..717bcbcac7a0 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -153,7 +153,7 @@ $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
>$(@D)/$(@F).map
rm -f $(@D)/.$(@F).[0-9]* $(@D)/..$(@F).[0-9]*
 ifeq ($(CONFIG_XEN_IBT),y)
-   $(SHELL) $(BASEDIR)/tools/check-endbr.sh $@
+   $(SHELL) $(srctree)/tools/check-endbr.sh $@
 endif
 
 $(obj)/note.o: $(TARGET)-syms
@@ -226,7 +2

[XEN PATCH v10 4/7] build: rework "headers*.chk" prerequisite in include/

[Anthony PERARD]

Listing public headers when out-of-tree build are involved becomes
more annoying where every path to every headers needs to start with
"$(srctree)/$(src)", or $(wildcard ) will not work. This means more
repetition. ( "$(srcdir)" is a shortcut for "$(srctree)/$(src)" )

This patch attempt to reduce the amount of duplication and make better
use of make's meta programming capability. The filters are now listed
in a variable and don't have to repeat the path to the headers files
as this is added later as needed.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---

Notes:
v10:
- acked

v9:
- reorder *-headers variables
- call public-filter-headers on $(public-c99-headers) as well, for this I
  needed to rework $(public-c99-headers) and $(public-ansi-headers-filter)

v8:
- add prefix "public-" to newly introduced macros.
- make use of the new "$(srcdir)" shortcut.

 xen/include/Makefile | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 5a2b4c9f65fa..fddf5a575bf6 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -39,8 +39,8 @@ cppflags-$(CONFIG_X86)+= -m32
 
 endif
 
-public-$(CONFIG_X86) := $(wildcard $(src)/public/arch-x86/*.h 
$(src)/public/arch-x86/*/*.h)
-public-$(CONFIG_ARM) := $(wildcard $(src)/public/arch-arm/*.h 
$(src)/public/arch-arm/*/*.h)
+public-$(CONFIG_X86) := $(wildcard $(srcdir)/public/arch-x86/*.h 
$(srcdir)/public/arch-x86/*/*.h)
+public-$(CONFIG_ARM) := $(wildcard $(srcdir)/public/arch-arm/*.h 
$(srcdir)/public/arch-arm/*/*.h)
 
 .PHONY: all
 all: $(addprefix $(obj)/,$(headers-y))
@@ -81,10 +81,23 @@ ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
 
 all: $(obj)/headers.chk $(obj)/headers99.chk $(obj)/headers++.chk
 
-PUBLIC_HEADERS := $(filter-out $(src)/public/arch-% $(src)/public/dom0_ops.h, 
$(wildcard $(src)/public/*.h $(src)/public/*/*.h) $(public-y))
+public-hdrs-path := $(srcdir)/public
 
-PUBLIC_C99_HEADERS := $(src)/public/io/9pfs.h $(src)/public/io/pvcalls.h
-PUBLIC_ANSI_HEADERS := $(filter-out $(src)/public/%ctl.h $(src)/public/xsm/% 
$(src)/public/%hvm/save.h $(PUBLIC_C99_HEADERS), $(PUBLIC_HEADERS))
+public-list-headers = $(wildcard $1/*.h $1/*/*.h)
+public-filter-headers = $(filter-out $(addprefix $(public-hdrs-path)/, 
$($1-filter)), $($1))
+
+public-headers := $(call public-list-headers, $(public-hdrs-path)) $(public-y)
+public-ansi-headers := $(public-headers)
+public-c99-headers := $(addprefix $(public-hdrs-path)/, io/9pfs.h io/pvcalls.h)
+
+public-headers-filter := dom0_ops.h arch-%
+public-ansi-headers-filter := %ctl.h xsm/% %hvm/save.h 
$(public-headers-filter) \
+$(patsubst $(public-hdrs-path)/%,%,$(public-c99-headers))
+public-c99-headers-filter :=
+
+PUBLIC_HEADERS := $(call public-filter-headers,public-headers)
+PUBLIC_ANSI_HEADERS := $(call public-filter-headers,public-ansi-headers)
+PUBLIC_C99_HEADERS := $(call public-filter-headers,public-c99-headers)
 
 $(src)/public/io/9pfs.h-prereq := string
 $(src)/public/io/pvcalls.h-prereq := string
-- 
Anthony PERARD

[XEN PATCH v10 2/7] build: replace $(BASEDIR) by $(objtree)

[Anthony PERARD]

We need to differentiate between source files and generated/built
files. We will be replacing $(BASEDIR) by $(objtree) for files that
are generated.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---

Notes:
v9:
- acked

v8:
- rebased

 xen/Rules.mk|  2 +-
 xen/arch/arm/Makefile   | 10 +-
 xen/arch/x86/Makefile   | 28 ++--
 xen/common/Makefile |  2 +-
 xen/test/livepatch/Makefile | 12 ++--
 5 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index abeba1ab7494..7712bfa063e0 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -12,7 +12,7 @@ src := $(obj)
 PHONY := __build
 __build:
 
--include $(BASEDIR)/include/config/auto.conf
+-include $(objtree)/include/config/auto.conf
 
 include $(XEN_ROOT)/Config.mk
 include $(BASEDIR)/scripts/Kbuild.include
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 51ec2ba928e3..1d862351d111 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -90,21 +90,21 @@ ifeq ($(CONFIG_ARM_64),y)
ln -sf $(@F) $@.efi
 endif
 
-$(TARGET)-syms: $(BASEDIR)/prelink.o $(obj)/xen.lds
+$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< \
-   $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
+   $(objtree)/common/symbols-dummy.o -o $(@D)/.$(@F).0
$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
-   | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort 
>$(@D)/.$(@F).0.S
+   | $(objtree)/tools/symbols $(all_symbols) --sysv --sort 
>$(@D)/.$(@F).0.S
$(MAKE) $(build)=$(@D) $(@D)/.$(@F).0.o
$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
-   | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort 
>$(@D)/.$(@F).1.S
+   | $(objtree)/tools/symbols $(all_symbols) --sysv --sort 
>$(@D)/.$(@F).1.S
$(MAKE) $(build)=$(@D) $(@D)/.$(@F).1.o
$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
$(@D)/.$(@F).1.o -o $@
$(NM) -pa --format=sysv $(@D)/$(@F) \
-   | $(BASEDIR)/tools/symbols --all-symbols --xensyms --sysv 
--sort \
+   | $(objtree)/tools/symbols --all-symbols --xensyms --sysv 
--sort \
>$(@D)/$(@F).map
rm -f $(@D)/.$(@F).[0-9]*
 
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b6b082ee1d14..7cea79ed2f8a 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -92,8 +92,8 @@ ifneq ($(CONFIG_HVM),y)
 $(obj)/x86_emulate.o: CFLAGS-y += -Wno-unused-label
 endif
 
-efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
-  -O $(BASEDIR)/include/xen/compile.h ]; then \
+efi-y := $(shell if [ ! -r $(objtree)/include/xen/compile.h -o \
+  -O $(objtree)/include/xen/compile.h ]; then \
  echo '$(TARGET).efi'; fi) \
  $(space)
 efi-$(CONFIG_PV_SHIM_EXCLUSIVE) :=
@@ -133,23 +133,23 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
 
 CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
 
-$(TARGET)-syms: $(BASEDIR)/prelink.o $(obj)/xen.lds
+$(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
-   $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
+   $(objtree)/common/symbols-dummy.o -o $(@D)/.$(@F).0
$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
-   | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort \
+   | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \
>$(@D)/.$(@F).0.S
$(MAKE) $(build)=$(@D) $(@D)/.$(@F).0.o
$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
-   | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort 
$(syms-warn-dup-y) \
+   | $(objtree)/tools/symbols $(all_symbols) --sysv --sort 
$(syms-warn-dup-y) \
>$(@D)/.$(@F).1.S
$(MAKE) $(build)=$(@D) $(@D)/.$(@F).1.o
$(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds -N $< $(build_id_linker) \
$(orphan-handling-y) $(@D)/.$(@F).1.o -o $@
$(NM) -pa --format=sysv $(@D)/$(@F) \
-   | $(BASEDIR)/tools/symbols --all-symbols --xensyms --sysv 
--sort \
+   | $(objtree)/tools/symbols --all-symbols --xensyms --sysv 
--sort \
>$(@D)/$(@F).map
rm -f $(@D)/.$(@F).[0-9]* $(@D)/..$(@F).[0-9]*
 ifeq ($(CONFIG_XEN_IBT),y)
@@ -202,28 +202,28 @@ note_file_option ?= $(note_file)
 
 extra-$(XEN_BUILD_PE) += efi.lds
 ifeq ($(XEN_BUILD_PE),y)
-$(TARGET).efi: $(BASEDIR)/prelink.o $(note_file) $(obj)/efi.lds 
$(obj)/efi/relocs-dummy.o $(obj)/efi/mkreloc
+$(TARGET).efi: $(objtree)/prelink.o $(note_fil

[XEN PATCH v10 0/7] xen: Build system improvements, now with out-of-tree build!

[Anthony PERARD]

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git 
br.build-system-xen-v10

v10:
Mainly a rebase (changes needed in patches 1 and 3).
One comment change in patch 1.

v9:
One new patch (patch 3).
Otherwise, detailed change logs in patches.

Removed the rfc part about doing out-of-tree build without setting VPATH
(which would have allowed mixed in-tree / out-of-tree builds).

v8:
Mostly rework of v7. With many patch already applied.
Some detail changes that are spread through many patches:
- `make cloc` recipe should now work throughout the series, update of it is
  done in 3 patches.
- new patch "build: fix enforce unique symbols for recent clang version"
  to fix an issue with clang.
- introducing $(srctree) and $(objtree) earlier
- introducing $(srcdir) as shortcut for $(srctree)/$(src)
- introduce usage of -iquote instead of -I in some cases
More detail change log can be found in patches notes.

Also this v8 present a work-in-progress of the ability to do out-of-tree
build without setting VPATH. This is presented as an alternative to force
use of out-of-tree build. As the last patch show, it allows to build the
xen-shim without the linkfarm and we don't need to make any other changes
to any thing that build xen (osstest, distribution packages, xen.git, ...,
and developers finger macros). The patches are only there as WIP / RFC as
they were some concern about the usefulness and extra changes needed.
We can decide whether those changes are good or if this is too much and we
should force out-of-tree build for the hypervisor.

v7:
Out-of-tree build!

This mean many more patches. Everything after patch 27 is new.

There's a few new patch before that, but otherwise are rework of v6.

Hi,

I have work toward building Xen (the hypervisor) with Linux's build system,
Kbuild.

The main reason for that is to be able to have out-of-tree build. It's annoying
when a build fail because of the pvshim. Other benefit is a much faster
rebuild, and `make clean` doesn't take ages, and better dependencies to figure
out what needs to be rebuild.

Cheers,

Anthony PERARD (7):
  build: grab common EFI source files in arch specific dir
  build: replace $(BASEDIR) by $(objtree)
  build: replace $(BASEDIR) and use $(srctree)
  build: rework "headers*.chk" prerequisite in include/
  build: specify source tree in include/ for prerequisite
  build: shuffle main Makefile
  build: adding out-of-tree support to the xen build

 .gitignore   |   1 +
 xen/Kconfig  |   4 +-
 xen/Makefile | 187 +++
 xen/Rules.mk |  22 -
 xen/arch/arm/Makefile|  10 +-
 xen/arch/arm/efi/Makefile|   4 +-
 xen/arch/x86/Makefile|  32 +++---
 xen/arch/x86/arch.mk |   7 +-
 xen/arch/x86/boot/Makefile   |   6 ++
 xen/arch/x86/efi/Makefile|   5 +-
 xen/build.mk |   4 +-
 xen/common/Makefile  |   4 +-
 xen/common/efi/efi-common.mk |  16 +++
 xen/common/libfdt/Makefile   |   2 +-
 xen/include/Makefile |  60 ++-
 xen/scripts/Kconfig.include  |   2 +-
 xen/scripts/Makefile.clean   |   5 +-
 xen/test/livepatch/Makefile  |  14 +--
 xen/xsm/flask/Makefile   |  13 +--
 xen/xsm/flask/ss/Makefile|   1 +
 20 files changed, 283 insertions(+), 116 deletions(-)
 create mode 100644 xen/common/efi/efi-common.mk

-- 
Anthony PERARD

[XEN PATCH v10 1/7] build: grab common EFI source files in arch specific dir

[Anthony PERARD]

Rather than preparing the efi source file, we will make the symbolic
link as needed from the build location.

The `ln` command is run every time to allow to update the link in case
the source tree change location.

This patch also introduce "efi-common.mk" which allow to reuse the
common make instructions without having to duplicate them into each
arch.

And now that we have a list of common source file, we can start to
remove the links to the source files on clean.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---

Notes:
v10:
- acked
- small change to comment in efi_common.mk
- rebased, removed change "subdir- += efi" in xen/arch/x86/Makefile as
  it isn't needed anymore.

v9:
- rename efi_common.mk to efi-common.mk
- generalize comment about cleaning "efi" and "boot" subdir in x86.
- add a space after the other comma of $(patsubst )
- create a relative symlink instead of an absolute one
- with the above, we don't need to use $(abs_srctree) anymore in the
  prerequisite of the link to the efi source file, use $(srctree).

v8:
- use symbolic link instead of making a copy of the source
- introduce efi_common.mk
- remove links to source file on clean
- use -iquote for "efi.h" headers in common/efi

 xen/Makefile |  5 -
 xen/arch/arm/efi/Makefile|  4 ++--
 xen/arch/x86/efi/Makefile|  5 +
 xen/common/efi/efi-common.mk | 15 +++
 4 files changed, 18 insertions(+), 11 deletions(-)
 create mode 100644 xen/common/efi/efi-common.mk

diff --git a/xen/Makefile b/xen/Makefile
index 18a4f7e1015a..dec489f2a909 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -441,11 +441,6 @@ $(TARGET).gz: $(TARGET)
 $(TARGET): FORCE
$(Q)$(MAKE) $(build)=tools
$(Q)$(MAKE) $(build)=. include/xen/compile.h
-   [ -e arch/$(TARGET_ARCH)/efi ] && for f in $$(cd common/efi; echo 
*.[ch]); \
-   do test -r arch/$(TARGET_ARCH)/efi/$$f || \
-  ln -nsf ../../../common/efi/$$f arch/$(TARGET_ARCH)/efi/; \
-   done; \
-   true
$(Q)$(MAKE) $(build)=include all
$(Q)$(MAKE) $(build)=arch/$(TARGET_ARCH) include
$(Q)$(MAKE) $(build)=. arch/$(TARGET_ARCH)/include/asm/asm-offsets.h
diff --git a/xen/arch/arm/efi/Makefile b/xen/arch/arm/efi/Makefile
index 1b1ed06feddc..4313c390665f 100644
--- a/xen/arch/arm/efi/Makefile
+++ b/xen/arch/arm/efi/Makefile
@@ -1,4 +1,4 @@
-CFLAGS-y += -fshort-wchar
+include $(srctree)/common/efi/efi-common.mk
 
-obj-y += boot.init.o pe.init.o ebmalloc.o runtime.o
+obj-y += $(EFIOBJ-y)
 obj-$(CONFIG_ACPI) +=  efi-dom0.init.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index e08b4d8e4808..034ec87895df 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,4 +1,4 @@
-CFLAGS-y += -fshort-wchar
+include $(srctree)/common/efi/efi-common.mk
 
 quiet_cmd_objcopy_o_ihex = OBJCOPY $@
 cmd_objcopy_o_ihex = $(OBJCOPY) -I ihex -O binary $< $@
@@ -8,9 +8,6 @@ $(obj)/%.o: $(src)/%.ihex FORCE
 
 $(obj)/boot.init.o: $(obj)/buildid.o
 
-EFIOBJ-y := boot.init.o pe.init.o ebmalloc.o runtime.o
-EFIOBJ-$(CONFIG_COMPAT) += compat.o
-
 $(call cc-option-add,cflags-stack-boundary,CC,-mpreferred-stack-boundary=4)
 $(addprefix $(obj)/,$(EFIOBJ-y)): CFLAGS_stack_boundary := 
$(cflags-stack-boundary)
 
diff --git a/xen/common/efi/efi-common.mk b/xen/common/efi/efi-common.mk
new file mode 100644
index ..960d44a6d55b
--- /dev/null
+++ b/xen/common/efi/efi-common.mk
@@ -0,0 +1,15 @@
+EFIOBJ-y := boot.init.o pe.init.o ebmalloc.o runtime.o
+EFIOBJ-$(CONFIG_COMPAT) += compat.o
+
+CFLAGS-y += -fshort-wchar
+CFLAGS-y += -iquote $(srctree)/common/efi
+
+# Part of the command line transforms $(obj)
+# e.g.: It transforms "dir/foo/bar" into successively
+#   "dir foo bar", ".. .. ..", "../../.."
+$(obj)/%.c: $(srctree)/common/efi/%.c FORCE
+   $(Q)ln -nfs $(subst $(space),/,$(patsubst %,..,$(subst /, 
,$(obj/common/efi/$(

Re: [PATCH v2 3/3] Use g_new() & friends where that makes obvious sense

[Igor Mammedov]

On Tue, 15 Mar 2022 15:41:56 +0100
Markus Armbruster  wrote:

> g_new(T, n) is neater than g_malloc(sizeof(T) * n).  It's also safer,
> for two reasons.  One, it catches multiplication overflowing size_t.
> Two, it returns T * rather than void *, which lets the compiler catch
> more type errors.
> 
> This commit only touches allocations with size arguments of the form
> sizeof(T).
> 
> Patch created mechanically with:
> 
> $ spatch --in-place --sp-file scripts/coccinelle/use-g_new-etc.cocci \
>--macro-file scripts/cocci-macro-file.h FILES...
> 
> Signed-off-by: Markus Armbruster 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Cédric Le Goater 
> Reviewed-by: Alex Bennée 
> Acked-by: Dr. David Alan Gilbert 


for */i386/*
Reviewed-by: Igor Mammedov 


nit:
possible miss, see below 

[...]
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index cf8e500514..0731f70410 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c

missed:

 pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);


> @@ -396,7 +396,7 @@ go_physmap:
>  
>  mr_name = memory_region_name(mr);
>  
> -physmap = g_malloc(sizeof(XenPhysmap));
> +physmap = g_new(XenPhysmap, 1);
>  
>  physmap->start_addr = start_addr;
>  physmap->size = size;
> @@ -1281,7 +1281,7 @@ static void xen_read_physmap(XenIOState *state)
>  return;
>  
>  for (i = 0; i < num; i++) {
> -physmap = g_malloc(sizeof (XenPhysmap));
> +physmap = g_new(XenPhysmap, 1);
>  physmap->phys_offset = strtoull(entries[i], NULL, 16);
>  snprintf(path, sizeof(path),
>  "/local/domain/0/device-model/%d/physmap/%s/start_addr",
> @@ -1410,7 +1410,7 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion 
> **ram_memory)
>  xen_pfn_t ioreq_pfn;
>  XenIOState *state;
>  
> -state = g_malloc0(sizeof (XenIOState));
> +state = g_new0(XenIOState, 1);
>  
>  state->xce_handle = xenevtchn_open(NULL, 0);
>  if (state->xce_handle == NULL) {
> @@ -1463,7 +1463,7 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion 
> **ram_memory)
>  }
>  
>  /* Note: cpus is empty at this point in init */
> -state->cpu_by_vcpu_id = g_malloc0(max_cpus * sizeof(CPUState *));
> +state->cpu_by_vcpu_id = g_new0(CPUState *, max_cpus);
>  
>  rc = xen_set_ioreq_server_state(xen_domid, state->ioservid, true);
>  if (rc < 0) {
> @@ -1472,7 +1472,7 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion 
> **ram_memory)
>  goto err;
>  }
>  
> -state->ioreq_local_port = g_malloc0(max_cpus * sizeof (evtchn_port_t));
> +state->ioreq_local_port = g_new0(evtchn_port_t, max_cpus);

[...]

[xen-unstable test] 168763: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  8aa0e9d2d1a4815516607eabe9b2e850f284a2f8
baseline version:
 xen  8aa0e9d2d1a48155

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

>>> 
>>> Can you document why this is necessary on x86 but not on other 
>>> architectures?
>> Hi Julien,
>> I received the warning by Juergen here: 
>> https://patchwork.kernel.org/comment/24740762/ that at least on x86 there 
>> could be
>> some problems if cpu0 is not in cpupool0, I tested it on arm and it was 
>> working fine and I didn’t find any restriction.
> 
> What exactly did you test on Arm?
> 

I have tested start/stop of some guest, moving cpus between cpupools, 
create/destroy cpupools, shutdown of Dom0


[ from your last mail ]
>>> 
>>> If dom0 must run on core0 and core0 is Little then you cannot build a 
>>> system where dom0 is running on big cores.
>>> If the limitation is not there, you can build such a configuration without 
>>> any dependency to the boot core type.
>> This might not be completely clear so let me rephrase:
>> In the current system:
>> - dom0 must run on cpupool-0
> 
> I don't think we need this restriction. In fact, with this series it will 
> become more a problem because the cpupool ID will based on how we parse the 
> Device-Tree.
> 
> So for dom0, we need to specify explicitely the cpupool to be used.
> 
>> - cpupool-0 must contain the boot core
>> - consequence: dom0 must run on the boot core
>> If boot core is little, you cannot build as system where dom0 runs only on 
>> the big cores.
>> Removing the second limitation (which is not required on arm) is making it 
>> possible.
> 
> IMHO removing the second restriction is a lot more risky than removing the 
> first one.

I see your point, my concern about moving Dom0 on another cpupool, different 
from cpupool0, is that we give the
opportunity to destroy the cpupool0 (we can’t let that happen), or remove every 
cpu from cpupool0.

Cheers,
Luca

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Bertrand Marquis]

Hi Julien,

> On 22 Mar 2022, at 10:16, Julien Grall  wrote:
> 
> Hi,
> 
> On 22/03/2022 08:47, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 22 Mar 2022, at 09:35, Bertrand Marquis  wrote:
>>> 
>>> Hi Julien,
>>> 
 On 21 Mar 2022, at 18:44, Julien Grall  wrote:
 
 Hi Bertrand,
 
 On 21/03/2022 17:19, Bertrand Marquis wrote:
>> On 21 Mar 2022, at 17:36, Julien Grall  wrote:
>>> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 
>>> maintainer have more knowledge about that and
>>> I can put a comment here.
>> 
>> On Arm, we are not yet supporting all the CPU features that x86 supports 
>> (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the 
>> restriction is just not there yet (or possibly hidden).
>> 
>> Therefore, before lifting the restriction on Arm (and other arch), I 
>> would like us to understand why it is necessary on x86.
>> 
>> We may not have the answer quickly, so is it going to be a problem to 
>> keep the restriction on Arm?
> I am ok to keep the limitation to have dom0 always running on cpu0.
> Only limitation I can see is that on a big little system, dom0 needs to 
> stay on the type of core of the first booted core.
 
 Where does this limitation come from?
>>> 
>>> If dom0 must run on core0 and core0 is Little then you cannot build a 
>>> system where dom0 is running on big cores.
>>> If the limitation is not there, you can build such a configuration without 
>>> any dependency to the boot core type.
>> This might not be completely clear so let me rephrase:
>> In the current system:
>> - dom0 must run on cpupool-0
> 
> I don't think we need this restriction. In fact, with this series it will 
> become more a problem because the cpupool ID will based on how we parse the 
> Device-Tree.
> 
> So for dom0, we need to specify explicitely the cpupool to be used.
> 
>> - cpupool-0 must contain the boot core
>> - consequence: dom0 must run on the boot core
>> If boot core is little, you cannot build as system where dom0 runs only on 
>> the big cores.
>> Removing the second limitation (which is not required on arm) is making it 
>> possible.
> 
> IMHO removing the second restriction is a lot more risky than removing the 
> first one.

So keeping boot core in cpupool-0 but allow Dom-0 to be in any pool.
Interesting, we will check that.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH 04/36] xen/arm: add parsing function for cache coloring configuration

[Luca Miccio]

Hi Julien,


Il giorno mer 9 mar 2022 alle ore 20:09 Julien Grall  ha
scritto:

> Hi,
>
> On 04/03/2022 17:46, Marco Solieri wrote:
> > From: Luca Miccio 
> >
> > Add three new bootargs allowing configuration of cache coloring support
> > for Xen:
>
> I would prefer if documentation of each command line is part of the
> patch introducing them. This would help understanding some of the
> parameters.
>
>
Ok.


> > - way_size: The size of a LLC way in bytes. This value is mainly used
> >to calculate the maximum available colors on the platform.
>
> We should only add command line option when they are a strong use case.
> In documentation, you wrote that someone may want to overwrite the way
> size for "specific needs".
>
> Can you explain what would be those needs?

> - dom0_colors: The coloring configuration for Dom0, which also acts as
> >default configuration for any DomU without an explicit configuration.
> > - xen_colors: The coloring configuration for the Xen hypervisor itself.
> >
> > A cache coloring configuration consists of a selection of colors to be
> > assigned to a VM or to the hypervisor. It is represented by a set of
> > ranges. Add a common function that parses a string with a
> > comma-separated set of hyphen-separated ranges like "0-7,15-16" and
> > returns both: the number of chosen colors, and an array containing their
> > ids.
> > Currently we support platforms with up to 128 colors.
>
> Is there any reason this value is hardcoded in Xen rather than part of
> the Kconfig?
>
>
Not really at the time when this patch was created. But as we notify in
patch 32,
there is an assert that fails if we use a certain amount of colors. Maybe
we should
find a better way to store the color information.

Luca.

> >
> > Signed-off-by: Luca Miccio 
> > Signed-off-by: Marco Solieri 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >   xen/arch/arm/Kconfig|   5 ++
> >   xen/arch/arm/Makefile   |   2 +-
> >   xen/arch/arm/coloring.c | 131 
> >   xen/arch/arm/include/asm/coloring.h |  28 ++
> >   4 files changed, 165 insertions(+), 1 deletion(-)
> >   create mode 100644 xen/arch/arm/coloring.c
> >   create mode 100644 xen/arch/arm/include/asm/coloring.h
> >
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index ecfa6822e4..f0f999d172 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -97,6 +97,11 @@ config HARDEN_BRANCH_PREDICTOR
> >
> > If unsure, say Y.
> >
> > +config COLORING
> > + bool "L2 cache coloring"
> > + default n
>
> This wants to be gated with EXPERT for time-being. SUPPORT.MD woudl
> Furthermore, I think this wants to be gated with EXPERT for the time-being.
>
> > + depends on ARM_64
>
> Why is this limited to arm64?
>
> > +
> >   config TEE
> >   bool "Enable TEE mediators support (UNSUPPORTED)" if UNSUPPORTED
> >   default n
> > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> > index c993ce72a3..581896a528 100644
> > --- a/xen/arch/arm/Makefile
> > +++ b/xen/arch/arm/Makefile
> > @@ -66,7 +66,7 @@ obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
> >   obj-y += vsmc.o
> >   obj-y += vpsci.o
> >   obj-y += vuart.o
> > -
> > +obj-$(CONFIG_COLORING) += coloring.o
>
> Please keep the newline before extra-y. The file are meant to be ordered
> alphabetically. So this should be inserted in the correct position.
>
> >   extra-y += xen.lds
> >
> >   #obj-bin-y += o
> > diff --git a/xen/arch/arm/coloring.c b/xen/arch/arm/coloring.c
> > new file mode 100644
> > index 00..8f1cff6efb
> > --- /dev/null
> > +++ b/xen/arch/arm/coloring.c
> > @@ -0,0 +1,131 @@
> > +/*
> > + * xen/arch/arm/coloring.c
> > + *
> > + * Coloring support for ARM
> > + *
> > + * Copyright (C) 2019 Xilinx Inc.
> > + *
> > + * Authors:
> > + *Luca Miccio 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program.  If not, see  >.
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> The includes should be ordered so  are first, then .
> They are also ordered alphabetically within their own category.
>
> > +
> > +/* Number of color(s) assigned to Xen */
> > +static uint32_t xen_col_num;
> > +/* Coloring configuration of Xen as bitmask */
> > +static uint32_t xen_col_mask[MAX_COLORS_CELLS];
> Xen provides helpers to create and use bitmaps (see
> include/xen/b

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi,

On 22/03/2022 08:47, Bertrand Marquis wrote:

Hi Julien,


On 22 Mar 2022, at 09:35, Bertrand Marquis  wrote:

Hi Julien,


On 21 Mar 2022, at 18:44, Julien Grall  wrote:

Hi Bertrand,

On 21/03/2022 17:19, Bertrand Marquis wrote:

On 21 Mar 2022, at 17:36, Julien Grall  wrote:

So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer 
have more knowledge about that and
I can put a comment here.


On Arm, we are not yet supporting all the CPU features that x86 supports (e.g. 
CPU hotplug, suspend/resume...). So I a am bit concerned that the restriction 
is just not there yet (or possibly hidden).

Therefore, before lifting the restriction on Arm (and other arch), I would like 
us to understand why it is necessary on x86.

We may not have the answer quickly, so is it going to be a problem to keep the 
restriction on Arm?

I am ok to keep the limitation to have dom0 always running on cpu0.
Only limitation I can see is that on a big little system, dom0 needs to stay on 
the type of core of the first booted core.


Where does this limitation come from?


If dom0 must run on core0 and core0 is Little then you cannot build a system 
where dom0 is running on big cores.
If the limitation is not there, you can build such a configuration without any 
dependency to the boot core type.


This might not be completely clear so let me rephrase:
In the current system:
- dom0 must run on cpupool-0


I don't think we need this restriction. In fact, with this series it 
will become more a problem because the cpupool ID will based on how we 
parse the Device-Tree.


So for dom0, we need to specify explicitely the cpupool to be used.


- cpupool-0 must contain the boot core
- consequence: dom0 must run on the boot core

If boot core is little, you cannot build as system where dom0 runs only on the 
big cores.
Removing the second limitation (which is not required on arm) is making it 
possible.


IMHO removing the second restriction is a lot more risky than removing 
the first one.


Cheers,

--
Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

>> +- cpupool-sched (optional)
>> +
>> +Must be a string having the name of a Xen scheduler, it has no effect 
>> when
>> +used in conjunction of a cpupool-id equal to zero, in that case the
>> +default Xen scheduler is selected (sched=<...> boot argument).
>> +Check the sched=<...> boot argument for allowed values.
> 
> I am happy with this version of the device tree bindings, thanks for
> your efforts to update them. Only one comment left: please update the
> description not to include "cpupool-id" given that there is no
> cpupool-id property anymore :-)
> 

Hi Stefano,

Thank you for your review,

Yes I missed that! I will fix in the next serie.

>> 
>> +/*
>> + * pool_cpu_map:   Index is logical cpu number, content is cpupool id, (-1) 
>> for
>> + * unassigned.
>> + * pool_sched_map: Index is cpupool id, content is scheduler id, (-1) for
>> + * unassigned.
>> + */
>> +static int __initdata pool_cpu_map[NR_CPUS]   = { [0 ... NR_CPUS-1] = -1 };
>> +static int __initdata pool_sched_map[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 };
>> +static unsigned int __initdata next_pool_id;
>> +
>> +#ifdef CONFIG_HAS_DEVICE_TREE
> 
> BOOT_TIME_CPUPOOLS depends on HAS_DEVICE_TREE, so it is not possible to
> have BOOT_TIME_CPUPOOLS but not HAS_DEVICE_TREE ?

Yes you are right, the ifdef is not needed at this stage since only arch with 
device tree are
using it, if x86 would like to implement a command line version then the code 
will be ifdef-ined
later.

> 
> 
>> +#define BTCPUPOOLS_DT_NODE_NO_REG (-1)
>> +#define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
>> +
>> +static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
>> +{
>> +unsigned int i;
>> +
>> +for ( i = 0; i < nr_cpu_ids; i++ )
>> +if ( cpu_physical_id(i) == hwid )
>> +return i;
>> +
>> +return -1;
>> +}
> 
> I wonder if there is a better way to implement this function but I am
> not sure. Also, it might be better to avoid premature optimizations.
> 
> That said, we could check first the simple case where hwid==i. Looking
> at various existing device tree, it seems to be the most common case.
> 
> This is not a requirement, just a hand-wavy suggestion. I think the
> patch is also OK as is.
> 

Not sure to understand here, at least on FVP (the first DT I have around), hwid 
!= i,
Or maybe I didn’t understand what you mean

> 
>> +void __init btcpupools_allocate_pools(void)
>> +{
>> +unsigned int i;
>> +bool add_extra_cpupool = false;
>> +
>> +/*
>> + * If there are no cpupools, the value of next_pool_id is zero, so the 
>> code
>> + * below will assign every cpu to cpupool0 as the default behavior.
>> + * When there are cpupools, the code below is assigning all the not
>> + * assigned cpu to a new pool (next_pool_id value is the last id + 1).
>> + * In the same loop we check if there is any assigned cpu that is not
>> + * online.
>> + */
>> +for ( i = 0; i < nr_cpu_ids; i++ )
>> +if ( cpumask_test_cpu(i, &cpu_online_map) )
> 
> Let me take this opportunity to explain the unfortunately unwritten
> coding style the way I understand it. I know this is tribal knowledge at
> the moment and I apologize for that.
> 
> If it is a single line statement, we skip the { }, we keep them in all
> other cases.
> 
> So:
> 
>  /* correct */
>  if ( xxx ) {
>  something;
>  something else;
>  }
> 
>  /* correct */
>  if ( xxx ) {
>  for ( yyy ) {
>  }
>  }
> 
>  /* correct */
>  if ( xxx )
>  something single line or 2 lines like a printk that go beyond 80
>  chars, never in case of nested ifs
> 
>  /* not correct */
>  if ( xxx )
>  something
>  multi
>  line;
> 
>  /* not correct */
>  if ( xxx )
>  if ( yyy )
>  something;
> 
> So basically we would keep the { } here but we would skip them ...

Ok this clarifies a lot, thank you, I will check the code and I will fix it 
where it’s not
compliant.

> 
>> +#ifdef CONFIG_HAS_DEVICE_TREE
>> +void btcpupools_dtb_parse(void);
>> +#else
>> +static inline void btcpupools_dtb_parse(void) {}
>> +#endif
> 
> same comment about !CONFIG_HAS_DEVICE_TREE

Yes I will fix it in the next serie.

Cheers,
Luca

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Bertrand Marquis]

Hi Julien,

> On 22 Mar 2022, at 09:35, Bertrand Marquis  wrote:
> 
> Hi Julien,
> 
>> On 21 Mar 2022, at 18:44, Julien Grall  wrote:
>> 
>> Hi Bertrand,
>> 
>> On 21/03/2022 17:19, Bertrand Marquis wrote:
 On 21 Mar 2022, at 17:36, Julien Grall  wrote:
> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 
> maintainer have more knowledge about that and
> I can put a comment here.
 
 On Arm, we are not yet supporting all the CPU features that x86 supports 
 (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the 
 restriction is just not there yet (or possibly hidden).
 
 Therefore, before lifting the restriction on Arm (and other arch), I would 
 like us to understand why it is necessary on x86.
 
 We may not have the answer quickly, so is it going to be a problem to keep 
 the restriction on Arm?
>>> I am ok to keep the limitation to have dom0 always running on cpu0.
>>> Only limitation I can see is that on a big little system, dom0 needs to 
>>> stay on the type of core of the first booted core.
>> 
>> Where does this limitation come from?
> 
> If dom0 must run on core0 and core0 is Little then you cannot build a system 
> where dom0 is running on big cores.
> If the limitation is not there, you can build such a configuration without 
> any dependency to the boot core type.

This might not be completely clear so let me rephrase:
In the current system:
- dom0 must run on cpupool-0
- cpupool-0 must contain the boot core
- consequence: dom0 must run on the boot core

If boot core is little, you cannot build as system where dom0 runs only on the 
big cores.
Removing the second limitation (which is not required on arm) is making it 
possible.

Regards
Bertrand

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Bertrand Marquis]

Hi Julien,

> On 21 Mar 2022, at 18:44, Julien Grall  wrote:
> 
> Hi Bertrand,
> 
> On 21/03/2022 17:19, Bertrand Marquis wrote:
>>> On 21 Mar 2022, at 17:36, Julien Grall  wrote:
 So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 
 maintainer have more knowledge about that and
 I can put a comment here.
>>> 
>>> On Arm, we are not yet supporting all the CPU features that x86 supports 
>>> (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the 
>>> restriction is just not there yet (or possibly hidden).
>>> 
>>> Therefore, before lifting the restriction on Arm (and other arch), I would 
>>> like us to understand why it is necessary on x86.
>>> 
>>> We may not have the answer quickly, so is it going to be a problem to keep 
>>> the restriction on Arm?
>> I am ok to keep the limitation to have dom0 always running on cpu0.
>> Only limitation I can see is that on a big little system, dom0 needs to stay 
>> on the type of core of the first booted core.
> 
> Where does this limitation come from?

If dom0 must run on core0 and core0 is Little then you cannot build a system 
where dom0 is running on big cores.
If the limitation is not there, you can build such a configuration without any 
dependency to the boot core type.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

[ovmf test] 168770: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 168254
 build-amd64   6 xen-buildfail REGR. vs. 168254
 build-i386-xsm6 xen-buildfail REGR. vs. 168254
 build-i3866 xen-buildfail REGR. vs. 168254

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 267a92fef3b705e6a3ecbeaa4d4b58f7bfac9734
baseline version:
 ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70

Last test of basis   168254  2022-02-28 10:41:46 Z   21 days
Failing since168258  2022-03-01 01:55:31 Z   21 days  219 attempts
Testing same since   168738  2022-03-21 02:39:18 Z1 days   18 attempts


People who touched revisions under test:
  Abdul Lateef Attar 
  Abdul Lateef Attar via groups.io 
  Abner Chang 
  Bandaru, Purna Chandra Rao 
  Gerd Hoffmann 
  Guo Dong 
  Guomin Jiang 
  Hao A Wu 
  Hua Ma 
  Huang, Li-Xia 
  Jagadeesh Ujja 
  Jason 
  Jason Lou 
  Ken Lautner 
  Kenneth Lautner 
  Kuo, Ted 
  Li, Zhihao 
  Lixia Huang 
  Lou, Yun 
  Ma, Hua 
  Matt DeVillier 
  Michael Kubacki 
  Patrick Rudolph 
  Purna Chandra Rao Bandaru 
  Sami Mujawar 
  Sean Rhodes 
  Sebastien Boeuf 
  Sunny Wang 
  Ted Kuo 
  Wenyi Xie 
  wenyi,xie via groups.io 
  Xiaolu.Jiang 
  Zhihao Li 

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



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


Not pushing.

(No revision log; it would be 859 lines long.)

[PATCH v2 2/2] xen: Populate xen.lds.h and make use of its macros

[Michal Orzel]

Populate header file xen.lds.h with the first portion of macros storing
constructs common to x86 and arm linker scripts. Replace the original
constructs with these helpers.

No functional improvements to x86 linker script.

Making use of common macros improves arm linker script with:
-explicit list of debug sections that otherwise are seen as "orphans"
by the linker. This will allow to fix issues after enabling linker
option --orphan-handling one day
-extended list of discarded section to include: .discard, desctructors
related sections, .fini_array which can reference .text.exit
-sections not related to debugging that are placed by ld.lld.
Even though Xen on arm compilation with LLVM support is not ready yet,
these sections do not cause problem to GNU ld.

Please note that this patch does not aim to perform the full sync up
between the linker scripts. It creates a base for further work.

Signed-off-by: Michal Orzel 
---
Changes since v1:
-merge x86 and arm changes into single patch
-do not propagate issues by generalizing CTORS
-extract sections not related to debugging into separate macro
-get rid of _SECTION suffix in favor of using more meaningful suffixes
---
 xen/arch/arm/xen.lds.S|  37 +-
 xen/arch/x86/xen.lds.S|  78 +++--
 xen/include/xen/xen.lds.h | 100 ++
 3 files changed, 119 insertions(+), 96 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index c666fc3e69..e8ce7ad5f1 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -69,10 +69,7 @@ SECTIONS
__proc_info_end = .;
 
 #ifdef CONFIG_HAS_VPCI
-   . = ALIGN(POINTER_ALIGN);
-   __start_vpci_array = .;
-   *(SORT(.data.vpci.*))
-   __end_vpci_array = .;
+   VPCI_ARRAY
 #endif
   } :text
 
@@ -110,10 +107,7 @@ SECTIONS
__end_schedulers_array = .;
 
 #ifdef CONFIG_HYPFS
-   . = ALIGN(8);
-   __paramhypfs_start = .;
-   *(.data.paramhypfs)
-   __paramhypfs_end = .;
+   HYPFS_PARAM
 #endif
 
*(.data .data.*)
@@ -179,10 +173,7 @@ SECTIONS
__alt_instructions_end = .;
 
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
-   . = ALIGN(POINTER_ALIGN);
-   __lock_profile_start = .;
-   *(.lockprofile.data)
-   __lock_profile_end = .;
+   LOCK_PROFILE_DATA
 #endif
 
*(.init.data)
@@ -222,22 +213,18 @@ SECTIONS
   /* Section for the device tree blob (if any). */
   .dtb : { *(.dtb) } :text
 
+  /*
+   * Explicitly list debug sections, to avoid these sections being viewed as
+   * "orphan" by the linker.
+   */
+  DWARF_DEBUG_SECTIONS
+
   /* Sections to be discarded */
-  /DISCARD/ : {
-   *(.exit.text)
-   *(.exit.data)
-   *(.exitcall.exit)
-   *(.eh_frame)
-  }
+  DISCARD_SECTIONS
 
   /* Stabs debugging sections.  */
-  .stab 0 : { *(.stab) }
-  .stabstr 0 : { *(.stabstr) }
-  .stab.excl 0 : { *(.stab.excl) }
-  .stab.exclstr 0 : { *(.stab.exclstr) }
-  .stab.index 0 : { *(.stab.index) }
-  .stab.indexstr 0 : { *(.stab.indexstr) }
-  .comment 0 : { *(.comment) }
+  STABS_DEBUG_SECTIONS
+  ELF_DETAILS_SECTIONS
 }
 
 /*
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 4e3a9a2789..65efbf9d0c 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -13,13 +13,6 @@
 #undef __XEN_VIRT_START
 #define __XEN_VIRT_START __image_base__
 #define DECL_SECTION(x) x :
-/*
- * Use the NOLOAD directive, despite currently ignored by (at least) GNU ld
- * for PE output, in order to record that we'd prefer these sections to not
- * be loaded into memory.
- */
-#define DECL_DEBUG(x, a) #x ALIGN(a) (NOLOAD) : { *(x) }
-#define DECL_DEBUG2(x, y, a) #x ALIGN(a) (NOLOAD) : { *(x) *(y) }
 
 ENTRY(efi_start)
 
@@ -27,8 +20,6 @@ ENTRY(efi_start)
 
 #define FORMAT "elf64-x86-64"
 #define DECL_SECTION(x) #x : AT(ADDR(#x) - __XEN_VIRT_START)
-#define DECL_DEBUG(x, a) #x 0 : { *(x) }
-#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
 
 ENTRY(start_pa)
 
@@ -160,10 +151,7 @@ SECTIONS
__note_gnu_build_id_end = .;
 #endif
 #ifdef CONFIG_HAS_VPCI
-   . = ALIGN(POINTER_ALIGN);
-   __start_vpci_array = .;
-   *(SORT(.data.vpci.*))
-   __end_vpci_array = .;
+   VPCI_ARRAY
 #endif
   } PHDR(text)
 
@@ -279,10 +267,7 @@ SECTIONS
 __alt_instructions_end = .;
 
 #ifdef CONFIG_DEBUG_LOCK_PROFILE
-   . = ALIGN(POINTER_ALIGN);
-   __lock_profile_start = .;
-   *(.lockprofile.data)
-   __lock_profile_end = .;
+   LOCK_PROFILE_DATA
 #endif
 
. = ALIGN(8);
@@ -336,10 +321,7 @@ SECTIONS
__end_schedulers_array = .;
 
 #ifdef CONFIG_HYPFS
-   . = ALIGN(8);
-   __paramhypfs_start = .;
-   *(.data.paramhypfs)
-   __paramhypfs_end = .;
+   HYPFS_PARAM
 #endif
   } PHDR(text)
 
@@ -396,24 +378,7 @@ SECTIONS
* _end here, so if these sections get loaded they'll be discarded at runtime
* anyway.
*/
-  DECL_DEBUG(.debug_abbrev, 1)
-  DECL_DEBUG2(.debug_info, .gnu.link

[PATCH v2 0/2] xen: Linker scripts synchronization

[Michal Orzel]

This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defined in just one place.

The first patch creates an empty header file xen.lds.h to store the
constructs mutual to both x86 and arm linker scripts. It also includes
this header in the scripts.

The second patch populates xen.lds.h with the first portion of common
macros and replaces the original contructs with these helpers.

Michal Orzel (2):
  xen: Introduce a header to store common linker scripts content
  xen: Populate xen.lds.h and make use of its macros

 xen/arch/arm/xen.lds.S|  38 +-
 xen/arch/x86/xen.lds.S|  79 +++-
 xen/include/xen/xen.lds.h | 108 ++
 3 files changed, 129 insertions(+), 96 deletions(-)
 create mode 100644 xen/include/xen/xen.lds.h

-- 
2.25.1

[PATCH v2 1/2] xen: Introduce a header to store common linker scripts content

[Michal Orzel]

Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen.lds.h to store the internals mutual to all
the linker scripts.

Include this header in linker scripts for x86 and arm.
This patch serves as an intermediate step before populating xen.lds.h
and making use of its content in the linker scripts later on.

Signed-off-by: Michal Orzel 
---
Changes since v1:
-rename header to xen.lds.h to be coherent with Linux kernel
-include empty header in linker scripts
---
 xen/arch/arm/xen.lds.S| 1 +
 xen/arch/x86/xen.lds.S| 1 +
 xen/include/xen/xen.lds.h | 8 
 3 files changed, 10 insertions(+)
 create mode 100644 xen/include/xen/xen.lds.h

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 7921d8fa28..c666fc3e69 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -3,6 +3,7 @@
 /* Modified for ARM Xen by Ian Campbell */
 
 #include 
+#include 
 #include 
 #undef ENTRY
 #undef ALIGN
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d33e295320..4e3a9a2789 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -2,6 +2,7 @@
 /* Modified for i386/x86-64 Xen by Keir Fraser */
 
 #include 
+#include 
 #include 
 #undef ENTRY
 #undef ALIGN
diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
new file mode 100644
index 00..dd292fa7dc
--- /dev/null
+++ b/xen/include/xen/xen.lds.h
@@ -0,0 +1,8 @@
+#ifndef __XEN_LDS_H__
+#define __XEN_LDS_H__
+
+/*
+ * Common macros to be used in architecture specific linker scripts.
+ */
+
+#endif /* __XEN_LDS_H__ */
-- 
2.25.1

Re: "BUG: using smp_processor_id() in preemptible" on resume from S3

[Juergen Gross]

Hi Marek,

On 21.03.22 23:26, Marek Marczykowski-Górecki wrote:

Hi,

After updating from 5.14.15 dom0 kernel to 5.16.13 I started getting
this on resume from S3:

[   88.082751] ACPI: PM: Low-level resume complete
[   88.087933] ACPI: EC: EC started
[   88.091464] ACPI: PM: Restoring platform NVS memory
[   88.097166] xen_acpi_processor: Uploading Xen processor PM info
[   88.103850] Enabling non-boot CPUs ...
[   88.108128] installing Xen timer for CPU 1
[   88.112763] BUG: using smp_processor_id() in preemptible [] code: 
systemd-sleep/7138
[   88.122256] caller is is_xen_pmu+0x12/0x30
[   88.126937] CPU: 0 PID: 7138 Comm: systemd-sleep Tainted: GW 
5.16.13-2.fc32.qubes.x86_64 #1
[   88.137939] Hardware name: Star Labs StarBook/StarBook, BIOS 7.97 03/21/2022
[   88.145930] Call Trace:
[   88.148757]  
[   88.151193]  dump_stack_lvl+0x48/0x5e
[   88.155381]  check_preemption_disabled+0xde/0xe0
[   88.160641]  is_xen_pmu+0x12/0x30
[   88.164441]  xen_smp_intr_init_pv+0x75/0x100
[   88.169311]  ? xen_read_cr0+0x20/0x20
[   88.173502]  xen_cpu_up_prepare_pv+0x3e/0x90


Thanks for the report.

Could you please test whether the attached patch is helping?


Juergen
From 52d3e1a690e4eff152b8aeb8df4c99e3f40f296c Mon Sep 17 00:00:00 2001
From: Juergen Gross 
To: x...@kernel.org
To: linux-ker...@vger.kernel.org
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: "H. Peter Anvin" 
Cc: xen-devel@lists.xenproject.org
Date: Tue, 22 Mar 2022 07:35:14 +0100
Subject: [PATCH] xen: fix is_xen_pmu()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

is_xen_pmu() is taking the cpu number as parameter, but it is not using
it. Instead it just tests whether the Xen PMU initialization on the
current cpu did succeed. As this test is done by checking a percpu
pointer, preemption needs to be disabled in order to avoid switching
the cpu while doing the test. While resuming from suspend() this seems
not to be the case:

[   88.082751] ACPI: PM: Low-level resume complete
[   88.087933] ACPI: EC: EC started
[   88.091464] ACPI: PM: Restoring platform NVS memory
[   88.097166] xen_acpi_processor: Uploading Xen processor PM info
[   88.103850] Enabling non-boot CPUs ...
[   88.108128] installing Xen timer for CPU 1
[   88.112763] BUG: using smp_processor_id() in preemptible [] code: systemd-sleep/7138
[   88.122256] caller is is_xen_pmu+0x12/0x30
[   88.126937] CPU: 0 PID: 7138 Comm: systemd-sleep Tainted: GW 5.16.13-2.fc32.qubes.x86_64 #1
[   88.137939] Hardware name: Star Labs StarBook/StarBook, BIOS 7.97 03/21/2022
[   88.145930] Call Trace:
[   88.148757]  
[   88.151193]  dump_stack_lvl+0x48/0x5e
[   88.155381]  check_preemption_disabled+0xde/0xe0
[   88.160641]  is_xen_pmu+0x12/0x30
[   88.164441]  xen_smp_intr_init_pv+0x75/0x100

Fix that by replacing is_xen_pmu() by a simple boolean variable which
reflects the Xen PMU initialization state on cpu 0.

Modify xen_pmu_init() to return early in case it is being called for a
cpu other than cpu 0 and the boolean variable not being set.

Fixes: bf6dfb154d93 ("xen/PMU: PMU emulation code")
Reported-by: Marek Marczykowski-Górecki 
Signed-off-by: Juergen Gross 
---
 arch/x86/xen/pmu.c| 11 ++-
 arch/x86/xen/pmu.h|  3 ++-
 arch/x86/xen/smp_pv.c |  2 +-
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index 89dd6b1708b0..0efe452eb13e 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -506,10 +506,7 @@ irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id)
 	return ret;
 }
 
-bool is_xen_pmu(int cpu)
-{
-	return (get_xenpmu_data() != NULL);
-}
+bool is_xen_pmu;
 
 void xen_pmu_init(int cpu)
 {
@@ -520,7 +517,7 @@ void xen_pmu_init(int cpu)
 
 	BUILD_BUG_ON(sizeof(struct xen_pmu_data) > PAGE_SIZE);
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || (cpu != 0 && !is_xen_pmu))
 		return;
 
 	xenpmu_data = (struct xen_pmu_data *)get_zeroed_page(GFP_KERNEL);
@@ -542,6 +539,7 @@ void xen_pmu_init(int cpu)
 	per_cpu(xenpmu_shared, cpu).flags = 0;
 
 	if (cpu == 0) {
+		is_xen_pmu = true;
 		perf_register_guest_info_callbacks(&xen_guest_cbs);
 		xen_pmu_arch_init();
 	}
@@ -572,4 +570,7 @@ void xen_pmu_finish(int cpu)
 
 	free_pages((unsigned long)per_cpu(xenpmu_shared, cpu).xenpmu_data, 0);
 	per_cpu(xenpmu_shared, cpu).xenpmu_data = NULL;
+
+	if (cpu == 0)
+		is_xen_pmu = false;
 }
diff --git a/arch/x86/xen/pmu.h b/arch/x86/xen/pmu.h
index 0e83a160589b..65c58894fc79 100644
--- a/arch/x86/xen/pmu.h
+++ b/arch/x86/xen/pmu.h
@@ -4,6 +4,8 @@
 
 #include 
 
+extern bool is_xen_pmu;
+
 irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id);
 #ifdef CONFIG_XEN_HAVE_VPMU
 void xen_pmu_init(int cpu);
@@ -12,7 +14,6 @@ void xen_pmu_finish(int cpu);
 static inline void xen_pmu_init(int cpu) {}
 static inline void xen_pmu_finish(int cpu) {}
 #endif
-bool