[qemu-upstream-unstable test] 175938: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 175938 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175938/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt broken
 test-armhf-armhf-libvirt-qcow2 broken
 test-armhf-armhf-libvirt-raw broken
 test-armhf-armhf-xl  broken
 test-armhf-armhf-xl-credit2  broken
 test-armhf-armhf-xl-cubietruck broken
 test-armhf-armhf-xl-multivcpu broken
 test-armhf-armhf-xl-rtds broken
 test-armhf-armhf-xl-vhd  broken
 test-armhf-armhf-xl-credit1  broken
 test-armhf-armhf-xl-arndale  broken
 test-armhf-armhf-xl-vhd   5 host-install(5)broken REGR. vs. 175283
 test-armhf-armhf-xl-multivcpu  5 host-install(5)   broken REGR. vs. 175283
 test-armhf-armhf-libvirt-qcow2  5 host-install(5)  broken REGR. vs. 175283
 test-armhf-armhf-xl-credit2   5 host-install(5)broken REGR. vs. 175283
 test-armhf-armhf-xl-arndale   5 host-install(5)broken REGR. vs. 175283
 test-armhf-armhf-libvirt-raw  5 host-install(5)broken REGR. vs. 175283
 test-armhf-armhf-xl-credit1   5 host-install(5)broken REGR. vs. 175283
 test-armhf-armhf-libvirt  5 host-install(5)broken REGR. vs. 175283
 test-armhf-armhf-xl-cubietruck  5 host-install(5)  broken REGR. vs. 175283
 test-armhf-armhf-xl   5 host-install(5)broken REGR. vs. 175283
 build-amd64   6 xen-buildfail REGR. vs. 175283
 build-i386-xsm6 xen-buildfail REGR. vs. 175283
 build-amd64-xsm   6 xen-buildfail REGR. vs. 175283
 build-i3866 xen-buildfail REGR. vs. 175283

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  5 host-install(5)broken REGR. vs. 175283

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-vhd1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-raw   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-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-coresched-i386-xl  1 build-check(1)   blocked  n/a
 test-amd64-coresched-amd64-xl  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-dom0pvh-xl-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-dom0pvh-xl-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 

Re: [PATCH v4 2/4] xen/riscv: introduce sbi call to putchar to console

[Jan Beulich]

On 18.01.2023 00:32, Andrew Cooper wrote:
> On 16/01/2023 2:39 pm, Oleksii Kurochko wrote:
>> +struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
>> +unsigned long arg0, unsigned long arg1,
>> +unsigned long arg2, unsigned long arg3,
>> +unsigned long arg4, unsigned long arg5)
>> +{
>> +struct sbiret ret;
>> +
>> +register unsigned long a0 asm ("a0") = arg0;
>> +register unsigned long a1 asm ("a1") = arg1;
>> +register unsigned long a2 asm ("a2") = arg2;
>> +register unsigned long a3 asm ("a3") = arg3;
>> +register unsigned long a4 asm ("a4") = arg4;
>> +register unsigned long a5 asm ("a5") = arg5;
>> +register unsigned long a6 asm ("a6") = fid;
>> +register unsigned long a7 asm ("a7") = ext;
>> +
>> +asm volatile ("ecall"
>> +  : "+r" (a0), "+r" (a1)
>> +  : "r" (a2), "r" (a3), "r" (a4), "r" (a5), "r" (a6), "r" (a7)
>> +  : "memory");
> 
> Indentation.  Each colon wants 4 more spaces in front of it.

Plus, if we're already talking of style, blanks are missing immediately inside
the outermost parentheses, requiring yet one more space of indentation on the
subsequent lines.

Jan

Re: [PATCH 02/10] x86: split populating of struct vcpu_time_info into a separate function

[Jan Beulich]

On 17.01.2023 21:19, Andrew Cooper wrote:
> On 19/10/2022 8:39 am, Jan Beulich wrote:
>> This is to facilitate subsequent re-use of this code.
>>
>> While doing so add const in a number of places, extending to
>> gtime_to_gtsc() and then for symmetry also its inverse function.
>>
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Andrew Cooper 

Thanks.

>> ---
>> I was on the edge of also folding the various is_hvm_domain() into a
>> function scope boolean, but then wasn't really certain that this
>> wouldn't open up undue speculation opportunities.
> 
> I can't see anything interesting under here speculation wise. 
> Commentary inline.

My interpretation of those comments is that the suggested conversion
would be okay-ish (as in not making things worse), but since you didn't
provide an explicit answer I thought I'd better ask for confirmation
before possibly making a patch to that effect.

Jan

>> --- a/xen/arch/x86/include/asm/time.h
>> +++ b/xen/arch/x86/include/asm/time.h
>> @@ -52,8 +52,8 @@ uint64_t cf_check acpi_pm_tick_to_ns(uin
>>  uint64_t tsc_ticks2ns(uint64_t ticks);
>>  
>>  uint64_t pv_soft_rdtsc(const struct vcpu *v, const struct cpu_user_regs 
>> *regs);
>> -u64 gtime_to_gtsc(struct domain *d, u64 time);
>> -u64 gtsc_to_gtime(struct domain *d, u64 tsc);
>> +uint64_t gtime_to_gtsc(const struct domain *d, uint64_t time);
>> +uint64_t gtsc_to_gtime(const struct domain *d, uint64_t tsc);
>>  
>>  int tsc_set_info(struct domain *d, uint32_t tsc_mode, uint64_t elapsed_nsec,
>>   uint32_t gtsc_khz, uint32_t incarnation);
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -1373,18 +1373,14 @@ uint64_t tsc_ticks2ns(uint64_t ticks)
>>  return scale_delta(ticks, >tsc_scale);
>>  }
>>  
>> -static void __update_vcpu_system_time(struct vcpu *v, int force)
>> +static void collect_time_info(const struct vcpu *v,
>> +  struct vcpu_time_info *u)
>>  {
>> -const struct cpu_time *t;
>> -struct vcpu_time_info *u, _u = {};
>> -struct domain *d = v->domain;
>> +const struct cpu_time *t = _cpu(cpu_time);
>> +const struct domain *d = v->domain;
>>  s_time_t tsc_stamp;
>>  
>> -if ( v->vcpu_info == NULL )
>> -return;
>> -
>> -t = _cpu(cpu_time);
>> -u = _info(v, time);
>> +memset(u, 0, sizeof(*u));
>>  
>>  if ( d->arch.vtsc )
>>  {
>> @@ -1392,7 +1388,7 @@ static void __update_vcpu_system_time(st
>>  
>>  if ( is_hvm_domain(d) )
>>  {
>> -struct pl_time *pl = v->domain->arch.hvm.pl_time;
>> +const struct pl_time *pl = d->arch.hvm.pl_time;
> 
> A PV guest could in in principle use...
> 
>>  
>>  stime += pl->stime_offset + v->arch.hvm.stime_offset;
> 
> ... this pl->stime_offset as the second deference of a whatever happens
> to sit under d->arch.hvm.pl_time in the pv union.
> 
> In the current build of Xen I have to hand, that's
> d->arch.pv.mapcache.{epoch,tlbflush_timestamp}, the combination of which
> doesn't seem like it can be steered into being a legal pointer into Xen.
> 
>>  if ( stime >= 0 )
>> @@ -1403,27 +1399,27 @@ static void __update_vcpu_system_time(st
>>  else
>>  tsc_stamp = gtime_to_gtsc(d, stime);
>>  
>> -_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
>> -_u.tsc_shift = d->arch.vtsc_to_ns.shift;
>> +u->tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
>> +u->tsc_shift = d->arch.vtsc_to_ns.shift;
>>  }
>>  else
>>  {
>>  if ( is_hvm_domain(d) && hvm_tsc_scaling_supported )
> 
> On the other hand, this is isn't safe.  There's no protection of the &&
> calculation, but...
> 
>>  {
>>  tsc_stamp= hvm_scale_tsc(d, t->stamp.local_tsc);
> 
> ... this path is the only path subject to speculative type confusion,
> and all it does is read d->arch.hvm.tsc_scaling_ratio, so is
> appropriately protected in this instance.
> 
> Also, all an attacker could do is encode the scaling ratio alongside
> t->stamp.local_tsc (unpredictable) in the calculation for the duration
> of the speculative window, with no way I can see to dereference the result.
> 
> 
>> -_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
>> -_u.tsc_shift = d->arch.vtsc_to_ns.shift;
>> +u->tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
>> +u->tsc_shift = d->arch.vtsc_to_ns.shift;
>>  }
>>  else
>>  {
>>  tsc_stamp= t->stamp.local_tsc;
>> -_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
>> -_u.tsc_shift = t->tsc_scale.shift;
>> +u->tsc_to_system_mul = t->tsc_scale.mul_frac;
>> +u->tsc_shift = t->tsc_scale.shift;
>>  }
>>  }
>>  
>> -_u.tsc_timestamp = tsc_stamp;
>> -_u.system_time   = t->stamp.local_stime;
>> +u->tsc_timestamp = tsc_stamp;
>> +

Re: [PATCH v3 07/17] tools/xenstore: change per-domain node accounting interface

[Juergen Gross]

On 17.01.23 10:11, Juergen Gross wrote:

Rework the interface and the internals of the per-domain node
accounting:

- rename the functions to domain_nbentry_*() in order to better match
   the related counter name

- switch from node pointer to domid as interface, as all nodes have the
   owner filled in

- use a common internal function for adding a value to the counter

For the transaction case add a helper function to get the list head
of the per-transaction changed domains, enabling to eliminate the
transaction_entry_*() functions.

Signed-off-by: Juergen Gross 
---
V3:
- add get_node_owner() (Julien Grall)
- rename domain_nbentry_add() parameter (Julien Grall)
- avoid negative entry count (Julien Grall)
---
  tools/xenstore/xenstored_core.c|  33 ---
  tools/xenstore/xenstored_domain.c  | 126 -
  tools/xenstore/xenstored_domain.h  |  10 +-
  tools/xenstore/xenstored_transaction.c |  15 +--
  tools/xenstore/xenstored_transaction.h |   7 +-
  5 files changed, 86 insertions(+), 105 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index fb4379e67c..561fb121d3 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -700,6 +700,11 @@ int do_tdb_delete(struct connection *conn, TDB_DATA *key,
return 0;
  }
  
+static unsigned int get_node_owner(const struct node *node)

+{
+   return node->perms.p[0].id;
+}


I have moved this helper as inline function to xenstored_core.h now,
as it will be needed in xenstored_domain.c, too.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2 6/9] x86/shadow: re-work 4-level SHADOW_FOREACH_L2E()

[Jan Beulich]

On 17.01.2023 19:48, Andrew Cooper wrote:
> On 11/01/2023 1:54 pm, Jan Beulich wrote:
>> First of all move the almost loop-invariant condition out of the loop;
>> transform it into an altered loop boundary. Since the new local variable
>> wants to be "unsigned int" and named without violating name space rules,
>> convert the loop induction variable accordingly.
> 
> I'm firmly -1 against using trailing underscores.

Well, I can undo that aspect, but just to get done with the change. I do
consider ...

> Mainly, I object to the attempt to justify doing so based on a rule we
> explicitly choose to violate for code consistency and legibility reasons.

... your view here at least questionable: I'm unaware of us doing so
explicitly, and I've pointed out numerous times that the C standard
specifies very clearly what underscore-prefixed names may be used for. 

> But in this case, you're taking a block of logic which was cleanly in
> one style, and making it mixed, even amongst only the local variables.

That's simply the result of wanting to limit how much of a change I
make to the macro, such that the actual changes are easier to spot.

>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -863,23 +863,20 @@ do {
>>  /* 64-bit l2: touch all entries except for PAE compat guests. */
>>  #define SHADOW_FOREACH_L2E(_sl2mfn, _sl2e, _gl2p, _done, _dom, _code)   
>> \
>>  do {
>> \
>> -int _i; 
>> \
>> -int _xen = !shadow_mode_external(_dom); 
>> \
>> +unsigned int i_, end_ = SHADOW_L2_PAGETABLE_ENTRIES;
>> \
>>  shadow_l2e_t *_sp = map_domain_page((_sl2mfn)); 
>> \
>>  ASSERT_VALID_L2(mfn_to_page(_sl2mfn)->u.sh.type);   
>> \
>> -for ( _i = 0; _i < SHADOW_L2_PAGETABLE_ENTRIES; _i++ )  
>> \
>> +if ( !shadow_mode_external(_dom) && 
>> \
>> + is_pv_32bit_domain(_dom) &&
>> \
> 
> The second clause here implies the first.  Given that all we're trying
> to say here is "are there Xen entries to skip", I think we'd be fine
> dropping the external() check entirely.

Will do. I may retain this in some form of comment.

>> + mfn_to_page(_sl2mfn)->u.sh.type != SH_type_l2_64_shadow )  
>> \
>> +end_ = COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(_dom);
>> \
>> +for ( i_ = 0; i_ < end_; ++i_ ) 
>> \
>>  {   
>> \
>> -if ( (!(_xen))  
>> \
>> - || !is_pv_32bit_domain(_dom)   
>> \
>> - || mfn_to_page(_sl2mfn)->u.sh.type == SH_type_l2_64_shadow 
>> \
>> - || (_i < COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(_dom)) )   
>> \
>> -{   
>> \
>> -(_sl2e) = _sp + _i; 
>> \
>> -if ( shadow_l2e_get_flags(*(_sl2e)) & _PAGE_PRESENT )   
>> \
>> -{_code} 
>> \
>> -if ( _done ) break; 
>> \
>> -increment_ptr_to_guest_entry(_gl2p);
>> \
>> -}   
>> \
>> +(_sl2e) = _sp + i_; 
>> \
>> +if ( shadow_l2e_get_flags(*(_sl2e)) & _PAGE_PRESENT )   
>> \
>> +{ _code }   
>> \
> 
> This doesn't match either of our two styles. 

Indeed, and I was unable to come up with good criteria whether to leave
it (for consistency with the other macros) or  change it. Since you're
...

> if ( ... )
> { _code }
> 
> would be closer to Xen's normal style, but  ...
> 
>> +if ( _done ) break; 
>> \
> 
> ... with this too, I think it would still be better to write it out
> fully, so:
> 
> if ( ... )
> {
>     _code
> }
> if ( _done )
>     break;
> 
> These macros are already big enough that trying to save 3 lines seems
> futile.

... explicitly asking for it, I'll change then. Would you mind if I then
also added a semicolon after _code, to make things look more sensible?

Jan

Re: [XEN PATCH] Create a Kconfig option to set preferred reboot method

[Jan Beulich]

On 17.01.2023 20:28, Per Bilse wrote:
> On 17/01/2023 15:55, Jan Beulich wrote:
>> On 16.01.2023 18:21, Per Bilse wrote:
>>> +   config REBOOT_METHOD_XEN
>>> +   bool "xen"
>>> +   help
>>> +   Use Xen SCHEDOP hypercall (if running under Xen as a 
>>> guest).
>>
>> This wants to depend on XEN_GUEST, doesn't it?
> 
> Yes, depending on context.  In providing a compiled-in equivalent
> of the command-line parameter, it should arguably provide and accept
> the same set of options, but I'll change it.

If consistency between the two cases is the goal, then why not adjust
command line handling (in a separate patch) to "not know" about "x"
when !XEN_GUEST?

Jan

[xen-unstable-smoke test] 175951: regressions - trouble: blocked/broken/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken
 build-armhf   4 host-install(4)broken REGR. vs. 175746
 build-amd64   6 xen-buildfail REGR. vs. 175746
 build-arm64-xsm   6 xen-buildfail REGR. vs. 175746

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

version targeted for testing:
 xen  f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
baseline version:
 xen  6bec713f871f21c6254a5783c1e39867ea828256

Last test of basis   175746  2023-01-12 16:03:41 Z5 days
Failing since175748  2023-01-12 20:01:56 Z5 days   25 attempts
Testing same since   175833  2023-01-14 07:00:25 Z3 days   23 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 
  Michal Orzel 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  broken  
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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

broken-job build-armhf broken
broken-step build-armhf host-install(4)

Not pushing.


commit f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
Author: Michal Orzel 
Date:   Tue Jan 3 11:25:19 2023 +0100

xen/arm: Add 0x prefix when printing memory size in construct_domU

Printing memory size in hex without 0x prefix can be misleading, so
add it. Also, take the opportunity to adhere to 80 chars line length
limit by moving the printk arguments to the next line.

Signed-off-by: Michal Orzel 
Reviewed-by: Ayan Kumar Halder 
Acked-by: Julien Grall 

commit 229ebd517b9df0e2d2f9e3ea50b57ca716334826
Author: Julien Grall 
Date:   Thu Jan 12 22:07:42 2023 +

xen/arm: linker: The identitymap check should cover the whole .text.header

At the moment, we are only checking that only some part of .text.header
is part of the identity mapping. However, this doesn't take into account
the literal pool which will be located at the end of the section.

While we could try to avoid using a literal pool, in the near future we
will also want to use an identity mapping for switch_ttbr().

Not everything in .text.header requires to be part of the identity
mapping. But it is below a page size (i.e. 4KB) so take a shortcut and
check that .text.header is smaller than a page size.

With that _end_boot can be removed as it is now unused. Take the
opportunity to avoid assuming that a page size is always 4KB in the
error message and comment.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit 22a9981ba2443bd569bad6b772fb6e7e64f0d714
Author: Julien Grall 
Date:   Thu Jan 12 22:06:42 2023 +

xen/arm: linker: Indent correctly _stext

_stext is indented by one space more compare to the lines. This doesn't
seem warrant, so delete the extra space.

Signed-off: Julien Grall 
Acked-by: Stefano Stabellini 

commit 3edca52ce736297d7fcf293860cd94ef62638052
Author: Andrew Cooper 
Date:   Mon Jan 9 10:58:31 2023 +

x86/vmx: Support for CPUs without model-specific LBR

Ice Lake (server at least) has both architectural LBR and model-specific 
LBR.
Sapphire Rapids does not have model-specific LBR at all.  I.e. On SPR and

Re: [PATCH v3 16/17] tools/xenstore: let check_store() check the accounting data

[Juergen Gross]

On 17.01.23 23:36, Julien Grall wrote:

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

Today check_store() is only testing the correctness of the node tree.

Add verification of the accounting data (number of nodes)  and correct


NIT: one too many space before 'and'.


the data if it is wrong.

Do the initial check_store() call only after Xenstore entries of a
live update have been read.


Can you clarify whether this is needed for the rest of the patch, or simply a 
nice thing to have in general?


I'll add: "This is wanted to make sure the accounting data is correct after
a live update."





Signed-off-by: Juergen Gross 
---
  tools/xenstore/xenstored_core.c   | 62 --
  tools/xenstore/xenstored_domain.c | 86 +++
  tools/xenstore/xenstored_domain.h |  4 ++
  3 files changed, 137 insertions(+), 15 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 3099077a86..e201f14053 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -2389,8 +2389,6 @@ void setup_structure(bool live_update)
  manual_node("@introduceDomain", NULL);
  domain_nbentry_fix(dom0_domid, 5, true);
  }
-
-    check_store();
  }
  static unsigned int hash_from_key_fn(void *k)
@@ -2433,20 +2431,28 @@ int remember_string(struct hashtable *hash, const char 
*str)

   * As we go, we record each node in the given reachable hashtable.  These
   * entries will be used later in clean_store.
   */
+
+struct check_store_data {
+    struct hashtable *reachable;
+    struct hashtable *domains;
+};
+
  static int check_store_step(const void *ctx, struct connection *conn,
  struct node *node, void *arg)
  {
-    struct hashtable *reachable = arg;
+    struct check_store_data *data = arg;
-    if (hashtable_search(reachable, (void *)node->name)) {
+    if (hashtable_search(data->reachable, (void *)node->name)) {


IIUC the cast is only necessary because hashtable_search() expects a non-const 
value. I can't think for a reason for the key to be non-const. So I will look to 
send a follow-up patch.


It is possible, but nasty, due to talloc_free() not taking a const pointer.




+
+void domain_check_acc_add(const struct node *node, struct hashtable *domains)
+{
+    struct domain_acc *dom;
+    unsigned int domid;
+
+    domid = node->perms.p[0].id;


This could be replaced with get_node_owner().


Indeed.




+    dom = hashtable_search(domains, );
+    if (!dom)
+    log("Node %s owned by unknown domain %u", node->name, domid);
+    else
+    dom->nodes++;
+}
+
+static int domain_check_acc_sub(const void *k, void *v, void *arg)


I find the suffix 'sub' misleading because we have a function with a very 
similar name (instead suffixed 'sub'). Yet, AFAICT, it is not meant to substract.


So I would prefix with '_cb' instead.


Fine with me.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v3 15/17] tools/xenstore: introduce trace classes

[Juergen Gross]

On 17.01.23 23:15, Julien Grall wrote:

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

@@ -2604,6 +2607,8 @@ static void usage(void)
  "  -N, --no-fork   to request that the daemon does not fork,\n"
  "  -P, --output-pid    to request that the pid of the daemon is output,\n"
  "  -T, --trace-file  giving the file for logging, and\n"
+"  --trace-control=+ activate a specific \n"
+"  --trace-control=- deactivate a specific \n"
  "  -E, --entry-nb  limit the number of entries per domain,\n"
  "  -S, --entry-size  limit the size of entry per domain, and\n"
  "  -W, --watch-nb  limit the number of watches per domain,\n"
@@ -2647,6 +2652,7 @@ static struct option options[] = {
  { "output-pid", 0, NULL, 'P' },
  { "entry-size", 1, NULL, 'S' },
  { "trace-file", 1, NULL, 'T' },
+    { "trace-control", 1, NULL, 1 },
  { "transaction", 1, NULL, 't' },
  { "perm-nb", 1, NULL, 'A' },
  { "path-max", 1, NULL, 'M' },
@@ -2721,6 +2727,43 @@ static void set_quota(const char *arg, bool soft)
  barf("unknown quota \"%s\"\n", arg);
  }
+/* Sorted by bit values of TRACE_* flags. Flag is (1u << index). */
+const char *trace_switches[] = {


AFAICT, this array is not meant to be modified. So you want a second const.


Yes, you are right.




+    "obj", "io", "wrl",
+    NULL
+};


[...]


diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index 3b96ecd018..c85b15515c 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -287,6 +287,12 @@ extern char **orig_argv;
  extern char *tracefile;
  extern int tracefd;
+extern unsigned int trace_flags;
+#define TRACE_OBJ    0x0001
+#define TRACE_IO    0x0002
+#define TRACE_WRL    0x0004
I would add a comment on top to explain that the value should be kept in sync 
with trace_switches.


Okay.


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v3 12/17] tools/xenstore: don't let hashtable_remove() return the removed value

[Juergen Gross]

On 17.01.23 23:03, Julien Grall wrote:

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

Letting hashtable_remove() return the value of the removed element is
not used anywhere in Xenstore, and it conflicts with a hashtable
created specifying the HASHTABLE_FREE_VALUE flag.

So just drop returning the value.


Any reason this can't be void? If there are, then I would consider to return a 
bool as the return can only be 2 values.


I think you are right. Switching to void should be fine.





Signed-off-by: Juergen Gross 
---
V3:
- new patch
---
  tools/xenstore/hashtable.c | 10 +-
  tools/xenstore/hashtable.h |  4 ++--
  2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/hashtable.c b/tools/xenstore/hashtable.c
index 299549c51e..6738719e47 100644
--- a/tools/xenstore/hashtable.c
+++ b/tools/xenstore/hashtable.c
@@ -214,7 +214,7 @@ hashtable_search(struct hashtable *h, void *k)
  }
  
/*/
-void * /* returns value associated with key */
+int
  hashtable_remove(struct hashtable *h, void *k)
  {
  /* TODO: consider compacting the table when the load factor drops enough,
@@ -222,7 +222,6 @@ hashtable_remove(struct hashtable *h, void *k)
  struct entry *e;
  struct entry **pE;
-    void *v;
  unsigned int hashvalue, index;
  hashvalue = hash(h,k);
@@ -236,16 +235,17 @@ hashtable_remove(struct hashtable *h, void *k)
  {
  *pE = e->next;
  h->entrycount--;
-    v = e->v;
  if (h->flags & HASHTABLE_FREE_KEY)
  free(e->k);
+    if (h->flags & HASHTABLE_FREE_VALUE)
+    free(e->v);


I don't quite understand how this change is related to this patch.


With not returning the value pointer any longer there would be no way
for the caller to free it, so it must be freed by hashtable_remove()
if the related flag was set.

I can add a sentence to the commit message.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

RE: [PATCH v1 06/13] xen/arm: assign shared memory to owner when host address not provided

[Penny Zheng]

Hi Julien

> -Original Message-
> From: Julien Grall 
> Sent: Monday, January 9, 2023 6:58 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk 
> Subject: Re: [PATCH v1 06/13] xen/arm: assign shared memory to owner
> when host address not provided
> 
> 
> 
> On 09/01/2023 07:49, Penny Zheng wrote:
> > Hi Julien
> 
> Hi Penny,
> 
> > Happy new year
> 
> Happy new year too!
> 
> >> -Original Message-
> >> From: Julien Grall 
> >> Sent: Sunday, January 8, 2023 8:53 PM
> >> To: Penny Zheng ; xen-
> de...@lists.xenproject.org
> >> Cc: Wei Chen ; Stefano Stabellini
> >> ; Bertrand Marquis
> >> ; Volodymyr Babchuk
> >> 
> >> Subject: Re: [PATCH v1 06/13] xen/arm: assign shared memory to owner
> >> when host address not provided
> >>
> >> Hi,
> >>
> >> On 15/11/2022 02:52, Penny Zheng wrote:
> >>> @@ -922,33 +927,82 @@ static mfn_t __init
> >> acquire_shared_memory_bank(struct domain *d,
> >>>d->max_pages += nr_pfns;
> >>>
> >>>smfn = maddr_to_mfn(pbase);
> >>> -res = acquire_domstatic_pages(d, smfn, nr_pfns, 0);
> >>> -if ( res )
> >>> +page = mfn_to_page(smfn);
> >>> +/*
> >>> + * If page is allocated from heap as static shared memory, then we
> just
> >>> + * assign it to the owner domain
> >>> + */
> >>> +if ( page->count_info == (PGC_state_inuse | PGC_static) )
> >> I am a bit confused how this can help differentiating
> >> becaPGC_state_inuse is 0. So effectively, you are checking that count_info
> is equal to PGC_static.
> >>
> >
> > When host address is provided, the host address range defined in
> > xen,static-mem will be stored as a "struct membank" with type of
> > "MEMBANK_STATIC_DOMAIN" in "bootinfo.reserved_mem"
> > Then it will be initialized as static memory through "init_staticmem_pages"
> > So here its page->count_info is PGC_state_free |PGC_static.
> > For pages allocated from heap, its page state is different, being
> PGC_state_inuse.
> > So actually, we are checking page state to tell the
> difference.
> 
> Ok. This is definitely not obvious from the code. But I think this is a very
> fragile assumption.
> 
> Instead, it would be better if we allocate the memory in
> acquire_shared_memory_bank() when the host address is not provided.
> 

Right now, acquire_shared_memory_bank is called only when domain is owner 
domain.
It is applicable when host address is provided, we could still do guest physmap 
when
borrower accessed before owner, as address is provided.
However when host address is not provided, we must allocate memory at first 
domain.
So allocating the memory shall be called outside acquire_shared_memory_bank

> >
> >> But as I wrote in a previous patch, I don't think you should convert
> >> {xen,dom}heap pages to a static pages.
> >>
> >
> > I agree that taking reference could also prevent giving these pages back to
> heap.
> > But may I ask what is your concern on converting {xen,dom}heap pages to
> a static pages?
> 
> A few reasons:
>   1) I consider them as two distinct allocators. So far they have the same
> behavior, but in the future this may change.
>   2) If the page is freed you really don't want the domain to be able to 
> re-use
> the page for a different purpose.
> 
> 
> I realize that 2) is already a problem today with static pages. So I think the
> best is to ensure that pages allocated for shared memory never reach the
> any of the allocators.
> 
> 
> Cheers,
> 
> --
> Julien Grall

Cheers,

--
Julien Grall

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

[Alex Williamson]

On Tue, 17 Jan 2023 19:15:57 -0500
Chuck Zmudzinski  wrote:

> On 1/17/2023 6:04 AM, Igor Mammedov wrote:
> > On Mon, 16 Jan 2023 13:00:53 -0500
> > Chuck Zmudzinski  wrote:
> >  
> > > On 1/16/23 10:33, Igor Mammedov wrote:  
> > > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > > Chuck Zmudzinski  wrote:
> > > > 
> > > >> On 1/13/23 4:33 AM, Igor Mammedov wrote:
> > > >> > On Thu, 12 Jan 2023 23:14:26 -0500
> > > >> > Chuck Zmudzinski  wrote:
> > > >> >   
> > > >> >> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:  
> > > >> >> > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote: 
> > > >> >> >
> > > >> >> >> I think the change Michael suggests is very minimalistic: Move 
> > > >> >> >> the if
> > > >> >> >> condition around xen_igd_reserve_slot() into the function itself 
> > > >> >> >> and
> > > >> >> >> always call it there unconditionally -- basically turning three 
> > > >> >> >> lines
> > > >> >> >> into one. Since xen_igd_reserve_slot() seems very problem 
> > > >> >> >> specific,
> > > >> >> >> Michael further suggests to rename it to something more general. 
> > > >> >> >> All
> > > >> >> >> in all no big changes required.
> > > >> >> > 
> > > >> >> > yes, exactly.
> > > >> >> > 
> > > >> >> 
> > > >> >> OK, got it. I can do that along with the other suggestions.  
> > > >> > 
> > > >> > have you considered instead of reservation, putting a slot check in 
> > > >> > device model
> > > >> > and if it's intel igd being passed through, fail at realize time  if 
> > > >> > it can't take
> > > >> > required slot (with a error directing user to fix command line)? 
> > > >> >  
> > > >> 
> > > >> Yes, but the core pci code currently already fails at realize time
> > > >> with a useful error message if the user tries to use slot 2 for the
> > > >> igd, because of the xen platform device which has slot 2. The user
> > > >> can fix this without patching qemu, but having the user fix it on
> > > >> the command line is not the best way to solve the problem, primarily
> > > >> because the user would need to hotplug the xen platform device via a
> > > >> command line option instead of having the xen platform device added by
> > > >> pc_xen_hvm_init functions almost immediately after creating the pci
> > > >> bus, and that delay in adding the xen platform device degrades
> > > >> startup performance of the guest.
> > > >> 
> > > >> > That could be less complicated than dealing with slot reservations 
> > > >> > at the cost of
> > > >> > being less convenient.  
> > > >> 
> > > >> And also a cost of reduced startup performance
> > > > 
> > > > Could you clarify how it affects performance (and how much).
> > > > (as I see, setup done at board_init time is roughly the same
> > > > as with '-device foo' CLI options, modulo time needed to parse
> > > > options which should be negligible. and both ways are done before
> > > > guest runs)
> > > 
> > > I preface my answer by saying there is a v9, but you don't
> > > need to look at that. I will answer all your questions here.
> > > 
> > > I am going by what I observe on the main HDMI display with the
> > > different approaches. With the approach of not patching Qemu
> > > to fix this, which requires adding the Xen platform device a
> > > little later, the length of time it takes to fully load the
> > > guest is increased. I also noticed with Linux guests that use
> > > the grub bootoader, the grub vga driver cannot display the
> > > grub boot menu at the native resolution of the display, which
> > > in the tested case is 1920x1080, when the Xen platform device
> > > is added via a command line option instead of by the
> > > pc_xen_hvm_init_pci fucntion in pc_piix.c, but with this patch
> > > to Qemu, the grub menu is displayed at the full, 1920x1080
> > > native resolution of the display. Once the guest fully loads,
> > > there is no noticeable difference in performance. It is mainly
> > > a degradation in startup performance, not performance once
> > > the guest OS is fully loaded.  
> >
> > Looking at igd-assign.txt, it recommends to add IGD using '-device' CLI
> > option, and actually drop at least graphics defaults explicitly.
> > So it is expected to work fine even when IGD is constructed with
> > '-device'.
> >
> > Could you provide full CLI current xen starts QEMU with and then
> > a CLI you used (with explicit -device for IGD) that leads
> > to reduced performance?
> >
> > CCing vfio folks who might have an idea what could be wrong based
> > on vfio experience.  
> 
> Actually, the igd is not added with an explicit -device option using Xen:
> 
>    1573 ?    Ssl    0:42 /usr/bin/qemu-system-i386 -xen-domid 1 
> -no-shutdown -chardev 
> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-1,server,nowait -mon 
> chardev=libxl-cmd,mode=control -chardev 
> socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-1,server,nowait 
> -mon chardev=libxenstat-cmd,mode=control -nodefaults 

[linux-linus test] 175933: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw broken
 test-armhf-armhf-xl-multivcpu broken
 test-armhf-armhf-xl-vhd  broken
 test-armhf-armhf-xl-vhd   5 host-install(5)broken REGR. vs. 173462
 test-armhf-armhf-xl-multivcpu  5 host-install(5)   broken REGR. vs. 173462
 test-armhf-armhf-libvirt-raw  5 host-install(5)broken REGR. vs. 173462
 test-arm64-arm64-examine  8 reboot   fail REGR. vs. 173462
 test-arm64-arm64-xl-seattle   8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-xl-xsm   8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-xl-credit2   8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-xl-credit2   8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-xl-arndale   8 xen-boot fail REGR. vs. 173462
 build-amd64   6 xen-buildfail REGR. vs. 173462
 build-amd64-xsm   6 xen-buildfail REGR. vs. 173462
 test-armhf-armhf-xl-credit1   8 xen-boot fail REGR. vs. 173462
 build-i386-xsm6 xen-buildfail REGR. vs. 173462
 build-i3866 xen-buildfail REGR. vs. 173462
 test-arm64-arm64-libvirt-xsm  8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-xl-vhd   8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-xl-credit1   8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-libvirt-raw  8 xen-boot fail REGR. vs. 173462
 test-arm64-arm64-xl   8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-libvirt-qcow2  8 xen-boot   fail REGR. vs. 173462
 test-armhf-armhf-xl   8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-libvirt  8 xen-boot fail REGR. vs. 173462
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 173462

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

Tests which did not succeed, but are not blocking:
 test-amd64-coresched-amd64-xl  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-dom0pvh-xl-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-dom0pvh-xl-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-examine  1 build-check(1)   blocked  n/a
 test-amd64-amd64-examine-bios  1 build-check(1)   blocked  n/a
 test-amd64-amd64-examine-uefi  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-freebsd11-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-freebsd12-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 

RE: [PATCH v2 05/40] xen/arm64: prepare for moving MMU related code from head.S

[Wei Chen]

Hi Julien,

> -Original Message-
> From: Julien Grall 
> Sent: 2023年1月18日 7:37
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk 
> Subject: Re: [PATCH v2 05/40] xen/arm64: prepare for moving MMU related
> code from head.S
> 
> Hi Penny,
> 
> On 13/01/2023 05:28, Penny Zheng wrote:
> > From: Wei Chen 
> >
> > We want to reuse head.S for MPU systems, but there are some
> > code implemented for MMU systems only. We will move such
> > code to another MMU specific file. But before that, we will
> > do some preparations in this patch to make them easier
> > for reviewing:
> 
> Well, I agree that...
> 
> > 1. Fix the indentations of code comments.
> 
> ... changing the indentation is better here. But...
> 
> > 2. Export some symbols that will be accessed out of file
> > scope.
> 
> ... I have no idea which functions are going to be used in a separate
> file. So I think they should belong to the patch moving the code.
> 

Ok, I will move these changes to the moving code patches.

> >
> > Signed-off-by: Wei Chen 
> 
> Your signed-off-by is missing.
> 
> > ---
> > v1 -> v2:
> > 1. New patch.
> > ---
> >   xen/arch/arm/arm64/head.S | 40 +++
> >   1 file changed, 20 insertions(+), 20 deletions(-)
> >
> > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> > index 93f9b0b9d5..b2214bc5e3 100644
> > --- a/xen/arch/arm/arm64/head.S
> > +++ b/xen/arch/arm/arm64/head.S
> > @@ -136,22 +136,22 @@
> >   add \xb, \xb, x20
> >   .endm
> >
> > -.section .text.header, "ax", %progbits
> > -/*.aarch64*/
> > +.section .text.header, "ax", %progbits
> > +/*.aarch64*/
> 
> This change is not mentioned.
> 

I will add the description in commit message.

> >
> > -/*
> > - * Kernel startup entry point.
> > - * ---
> > - *
> > - * The requirements are:
> > - *   MMU = off, D-cache = off, I-cache = on or off,
> > - *   x0 = physical address to the FDT blob.
> > - *
> > - * This must be the very first address in the loaded image.
> > - * It should be linked at XEN_VIRT_START, and loaded at any
> > - * 4K-aligned address.  All of text+data+bss must fit in 2MB,
> > - * or the initial pagetable code below will need adjustment.
> > - */
> > +/*
> > + * Kernel startup entry point.
> > + * ---
> > + *
> > + * The requirements are:
> > + *   MMU = off, D-cache = off, I-cache = on or off,
> > + *   x0 = physical address to the FDT blob.
> > + *
> > + * This must be the very first address in the loaded image.
> > + * It should be linked at XEN_VIRT_START, and loaded at any
> > + * 4K-aligned address.  All of text+data+bss must fit in 2MB,
> > + * or the initial pagetable code below will need adjustment.
> > + */
> >
> >   GLOBAL(start)
> >   /*
> > @@ -586,7 +586,7 @@ ENDPROC(cpu_init)
> >*
> >* Clobbers x0 - x4
> >*/
> > -create_page_tables:
> > +ENTRY(create_page_tables)
> 
> I am not sure about keeping this name. Now we have create_page_tables()
> and arch_setup_page_tables().
> 
> I would conside to name it create_boot_page_tables().
> 

Do you need me to rename it in this patch?

> >   /* Prepare the page-tables for mapping Xen */
> >   ldr   x0, =XEN_VIRT_START
> >   create_table_entry boot_pgtable, boot_first, x0, 0, x1, x2, x3
> > @@ -680,7 +680,7 @@ ENDPROC(create_page_tables)
> >*
> >* Clobbers x0 - x3
> >*/
> > -enable_mmu:
> > +ENTRY(enable_mmu)
> >   PRINT("- Turning on paging -\r\n")
> >
> >   /*
> > @@ -714,7 +714,7 @@ ENDPROC(enable_mmu)
> >*
> >* Clobbers x0 - x1
> >*/
> > -remove_identity_mapping:
> > +ENTRY(remove_identity_mapping)
> 
> Patch #14 should be before this patch. So you don't have to export
> remove_identity_mapping temporarily.
> 
> This will also avoid (transient) naming confusing with my work (see [1]).
> 

Ok, we will do it.

> >   /*
> >* Find the zeroeth slot used. Remove the entry from zeroeth
> >* table if the slot is not XEN_ZEROETH_SLOT.
> > @@ -775,7 +775,7 @@ ENDPROC(remove_identity_mapping)
> >*
> >* Clobbers x0 - x3
> >*/
> > -setup_fixmap:
> > +ENTRY(setup_fixmap)
> >   #ifdef CONFIG_EARLY_PRINTK
> >   /* Add UART to the fixmap table */
> >   ldr   x0, =EARLY_UART_VIRTUAL_ADDRESS
> > @@ -871,7 +871,7 @@ ENDPROC(init_uart)
> >* x0: Nul-terminated string to print.
> >* x23: Early UART base address
> >* Clobbers x0-x1 */
> > -puts:
> > +ENTRY(puts)
> 
> This name is a bit too generic to be globally exported. It is also now
> quite confusing because we have "early_puts" and "puts".
> 
> I would consider to name it asm_puts(). It is still not great but
> hopefully it would give a hint that should be call from assembly code.
> 

Yes, I had 

RE: [PATCH v2 04/40] xen/arm: add an option to define Xen start address for Armv8-R

[Wei Chen]

Hi Julien,

> -Original Message-
> From: Julien Grall 
> Sent: 2023年1月18日 7:24
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk ; Jiamei Xie
> 
> Subject: Re: [PATCH v2 04/40] xen/arm: add an option to define Xen start
> address for Armv8-R
> 
> Hi Penny,
> 
> On 13/01/2023 05:28, Penny Zheng wrote:
> > From: Wei Chen 
> >
> > On Armv8-A, Xen has a fixed virtual start address (link address
> > too) for all Armv8-A platforms. In an MMU based system, Xen can
> > map its loaded address to this virtual start address. So, on
> > Armv8-A platforms, the Xen start address does not need to be
> > configurable. But on Armv8-R platforms, there is no MMU to map
> > loaded address to a fixed virtual address and different platforms
> > will have very different address space layout. So Xen cannot use
> > a fixed physical address on MPU based system and need to have it
> > configurable.
> >
> > In this patch we introduce one Kconfig option for users to define
> > the default Xen start address for Armv8-R. Users can enter the
> > address in config time, or select the tailored platform config
> > file from arch/arm/configs.
> >
> > And as we introduced Armv8-R platforms to Xen, that means the
> > existed Arm64 platforms should not be listed in Armv8-R platform
> > list, so we add !ARM_V8R dependency for these platforms.
> >
> > Signed-off-by: Wei Chen 
> > Signed-off-by: Jiamei.Xie 
> 
> Your signed-off-by is missing.
> 
> > ---
> > v1 -> v2:
> > 1. Remove the platform header fvp_baser.h.
> > 2. Remove the default start address for fvp_baser64.
> > 3. Remove the description of default address from commit log.
> > 4. Change HAS_MPU to ARM_V8R for Xen start address dependency.
> > No matter Arm-v8r board has MPU or not, it always need to
> > specify the start address.
> 
> I don't quite understand the last sentence. Are you saying that it is
> possible to have an ARMv8-R system with an MPU nor a page-table?
> 

Yes, from the Cortex-R82 page [1], you can see the MPU is optional in EL1
and EL2:
"Two optional and programmable MPUs controlled from EL1 and EL2 respectively."

Although it is unlikely that vendors using the Armv8-R IP will do so, it
is indeed an option. In the ID register, there are also related bits in
ID_AA64MMFR0_EL1 (MSA_frac) to indicate this.

> > ---
> >   xen/arch/arm/Kconfig   |  8 
> >   xen/arch/arm/platforms/Kconfig | 16 +---
> >   2 files changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index ace7178c9a..c6b6b612d1 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -145,6 +145,14 @@ config TEE
> >   This option enables generic TEE mediators support. It allows
> guests
> >   to access real TEE via one of TEE mediators implemented in XEN.
> >
> > +config XEN_START_ADDRESS
> > +   hex "Xen start address: keep default to use platform defined
> address"
> > +   default 0
> > +   depends on ARM_V8R
> 
> It is still pretty unclear to me what would be the difference between
> HAS_MPU and ARM_V8R.
> 

If we don't want to support non-MPU supported Armv8-R, I think they are the
same. IMO, non-MPU supported Armv8-R is meaningless to Xen.

> > +   help
> > + This option allows to set the customized address at which Xen will
> be
> > + linked on MPU systems. This address must be aligned to a page size.
> > +
> >   source "arch/arm/tee/Kconfig"
> >
> >   config STATIC_SHM
> > diff --git a/xen/arch/arm/platforms/Kconfig
> b/xen/arch/arm/platforms/Kconfig
> > index c93a6b2756..0904793a0b 100644
> > --- a/xen/arch/arm/platforms/Kconfig
> > +++ b/xen/arch/arm/platforms/Kconfig
> > @@ -1,6 +1,7 @@
> >   choice
> > prompt "Platform Support"
> > default ALL_PLAT
> > +   default FVP_BASER if ARM_V8R
> > ---help---
> > Choose which hardware platform to enable in Xen.
> >
> > @@ -8,13 +9,14 @@ choice
> >
> >   config ALL_PLAT
> > bool "All Platforms"
> > +   depends on !ARM_V8R
> > ---help---
> > Enable support for all available hardware platforms. It doesn't
> > automatically select any of the related drivers.
> >
> >   config QEMU
> > bool "QEMU aarch virt machine support"
> > -   depends on ARM_64
> > +   depends on ARM_64 && !ARM_V8R
> > select GICV3
> > select HAS_PL011
> > ---help---
> > @@ -23,7 +25,7 @@ config QEMU
> >
> >   config RCAR3
> > bool "Renesas RCar3 support"
> > -   depends on ARM_64
> > +   depends on ARM_64 && !ARM_V8R
> > select HAS_SCIF
> > select IPMMU_VMSA
> > ---help---
> > @@ -31,14 +33,22 @@ config RCAR3
> >
> >   config MPSOC
> > bool "Xilinx Ultrascale+ MPSoC support"
> > -   depends on ARM_64
> > +   depends on ARM_64 && !ARM_V8R
> > select HAS_CADENCE_UART
> > select ARM_SMMU
> > ---help---
> > Enable all the required drivers for Xilinx Ultrascale+ MPSoC
> >
> > +config FVP_BASER
> > +   

RE: [PATCH v2 03/40] xen/arm: adjust Xen TLB helpers for Armv8-R64 PMSA

[Wei Chen]

Hi Julien,

> -Original Message-
> From: Julien Grall 
> Sent: 2023年1月18日 7:17
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk 
> Subject: Re: [PATCH v2 03/40] xen/arm: adjust Xen TLB helpers for Armv8-
> R64 PMSA
> 
> Hi,
> 
> On 13/01/2023 05:28, Penny Zheng wrote:
> > From: Wei Chen 
> >
> >  From Arm ARM Supplement of Armv8-R AArch64 (DDI 0600A) [1],
> > section D1.6.2 TLB maintenance instructions, we know that
> > Armv8-R AArch64 permits an implementation to cache stage 1
> > VMSAv8-64 and stage 2 PMSAv8-64 attributes as a common entry
> > for the Secure EL1&0 translation regime. But for Xen itself,
> > it's running with stage 1 PMSAv8-64 on Armv8-R AArch64. The
> > EL2 MPU updates for stage 1 PMSAv8-64 will not be cached in
> > TLB entries. So we don't need any TLB invalidation for Xen
> > itself in EL2.
> 
> So I understand the theory here. But I would expect that none of the
> common code will call any of those helpers. Therefore the #ifdef should
> be unnecessary.
> 
> Can you clarify if my understanding is correct?
> 

Yes, you're right, after we separate common code and MMU code, these
helpers will be called in MMU specific code only. We will drop this
patch in next version.

Cheers,
Wei Chen

> Cheers,
> 
> --
> Julien Grall

[qemu-mainline test] 175932: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw broken
 test-armhf-armhf-libvirt-raw  5 host-install(5)broken REGR. vs. 175743
 build-amd64   6 xen-buildfail REGR. vs. 175743
 build-amd64-xsm   6 xen-buildfail REGR. vs. 175743
 build-i3866 xen-buildfail REGR. vs. 175743
 build-i386-xsm6 xen-buildfail REGR. vs. 175743
 test-armhf-armhf-libvirt 12 debian-install   fail REGR. vs. 175743
 test-armhf-armhf-xl-vhd  12 debian-di-installfail REGR. vs. 175743

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-vhd1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-raw   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-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-coresched-i386-xl  1 build-check(1)   blocked  n/a
 test-amd64-coresched-amd64-xl  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-dom0pvh-xl-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-dom0pvh-xl-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 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-xl-qcow2 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-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-freebsd11-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-qemuu-freebsd12-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 

RE: [PATCH v2 02/40] xen/arm: make ARM_EFI selectable for Arm64

[Wei Chen]

Hi Julien,

> -Original Message-
> From: Julien Grall 
> Sent: 2023年1月18日 7:09
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk 
> Subject: Re: [PATCH v2 02/40] xen/arm: make ARM_EFI selectable for Arm64
> 
> Hi Penny,
> 
> On 13/01/2023 05:28, Penny Zheng wrote:
> > From: Wei Chen 
> >
> > Currently, ARM_EFI will mandatorily selected by Arm64.
> > Even if the user knows for sure that their images will not
> > start in the EFI environment, they can't disable the EFI
> > support for Arm64. This means there will be about 3K lines
> > unused code in their images.
> >
> > So in this patch, we make ARM_EFI selectable for Arm64, and
> > based on that, we can use CONFIG_ARM_EFI to gate the EFI
> > specific code in head.S for those images that will not be
> > booted in EFI environment.
> >
> > Signed-off-by: Wei Chen 
> 
> Your signed-off-by is missing.
> 
> > ---
> > v1 -> v2:
> > 1. New patch
> > ---
> >   xen/arch/arm/Kconfig  | 10 --
> >   xen/arch/arm/arm64/head.S | 15 +--
> >   2 files changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > index 239d3aed3c..ace7178c9a 100644
> > --- a/xen/arch/arm/Kconfig
> > +++ b/xen/arch/arm/Kconfig
> > @@ -7,7 +7,6 @@ config ARM_64
> > def_bool y
> > depends on !ARM_32
> > select 64BIT
> > -   select ARM_EFI
> > select HAS_FAST_MULTIPLY
> >
> >   config ARM
> > @@ -37,7 +36,14 @@ config ACPI
> >   an alternative to device tree on ARM64.
> >
> >   config ARM_EFI
> > -   bool
> > +   bool "UEFI boot service support"
> > +   depends on ARM_64
> > +   default y
> > +   help
> > + This option provides support for boot services through
> > + UEFI firmware. A UEFI stub is provided to allow Xen to
> > + be booted as an EFI application. This is only useful for
> > + Xen that may run on systems that have UEFI firmware.
> 
> I would drop the last sentence as this is implied with the rest of the
> paragraph.
> 

Ok.

Cheers,
Wei Chen

> Cheers,
> 
> --
> Julien Grall

RE: [PATCH v2 07/40] xen/arm64: add .text.idmap for Xen identity map sections

[Wei Chen]

Hi Julien,

> -Original Message-
> From: Julien Grall 
> Sent: 2023年1月18日 7:46
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk 
> Subject: Re: [PATCH v2 07/40] xen/arm64: add .text.idmap for Xen identity
> map sections
> 
> Hi,
> 
> On 13/01/2023 05:28, Penny Zheng wrote:
> > From: Wei Chen 
> >
> > Only the first 4KB of Xen image will be mapped as identity
> > (PA == VA). At the moment, Xen guarantees this by having
> > everything that needs to be used in the identity mapping
> > in head.S before _end_boot and checking at link time if this
> > fits in 4KB.
> >
> > In previous patch, we have moved the MMU code outside of
> > head.S. Although we have added .text.header to the new file
> > to guarantee all identity map code still in the first 4KB.
> > However, the order of these two files on this 4KB depends
> > on the build tools. Currently, we use the build tools to
> > process the order of objs in the Makefile to ensure that
> > head.S must be at the top. But if you change to another build
> > tools, it may not be the same result.
> 
> Right, so this is fixing a bug you introduced in the previous patch. We
> should really avoid introducing (latent) regression in a series. So
> please re-order the patches.
> 

Ok.

> >
> > In this patch we introduce .text.idmap to head_mmu.S, and
> > add this section after .text.header. to ensure code of
> > head_mmu.S after the code of header.S.
> >
> > After this, we will still include some code that does not
> > belong to identity map before _end_boot. Because we have
> > moved _end_boot to head_mmu.S.
> 
> I dislike this approach because you are expecting that only head_mmu.S
> will be part of .text.idmap. If it is not, everything could blow up again.
> 

I agree.

> That said, if you look at staging, you will notice that now _end_boot is
> defined in the linker script to avoid any issue.
> 

Sorry, I am not quite clear about this comment. The _end_boot of original
staging branch is defined in head.S. And I am not quite sure how this
_end_boot solve multiple files contain idmap code.

Cheers,
Wei Chen

> > That means all code in head.S
> > will be included before _end_boot. In this patch, we also
> > added .text flag in the place of original _end_boot in head.S.
> > All the code after .text in head.S will not be included in
> > identity map section.
> >
> > Signed-off-by: Wei Chen 
> > ---
> > v1 -> v2:
> > 1. New patch.
> > ---
> >   xen/arch/arm/arm64/head.S | 6 ++
> >   xen/arch/arm/arm64/head_mmu.S | 2 +-
> >   xen/arch/arm/xen.lds.S| 1 +
> >   3 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> > index 5cfa47279b..782bd1f94c 100644
> > --- a/xen/arch/arm/arm64/head.S
> > +++ b/xen/arch/arm/arm64/head.S
> > @@ -466,6 +466,12 @@ fail:   PRINT("- Boot failed -\r\n")
> >   b 1b
> >   ENDPROC(fail)
> >
> > +/*
> > + * For the code that do not need in indentity map section,
> > + * we put them back to normal .text section
> > + */
> > +.section .text, "ax", %progbits
> > +
> 
> I would argue that puts wants to be part of the idmap.
> 

I am ok to move puts to idmap. But from the original head.S, puts is
placed after _end_boot, and from the xen.ld.S, we can see idmap is
area is the section of "_end_boot - start". The reason of moving puts
to idmap is because we're using it in idmap?

Cheers,
Wei Chen

> >   #ifdef CONFIG_EARLY_PRINTK
> >   /*
> >* Initialize the UART. Should only be called on the boot CPU.
> > diff --git a/xen/arch/arm/arm64/head_mmu.S
> b/xen/arch/arm/arm64/head_mmu.S
> > index e2c8f07140..6ff13c751c 100644
> > --- a/xen/arch/arm/arm64/head_mmu.S
> > +++ b/xen/arch/arm/arm64/head_mmu.S
> > @@ -105,7 +105,7 @@
> >   str   \tmp2, [\tmp3, \tmp1, lsl #3]
> >   .endm
> >
> > -.section .text.header, "ax", %progbits
> > +.section .text.idmap, "ax", %progbits
> >   /*.aarch64*/
> >
> >   /*
> > diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> > index 92c2984052..bc45ea2c65 100644
> > --- a/xen/arch/arm/xen.lds.S
> > +++ b/xen/arch/arm/xen.lds.S
> > @@ -33,6 +33,7 @@ SECTIONS
> > .text : {
> >   _stext = .;/* Text section */
> >  *(.text.header)
> > +   *(.text.idmap)
> >
> >  *(.text.cold)
> >  *(.text.unlikely .text.*_unlikely .text.unlikely.*)
> 
> Cheers,
> 
> --
> Julien Grall

Re: [PATCH v2 0/7] x86: retbleed=stuff fixes

[Joan Bruguera]

Thanks, I've been testing those patches on my real system (i5-7200U) for
the last day with no problems so far, waking from s2ram works as well.
I can also no longer see those `sarq $5, %gs:0x1337` with %gs=0 on QEMU.

Regards,
- Joan

RE: [PATCH v2 08/40] xen/arm: use PA == VA for EARLY_UART_VIRTUAL_ADDRESS on Armv-8R

[Wei Chen]

Hi Julien,

> -Original Message-
> From: Julien Grall 
> Sent: 2023年1月18日 7:49
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk 
> Subject: Re: [PATCH v2 08/40] xen/arm: use PA == VA for
> EARLY_UART_VIRTUAL_ADDRESS on Armv-8R
> 
> Hi Penny,
> 
> On 13/01/2023 05:28, Penny Zheng wrote:
> > From: Wei Chen 
> >
> > There is no VMSA support on Armv8-R AArch64, so we can not map early
> > UART to FIXMAP_CONSOLE. Instead, we use PA == VA to define
> > EARLY_UART_VIRTUAL_ADDRESS on Armv8-R AArch64.
> >
> > Signed-off-by: Wei Chen 
> 
> Your signed-off-by is missing.
> 
> > ---
> > 1. New patch
> > ---
> >   xen/arch/arm/include/asm/early_printk.h | 12 
> >   1 file changed, 12 insertions(+)
> >
> > diff --git a/xen/arch/arm/include/asm/early_printk.h
> b/xen/arch/arm/include/asm/early_printk.h
> > index c5149b2976..44a230853f 100644
> > --- a/xen/arch/arm/include/asm/early_printk.h
> > +++ b/xen/arch/arm/include/asm/early_printk.h
> > @@ -15,10 +15,22 @@
> >
> >   #ifdef CONFIG_EARLY_PRINTK
> >
> > +#ifdef CONFIG_ARM_V8R
> 
> Shouldn't this be CONFIG_HAS_MPU?
> 

We had considered that there may be an implementation of Arm8R without
an MPU, so we used CONFIG_ARM_V8R here. But you're right, we have not
support non-MPU scenario in this series, so use CONFIG_HAS_MPU here
would be better to indicate this is a feature based code section.
We will change it to CONFIG_HAS_MPU in next version.

> > +
> > +/*
> > + * For Armv-8r, there is not VMSA support in EL2, so we use VA == PA
> 
> s/not/no/
> 

Ok.

Cheers,
Wei Chen

> > + * for EARLY_UART_VIRTUAL_ADDRESS. > + */
> > +#define EARLY_UART_VIRTUAL_ADDRESS CONFIG_EARLY_UART_BASE_ADDRESS
> > +
> > +#else
> > +
> >   /* need to add the uart address offset in page to the fixmap address
> */
> >   #define EARLY_UART_VIRTUAL_ADDRESS \
> >   (FIXMAP_ADDR(FIXMAP_CONSOLE) + (CONFIG_EARLY_UART_BASE_ADDRESS &
> ~PAGE_MASK))
> >
> > +#endif /* CONFIG_ARM_V8R */
> > +
> >   #endif /* !CONFIG_EARLY_PRINTK */
> >
> >   #endif
> 
> Cheers,
> 
> --
> Julien Grall

Re: [PATCH v4 4/4] automation: add RISC-V smoke test

[Alistair Francis]

On Tue, Jan 17, 2023 at 12:40 AM Oleksii Kurochko
 wrote:
>
> Add check if there is a message 'Hello from C env' presents
> in log file to be sure that stack is set and C part of early printk
> is working.
>
> Signed-off-by: Oleksii Kurochko 
> Acked-by: Stefano Stabellini 

Reviewed-by: Alistair Francis 

Alistair

> ---
> Changes in V4:
> - Nothing changed
> ---
> Changes in V3:
> - Nothing changed
> - All mentioned comments by Stefano in Xen mailing list will be
>   fixed as a separate patch out of this patch series.
> ---
>  automation/gitlab-ci/test.yaml   | 20 
>  automation/scripts/qemu-smoke-riscv64.sh | 20 
>  2 files changed, 40 insertions(+)
>  create mode 100755 automation/scripts/qemu-smoke-riscv64.sh
>
> diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
> index afd80adfe1..64f47a0ab9 100644
> --- a/automation/gitlab-ci/test.yaml
> +++ b/automation/gitlab-ci/test.yaml
> @@ -54,6 +54,19 @@
>tags:
>  - x86_64
>
> +.qemu-riscv64:
> +  extends: .test-jobs-common
> +  variables:
> +CONTAINER: archlinux:riscv64
> +LOGFILE: qemu-smoke-riscv64.log
> +  artifacts:
> +paths:
> +  - smoke.serial
> +  - '*.log'
> +when: always
> +  tags:
> +- x86_64
> +
>  .yocto-test:
>extends: .test-jobs-common
>script:
> @@ -234,6 +247,13 @@ qemu-smoke-x86-64-clang-pvh:
>needs:
>  - debian-unstable-clang-debug
>
> +qemu-smoke-riscv64-gcc:
> +  extends: .qemu-riscv64
> +  script:
> +- ./automation/scripts/qemu-smoke-riscv64.sh 2>&1 | tee ${LOGFILE}
> +  needs:
> +- riscv64-cross-gcc
> +
>  # Yocto test jobs
>  yocto-qemuarm64:
>extends: .yocto-test-arm64
> diff --git a/automation/scripts/qemu-smoke-riscv64.sh 
> b/automation/scripts/qemu-smoke-riscv64.sh
> new file mode 100755
> index 00..e0f06360bc
> --- /dev/null
> +++ b/automation/scripts/qemu-smoke-riscv64.sh
> @@ -0,0 +1,20 @@
> +#!/bin/bash
> +
> +set -ex
> +
> +# Run the test
> +rm -f smoke.serial
> +set +e
> +
> +timeout -k 1 2 \
> +qemu-system-riscv64 \
> +-M virt \
> +-smp 1 \
> +-nographic \
> +-m 2g \
> +-kernel binaries/xen \
> +|& tee smoke.serial
> +
> +set -e
> +(grep -q "Hello from C env" smoke.serial) || exit 1
> +exit 0
> --
> 2.39.0
>
>

Re: [PATCH v4 2/4] xen/riscv: introduce sbi call to putchar to console

[Alistair Francis]

On Tue, Jan 17, 2023 at 12:39 AM Oleksii Kurochko
 wrote:
>
> From: Bobby Eshleman 
>
> Originally SBI implementation for Xen was introduced by
> Bobby Eshleman  but it was removed
> all the stuff for simplicity  except SBI call for putting
> character to console.
>
> The patch introduces sbi_putchar() SBI call which is necessary
> to implement initial early_printk.
>
> Signed-off-by: Bobby Eshleman 
> Signed-off-by: Oleksii Kurochko 

Reviewed-by: Alistair Francis 

Alistair

> ---
> Changes in V4:
> - Nothing changed
> ---
> Changes in V3:
> - update copyright's year
> - rename definition of __CPU_SBI_H__ to __ASM_RISCV_SBI_H__
> - fix identations
> - change an author of the commit
> ---
> Changes in V2:
> - add an explanatory comment about sbi_console_putchar() function.
> - order the files alphabetically in Makefile
> ---
>  xen/arch/riscv/Makefile  |  1 +
>  xen/arch/riscv/include/asm/sbi.h | 34 
>  xen/arch/riscv/sbi.c | 45 
>  3 files changed, 80 insertions(+)
>  create mode 100644 xen/arch/riscv/include/asm/sbi.h
>  create mode 100644 xen/arch/riscv/sbi.c
>
> diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
> index 5a67a3f493..fd916e1004 100644
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_RISCV_64) += riscv64/
> +obj-y += sbi.o
>  obj-y += setup.o
>
>  $(TARGET): $(TARGET)-syms
> diff --git a/xen/arch/riscv/include/asm/sbi.h 
> b/xen/arch/riscv/include/asm/sbi.h
> new file mode 100644
> index 00..0e6820a4ed
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/sbi.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: (GPL-2.0-or-later) */
> +/*
> + * Copyright (c) 2021-2023 Vates SAS.
> + *
> + * Taken from xvisor, modified by Bobby Eshleman (bobby.eshle...@gmail.com).
> + *
> + * Taken/modified from Xvisor project with the following copyright:
> + *
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + */
> +
> +#ifndef __ASM_RISCV_SBI_H__
> +#define __ASM_RISCV_SBI_H__
> +
> +#define SBI_EXT_0_1_CONSOLE_PUTCHAR0x1
> +
> +struct sbiret {
> +long error;
> +long value;
> +};
> +
> +struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
> +unsigned long arg0, unsigned long arg1,
> +unsigned long arg2, unsigned long arg3,
> +unsigned long arg4, unsigned long arg5);
> +
> +/**
> + * Writes given character to the console device.
> + *
> + * @param ch The data to be written to the console.
> + */
> +void sbi_console_putchar(int ch);
> +
> +#endif /* __ASM_RISCV_SBI_H__ */
> diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c
> new file mode 100644
> index 00..dc0eb44bc6
> --- /dev/null
> +++ b/xen/arch/riscv/sbi.c
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Taken and modified from the xvisor project with the copyright Copyright 
> (c)
> + * 2019 Western Digital Corporation or its affiliates and author Anup Patel
> + * (anup.pa...@wdc.com).
> + *
> + * Modified by Bobby Eshleman (bobby.eshle...@gmail.com).
> + *
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + * Copyright (c) 2021-2023 Vates SAS.
> + */
> +
> +#include 
> +#include 
> +
> +struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
> +unsigned long arg0, unsigned long arg1,
> +unsigned long arg2, unsigned long arg3,
> +unsigned long arg4, unsigned long arg5)
> +{
> +struct sbiret ret;
> +
> +register unsigned long a0 asm ("a0") = arg0;
> +register unsigned long a1 asm ("a1") = arg1;
> +register unsigned long a2 asm ("a2") = arg2;
> +register unsigned long a3 asm ("a3") = arg3;
> +register unsigned long a4 asm ("a4") = arg4;
> +register unsigned long a5 asm ("a5") = arg5;
> +register unsigned long a6 asm ("a6") = fid;
> +register unsigned long a7 asm ("a7") = ext;
> +
> +asm volatile ("ecall"
> +  : "+r" (a0), "+r" (a1)
> +  : "r" (a2), "r" (a3), "r" (a4), "r" (a5), "r" (a6), "r" (a7)
> +  : "memory");
> +ret.error = a0;
> +ret.value = a1;
> +
> +return ret;
> +}
> +
> +void sbi_console_putchar(int ch)
> +{
> +sbi_ecall(SBI_EXT_0_1_CONSOLE_PUTCHAR, 0, ch, 0, 0, 0, 0, 0);
> +}
> --
> 2.39.0
>
>

[xen-unstable-smoke test] 175949: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  broken
 build-amd64   6 xen-buildfail REGR. vs. 175746

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   5 host-install(5)  broken pass in 175944

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl 15 migrate-support-check fail in 175944 never pass
 test-armhf-armhf-xl 16 saverestore-support-check fail in 175944 never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
baseline version:
 xen  6bec713f871f21c6254a5783c1e39867ea828256

Last test of basis   175746  2023-01-12 16:03:41 Z5 days
Failing since175748  2023-01-12 20:01:56 Z5 days   24 attempts
Testing same since   175833  2023-01-14 07:00:25 Z3 days   22 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 
  Michal Orzel 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  broken  
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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

broken-job test-armhf-armhf-xl broken
broken-step test-armhf-armhf-xl host-install(5)

Not pushing.


commit f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
Author: Michal Orzel 
Date:   Tue Jan 3 11:25:19 2023 +0100

xen/arm: Add 0x prefix when printing memory size in construct_domU

Printing memory size in hex without 0x prefix can be misleading, so
add it. Also, take the opportunity to adhere to 80 chars line length
limit by moving the printk arguments to the next line.

Signed-off-by: Michal Orzel 
Reviewed-by: Ayan Kumar Halder 
Acked-by: Julien Grall 

commit 229ebd517b9df0e2d2f9e3ea50b57ca716334826
Author: Julien Grall 
Date:   Thu Jan 12 22:07:42 2023 +

xen/arm: linker: The identitymap check should cover the whole .text.header

At the moment, we are only checking that only some part of .text.header
is part of the identity mapping. However, this doesn't take into account
the literal pool which will be located at the end of the section.

While we could try to avoid using a literal pool, in the near future we
will also want to use an identity mapping for switch_ttbr().

Not everything in .text.header requires to be part of the identity
mapping. But it is below a page size (i.e. 4KB) so take a shortcut and
check that .text.header is smaller than a page size.

With that _end_boot can be removed as it is now unused. Take the
opportunity to avoid assuming that a page size is always 4KB in the
error message and comment.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit 22a9981ba2443bd569bad6b772fb6e7e64f0d714
Author: Julien Grall 
Date:   Thu Jan 12 22:06:42 2023 +

xen/arm: linker: Indent correctly _stext

_stext is indented by one space more compare to the lines. This doesn't
seem warrant, so delete the extra space.

Signed-off: Julien Grall 
Acked-by: Stefano Stabellini 

commit 3edca52ce736297d7fcf293860cd94ef62638052
Author: Andrew Cooper 
Date:   Mon Jan 9 10:58:31 2023 +

x86/vmx: Support for CPUs without model-specific LBR

Ice 

Re: [PATCH v4 3/4] xen/riscv: introduce early_printk basic stuff

[Julien Grall]

On Tue, 17 Jan 2023 at 23:57, Andrew Cooper 
wrote:

> On 16/01/2023 2:39 pm, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/riscv/Kconfig.debug b/xen/arch/riscv/Kconfig.debug
> > index e69de29bb2..e139e44873 100644
> > --- a/xen/arch/riscv/Kconfig.debug
> > +++ b/xen/arch/riscv/Kconfig.debug
> > @@ -0,0 +1,6 @@
> > +config EARLY_PRINTK
> > +bool "Enable early printk"
> > +default DEBUG
> > +help
> > +
> > +  Enables early printk debug messages
>
> Kconfig indentation is a little hard to get used to.
>
> It's one tab for the main block, and one tab + 2 spaces for the help text.
>
> Also, drop the blank line after help.
>
> > diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
> > index fd916e1004..1a4f1a6015 100644
> > --- a/xen/arch/riscv/Makefile
> > +++ b/xen/arch/riscv/Makefile
> > @@ -1,3 +1,4 @@
> > +obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
> >  obj-$(CONFIG_RISCV_64) += riscv64/
> >  obj-y += sbi.o
> >  obj-y += setup.o
> > diff --git a/xen/arch/riscv/early_printk.c
> b/xen/arch/riscv/early_printk.c
> > new file mode 100644
> > index 00..6bc29a1942
> > --- /dev/null
> > +++ b/xen/arch/riscv/early_printk.c
> > @@ -0,0 +1,45 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * RISC-V early printk using SBI
> > + *
> > + * Copyright (C) 2021 Bobby Eshleman 
> > + */
> > +#include 
> > +#include 
> > +
> > +/*
> > + * early_*() can be called from head.S with MMU-off.
> > + *
> > + * The following requiremets should be honoured for early_*() to
> > + * work correctly:
> > + *It should use PC-relative addressing for accessing symbols.
> > + *To achieve that GCC cmodel=medany should be used.
> > + */
> > +#ifndef __riscv_cmodel_medany
> > +#error "early_*() can be called from head.S before relocate so it
> should not use absolute addressing."
> > +#endif
>
> This is incorrect.


Aside the part about the relocation, I do not see what is wrong with it
(see below)

>
>
> What *this* file is compiled with has no bearing on how head.S calls
> us.  The RISC-V documentation explaining __riscv_cmodel_medany vs
> __riscv_cmodel_medlow calls this point out specifically.  There's
> nothing you can put here to check that head.S gets compiled with medany.


I believe you misunderstood the goal here. It is not to check how head.S
will call it but to ensure the function is safe to be called when the MMU
is off (e.g VA != VA).


>
> Right now, there's nothing in this file dependent on either mode, and
> it's not liable to change in the short term.


The whole point is to make sure this don’t change without us knowing.


  Furthermore, Xen isn't
> doing any relocation in the first place.
>
> We will want to support XIP in due course, and that will be compiled
> __riscv_cmodel_medlow, which is a fine and legitimate usecase.
>
>
> The build system sets the model up consistently.  All you are doing by
> putting this in is creating work that someone is going to have to delete
> for legitimate reasons in the future.



Are you saying that a code compiled with medlow can also work with MMU off
and no relocation needed?

If not, then the check is correct. It would avoid hours of debugging…

Cheers,


>
> > diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> > index 13e24e2fe1..9c9412152a 100644
> > --- a/xen/arch/riscv/setup.c
> > +++ b/xen/arch/riscv/setup.c
> > @@ -1,13 +1,17 @@
> >  #include 
> >  #include 
> >
> > +#include 
> > +
> >  /* Xen stack for bringing up the first CPU. */
> >  unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
> >  __aligned(STACK_SIZE);
> >
> >  void __init noreturn start_xen(void)
> >  {
> > -for ( ;; )
> > +early_printk("Hello from C env\n");
> > +
> > +for ( ; ; )
>
> Rebasing error?
>
> ~Andrew
>
-- 
Julien Grall

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

[Chuck Zmudzinski]

On 1/17/2023 6:04 AM, Igor Mammedov wrote:
> On Mon, 16 Jan 2023 13:00:53 -0500
> Chuck Zmudzinski  wrote:
>
> > On 1/16/23 10:33, Igor Mammedov wrote:
> > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > Chuck Zmudzinski  wrote:
> > >   
> > >> On 1/13/23 4:33 AM, Igor Mammedov wrote:  
> > >> > On Thu, 12 Jan 2023 23:14:26 -0500
> > >> > Chuck Zmudzinski  wrote:
> > >> > 
> > >> >> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:
> > >> >> > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote:   
> > >> >> >
> > >> >> >> I think the change Michael suggests is very minimalistic: Move the 
> > >> >> >> if
> > >> >> >> condition around xen_igd_reserve_slot() into the function itself 
> > >> >> >> and
> > >> >> >> always call it there unconditionally -- basically turning three 
> > >> >> >> lines
> > >> >> >> into one. Since xen_igd_reserve_slot() seems very problem specific,
> > >> >> >> Michael further suggests to rename it to something more general. 
> > >> >> >> All
> > >> >> >> in all no big changes required.  
> > >> >> > 
> > >> >> > yes, exactly.
> > >> >> >   
> > >> >> 
> > >> >> OK, got it. I can do that along with the other suggestions.
> > >> > 
> > >> > have you considered instead of reservation, putting a slot check in 
> > >> > device model
> > >> > and if it's intel igd being passed through, fail at realize time  if 
> > >> > it can't take
> > >> > required slot (with a error directing user to fix command line)?
> > >> 
> > >> Yes, but the core pci code currently already fails at realize time
> > >> with a useful error message if the user tries to use slot 2 for the
> > >> igd, because of the xen platform device which has slot 2. The user
> > >> can fix this without patching qemu, but having the user fix it on
> > >> the command line is not the best way to solve the problem, primarily
> > >> because the user would need to hotplug the xen platform device via a
> > >> command line option instead of having the xen platform device added by
> > >> pc_xen_hvm_init functions almost immediately after creating the pci
> > >> bus, and that delay in adding the xen platform device degrades
> > >> startup performance of the guest.
> > >>   
> > >> > That could be less complicated than dealing with slot reservations at 
> > >> > the cost of
> > >> > being less convenient.
> > >> 
> > >> And also a cost of reduced startup performance  
> > > 
> > > Could you clarify how it affects performance (and how much).
> > > (as I see, setup done at board_init time is roughly the same
> > > as with '-device foo' CLI options, modulo time needed to parse
> > > options which should be negligible. and both ways are done before
> > > guest runs)  
> > 
> > I preface my answer by saying there is a v9, but you don't
> > need to look at that. I will answer all your questions here.
> > 
> > I am going by what I observe on the main HDMI display with the
> > different approaches. With the approach of not patching Qemu
> > to fix this, which requires adding the Xen platform device a
> > little later, the length of time it takes to fully load the
> > guest is increased. I also noticed with Linux guests that use
> > the grub bootoader, the grub vga driver cannot display the
> > grub boot menu at the native resolution of the display, which
> > in the tested case is 1920x1080, when the Xen platform device
> > is added via a command line option instead of by the
> > pc_xen_hvm_init_pci fucntion in pc_piix.c, but with this patch
> > to Qemu, the grub menu is displayed at the full, 1920x1080
> > native resolution of the display. Once the guest fully loads,
> > there is no noticeable difference in performance. It is mainly
> > a degradation in startup performance, not performance once
> > the guest OS is fully loaded.
>
> Looking at igd-assign.txt, it recommends to add IGD using '-device' CLI
> option, and actually drop at least graphics defaults explicitly.
> So it is expected to work fine even when IGD is constructed with
> '-device'.
>
> Could you provide full CLI current xen starts QEMU with and then
> a CLI you used (with explicit -device for IGD) that leads
> to reduced performance?
>
> CCing vfio folks who might have an idea what could be wrong based
> on vfio experience.

Actually, the igd is not added with an explicit -device option using Xen:

   1573 ?    Ssl    0:42 /usr/bin/qemu-system-i386 -xen-domid 1 
-no-shutdown -chardev 
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-1,server,nowait -mon 
chardev=libxl-cmd,mode=control -chardev 
socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-1,server,nowait -mon 
chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name windows 
-vnc none -display none -serial pty -boot order=c -smp 4,maxcpus=4 -net none 
-machine xenfv,max-ram-below-4g=3758096384,igd-passthru=on -m 6144 -drive 
file=/dev/loop0,if=ide,index=0,media=disk,format=raw,cache=writeback -drive 

Re: [PATCH v4 3/4] xen/riscv: introduce early_printk basic stuff

[Andrew Cooper]

On 16/01/2023 2:39 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/Kconfig.debug b/xen/arch/riscv/Kconfig.debug
> index e69de29bb2..e139e44873 100644
> --- a/xen/arch/riscv/Kconfig.debug
> +++ b/xen/arch/riscv/Kconfig.debug
> @@ -0,0 +1,6 @@
> +config EARLY_PRINTK
> +bool "Enable early printk"
> +default DEBUG
> +help
> +
> +  Enables early printk debug messages

Kconfig indentation is a little hard to get used to.

It's one tab for the main block, and one tab + 2 spaces for the help text.

Also, drop the blank line after help.

> diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
> index fd916e1004..1a4f1a6015 100644
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -1,3 +1,4 @@
> +obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
>  obj-$(CONFIG_RISCV_64) += riscv64/
>  obj-y += sbi.o
>  obj-y += setup.o
> diff --git a/xen/arch/riscv/early_printk.c b/xen/arch/riscv/early_printk.c
> new file mode 100644
> index 00..6bc29a1942
> --- /dev/null
> +++ b/xen/arch/riscv/early_printk.c
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * RISC-V early printk using SBI
> + *
> + * Copyright (C) 2021 Bobby Eshleman 
> + */
> +#include 
> +#include 
> +
> +/*
> + * early_*() can be called from head.S with MMU-off.
> + *
> + * The following requiremets should be honoured for early_*() to
> + * work correctly:
> + *It should use PC-relative addressing for accessing symbols.
> + *To achieve that GCC cmodel=medany should be used.
> + */
> +#ifndef __riscv_cmodel_medany
> +#error "early_*() can be called from head.S before relocate so it should not 
> use absolute addressing."
> +#endif

This is incorrect.

What *this* file is compiled with has no bearing on how head.S calls
us.  The RISC-V documentation explaining __riscv_cmodel_medany vs
__riscv_cmodel_medlow calls this point out specifically.  There's
nothing you can put here to check that head.S gets compiled with medany.

Right now, there's nothing in this file dependent on either mode, and
it's not liable to change in the short term.  Furthermore, Xen isn't
doing any relocation in the first place.

We will want to support XIP in due course, and that will be compiled
__riscv_cmodel_medlow, which is a fine and legitimate usecase.


The build system sets the model up consistently.  All you are doing by
putting this in is creating work that someone is going to have to delete
for legitimate reasons in the future.

> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> index 13e24e2fe1..9c9412152a 100644
> --- a/xen/arch/riscv/setup.c
> +++ b/xen/arch/riscv/setup.c
> @@ -1,13 +1,17 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  /* Xen stack for bringing up the first CPU. */
>  unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
>  __aligned(STACK_SIZE);
>  
>  void __init noreturn start_xen(void)
>  {
> -for ( ;; )
> +early_printk("Hello from C env\n");
> +
> +for ( ; ; )

Rebasing error?

~Andrew

Re: [PATCH v2 08/40] xen/arm: use PA == VA for EARLY_UART_VIRTUAL_ADDRESS on Armv-8R

[Julien Grall]

Hi Penny,

On 13/01/2023 05:28, Penny Zheng wrote:

From: Wei Chen 

There is no VMSA support on Armv8-R AArch64, so we can not map early
UART to FIXMAP_CONSOLE. Instead, we use PA == VA to define
EARLY_UART_VIRTUAL_ADDRESS on Armv8-R AArch64.

Signed-off-by: Wei Chen 


Your signed-off-by is missing.


---
1. New patch
---
  xen/arch/arm/include/asm/early_printk.h | 12 
  1 file changed, 12 insertions(+)

diff --git a/xen/arch/arm/include/asm/early_printk.h 
b/xen/arch/arm/include/asm/early_printk.h
index c5149b2976..44a230853f 100644
--- a/xen/arch/arm/include/asm/early_printk.h
+++ b/xen/arch/arm/include/asm/early_printk.h
@@ -15,10 +15,22 @@
  
  #ifdef CONFIG_EARLY_PRINTK
  
+#ifdef CONFIG_ARM_V8R


Shouldn't this be CONFIG_HAS_MPU?


+
+/*
+ * For Armv-8r, there is not VMSA support in EL2, so we use VA == PA


s/not/no/


+ * for EARLY_UART_VIRTUAL_ADDRESS. > + */
+#define EARLY_UART_VIRTUAL_ADDRESS CONFIG_EARLY_UART_BASE_ADDRESS
+
+#else
+
  /* need to add the uart address offset in page to the fixmap address */
  #define EARLY_UART_VIRTUAL_ADDRESS \
  (FIXMAP_ADDR(FIXMAP_CONSOLE) + (CONFIG_EARLY_UART_BASE_ADDRESS & 
~PAGE_MASK))
  
+#endif /* CONFIG_ARM_V8R */

+
  #endif /* !CONFIG_EARLY_PRINTK */
  
  #endif


Cheers,

--
Julien Grall

Re: [PATCH v2 07/40] xen/arm64: add .text.idmap for Xen identity map sections

[Julien Grall]

Hi,

On 13/01/2023 05:28, Penny Zheng wrote:

From: Wei Chen 

Only the first 4KB of Xen image will be mapped as identity
(PA == VA). At the moment, Xen guarantees this by having
everything that needs to be used in the identity mapping
in head.S before _end_boot and checking at link time if this
fits in 4KB.

In previous patch, we have moved the MMU code outside of
head.S. Although we have added .text.header to the new file
to guarantee all identity map code still in the first 4KB.
However, the order of these two files on this 4KB depends
on the build tools. Currently, we use the build tools to
process the order of objs in the Makefile to ensure that
head.S must be at the top. But if you change to another build
tools, it may not be the same result.


Right, so this is fixing a bug you introduced in the previous patch. We 
should really avoid introducing (latent) regression in a series. So 
please re-order the patches.




In this patch we introduce .text.idmap to head_mmu.S, and
add this section after .text.header. to ensure code of
head_mmu.S after the code of header.S.

After this, we will still include some code that does not
belong to identity map before _end_boot. Because we have
moved _end_boot to head_mmu.S. 


I dislike this approach because you are expecting that only head_mmu.S 
will be part of .text.idmap. If it is not, everything could blow up again.


That said, if you look at staging, you will notice that now _end_boot is 
defined in the linker script to avoid any issue.



That means all code in head.S
will be included before _end_boot. In this patch, we also
added .text flag in the place of original _end_boot in head.S.
All the code after .text in head.S will not be included in
identity map section.

Signed-off-by: Wei Chen 
---
v1 -> v2:
1. New patch.
---
  xen/arch/arm/arm64/head.S | 6 ++
  xen/arch/arm/arm64/head_mmu.S | 2 +-
  xen/arch/arm/xen.lds.S| 1 +
  3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 5cfa47279b..782bd1f94c 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -466,6 +466,12 @@ fail:   PRINT("- Boot failed -\r\n")
  b 1b
  ENDPROC(fail)
  
+/*

+ * For the code that do not need in indentity map section,
+ * we put them back to normal .text section
+ */
+.section .text, "ax", %progbits
+


I would argue that puts wants to be part of the idmap.


  #ifdef CONFIG_EARLY_PRINTK
  /*
   * Initialize the UART. Should only be called on the boot CPU.
diff --git a/xen/arch/arm/arm64/head_mmu.S b/xen/arch/arm/arm64/head_mmu.S
index e2c8f07140..6ff13c751c 100644
--- a/xen/arch/arm/arm64/head_mmu.S
+++ b/xen/arch/arm/arm64/head_mmu.S
@@ -105,7 +105,7 @@
  str   \tmp2, [\tmp3, \tmp1, lsl #3]
  .endm
  
-.section .text.header, "ax", %progbits

+.section .text.idmap, "ax", %progbits
  /*.aarch64*/
  
  /*

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 92c2984052..bc45ea2c65 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -33,6 +33,7 @@ SECTIONS
.text : {
  _stext = .;/* Text section */
 *(.text.header)
+   *(.text.idmap)
  
 *(.text.cold)

 *(.text.unlikely .text.*_unlikely .text.unlikely.*)


Cheers,

--
Julien Grall

Re: [PATCH v2 05/40] xen/arm64: prepare for moving MMU related code from head.S

[Julien Grall]

Hi Penny,

On 13/01/2023 05:28, Penny Zheng wrote:

From: Wei Chen 

We want to reuse head.S for MPU systems, but there are some
code implemented for MMU systems only. We will move such
code to another MMU specific file. But before that, we will
do some preparations in this patch to make them easier
for reviewing:


Well, I agree that...


1. Fix the indentations of code comments.


... changing the indentation is better here. But...


2. Export some symbols that will be accessed out of file
scope.


... I have no idea which functions are going to be used in a separate 
file. So I think they should belong to the patch moving the code.




Signed-off-by: Wei Chen 


Your signed-off-by is missing.


---
v1 -> v2:
1. New patch.
---
  xen/arch/arm/arm64/head.S | 40 +++
  1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 93f9b0b9d5..b2214bc5e3 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -136,22 +136,22 @@
  add \xb, \xb, x20
  .endm
  
-.section .text.header, "ax", %progbits

-/*.aarch64*/
+.section .text.header, "ax", %progbits
+/*.aarch64*/


This change is not mentioned.

  
-/*

- * Kernel startup entry point.
- * ---
- *
- * The requirements are:
- *   MMU = off, D-cache = off, I-cache = on or off,
- *   x0 = physical address to the FDT blob.
- *
- * This must be the very first address in the loaded image.
- * It should be linked at XEN_VIRT_START, and loaded at any
- * 4K-aligned address.  All of text+data+bss must fit in 2MB,
- * or the initial pagetable code below will need adjustment.
- */
+/*
+ * Kernel startup entry point.
+ * ---
+ *
+ * The requirements are:
+ *   MMU = off, D-cache = off, I-cache = on or off,
+ *   x0 = physical address to the FDT blob.
+ *
+ * This must be the very first address in the loaded image.
+ * It should be linked at XEN_VIRT_START, and loaded at any
+ * 4K-aligned address.  All of text+data+bss must fit in 2MB,
+ * or the initial pagetable code below will need adjustment.
+ */
  
  GLOBAL(start)

  /*
@@ -586,7 +586,7 @@ ENDPROC(cpu_init)
   *
   * Clobbers x0 - x4
   */
-create_page_tables:
+ENTRY(create_page_tables)


I am not sure about keeping this name. Now we have create_page_tables() 
and arch_setup_page_tables().


I would conside to name it create_boot_page_tables().


  /* Prepare the page-tables for mapping Xen */
  ldr   x0, =XEN_VIRT_START
  create_table_entry boot_pgtable, boot_first, x0, 0, x1, x2, x3
@@ -680,7 +680,7 @@ ENDPROC(create_page_tables)
   *
   * Clobbers x0 - x3
   */
-enable_mmu:
+ENTRY(enable_mmu)
  PRINT("- Turning on paging -\r\n")
  
  /*

@@ -714,7 +714,7 @@ ENDPROC(enable_mmu)
   *
   * Clobbers x0 - x1
   */
-remove_identity_mapping:
+ENTRY(remove_identity_mapping)


Patch #14 should be before this patch. So you don't have to export 
remove_identity_mapping temporarily.


This will also avoid (transient) naming confusing with my work (see [1]).


  /*
   * Find the zeroeth slot used. Remove the entry from zeroeth
   * table if the slot is not XEN_ZEROETH_SLOT.
@@ -775,7 +775,7 @@ ENDPROC(remove_identity_mapping)
   *
   * Clobbers x0 - x3
   */
-setup_fixmap:
+ENTRY(setup_fixmap)
  #ifdef CONFIG_EARLY_PRINTK
  /* Add UART to the fixmap table */
  ldr   x0, =EARLY_UART_VIRTUAL_ADDRESS
@@ -871,7 +871,7 @@ ENDPROC(init_uart)
   * x0: Nul-terminated string to print.
   * x23: Early UART base address
   * Clobbers x0-x1 */
-puts:
+ENTRY(puts)


This name is a bit too generic to be globally exported. It is also now 
quite confusing because we have "early_puts" and "puts".


I would consider to name it asm_puts(). It is still not great but 
hopefully it would give a hint that should be call from assembly code.



  early_uart_ready x23, 1
  ldrb  w1, [x0], #1   /* Load next char */
  cbz   w1, 1f /* Exit on nul */


Cheers,

[1] https://lore.kernel.org/all/20230113101136.479-13-jul...@xen.org/

--
Julien Grall

Re: [PATCH v4 2/4] xen/riscv: introduce sbi call to putchar to console

[Andrew Cooper]

On 16/01/2023 2:39 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c
> new file mode 100644
> index 00..dc0eb44bc6
> --- /dev/null
> +++ b/xen/arch/riscv/sbi.c
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Taken and modified from the xvisor project with the copyright Copyright 
> (c)
> + * 2019 Western Digital Corporation or its affiliates and author Anup Patel
> + * (anup.pa...@wdc.com).
> + *
> + * Modified by Bobby Eshleman (bobby.eshle...@gmail.com).
> + *
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + * Copyright (c) 2021-2023 Vates SAS.
> + */
> +
> +#include 

Unused header.  All this file needs (in this form at least) is asm/sbi.h

> +#include 
> +
> +struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
> +unsigned long arg0, unsigned long arg1,
> +unsigned long arg2, unsigned long arg3,
> +unsigned long arg4, unsigned long arg5)
> +{
> +struct sbiret ret;
> +
> +register unsigned long a0 asm ("a0") = arg0;
> +register unsigned long a1 asm ("a1") = arg1;
> +register unsigned long a2 asm ("a2") = arg2;
> +register unsigned long a3 asm ("a3") = arg3;
> +register unsigned long a4 asm ("a4") = arg4;
> +register unsigned long a5 asm ("a5") = arg5;
> +register unsigned long a6 asm ("a6") = fid;
> +register unsigned long a7 asm ("a7") = ext;
> +
> +asm volatile ("ecall"
> +  : "+r" (a0), "+r" (a1)
> +  : "r" (a2), "r" (a3), "r" (a4), "r" (a5), "r" (a6), "r" (a7)
> +  : "memory");

Indentation.  Each colon wants 4 more spaces in front of it.

Both can be fixed on commit.

~Andrew

Re: [PATCH v2 04/40] xen/arm: add an option to define Xen start address for Armv8-R

[Julien Grall]

Hi Penny,

On 13/01/2023 05:28, Penny Zheng wrote:

From: Wei Chen 

On Armv8-A, Xen has a fixed virtual start address (link address
too) for all Armv8-A platforms. In an MMU based system, Xen can
map its loaded address to this virtual start address. So, on
Armv8-A platforms, the Xen start address does not need to be
configurable. But on Armv8-R platforms, there is no MMU to map
loaded address to a fixed virtual address and different platforms
will have very different address space layout. So Xen cannot use
a fixed physical address on MPU based system and need to have it
configurable.

In this patch we introduce one Kconfig option for users to define
the default Xen start address for Armv8-R. Users can enter the
address in config time, or select the tailored platform config
file from arch/arm/configs.

And as we introduced Armv8-R platforms to Xen, that means the
existed Arm64 platforms should not be listed in Armv8-R platform
list, so we add !ARM_V8R dependency for these platforms.

Signed-off-by: Wei Chen 
Signed-off-by: Jiamei.Xie 


Your signed-off-by is missing.


---
v1 -> v2:
1. Remove the platform header fvp_baser.h.
2. Remove the default start address for fvp_baser64.
3. Remove the description of default address from commit log.
4. Change HAS_MPU to ARM_V8R for Xen start address dependency.
No matter Arm-v8r board has MPU or not, it always need to
specify the start address.


I don't quite understand the last sentence. Are you saying that it is 
possible to have an ARMv8-R system with an MPU nor a page-table?



---
  xen/arch/arm/Kconfig   |  8 
  xen/arch/arm/platforms/Kconfig | 16 +---
  2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index ace7178c9a..c6b6b612d1 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -145,6 +145,14 @@ config TEE
  This option enables generic TEE mediators support. It allows guests
  to access real TEE via one of TEE mediators implemented in XEN.
  
+config XEN_START_ADDRESS

+   hex "Xen start address: keep default to use platform defined address"
+   default 0
+   depends on ARM_V8R


It is still pretty unclear to me what would be the difference between 
HAS_MPU and ARM_V8R.



+   help
+ This option allows to set the customized address at which Xen will be
+ linked on MPU systems. This address must be aligned to a page size.
+
  source "arch/arm/tee/Kconfig"
  
  config STATIC_SHM

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
index c93a6b2756..0904793a0b 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -1,6 +1,7 @@
  choice
prompt "Platform Support"
default ALL_PLAT
+   default FVP_BASER if ARM_V8R
---help---
Choose which hardware platform to enable in Xen.
  
@@ -8,13 +9,14 @@ choice
  
  config ALL_PLAT

bool "All Platforms"
+   depends on !ARM_V8R
---help---
Enable support for all available hardware platforms. It doesn't
automatically select any of the related drivers.
  
  config QEMU

bool "QEMU aarch virt machine support"
-   depends on ARM_64
+   depends on ARM_64 && !ARM_V8R
select GICV3
select HAS_PL011
---help---
@@ -23,7 +25,7 @@ config QEMU
  
  config RCAR3

bool "Renesas RCar3 support"
-   depends on ARM_64
+   depends on ARM_64 && !ARM_V8R
select HAS_SCIF
select IPMMU_VMSA
---help---
@@ -31,14 +33,22 @@ config RCAR3
  
  config MPSOC

bool "Xilinx Ultrascale+ MPSoC support"
-   depends on ARM_64
+   depends on ARM_64 && !ARM_V8R
select HAS_CADENCE_UART
select ARM_SMMU
---help---
Enable all the required drivers for Xilinx Ultrascale+ MPSoC
  
+config FVP_BASER

+   bool "Fixed Virtual Platform BaseR support"
+   depends on ARM_V8R
+   help
+ Enable platform specific configurations for Fixed Virtual
+ Platform BaseR


This seems unrelated to this patch.


+
  config NO_PLAT
bool "No Platforms"
+   depends on !ARM_V8R
---help---
Do not enable specific support for any platform.
  


Cheers,

--
Julien Grall

Re: [PATCH v4 3/4] xen/riscv: introduce early_printk basic stuff

[Bobby Eshleman]

On Mon, Jan 16, 2023 at 04:39:31PM +0200, Oleksii Kurochko wrote:
> Because printk() relies on a serial driver (like the ns16550 driver)
> and drivers require working virtual memory (ioremap()) there is not
> print functionality early in Xen boot.
> 
> The patch introduces the basic stuff of early_printk functionality
> which will be enough to print 'hello from C environment".
> 
> Originally early_printk.{c,h} was introduced by Bobby Eshleman
> (https://github.com/glg-rv/xen/commit/a3c9916bbdff7ad6030055bbee7e53d1aab71384)
> but some functionality was changed:
> early_printk() function was changed in comparison with the original as
> common isn't being built now so there is no vscnprintf.
> 
> This commit adds early printk implementation built on the putc SBI call.
> 
> As sbi_console_putchar() is already being planned for deprecation
> it is used temporarily now and will be removed or reworked after
> real uart will be ready.
> 
> Signed-off-by: Bobby Eshleman 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V4:
> - Remove "depends on RISCV*" from Kconfig.debug as it is located in
>   arch specific folder so by default RISCV configs should be ebabled.
> - Add "ifdef __riscv_cmodel_medany" to be sure that PC-relative addressing
>   is used as early_*() functions can be called from head.S with MMU-off 
> and
>   before relocation (if it would be needed at all for RISC-V)
> - fix code style
> ---
> Changes in V3:
> - reorder headers in alphabetical order
> - merge changes related to start_xen() function from "[PATCH v2 7/8]
>   xen/riscv: print hello message from C env" to this patch
> - remove unneeded parentheses in definition of STACK_SIZE
> ---
> Changes in V2:
> - introduce STACK_SIZE define.
> - use consistent padding between instruction mnemonic and operand(s)
> ---
> ---
>  xen/arch/riscv/Kconfig.debug  |  6 +++
>  xen/arch/riscv/Makefile   |  1 +
>  xen/arch/riscv/early_printk.c | 45 +++
>  xen/arch/riscv/include/asm/early_printk.h | 12 ++
>  xen/arch/riscv/setup.c|  6 ++-
>  5 files changed, 69 insertions(+), 1 deletion(-)
>  create mode 100644 xen/arch/riscv/early_printk.c
>  create mode 100644 xen/arch/riscv/include/asm/early_printk.h
> 
> diff --git a/xen/arch/riscv/Kconfig.debug b/xen/arch/riscv/Kconfig.debug
> index e69de29bb2..e139e44873 100644
> --- a/xen/arch/riscv/Kconfig.debug
> +++ b/xen/arch/riscv/Kconfig.debug
> @@ -0,0 +1,6 @@
> +config EARLY_PRINTK
> +bool "Enable early printk"
> +default DEBUG
> +help
> +
> +  Enables early printk debug messages
> diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
> index fd916e1004..1a4f1a6015 100644
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -1,3 +1,4 @@
> +obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
>  obj-$(CONFIG_RISCV_64) += riscv64/
>  obj-y += sbi.o
>  obj-y += setup.o
> diff --git a/xen/arch/riscv/early_printk.c b/xen/arch/riscv/early_printk.c
> new file mode 100644
> index 00..6bc29a1942
> --- /dev/null
> +++ b/xen/arch/riscv/early_printk.c
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * RISC-V early printk using SBI
> + *
> + * Copyright (C) 2021 Bobby Eshleman 
> + */
> +#include 
> +#include 
> +
> +/*
> + * early_*() can be called from head.S with MMU-off.
> + *
> + * The following requiremets should be honoured for early_*() to
> + * work correctly:
> + *It should use PC-relative addressing for accessing symbols.
> + *To achieve that GCC cmodel=medany should be used.
> + */
> +#ifndef __riscv_cmodel_medany
> +#error "early_*() can be called from head.S before relocate so it should not 
> use absolute addressing."
> +#endif
> +
> +/*
> + * TODO:
> + *   sbi_console_putchar is already planned for deprecation
> + *   so it should be reworked to use UART directly.
> +*/
> +void early_puts(const char *s, size_t nr)
> +{
> +while ( nr-- > 0 )
> +{
> +if ( *s == '\n' )
> +sbi_console_putchar('\r');
> +sbi_console_putchar(*s);
> +s++;
> +}
> +}
> +
> +void early_printk(const char *str)
> +{
> +while ( *str )
> +{
> +early_puts(str, 1);
> +str++;
> +}
> +}
> diff --git a/xen/arch/riscv/include/asm/early_printk.h 
> b/xen/arch/riscv/include/asm/early_printk.h
> new file mode 100644
> index 00..05106e160d
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/early_printk.h
> @@ -0,0 +1,12 @@
> +#ifndef __EARLY_PRINTK_H__
> +#define __EARLY_PRINTK_H__
> +
> +#include 
> +
> +#ifdef CONFIG_EARLY_PRINTK
> +void early_printk(const char *str);
> +#else
> +static inline void early_printk(const char *s) {};
> +#endif
> +
> +#endif /* __EARLY_PRINTK_H__ */
> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> index 13e24e2fe1..9c9412152a 100644
> --- a/xen/arch/riscv/setup.c
> +++ b/xen/arch/riscv/setup.c
> @@ -1,13 +1,17 @@
>  

Re: [PATCH v4 2/4] xen/riscv: introduce sbi call to putchar to console

[Bobby Eshleman]

On Mon, Jan 16, 2023 at 04:39:30PM +0200, Oleksii Kurochko wrote:
> From: Bobby Eshleman 
> 
> Originally SBI implementation for Xen was introduced by
> Bobby Eshleman  but it was removed
> all the stuff for simplicity  except SBI call for putting
> character to console.
> 
> The patch introduces sbi_putchar() SBI call which is necessary
> to implement initial early_printk.
> 
> Signed-off-by: Bobby Eshleman 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V4:
> - Nothing changed
> ---
> Changes in V3:
> - update copyright's year
> - rename definition of __CPU_SBI_H__ to __ASM_RISCV_SBI_H__
> - fix identations
> - change an author of the commit
> ---
> Changes in V2:
> - add an explanatory comment about sbi_console_putchar() function.
> - order the files alphabetically in Makefile
> ---
>  xen/arch/riscv/Makefile  |  1 +
>  xen/arch/riscv/include/asm/sbi.h | 34 
>  xen/arch/riscv/sbi.c | 45 
>  3 files changed, 80 insertions(+)
>  create mode 100644 xen/arch/riscv/include/asm/sbi.h
>  create mode 100644 xen/arch/riscv/sbi.c
> 
> diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
> index 5a67a3f493..fd916e1004 100644
> --- a/xen/arch/riscv/Makefile
> +++ b/xen/arch/riscv/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_RISCV_64) += riscv64/
> +obj-y += sbi.o
>  obj-y += setup.o
>  
>  $(TARGET): $(TARGET)-syms
> diff --git a/xen/arch/riscv/include/asm/sbi.h 
> b/xen/arch/riscv/include/asm/sbi.h
> new file mode 100644
> index 00..0e6820a4ed
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/sbi.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: (GPL-2.0-or-later) */
> +/*
> + * Copyright (c) 2021-2023 Vates SAS.
> + *
> + * Taken from xvisor, modified by Bobby Eshleman (bobby.eshle...@gmail.com).
> + *
> + * Taken/modified from Xvisor project with the following copyright:
> + *
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + */
> +
> +#ifndef __ASM_RISCV_SBI_H__
> +#define __ASM_RISCV_SBI_H__
> +
> +#define SBI_EXT_0_1_CONSOLE_PUTCHAR  0x1
> +
> +struct sbiret {
> +long error;
> +long value;
> +};
> +
> +struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
> +unsigned long arg0, unsigned long arg1,
> +unsigned long arg2, unsigned long arg3,
> +unsigned long arg4, unsigned long arg5);
> +
> +/**
> + * Writes given character to the console device.
> + *
> + * @param ch The data to be written to the console.
> + */
> +void sbi_console_putchar(int ch);
> +
> +#endif /* __ASM_RISCV_SBI_H__ */
> diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c
> new file mode 100644
> index 00..dc0eb44bc6
> --- /dev/null
> +++ b/xen/arch/riscv/sbi.c
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Taken and modified from the xvisor project with the copyright Copyright 
> (c)
> + * 2019 Western Digital Corporation or its affiliates and author Anup Patel
> + * (anup.pa...@wdc.com).
> + *
> + * Modified by Bobby Eshleman (bobby.eshle...@gmail.com).
> + *
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + * Copyright (c) 2021-2023 Vates SAS.
> + */
> +
> +#include 
> +#include 
> +
> +struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
> +unsigned long arg0, unsigned long arg1,
> +unsigned long arg2, unsigned long arg3,
> +unsigned long arg4, unsigned long arg5)
> +{
> +struct sbiret ret;
> +
> +register unsigned long a0 asm ("a0") = arg0;
> +register unsigned long a1 asm ("a1") = arg1;
> +register unsigned long a2 asm ("a2") = arg2;
> +register unsigned long a3 asm ("a3") = arg3;
> +register unsigned long a4 asm ("a4") = arg4;
> +register unsigned long a5 asm ("a5") = arg5;
> +register unsigned long a6 asm ("a6") = fid;
> +register unsigned long a7 asm ("a7") = ext;
> +
> +asm volatile ("ecall"
> +  : "+r" (a0), "+r" (a1)
> +  : "r" (a2), "r" (a3), "r" (a4), "r" (a5), "r" (a6), "r" (a7)
> +  : "memory");
> +ret.error = a0;
> +ret.value = a1;
> +
> +return ret;
> +}
> +
> +void sbi_console_putchar(int ch)
> +{
> +sbi_ecall(SBI_EXT_0_1_CONSOLE_PUTCHAR, 0, ch, 0, 0, 0, 0, 0);
> +}
> -- 
> 2.39.0
> 
> 

Reviewed-by: Bobby Eshleman 

Re: [PATCH v2 03/40] xen/arm: adjust Xen TLB helpers for Armv8-R64 PMSA

[Julien Grall]

Hi,

On 13/01/2023 05:28, Penny Zheng wrote:

From: Wei Chen 

 From Arm ARM Supplement of Armv8-R AArch64 (DDI 0600A) [1],
section D1.6.2 TLB maintenance instructions, we know that
Armv8-R AArch64 permits an implementation to cache stage 1
VMSAv8-64 and stage 2 PMSAv8-64 attributes as a common entry
for the Secure EL1&0 translation regime. But for Xen itself,
it's running with stage 1 PMSAv8-64 on Armv8-R AArch64. The
EL2 MPU updates for stage 1 PMSAv8-64 will not be cached in
TLB entries. So we don't need any TLB invalidation for Xen
itself in EL2.


So I understand the theory here. But I would expect that none of the 
common code will call any of those helpers. Therefore the #ifdef should 
be unnecessary.


Can you clarify if my understanding is correct?

Cheers,

--
Julien Grall

Re: [PATCH v2 02/40] xen/arm: make ARM_EFI selectable for Arm64

[Julien Grall]

Hi Penny,

On 13/01/2023 05:28, Penny Zheng wrote:

From: Wei Chen 

Currently, ARM_EFI will mandatorily selected by Arm64.
Even if the user knows for sure that their images will not
start in the EFI environment, they can't disable the EFI
support for Arm64. This means there will be about 3K lines
unused code in their images.

So in this patch, we make ARM_EFI selectable for Arm64, and
based on that, we can use CONFIG_ARM_EFI to gate the EFI
specific code in head.S for those images that will not be
booted in EFI environment.

Signed-off-by: Wei Chen 


Your signed-off-by is missing.


---
v1 -> v2:
1. New patch
---
  xen/arch/arm/Kconfig  | 10 --
  xen/arch/arm/arm64/head.S | 15 +--
  2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 239d3aed3c..ace7178c9a 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -7,7 +7,6 @@ config ARM_64
def_bool y
depends on !ARM_32
select 64BIT
-   select ARM_EFI
select HAS_FAST_MULTIPLY
  
  config ARM

@@ -37,7 +36,14 @@ config ACPI
  an alternative to device tree on ARM64.
  
  config ARM_EFI

-   bool
+   bool "UEFI boot service support"
+   depends on ARM_64
+   default y
+   help
+ This option provides support for boot services through
+ UEFI firmware. A UEFI stub is provided to allow Xen to
+ be booted as an EFI application. This is only useful for
+ Xen that may run on systems that have UEFI firmware.


I would drop the last sentence as this is implied with the rest of the 
paragraph.


Cheers,

--
Julien Grall

Re: [PATCH v2 0/6] Resolve TYPE_PIIX3_XEN_DEVICE

[Bernhard Beschow]

Am 4. Januar 2023 14:44:31 UTC schrieb Bernhard Beschow :
>This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes
>
>it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC
>
>machine agnostic to the precise southbridge being used. 2/ will become
>
>particularily interesting once PIIX4 becomes usable in the PC machine, avoiding
>
>the "Frankenstein" use of PIIX4_ACPI in PIIX3.
>
>
>
>v2:
>
>- xen_piix3_set_irq() is already generic. Just rename it. (Chuck)
>
>
>
>Testing done:
>
>None, because I don't know how to conduct this properly :(

Ping

Successfully tested by Chuck. Patches 2, 4 and 6 still need review.

I can rebase to master if that eases review -- please let me know. Currently 
this series is based on my "Consolidate PIIX south bridges" series:

>Based-on: <20221221170003.2929-1-shen...@gmail.com>
>
>  "[PATCH v4 00/30] Consolidate PIIX south bridges"
>
>
>
>Bernhard Beschow (6):
>
>  include/hw/xen/xen: Rename xen_piix3_set_irq() to xen_intx_set_irq()
>
>  hw/isa/piix: Reuse piix3_realize() in piix3_xen_realize()
>
>  hw/isa/piix: Wire up Xen PCI IRQ handling outside of PIIX3
>
>  hw/isa/piix: Avoid Xen-specific variant of piix_write_config()
>
>  hw/isa/piix: Resolve redundant k->config_write assignments
>
>  hw/isa/piix: Resolve redundant TYPE_PIIX3_XEN_DEVICE
>
>
>
> hw/i386/pc_piix.c | 34 --
>
> hw/i386/xen/xen-hvm.c |  2 +-
>
> hw/isa/piix.c | 66 +--
>
> include/hw/southbridge/piix.h |  1 -
>
> include/hw/xen/xen.h  |  2 +-
>
> stubs/xen-hw-stub.c   |  2 +-
>
> 6 files changed, 35 insertions(+), 72 deletions(-)
>
>
>
>-- >
>2.39.0
>
>
>

Re: [PATCH RFC 07/10] domain: map/unmap GADDR based shared guest areas

[Julien Grall]

Hi Andrew,

On 17/01/2023 22:20, Andrew Cooper wrote:

On 24/11/2022 9:29 pm, Julien Grall wrote:

Hi Jan,

I am still digesting this series and replying with some initial comments.

On 19/10/2022 09:43, Jan Beulich wrote:

The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the areas are inaccessible (and hence cannot be updated by
Xen) when in guest-user mode.

In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the two is x86-specific) by
guest-physical address, flesh out the map/unmap functions.

Noteworthy differences from map_vcpu_info():
- areas can be registered more than once (and de-registered),
- remote vCPU-s are paused rather than checked for being down (which in
    principle can change right after the check),
- the domain lock is taken for a much smaller region.

Signed-off-by: Jan Beulich 
---
RFC: By using global domain page mappings the demand on the underlying
   VA range may increase significantly. I did consider to use per-
   domain mappings instead, but they exist for x86 only. Of course we
   could have arch_{,un}map_guest_area() aliasing global domain page
   mapping functions on Arm and using per-domain mappings on x86. Yet
   then again map_vcpu_info() doesn't do so either (albeit that's
   likely to be converted subsequently to use map_vcpu_area()
anyway).

RFC: In map_guest_area() I'm not checking the P2M type, instead - just
   like map_vcpu_info() - solely relying on the type ref acquisition.
   Checking for p2m_ram_rw alone would be wrong, as at least
   p2m_ram_logdirty ought to also be okay to use here (and in similar
   cases, e.g. in Argo's find_ring_mfn()). p2m_is_pageable() could be
   used here (like altp2m_vcpu_enable_ve() does) as well as in
   map_vcpu_info(), yet then again the P2M type is stale by the time
   it is being looked at anyway without the P2M lock held.

--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1563,7 +1563,82 @@ int map_guest_area(struct vcpu *v, paddr
  struct guest_area *area,
  void (*populate)(void *dst, struct vcpu *v))
   {
-    return -EOPNOTSUPP;
+    struct domain *currd = v->domain;
+    void *map = NULL;
+    struct page_info *pg = NULL;
+    int rc = 0;
+
+    if ( gaddr )


0 is technically a valid (guest) physical address on Arm.


It is on x86 too, but that's not why 0 is generally considered an
invalid address.

See the multitude of XSAs, and near-XSAs which have been caused by bad
logic in Xen caused by trying to make a variable held in struct
vcpu/domain have a default value other than 0.

It's not impossible to write such code safely, and in this case I expect
it can be done by the NULLness (or not) of the mapping pointer, rather
than by stashing the gaddr, but history has proved repeatedly that this
is a very fertile source of security bugs.


I understand the security concern. However... you are now imposing some 
constraint in the guest OS which may be more difficult to address.


Furthermore, we are trying to make a sane ABI. It doesn't look sane to 
me to expose our currently shortcomings to the guest OS. The more that 
if we decide it to relax in the future, then it would not help an OS 
because they will need to support older Xen...


Cheers,

--
Julien Grall

Re: [PATCH v3 17/17] tools/xenstore: make output of "xenstore-control help" more pretty

[Julien Grall]

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

Using a tab for separating the command from the options in the output
of "xenstore-control help" results in a rather ugly list.

Use a fixed size for the command instead.

Signed-off-by: Juergen Gross 


Rwviewed-by: Julien Grall 

Cheers,

--
Julien Grall

[ovmf test] 175950: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 ea382b3b21ef6664d5850dfbe08793f77d10c15d
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z5 days
Failing since175860  2023-01-15 07:11:07 Z2 days   38 attempts
Testing same since   175945  2023-01-17 19:40:40 Z0 days4 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Jiewen Yao 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 
  Oliver Steffen 

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 718 lines long.)

Re: [PATCH v3 16/17] tools/xenstore: let check_store() check the accounting data

[Julien Grall]

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

Today check_store() is only testing the correctness of the node tree.

Add verification of the accounting data (number of nodes)  and correct


NIT: one too many space before 'and'.


the data if it is wrong.

Do the initial check_store() call only after Xenstore entries of a
live update have been read.


Can you clarify whether this is needed for the rest of the patch, or 
simply a nice thing to have in general?




Signed-off-by: Juergen Gross 
---
  tools/xenstore/xenstored_core.c   | 62 --
  tools/xenstore/xenstored_domain.c | 86 +++
  tools/xenstore/xenstored_domain.h |  4 ++
  3 files changed, 137 insertions(+), 15 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 3099077a86..e201f14053 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -2389,8 +2389,6 @@ void setup_structure(bool live_update)
manual_node("@introduceDomain", NULL);
domain_nbentry_fix(dom0_domid, 5, true);
}
-
-   check_store();
  }
  
  static unsigned int hash_from_key_fn(void *k)

@@ -2433,20 +2431,28 @@ int remember_string(struct hashtable *hash, const char 
*str)
   * As we go, we record each node in the given reachable hashtable.  These
   * entries will be used later in clean_store.
   */
+
+struct check_store_data {
+   struct hashtable *reachable;
+   struct hashtable *domains;
+};
+
  static int check_store_step(const void *ctx, struct connection *conn,
struct node *node, void *arg)
  {
-   struct hashtable *reachable = arg;
+   struct check_store_data *data = arg;
  
-	if (hashtable_search(reachable, (void *)node->name)) {

+   if (hashtable_search(data->reachable, (void *)node->name)) {


IIUC the cast is only necessary because hashtable_search() expects a 
non-const value. I can't think for a reason for the key to be non-const. 
So I will look to send a follow-up patch.



+
+void domain_check_acc_add(const struct node *node, struct hashtable *domains)
+{
+   struct domain_acc *dom;
+   unsigned int domid;
+
+   domid = node->perms.p[0].id;


This could be replaced with get_node_owner().


+   dom = hashtable_search(domains, );
+   if (!dom)
+   log("Node %s owned by unknown domain %u", node->name, domid);
+   else
+   dom->nodes++;
+}
+
+static int domain_check_acc_sub(const void *k, void *v, void *arg)


I find the suffix 'sub' misleading because we have a function with a 
very similar name (instead suffixed 'sub'). Yet, AFAICT, it is not meant 
to substract.


So I would prefix with '_cb' instead.

Cheers,

--
Julien Grall

Re: [PATCH RFC 07/10] domain: map/unmap GADDR based shared guest areas

[Andrew Cooper]

On 24/11/2022 9:29 pm, Julien Grall wrote:
> Hi Jan,
>
> I am still digesting this series and replying with some initial comments.
>
> On 19/10/2022 09:43, Jan Beulich wrote:
>> The registration by virtual/linear address has downsides: At least on
>> x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
>> PV domains the areas are inaccessible (and hence cannot be updated by
>> Xen) when in guest-user mode.
>>
>> In preparation of the introduction of new vCPU operations allowing to
>> register the respective areas (one of the two is x86-specific) by
>> guest-physical address, flesh out the map/unmap functions.
>>
>> Noteworthy differences from map_vcpu_info():
>> - areas can be registered more than once (and de-registered),
>> - remote vCPU-s are paused rather than checked for being down (which in
>>    principle can change right after the check),
>> - the domain lock is taken for a much smaller region.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> RFC: By using global domain page mappings the demand on the underlying
>>   VA range may increase significantly. I did consider to use per-
>>   domain mappings instead, but they exist for x86 only. Of course we
>>   could have arch_{,un}map_guest_area() aliasing global domain page
>>   mapping functions on Arm and using per-domain mappings on x86. Yet
>>   then again map_vcpu_info() doesn't do so either (albeit that's
>>   likely to be converted subsequently to use map_vcpu_area()
>> anyway).
>>
>> RFC: In map_guest_area() I'm not checking the P2M type, instead - just
>>   like map_vcpu_info() - solely relying on the type ref acquisition.
>>   Checking for p2m_ram_rw alone would be wrong, as at least
>>   p2m_ram_logdirty ought to also be okay to use here (and in similar
>>   cases, e.g. in Argo's find_ring_mfn()). p2m_is_pageable() could be
>>   used here (like altp2m_vcpu_enable_ve() does) as well as in
>>   map_vcpu_info(), yet then again the P2M type is stale by the time
>>   it is being looked at anyway without the P2M lock held.
>>
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1563,7 +1563,82 @@ int map_guest_area(struct vcpu *v, paddr
>>  struct guest_area *area,
>>  void (*populate)(void *dst, struct vcpu *v))
>>   {
>> -    return -EOPNOTSUPP;
>> +    struct domain *currd = v->domain;
>> +    void *map = NULL;
>> +    struct page_info *pg = NULL;
>> +    int rc = 0;
>> +
>> +    if ( gaddr )
>
> 0 is technically a valid (guest) physical address on Arm.

It is on x86 too, but that's not why 0 is generally considered an
invalid address.

See the multitude of XSAs, and near-XSAs which have been caused by bad
logic in Xen caused by trying to make a variable held in struct
vcpu/domain have a default value other than 0.

It's not impossible to write such code safely, and in this case I expect
it can be done by the NULLness (or not) of the mapping pointer, rather
than by stashing the gaddr, but history has proved repeatedly that this
is a very fertile source of security bugs.

~Andrew

Re: [PATCH v3 15/17] tools/xenstore: introduce trace classes

[Julien Grall]

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

@@ -2604,6 +2607,8 @@ static void usage(void)
  "  -N, --no-fork   to request that the daemon does not fork,\n"
  "  -P, --output-pidto request that the pid of the daemon is output,\n"
  "  -T, --trace-file  giving the file for logging, and\n"
+"  --trace-control=+ activate a specific \n"
+"  --trace-control=- deactivate a specific \n"
  "  -E, --entry-nb  limit the number of entries per domain,\n"
  "  -S, --entry-size  limit the size of entry per domain, and\n"
  "  -W, --watch-nb  limit the number of watches per domain,\n"
@@ -2647,6 +2652,7 @@ static struct option options[] = {
{ "output-pid", 0, NULL, 'P' },
{ "entry-size", 1, NULL, 'S' },
{ "trace-file", 1, NULL, 'T' },
+   { "trace-control", 1, NULL, 1 },
{ "transaction", 1, NULL, 't' },
{ "perm-nb", 1, NULL, 'A' },
{ "path-max", 1, NULL, 'M' },
@@ -2721,6 +2727,43 @@ static void set_quota(const char *arg, bool soft)
barf("unknown quota \"%s\"\n", arg);
  }
  
+/* Sorted by bit values of TRACE_* flags. Flag is (1u << index). */

+const char *trace_switches[] = {


AFAICT, this array is not meant to be modified. So you want a second const.


+   "obj", "io", "wrl",
+   NULL
+};


[...]


diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index 3b96ecd018..c85b15515c 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -287,6 +287,12 @@ extern char **orig_argv;
  
  extern char *tracefile;

  extern int tracefd;
+extern unsigned int trace_flags;
+#define TRACE_OBJ  0x0001
+#define TRACE_IO   0x0002
+#define TRACE_WRL  0x0004
I would add a comment on top to explain that the value should be kept in 
sync with trace_switches.


Cheers,

--
Julien Grall

Re: [PATCH RFC 07/10] domain: map/unmap GADDR based shared guest areas

[Andrew Cooper]

On 19/10/2022 8:43 am, Jan Beulich wrote:
> The registration by virtual/linear address has downsides: At least on
> x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
> PV domains the areas are inaccessible (and hence cannot be updated by
> Xen) when in guest-user mode.

They're also inaccessible in HVM guests (x86 and ARM) when Meltdown
mitigations are in place.

And lets not get started on the multitude of layering violations that is
guest_memory_policy() for nested virt.  In fact, prohibiting any form of
map-by-va is a perquisite to any rational attempt to make nested virt work.

(In fact, that infrastructure needs purging before any other
architecture pick up stubs too.)

They're also inaccessible in general because no architecture has
hypervisor privilege in a normal user/supervisor split, and you don't
know whether the mapping is over supervisor or user mapping, and
settings like SMAP/PAN can cause the pagewalk to fail even when the
mapping is in place.


There are a lot of good reasons why map-by-va should never have happened.

Even for PV guests, map-by-gfn (and let the guest manage whatever
virtual mappings it wants on its own) would have been closer to the
status quo for how real hardware worked, and critically would have
avoided the restriction that the areas had to live at a globally fixed
position to be useful.





>
> In preparation of the introduction of new vCPU operations allowing to
> register the respective areas (one of the two is x86-specific) by
> guest-physical address, flesh out the map/unmap functions.
>
> Noteworthy differences from map_vcpu_info():
> - areas can be registered more than once (and de-registered),

When register by GFN is available, there is never a good reason to the
same area twice.

The guest maps one MMIO-like region, and then constructs all the regular
virtual addresses mapping it (or not) that it wants.

This API is new, so we can enforce sane behaviour from the outset.  In
particular, it will help with ...

> - remote vCPU-s are paused rather than checked for being down (which in
>   principle can change right after the check),
> - the domain lock is taken for a much smaller region.
>
> Signed-off-by: Jan Beulich 
> ---
> RFC: By using global domain page mappings the demand on the underlying
>  VA range may increase significantly. I did consider to use per-
>  domain mappings instead, but they exist for x86 only. Of course we
>  could have arch_{,un}map_guest_area() aliasing global domain page
>  mapping functions on Arm and using per-domain mappings on x86. Yet
>  then again map_vcpu_info() doesn't do so either (albeit that's
>  likely to be converted subsequently to use map_vcpu_area() anyway).

... this by providing a bound on the amount of vmap() space can be consumed.

>
> RFC: In map_guest_area() I'm not checking the P2M type, instead - just
>  like map_vcpu_info() - solely relying on the type ref acquisition.
>  Checking for p2m_ram_rw alone would be wrong, as at least
>  p2m_ram_logdirty ought to also be okay to use here (and in similar
>  cases, e.g. in Argo's find_ring_mfn()). p2m_is_pageable() could be
>  used here (like altp2m_vcpu_enable_ve() does) as well as in
>  map_vcpu_info(), yet then again the P2M type is stale by the time
>  it is being looked at anyway without the P2M lock held.

Again, another error caused by Xen not knowing the guest physical
address layout.  These mappings should be restricted to just RAM regions
and I think we want to enforce that right from the outset.

~Andrew

Re: [PATCH v3 12/17] tools/xenstore: don't let hashtable_remove() return the removed value

[Julien Grall]

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

Letting hashtable_remove() return the value of the removed element is
not used anywhere in Xenstore, and it conflicts with a hashtable
created specifying the HASHTABLE_FREE_VALUE flag.

So just drop returning the value.


Any reason this can't be void? If there are, then I would consider to 
return a bool as the return can only be 2 values.




Signed-off-by: Juergen Gross 
---
V3:
- new patch
---
  tools/xenstore/hashtable.c | 10 +-
  tools/xenstore/hashtable.h |  4 ++--
  2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/hashtable.c b/tools/xenstore/hashtable.c
index 299549c51e..6738719e47 100644
--- a/tools/xenstore/hashtable.c
+++ b/tools/xenstore/hashtable.c
@@ -214,7 +214,7 @@ hashtable_search(struct hashtable *h, void *k)
  }
  
  /*/

-void * /* returns value associated with key */
+int
  hashtable_remove(struct hashtable *h, void *k)
  {
  /* TODO: consider compacting the table when the load factor drops enough,
@@ -222,7 +222,6 @@ hashtable_remove(struct hashtable *h, void *k)
  
  struct entry *e;

  struct entry **pE;
-void *v;
  unsigned int hashvalue, index;
  
  hashvalue = hash(h,k);

@@ -236,16 +235,17 @@ hashtable_remove(struct hashtable *h, void *k)
  {
  *pE = e->next;
  h->entrycount--;
-v = e->v;
  if (h->flags & HASHTABLE_FREE_KEY)
  free(e->k);
+if (h->flags & HASHTABLE_FREE_VALUE)
+free(e->v);


I don't quite understand how this change is related to this patch.


  free(e);
-return v;
+return 1;
  }
  pE = &(e->next);
  e = e->next;
  }
-return NULL;
+return 0;
  }
  
  /*/

diff --git a/tools/xenstore/hashtable.h b/tools/xenstore/hashtable.h
index 6d65431f96..d6feb1b038 100644
--- a/tools/xenstore/hashtable.h
+++ b/tools/xenstore/hashtable.h
@@ -68,10 +68,10 @@ hashtable_search(struct hashtable *h, void *k);
   * @namehashtable_remove
   * @param   h   the hashtable to remove the item from
   * @param   k   the key to search for  - does not claim ownership
- * @return  the value associated with the key, or NULL if none found
+ * @return  0 if element not found
   */
  
-void * /* returns value */

+int
  hashtable_remove(struct hashtable *h, void *k);
  
  /*


Cheers,

--
Julien Grall

[ovmf test] 175947: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 ea382b3b21ef6664d5850dfbe08793f77d10c15d
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z5 days
Failing since175860  2023-01-15 07:11:07 Z2 days   37 attempts
Testing same since   175945  2023-01-17 19:40:40 Z0 days3 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Jiewen Yao 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 
  Oliver Steffen 

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 718 lines long.)

[xen-unstable-smoke test] 175944: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 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  f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
baseline version:
 xen  6bec713f871f21c6254a5783c1e39867ea828256

Last test of basis   175746  2023-01-12 16:03:41 Z5 days
Failing since175748  2023-01-12 20:01:56 Z5 days   23 attempts
Testing same since   175833  2023-01-14 07:00:25 Z3 days   21 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 
  Michal Orzel 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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.


commit f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
Author: Michal Orzel 
Date:   Tue Jan 3 11:25:19 2023 +0100

xen/arm: Add 0x prefix when printing memory size in construct_domU

Printing memory size in hex without 0x prefix can be misleading, so
add it. Also, take the opportunity to adhere to 80 chars line length
limit by moving the printk arguments to the next line.

Signed-off-by: Michal Orzel 
Reviewed-by: Ayan Kumar Halder 
Acked-by: Julien Grall 

commit 229ebd517b9df0e2d2f9e3ea50b57ca716334826
Author: Julien Grall 
Date:   Thu Jan 12 22:07:42 2023 +

xen/arm: linker: The identitymap check should cover the whole .text.header

At the moment, we are only checking that only some part of .text.header
is part of the identity mapping. However, this doesn't take into account
the literal pool which will be located at the end of the section.

While we could try to avoid using a literal pool, in the near future we
will also want to use an identity mapping for switch_ttbr().

Not everything in .text.header requires to be part of the identity
mapping. But it is below a page size (i.e. 4KB) so take a shortcut and
check that .text.header is smaller than a page size.

With that _end_boot can be removed as it is now unused. Take the
opportunity to avoid assuming that a page size is always 4KB in the
error message and comment.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit 22a9981ba2443bd569bad6b772fb6e7e64f0d714
Author: Julien Grall 
Date:   Thu Jan 12 22:06:42 2023 +

xen/arm: linker: Indent correctly _stext

_stext is indented by one space more compare to the lines. This doesn't
seem warrant, so delete the extra space.

Signed-off: Julien Grall 
Acked-by: Stefano Stabellini 

commit 3edca52ce736297d7fcf293860cd94ef62638052
Author: Andrew Cooper 
Date:   Mon Jan 9 10:58:31 2023 +

x86/vmx: Support for CPUs without model-specific LBR

Ice Lake (server at least) has both architectural LBR and model-specific 
LBR.
Sapphire Rapids does not have model-specific LBR at all.  I.e. On SPR and
later, model_specific_lbr will always be NULL, so we must make changes to
avoid reliably hitting the domain_crash().
 

Re: [PATCH RFC 03/10] domain: GADDR based shared guest area registration alternative - teardown

[Andrew Cooper]

On 19/10/2022 8:40 am, Jan Beulich wrote:
> In preparation of the introduction of new vCPU operations allowing to
> register the respective areas (one of the two is x86-specific) by
> guest-physical address, add the necessary domain cleanup hooks.

What are the two areas you're discussing here?

I assume you mean VCPUOP_register_vcpu_time_memory_area to be the
x86-specific op, but ARM permits both  VCPUOP_register_vcpu_info and
VCPUOP_register_runstate_memory_area.

So isn't it more 2+1 rather than 1+1?

>
> Signed-off-by: Jan Beulich 
> ---
> RFC: Zapping the areas in pv_shim_shutdown() may not be strictly
>  necessary: Aiui unmap_vcpu_info() is called only because the vCPU
>  info area cannot be re-registered. Beyond that I guess the
>  assumption is that the areas would only be re-registered as they
>  were before. If that's not the case I wonder whether the guest
>  handles for both areas shouldn't also be zapped.

At this point in pv_shim_shutdown(), have already come out of suspend
(successfully) and are preparing to poke the PV guest out of suspend too.

The PV guest needs to not have its subsequent VCPUOP_register_vcpu_info
call fail, but beyond that I can entirely believe that it was coded to
"Linux doesn't crash" rather than "what's everything we ought to reset
here" - recall that we weren't exactly flush with time when trying to
push Shim out of the door.

Whatever does get reregstered will be reregistered at the same
position.  No guest at all is going to have details like that dynamic
across migrate.


As a tangential observation, i see the periodic timer gets rearmed. 
This is still one of the more insane default properties of a PV guest;
Linux intentionally clobbers it on boot, but I can equivalent logic to
re-clobber after resume.

~Andrew

[xen-unstable test] 175931: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-i386   broken
 build-i386-xsm   broken
 build-amd64-xsm   5 host-build-prep  fail REGR. vs. 175734
 build-i386-xsm5 host-build-prep  fail REGR. vs. 175734
 build-amd64-prev  6 xen-buildfail REGR. vs. 175734
 build-i386-prev   6 xen-buildfail REGR. vs. 175734
 build-arm64   6 xen-buildfail REGR. vs. 175734
 build-amd64   6 xen-buildfail REGR. vs. 175734
 build-i3865 host-build-prep  fail REGR. vs. 175734

Tests which did not succeed, but are not blocking:
 test-amd64-i386-examine-bios  1 build-check(1)   blocked  n/a
 test-amd64-i386-examine-uefi  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  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-amd64-i386-livepatch 1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 

[ovmf test] 175946: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 ea382b3b21ef6664d5850dfbe08793f77d10c15d
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z5 days
Failing since175860  2023-01-15 07:11:07 Z2 days   36 attempts
Testing same since   175945  2023-01-17 19:40:40 Z0 days2 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Jiewen Yao 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 
  Oliver Steffen 

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 718 lines long.)

Re: [PATCH RFC 05/10] x86: update GADDR based secondary time area

[Andrew Cooper]

On 19/10/2022 8:41 am, Jan Beulich wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1462,12 +1462,34 @@ static void __update_vcpu_system_time(st
>  v->arch.pv.pending_system_time = _u;
>  }
>  
> +static void write_time_guest_area(struct vcpu_time_info *map,
> +  const struct vcpu_time_info *src)
> +{
> +/* 1. Update userspace version. */
> +write_atomic(>version, src->version);

version_update_begin()

~Andrew

> +smp_wmb();
> +
> +/* 2. Update all other userspace fields. */
> +*map = *src;
> +
> +/* 3. Update userspace version again. */
> +smp_wmb();
> +write_atomic(>version, version_update_end(src->version));
> +}
> +
>  bool update_secondary_system_time(struct vcpu *v,
>struct vcpu_time_info *u)
>  {
>  XEN_GUEST_HANDLE(vcpu_time_info_t) user_u = v->arch.time_info_guest;
> +struct vcpu_time_info *map = v->arch.time_guest_area.map;
>  struct guest_memory_policy policy = { .nested_guest_mode = false };
>  
> +if ( map )
> +{
> +write_time_guest_area(map, u);
> +return true;
> +}
> +
>  if ( guest_handle_is_null(user_u) )
>  return true;
>  
>

[ovmf test] 175945: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 ea382b3b21ef6664d5850dfbe08793f77d10c15d
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z5 days
Failing since175860  2023-01-15 07:11:07 Z2 days   35 attempts
Testing same since   175945  2023-01-17 19:40:40 Z0 days1 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Jiewen Yao 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 
  Oliver Steffen 

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 718 lines long.)

Re: [PATCH 02/10] x86: split populating of struct vcpu_time_info into a separate function

[Andrew Cooper]

On 19/10/2022 8:39 am, Jan Beulich wrote:
> This is to facilitate subsequent re-use of this code.
>
> While doing so add const in a number of places, extending to
> gtime_to_gtsc() and then for symmetry also its inverse function.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

> ---
> I was on the edge of also folding the various is_hvm_domain() into a
> function scope boolean, but then wasn't really certain that this
> wouldn't open up undue speculation opportunities.

I can't see anything interesting under here speculation wise. 
Commentary inline.

>
> --- a/xen/arch/x86/include/asm/time.h
> +++ b/xen/arch/x86/include/asm/time.h
> @@ -52,8 +52,8 @@ uint64_t cf_check acpi_pm_tick_to_ns(uin
>  uint64_t tsc_ticks2ns(uint64_t ticks);
>  
>  uint64_t pv_soft_rdtsc(const struct vcpu *v, const struct cpu_user_regs 
> *regs);
> -u64 gtime_to_gtsc(struct domain *d, u64 time);
> -u64 gtsc_to_gtime(struct domain *d, u64 tsc);
> +uint64_t gtime_to_gtsc(const struct domain *d, uint64_t time);
> +uint64_t gtsc_to_gtime(const struct domain *d, uint64_t tsc);
>  
>  int tsc_set_info(struct domain *d, uint32_t tsc_mode, uint64_t elapsed_nsec,
>   uint32_t gtsc_khz, uint32_t incarnation);
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1373,18 +1373,14 @@ uint64_t tsc_ticks2ns(uint64_t ticks)
>  return scale_delta(ticks, >tsc_scale);
>  }
>  
> -static void __update_vcpu_system_time(struct vcpu *v, int force)
> +static void collect_time_info(const struct vcpu *v,
> +  struct vcpu_time_info *u)
>  {
> -const struct cpu_time *t;
> -struct vcpu_time_info *u, _u = {};
> -struct domain *d = v->domain;
> +const struct cpu_time *t = _cpu(cpu_time);
> +const struct domain *d = v->domain;
>  s_time_t tsc_stamp;
>  
> -if ( v->vcpu_info == NULL )
> -return;
> -
> -t = _cpu(cpu_time);
> -u = _info(v, time);
> +memset(u, 0, sizeof(*u));
>  
>  if ( d->arch.vtsc )
>  {
> @@ -1392,7 +1388,7 @@ static void __update_vcpu_system_time(st
>  
>  if ( is_hvm_domain(d) )
>  {
> -struct pl_time *pl = v->domain->arch.hvm.pl_time;
> +const struct pl_time *pl = d->arch.hvm.pl_time;

A PV guest could in in principle use...

>  
>  stime += pl->stime_offset + v->arch.hvm.stime_offset;

... this pl->stime_offset as the second deference of a whatever happens
to sit under d->arch.hvm.pl_time in the pv union.

In the current build of Xen I have to hand, that's
d->arch.pv.mapcache.{epoch,tlbflush_timestamp}, the combination of which
doesn't seem like it can be steered into being a legal pointer into Xen.

>  if ( stime >= 0 )
> @@ -1403,27 +1399,27 @@ static void __update_vcpu_system_time(st
>  else
>  tsc_stamp = gtime_to_gtsc(d, stime);
>  
> -_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
> -_u.tsc_shift = d->arch.vtsc_to_ns.shift;
> +u->tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
> +u->tsc_shift = d->arch.vtsc_to_ns.shift;
>  }
>  else
>  {
>  if ( is_hvm_domain(d) && hvm_tsc_scaling_supported )

On the other hand, this is isn't safe.  There's no protection of the &&
calculation, but...

>  {
>  tsc_stamp= hvm_scale_tsc(d, t->stamp.local_tsc);

... this path is the only path subject to speculative type confusion,
and all it does is read d->arch.hvm.tsc_scaling_ratio, so is
appropriately protected in this instance.

Also, all an attacker could do is encode the scaling ratio alongside
t->stamp.local_tsc (unpredictable) in the calculation for the duration
of the speculative window, with no way I can see to dereference the result.


> -_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
> -_u.tsc_shift = d->arch.vtsc_to_ns.shift;
> +u->tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
> +u->tsc_shift = d->arch.vtsc_to_ns.shift;
>  }
>  else
>  {
>  tsc_stamp= t->stamp.local_tsc;
> -_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
> -_u.tsc_shift = t->tsc_scale.shift;
> +u->tsc_to_system_mul = t->tsc_scale.mul_frac;
> +u->tsc_shift = t->tsc_scale.shift;
>  }
>  }
>  
> -_u.tsc_timestamp = tsc_stamp;
> -_u.system_time   = t->stamp.local_stime;
> +u->tsc_timestamp = tsc_stamp;
> +u->system_time   = t->stamp.local_stime;
>  
>  /*
>   * It's expected that domains cope with this bit changing on every
> @@ -1431,10 +1427,21 @@ static void __update_vcpu_system_time(st
>   * or if it further requires monotonicity checks with other vcpus.
>   */
>  if ( clocksource_is_tsc() )
> -_u.flags |= XEN_PVCLOCK_TSC_STABLE_BIT;
> +u->flags |= XEN_PVCLOCK_TSC_STABLE_BIT;
>  
>  if ( is_hvm_domain(d) )
> -

[ovmf test] 175943: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 015a001b03db14f791476f817b8b125b195b6d10
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z5 days
Failing since175860  2023-01-15 07:11:07 Z2 days   34 attempts
Testing same since   175940  2023-01-17 16:40:41 Z0 days4 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 

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 424 lines long.)

Re: [XEN PATCH] Create a Kconfig option to set preferred reboot method

[Per Bilse]

On 17/01/2023 15:55, Jan Beulich wrote:
> On 16.01.2023 18:21, Per Bilse wrote:
>> +config REBOOT_SYSTEM_DEFAULT
>> +default y
>> +bool "Xen-defined reboot method"
> 
> May I ask that you swap the two lines? (Personally I consider kconfig
> too forgiving here - it doesn't make a lot of sense to set a default
> when the type isn't known yet.)

Certainly, I spotted it myself after sending, and was kicking myself
for not seeing it earlier.

>> +choice
>> +bool "Choose reboot method"
>> +depends on !REBOOT_SYSTEM_DEFAULT
>> +default REBOOT_METHOD_ACPI
>> +help
>> +This is a compiled-in alternative to specifying the
>> +reboot method on the Xen command line.  Specifying a
>> +method on the command line will override this choice.
>> +
>> +warmDon't set the cold reboot flag
>> +coldSet the cold reboot flag
> 
> These two are modifiers, not reboot methods on their own. They set a
> field in the BDA to tell the BIOS how much initialization / checking
> to do (in the legacy case). Therefore they shouldn't be selectable
> right here. If you feel like it you could add another boolean to
> control that default.

My understanding is that it was desired to provide a compiled-in
equivalent of the command line 'reboot=' option (which includes
cold and warm), but this may be a misunderstanding.  I can separate
these two out.

>> +config REBOOT_METHOD_WARM
>> +bool "warm"
>> +help
>> +Don't set the cold reboot flag.
> 
> I don't think help text is very useful in sub-items of a choice. Plus
> you also explain each item above.

I thought it better to err on the side of caution.  The help texts will
appear at two different menu levels, but I can remove it.

>> +config REBOOT_METHOD_XEN
>> +bool "xen"
>> +help
>> +Use Xen SCHEDOP hypercall (if running under Xen as a 
>> guest).
> 
> This wants to depend on XEN_GUEST, doesn't it?

Yes, depending on context.  In providing a compiled-in equivalent
of the command-line parameter, it should arguably provide and accept
the same set of options, but I'll change it.

>> +default "x" if REBOOT_METHOD_XEN
> 
> I think it would be neater (and more forward compatible) if the strings
> were actually spelled out here. We may, at any time, make set_reboot_type()
> look at more than just the first character.

OK.

>> +#ifdef CONFIG_REBOOT_SYSTEM_DEFAULT
>>   default_reboot_type();
>>   dmi_check_system(reboot_dmi_table);
>> +#else
>> +set_reboot_type(CONFIG_REBOOT_METHOD);
>> +#endif
> 
> I don't think you should eliminate the use of DMI - that's machine
> specific information which should imo still overrule a build-time default.
> See also the comment just out of context - it's a difference whether the
> override came from the command line or was set at build time.

OK; again, it's a slightly different take on the purpose than I had, but
I can change it.  Also for the rest.

Best,

   -- Per

Re: [PATCH v2 9/9] x86/shadow: harden shadow_size()

[Andrew Cooper]

On 12/01/2023 10:42 am, Jan Beulich wrote:
> On 12.01.2023 11:31, Andrew Cooper wrote:
>> On 12/01/2023 9:47 am, Jan Beulich wrote:
>>> On 12.01.2023 00:15, Andrew Cooper wrote:
 On 11/01/2023 1:57 pm, Jan Beulich wrote:
> Make HVM=y release build behavior prone against array overrun, by
> (ab)using array_access_nospec(). This is in particular to guard against
> e.g. SH_type_unused making it here unintentionally.
>
> Signed-off-by: Jan Beulich 
> ---
> v2: New.
>
> --- a/xen/arch/x86/mm/shadow/private.h
> +++ b/xen/arch/x86/mm/shadow/private.h
> @@ -27,6 +27,7 @@
>  // been included...
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -368,7 +369,7 @@ shadow_size(unsigned int shadow_type)
>  {
>  #ifdef CONFIG_HVM
>  ASSERT(shadow_type < ARRAY_SIZE(sh_type_to_size));
> -return sh_type_to_size[shadow_type];
> +return array_access_nospec(sh_type_to_size, shadow_type);
 I don't think this is warranted.

 First, if the commit message were accurate, then it's a problem for all
 arrays of size SH_type_unused, yet you've only adjusted a single instance.
>>> Because I think the risk is higher here than for other arrays. In
>>> other cases we have suitable build-time checks (HASH_CALLBACKS_CHECK()
>>> in particular) which would trip upon inappropriate use of one of the
>>> types which are aliased to SH_type_unused when !HVM.
>>>
 Secondly, if it were reliably 16 then we could do the basically-free
 "type &= 15;" modification.  (It appears my change to do this
 automatically hasn't been taken yet.), but we'll end up with lfence
 variation here.
>>> How could anything be "reliably 16"? Such enums can change at any time:
>>> They did when making HVM types conditional, and they will again when
>>> adding types needed for 5-level paging.
>>>
 But the value isn't attacker controlled.  shadow_type always comes from
 Xen's metadata about the guest, not the guest itself.  So I don't see
 how this can conceivably be a speculative issue even in principle.
>>> I didn't say anything about there being a speculative issue here. It
>>> is for this very reason that I wrote "(ab)using".
>> Then it is entirely wrong to be using a nospec accessor.
>>
>> Speculation problems are subtle enough, without false uses of the safety
>> helpers.
>>
>> If you want to "harden" against runtime architectural errors, you want
>> to up the ASSERT() to a BUG(), which will execute faster than sticking
>> an hiding an lfence in here, and not hide what is obviously a major
>> malfunction in the shadow pagetable logic.
> I should have commented on this earlier already: What lfence are you
> talking about?

The one I thought was hiding under array_access_nospec(), but I forgot
we'd done the sbb trick.

> As to BUG() - the goal here specifically is to avoid a
> crash in release builds, by forcing the function to return zero (via
> having it use array slot zero for out of range indexes).

I'm very uneasy about having something this deep inside a component,
which ASSERT()s correctness doing something custom like this "just to
avoid crashing".

There is either something important which makes this more likely than
most to go wrong at runtime, or there is not.  And honestly, I can't see
why it is more risky at runtime.

If we really do need to clamp it, then we need a brand new helper with a
name that doesn't reference speculation at all.  It's fine for *_nospec
to reuse this helper, stating the safety of doing so, but at a code
level there need to be two appropriately named helpers for their two
logically-unrelated purposes.

~Andrew

Re: [PATCH v2 5/9] x86/shadow: L2H shadow type is PV32-only

[Andrew Cooper]

On 11/01/2023 1:54 pm, Jan Beulich wrote:
> Like for the various HVM-only types, save a little bit of code by suitably
> "masking" this type out when !PV32.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

[xen-unstable-smoke test] 175936: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 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  f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
baseline version:
 xen  6bec713f871f21c6254a5783c1e39867ea828256

Last test of basis   175746  2023-01-12 16:03:41 Z5 days
Failing since175748  2023-01-12 20:01:56 Z4 days   22 attempts
Testing same since   175833  2023-01-14 07:00:25 Z3 days   20 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 
  Michal Orzel 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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.


commit f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
Author: Michal Orzel 
Date:   Tue Jan 3 11:25:19 2023 +0100

xen/arm: Add 0x prefix when printing memory size in construct_domU

Printing memory size in hex without 0x prefix can be misleading, so
add it. Also, take the opportunity to adhere to 80 chars line length
limit by moving the printk arguments to the next line.

Signed-off-by: Michal Orzel 
Reviewed-by: Ayan Kumar Halder 
Acked-by: Julien Grall 

commit 229ebd517b9df0e2d2f9e3ea50b57ca716334826
Author: Julien Grall 
Date:   Thu Jan 12 22:07:42 2023 +

xen/arm: linker: The identitymap check should cover the whole .text.header

At the moment, we are only checking that only some part of .text.header
is part of the identity mapping. However, this doesn't take into account
the literal pool which will be located at the end of the section.

While we could try to avoid using a literal pool, in the near future we
will also want to use an identity mapping for switch_ttbr().

Not everything in .text.header requires to be part of the identity
mapping. But it is below a page size (i.e. 4KB) so take a shortcut and
check that .text.header is smaller than a page size.

With that _end_boot can be removed as it is now unused. Take the
opportunity to avoid assuming that a page size is always 4KB in the
error message and comment.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit 22a9981ba2443bd569bad6b772fb6e7e64f0d714
Author: Julien Grall 
Date:   Thu Jan 12 22:06:42 2023 +

xen/arm: linker: Indent correctly _stext

_stext is indented by one space more compare to the lines. This doesn't
seem warrant, so delete the extra space.

Signed-off: Julien Grall 
Acked-by: Stefano Stabellini 

commit 3edca52ce736297d7fcf293860cd94ef62638052
Author: Andrew Cooper 
Date:   Mon Jan 9 10:58:31 2023 +

x86/vmx: Support for CPUs without model-specific LBR

Ice Lake (server at least) has both architectural LBR and model-specific 
LBR.
Sapphire Rapids does not have model-specific LBR at all.  I.e. On SPR and
later, model_specific_lbr will always be NULL, so we must make changes to
avoid reliably hitting the domain_crash().
 

Re: [PATCH v2 6/9] x86/shadow: re-work 4-level SHADOW_FOREACH_L2E()

[Andrew Cooper]

On 11/01/2023 1:54 pm, Jan Beulich wrote:
> First of all move the almost loop-invariant condition out of the loop;
> transform it into an altered loop boundary. Since the new local variable
> wants to be "unsigned int" and named without violating name space rules,
> convert the loop induction variable accordingly.

I'm firmly -1 against using trailing underscores.

Mainly, I object to the attempt to justify doing so based on a rule we
explicitly choose to violate for code consistency and legibility reasons.

But in this case, you're taking a block of logic which was cleanly in
one style, and making it mixed, even amongst only the local variables.

> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -863,23 +863,20 @@ do {
>  /* 64-bit l2: touch all entries except for PAE compat guests. */
>  #define SHADOW_FOREACH_L2E(_sl2mfn, _sl2e, _gl2p, _done, _dom, _code)   \
>  do {\
> -int _i; \
> -int _xen = !shadow_mode_external(_dom); \
> +unsigned int i_, end_ = SHADOW_L2_PAGETABLE_ENTRIES;\
>  shadow_l2e_t *_sp = map_domain_page((_sl2mfn)); \
>  ASSERT_VALID_L2(mfn_to_page(_sl2mfn)->u.sh.type);   \
> -for ( _i = 0; _i < SHADOW_L2_PAGETABLE_ENTRIES; _i++ )  \
> +if ( !shadow_mode_external(_dom) && \
> + is_pv_32bit_domain(_dom) &&\

The second clause here implies the first.  Given that all we're trying
to say here is "are there Xen entries to skip", I think we'd be fine
dropping the external() check entirely.

> + mfn_to_page(_sl2mfn)->u.sh.type != SH_type_l2_64_shadow )  \
> +end_ = COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(_dom);\
> +for ( i_ = 0; i_ < end_; ++i_ ) \
>  {   \
> -if ( (!(_xen))  \
> - || !is_pv_32bit_domain(_dom)   \
> - || mfn_to_page(_sl2mfn)->u.sh.type == SH_type_l2_64_shadow \
> - || (_i < COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(_dom)) )   \
> -{   \
> -(_sl2e) = _sp + _i; \
> -if ( shadow_l2e_get_flags(*(_sl2e)) & _PAGE_PRESENT )   \
> -{_code} \
> -if ( _done ) break; \
> -increment_ptr_to_guest_entry(_gl2p);\
> -}   \
> +(_sl2e) = _sp + i_; \
> +if ( shadow_l2e_get_flags(*(_sl2e)) & _PAGE_PRESENT )   \
> +{ _code }   \

This doesn't match either of our two styles. 

if ( ... )
{ _code }

would be closer to Xen's normal style, but  ...

> +if ( _done ) break; \

... with this too, I think it would still be better to write it out
fully, so:

if ( ... )
{
    _code
}
if ( _done )
    break;

These macros are already big enough that trying to save 3 lines seems
futile.

~Andrew

> +increment_ptr_to_guest_entry(_gl2p);\

P.S. I'm pretty sure I had encountered this before, but I'm re-reminded
of how much this function seems like a bad idea, even in the context of
this macroset taking arbitrary _done and _code blobs...

[ovmf test] 175942: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 015a001b03db14f791476f817b8b125b195b6d10
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z5 days
Failing since175860  2023-01-15 07:11:07 Z2 days   33 attempts
Testing same since   175940  2023-01-17 16:40:41 Z0 days3 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 

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 424 lines long.)

[ovmf test] 175941: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 015a001b03db14f791476f817b8b125b195b6d10
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z5 days
Failing since175860  2023-01-15 07:11:07 Z2 days   32 attempts
Testing same since   175940  2023-01-17 16:40:41 Z0 days2 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 

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 424 lines long.)

[XEN v2 10/11] xen/arm: Restrict zeroeth_table_offset for ARM_64

[Ayan Kumar Halder]

zeroeth_table_offset is not accessed by ARM_32.
Also, when 32 bit physical addresses are used (ie ARM_PA_32=y), this
causes an overflow.

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

v1 - Removed the duplicate declaration for DECLARE_OFFSETS.

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

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

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

[Ayan Kumar Halder]

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

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

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

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

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

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

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

[Ayan Kumar Halder]

VTCR.T0SZ should be set as 0x20 to support 32bit IPA.
Refer ARM DDI 0487I.a ID081822, G8-9824, G8.2.171, VTCR,
"Virtualization Translation Control Register" for the bit descriptions.

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

v1 - New patch.

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

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 948f199d84..cfdea55e71 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -2266,13 +2266,17 @@ void __init setup_virt_paging(void)
 register_t val = VTCR_RES1|VTCR_SH0_IS|VTCR_ORGN0_WBWA|VTCR_IRGN0_WBWA;
 
 #ifdef CONFIG_ARM_32
-if ( p2m_ipa_bits < 40 )
+if ( p2m_ipa_bits < PADDR_BITS )
 panic("P2M: Not able to support %u-bit IPA at the moment\n",
   p2m_ipa_bits);
 
-printk("P2M: 40-bit IPA\n");
-p2m_ipa_bits = 40;
+printk("P2M: %u-bit IPA\n",PADDR_BITS);
+p2m_ipa_bits = PADDR_BITS;
+#ifdef CONFIG_ARM_PA_32
+val |= VTCR_T0SZ(0x20); /* 32 bit IPA */
+#else
 val |= VTCR_T0SZ(0x18); /* 40 bit IPA */
+#endif
 val |= VTCR_SL0(0x1); /* P2M starts at first level */
 #else /* CONFIG_ARM_64 */
 static const struct {
-- 
2.17.1

[XEN v2 05/11] xen/arm: Use paddr_t instead of u64 for address/size

[Ayan Kumar Halder]

One should now be able to use 'paddr_t' to represent address and size.
Consequently, one should use 'PRIpaddr' as a format specifier for paddr_t.

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

Changes from -

v1 - 1. Rebased the patch.

 xen/arch/arm/domain_build.c|  9 +
 xen/arch/arm/gic-v3.c  |  2 +-
 xen/arch/arm/platforms/exynos5.c   | 26 +-
 xen/drivers/char/exynos4210-uart.c |  2 +-
 xen/drivers/char/ns16550.c |  8 
 xen/drivers/char/omap-uart.c   |  2 +-
 xen/drivers/char/pl011.c   |  4 ++--
 xen/drivers/char/scif-uart.c   |  2 +-
 xen/drivers/passthrough/arm/smmu.c |  6 +++---
 9 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 72b9afbb4c..cf8ae37a14 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1666,7 +1666,7 @@ static int __init find_memory_holes(const struct 
kernel_info *kinfo,
 dt_for_each_device_node( dt_host, np )
 {
 unsigned int naddr;
-u64 addr, size;
+paddr_t addr, size;
 
 naddr = dt_number_of_address(np);
 
@@ -2445,7 +2445,7 @@ static int __init handle_device(struct domain *d, struct 
dt_device_node *dev,
 unsigned int naddr;
 unsigned int i;
 int res;
-u64 addr, size;
+paddr_t addr, size;
 bool own_device = !dt_device_for_passthrough(dev);
 /*
  * We want to avoid mapping the MMIO in dom0 for the following cases:
@@ -2941,9 +2941,10 @@ static int __init handle_passthrough_prop(struct 
kernel_info *kinfo,
 if ( res )
 {
 printk(XENLOG_ERR "Unable to permit to dom%d access to"
-   " 0x%"PRIx64" - 0x%"PRIx64"\n",
+   " 0x%"PRIpaddr" - 0x%"PRIpaddr"\n",
kinfo->d->domain_id,
-   mstart & PAGE_MASK, PAGE_ALIGN(mstart + size) - 1);
+   (paddr_t) (mstart & PAGE_MASK),
+   (paddr_t) (PAGE_ALIGN(mstart + size) - 1));
 return res;
 }
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index bb59ea94cd..391dfa53d7 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1393,7 +1393,7 @@ static void __init gicv3_dt_init(void)
 
 for ( i = 0; i < gicv3.rdist_count; i++ )
 {
-uint64_t rdist_base, rdist_size;
+paddr_t rdist_base, rdist_size;
 
 res = dt_device_get_address(node, 1 + i, _base, _size);
 if ( res )
diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index 6560507092..f79fad9957 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -42,8 +42,8 @@ static int exynos5_init_time(void)
 void __iomem *mct;
 int rc;
 struct dt_device_node *node;
-u64 mct_base_addr;
-u64 size;
+paddr_t mct_base_addr;
+paddr_t size;
 
 node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-mct");
 if ( !node )
@@ -59,7 +59,7 @@ static int exynos5_init_time(void)
 return -ENXIO;
 }
 
-dprintk(XENLOG_INFO, "mct_base_addr: %016llx size: %016llx\n",
+dprintk(XENLOG_INFO, "mct_base_addr: 0x%"PRIpaddr" size: 0x%"PRIpaddr"\n",
 mct_base_addr, size);
 
 mct = ioremap_nocache(mct_base_addr, size);
@@ -97,9 +97,9 @@ static int __init exynos5_smp_init(void)
 struct dt_device_node *node;
 void __iomem *sysram;
 char *compatible;
-u64 sysram_addr;
-u64 size;
-u64 sysram_offset;
+paddr_t sysram_addr;
+paddr_t size;
+paddr_t sysram_offset;
 int rc;
 
 node = dt_find_compatible_node(NULL, NULL, "samsung,secure-firmware");
@@ -131,7 +131,7 @@ static int __init exynos5_smp_init(void)
 dprintk(XENLOG_ERR, "Error in %s\n", compatible);
 return -ENXIO;
 }
-dprintk(XENLOG_INFO, "sysram_addr: %016llx size: %016llx offset: 
%016llx\n",
+dprintk(XENLOG_INFO,"sysram_addr: 0x%"PRIpaddr" size: 0x%"PRIpaddr"offset: 
0x%"PRIpaddr"\n",
 sysram_addr, size, sysram_offset);
 
 sysram = ioremap_nocache(sysram_addr, size);
@@ -189,7 +189,7 @@ static int exynos5_cpu_power_up(void __iomem *power, int 
cpu)
 return 0;
 }
 
-static int exynos5_get_pmu_baseandsize(u64 *power_base_addr, u64 *size)
+static int exynos5_get_pmu_baseandsize(paddr_t *power_base_addr, paddr_t *size)
 {
 struct dt_device_node *node;
 int rc;
@@ -215,7 +215,7 @@ static int exynos5_get_pmu_baseandsize(u64 
*power_base_addr, u64 *size)
 return -ENXIO;
 }
 
-dprintk(XENLOG_DEBUG, "power_base_addr: %016llx size: %016llx\n",
+dprintk(XENLOG_DEBUG, "power_base_addr: 0x%"PRIpaddr" size: 
0x%"PRIpaddr"\n",
 *power_base_addr, *size);
 
 return 0;
@@ -223,8 +223,8 @@ static int exynos5_get_pmu_baseandsize(u64 
*power_base_addr, u64 *size)
 
 static int exynos5_cpu_up(int cpu)
 {
-u64 power_base_addr;
-u64 size;
+paddr_t power_base_addr;
+

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

[Ayan Kumar Halder]

In the subsequent patch, we introduce "CONFIG_ARM_PA_32" to support
32 bit physical addresses. Thus, the code specific to
"Large Page Address Extension" (ie LPAE) should be enclosed within
"ifndef CONFIG_ARM_PA_32".

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

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

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

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

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

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

[XEN v2 04/11] xen/arm: Typecast the DT values into paddr_t

[Ayan Kumar Halder]

In future, we wish to support 32 bit physical address.
However, one can only read u64 values from the DT. Thus, we need to
typecast the values appropriately from u64 to paddr_t.

device_tree_get_reg() should now be able to return paddr_t. This is
invoked by various callers to get DT address and size.
Similarly, dt_read_number() is invoked as well to get DT address and
size. The return value is typecasted to paddr_t.
fdt_get_mem_rsv() can only accept u64 values. So, we provide a warpper
for this called fdt_get_mem_rsv_paddr() which will do the necessary
typecasting before invoking fdt_get_mem_rsv() and while returning.

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

Changes from

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

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

 xen/arch/arm/bootfdt.c | 23 +--
 xen/arch/arm/domain_build.c|  2 +-
 xen/arch/arm/include/asm/device_tree.h | 40 ++
 xen/arch/arm/include/asm/setup.h   |  2 +-
 xen/arch/arm/setup.c   | 14 -
 xen/arch/arm/smpboot.c |  2 +-
 6 files changed, 65 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/device_tree.h

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 0085c28d74..f536a3f3ab 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -11,9 +11,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 
 static bool __init device_tree_node_matches(const void *fdt, int node,
@@ -53,10 +53,15 @@ static bool __init device_tree_node_compatible(const void 
*fdt, int node,
 }
 
 void __init device_tree_get_reg(const __be32 **cell, u32 address_cells,
-u32 size_cells, u64 *start, u64 *size)
+u32 size_cells, paddr_t *start, paddr_t *size)
 {
-*start = dt_next_cell(address_cells, cell);
-*size = dt_next_cell(size_cells, cell);
+/*
+ * dt_next_cell will return u64 whereas paddr_t may be u64 or u32. Thus, 
one
+ * needs to cast paddr_t to u32. Note that we do not check for truncation 
as
+ * it is user's responsibility to provide the correct values in the DT.
+ */
+*start = (paddr_t) dt_next_cell(address_cells, cell);
+*size = (paddr_t) dt_next_cell(size_cells, cell);
 }
 
 static int __init device_tree_get_meminfo(const void *fdt, int node,
@@ -326,7 +331,7 @@ static int __init process_chosen_node(const void *fdt, int 
node,
 printk("linux,initrd-start property has invalid length %d\n", len);
 return -EINVAL;
 }
-start = dt_read_number((void *)>data, dt_size_to_cells(len));
+start = (paddr_t) dt_read_number((void *)>data, 
dt_size_to_cells(len));
 
 prop = fdt_get_property(fdt, node, "linux,initrd-end", );
 if ( !prop )
@@ -339,7 +344,7 @@ static int __init process_chosen_node(const void *fdt, int 
node,
 printk("linux,initrd-end property has invalid length %d\n", len);
 return -EINVAL;
 }
-end = dt_read_number((void *)>data, dt_size_to_cells(len));
+end = (paddr_t) dt_read_number((void *)>data, dt_size_to_cells(len));
 
 if ( start >= end )
 {
@@ -594,9 +599,11 @@ static void __init early_print_info(void)
 for ( i = 0; i < nr_rsvd; i++ )
 {
 paddr_t s, e;
-if ( fdt_get_mem_rsv(device_tree_flattened, i, , ) < 0 )
+
+if ( fdt_get_mem_rsv_paddr(device_tree_flattened, i, , ) < 0 )
 continue;
-/* fdt_get_mem_rsv returns length */
+
+/* fdt_get_mem_rsv_paddr returns length */
 e += s;
 printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n", i, s, e);
 }
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f904f12408..72b9afbb4c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -949,7 +949,7 @@ static int __init process_shm(struct domain *d, struct 
kernel_info *kinfo,
 BUG_ON(!prop);
 cells = (const __be32 *)prop->value;
 device_tree_get_reg(, addr_cells, addr_cells, , );
-psize = dt_read_number(cells, size_cells);
+psize = (paddr_t) dt_read_number(cells, size_cells);
 if ( !IS_ALIGNED(pbase, PAGE_SIZE) || !IS_ALIGNED(gbase, PAGE_SIZE) )
 {
 printk("%pd: physical address 0x%"PRIpaddr", or guest address 
0x%"PRIpaddr" is not suitably aligned.\n",
diff --git a/xen/arch/arm/include/asm/device_tree.h 
b/xen/arch/arm/include/asm/device_tree.h
new file mode 100644
index 00..51e0f0ae20
--- /dev/null
+++ b/xen/arch/arm/include/asm/device_tree.h
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * 

[XEN v2 09/11] xen/arm: Introduce ARM_PA_32 to support 32 bit physical address

[Ayan Kumar Halder]

We have introduced a new config option to support 32 bit physical address.
By default, it is disabled.
ARM_PA_32 cannot be enabled on ARM_64 as the memory management unit works
on 48bit physical addresses.
On ARM_32, it can be used on systems where large page address extension is
not supported.

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

v1 - 1. No changes.

 xen/arch/arm/Kconfig | 9 +
 xen/arch/arm/include/asm/page-bits.h | 2 ++
 xen/arch/arm/include/asm/types.h | 7 +++
 3 files changed, 18 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 239d3aed3c..aeb0f7252e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -39,6 +39,15 @@ config ACPI
 config ARM_EFI
bool
 
+config ARM_PA_32
+   bool "32 bit Physical Address"
+   depends on ARM_32
+   default n
+   ---help---
+
+ Support 32 bit physical addresses.
+ If unsure, say N
+
 config GICV3
bool "GICv3 driver"
depends on !NEW_VGIC
diff --git a/xen/arch/arm/include/asm/page-bits.h 
b/xen/arch/arm/include/asm/page-bits.h
index 5d6477e599..8f4dcebcfd 100644
--- a/xen/arch/arm/include/asm/page-bits.h
+++ b/xen/arch/arm/include/asm/page-bits.h
@@ -5,6 +5,8 @@
 
 #ifdef CONFIG_ARM_64
 #define PADDR_BITS  48
+#elif CONFIG_ARM_PA_32
+#define PADDR_BITS  32
 #else
 #define PADDR_BITS  40
 #endif
diff --git a/xen/arch/arm/include/asm/types.h b/xen/arch/arm/include/asm/types.h
index 083acbd151..f9595b9098 100644
--- a/xen/arch/arm/include/asm/types.h
+++ b/xen/arch/arm/include/asm/types.h
@@ -37,9 +37,16 @@ typedef signed long long s64;
 typedef unsigned long long u64;
 typedef u32 vaddr_t;
 #define PRIvaddr PRIx32
+#if defined(CONFIG_ARM_PA_32)
+typedef u32 paddr_t;
+#define INVALID_PADDR (~0UL)
+#define PADDR_SHIFT BITS_PER_LONG
+#define PRIpaddr PRIx32
+#else
 typedef u64 paddr_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
+#endif
 typedef u32 register_t;
 #define PRIregister "08x"
 #elif defined (CONFIG_ARM_64)
-- 
2.17.1

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

[Ayan Kumar Halder]

dt_device_get_address() can accept u64 only for address and size. The
various callers will use 'paddr_t' datatype for address and size.
'paddr_t' is currently defined as u64, but we may support u32 as well.
Thus, we need an appropriate wrapper which can handle this type
conversion.

The callers will now invoke dt_device_get_paddr(). This inturn invokes
dt_device_get_address() with u64 address/size. And then it typecasts
the u64 address/size to paddr_t address/size.

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

Changes from -

v1 - 1. New patch introduced.

 xen/arch/arm/domain_build.c|  5 +++--
 xen/arch/arm/gic-v2.c  | 11 ++-
 xen/arch/arm/gic-v3.c  |  9 +
 xen/arch/arm/include/asm/device_tree.h | 19 +++
 xen/arch/arm/platforms/exynos5.c   |  7 ---
 xen/arch/arm/platforms/sunxi.c |  3 ++-
 xen/drivers/char/exynos4210-uart.c |  3 ++-
 xen/drivers/char/ns16550.c |  3 ++-
 xen/drivers/char/omap-uart.c   |  3 ++-
 xen/drivers/char/pl011.c   |  3 ++-
 xen/drivers/char/scif-uart.c   |  3 ++-
 xen/drivers/passthrough/arm/smmu.c |  3 ++-
 12 files changed, 51 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cf8ae37a14..21199b624b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1672,7 +1673,7 @@ static int __init find_memory_holes(const struct 
kernel_info *kinfo,
 
 for ( i = 0; i < naddr; i++ )
 {
-res = dt_device_get_address(np, i, , );
+res = dt_device_get_paddr(np, i, , );
 if ( res )
 {
 printk(XENLOG_ERR "Unable to retrieve address %u for %s\n",
@@ -2500,7 +2501,7 @@ static int __init handle_device(struct domain *d, struct 
dt_device_node *dev,
 /* Give permission and map MMIOs */
 for ( i = 0; i < naddr; i++ )
 {
-res = dt_device_get_address(dev, i, , );
+res = dt_device_get_paddr(dev, i, , );
 if ( res )
 {
 printk(XENLOG_ERR "Unable to retrieve address %u for %s\n",
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 5d4d298b86..5230c4ebaf 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -993,7 +994,7 @@ static void gicv2_extension_dt_init(const struct 
dt_device_node *node)
 continue;
 
 /* Get register frame resource from DT. */
-if ( dt_device_get_address(v2m, 0, , ) )
+if ( dt_device_get_paddr(v2m, 0, , ) )
 panic("GICv2: Cannot find a valid v2m frame address\n");
 
 /*
@@ -1018,19 +1019,19 @@ static void __init gicv2_dt_init(void)
 paddr_t vsize;
 const struct dt_device_node *node = gicv2_info.node;
 
-res = dt_device_get_address(node, 0, , NULL);
+res = dt_device_get_paddr(node, 0, , NULL);
 if ( res )
 panic("GICv2: Cannot find a valid address for the distributor\n");
 
-res = dt_device_get_address(node, 1, , );
+res = dt_device_get_paddr(node, 1, , );
 if ( res )
 panic("GICv2: Cannot find a valid address for the CPU\n");
 
-res = dt_device_get_address(node, 2, , NULL);
+res = dt_device_get_paddr(node, 2, , NULL);
 if ( res )
 panic("GICv2: Cannot find a valid address for the hypervisor\n");
 
-res = dt_device_get_address(node, 3, , );
+res = dt_device_get_paddr(node, 3, , );
 if ( res )
 panic("GICv2: Cannot find a valid address for the virtual CPU\n");
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 391dfa53d7..58d2eb0690 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1377,7 +1378,7 @@ static void __init gicv3_dt_init(void)
 int res, i;
 const struct dt_device_node *node = gicv3_info.node;
 
-res = dt_device_get_address(node, 0, , NULL);
+res = dt_device_get_paddr(node, 0, , NULL);
 if ( res )
 panic("GICv3: Cannot find a valid distributor address\n");
 
@@ -1395,7 +1396,7 @@ static void __init gicv3_dt_init(void)
 {
 paddr_t rdist_base, rdist_size;
 
-res = dt_device_get_address(node, 1 + i, _base, _size);
+res = dt_device_get_paddr(node, 1 + i, _base, _size);
 if ( res )
 panic("GICv3: No rdist base found for region %d\n", i);
 
@@ -1417,10 +1418,10 @@ static void __init gicv3_dt_init(void)
  * For GICv3 supporting GICv2, GICC and GICV base address will be
  * provided.
  */
-res = dt_device_get_address(node, 1 + gicv3.rdist_count,
+res = dt_device_get_paddr(node, 1 + gicv3.rdist_count,
 , );
 if ( !res )
-

[XEN v2 02/11] xen/arm: Use the correct format specifier

[Ayan Kumar Halder]

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

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

Changes from -

v1 - 1. Moved the patch earlier.
2. Moved a part of change from "[XEN v1 8/9] xen/arm: Other adaptations 
required to support 32bit paddr"
into this patch.

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

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 829cea8de8..33a5945a2d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1315,7 +1315,7 @@ static int __init make_memory_node(const struct domain *d,
 dt_dprintk("Create memory node\n");
 
 /* ePAPR 3.4 */
-snprintf(buf, sizeof(buf), "memory@%"PRIx64, mem->bank[i].start);
+snprintf(buf, sizeof(buf), "memory@%"PRIpaddr, mem->bank[i].start);
 res = fdt_begin_node(fdt, buf);
 if ( res )
 return res;
@@ -1383,7 +1383,7 @@ static int __init make_shm_memory_node(const struct 
domain *d,
 __be32 *cells;
 unsigned int len = (addrcells + sizecells) * sizeof(__be32);
 
-snprintf(buf, sizeof(buf), "xen-shmem@%"PRIx64, mem->bank[i].start);
+snprintf(buf, sizeof(buf), "xen-shmem@%"PRIpaddr, mem->bank[i].start);
 res = fdt_begin_node(fdt, buf);
 if ( res )
 return res;
@@ -2719,7 +2719,7 @@ static int __init make_gicv2_domU_node(struct kernel_info 
*kinfo)
 /* Placeholder for interrupt-controller@ + a 64-bit number + \0 */
 char buf[38];
 
-snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIx64,
+snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIpaddr,
  vgic_dist_base(>arch.vgic));
 res = fdt_begin_node(fdt, buf);
 if ( res )
@@ -2775,7 +2775,7 @@ static int __init make_gicv3_domU_node(struct kernel_info 
*kinfo)
 char buf[38];
 unsigned int i, len = 0;
 
-snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIx64,
+snprintf(buf, sizeof(buf), "interrupt-controller@%"PRIpaddr,
  vgic_dist_base(>arch.vgic));
 
 res = fdt_begin_node(fdt, buf);
@@ -2861,7 +2861,7 @@ static int __init make_vpl011_uart_node(struct 
kernel_info *kinfo)
 /* Placeholder for sbsa-uart@ + a 64-bit number + \0 */
 char buf[27];
 
-snprintf(buf, sizeof(buf), "sbsa-uart@%"PRIx64, d->arch.vpl011.base_addr);
+snprintf(buf, sizeof(buf), "sbsa-uart@%"PRIpaddr, 
d->arch.vpl011.base_addr);
 res = fdt_begin_node(fdt, buf);
 if ( res )
 return res;
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 61802839cb..5d4d298b86 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1049,7 +1049,7 @@ static void __init gicv2_dt_init(void)
 if ( csize < SZ_8K )
 {
 printk(XENLOG_WARNING "GICv2: WARNING: "
-   "The GICC size is too small: %#"PRIx64" expected %#x\n",
+   "The GICC size is too small: %#"PRIpaddr" expected %#x\n",
csize, SZ_8K);
 if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
 {
@@ -1280,11 +1280,11 @@ static int __init gicv2_init(void)
 gicv2.map_cbase += aliased_offset;
 
 printk(XENLOG_WARNING
-   "GICv2: Adjusting CPU interface base to %#"PRIx64"\n",
+   "GICv2: Adjusting CPU interface base to %#"PRIpaddr"\n",
cbase + aliased_offset);
 } else if ( csize == SZ_128K )
 printk(XENLOG_WARNING
-   "GICv2: GICC size=%#"PRIx64" but not aliased\n",
+   "GICv2: GICC size=%#"PRIpaddr" but not aliased\n",
csize);
 
 gicv2.map_hbase = ioremap_nocache(hbase, PAGE_SIZE);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0fc6f2992d..fab54618ab 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -249,7 +249,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
 
 pte = mapping[offsets[level]];
 
-printk("%s[0x%03x] = 0x%"PRIpaddr"\n",
+printk("%s[0x%03x] = 0x%"PRIx64"\n",
level_strs[level], offsets[level], pte.bits);
 
 if ( level == 3 || !pte.walk.valid || !pte.walk.table )
-- 
2.17.1

[XEN v2 03/11] xen/arm: domain_build: Replace use of paddr_t in find_domU_holes()

[Ayan Kumar Halder]

bankbase, banksize and bankend are used to hold values of type 'unsigned
long long'. This can be represented as 'uint64_t' instead of 'paddr_t'.
This will ensure consistency with allocate_static_memory() (where we use
'uint64_t' for rambase and ramsize).

In future, paddr_t can be used for 'uin32_t' as well to represent 32bit
physical addresses.

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

Changes from -

v1 - Modified the title/commit message from "[XEN v1 6/9] xen/arm: Use 'u64' to 
represent 'unsigned long long"
and moved it earlier.

 xen/arch/arm/domain_build.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 33a5945a2d..f904f12408 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1726,9 +1726,9 @@ static int __init find_domU_holes(const struct 
kernel_info *kinfo,
   struct meminfo *ext_regions)
 {
 unsigned int i;
-paddr_t bankend;
-const paddr_t bankbase[] = GUEST_RAM_BANK_BASES;
-const paddr_t banksize[] = GUEST_RAM_BANK_SIZES;
+uint64_t bankend;
+const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+const uint64_t banksize[] = GUEST_RAM_BANK_SIZES;
 int res = -ENOENT;
 
 for ( i = 0; i < GUEST_RAM_BANKS; i++ )
-- 
2.17.1

[XEN v2 01/11] xen/ns16550: Remove unneeded truncation check in the DT init code

[Ayan Kumar Halder]

In an earlier commit (7c1de0038895), "ns16550.io_size" was u32 and
"io_size" was u64. Thus, the ASSERT() was needed to check if the values
are the same.
However, in a later commit (c9f8e0aee507), "ns16550.io_size" was changed
to u64. Thus, the ASSERT() became redundant.

So, now as "io_size" and "uart->io_size" are both u64, there will be no
truncation. Thus, one can remove the ASSERT() and extra assignment.

Signed-off-by: Ayan Kumar Halder 
Reviewed-by: Jan Beulich 
---

Changes from :

v1 - 1. Updated commit message/title.
2. Added Rb.

 xen/drivers/char/ns16550.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 01a05c9aa8..58d0ccd889 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1747,7 +1747,6 @@ static int __init ns16550_uart_dt_init(struct 
dt_device_node *dev,
 struct ns16550 *uart;
 int res;
 u32 reg_shift, reg_width;
-u64 io_size;
 
 uart = _com[0];
 
@@ -1758,14 +1757,10 @@ static int __init ns16550_uart_dt_init(struct 
dt_device_node *dev,
 uart->parity= UART_PARITY_NONE;
 uart->stop_bits = 1;
 
-res = dt_device_get_address(dev, 0, >io_base, _size);
+res = dt_device_get_address(dev, 0, >io_base, >io_size);
 if ( res )
 return res;
 
-uart->io_size = io_size;
-
-ASSERT(uart->io_size == io_size); /* Detect truncation */
-
 res = dt_property_read_u32(dev, "reg-shift", _shift);
 if ( !res )
 uart->reg_shift = 0;
-- 
2.17.1

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

[Ayan Kumar Halder]

Hi All,

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

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

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

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


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

Changes from :

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

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

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

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

Ayan Kumar Halder (11):
  xen/ns16550: Remove unneeded truncation check in the DT init code
  xen/arm: Use the correct format specifier
  xen/arm: domain_build: Replace use of paddr_t in find_domU_holes()
  xen/arm: Typecast the DT values into paddr_t
  xen/arm: Use paddr_t instead of u64 for address/size
  xen/arm: Introduce a wrapper for dt_device_get_address() to handle
paddr_t
  xen/arm: smmu: Use writeq_relaxed_non_atomic() for writing to
SMMU_CBn_TTBR0
  xen/arm: guest_walk: LPAE specific bits should be enclosed within
"ifndef CONFIG_ARM_PA_32"
  xen/arm: Introduce ARM_PA_32 to support 32 bit physical address
  xen/arm: Restrict zeroeth_table_offset for ARM_64
  xen/arm: p2m: Enable support for 32bit IPA

 xen/arch/arm/Kconfig   |  9 
 xen/arch/arm/bootfdt.c | 23 ++
 xen/arch/arm/domain_build.c| 32 +++---
 xen/arch/arm/gic-v2.c  | 17 
 xen/arch/arm/gic-v3.c  | 11 ++---
 xen/arch/arm/guest_walk.c  |  2 +
 xen/arch/arm/include/asm/device_tree.h | 59 ++
 xen/arch/arm/include/asm/lpae.h|  4 ++
 xen/arch/arm/include/asm/page-bits.h   |  2 +
 xen/arch/arm/include/asm/setup.h   |  2 +-
 xen/arch/arm/include/asm/types.h   |  7 +++
 xen/arch/arm/mm.c  |  9 +---
 xen/arch/arm/p2m.c | 10 +++--
 xen/arch/arm/platforms/exynos5.c   | 33 +++---
 xen/arch/arm/platforms/sunxi.c |  3 +-
 xen/arch/arm/setup.c   | 14 +++---
 xen/arch/arm/smpboot.c |  2 +-
 xen/drivers/char/exynos4210-uart.c |  5 ++-
 xen/drivers/char/ns16550.c | 16 +++
 xen/drivers/char/omap-uart.c   |  5 ++-
 xen/drivers/char/pl011.c   |  7 +--
 xen/drivers/char/scif-uart.c   |  5 ++-
 xen/drivers/passthrough/arm/smmu.c | 24 ++-
 23 files changed, 199 insertions(+), 102 deletions(-)
 create mode 100644 xen/arch/arm/include/asm/device_tree.h

-- 
2.17.1

Re: [PATCH v2 3/5] xen/version: Introduce non-truncating XENVER_* subops

[Andrew Cooper]

On 17/01/2023 4:21 pm, Jason Andryuk wrote:
> On Fri, Jan 13, 2023 at 6:08 PM Andrew Cooper  
> wrote:
>> Recently in XenServer, we have encountered problems caused by both
>> XENVER_extraversion and XENVER_commandline having fixed bounds.
>>
>> More than just the invariant size, the APIs/ABIs also broken by typedef-ing 
>> an
>> array, and using an unqualified 'char' which has implementation-specific
>> signed-ness
>>
>> Provide brand new ops, which are capable of expressing variable length
>> strings, and mark the older ops as broken.
>>
>> This fixes all issues around XENVER_extraversion being longer than 15 chars.
>> More work is required to remove other assumptions about XENVER_commandline
>> being 1023 chars long.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: George Dunlap 
>> CC: Jan Beulich 
>> CC: Stefano Stabellini 
>> CC: Wei Liu 
>> CC: Julien Grall 
>> CC: Daniel De Graaf 
>> CC: Daniel Smith 
>> CC: Jason Andryuk 
>>
>> v2:
>>  * Remove xen_capabilities_info_t from the stack now that arch_get_xen_caps()
>>has gone.
>>  * Use an arbitrary limit check much lower than INT_MAX.
>>  * Use "buf" rather than "string" terminology.
>>  * Expand the API comment.
>>
>> Tested by forcing XENVER_extraversion to be 20 chars long, and confirming 
>> that
>> an untruncated version can be obtained.
>> ---
>>  xen/common/kernel.c  | 62 
>> +++
>>  xen/include/public/version.h | 63 
>> ++--
>>  xen/include/xlat.lst |  1 +
>>  xen/xsm/flask/hooks.c|  4 +++
> The Flask change looks good, so that part is:
> Reviewed-by: Jason Andryuk  # Flask

Thanks.

>
> Looking at include/xsm/dummy.h, these new subops would fall under the
> default case and require XSM_PRIV.  Is that the desired permission,
> and guests would just have to handle EPERM?

I noticed that during further testing.  I made a modification to dummy
in the same manner as flask.

Given that it's the same piece of information (just with a less broken
API), permission handling for the two ops should be the same.

~Andrew

[ovmf test] 175940: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 015a001b03db14f791476f817b8b125b195b6d10
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z5 days
Failing since175860  2023-01-15 07:11:07 Z2 days   31 attempts
Testing same since   175940  2023-01-17 16:40:41 Z0 days1 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 

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 424 lines long.)

Re: [XEN PATCH v3 1/1] build: replace get-fields.sh by a python script

[Andrew Cooper]

On 16/01/2023 6:10 pm, Anthony PERARD wrote:
> The get-fields.sh which generate all the include/compat/.xlat/*.h
> headers is quite slow. It takes for example nearly 3 seconds to
> generate platform.h on a recent machine, or 2.3 seconds for memory.h.
>
> Rewriting the mix of shell/sed/python into a single python script make
> the generation of those file a lot faster.
>
> No functional change, the headers generated are identical.
>
> Signed-off-by: Anthony PERARD 

I'll happily trust the testing you've done, and that the outputs are
equivalent.  However, I have some general python suggestions.

> diff --git a/xen/tools/compat-xlat-header.py b/xen/tools/compat-xlat-header.py
> new file mode 100644
> index 00..c1b361ac56
> --- /dev/null
> +++ b/xen/tools/compat-xlat-header.py
> @@ -0,0 +1,468 @@
> +#!/usr/bin/env python
> +
> +from __future__ import print_function
> +import re
> +import sys
> +
> +typedefs = []
> +
> +def removeprefix(s, prefix):
> +if s.startswith(prefix):
> +return s[len(prefix):]
> +return s
> +
> +def removesuffix(s, suffix):
> +if s.endswith(suffix):
> +return s[:-len(suffix)]
> +return s
> +
> +def get_fields(looking_for, header_tokens):
> +level = 1
> +aggr = 0
> +fields = []
> +name = ''
> +
> +for token in header_tokens:
> +if token in ['struct', 'union']:

('struct', 'union')

A tuple here rather than a list is marginally more efficient.

> +if level == 1:
> +aggr = 1
> +fields = []
> +name = ''
> +elif token == '{':
> +level += 1
> +elif token == '}':
> +level -= 1
> +if level == 1 and name == looking_for:
> +fields.append(token)
> +return fields
> +elif re.match(r'^[a-zA-Z_]', token):

Here and many other places, you've got re.{search,match} with repeated
regexes.   This can end up being quite expensive, and we already had one
build system slowdown caused by it.

Up near typedefs at the top, you want something like:

token_re = re.compile('[a-zA-Z_]')

to prepare the regex once at the start of day, and and use 'elif
token_re.match(token)' here.

Another thing to note, the difference between re.search and re.match is
that match has an implicit '^' anchor.  You need to be aware of this
when compiling one regex to be used with both.


All of this said, where is 0-9 in the token regex?  Have we just got
extremely lucky with having no embedded digits in identifiers thus far?

> +if not (aggr == 0 or name != ''):
> +name = token
> +
> +if aggr != 0:
> +fields.append(token)
> +
> +return []
> +
> +def get_typedefs(tokens):
> +level = 1
> +state = 0
> +typedefs = []

This shadows the global typedefs list, but the result of calling this
function is simply assigned to it.  Looking at the code, the global list
is used in several places

It would be better to "global typedefs" here, and make this function
void, unless you want to modify handle_field() and build_body() to take
it in as a regular parameter.

I'm pretty sure typedefs actually wants to be a dict rather than a list
(will have better "id in typedefs" performance lower down), but that
wants matching with code changes elsewhere, and probably wants doing
separately.

> +for token in tokens:
> +if token == 'typedef':
> +if level == 1:
> +state = 1
> +elif re.match(r'^COMPAT_HANDLE\((.*)\)$', token):
> +if not (level != 1 or state != 1):
> +state = 2
> +elif token in ['[', '{']:
> +level += 1
> +elif token in [']', '}']:
> +level -= 1
> +elif token == ';':
> +if level == 1:
> +state = 0
> +elif re.match(r'^[a-zA-Z_]', token):
> +if not (level != 1 or state != 2):
> +typedefs.append(token)
> +return typedefs
> +
> +def build_enums(name, tokens):
> +level = 1
> +kind = ''
> +named = ''
> +fields = []
> +members = []
> +id = ''
> +
> +for token in tokens:
> +if token in ['struct', 'union']:
> +if not level != 2:
> +fields = ['']
> +kind = "%s;%s" % (token, kind)
> +elif token == '{':
> +level += 1
> +elif token == '}':
> +level -= 1
> +if level == 1:
> +subkind = kind
> +(subkind, _, _) = subkind.partition(';')
> +if subkind == 'union':
> +print("\nenum XLAT_%s {" % (name,))
> +for m in members:
> +print("XLAT_%s_%s," % (name, m))
> +print("};")
> +return
> +elif level == 2:
> +named = '?'
> +elif re.match(r'^[a-zA-Z_]', token):
> +id = token
> +

Re: [XEN PATCH v3 1/1] build: replace get-fields.sh by a python script

[Luca Fancellu]

> On 17 Jan 2023, at 16:55, Anthony PERARD  wrote:
> 
> On Tue, Jan 17, 2023 at 04:07:24PM +, Luca Fancellu wrote:
>>> On 16 Jan 2023, at 18:10, Anthony PERARD  wrote:
>>> diff --git a/xen/tools/compat-xlat-header.py 
>>> b/xen/tools/compat-xlat-header.py
>>> new file mode 100644
>>> index 00..c1b361ac56
>>> --- /dev/null
>>> +++ b/xen/tools/compat-xlat-header.py
>>> @@ -0,0 +1,468 @@
>>> +#!/usr/bin/env python
>> 
>> Would it make sense to start with python3 since it is a new script?
> 
> That shebang isn't even used as the script doesn't even have the
> execution bit set. So why do you say that the script isn't python3? Not
> really asking, just been pedantic :-)

Yes I didn’t pay attention to that

> 
> Even if it's a new script, it isn't a new project. We can't depend on
> brand new functionality from our dependencies. We need to be able to
> build the hypervisor with old build toolchain / distribution.
> 
> Anyway, I did start by writing a python3 script in all its glory (or at
> least some of the new part of the language that I know about), but I had
> to rework it to be able to use it on older distribution. Our centos7
> container in our GitLab CI seems to use python2.7.

That makes sense, thanks for the explanation.

> 
> So I had to stop using str.removeprefix() and I introduce some function
> doing the same thing instead (so that works with older than python 3.9).
> Then I had to stop using f-strings and use %-formatting instead.
> Then use "m.groups()[0]" instead of "m[1]" where "m" is a match result
> from re.match() and other.
> And use the classing "from __future__ ..." preamble.
> 
> Cheers,
> 
> -- 
> Anthony PERARD

Re: [XEN PATCH v3 1/1] build: replace get-fields.sh by a python script

[Anthony PERARD]

On Tue, Jan 17, 2023 at 04:07:24PM +, Luca Fancellu wrote:
> > On 16 Jan 2023, at 18:10, Anthony PERARD  wrote:
> > diff --git a/xen/tools/compat-xlat-header.py 
> > b/xen/tools/compat-xlat-header.py
> > new file mode 100644
> > index 00..c1b361ac56
> > --- /dev/null
> > +++ b/xen/tools/compat-xlat-header.py
> > @@ -0,0 +1,468 @@
> > +#!/usr/bin/env python
> 
> Would it make sense to start with python3 since it is a new script?

That shebang isn't even used as the script doesn't even have the
execution bit set. So why do you say that the script isn't python3? Not
really asking, just been pedantic :-)

Even if it's a new script, it isn't a new project. We can't depend on
brand new functionality from our dependencies. We need to be able to
build the hypervisor with old build toolchain / distribution.

Anyway, I did start by writing a python3 script in all its glory (or at
least some of the new part of the language that I know about), but I had
to rework it to be able to use it on older distribution. Our centos7
container in our GitLab CI seems to use python2.7.

So I had to stop using str.removeprefix() and I introduce some function
doing the same thing instead (so that works with older than python 3.9).
Then I had to stop using f-strings and use %-formatting instead.
Then use "m.groups()[0]" instead of "m[1]" where "m" is a match result
from re.match() and other.
And use the classing "from __future__ ..." preamble.

Cheers,

-- 
Anthony PERARD

[ovmf test] 175939: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 a107ad0f623669c72997443dc0431eeb732f81a0
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z5 days
Failing since175860  2023-01-15 07:11:07 Z2 days   30 attempts
Testing same since   175935  2023-01-17 14:42:05 Z0 days3 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 

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 323 lines long.)

Re: [PATCH v2 3/5] xen/version: Introduce non-truncating XENVER_* subops

[Jason Andryuk]

On Fri, Jan 13, 2023 at 6:08 PM Andrew Cooper  wrote:
>
> Recently in XenServer, we have encountered problems caused by both
> XENVER_extraversion and XENVER_commandline having fixed bounds.
>
> More than just the invariant size, the APIs/ABIs also broken by typedef-ing an
> array, and using an unqualified 'char' which has implementation-specific
> signed-ness
>
> Provide brand new ops, which are capable of expressing variable length
> strings, and mark the older ops as broken.
>
> This fixes all issues around XENVER_extraversion being longer than 15 chars.
> More work is required to remove other assumptions about XENVER_commandline
> being 1023 chars long.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: George Dunlap 
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Wei Liu 
> CC: Julien Grall 
> CC: Daniel De Graaf 
> CC: Daniel Smith 
> CC: Jason Andryuk 
>
> v2:
>  * Remove xen_capabilities_info_t from the stack now that arch_get_xen_caps()
>has gone.
>  * Use an arbitrary limit check much lower than INT_MAX.
>  * Use "buf" rather than "string" terminology.
>  * Expand the API comment.
>
> Tested by forcing XENVER_extraversion to be 20 chars long, and confirming that
> an untruncated version can be obtained.
> ---
>  xen/common/kernel.c  | 62 +++
>  xen/include/public/version.h | 63 
> ++--
>  xen/include/xlat.lst |  1 +
>  xen/xsm/flask/hooks.c|  4 +++

The Flask change looks good, so that part is:
Reviewed-by: Jason Andryuk  # Flask

Looking at include/xsm/dummy.h, these new subops would fall under the
default case and require XSM_PRIV.  Is that the desired permission,
and guests would just have to handle EPERM?

Regards,
Jason

Re: [XEN PATCH v3 1/1] build: replace get-fields.sh by a python script

[Luca Fancellu]

> On 16 Jan 2023, at 18:10, Anthony PERARD  wrote:
> 
> The get-fields.sh which generate all the include/compat/.xlat/*.h
> headers is quite slow. It takes for example nearly 3 seconds to
> generate platform.h on a recent machine, or 2.3 seconds for memory.h.
> 
> Rewriting the mix of shell/sed/python into a single python script make
> the generation of those file a lot faster.
> 
> No functional change, the headers generated are identical.
> 
> Signed-off-by: Anthony PERARD 
> ---
> 
> Notes:
>To test the header generation, I've submit a branch to gitlab ci,
>where all the headers where generated, and for each one both the shell
>script and the python script where run and the result of both
>compared.
> 
>v3:
>convert to python script instead of perl
>- this should allow more developper do be able to review/edit it.
>- it avoid adding a dependency on perl for the hypervisor build.
> 
>It can be twice as slow than the perl version, but overall, when doing
>a build with make, there isn't much difference between the perl and
>python script.
>We might be able to speed the python script up by precompiling the
>many regex, but it's probably not worth it. (python already have a
>cache of compiled regex, but I think it's small, maybe 10 or so)
> 
>v2:
>- Add .pl extension to the perl script
>- remove "-w" from the shebang as it is duplicate of "use warning;"
>- Add a note in the commit message that the "headers generated are 
> identical".
> 
> xen/include/Makefile|   6 +-
> xen/tools/compat-xlat-header.py | 468 
> xen/tools/get-fields.sh | 528 
> 3 files changed, 470 insertions(+), 532 deletions(-)
> create mode 100644 xen/tools/compat-xlat-header.py
> delete mode 100644 xen/tools/get-fields.sh
> 
> diff --git a/xen/include/Makefile b/xen/include/Makefile
> index 65be310eca..b950423efe 100644
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -60,9 +60,7 @@ cmd_compat_c = \
> 
> quiet_cmd_xlat_headers = GEN $@
> cmd_xlat_headers = \
> -while read what name; do \
> -$(SHELL) $(srctree)/tools/get-fields.sh "$$what" compat_$$name $< || 
> exit $$?; \
> -done <$(patsubst $(obj)/compat/%,$(obj)/compat/.xlat/%,$(basename 
> $<)).lst >$@.new; \
> +$(PYTHON) $(srctree)/tools/compat-xlat-header.py $< $(patsubst 
> $(obj)/compat/%,$(obj)/compat/.xlat/%,$(basename $<)).lst > $@.new; \
> mv -f $@.new $@
> 
> targets += $(headers-y)
> @@ -80,7 +78,7 @@ $(obj)/compat/%.c: $(src)/public/%.h $(srcdir)/xlat.lst 
> $(srctree)/tools/compat-
> $(call if_changed,compat_c)
> 
> targets += $(patsubst compat/%, compat/.xlat/%, $(headers-y))
> -$(obj)/compat/.xlat/%.h: $(obj)/compat/%.h $(obj)/compat/.xlat/%.lst 
> $(srctree)/tools/get-fields.sh FORCE
> +$(obj)/compat/.xlat/%.h: $(obj)/compat/%.h $(obj)/compat/.xlat/%.lst 
> $(srctree)/tools/compat-xlat-header.py FORCE
> $(call if_changed,xlat_headers)
> 
> quiet_cmd_xlat_lst = GEN $@
> diff --git a/xen/tools/compat-xlat-header.py b/xen/tools/compat-xlat-header.py
> new file mode 100644
> index 00..c1b361ac56
> --- /dev/null
> +++ b/xen/tools/compat-xlat-header.py
> @@ -0,0 +1,468 @@
> +#!/usr/bin/env python

Would it make sense to start with python3 since it is a new script?

[ovmf test] 175937: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 a107ad0f623669c72997443dc0431eeb732f81a0
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z4 days
Failing since175860  2023-01-15 07:11:07 Z2 days   29 attempts
Testing same since   175935  2023-01-17 14:42:05 Z0 days2 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 

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 323 lines long.)

Re: [XEN PATCH] Create a Kconfig option to set preferred reboot method

[Jan Beulich]

On 16.01.2023 18:21, Per Bilse wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -306,6 +306,101 @@ config MEM_SHARING
>   bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
>   depends on HVM
>  
> +config REBOOT_SYSTEM_DEFAULT
> + default y
> + bool "Xen-defined reboot method"

May I ask that you swap the two lines? (Personally I consider kconfig
too forgiving here - it doesn't make a lot of sense to set a default
when the type isn't known yet.)

> + help
> + Xen will choose the most appropriate reboot method,
> + which will be EFI, ACPI, or by way of the keyboard
> + controller, depending on system features.  Disabling
> + this will allow you to choose exactly how the system
> + will be rebooted.

Indentation: Help text is to be indented by a tab and two spaces. See
pre-existing examples.

> +choice
> + bool "Choose reboot method"
> + depends on !REBOOT_SYSTEM_DEFAULT
> + default REBOOT_METHOD_ACPI
> + help
> + This is a compiled-in alternative to specifying the
> + reboot method on the Xen command line.  Specifying a
> + method on the command line will override this choice.
> +
> + warmDon't set the cold reboot flag
> + coldSet the cold reboot flag

These two are modifiers, not reboot methods on their own. They set a
field in the BDA to tell the BIOS how much initialization / checking
to do (in the legacy case). Therefore they shouldn't be selectable
right here. If you feel like it you could add another boolean to
control that default.

> + noneSuppress automatic reboot after panics or crashes
> + triple  Force a triple fault (init)
> + kbd Use the keyboard controller, cold reset
> + acpiUse the RESET_REG in the FADT
> + pci Use the so-called "PCI reset register", CF9
> + power   Like 'pci' but for a full power-cyle reset
> + efi Use the EFI reboot (if running under EFI)
> + xen Use Xen SCHEDOP hypercall (if running under Xen as a 
> guest)
> +
> + config REBOOT_METHOD_WARM
> + bool "warm"
> + help
> + Don't set the cold reboot flag.

I don't think help text is very useful in sub-items of a choice. Plus
you also explain each item above.

> + config REBOOT_METHOD_COLD
> + bool "cold"
> + help
> + Set the cold reboot flag.
> +
> + config REBOOT_METHOD_NONE
> + bool "none"
> + help
> + Suppress automatic reboot after panics or crashes.
> +
> + config REBOOT_METHOD_TRIPLE
> + bool "triple"
> + help
> + Force a triple fault (init).
> +
> + config REBOOT_METHOD_KBD
> + bool "kbd"
> + help
> + Use the keyboard controller, cold reset.
> +
> + config REBOOT_METHOD_ACPI
> + bool "acpi"
> + help
> + Use the RESET_REG in the FADT.
> +
> + config REBOOT_METHOD_PCI
> + bool "pci"
> + help
> + Use the so-called "PCI reset register", CF9.
> +
> + config REBOOT_METHOD_POWER
> + bool "power"
> + help
> + Like 'pci' but for a full power-cyle reset.
> +
> + config REBOOT_METHOD_EFI
> + bool "efi"
> + help
> + Use the EFI reboot (if running under EFI).
> +
> + config REBOOT_METHOD_XEN
> + bool "xen"
> + help
> + Use Xen SCHEDOP hypercall (if running under Xen as a 
> guest).

This wants to depend on XEN_GUEST, doesn't it?

> +endchoice
> +
> +config REBOOT_METHOD
> + string
> + default "w" if REBOOT_METHOD_WARM
> + default "c" if REBOOT_METHOD_COLD
> + default "n" if REBOOT_METHOD_NONE
> + default "t" if REBOOT_METHOD_TRIPLE
> + default "k" if REBOOT_METHOD_KBD
> + default "a" if REBOOT_METHOD_ACPI
> + default "p" if REBOOT_METHOD_PCI
> + default "P" if REBOOT_METHOD_POWER
> + default "e" if REBOOT_METHOD_EFI
> + default "x" if REBOOT_METHOD_XEN

I think it would be neater (and more forward compatible) if the strings
were actually spelled out here. We may, at any time, make set_reboot_type()
look at more than just the first character.

> @@ -143,6 +144,8 @@ void machine_halt(void)
>  __machine_halt(NULL);
>  }
>  
> +#ifdef CONFIG_REBOOT_SYSTEM_DEFAULT
> +
>  static void default_reboot_type(void)
>  {
>  if ( reboot_type != BOOT_INVALID )
> @@ -533,6 +536,8 @@ static const struct dmi_system_id __initconstrel 
> reboot_dmi_table[] = {
>  { }
>  };
>  
> +#endif /* CONFIG_REBOOT_SYSTEM_DEFAULT */
> +
>  static int __init cf_check reboot_init(void)
>  {
>  /*
> @@ -542,8 +547,12 @@ 

Re: [PATCH v3 08/17] tools/xenstore: don't allow creating too many nodes in a transaction

[Juergen Gross]

On 17.01.23 15:08, Julien Grall wrote:

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

The accounting for the number of nodes of a domain in an active
transaction is not working correctly, as it allows to create arbitrary
number of nodes. The transaction will finally fail due to exceeding
the number of nodes quota, but before closing the transaction an
unprivileged guest could cause Xenstore to use a lot of memory.

Signed-off-by: Juergen Gross 


Is the rest of the series depend on this patch? I am asking this because I still 
need to go through your second series before forging an opinion on this patch.


I think the rest should apply without this one. There shouldn't be any
functional dependency.


Yet, I would like to reduce the number of inflight patches :).


+1


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v3 04/17] tools/xenstore: introduce dummy nodes for special watch paths

[Juergen Gross]

On 17.01.23 15:02, Julien Grall wrote:

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

+static void fire_special_watches(const char *name)
+{
+    void *ctx = talloc_new(NULL);
+    struct node *node;
+
+    if (!ctx)
+    return;
+
+    node = read_node(NULL, ctx, name);
+
+    if (node)
+    fire_watches(NULL, ctx, name, node, true, NULL);
+    else
+    syslog(LOG_ERR, "special node %s not found\n", name);


NIT: How about using log() so it is also printed in the trace log? This would be 
handy to avoid having to check multiple log files.


This would require to move patch 14 in front of this one.

I think this is possible without problems.



With or without:

Reviewed-by: Julien Grall 


Thanks,


Juergen



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] x86/acpi: fix suspend with Xen

[Rafael J. Wysocki]

On Tue, Jan 17, 2023 at 4:32 PM Juergen Gross  wrote:
>
> On 17.01.23 15:09, Rafael J. Wysocki wrote:
> > On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross  wrote:
> >>
> >> On 13.01.23 20:40, Rafael J. Wysocki wrote:
> >>> On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross  wrote:
> 
>  Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
>  Xen PV guest") missed one code path accessing real_mode_header, leading
>  to dereferencing NULL when suspending the system under Xen:
> 
>    [  348.284004] PM: suspend entry (deep)
>    [  348.289532] Filesystems sync: 0.005 seconds
>    [  348.291545] Freezing user space processes ... (elapsed 0.000 
>  seconds) done.
>    [  348.292457] OOM killer disabled.
>    [  348.292462] Freezing remaining freezable tasks ... (elapsed 
>  0.104 seconds) done.
>    [  348.396612] printk: Suspending console(s) (use 
>  no_console_suspend to debug)
>    [  348.749228] PM: suspend devices took 0.352 seconds
>    [  348.769713] ACPI: EC: interrupt blocked
>    [  348.816077] BUG: kernel NULL pointer dereference, address: 
>  001c
>    [  348.816080] #PF: supervisor read access in kernel mode
>    [  348.816081] #PF: error_code(0x) - not-present page
>    [  348.816083] PGD 0 P4D 0
>    [  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
>    [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
>  6.1.3-1.fc32.qubes.x86_64 #1
>    [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 
>  8.01 07/03/2022
>    [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20
> 
>  Fix that by adding an indirection for acpi_get_wakeup_address() which
>  Xen PV dom0 can use to return a dummy non-zero wakeup address (this
>  address won't ever be used, as the real suspend handling is done by the
>  hypervisor).
> >>>
> >>> How exactly does this help?
> >>
> >> I believed the first sentence of the commit message would make this
> >> clear enough.
> >
> > That was clear, but the fix part wasn't really.
> >
> >> I can expand the commit message to go more into detail if you think
> >> this is really needed.
> >
> > IMO calling acpi_set_waking_vector() with a known-invalid wakeup
> > vector address in dom0 is plain confusing.
> >
> > I'm not sure what to do about it yet, but IMV something needs to be done.
>
> Another possibility would be to modify acpi_sleep_prepare(), e.g. like the
> attached patch (compile tested only).

I prefer this to the previous version.  It is much more straightforward IMV.

Re: [PATCH] x86/acpi: fix suspend with Xen

[Juergen Gross]

On 17.01.23 15:09, Rafael J. Wysocki wrote:

On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross  wrote:


On 13.01.23 20:40, Rafael J. Wysocki wrote:

On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross  wrote:


Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
Xen PV guest") missed one code path accessing real_mode_header, leading
to dereferencing NULL when suspending the system under Xen:

  [  348.284004] PM: suspend entry (deep)
  [  348.289532] Filesystems sync: 0.005 seconds
  [  348.291545] Freezing user space processes ... (elapsed 0.000 seconds) 
done.
  [  348.292457] OOM killer disabled.
  [  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 
seconds) done.
  [  348.396612] printk: Suspending console(s) (use no_console_suspend to 
debug)
  [  348.749228] PM: suspend devices took 0.352 seconds
  [  348.769713] ACPI: EC: interrupt blocked
  [  348.816077] BUG: kernel NULL pointer dereference, address: 
001c
  [  348.816080] #PF: supervisor read access in kernel mode
  [  348.816081] #PF: error_code(0x) - not-present page
  [  348.816083] PGD 0 P4D 0
  [  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
  [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
6.1.3-1.fc32.qubes.x86_64 #1
  [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 
07/03/2022
  [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20

Fix that by adding an indirection for acpi_get_wakeup_address() which
Xen PV dom0 can use to return a dummy non-zero wakeup address (this
address won't ever be used, as the real suspend handling is done by the
hypervisor).


How exactly does this help?


I believed the first sentence of the commit message would make this
clear enough.


That was clear, but the fix part wasn't really.


I can expand the commit message to go more into detail if you think
this is really needed.


IMO calling acpi_set_waking_vector() with a known-invalid wakeup
vector address in dom0 is plain confusing.

I'm not sure what to do about it yet, but IMV something needs to be done.


Another possibility would be to modify acpi_sleep_prepare(), e.g. like the
attached patch (compile tested only).


Juergen
From 5a2de7250c4e8782ed89c7898061815058fa2710 Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Tue, 17 Jan 2023 16:20:04 +0100
Subject: [PATCH] acpi: fix suspend with Xen PV
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
Xen PV guest") missed one code path accessing real_mode_header, leading
to dereferencing NULL when suspending the system under Xen:

[  348.284004] PM: suspend entry (deep)
[  348.289532] Filesystems sync: 0.005 seconds
[  348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done.
[  348.292457] OOM killer disabled.
[  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done.
[  348.396612] printk: Suspending console(s) (use no_console_suspend to debug)
[  348.749228] PM: suspend devices took 0.352 seconds
[  348.769713] ACPI: EC: interrupt blocked
[  348.816077] BUG: kernel NULL pointer dereference, address: 001c
[  348.816080] #PF: supervisor read access in kernel mode
[  348.816081] #PF: error_code(0x) - not-present page
[  348.816083] PGD 0 P4D 0
[  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
[  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1
[  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022
[  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20

Fix that by adding an optional acpi callback allowing to skip setting
the wakeup address, as in the Xen PV case this will be handled by the
hypervisor anyway.

Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest")
Reported-by: Marek Marczykowski-Górecki 
Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/acpi.h | 8 
 drivers/acpi/sleep.c| 6 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 65064d9f7fa6..8eb74cf386db 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_ACPI_APEI
 # include 
@@ -63,6 +64,13 @@ extern int (*acpi_suspend_lowlevel)(void);
 /* Physical address to resume after wakeup */
 unsigned long acpi_get_wakeup_address(void);
 
+static inline bool acpi_skip_set_wakeup_address(void)
+{
+	return cpu_feature_enabled(X86_FEATURE_XENPV);
+}
+
+#define acpi_skip_set_wakeup_address acpi_skip_set_wakeup_address
+
 /*
  * Check if the CPU can handle C2 and deeper
  */
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 0b557c0d405e..4ca667251272 100644
--- 

[ovmf test] 175935: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 a107ad0f623669c72997443dc0431eeb732f81a0
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z4 days
Failing since175860  2023-01-15 07:11:07 Z2 days   28 attempts
Testing same since   175935  2023-01-17 14:42:05 Z0 days1 attempts


People who touched revisions under test:
  Abner Chang 
  Ard Biesheuvel 
  Gerd Hoffmann 
  Jiangang He 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 

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 323 lines long.)

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

[Chuck Zmudzinski]

On 1/17/2023 5:35 AM, Igor Mammedov wrote:
> On Mon, 16 Jan 2023 13:00:53 -0500
> Chuck Zmudzinski  wrote:
>
> > On 1/16/23 10:33, Igor Mammedov wrote:
> > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > Chuck Zmudzinski  wrote:
> > >   
> > >> On 1/13/23 4:33 AM, Igor Mammedov wrote:  
> > >> > On Thu, 12 Jan 2023 23:14:26 -0500
> > >> > Chuck Zmudzinski  wrote:
> > >> > 
> > >> >> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:
> > >> >> > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote:   
> > >> >> >
> > >> >> >> I think the change Michael suggests is very minimalistic: Move the 
> > >> >> >> if
> > >> >> >> condition around xen_igd_reserve_slot() into the function itself 
> > >> >> >> and
> > >> >> >> always call it there unconditionally -- basically turning three 
> > >> >> >> lines
> > >> >> >> into one. Since xen_igd_reserve_slot() seems very problem specific,
> > >> >> >> Michael further suggests to rename it to something more general. 
> > >> >> >> All
> > >> >> >> in all no big changes required.  
> > >> >> > 
> > >> >> > yes, exactly.
> > >> >> >   
> > >> >> 
> > >> >> OK, got it. I can do that along with the other suggestions.
> > >> > 
> > >> > have you considered instead of reservation, putting a slot check in 
> > >> > device model
> > >> > and if it's intel igd being passed through, fail at realize time  if 
> > >> > it can't take
> > >> > required slot (with a error directing user to fix command line)?
> > >> 
> > >> Yes, but the core pci code currently already fails at realize time
> > >> with a useful error message if the user tries to use slot 2 for the
> > >> igd, because of the xen platform device which has slot 2. The user
> > >> can fix this without patching qemu, but having the user fix it on
> > >> the command line is not the best way to solve the problem, primarily
> > >> because the user would need to hotplug the xen platform device via a
> > >> command line option instead of having the xen platform device added by
> > >> pc_xen_hvm_init functions almost immediately after creating the pci
> > >> bus, and that delay in adding the xen platform device degrades
> > >> startup performance of the guest.
> > >>   
> > >> > That could be less complicated than dealing with slot reservations at 
> > >> > the cost of
> > >> > being less convenient.
> > >> 
> > >> And also a cost of reduced startup performance  
> > > 
> > > Could you clarify how it affects performance (and how much).
> > > (as I see, setup done at board_init time is roughly the same
> > > as with '-device foo' CLI options, modulo time needed to parse
> > > options which should be negligible. and both ways are done before
> > > guest runs)  
> > 
> > I preface my answer by saying there is a v9, but you don't
> > need to look at that. I will answer all your questions here.
> > 
> > I am going by what I observe on the main HDMI display with the
> > different approaches. With the approach of not patching Qemu
> > to fix this, which requires adding the Xen platform device a
> > little later, the length of time it takes to fully load the
> > guest is increased. I also noticed with Linux guests that use
> > the grub bootoader, the grub vga driver cannot display the
> > grub boot menu at the native resolution of the display, which
> > in the tested case is 1920x1080, when the Xen platform device
> > is added via a command line option instead of by the
> > pc_xen_hvm_init_pci fucntion in pc_piix.c, but with this patch
> > to Qemu, the grub menu is displayed at the full, 1920x1080
> > native resolution of the display. Once the guest fully loads,
> > there is no noticeable difference in performance. It is mainly
> > a degradation in startup performance, not performance once
> > the guest OS is fully loaded.
> above hints on presence of bug[s] in igd-passthru implementation,
> and this patch effectively hides problem instead of trying to figure
> out what's wrong and fixing it.
>

I agree that the with the current Qemu there is a bug in the igd-passthru
implementation. My proposed patch fixes it. So why not support the
proposed patch with a Reviewed-by tag?

Re: [PATCH v8] xen/pt: reserve PCI slot 2 for Intel igd-passthru

[Chuck Zmudzinski]

On 1/17/2023 5:35 AM, Igor Mammedov wrote:
> On Mon, 16 Jan 2023 13:00:53 -0500
> Chuck Zmudzinski  wrote:
>
> > On 1/16/23 10:33, Igor Mammedov wrote:
> > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > Chuck Zmudzinski  wrote:
> > >   
> > >> On 1/13/23 4:33 AM, Igor Mammedov wrote:  
> > >> > On Thu, 12 Jan 2023 23:14:26 -0500
> > >> > Chuck Zmudzinski  wrote:
> > >> > 
> > >> >> On 1/12/23 6:03 PM, Michael S. Tsirkin wrote:
> > >> >> > On Thu, Jan 12, 2023 at 10:55:25PM +, Bernhard Beschow wrote:   
> > >> >> >
> > >> >> >> I think the change Michael suggests is very minimalistic: Move the 
> > >> >> >> if
> > >> >> >> condition around xen_igd_reserve_slot() into the function itself 
> > >> >> >> and
> > >> >> >> always call it there unconditionally -- basically turning three 
> > >> >> >> lines
> > >> >> >> into one. Since xen_igd_reserve_slot() seems very problem specific,
> > >> >> >> Michael further suggests to rename it to something more general. 
> > >> >> >> All
> > >> >> >> in all no big changes required.  
> > >> >> > 
> > >> >> > yes, exactly.
> > >> >> >   
> > >> >> 
> > >> >> OK, got it. I can do that along with the other suggestions.
> > >> > 
> > >> > have you considered instead of reservation, putting a slot check in 
> > >> > device model
> > >> > and if it's intel igd being passed through, fail at realize time  if 
> > >> > it can't take
> > >> > required slot (with a error directing user to fix command line)?
> > >> 
> > >> Yes, but the core pci code currently already fails at realize time
> > >> with a useful error message if the user tries to use slot 2 for the
> > >> igd, because of the xen platform device which has slot 2. The user
> > >> can fix this without patching qemu, but having the user fix it on
> > >> the command line is not the best way to solve the problem, primarily
> > >> because the user would need to hotplug the xen platform device via a
> > >> command line option instead of having the xen platform device added by
> > >> pc_xen_hvm_init functions almost immediately after creating the pci
> > >> bus, and that delay in adding the xen platform device degrades
> > >> startup performance of the guest.
> > >>   
> > >> > That could be less complicated than dealing with slot reservations at 
> > >> > the cost of
> > >> > being less convenient.
> > >> 
> > >> And also a cost of reduced startup performance  
> > > 
> > > Could you clarify how it affects performance (and how much).
> > > (as I see, setup done at board_init time is roughly the same
> > > as with '-device foo' CLI options, modulo time needed to parse
> > > options which should be negligible. and both ways are done before
> > > guest runs)  
> > 
> > I preface my answer by saying there is a v9, but you don't
> > need to look at that. I will answer all your questions here.
> > 
> > I am going by what I observe on the main HDMI display with the
> > different approaches. With the approach of not patching Qemu
> > to fix this, which requires adding the Xen platform device a
> > little later, the length of time it takes to fully load the
> > guest is increased. I also noticed with Linux guests that use
> > the grub bootoader, the grub vga driver cannot display the
> > grub boot menu at the native resolution of the display, which
> > in the tested case is 1920x1080, when the Xen platform device
> > is added via a command line option instead of by the
> > pc_xen_hvm_init_pci fucntion in pc_piix.c, but with this patch
> > to Qemu, the grub menu is displayed at the full, 1920x1080
> > native resolution of the display. Once the guest fully loads,
> > there is no noticeable difference in performance. It is mainly
> > a degradation in startup performance, not performance once
> > the guest OS is fully loaded.
> above hints on presence of bug[s] in igd-passthru implementation,
> and this patch effectively hides problem instead of trying to figure
> out what's wrong and fixing it.
>

Why did you delete the rest of my answers to your other observations and
not respond to them?

Re: AW: Xenalyze on ARM ( NXP S32G3 with Cortex-A53)

[Julien Grall]

On 13/01/2023 12:56, El Mesdadi Youssef ESK UILD7 wrote:

Hello Julien,


Hi,


xentrace should work on upstream Xen. What did you version did you try?


While building my image using the BSP-linux of NXP, the version that was 
downloaded is Xen 4.14.


Do you know where the source are downloaded from?





Can you also clarify the error you are seen?


The error I receive while tipping xentrace is: Command not found.



"Command not found" means the program hasn't been installed.


I assume in this Xen version, Xentrace is not compatible with ARM architecture
The support for xentrace on Arm has been added around Xen 4.12. So it 
should work for Xen 4.14 (even though I don't recommend using older 
release).


I would suggest to check how you are building the tools and which 
package will be installed.




My question is, is there any new version of Xen that supports Xentrace on ARM? If yes how 
could I install it? Because Xen.4.14 was installed automatically by typing this ( 
DISTRO_FEATURES_append += "xen") in the local.conf file while creating my image.


I am not familiar with the BSP-linux of NXP as this is not a project 
maintained by Xen Project.


If you need support for it, then I would suggest to discuss with NXP 
directly.




Or is there any source on Xentrace that is compatible with ARM on GitHub, that 
I could download and compile myself?
Even if the hypervisor is Xen, you seem to use code provided by an 
external entity. I can't advise on the next steps without knowing the 
modification that NXP made in the hypervisor.





Yes if you assign (or provide para-virtualized driver) the 
GPIO/LED/Can-Interface to the guest.


Is there any tutorial that could help me create those drivers? And how 
complicated is that, to create them?


I am not aware of any tutorial. Regarding the complexity, it all depends 
on what exactly you want to do.



Or can they be assigned just with PCI-Passthrough?


PCI passthrough is not yet supported on Arm. That said, I was not 
expecting the GPIO/LED/Can-interface to be PCI devices.


If they are platform devices (i.e non-PCI devices), then you could 
potentially directly assign them to *one* guest (this would not work if 
you need to share them).


I wrote potentially because if the device is DMA-capabable, then the 
device must be behind an IOMMU.


Cheers,

--
Julien Grall

[ovmf test] 175934: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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 d05739a3ff88457ae3ce90db3e91e9d2a11949c8
baseline version:
 ovmf 9d70d8f20d0feee1d232cbf86fc87147ce92c2cb

Last test of basis   175747  2023-01-12 16:10:44 Z4 days
Failing since175860  2023-01-15 07:11:07 Z2 days   27 attempts
Testing same since   175934  2023-01-17 13:40:59 Z0 days1 attempts


People who touched revisions under test:
  Abner Chang 
  Gerd Hoffmann 
  Jiangang He 
  Konstantin Aladyshev 
  Min M Xu 
  Min Xu 

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.


commit d05739a3ff88457ae3ce90db3e91e9d2a11949c8
Author: Konstantin Aladyshev 
Date:   Wed Dec 14 00:22:22 2022 +0800

Fix cyclic dependency error on OptionROM build

EDKII build system supports OptionROM generation if particular PCI_*
defines are present in the module INF file:
```
[Defines]
  ...
  PCI_VENDOR_ID  = <...>
  PCI_DEVICE_ID  = <...>
  PCI_CLASS_CODE = <...>
  PCI_REVISION   = <...>
```
Although after the commit d372ab585a2cdc5348af5f701c56c631235fe698
("BaseTools/Conf: Fix Dynamic-Library-File template") it is no longer
possible.
The build system fails with the error:
```
Cyclic dependency detected while generating rule for
"<...>/DEBUG/<...>.efi" file
```
Remove "$(DEBUG_DIR)(+)$(MODULE_NAME).efi" from the 'dll' output files
to fix the cyclic dependency.

Signed-off-by: Konstantin Aladyshev 
Reviewed-by: Bob Feng 

commit 987cc09c7cf38d628063062483e2341fba679b0e
Author: Gerd Hoffmann 
Date:   Mon Jan 16 10:46:39 2023 +0100

ArmVirt: don't use unaligned CopyMem () on NOR flash

Commit 789a72328553 reclassified the NOR flash region as EFI_MEMORY_WC
in the OS visible EFI memory map, and dropped the explicit aligned
CopyMem() implementation, in the assumption that EFI_MEMORY_WC will be
honored by the OS, and that the region will be mapped in a way that
tolerates misaligned accesseses. However, Linux today uses device
attributes for all EFI MMIO regions, in spite of the memory type
attributes, and so using misaligned accesses is never safe.

So instead, switch to the generic CopyMem() implementation entirely,
just like we already did for VariableRuntimeDxe.

Fixes: 789a72328553 ("OvmfPkg/VirtNorFlashDxe: use EFI_MEMORY_WC and drop 
AlignedCopyMem()")
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Ard Biesheuvel 

commit 47ab397011b6d1ce4d5805117dc87d9e35f378db
Author: Abner Chang 
Date:   Wed Jan 11 11:10:08 2023 +0800

MdeModulePkg/XhciPei: Unlinked XhciPei memory block

Unlink the XhciPei 

Re: Xentrace and Xenalyze on ARM S32G3

[Julien Grall]

On 17/01/2023 14:17, El Mesdadi Youssef ESK UILD7 wrote:

Hello everyone,


Hi,


My name is Youssef, I am an electrical Eng. student and right now I'm working 
on my thesis using Xen hypervisor on an S32G3 microprocessor (ARM 
architecture). After building my Yocto-Image using the Linux-BSP of the 
microprocessor, I noticed that Xentrace and Xenalyze are not working because 
they are not compatible with ARM architecture. I have found on Xen.markmail.org 
that you have already done this, I tried to understand the changes that Mr. ben 
and Paul did, but I could not understand them. I wish you can help me with that 
by sending me the repo.


You already asked the question in a separate thread. If you don't get 
answer there, then it would be better to "ping" on the other thread.


This will avoid duplication on the ML. I will answer on the other thread 
soon.


Cheers,

--
Julien Grall

Xentrace and Xenalyze on ARM S32G3

[El Mesdadi Youssef ESK UILD7]

Hello everyone,

My name is Youssef, I am an electrical Eng. student and right now I'm working 
on my thesis using Xen hypervisor on an S32G3 microprocessor (ARM 
architecture). After building my Yocto-Image using the Linux-BSP of the 
microprocessor, I noticed that Xentrace and Xenalyze are not working because 
they are not compatible with ARM architecture. I have found on Xen.markmail.org 
that you have already done this, I tried to understand the changes that Mr. ben 
and Paul did, but I could not understand them. I wish you can help me with that 
by sending me the repo.

If you have any more information that could help me to enable Xenalyze and 
Xentrace, I would appreciate it.

The Xen version I am using is Xen 1.14. ( this was downloaded automatically by 
giving this in the local.conf file DISTRO_FEATURES_append += "xen" ).

Thank you so much In Advance.

Cheers
Youssef

Re: [PATCH] x86/acpi: fix suspend with Xen

[Rafael J. Wysocki]

On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross  wrote:
>
> On 13.01.23 20:40, Rafael J. Wysocki wrote:
> > On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross  wrote:
> >>
> >> Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> >> Xen PV guest") missed one code path accessing real_mode_header, leading
> >> to dereferencing NULL when suspending the system under Xen:
> >>
> >>  [  348.284004] PM: suspend entry (deep)
> >>  [  348.289532] Filesystems sync: 0.005 seconds
> >>  [  348.291545] Freezing user space processes ... (elapsed 0.000 
> >> seconds) done.
> >>  [  348.292457] OOM killer disabled.
> >>  [  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 
> >> seconds) done.
> >>  [  348.396612] printk: Suspending console(s) (use no_console_suspend 
> >> to debug)
> >>  [  348.749228] PM: suspend devices took 0.352 seconds
> >>  [  348.769713] ACPI: EC: interrupt blocked
> >>  [  348.816077] BUG: kernel NULL pointer dereference, address: 
> >> 001c
> >>  [  348.816080] #PF: supervisor read access in kernel mode
> >>  [  348.816081] #PF: error_code(0x) - not-present page
> >>  [  348.816083] PGD 0 P4D 0
> >>  [  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
> >>  [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
> >> 6.1.3-1.fc32.qubes.x86_64 #1
> >>  [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 
> >> 07/03/2022
> >>  [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20
> >>
> >> Fix that by adding an indirection for acpi_get_wakeup_address() which
> >> Xen PV dom0 can use to return a dummy non-zero wakeup address (this
> >> address won't ever be used, as the real suspend handling is done by the
> >> hypervisor).
> >
> > How exactly does this help?
>
> I believed the first sentence of the commit message would make this
> clear enough.

That was clear, but the fix part wasn't really.

> I can expand the commit message to go more into detail if you think
> this is really needed.

IMO calling acpi_set_waking_vector() with a known-invalid wakeup
vector address in dom0 is plain confusing.

I'm not sure what to do about it yet, but IMV something needs to be done.

[xen-unstable-smoke test] 175930: regressions - trouble: blocked/broken

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-arm64-xsm  broken
 build-armhf  broken
 build-armhf   4 host-install(4)broken REGR. vs. 175746
 build-amd64   5 host-build-prep  fail REGR. vs. 175746
 build-arm64-xsm   5 host-build-prep  fail REGR. vs. 175746

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

version targeted for testing:
 xen  f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
baseline version:
 xen  6bec713f871f21c6254a5783c1e39867ea828256

Last test of basis   175746  2023-01-12 16:03:41 Z4 days
Failing since175748  2023-01-12 20:01:56 Z4 days   21 attempts
Testing same since   175833  2023-01-14 07:00:25 Z3 days   19 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 
  Michal Orzel 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  broken  
 build-amd64  broken  
 build-armhf  broken  
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-amd64-libvirt 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

broken-job build-amd64 broken
broken-job build-arm64-xsm broken
broken-job build-armhf broken
broken-step build-armhf host-install(4)

Not pushing.


commit f588e7b7cb70800533aaa8a2a9d7a4b32d10b363
Author: Michal Orzel 
Date:   Tue Jan 3 11:25:19 2023 +0100

xen/arm: Add 0x prefix when printing memory size in construct_domU

Printing memory size in hex without 0x prefix can be misleading, so
add it. Also, take the opportunity to adhere to 80 chars line length
limit by moving the printk arguments to the next line.

Signed-off-by: Michal Orzel 
Reviewed-by: Ayan Kumar Halder 
Acked-by: Julien Grall 

commit 229ebd517b9df0e2d2f9e3ea50b57ca716334826
Author: Julien Grall 
Date:   Thu Jan 12 22:07:42 2023 +

xen/arm: linker: The identitymap check should cover the whole .text.header

At the moment, we are only checking that only some part of .text.header
is part of the identity mapping. However, this doesn't take into account
the literal pool which will be located at the end of the section.

While we could try to avoid using a literal pool, in the near future we
will also want to use an identity mapping for switch_ttbr().

Not everything in .text.header requires to be part of the identity
mapping. But it is below a page size (i.e. 4KB) so take a shortcut and
check that .text.header is smaller than a page size.

With that _end_boot can be removed as it is now unused. Take the
opportunity to avoid assuming that a page size is always 4KB in the
error message and comment.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit 22a9981ba2443bd569bad6b772fb6e7e64f0d714
Author: Julien Grall 
Date:   Thu Jan 12 22:06:42 2023 +

xen/arm: linker: Indent correctly _stext

_stext is indented by one space more compare to the lines. This doesn't
seem warrant, so delete the extra space.

Signed-off: Julien Grall 
Acked-by: Stefano Stabellini 

commit 3edca52ce736297d7fcf293860cd94ef62638052
Author: Andrew Cooper 
Date:   Mon Jan 9 10:58:31 2023 +

x86/vmx: Support for CPUs without model-specific 

Re: [PATCH v3 08/17] tools/xenstore: don't allow creating too many nodes in a transaction

[Julien Grall]

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

The accounting for the number of nodes of a domain in an active
transaction is not working correctly, as it allows to create arbitrary
number of nodes. The transaction will finally fail due to exceeding
the number of nodes quota, but before closing the transaction an
unprivileged guest could cause Xenstore to use a lot of memory.

Signed-off-by: Juergen Gross 


Is the rest of the series depend on this patch? I am asking this because 
I still need to go through your second series before forging an opinion 
on this patch.


Yet, I would like to reduce the number of inflight patches :).

Cheers,


---
  tools/xenstore/xenstored_domain.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c 
b/tools/xenstore/xenstored_domain.c
index edfe5809be..07d91eb50c 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -1129,9 +1129,8 @@ int domain_nbentry_fix(unsigned int domid, int num, bool 
update)
  
  int domain_nbentry(struct connection *conn)

  {
-   return (domain_is_unprivileged(conn))
-   ? conn->domain->nbentry
-   : 0;
+   return domain_is_unprivileged(conn)
+  ? domain_nbentry_add(conn, conn->id, 0, true) : 0;
  }
  
  static bool domain_chk_quota(struct domain *domain, int mem)


--
Julien Grall

Re: [PATCH v3 06/17] tools/xenstore: move changed domain handling

[Julien Grall]

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

Move all code related to struct changed_domain from
xenstored_transaction.c to xenstored_domain.c.

This will be needed later in order to simplify the accounting data
updates in cases of errors during a request.

Split the code to have a more generic base framework.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v3 05/17] tools/xenstore: replace watch->relative_path with a prefix length

[Julien Grall]

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

Instead of storing a pointer to the path which is prepended to
relative paths in struct watch, just use the length of the prepended
path.

It should be noted that the now removed special case of the
relative path being "" in get_watch_path() can't happen at all.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

Re: [PATCH v3 04/17] tools/xenstore: introduce dummy nodes for special watch paths

[Julien Grall]

Hi Juergen,

On 17/01/2023 09:11, Juergen Gross wrote:

+static void fire_special_watches(const char *name)
+{
+   void *ctx = talloc_new(NULL);
+   struct node *node;
+
+   if (!ctx)
+   return;
+
+   node = read_node(NULL, ctx, name);
+
+   if (node)
+   fire_watches(NULL, ctx, name, node, true, NULL);
+   else
+   syslog(LOG_ERR, "special node %s not found\n", name);


NIT: How about using log() so it is also printed in the trace log? This 
would be handy to avoid having to check multiple log files.


With or without:

Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall