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

[Jan Beulich]

On 12.07.2023 21:38, Jason Andryuk wrote:
> I think I just prefer the ';' separator and letting "verbose" be
> weird.  It maps well into the existing syntax and I liked it when you
> first suggested it.

Well, okay, then let's stick to that, emphasizing the weirdness in doc.

Jan

Re: [XEN PATCH v9 02/24] xen/arm: add TEE teardown to arch_domain_teardown()

[Jens Wiklander]

Hi,

On Wed, Jul 12, 2023 at 10:31 AM Andrew Cooper
 wrote:
>
> On 05/07/2023 10:34 am, Jens Wiklander wrote:
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 15d9709a97d2..18171decdc66 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -795,6 +795,42 @@ fail:
> >
> >  int arch_domain_teardown(struct domain *d)
> >  {
> > +int ret = 0;
> > +
> > +BUG_ON(!d->is_dying);
> > +
> > +/* See domain_teardown() for an explanation of all of this magic. */
> > +switch ( d->teardown.arch_val )
> > +{
> > +#define PROGRESS(x) \
> > +d->teardown.arch_val = PROG_ ## x;  \
> > +fallthrough;\
> > +case PROG_ ## x
> > +
> > +enum {
> > +PROG_none,
> > +PROG_tee,
> > +PROG_done,
> > +};
> > +
> > +case PROG_none:
> > +BUILD_BUG_ON(PROG_none != 0);
> > +
> > +PROGRESS(tee):
> > +ret = tee_domain_teardown(d);
> > +if ( ret )
> > +return ret;
> > +break;
>
> This unconditional break isn't correct.
>
> The logic functions right now (because upon hitting return 0, you don't
> re-enter this function), but will cease working when you add a new
> PROG_*, or when the calling code gets more complicated.
>
> > +
> > +PROGRESS(done):
> > +break;
>
> This needs to be the only break in the switch statement, for it to
> behave in the intended manner.

Got it, thanks for the explanation. I'll fix it in the next version.

Thanks,
Jens

>
> ~Andrew

Re: [PATCH v3 35/52] xen/arm: map static memory on demand

[Penny Zheng]

Hi Ayan

On 2023/7/5 21:33, Ayan Kumar Halder wrote:


On 05/07/2023 11:16, Penny Zheng wrote:

Hi Ayan

Hi Penny,


On 2023/7/4 23:10, Ayan Kumar Halder wrote:

Hi Penny,

On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please 
use proper judgment and caution when opening attachments, clicking 
links, or responding to this email.



In function init_staticmem_pages, we need the access to static memory
for proper initialization.
It is not a problem in MMU system, as Xen map the whole RAM in
setup_mm(). However, with limited MPU memory regions, it is too luxury
to map the whole RAM.
As a result, we follow the rule of "map on demand", to map static 
memory

temporarily before its initialization, and unmap immediately after its
initialization.


I could see that you are using _PAGE_TRANSIENT  to map memory 
temporarily. However, I don't see this being translated to any of the 
MPU hardware features (ie _PAGE_TRANSIENT does not seem to translate 
to any of the attributes in PRBAR, PRLAR, PRENR, etc). Thus, how is 
it different from mapping the memory in "non temporary" way ?




It is only software feature.
It is designed for implementing functions like ioremap_xxx(), or 
map_staticmem_pages_to_xen() here, which are always occuring with its 
reverse unmapping function nearby like iounmap(), or 
unmap_staticmem_pages_to_xen(), to map a chunk of memory 
*temporarily*, for a very short time.
I understand that it is a software only feature. But why does the 
software need to know if the memory is mapped temporarily or not ? What 
difference does it make ?


See this pair map_domain_page()/unmap_domain_page(), which is used to 
map/unmap page of guest RAM. vcpu in different mode is facing different 
scenario.


Taking usage in copy_guest() as example:
When vcpu in guest mode trying to access its own memory(e.g. copy
hypercall param), there is no need to do the mapping/unmapping in MPU,
as page is already mapped at both EL1/EL2. Checking if it is transient
region in unmap_domain_page() is definitely necessary to help avoid 
unmapping it here.

When vcpu in hypervisor mode at boot time copying kernel image to guest
memory, we need to map page as transient MPU region to do the copying 
and pasting.


I want to check this flag in the unmapping function, to ensure that we 
are unmapping the proper MPU region.


I had a look at unmap_staticmem_pages_to_xen() --> xen_mpumap_update() 
--> control_mpu_region_from_index() and I don't see this flag used 
anywhere.

>

- Ayan



Fixed MPU regions are like Xen text section, Xen data section, etc.


Please let me know what I am missing.

- Ayan



Signed-off-by: Penny Zheng 
Signed-off-by: Wei Chen 
---
v3:
- new commit
---
  xen/arch/arm/include/asm/mm.h |  2 ++
  xen/arch/arm/mmu/mm.c | 10 ++
  xen/arch/arm/mpu/mm.c | 10 ++
  xen/arch/arm/setup.c  | 21 +
  4 files changed, 43 insertions(+)

diff --git a/xen/arch/arm/include/asm/mm.h 
b/xen/arch/arm/include/asm/mm.h

index 66d98b9a29..cffbf8a595 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -224,6 +224,8 @@ extern void mm_init_secondary_cpu(void);
  extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
  /* map a physical range in virtual memory */
  void __iomem *ioremap_attr(paddr_t start, size_t len, unsigned int 
attributes);

+extern int map_staticmem_pages_to_xen(paddr_t start, paddr_t end);
+extern int unmap_staticmem_pages_to_xen(paddr_t start, paddr_t end);

  static inline void __iomem *ioremap_nocache(paddr_t start, size_t 
len)

  {
diff --git a/xen/arch/arm/mmu/mm.c b/xen/arch/arm/mmu/mm.c
index 2f29cb53fe..4196a55c32 100644
--- a/xen/arch/arm/mmu/mm.c
+++ b/xen/arch/arm/mmu/mm.c
@@ -1113,6 +1113,16 @@ int populate_pt_range(unsigned long virt, 
unsigned long nr_mfns)

  return xen_pt_update(virt, INVALID_MFN, nr_mfns, _PAGE_POPULATE);
  }

+int __init map_staticmem_pages_to_xen(paddr_t start, paddr_t end)
+{
+    return 0;
+}
+
+int __init unmap_staticmem_pages_to_xen(paddr_t start, paddr_t end)
+{
+    return 0;
+}
+
  /*
   * Local variables:
   * mode: C
diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
index a40055ae5e..9d5c1da39c 100644
--- a/xen/arch/arm/mpu/mm.c
+++ b/xen/arch/arm/mpu/mm.c
@@ -614,6 +614,16 @@ void __init setup_frametable_mappings(paddr_t 
ps, paddr_t pe)

 frametable_size - (nr_pdxs * sizeof(struct page_info)));
  }

+int __init map_staticmem_pages_to_xen(paddr_t start, paddr_t end)
+{
+    return xen_mpumap_update(start, end, PAGE_HYPERVISOR | 
_PAGE_TRANSIENT);

+}
+
+int __init unmap_staticmem_pages_to_xen(paddr_t start, paddr_t end)
+{
+    return xen_mpumap_update(start, end, 0);
+}
+
  /*
   * Local variables:
   * mode: C
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f42b53d17b..c21d1db763 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -637,12 +637,33 @@ void __init in

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Luben Tuikov]

On 2023-07-12 09:53, Christian König wrote:
> Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
>> Hello Maxime,
>>
>> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
>>> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> Background is that this makes merge conflicts easier to handle and detect.
 Really?
>>> FWIW, I agree with Christian here.
>>>
 Each file (apart from include/drm/drm_crtc.h) is only touched once. So
 unless I'm missing something you don't get less or easier conflicts by
 doing it all in a single patch. But you gain the freedom to drop a
 patch for one driver without having to drop the rest with it.
>>> Not really, because the last patch removed the union anyway. So you have
>>> to revert both the last patch, plus that driver one. And then you need
>>> to add a TODO to remove that union eventually.
>> Yes, with a single patch you have only one revert (but 194 files changed,
>> 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1
>> file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit
>> bigger). (And maybe you get away with just reverting the last patch.)
>>
>> With a single patch the TODO after a revert is "redo it all again (and
>> prepare for a different set of conflicts)" while with the split series
>> it's only "fix that one driver that was forgotten/borked" + reapply that
>> 10 line patch.
> 
> Yeah, but for a maintainer the size of the patches doesn't matter. 
> That's only interesting if you need to manually review the patch, which 
> you hopefully doesn't do in case of something auto-generated.
> 
> In other words if the patch is auto-generated re-applying it completely 
> is less work than fixing things up individually.
> 
>>   As the one who gets that TODO, I prefer the latter.
> 
> Yeah, but your personal preferences are not a technical relevant 
> argument to a maintainer.
> 
> At the end of the day Dave or Daniel need to decide, because they need 
> to live with it.
> 
> Regards,
> Christian.
> 
>>
>> So in sum: If your metric is "small count of reverted commits", you're
>> right. If however your metric is: Better get 95% of this series' change
>> in than maybe 0%, the split series is the way to do it.
>>
>> With me having spend ~3h on this series' changes, it's maybe
>> understandable that I did it the way I did.
>>
>> FTR: This series was created on top of v6.5-rc1. If you apply it to
>> drm-misc-next you get a (trivial) conflict in patch #2. If I consider to
>> be the responsible maintainer who applies this series, I like being able
>> to just do git am --skip then.
>>
>> FTR#2: In drm-misc-next is a new driver
>> (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for
>> now might indeed be a good idea.
>>
 So I still like the split version better, but I'm open to a more
 verbose reasoning from your side.
>>> You're doing only one thing here, really: you change the name of a
>>> structure field. If it was shared between multiple maintainers, then
>>> sure, splitting that up is easier for everyone, but this will go through
>>> drm-misc, so I can't see the benefit it brings.
>> I see your argument, but I think mine weights more.

I'm with Maxime and Christian on this--a single action necessitates a single 
patch.
One single movement. As Maxime said "either 0 or 100."

As to the name, perhaps "drm_dev" is more descriptive than just "drm".
What is "drm"? Ah it's a "dev", as in "drm dev"... Then why not rename it
to "drm_dev"? You are renaming it from "dev" to something more descriptive
after all. "dev" --> "drm" is no better, but "dev" --> "drm_dev" is just
right.
-- 
Regards,
Luben

Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Krzysztof Kozlowski]

On 12/07/2023 20:31, Sean Paul wrote:
>>> 216 struct drm_device *ddev
>>> 234 struct drm_device *drm_dev
>>> 611 struct drm_device *drm
>>>4190 struct drm_device *dev
>>>
>>> This series starts with renaming struct drm_crtc::dev to drm_dev. If
>>> it's not only me and others like the result of this effort it should be
>>> followed up by adapting the other structs and the individual usages in
>>> the different drivers.
>>
>> I think this is an unnecessary change. In drm, a dev is usually a drm
>> device, i.e. struct drm_device *. As shown by the numbers above.
>>
> 
> I'd really prefer this patch (series or single) is not accepted. This
> will cause problems for everyone cherry-picking patches to a
> downstream kernel (LTS or distro tree). I usually wouldn't expect
> sympathy here, but the questionable benefit does not outweigh the cost
> IM[biased]O.

You know, every code cleanup and style adjustment is interfering with
backporting. The only argument for a fast-pacing kernel should be
whether the developers of this code find it more readable with such cleanup.

Best regards,
Krzysztof

Re: [PATCH v3 31/52] xen/mpu: make early_fdt_map support in MPU systems

[Penny Zheng]

Hi Julien

On 2023/7/3 17:20, Julien Grall wrote:

Hi,

On 03/07/2023 06:12, Penny Zheng wrote:

Hi,


On 2023/6/30 23:02, Julien Grall wrote:

Hi,

On 30/06/2023 15:42, Ayan Kumar Halder wrote:

Hi Julien,

On 30/06/2023 12:22, Julien Grall wrote:



On 30/06/2023 11:49, Ayan Kumar Halder wrote:


On 30/06/2023 05:07, Penny Zheng wrote:

Hi,

Hi Penny,



On 2023/6/30 01:22, Ayan Kumar Halder wrote:


On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. 
Please use proper judgment and caution when opening 
attachments, clicking links, or responding to this email.



In MPU system, MPU memory region is always mapped PAGE_ALIGN, 
so in order to
not access unexpected memory area, dtb section in xen.lds.S 
should be made

page-aligned too.
We add . = ALIGN(PAGE_SIZE); in the head of dtb section to make 
it happen.


In this commit, we map early FDT with a transient MPU memory 
region, as

it will be relocated into heap and unmapped at the end of boot.

Signed-off-by: Penny Zheng 
Signed-off-by: Wei Chen 
---
v3:
- map the first 2MB. Check the size and then re-map with an 
extra 2MB if needed

---
  xen/arch/arm/include/asm/arm64/mpu.h |  3 ++-
  xen/arch/arm/include/asm/page.h  |  5 +
  xen/arch/arm/mm.c    | 26 
--

  xen/arch/arm/mpu/mm.c    |  1 +
  xen/arch/arm/xen.lds.S   |  5 -
  5 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/include/asm/arm64/mpu.h 
b/xen/arch/arm/include/asm/arm64/mpu.h

index a6b07bab02..715ea69884 100644
--- a/xen/arch/arm/include/asm/arm64/mpu.h
+++ b/xen/arch/arm/include/asm/arm64/mpu.h
@@ -72,7 +72,8 @@ typedef union {
  unsigned long ns:1; /* Not-Secure */
  unsigned long res:1;    /* Reserved 0 by hardware */
  unsigned long limit:42; /* Limit Address */
-    unsigned long pad:16;
+    unsigned long pad:15;
+    unsigned long tran:1;   /* Transient region */
  } reg;
  uint64_t bits;
  } prlar_t;
diff --git a/xen/arch/arm/include/asm/page.h 
b/xen/arch/arm/include/asm/page.h

index 85ecd5e4de..a434e2205a 100644
--- a/xen/arch/arm/include/asm/page.h
+++ b/xen/arch/arm/include/asm/page.h
@@ -97,19 +97,24 @@
   * [3:4] Execute Never
   * [5:6] Access Permission
   * [7]   Region Present
+ * [8]   Transient Region, e.g. MPU memory region is temproraily
+ *  mapped for a short time
   */
  #define _PAGE_AI_BIT    0
  #define _PAGE_XN_BIT    3
  #define _PAGE_AP_BIT    5
  #define _PAGE_PRESENT_BIT   7
+#define _PAGE_TRANSIENT_BIT 8
I don't think this is related to MPU. At least when I look at 
the bit representation of PRBAR_EL1/2,


This set of _PAGE_xxx flags aren't compliant with PRBAR_EL1/2 
register map.
It is a flag passed to function map_pages_to_xen() to indicate 
memory

attributes and permission.


But aren't you writing these flags to PRBAR_EL1/EL2 when you call 
xen_mpumap_update_entry().


In the below snippet of xen_mpumap_update_entry(), IIUC, you are 
writing these flags.


 xen_mpumap[idx].prbar.reg.ap = PAGE_AP_MASK(flags);
 xen_mpumap[idx].prbar.reg.xn = PAGE_XN_MASK(flags);

 write_protection_region((const pr_t*)(&xen_mpumap[idx]), 
idx);


Please clarify here.

In this case, I don't prefer mixing hardware specific bits with 
software only representation for these reasons :-


1. It makes it confusing and hard to differentiate the hardware 
specific attrbutes from software only.


Penny's approach matches what we are doing in the MMU code. We want 
to have a way for the caller to pass just set of flags and let the 
callee to decide what to do with them.


This may be flags converted for HW fields or just used by the logic.

If you disagree with this approach, then can you propose a 
different way that we can discuss?


Thanks ayan for pointing out that RES0 is not suitable for storing 
software-only flags, agreed.


Then, maybe we should refine the existing "struct pr_t" to store these
sw bits, like:
```
typedef union {
 struct {
    uint8_t tran:1; /* Transient region */
    uint8_t p2m_type:4; /* Used to store p2m types.*/


Why do you need the p2m_type?



I inherited the usage from MMU. Right now, in commit "[PATCH v3 46/52] 
xen/mpu: look up entry in p2m table", we introduce the first usage to

tell whether it is a valid P2M MPU memory region. In the future,
we may also use it to check whether it works as RAM region(p2m_ram_rw).


 };
 uint8_t bits;
} pr_flags;

/* MPU Protection Region */
typedef struct {
 prbar_t prbar;
 prlar_t prlar;
 pr_flags flags;
} pr_t;
```
The drawback is that, considering the padding, "struct pr_t" expands 
from 16 bytes to 24 bytes.


For clarifications, pr_t is going to be used to create an array in Xen, 
right? If so, what's the expected size of the array?




Yes, it is going to be an array. And the maxim

[linux-linus test] 181774: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 guest-saverestore.2 fail in 
181765 pass in 181774
 test-amd64-amd64-xl-credit1 20 guest-localmigrate/x10 fail in 181765 pass in 
181774
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 16 guest-localmigrate fail in 
181765 pass in 181774
 test-amd64-amd64-dom0pvh-xl-amd 22 guest-start/debian.repeat fail in 181765 
pass in 181774
 test-arm64-arm64-xl-credit2 18 guest-start/debian.repeat fail in 181765 pass 
in 181774
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 18 guest-localmigrate/x10 fail in 
181765 pass in 181774
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 18 
guest-localmigrate/x10 fail in 181765 pass in 181774
 test-amd64-amd64-freebsd11-amd64 21 guest-start/freebsd.repeat fail in 181765 
pass in 181774
 test-amd64-amd64-xl-multivcpu 22 guest-start/debian.repeat fail in 181768 pass 
in 181774
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 15 guest-saverestore fail 
in 181768 pass in 181774
 test-amd64-amd64-dom0pvh-xl-intel 22 guest-start/debian.repeat fail in 181768 
pass in 181774
 test-amd64-amd64-xl-credit2  20 guest-localmigrate/x10 fail pass in 181765
 test-amd64-amd64-xl-shadow   22 guest-start/debian.repeat  fail pass in 181765
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 18 guest-localmigrate/x10 
fail pass in 181765
 test-amd64-amd64-xl-xsm  19 guest-saverestore.2fail pass in 181768
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-installfail pass in 181768
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 18 guest-localmigrate/x10 fail 
pass in 181768
 test-amd64-amd64-xl-vhd  21 guest-start/debian.repeat  fail pass in 181768

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

version targeted for testing:
 linux3f01e9fed8454dcd89727016c3e5b2fbb8f8e50c
baseline version:
 linux6c538e1adbfc696ac4747fb10d63e704344f763d

Last test of basis   180278  2023-04-16 19:41:46

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  24909098fdb260da9ffd0ba733d3a540c8c61aec
baseline version:
 xen  0a834e953b01ec25c412369d7a5b8b57d340ac60

Last test of basis   181773  2023-07-12 12:02:02 Z0 days
Testing same since   181776  2023-07-12 21:00:25 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   0a834e953b..24909098fd  24909098fdb260da9ffd0ba733d3a540c8c61aec -> smoke

Re: [XEN PATCH] xen: fix violations of MISRA C:2012 Rule 3.1

[Stefano Stabellini]

On Wed, 12 Jul 2023, Nicola Vetrini wrote:
> In the file 'xen/common/xmalloc_tlsf.c' is not clear how
> the commented-out code should interact with the previous statement.
> To resolve the MISRA violation generated by the nested comment
> a #if .. #endif block with an explanatory comment substitutes
> the earlier construct.
> 
> In the file 'xen/include/xen/atomic.h' the nested comment has been removed,
> since the code sample is already explained by the preceding comment.
> 
> Signed-off-by: Nicola Vetrini 

Reviewed-by: Stefano Stabellini 


> ---
> Following the suggestion of this message
> https://lore.kernel.org/xen-devel/536f3049-41f7-b127-ba94-81925e34e...@suse.com/
> an explanatory comment has been added.
> ---
>  xen/common/xmalloc_tlsf.c | 13 ++---
>  xen/include/xen/atomic.h  |  2 +-
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
> index c21bf71e88..56c3849414 100644
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -139,10 +139,17 @@ static inline void MAPPING_SEARCH(unsigned long *r, int 
> *fl, int *sl)
>  *r = *r + t;
>  *fl = flsl(*r) - 1;
>  *sl = (*r >> (*fl - MAX_LOG2_SLI)) - MAX_SLI;
> -*fl -= FLI_OFFSET;
> -/*if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
> - *fl = *sl = 0;
> +/* 
> + * It's unclear what was the purpose of the commented-out code that 
> now
> + * is in the #else branch. The current form is motivated by the 
> correction
> + * of a violation MISRA:C 2012 Rule 3.1
>   */
> +#if 1
> +*fl -= FLI_OFFSET;
> +#else
> +if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
> +  *fl = *sl = 0;
> +#endif
>  *r &= ~t;
>  }
>  }
> diff --git a/xen/include/xen/atomic.h b/xen/include/xen/atomic.h
> index 529213ebbb..fa750a18ae 100644
> --- a/xen/include/xen/atomic.h
> +++ b/xen/include/xen/atomic.h
> @@ -78,7 +78,7 @@ static inline void _atomic_set(atomic_t *v, int i);
>   *  int old = atomic_read(&v);
>   *  int new = old + 1;
>   *  if ( likely(old == atomic_cmpxchg(&v, old, new)) )
> - *  break; // success!
> + *  break;
>   *  }
>   */
>  static inline int atomic_cmpxchg(atomic_t *v, int old, int new);
> -- 
> 2.34.1
> 

Re: [XEN PATCH v3 13/15] x86/viridian: fix violations of MISRA C:2012 Rule 7.2

[Stefano Stabellini]

On Wed, 12 Jul 2023, Simone Ballarin wrote:
> From: Gianluca Luparini 
> 
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline states:
> "A 'u' or 'U' suffix shall be applied to all integer constants
> that are represented in an unsigned type".
> 
> Add the 'U' suffix to integers literals with unsigned type and also to other
> literals used in the same contexts or near violations, when their positive
> nature is immediately clear. The latter changes are done for the sake of
> uniformity.
> 
> Signed-off-by: Gianluca Luparini 
> Signed-off-by: Simone Ballarin 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v3:
> - create this commit for 'viridian.c' and 'hyperv-tlfs.h'
> ---
>  xen/arch/x86/hvm/viridian/viridian.c |  2 +-
>  xen/arch/x86/include/asm/guest/hyperv-tlfs.h | 28 ++--
>  2 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/viridian/viridian.c 
> b/xen/arch/x86/hvm/viridian/viridian.c
> index 7405c117bc..61171e3363 100644
> --- a/xen/arch/x86/hvm/viridian/viridian.c
> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> @@ -291,7 +291,7 @@ static void enable_hypercall_page(struct domain *d)
>   * calling convention) to differentiate Xen and Viridian hypercalls.
>   */
>  *(u8  *)(p + 0) = 0x0d; /* orl $0x8000, %eax */
> -*(u32 *)(p + 1) = 0x8000;
> +*(u32 *)(p + 1) = 0x8000U;
>  *(u8  *)(p + 5) = 0x0f; /* vmcall/vmmcall */
>  *(u8  *)(p + 6) = 0x01;
>  *(u8  *)(p + 7) = (cpu_has_vmx ? 0xc1 : 0xd9);
> diff --git a/xen/arch/x86/include/asm/guest/hyperv-tlfs.h 
> b/xen/arch/x86/include/asm/guest/hyperv-tlfs.h
> index 38f997a0c8..a6915ad731 100644
> --- a/xen/arch/x86/include/asm/guest/hyperv-tlfs.h
> +++ b/xen/arch/x86/include/asm/guest/hyperv-tlfs.h
> @@ -471,30 +471,30 @@ typedef struct _HV_REFERENCE_TSC_PAGE {
>  
>  /* Define hypervisor message types. */
>  enum hv_message_type {
> - HVMSG_NONE  = 0x,
> + HVMSG_NONE  = 0xU,
>  
>   /* Memory access messages. */
> - HVMSG_UNMAPPED_GPA  = 0x8000,
> - HVMSG_GPA_INTERCEPT = 0x8001,
> + HVMSG_UNMAPPED_GPA  = 0x8000U,
> + HVMSG_GPA_INTERCEPT = 0x8001U,
>  
>   /* Timer notification messages. */
> - HVMSG_TIMER_EXPIRED = 0x8010,
> + HVMSG_TIMER_EXPIRED = 0x8010U,
>  
>   /* Error messages. */
> - HVMSG_INVALID_VP_REGISTER_VALUE = 0x8020,
> - HVMSG_UNRECOVERABLE_EXCEPTION   = 0x8021,
> - HVMSG_UNSUPPORTED_FEATURE   = 0x8022,
> + HVMSG_INVALID_VP_REGISTER_VALUE = 0x8020U,
> + HVMSG_UNRECOVERABLE_EXCEPTION   = 0x8021U,
> + HVMSG_UNSUPPORTED_FEATURE   = 0x8022U,
>  
>   /* Trace buffer complete messages. */
> - HVMSG_EVENTLOG_BUFFERCOMPLETE   = 0x8040,
> + HVMSG_EVENTLOG_BUFFERCOMPLETE   = 0x8040U,
>  
>   /* Platform-specific processor intercept messages. */
> - HVMSG_X64_IOPORT_INTERCEPT  = 0x8001,
> - HVMSG_X64_MSR_INTERCEPT = 0x80010001,
> - HVMSG_X64_CPUID_INTERCEPT   = 0x80010002,
> - HVMSG_X64_EXCEPTION_INTERCEPT   = 0x80010003,
> - HVMSG_X64_APIC_EOI  = 0x80010004,
> - HVMSG_X64_LEGACY_FP_ERROR   = 0x80010005
> + HVMSG_X64_IOPORT_INTERCEPT  = 0x8001U,
> + HVMSG_X64_MSR_INTERCEPT = 0x80010001U,
> + HVMSG_X64_CPUID_INTERCEPT   = 0x80010002U,
> + HVMSG_X64_EXCEPTION_INTERCEPT   = 0x80010003U,
> + HVMSG_X64_APIC_EOI  = 0x80010004U,
> + HVMSG_X64_LEGACY_FP_ERROR   = 0x80010005U
>  };
>  
>  /* Define synthetic interrupt controller message flags. */
> -- 
> 2.41.0
> 

Re: [XEN PATCH v3 12/15] xen/x86: fix violations of MISRA C:2012 Rule 7.2

[Stefano Stabellini]

On Wed, 12 Jul 2023, Simone Ballarin wrote:
> From: Gianluca Luparini 
> 
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline states:
> "A 'u' or 'U' suffix shall be applied to all integer constants
> that are represented in an unsigned type".
> 
> Add the 'U' suffix to integers literals with unsigned type.
> 
> For the sake of uniformity, the following changes are made:
> - add the 'U' suffix to all first macro's arguments in 'mce-apei.c'
> - add the 'U' suffix to switch cases in 'cpuid.c'
> - add 'U' suffixes to 'mask16' in 'stdvga.c'
> - add the 'U' suffix to macros in 'pci.h'
> 
> Signed-off-by: Gianluca Luparini 
> Signed-off-by: Simone Ballarin 

The checked the patch and everything looks correct.

Reviewed-by: Stefano Stabellini 


Two minor comments below that could or could not be addressed on commit.
It is fine either way for me.


> diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
> index c3771c2e39..0e8694c188 100644
> --- a/xen/arch/x86/extable.c
> +++ b/xen/arch/x86/extable.c
> @@ -141,7 +141,7 @@ static int __init cf_check stub_selftest(void)
>.rax = 0x0123456789abcdef,
>.res.fields.trapnr = X86_EXC_GP },
>  { .opc = { endbr64, 0x02, 0x04, 0x04, 0xc3 }, /* add (%rsp,%rax),%al 
> */
> -  .rax = 0xfedcba9876543210,
> +  .rax = 0xfedcba9876543210UL,
>.res.fields.trapnr = X86_EXC_SS },
>  { .opc = { endbr64, 0xcc, 0xc3, 0xc3, 0xc3 }, /* int3 */
>.res.fields.trapnr = X86_EXC_BP },

I wonder if it would be easier to be consistent cross-arch and just use
ULL everywhere a 64-bit value is present.

I know it is not required on x86, so this is just an optional
comment, I'll leave it to the maintainers.


> @@ -325,83 +325,83 @@
>  
>  /* K7/K8 MSRs. Not complete. See the architecture manual for a more
> complete list. */
> -#define MSR_K7_EVNTSEL0  0xc001
> -#define MSR_K7_PERFCTR0  0xc0010004
> -#define MSR_K7_EVNTSEL1  0xc0010001
> -#define MSR_K7_PERFCTR1  0xc0010005
> -#define MSR_K7_EVNTSEL2  0xc0010002
> -#define MSR_K7_PERFCTR2  0xc0010006
> -#define MSR_K7_EVNTSEL3  0xc0010003
> -#define MSR_K7_PERFCTR3  0xc0010007
> -#define MSR_K8_TOP_MEM1  0xc001001a
> -#define MSR_K7_CLK_CTL   0xc001001b
> -#define MSR_K8_TOP_MEM2  0xc001001d
> -
> -#define MSR_K8_HWCR  0xc0010015
> +#define MSR_K7_EVNTSEL0  0xc001U
> +#define MSR_K7_PERFCTR0  0xc0010004U
> +#define MSR_K7_EVNTSEL1  0xc0010001U
> +#define MSR_K7_PERFCTR1  0xc0010005U
> +#define MSR_K7_EVNTSEL2  0xc0010002U
> +#define MSR_K7_PERFCTR2  0xc0010006U
> +#define MSR_K7_EVNTSEL3  0xc0010003U
> +#define MSR_K7_PERFCTR3  0xc0010007U
> +#define MSR_K8_TOP_MEM1  0xc001001aU
> +#define MSR_K7_CLK_CTL   0xc001001bU
> +#define MSR_K8_TOP_MEM2  0xc001001dU
> +
> +#define MSR_K8_HWCR  0xc0010015U
>  #define K8_HWCR_TSC_FREQ_SEL (1ULL << 24)
>  #define K8_HWCR_CPUID_USER_DIS   (1ULL << 35)
>  
> -#define MSR_K7_FID_VID_CTL   0xc0010041
> -#define MSR_K7_FID_VID_STATUS0xc0010042
> -#define MSR_K8_PSTATE_LIMIT  0xc0010061
> -#define MSR_K8_PSTATE_CTRL   0xc0010062
> -#define MSR_K8_PSTATE_STATUS 0xc0010063
> -#define MSR_K8_PSTATE0   0xc0010064
> -#define MSR_K8_PSTATE1   0xc0010065
> -#define MSR_K8_PSTATE2   0xc0010066
> -#define MSR_K8_PSTATE3   0xc0010067
> -#define MSR_K8_PSTATE4   0xc0010068
> -#define MSR_K8_PSTATE5   0xc0010069
> -#define MSR_K8_PSTATE6   0xc001006A
> -#define MSR_K8_PSTATE7   0xc001006B
> -#define MSR_K8_ENABLE_C1E0xc0010055
> -#define MSR_K8_VM_HSAVE_PA   0xc0010117
> -
> -#define MSR_AMD_FAM15H_EVNTSEL0  0xc0010200
> -#define MSR_AMD_FAM15H_PERFCTR0  0xc0010201
> -#define MSR_AMD_FAM15H_EVNTSEL1  0xc0010202
> -#define MSR_AMD_FAM15H_PERFCTR1  0xc0010203
> -#define MSR_AMD_FAM15H_EVNTSEL2  0xc0010204
> -#define MSR_AMD_FAM15H_PERFCTR2  0xc0010205
> -#define MSR_AMD_FAM15H_EVNTSEL3  0xc0010206
> -#define MSR_AMD_FAM15H_PERFCTR3  0xc0010207
> -#define MSR_AMD_FAM15H_EVNTSEL4  0xc0010208
> -#define MSR_AMD_FAM15H_PERFCTR4  0xc0010209
> -#define MSR_AMD_FAM15H_EVNTSEL5  0xc001020a
> -#define MSR_AMD_FAM15H_PERFCTR5  0xc001020b
> -
> -#define MSR_AMD_L7S0_FEAT

Re: [XEN PATCH v3 07/15] x86/vmx: fix violations of MISRA C:2012 Rule 7.2

[Stefano Stabellini]

On Wed, 12 Jul 2023, Jan Beulich wrote:
> On 12.07.2023 12:32, Simone Ballarin wrote:
> > From: Gianluca Luparini 
> > 
> > The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> > headline states:
> > "A 'u' or 'U' suffix shall be applied to all integer constants
> > that are represented in an unsigned type".
> > 
> > Add the 'U' suffix to integers literals with unsigned type.
> > 
> > For the sake of uniformity, the following changes are made:
> > - add the 'U' suffix to macros near
> >   'CPU_BASED_ACTIVATE_SECONDARY_CONTROLS' and
> >   'SECONDARY_EXEC_NOTIFY_VM_EXITING' macros in 'vmcs.h'
> > - add the 'U' suffix to macros near 'INTR_INFO_VALID_MASK'
> >   macro in 'vmx.h'
> > 
> > Signed-off-by: Gianluca Luparini 
> > Signed-off-by: Simone Ballarin 
> > Reviewed-by: Stefano Stabellini 
> > ---
> > Changes in v3:
> > - change 'Signed-off-by' ordering
> > - change commit message
> > - remove unnecessary changes in 'vvmx.c'
> > - add 'uint32_t' casts in 'vvmx.c'
> > - add missing 'U' in 'vmcs.h' macros
> > - change macro to '(1u << 31)' in 'vmx.h'
> > - remove unnecessary changes to 'vmx.h'
> 
> With this many changes I don't think you can retain an R-b, unless
> the person it came from really explicitly agreed with at least all
> not purely cosmetic changes (which I don't think was the case here).

I re-reviewed it:

Reviewed-by: Stefano Stabellini 


> Irrespective:
> Reviewed-by: Jan Beulich 
> 
> Jan
> 

Re: [XEN PATCH v3 04/15] xen/arm: fix violations of MISRA C:2012 Rule 7.2

[Stefano Stabellini]

On Wed, 12 Jul 2023, Simone Ballarin wrote:
> From: Gianluca Luparini 
> 
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline states:
> "A 'u' or 'U' suffix shall be applied to all integer constants
> that are represented in an unsigned type".
> 
> Add the 'U' suffix to integers literals with unsigned type and also to other
> literals used in the same contexts or near violations, when their positive
> nature is immediately clear. The latter changes are done for the sake of
> uniformity.
> 
> Signed-off-by: Gianluca Luparini 
> Signed-off-by: Simone Ballarin 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v3:
> - change 'Signed-off-by' ordering
> - add 'ULL' instead of 'U' in 'efibind.h' and 'vgic-v3.c'
> - remove excessive suffixes in 'efi-boot.h' and 'smccc.h'
> 
> Changes in v2:
> - minor change to commit title
> - change commit message
> - fix in 'domain_build.c' file for consistency
> - fix typo in 'gic-v2.c' file
> - fix in 'insn.h' file for consistency
> - add fixes in 'gic-v3.c', 'traps.c' and 'vgic-v3.c'
> ---
>  xen/arch/arm/domain_build.c  |  4 ++--
>  xen/arch/arm/efi/efi-boot.h  |  2 +-
>  xen/arch/arm/gic-v2.c|  6 +++---
>  xen/arch/arm/gic-v3.c| 10 +-
>  xen/arch/arm/include/asm/arm64/brk.h |  2 +-
>  xen/arch/arm/include/asm/arm64/efibind.h | 10 +-
>  xen/arch/arm/include/asm/arm64/insn.h| 16 
>  xen/arch/arm/include/asm/vreg.h  |  2 +-
>  xen/arch/arm/kernel.c|  2 +-
>  xen/arch/arm/traps.c | 14 +++---
>  xen/arch/arm/vgic-v2.c   |  2 +-
>  xen/arch/arm/vgic-v3.c   |  2 +-
>  xen/include/public/arch-arm/smccc.h  |  4 ++--
>  13 files changed, 38 insertions(+), 38 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d0d6be922d..d58604ef4a 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -3751,8 +3751,8 @@ static int __init construct_domain(struct domain *d, 
> struct kernel_info *kinfo)
>   * r1 = machine nr, r2 = atags or dtb pointer.
>   *...
>   */
> -regs->r0 = 0; /* SBZ */
> -regs->r1 = 0x; /* We use DTB therefore no machine id */
> +regs->r0 = 0U; /* SBZ */
> +regs->r1 = 0xU; /* We use DTB therefore no machine id */
>  regs->r2 = kinfo->dtb_paddr;
>  }
>  #ifdef CONFIG_ARM_64
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index bb64925d70..3daa63a40d 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -46,7 +46,7 @@ static int get_module_file_index(const char *name, unsigned 
> int name_len);
>  static void PrintMessage(const CHAR16 *s);
>  
>  #define DEVICE_TREE_GUID \
> -{0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 
> 0xe0}}
> +{0xb1b621d5U, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 
> 0xe0}}
>  
>  static struct file __initdata dtbfile;
>  static void __initdata *fdt;
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 6476ff4230..cf392bfd1c 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -386,9 +386,9 @@ static void gicv2_cpu_init(void)
>  /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
>   * even though they are controlled with GICD registers, they must
>   * be set up here with the other per-cpu state. */
> -writel_gicd(0x, GICD_ICACTIVER); /* Diactivate PPIs and SGIs */
> -writel_gicd(0x, GICD_ICENABLER); /* Disable all PPI */
> -writel_gicd(0x, GICD_ISENABLER); /* Enable all SGI */
> +writel_gicd(0xU, GICD_ICACTIVER); /* De-activate PPIs and SGIs */
> +writel_gicd(0xU, GICD_ICENABLER); /* Disable all PPI */
> +writel_gicd(0xU, GICD_ISENABLER); /* Enable all SGI */
>  
>  /* Set SGI priorities */
>  for ( i = 0; i < 16; i += 4 )
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 4e6c98bada..95e4f020fe 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -619,8 +619,8 @@ static void __init gicv3_dist_init(void)
>  /* Disable/deactivate all global interrupts */
>  for ( i = NR_GIC_LOCAL_IRQS; i < nr_lines; i += 32 )
>  {
> -writel_relaxed(0x, GICD + GICD_ICENABLER + (i / 32) * 4);
> -writel_relaxed(0x, GICD + GICD_ICACTIVER + (i / 32) * 4);
> +writel_relaxed(0xU, GICD + GICD_ICENABLER + (i / 32) * 4);
> +writel_relaxed(0xU, GICD + GICD_ICACTIVER + (i / 32) * 4);
>  }
>  
>  /*
> @@ -832,13 +832,13 @@ static int gicv3_cpu_init(void)
>   * The activate state is unknown at boot, so make sure all
>   * SGIs and PPIs are de-activated.
>   */
> -writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICACTIVER0);
> + 

[xen-unstable test] 181772: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 12 debian-hvm-install fail in 
181767 pass in 181772
 test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail in 181767 pass 
in 181772
 test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail in 181767 pass in 
181772
 test-amd64-i386-xl-shadow 7 xen-installfail pass in 181767
 test-amd64-amd64-xl-multivcpu 20 guest-localmigrate/x10fail pass in 181767
 test-armhf-armhf-libvirt-raw 13 guest-startfail pass in 181767
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass 
in 181767

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

[PATCH v3 3/3] x86/APIC: adjustments to error_interrupt() loop

[Elliott Mitchell]

ARRAY_SIZE() makes future maintainance easier and thus less likely for
bugs to occur.

Signed-off-by: Elliott Mitchell 
---
v2:
Breaking this miniscule tidbit off.
---
 xen/arch/x86/apic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 5b830b2312..18ceb35e34 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1412,7 +1412,7 @@ static void cf_check error_interrupt(struct cpu_user_regs 
*regs)
 };
 const char *entries[ARRAY_SIZE(esr_fields)];
 unsigned int v, v1;
-int i;
+unsigned int i;
 
 /* First tickle the hardware, only then report what went on. -- REW */
 v = apic_read(APIC_ESR);
@@ -1420,7 +1420,7 @@ static void cf_check error_interrupt(struct cpu_user_regs 
*regs)
 v1 = apic_read(APIC_ESR);
 ack_APIC_irq();
 
-for ( i = 7; i >= 0; --i )
+for ( i = 0; i < ARRAY_SIZE(entries); ++i )
 entries[i] = v1 & (1 << i) ? esr_fields[i] : "";
 printk(XENLOG_DEBUG "APIC error on CPU%u: %02x(%02x)"
 "%s%s%s%s%s%s%s%s" "\n",
-- 
2.30.2

[PATCH v3 2/3] x86/APIC: modify error_interrupt() to output using single printk()

[Elliott Mitchell]

This takes care of the issue of APIC errors tending to occur on multiple
cores at once.  In turn this tends to causes the error messages to be
merged together, making understanding them difficult.

Signed-off-by: Elliott Mitchell 
---
v2:
Splitting the loop adjustment off.  Fixing the entry display
order.
---
 xen/arch/x86/apic.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 8cfb8cd71c..5b830b2312 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1410,6 +1410,7 @@ static void cf_check error_interrupt(struct cpu_user_regs 
*regs)
 ", Received illegal vector",
 ", Illegal register address",
 };
+const char *entries[ARRAY_SIZE(esr_fields)];
 unsigned int v, v1;
 int i;
 
@@ -1419,12 +1420,13 @@ static void cf_check error_interrupt(struct 
cpu_user_regs *regs)
 v1 = apic_read(APIC_ESR);
 ack_APIC_irq();
 
-printk(XENLOG_DEBUG "APIC error on CPU%u: %02x(%02x)",
-smp_processor_id(), v , v1);
 for ( i = 7; i >= 0; --i )
-if ( v1 & (1 << i) )
-printk("%s", esr_fields[i]);
-printk("\n");
+entries[i] = v1 & (1 << i) ? esr_fields[i] : "";
+printk(XENLOG_DEBUG "APIC error on CPU%u: %02x(%02x)"
+"%s%s%s%s%s%s%s%s" "\n",
+smp_processor_id(), v , v1,
+entries[7], entries[6],
+entries[5], entries[4], entries[3], entries[2], entries[1], 
entries[0]);
 }
 
 /*
-- 
2.30.2

[PATCH v3 1/3] x86/APIC: include full string with error_interrupt() error messages

[Elliott Mitchell]

Rather than adding ", " with each printf(), simply include them in the
string initially.  This allows converting to strlcat() or other methods
which strictly concatenate, rather than formatting.

Signed-off-by: Elliott Mitchell 
---
v2:
One more sentence in the commit message.
---
 xen/arch/x86/apic.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index f71474d47d..8cfb8cd71c 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1401,14 +1401,14 @@ static void cf_check spurious_interrupt(struct 
cpu_user_regs *regs)
 static void cf_check error_interrupt(struct cpu_user_regs *regs)
 {
 static const char *const esr_fields[] = {
-"Send CS error",
-"Receive CS error",
-"Send accept error",
-"Receive accept error",
-"Redirectable IPI",
-"Send illegal vector",
-"Received illegal vector",
-"Illegal register address",
+", Send CS error",
+", Receive CS error",
+", Send accept error",
+", Receive accept error",
+", Redirectable IPI",
+", Send illegal vector",
+", Received illegal vector",
+", Illegal register address",
 };
 unsigned int v, v1;
 int i;
@@ -1423,7 +1423,7 @@ static void cf_check error_interrupt(struct cpu_user_regs 
*regs)
 smp_processor_id(), v , v1);
 for ( i = 7; i >= 0; --i )
 if ( v1 & (1 << i) )
-printk(", %s", esr_fields[i]);
+printk("%s", esr_fields[i]);
 printk("\n");
 }
 
-- 
2.30.2

[PATCH v3 0/3] Fixing ACPI error reporting display

[Elliott Mitchell]

This series has been seen previously.  The issue is pretty simple, if
ACPI errors occur there is a high probability they will occur on multiple
cores at once.  Since there is no locking for `printk()` there is a need
to emit the entire error with a single `printk()`.

I believe this is roughly where things left off.  The loop adjustment had
been requested to be broken into a separate step.  I had also goofed when
adjusting the handling and the string order had gotten reversed.

I'm unsure how best to make the `printk()` more maintainable.  Yet more
"%s" and entries[#] will be needed if additional bits get defined.  I'm
inclined to keep the string broken apart to hint as to how it matches
the entry list.  I'm okay with everything being fully concatenated if
that is felt best.


Elliott Mitchell (3):
  x86/APIC: include full string with error_interrupt() error messages
  x86/APIC: modify error_interrupt() to output using single printk()
  x86/APIC: adjustments to error_interrupt() loop

 xen/arch/x86/apic.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

-- 
2.30.2

Re: [PATCH] docs: Fix style in misc/arm/silicon-errata.txt table

[Stefano Stabellini]

On Wed, 12 Jul 2023, Luca Fancellu wrote:
> > On 12 Jul 2023, at 14:04, Michal Orzel  wrote:
> > 
> > Hi Luca,
> > 
> > On 12/07/2023 14:04, Luca Fancellu wrote:
> >> 
> >> 
> >> Fix the right border of the silicon-errata.txt table
> >> 
> >> Fixes: 1814a626fb58 ("xen/arm: Update silicon-errata.txt with the Neovers 
> >> AT erratum")
> > Fixes tag is for bugs and this one is clearly not.
> > With that removed:
> > Reviewed-by: Michal Orzel 
> 
> Thank you, yeah well I discovered it can be used also on back-ports, so I’ve 
> added it, anyway
> If maintainer are ok, it can be addressed on commit

Acked-by: Stefano Stabellini 

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

[Jason Andryuk]

On Wed, Jul 12, 2023 at 4:43 AM Jan Beulich  wrote:
>
> On 11.07.2023 19:49, Jason Andryuk wrote:
> > On Tue, Jul 11, 2023 at 10:41 AM Jan Beulich  wrote:
> >>
> >> On 11.07.2023 16:16, Jason Andryuk wrote:
> >>> On Tue, Jul 11, 2023 at 4:18 AM Jan Beulich  wrote:
>  On 10.07.2023 17:22, Jason Andryuk wrote:
> > On Mon, Jul 10, 2023 at 9:13 AM Jan Beulich  wrote:
> >> On 06.07.2023 20:54, Jason Andryuk wrote:
> >>> @@ -510,6 +510,22 @@ choice of `dom0-kernel` is deprecated and not 
> >>> supported by all Dom0 kernels.
> >>>  * `` and `` are integers which represent max and 
> >>> min processor frequencies
> >>>respectively.
> >>>  * `verbose` option can be included as a string or also as 
> >>> `verbose=`
> >>> +  for `xen`.  It is a boolean for `hwp`.
> >>> +* `hwp` selects Hardware-Controlled Performance States (HWP) on 
> >>> supported Intel
> >>> +  hardware.  HWP is a Skylake+ feature which provides better CPU 
> >>> power
> >>> +  management.  The default is disabled.  If `hwp` is selected, but 
> >>> hardware
> >>> +  support is not available, Xen will fallback to cpufreq=xen.
> >>> +* `` is a boolean to enable Hardware Duty Cycling (HDC).  HDC 
> >>> enables the
> >>> +  processor to autonomously force physical package components into 
> >>> idle state.
> >>> +  The default is enabled, but the option only applies when `hwp` is 
> >>> enabled.
> >>> +
> >>> +There is also support for `;`-separated fallback options:
> >>> +`cpufreq=hwp,verbose;xen`.  This first tries `hwp` and falls back to 
> >>> `xen`
> >>> +if unavailable.
> >>
> >> In the given example, does "verbose" also apply to the fallback case? 
> >> If so,
> >> perhaps better "cpufreq=hwp;xen,verbose", to eliminate that ambiguity?
> >
> > Yes, "verbose" is applied to both.  I can make the change.  I
> > mentioned it in the commit message, but I'll mention it here as well.
> 
>  FTAOD my earlier comment implied that the spelling form you use above
>  should not even be accepted when parsing. I.e. it was not just about
>  the doc aspect.
> >>>
> >>> Oh.  So what exactly do you want then?
> >>>
> >>> There is a single cpufreq_verbose variable today that is set by either
> >>> cpufreq=hwp,verbose or cpufreq=xen,verbose.  Is that okay, or should
> >>> the "xen" and "hwp" each get a separate variable?
> >>>
> >>> Do you only want to allow a single trailing "verbose" to apply to all
> >>> of cpufreq (cpufreq=$foo,verbose)?  Or do you want "verbose" to be
> >>> only valid for "xen"?  Both cpufreq_cmdline_parse() and
> >>> hwp_cmdline_parse() just loop over their options and don't care about
> >>> order, even though the documentation lists verbose last.  Would you
> >>> want "cpufreq=hwp,verbose,hdc" to fail to parse?
> >>>
> >>> All parsing is done upfront before knowing whether "xen" or "hwp" will
> >>> be used as the cpufreq driver, so there is a trickiness for
> >>> implementing "verbose" only for one option.  Similarly,
> >>> "cpufreq=hwp,invalid;xen" will try "hwp" (but not "xen")  since the
> >>> live variables are updated.  Even without this patch, cpufreq will be
> >>> configured up to an invalid parameter.
> >>
> >> Right, and I'd like to see "hwp;xen" to be treated as a "unit", with
> >> ",verbose" applying to whichever succeeds initializing. I don't think
> >> there is much point to have separate verbosity variables.
> >
> > When you say "hwp;xen" as a unit, you don't mean to intermix all the
> > options like:
> > cpufreq=hwp;xen:ondemand,hdc,maxfreq=42
> > do you?
> >
> > Because of the suboptions, I don't treat "hwp;xen" as a unit, but as
> > strings separated by ';'.
> > That allows the full selection of parameters like:
> > cpufreq=hwc,no-hdc;xen:ondemand,maxfreq=42,minfreq=0
> >
> > This lets each respective parser handle the options it knows about.
> > This does duplicate "verbose" handling.  cpufreq_cmdline_parse() and
> > hwp_cmdline_parse() are also usable when only one of "hwp" or "xen" is
> > specified.
> >
> > These all work:
> > cpufreq=xen:ondemand,verbose
> > cpufreq=hwp,hdc,verbose
> > cpurfre=hwp,hdc;xen:ondemand,verbose
> >
> > To disallow "verbose" in "cpufreq=hwp,verbose;xen" would require extra
> > code, and setup_cpufreq_option() is already rather complicated IMO.
> > It's a corner case, but doesn't seem harmful to me.   Hmmm, making the
> > above fail parsing may be worse since it would only try "hwp" without
> > a fallback to "xen".
> >
> > I just want to be clear on exactly what I need to implement.
>
> Maybe we need to take a step back a revisit what option forms actually
> make sense to express. Part of the problem may be that we permit (but
> not require afaics) the use of colon as a separator after the "main"
> option ("xen", "none", "dom0-kernel", and perhaps now "hwp"). Such a
> colon suggests that what follows are sub-options applicable to that

Re: [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Sean Paul]

On Wed, Jul 12, 2023 at 10:52 AM Jani Nikula  wrote:
>
> On Wed, 12 Jul 2023, Uwe Kleine-König  wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> >
> > I think there is a big benefit when these are all renamed to "drm_dev".
> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
> >
> > Some statistics:
> >
> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq 
> > -c | sort -n
> >   1 struct drm_device *adev_to_drm
> >   1 struct drm_device *drm_
> >   1 struct drm_device  *drm_dev
> >   1 struct drm_device*drm_dev
> >   1 struct drm_device *pdev
> >   1 struct drm_device *rdev
> >   1 struct drm_device *vdev
> >   2 struct drm_device *dcss_drv_dev_to_drm
> >   2 struct drm_device **ddev
> >   2 struct drm_device *drm_dev_alloc
> >   2 struct drm_device *mock
> >   2 struct drm_device *p_ddev
> >   5 struct drm_device *device
> >   9 struct drm_device * dev
> >  25 struct drm_device *d
> >  95 struct drm_device *
> > 216 struct drm_device *ddev
> > 234 struct drm_device *drm_dev
> > 611 struct drm_device *drm
> >4190 struct drm_device *dev
> >
> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > it's not only me and others like the result of this effort it should be
> > followed up by adapting the other structs and the individual usages in
> > the different drivers.
>
> I think this is an unnecessary change. In drm, a dev is usually a drm
> device, i.e. struct drm_device *. As shown by the numbers above.
>

I'd really prefer this patch (series or single) is not accepted. This
will cause problems for everyone cherry-picking patches to a
downstream kernel (LTS or distro tree). I usually wouldn't expect
sympathy here, but the questionable benefit does not outweigh the cost
IM[biased]O.

Sean

> If folks insist on following through with this anyway, I'm firmly in the
> camp the name should be "drm" and nothing else.
>
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center

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

[Anthony PERARD]

On Tue, Jul 11, 2023 at 11:22:29AM +0200, Roger Pau Monne wrote:
> The current implementation in libxl_cpuid_parse_config() requires
> keeping a list of cpuid feature bits that should be mostly in sync
> with the contents of cpufeatureset.h.
> 
> Avoid such duplication by using the automatically generated list of
> cpuid features in INIT_FEATURE_NAMES in order to map feature names to
> featureset bits, and then translate from featureset bits into cpuid
> leaf, subleaf, register tuple.
> 
> Note that the full contents of the previous cpuid translation table
> can't be removed.  That's because some feature names allowed by libxl
> are not described in the featuresets, or because naming has diverged
> and the previous nomenclature is preserved for compatibility reasons.
> 
> Should result in no functional change observed by callers, albeit some
> new cpuid features will be available as a result of the change.
> 
> While there constify cpuid_flags name field.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

[libvirt test] 181769: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 13 guest-start fail pass in 181775-retest

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail blocked in 
181759
 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail in 181775 like 
181759
 test-armhf-armhf-libvirt-raw 14 migrate-support-check fail in 181775 never pass
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 181759
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass

version targeted for testing:
 libvirt  ded44a0406c82c560b654ac69ef4259add152eb4
baseline version:
 libvirt  3bf02acdc5446b2c4a3078f99d8f5232acff9043

Last test of basis   181759  2023-07-11 04:18:51 Z1 days
Testing same since   181769  2023-07-12 04:20:30 Z0 days1 attempts


People who touched revisions under test:
  Michal Privoznik 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-arm64-arm64-libvirt-raw pass
 test-armhf-armhf-libvirt-raw fail
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-f

Re: [PATCH v3] xen/arm: pci: fix check in pci_check_bar()

[Rahul Singh]

Hi Stewart,

> On 12 Jul 2023, at 2:52 pm, Stewart Hildebrand  
> wrote:
> 
> When mapping BARs for vPCI, it's valid for a BAR mfn_t start to equal the BAR
> mfn_t end (i.e. start == end) since end is inclusive. However, pci_check_bar()
> currently returns false in this case, which results in Xen not mapping the BAR
> in the guest 2nd stage page tables. In this example boot log, Linux has mapped
> the BARs in the 1st stage, but since Xen did not map them in the 2nd stage,
> Linux encounters a data abort and panics:
> 
> [2.593300] pci :00:00.0: BAR 0: assigned [mem 0x50008000-0x50008fff]
> [2.593682] pci :00:00.0: BAR 2: assigned [mem 0x50009000-0x50009fff]
> [2.594066] pci :00:00.0: BAR 4: assigned [mem 0x5000a000-0x5000afff]
> ...
> [2.810502] virtio-pci :00:00.0: enabling device ( -> 0002)
> (XEN) :00:00.0: not mapping BAR [50008, 50008] invalid position
> (XEN) :00:00.0: not mapping BAR [50009, 50009] invalid position
> (XEN) :00:00.0: not mapping BAR [5000a, 5000a] invalid position
> [2.817502] virtio-pci :00:00.0: virtio_pci: leaving for legacy driver
> [2.817853] virtio-pci :00:00.0: enabling bus mastering
> (XEN) arch/arm/traps.c:1992:d0v0 HSR=0x0093010045 pc=0x889507d4 
> gva=0x8c46d012 gpa=0x0050008012
> [2.818397] Unable to handle kernel ttbr address size fault at virtual 
> address 8c46d012
> ...
> 
> Adjust the end physical address e to account for the full page when converting
> from mfn, at which point s and e cannot be equal, so drop the equality check 
> in
> the condition.
> 
> Note that adjusting e to account for the full page also increases the accuracy
> of the subsequent is_bar_valid check.
> 
> Fixes: cc80e2bab0d0 ("xen/pci: replace call to is_memory_hole to 
> pci_check_bar")
> Signed-off-by: Stewart Hildebrand 
> Reviewed-by: Roger Pau Monné 

I tested the patch on N1SDP board everything works.

Reviewed-by: Rahul Singh 
Tested-by: Rahul Singh 

Regards,
Rahul

Re: [PATCH v3] xen/arm: pci: fix check in pci_check_bar()

[Rahul Singh]

Hi Stewart,

> On 12 Jul 2023, at 2:52 pm, Stewart Hildebrand  
> wrote:
> 
> When mapping BARs for vPCI, it's valid for a BAR mfn_t start to equal the BAR
> mfn_t end (i.e. start == end) since end is inclusive. However, pci_check_bar()
> currently returns false in this case, which results in Xen not mapping the BAR
> in the guest 2nd stage page tables. In this example boot log, Linux has mapped
> the BARs in the 1st stage, but since Xen did not map them in the 2nd stage,
> Linux encounters a data abort and panics:
> 
> [2.593300] pci :00:00.0: BAR 0: assigned [mem 0x50008000-0x50008fff]
> [2.593682] pci :00:00.0: BAR 2: assigned [mem 0x50009000-0x50009fff]
> [2.594066] pci :00:00.0: BAR 4: assigned [mem 0x5000a000-0x5000afff]
> ...
> [2.810502] virtio-pci :00:00.0: enabling device ( -> 0002)
> (XEN) :00:00.0: not mapping BAR [50008, 50008] invalid position
> (XEN) :00:00.0: not mapping BAR [50009, 50009] invalid position
> (XEN) :00:00.0: not mapping BAR [5000a, 5000a] invalid position
> [2.817502] virtio-pci :00:00.0: virtio_pci: leaving for legacy driver
> [2.817853] virtio-pci :00:00.0: enabling bus mastering
> (XEN) arch/arm/traps.c:1992:d0v0 HSR=0x0093010045 pc=0x889507d4 
> gva=0x8c46d012 gpa=0x0050008012
> [2.818397] Unable to handle kernel ttbr address size fault at virtual 
> address 8c46d012
> ...
> 
> Adjust the end physical address e to account for the full page when converting
> from mfn, at which point s and e cannot be equal, so drop the equality check 
> in
> the condition.
> 
> Note that adjusting e to account for the full page also increases the accuracy
> of the subsequent is_bar_valid check.
> 
> Fixes: cc80e2bab0d0 ("xen/pci: replace call to is_memory_hole to 
> pci_check_bar")
> Signed-off-by: Stewart Hildebrand 
> Reviewed-by: Roger Pau Monné 

I tested the patch on N1SDP board everything works.

Reviewed-by: Rahul Singh 
Tested-by: Rahul Singh 

Regards,
Rahul

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

[Anthony PERARD]

On Tue, Jul 11, 2023 at 11:22:28AM +0200, Roger Pau Monne wrote:
> Move the CPUID value parsers out of libxl_cpuid_parse_config() into a
> newly created cpuid_add() local helper.  This is in preparation for
> also adding MSR feature parsing support.
> 
> No functional change intended.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

[Anthony PERARD]

On Tue, Jul 11, 2023 at 11:22:27AM +0200, Roger Pau Monne wrote:
> Add a new array field to libxl_cpuid_policy in order to store the MSR
> policies.
> 
> Note that libxl_cpuid_policy_list_{copy,length,parse_json,gen_json}
> are not adjusted to deal with the new MSR array now part of
> libxl_cpuid_policy_list.

Why? Isn't this going to be an issue? Or maybe that going to be dealt
with in a future patch?

> 
> Adding the MSR data in the libxl_cpuid_policy_list type is done so
> that existing users can seamlessly pass MSR features as part of the
> CPUID data, without requiring the introduction of a separate
> domain_build_info field, and a new set of handlers functions.
> 
> Signed-off-by: Roger Pau Monné 
> ---
>  tools/libs/light/libxl_cpuid.c| 6 +-
>  tools/libs/light/libxl_internal.h | 1 +
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
> index 724cb4f182d4..65cad28c3ef0 100644
> --- a/tools/libs/light/libxl_cpuid.c
> +++ b/tools/libs/light/libxl_cpuid.c
> @@ -40,6 +40,9 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *pl)
>  free(policy->cpuid);
>  }
>  
> +if (policy->msr)

You don't need to test for NULL, you can call free() in this case as
well.

> +free(policy->msr);
> +
>  free(policy);
>  *pl = NULL;
>  return;

-- 
Anthony PERARD

Re: [XEN PATCH] xen: fix violations of MISRA C:2012 Rule 3.1

[Luca Fancellu]

> On 12 Jul 2023, at 17:17, Nicola Vetrini  wrote:
> 
> 
> 
> On 12/07/23 18:02, Luca Fancellu wrote:
>>> On 12 Jul 2023, at 16:54, Nicola Vetrini  wrote:
>>> 
>>> In the file 'xen/common/xmalloc_tlsf.c' is not clear how
>>> the commented-out code should interact with the previous statement.
>>> To resolve the MISRA violation generated by the nested comment
>>> a #if .. #endif block with an explanatory comment substitutes
>>> the earlier construct.
>>> 
>>> In the file 'xen/include/xen/atomic.h' the nested comment has been removed,
>>> since the code sample is already explained by the preceding comment.
>>> 
>>> Signed-off-by: Nicola Vetrini 
>>> ---
>>> Following the suggestion of this message
>>> https://lore.kernel.org/xen-devel/536f3049-41f7-b127-ba94-81925e34e...@suse.com/
>>> an explanatory comment has been added.
>>> ---
>>> xen/common/xmalloc_tlsf.c | 13 ++---
>>> xen/include/xen/atomic.h  |  2 +-
>>> 2 files changed, 11 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
>>> index c21bf71e88..56c3849414 100644
>>> --- a/xen/common/xmalloc_tlsf.c
>>> +++ b/xen/common/xmalloc_tlsf.c
>>> @@ -139,10 +139,17 @@ static inline void MAPPING_SEARCH(unsigned long *r, 
>>> int *fl, int *sl)
>>> *r = *r + t;
>>> *fl = flsl(*r) - 1;
>>> *sl = (*r >> (*fl - MAX_LOG2_SLI)) - MAX_SLI;
>>> -*fl -= FLI_OFFSET;
>>> -/*if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
>>> - *fl = *sl = 0;
>>> +/*
>>> + * It's unclear what was the purpose of the commented-out code 
>>> that now
>>> + * is in the #else branch. The current form is motivated by the 
>>> correction
>>> + * of a violation MISRA:C 2012 Rule 3.1
>>>  */
>>> +#if 1
>>> +*fl -= FLI_OFFSET;
>>> +#else
>>> +if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
>> In the message you linked above, you suggested to use /* FL will be always 
>> >0! */, why has it changed?
>> Was some comment I missed? The xen codestyle mandates the use of /* */, 
>> anyway I agree that here you
>> are just moving code...
>> So maybe the maintainer can tell what is the best thing to do here.
> 
> You didn't miss any further comment: my suggestion was related to the 
> explanatory comment, not the nested comment itself. If a better wording can 
> be found for the former, no problem. As for the codestyle point: it does not 
> change anything doing
> "// FL will be always >0!" -> "/* FL will be always >0!  */
> w.r.t. Rule 3.1 (both would have been nested comments).

Yes, I agree it does not change anything, now that I read better the message, 
it is from Jan suggesting this:

#if 1
*fl -= FLI_OFFSET;
#else
if ((*fl -= FLI_OFFSET) < 0) /* FL will be always >0! */
*fl = *sl = 0;
#endif

So using /* FL will be always >0! */ instead of copying // FL will be always >0!

Anyway, I think it can be addressed on commit, whatever form the maintainer 
prefers.

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

Re: [XEN PATCH] xen: fix violations of MISRA C:2012 Rule 3.1

[Nicola Vetrini]

On 12/07/23 18:02, Luca Fancellu wrote:




On 12 Jul 2023, at 16:54, Nicola Vetrini  wrote:

In the file 'xen/common/xmalloc_tlsf.c' is not clear how
the commented-out code should interact with the previous statement.
To resolve the MISRA violation generated by the nested comment
a #if .. #endif block with an explanatory comment substitutes
the earlier construct.

In the file 'xen/include/xen/atomic.h' the nested comment has been removed,
since the code sample is already explained by the preceding comment.

Signed-off-by: Nicola Vetrini 
---
Following the suggestion of this message
https://lore.kernel.org/xen-devel/536f3049-41f7-b127-ba94-81925e34e...@suse.com/
an explanatory comment has been added.
---
xen/common/xmalloc_tlsf.c | 13 ++---
xen/include/xen/atomic.h  |  2 +-
2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
index c21bf71e88..56c3849414 100644
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -139,10 +139,17 @@ static inline void MAPPING_SEARCH(unsigned long *r, int 
*fl, int *sl)
 *r = *r + t;
 *fl = flsl(*r) - 1;
 *sl = (*r >> (*fl - MAX_LOG2_SLI)) - MAX_SLI;
-*fl -= FLI_OFFSET;
-/*if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
- *fl = *sl = 0;
+/*
+ * It's unclear what was the purpose of the commented-out code that now
+ * is in the #else branch. The current form is motivated by the 
correction
+ * of a violation MISRA:C 2012 Rule 3.1
  */
+#if 1
+*fl -= FLI_OFFSET;
+#else
+if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!


In the message you linked above, you suggested to use /* FL will be always >0! 
*/, why has it changed?
Was some comment I missed? The xen codestyle mandates the use of /* */, anyway 
I agree that here you
are just moving code...
So maybe the maintainer can tell what is the best thing to do here.


You didn't miss any further comment: my suggestion was related to the 
explanatory comment, not the nested comment itself. If a better wording 
can be found for the former, no problem. As for the codestyle point: it 
does not change anything doing

"// FL will be always >0!" -> "/* FL will be always >0!  */
w.r.t. Rule 3.1 (both would have been nested comments).

Regards,

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

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Uwe Kleine-König]

Hello Jani,

On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König  wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> >
> > I think there is a big benefit when these are all renamed to "drm_dev".
> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
> >
> > Some statistics:
> >
> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq 
> > -c | sort -n
> >   1 struct drm_device *adev_to_drm
> >   1 struct drm_device *drm_
> >   1 struct drm_device  *drm_dev
> >   1 struct drm_device*drm_dev
> >   1 struct drm_device *pdev
> >   1 struct drm_device *rdev
> >   1 struct drm_device *vdev
> >   2 struct drm_device *dcss_drv_dev_to_drm
> >   2 struct drm_device **ddev
> >   2 struct drm_device *drm_dev_alloc
> >   2 struct drm_device *mock
> >   2 struct drm_device *p_ddev
> >   5 struct drm_device *device
> >   9 struct drm_device * dev
> >  25 struct drm_device *d
> >  95 struct drm_device *
> > 216 struct drm_device *ddev
> > 234 struct drm_device *drm_dev
> > 611 struct drm_device *drm
> >4190 struct drm_device *dev
> >
> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > it's not only me and others like the result of this effort it should be
> > followed up by adapting the other structs and the individual usages in
> > the different drivers.
> 
> I think this is an unnecessary change. In drm, a dev is usually a drm
> device, i.e. struct drm_device *.

Well, unless it's not. Prominently there is

struct drm_device {
...
struct device *dev;
...
};

which yields quite a few code locations using dev->dev which is
IMHO unnecessary irritating:

$ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l
1633

Also the functions that deal with both a struct device and a struct
drm_device often use "dev" for the struct device and then "ddev" for
the drm_device (see for example amdgpu_device_get_pcie_replay_count()).

> If folks insist on following through with this anyway, I'm firmly in the
> camp the name should be "drm" and nothing else.

Up to now positive feedback is in the majority.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH 01/32] block: Provide blkdev_get_handle_* functions

[Haris Iqbal]

On Thu, Jul 6, 2023 at 5:38 PM Christoph Hellwig  wrote:
>
> On Tue, Jul 04, 2023 at 02:21:28PM +0200, Jan Kara wrote:
> > Create struct bdev_handle that contains all parameters that need to be
> > passed to blkdev_put() and provide blkdev_get_handle_* functions that
> > return this structure instead of plain bdev pointer. This will
> > eventually allow us to pass one more argument to blkdev_put() without
> > too much hassle.
>
> Can we use the opportunity to come up with better names?  blkdev_get_*
> was always a rather horrible naming convention for something that
> ends up calling into ->open.
>
> What about:
>
> struct bdev_handle *bdev_open_by_dev(dev_t dev, blk_mode_t mode, void *holder,
> const struct blk_holder_ops *hops);
> struct bdev_handle *bdev_open_by_path(dev_t dev, blk_mode_t mode,
> void *holder, const struct blk_holder_ops *hops);
> void bdev_release(struct bdev_handle *handle);

+1 to this.
Also, if we are removing "handle" from the function, should the name
of the structure it returns also change? Would something like bdev_ctx
be better?

(Apologies for the previous non-plaintext email)

>
> ?

Re: [XEN PATCH] xen: fix violations of MISRA C:2012 Rule 3.1

[Luca Fancellu]

> On 12 Jul 2023, at 16:54, Nicola Vetrini  wrote:
> 
> In the file 'xen/common/xmalloc_tlsf.c' is not clear how
> the commented-out code should interact with the previous statement.
> To resolve the MISRA violation generated by the nested comment
> a #if .. #endif block with an explanatory comment substitutes
> the earlier construct.
> 
> In the file 'xen/include/xen/atomic.h' the nested comment has been removed,
> since the code sample is already explained by the preceding comment.
> 
> Signed-off-by: Nicola Vetrini 
> ---
> Following the suggestion of this message
> https://lore.kernel.org/xen-devel/536f3049-41f7-b127-ba94-81925e34e...@suse.com/
> an explanatory comment has been added.
> ---
> xen/common/xmalloc_tlsf.c | 13 ++---
> xen/include/xen/atomic.h  |  2 +-
> 2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
> index c21bf71e88..56c3849414 100644
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -139,10 +139,17 @@ static inline void MAPPING_SEARCH(unsigned long *r, int 
> *fl, int *sl)
> *r = *r + t;
> *fl = flsl(*r) - 1;
> *sl = (*r >> (*fl - MAX_LOG2_SLI)) - MAX_SLI;
> -*fl -= FLI_OFFSET;
> -/*if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
> - *fl = *sl = 0;
> +/* 
> + * It's unclear what was the purpose of the commented-out code that 
> now
> + * is in the #else branch. The current form is motivated by the 
> correction
> + * of a violation MISRA:C 2012 Rule 3.1
>  */
> +#if 1
> +*fl -= FLI_OFFSET;
> +#else
> +if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!

In the message you linked above, you suggested to use /* FL will be always >0! 
*/, why has it changed?
Was some comment I missed? The xen codestyle mandates the use of /* */, anyway 
I agree that here you
are just moving code...
So maybe the maintainer can tell what is the best thing to do here.

> +  *fl = *sl = 0;
> +#endif
> *r &= ~t;
> }
> }
> diff --git a/xen/include/xen/atomic.h b/xen/include/xen/atomic.h
> index 529213ebbb..fa750a18ae 100644
> --- a/xen/include/xen/atomic.h
> +++ b/xen/include/xen/atomic.h
> @@ -78,7 +78,7 @@ static inline void _atomic_set(atomic_t *v, int i);
>  *  int old = atomic_read(&v);
>  *  int new = old + 1;
>  *  if ( likely(old == atomic_cmpxchg(&v, old, new)) )
> - *  break; // success!
> + *  break;
>  *  }
>  */
> static inline int atomic_cmpxchg(atomic_t *v, int old, int new);
> -- 
> 2.34.1
> 
> 

Anyway apart from that, the patch looks ok to me.

Reviewed-by: Luca Fancellu 

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

[Anthony PERARD]

On Tue, Jul 11, 2023 at 11:22:26AM +0200, Roger Pau Monne wrote:
> -void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
> +void libxl_cpuid_dispose(libxl_cpuid_policy_list *pl)
>  {
> -int i, j;
> -libxl_cpuid_policy_list cpuid_list = *p_cpuid_list;
> +libxl_cpuid_policy_list policy = *pl;
>  
> -if (cpuid_list == NULL)
> +if (policy == NULL)
>  return;
> -for (i = 0; cpuid_list[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
> -for (j = 0; j < 4; j++)
> -if (cpuid_list[i].policy[j] != NULL) {
> -free(cpuid_list[i].policy[j]);
> -cpuid_list[i].policy[j] = NULL;
> -}
> +
> +if (policy->cpuid) {
> +unsigned int i, j;
> +struct xc_xend_cpuid *cpuid_list = policy->cpuid;
> +
> +for (i = 0; cpuid_list[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) {
> +for (j = 0; j < 4; j++)
> +if (cpuid_list[i].policy[j] != NULL) {
> +free(cpuid_list[i].policy[j]);
> +cpuid_list[i].policy[j] = NULL;
> +}

This looks like a lot of work. We could just call
free(cpuid_list[i].policy[j]) and that's all, as cpuid_list will be gone
right after the loop.

Also, please add {} for the second "for ()" loop.

> +}
> +free(policy->cpuid);
>  }

Beside some the coding style pointing out, the patch looks fine:
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

[XEN PATCH] xen: fix violations of MISRA C:2012 Rule 3.1

[Nicola Vetrini]

In the file 'xen/common/xmalloc_tlsf.c' is not clear how
the commented-out code should interact with the previous statement.
To resolve the MISRA violation generated by the nested comment
a #if .. #endif block with an explanatory comment substitutes
the earlier construct.

In the file 'xen/include/xen/atomic.h' the nested comment has been removed,
since the code sample is already explained by the preceding comment.

Signed-off-by: Nicola Vetrini 
---
Following the suggestion of this message
https://lore.kernel.org/xen-devel/536f3049-41f7-b127-ba94-81925e34e...@suse.com/
an explanatory comment has been added.
---
 xen/common/xmalloc_tlsf.c | 13 ++---
 xen/include/xen/atomic.h  |  2 +-
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
index c21bf71e88..56c3849414 100644
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -139,10 +139,17 @@ static inline void MAPPING_SEARCH(unsigned long *r, int 
*fl, int *sl)
 *r = *r + t;
 *fl = flsl(*r) - 1;
 *sl = (*r >> (*fl - MAX_LOG2_SLI)) - MAX_SLI;
-*fl -= FLI_OFFSET;
-/*if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
- *fl = *sl = 0;
+/* 
+ * It's unclear what was the purpose of the commented-out code that now
+ * is in the #else branch. The current form is motivated by the 
correction
+ * of a violation MISRA:C 2012 Rule 3.1
  */
+#if 1
+*fl -= FLI_OFFSET;
+#else
+if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
+  *fl = *sl = 0;
+#endif
 *r &= ~t;
 }
 }
diff --git a/xen/include/xen/atomic.h b/xen/include/xen/atomic.h
index 529213ebbb..fa750a18ae 100644
--- a/xen/include/xen/atomic.h
+++ b/xen/include/xen/atomic.h
@@ -78,7 +78,7 @@ static inline void _atomic_set(atomic_t *v, int i);
  *  int old = atomic_read(&v);
  *  int new = old + 1;
  *  if ( likely(old == atomic_cmpxchg(&v, old, new)) )
- *  break; // success!
+ *  break;
  *  }
  */
 static inline int atomic_cmpxchg(atomic_t *v, int old, int new);
-- 
2.34.1

Re: [PATCH] x86/ioapic: sanitize IO-APIC pins before enabling the local APIC

[Roger Pau Monné]

On Wed, Jul 12, 2023 at 04:50:34PM +0200, Jan Beulich wrote:
> On 12.07.2023 15:53, Roger Pau Monné wrote:
> > On Wed, Jul 12, 2023 at 12:07:43PM +0200, Jan Beulich wrote:
> >> On 11.07.2023 15:02, Roger Pau Monné wrote:
> >>> On Tue, Jul 11, 2023 at 12:53:31PM +0200, Jan Beulich wrote:
>  On 10.07.2023 16:43, Roger Pau Monné wrote:
> > On Mon, Jul 10, 2023 at 12:56:27PM +0200, Jan Beulich wrote:
> >> On 07.07.2023 11:53, Roger Pau Monne wrote:
> >>> The current logic to init the local APIC and the IO-APIC does init the
> >>> former first before doing any kind of sanitation on the IO-APIC pin
> >>> configuration.  It's already noted on enable_IO_APIC() that Xen
> >>> shouldn't trust the IO-APIC being empty at bootup.
> >>>
> >>> At XenServer we have a system where the IO-APIC 0 is handed to Xen
> >>> with pin 0 unmasked, set to Fixed delivery mode, edge triggered and
> >>> with a vector of 0 (all fields of the RTE are zeroed).  Once the local
> >>> APIC is enabled periodic injections from such pin cause a storm of
> >>> errors:
> >>>
> >>> APIC error on CPU0: 00(40), Received illegal vector
> >>> APIC error on CPU0: 40(40), Received illegal vector
> >>> APIC error on CPU0: 40(40), Received illegal vector
> >>> APIC error on CPU0: 40(40), Received illegal vector
> >>> APIC error on CPU0: 40(40), Received illegal vector
> >>> APIC error on CPU0: 40(40), Received illegal vector
> >>>
> >>> That prevents Xen from booting.
> >>
> >> And I expect no RTE is in ExtInt mode, so one might conclude that
> >> firmware meant to set up RTE 0 that way. Mainly as a remark, albeit
> >> of course there's then the question whether to change the RTE
> >> rather than masking it. What do ACPI tables say?
> >
> > There's one relevant override:
> >
> > [668h 1640   1]Subtable Type : 02 [Interrupt Source 
> > Override]
> > [669h 1641   1]   Length : 0A
> > [66Ah 1642   1]  Bus : 00
> > [66Bh 1643   1]   Source : 00
> > [66Ch 1644   4]Interrupt : 0002
> > [670h 1648   2]Flags (decoded below) : 
> > Polarity : 0
> > Trigger Mode : 0
> >
> > So IRQ 0 -> GSI 2, so it's likely pin 0 is the one the i8259 is
> > connected to.
> 
>  Then wouldn't we be better off converting that RTE to ExtInt? That
>  would allow PIC IRQs (not likely to exist, but still) to work
>  (without undue other side effects afaics), whereas masking this RTE
>  would not.
> >>>
> >>> I'm kind of worry of trying to automate this logic.  Should we always
> >>> convert pin 0 to ExtInt if it's found unmasked, with and invalid
> >>> vector and there's a source override entry for the IRQ?
> >>>
> >>> It seems weird to infer this just from the fact that pin 0 is all
> >>> zeroed out.
> >>
> >> As you say in the earlier paragraph, it wouldn't be just that. It's
> >> unmasked + bad vector + present source override (indicating that
> >> nothing except perhaps a PIC is connected to the pin).
> > 
> > I can do this as a separate patch, but not really here IMO.  The
> > purpose of this patch is strictly to perform the IO-APIC sanitation
> > ahead of enabling the local APIC.  I will add a followup patch to the
> > series, albeit I'm unconvinced we want to infer IO-APIC pin
> > configuration based on firmware miss configurations.
> 
> Hmm. The question really is which of the changes we want to backport.
> That one should be first. While it's largely guesswork, I'd be more
> inclined to take the change that has less of an effect overall.

My views would be the other way around I think.  Current code already
has a comment to notice that IO-APIC pins might be wrongly unmasked,
and there's also logic for masking them when the IO-APICs are
initialized.  The fact that such logic is placed after the local APIC
has been initialized is IMO a bug, as having unmasked unconfigured
IO-APIC pins when the local APIC is enabled should be avoided.

> That said I can see that Linux have their enable_IO_APIC() calls
> also ahead of setup_IO_APIC() (but after connect_bsp_APIC() and
> setup_local_APIC()). IOW with your change we'd do the masking yet
> earlier than them. This may of course even be advantageous, but
> there may also be good reasons for the sequence they're using.

Linux calls enable_IO_APIC() before setting up the local
APIC LVT Error vector (that's done in end_local_APIC_setup()).  That
logic seems to be introduced by commit:

1c69524c2e5b x86: clear IO_APIC before enabing apic error vector.

Might it be less controversial to do like Linux does and call
enable_IO_APIC() before the local APIC ESR is setup?

Thanks, Roger.

Re: Violations of mandatory MISRA C:2012 Rule 19.1 in X86_64 build

[Jan Beulich]

On 11.07.2023 18:40, Roberto Bagnara wrote:
> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> overlapping object) is directly targeted at two undefined behaviors,
> one of which is the subject of 6.5.16.1p3, namely:
> 
>If the value being stored in an object is read from another object
>that overlaps in any way the storage of the first object, then the
>overlap shall be exact and the two objects shall have qualified or
>unqualified versions of a compatible type; otherwise, the behavior
>is undefined.
> 
> You can see a number of definite violations in the X86_64 build
> at this link:
> 
>
> https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/origin/staging/X86_64-Set1/149/PROJECT.ecd;/by_service/MC3R1.R19.1.html

Just to summarize: Except for one instance, all follow the same pattern
of extending in-place a (guest) register value. Sometimes in straight
line code (typically eip -> rip), otherwise in get_rep_prefix() (esi ->
rsi and edi -> rdi). I continue to think that the way we have it is the
best way for it to be written; as per an earlier reply I also can't see
how even a "malicious" compiler (still aiming at generating correct
code, just not necessarily doing things the "obvious" way) could break
those cases. (I understand none of this is going to help, yet I'd like
to clarify that sometimes overly strict rules are getting in the way,
like here forcing use to e.g. switch to using casts when we'd like to
avoid doing so.)

The one other instance is in compat multicall handling. There I guess
the compiler could indeed do things "the wrong way". Any solution there
that I can think of would involve an auxiliary on-stack array, to first
copy into and then out of. That's not very efficient, so I wonder what
your suggestion would be how to deal with such a case.

Jan

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Jani Nikula]

On Wed, 12 Jul 2023, Uwe Kleine-König  wrote:
> Hello,
>
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.
>
> I think there is a big benefit when these are all renamed to "drm_dev".
> I have no strong preference here though, so "drmdev" or "drm" are fine
> for me, too. Let the bikesheding begin!
>
> Some statistics:
>
> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c 
> | sort -n
>   1 struct drm_device *adev_to_drm
>   1 struct drm_device *drm_
>   1 struct drm_device  *drm_dev
>   1 struct drm_device*drm_dev
>   1 struct drm_device *pdev
>   1 struct drm_device *rdev
>   1 struct drm_device *vdev
>   2 struct drm_device *dcss_drv_dev_to_drm
>   2 struct drm_device **ddev
>   2 struct drm_device *drm_dev_alloc
>   2 struct drm_device *mock
>   2 struct drm_device *p_ddev
>   5 struct drm_device *device
>   9 struct drm_device * dev
>  25 struct drm_device *d
>  95 struct drm_device *
> 216 struct drm_device *ddev
> 234 struct drm_device *drm_dev
> 611 struct drm_device *drm
>4190 struct drm_device *dev
>
> This series starts with renaming struct drm_crtc::dev to drm_dev. If
> it's not only me and others like the result of this effort it should be
> followed up by adapting the other structs and the individual usages in
> the different drivers.

I think this is an unnecessary change. In drm, a dev is usually a drm
device, i.e. struct drm_device *. As shown by the numbers above.

If folks insist on following through with this anyway, I'm firmly in the
camp the name should be "drm" and nothing else.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] x86/ioapic: sanitize IO-APIC pins before enabling the local APIC

[Jan Beulich]

On 12.07.2023 15:53, Roger Pau Monné wrote:
> On Wed, Jul 12, 2023 at 12:07:43PM +0200, Jan Beulich wrote:
>> On 11.07.2023 15:02, Roger Pau Monné wrote:
>>> On Tue, Jul 11, 2023 at 12:53:31PM +0200, Jan Beulich wrote:
 On 10.07.2023 16:43, Roger Pau Monné wrote:
> On Mon, Jul 10, 2023 at 12:56:27PM +0200, Jan Beulich wrote:
>> On 07.07.2023 11:53, Roger Pau Monne wrote:
>>> The current logic to init the local APIC and the IO-APIC does init the
>>> former first before doing any kind of sanitation on the IO-APIC pin
>>> configuration.  It's already noted on enable_IO_APIC() that Xen
>>> shouldn't trust the IO-APIC being empty at bootup.
>>>
>>> At XenServer we have a system where the IO-APIC 0 is handed to Xen
>>> with pin 0 unmasked, set to Fixed delivery mode, edge triggered and
>>> with a vector of 0 (all fields of the RTE are zeroed).  Once the local
>>> APIC is enabled periodic injections from such pin cause a storm of
>>> errors:
>>>
>>> APIC error on CPU0: 00(40), Received illegal vector
>>> APIC error on CPU0: 40(40), Received illegal vector
>>> APIC error on CPU0: 40(40), Received illegal vector
>>> APIC error on CPU0: 40(40), Received illegal vector
>>> APIC error on CPU0: 40(40), Received illegal vector
>>> APIC error on CPU0: 40(40), Received illegal vector
>>>
>>> That prevents Xen from booting.
>>
>> And I expect no RTE is in ExtInt mode, so one might conclude that
>> firmware meant to set up RTE 0 that way. Mainly as a remark, albeit
>> of course there's then the question whether to change the RTE
>> rather than masking it. What do ACPI tables say?
>
> There's one relevant override:
>
> [668h 1640   1]Subtable Type : 02 [Interrupt Source 
> Override]
> [669h 1641   1]   Length : 0A
> [66Ah 1642   1]  Bus : 00
> [66Bh 1643   1]   Source : 00
> [66Ch 1644   4]Interrupt : 0002
> [670h 1648   2]Flags (decoded below) : 
> Polarity : 0
> Trigger Mode : 0
>
> So IRQ 0 -> GSI 2, so it's likely pin 0 is the one the i8259 is
> connected to.

 Then wouldn't we be better off converting that RTE to ExtInt? That
 would allow PIC IRQs (not likely to exist, but still) to work
 (without undue other side effects afaics), whereas masking this RTE
 would not.
>>>
>>> I'm kind of worry of trying to automate this logic.  Should we always
>>> convert pin 0 to ExtInt if it's found unmasked, with and invalid
>>> vector and there's a source override entry for the IRQ?
>>>
>>> It seems weird to infer this just from the fact that pin 0 is all
>>> zeroed out.
>>
>> As you say in the earlier paragraph, it wouldn't be just that. It's
>> unmasked + bad vector + present source override (indicating that
>> nothing except perhaps a PIC is connected to the pin).
> 
> I can do this as a separate patch, but not really here IMO.  The
> purpose of this patch is strictly to perform the IO-APIC sanitation
> ahead of enabling the local APIC.  I will add a followup patch to the
> series, albeit I'm unconvinced we want to infer IO-APIC pin
> configuration based on firmware miss configurations.

Hmm. The question really is which of the changes we want to backport.
That one should be first. While it's largely guesswork, I'd be more
inclined to take the change that has less of an effect overall.

That said I can see that Linux have their enable_IO_APIC() calls
also ahead of setup_IO_APIC() (but after connect_bsp_APIC() and
setup_local_APIC()). IOW with your change we'd do the masking yet
earlier than them. This may of course even be advantageous, but
there may also be good reasons for the sequence they're using.

Jan

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

[Anthony PERARD]

On Tue, Jul 11, 2023 at 11:22:25AM +0200, Roger Pau Monne wrote:
> diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c
> index 5b035223f4f5..5e5c8124dd74 100644
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> +static int xc_msr_policy(xc_interface *xch, domid_t domid,
> + const struct xc_msr *msr)
> +{
[...]
> +
> +rc = -ENOMEM;

This `rc' value looks unused, should it be moved to the if true block?

> +if ( (host = calloc(nr_msrs, sizeof(*host))) == NULL ||
> + (def  = calloc(nr_msrs, sizeof(*def)))  == NULL ||
> + (cur  = calloc(nr_msrs, sizeof(*cur)))  == NULL )
> +{
> +ERROR("Unable to allocate memory for %u CPUID leaves", nr_leaves);
> +goto fail;
> +}
> +
> +/* Get the domain's current policy. */
> +nr_leaves = 0;
> +nr_cur = nr_msrs;
> +rc = get_domain_cpu_policy(xch, domid, &nr_leaves, NULL, &nr_cur, cur);
[...]
> +for ( ; msr->index != XC_MSR_INPUT_UNUSED; ++msr )
> +{
> +xen_msr_entry_t *cur_msr = find_msr(cur, nr_cur, msr->index);
> +const xen_msr_entry_t *def_msr = find_msr(def, nr_def, msr->index);
> +const xen_msr_entry_t *host_msr = find_msr(host, nr_host, 
> msr->index);
> +unsigned int i;
> +
> +if ( cur_msr == NULL || def_msr == NULL || host_msr == NULL )
> +{
> +ERROR("Missing MSR %#x", msr->index);
> +rc = -ENOENT;
> +goto fail;
> +}
> +
> +for ( i = 0; i < ARRAY_SIZE(msr->policy) - 1; i++ )
> +{
> +bool val;
> +
> +if ( msr->policy[i] == '1' )
> +val = true;
> +else if ( msr->policy[i] == '0' )
> +val = false;
> +else if ( msr->policy[i] == 'x' )
> +val = test_bit(63 - i, &def_msr->val);
> +else if ( msr->policy[i] == 'k' )
> +val = test_bit(63 - i, &host_msr->val);
> +else
> +{
> +ERROR("Bad character '%c' in policy string '%s'",
> +  msr->policy[i], msr->policy);

Would it be useful to also display msr->index?

> +rc = -EINVAL;
> +goto fail;
> +}
> +
> +clear_bit(63 - i, &cur_msr->val);
> +if ( val )
> +set_bit(63 - i, &cur_msr->val);

Does this need to be first clear then set? A opposed to just do one or
the other.

> +}
> +}
> +
> +/* Feed the transformed policy back up to Xen. */
> +rc = xc_set_domain_cpu_policy(xch, domid, 0, NULL, nr_cur, cur,
> +  &err_leaf, &err_subleaf, &err_msr);
> +if ( rc )
> +{
> +PERROR("Failed to set d%d's policy (err leaf %#x, subleaf %#x, msr 
> %#x)",
> +   domid, err_leaf, err_subleaf, err_msr);
> +rc = -errno;
> +goto fail;
> +}
> +
> +/* Success! */
> +
> + fail:

Even if this label is only used on "fail", the code path is also use on
success. So a label named "out" might be more appropriate.

> +free(cur);
> +free(def);
> +free(host);
> +
> +return rc;
> +}
> +

In any case, patch looks fine to me:
Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

[PATCH 0.5/3] build: make cc-option properly deal with unrecognized sub-options

[Jan Beulich]

In options like -march=, it may be only the sub-option which is
unrecognized by the compiler. In such an event the error message often
splits option and argument, typically saying something like "bad value
'' for ''. Extend the grep invocation to check for
any of the three resulting variants.

To keep things halfway readable, re-wrap and re-indent the entire
construct.

Signed-off-by: Jan Beulich 
---
I'm sorry, re-sending with wider Cc list (as was intended originally).

--- a/Config.mk
+++ b/Config.mk
@@ -90,9 +90,14 @@ PYTHON_PREFIX_ARG ?= --prefix="$(prefix)
 # of which would indicate an "unrecognized command-line option" warning/error.
 #
 # Usage: cflags-y += $(call cc-option,$(CC),-march=winchip-c6,-march=i586)
-cc-option = $(shell if test -z "`echo 'void*p=1;' | \
-  $(1) $(2) -c -o /dev/null -x c - 2>&1 | grep -- 
$(2:-Wa$(comma)%=%) -`"; \
-  then echo "$(2)"; else echo "$(3)"; fi ;)
+cc-option = $(shell pat='$(2:-Wa$(comma)%=%)'; \
+opt="$${pat%%=*}" arg="$${pat\#*=}"; \
+if test -z "`echo 'void*p=1;' | \
+ $(1) $(2) -c -o /dev/null -x c - 2>&1 | \
+ grep -e "$$pat" -e "$$arg.*$$opt" -e 
"$$opt.*$$arg" -`"; \
+then echo "$(2)"; \
+else echo "$(3)"; \
+fi;)
 
 # cc-option-add: Add an option to compilation flags, but only if supported.
 # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6)

[PATCH 0.5/3] build: make cc-option properly deal with unrecognized sub-options

[Jan Beulich]

In options like -march=, it may be only the sub-option which is
unrecognized by the compiler. In such an event the error message often
splits option and argument, typically saying something like "bad value
'' for ''. Extend the grep invocation to check for
any of the three resulting variants.

To keep things halfway readable, re-wrap and re-indent the entire
construct.

Signed-off-by: Jan Beulich 

--- a/Config.mk
+++ b/Config.mk
@@ -90,9 +90,14 @@ PYTHON_PREFIX_ARG ?= --prefix="$(prefix)
 # of which would indicate an "unrecognized command-line option" warning/error.
 #
 # Usage: cflags-y += $(call cc-option,$(CC),-march=winchip-c6,-march=i586)
-cc-option = $(shell if test -z "`echo 'void*p=1;' | \
-  $(1) $(2) -c -o /dev/null -x c - 2>&1 | grep -- 
$(2:-Wa$(comma)%=%) -`"; \
-  then echo "$(2)"; else echo "$(3)"; fi ;)
+cc-option = $(shell pat='$(2:-Wa$(comma)%=%)'; \
+opt="$${pat%%=*}" arg="$${pat\#*=}"; \
+if test -z "`echo 'void*p=1;' | \
+ $(1) $(2) -c -o /dev/null -x c - 2>&1 | \
+ grep -e "$$pat" -e "$$arg.*$$opt" -e 
"$$opt.*$$arg" -`"; \
+then echo "$(2)"; \
+else echo "$(3)"; \
+fi;)
 
 # cc-option-add: Add an option to compilation flags, but only if supported.
 # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6)

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  0a834e953b01ec25c412369d7a5b8b57d340ac60
baseline version:
 xen  3c911be55f1c4e0063e690fb61223df21511b5bb

Last test of basis   181766  2023-07-11 21:02:08 Z0 days
Testing same since   181773  2023-07-12 12:02:02 Z0 days1 attempts


People who touched revisions under test:
  Gianluca Luparini 
  Jan Beulich 
  Roger Pau Monné 
  Simone Ballarin 
  Tamas K Lengyel 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   3c911be55f..0a834e953b  0a834e953b01ec25c412369d7a5b8b57d340ac60 -> smoke

[PATCH] build: correct gas --noexecstack check

[Jan Beulich]

The check was missing an escape for the inner $, thus breaking things
in the unlikely event that the underlying assembler doesn't support this
option.

Fixes: 62d22296a95d ("build: silence GNU ld warning about executable stacks")
Signed-off-by: Jan Beulich 

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -397,7 +397,7 @@ endif
 
 AFLAGS += -D__ASSEMBLY__
 
-$(call cc-option-add,AFLAGS,CC,-Wa$(comma)--noexecstack)
+$(call cc-option-add,AFLAGS,CC,-Wa$$(comma)--noexecstack)
 
 LDFLAGS-$(call ld-option,--warn-rwx-segments) += --no-warn-rwx-segments
 

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Christian König]

Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:

Hello Maxime,

On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:

On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:

Background is that this makes merge conflicts easier to handle and detect.

Really?

FWIW, I agree with Christian here.


Each file (apart from include/drm/drm_crtc.h) is only touched once. So
unless I'm missing something you don't get less or easier conflicts by
doing it all in a single patch. But you gain the freedom to drop a
patch for one driver without having to drop the rest with it.

Not really, because the last patch removed the union anyway. So you have
to revert both the last patch, plus that driver one. And then you need
to add a TODO to remove that union eventually.

Yes, with a single patch you have only one revert (but 194 files changed,
1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1
file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit
bigger). (And maybe you get away with just reverting the last patch.)

With a single patch the TODO after a revert is "redo it all again (and
prepare for a different set of conflicts)" while with the split series
it's only "fix that one driver that was forgotten/borked" + reapply that
10 line patch.


Yeah, but for a maintainer the size of the patches doesn't matter. 
That's only interesting if you need to manually review the patch, which 
you hopefully doesn't do in case of something auto-generated.


In other words if the patch is auto-generated re-applying it completely 
is less work than fixing things up individually.



  As the one who gets that TODO, I prefer the latter.


Yeah, but your personal preferences are not a technical relevant 
argument to a maintainer.


At the end of the day Dave or Daniel need to decide, because they need 
to live with it.


Regards,
Christian.



So in sum: If your metric is "small count of reverted commits", you're
right. If however your metric is: Better get 95% of this series' change
in than maybe 0%, the split series is the way to do it.

With me having spend ~3h on this series' changes, it's maybe
understandable that I did it the way I did.

FTR: This series was created on top of v6.5-rc1. If you apply it to
drm-misc-next you get a (trivial) conflict in patch #2. If I consider to
be the responsible maintainer who applies this series, I like being able
to just do git am --skip then.

FTR#2: In drm-misc-next is a new driver
(drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for
now might indeed be a good idea.


So I still like the split version better, but I'm open to a more
verbose reasoning from your side.

You're doing only one thing here, really: you change the name of a
structure field. If it was shared between multiple maintainers, then
sure, splitting that up is easier for everyone, but this will go through
drm-misc, so I can't see the benefit it brings.

I see your argument, but I think mine weights more.

Best regards
Uwe

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Maxime Ripard]

On Wed, Jul 12, 2023 at 03:38:03PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
> 
> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> > On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > > Background is that this makes merge conflicts easier to handle and 
> > > > detect.
> > > 
> > > Really?
> > 
> > FWIW, I agree with Christian here.
> > 
> > > Each file (apart from include/drm/drm_crtc.h) is only touched once. So
> > > unless I'm missing something you don't get less or easier conflicts by
> > > doing it all in a single patch. But you gain the freedom to drop a
> > > patch for one driver without having to drop the rest with it.
> > 
> > Not really, because the last patch removed the union anyway. So you have
> > to revert both the last patch, plus that driver one. And then you need
> > to add a TODO to remove that union eventually.
> 
> Yes, with a single patch you have only one revert (but 194 files changed,
> 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1
> file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit
> bigger). (And maybe you get away with just reverting the last patch.)
> 
> With a single patch the TODO after a revert is "redo it all again (and
> prepare for a different set of conflicts)" while with the split series
> it's only "fix that one driver that was forgotten/borked" + reapply that
> 10 line patch. As the one who gets that TODO, I prefer the latter.
> 
> So in sum: If your metric is "small count of reverted commits", you're
> right. If however your metric is: Better get 95% of this series' change
> in than maybe 0%, the split series is the way to do it.

I guess that's where we disagree: I don't see the point of having 95% of
it, either 0 or 100.

> With me having spend ~3h on this series' changes, it's maybe
> understandable that I did it the way I did.

I'm sorry, but that's never been an argument? I'm sure you and I both
have had series that took much longer dropped because it wasn't the
right approach.

> FTR: This series was created on top of v6.5-rc1. If you apply it to
> drm-misc-next you get a (trivial) conflict in patch #2. If I consider to
> be the responsible maintainer who applies this series, I like being able
> to just do git am --skip then. 

Or we can ask that the driver is based on drm-misc-next ...

> FTR#2: In drm-misc-next is a new driver
> (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for
> now might indeed be a good idea.

... which is going to fix that one too.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH] x86/ioapic: sanitize IO-APIC pins before enabling the local APIC

[Roger Pau Monné]

On Wed, Jul 12, 2023 at 12:07:43PM +0200, Jan Beulich wrote:
> On 11.07.2023 15:02, Roger Pau Monné wrote:
> > On Tue, Jul 11, 2023 at 12:53:31PM +0200, Jan Beulich wrote:
> >> On 10.07.2023 16:43, Roger Pau Monné wrote:
> >>> On Mon, Jul 10, 2023 at 12:56:27PM +0200, Jan Beulich wrote:
>  On 07.07.2023 11:53, Roger Pau Monne wrote:
> > The current logic to init the local APIC and the IO-APIC does init the
> > former first before doing any kind of sanitation on the IO-APIC pin
> > configuration.  It's already noted on enable_IO_APIC() that Xen
> > shouldn't trust the IO-APIC being empty at bootup.
> >
> > At XenServer we have a system where the IO-APIC 0 is handed to Xen
> > with pin 0 unmasked, set to Fixed delivery mode, edge triggered and
> > with a vector of 0 (all fields of the RTE are zeroed).  Once the local
> > APIC is enabled periodic injections from such pin cause a storm of
> > errors:
> >
> > APIC error on CPU0: 00(40), Received illegal vector
> > APIC error on CPU0: 40(40), Received illegal vector
> > APIC error on CPU0: 40(40), Received illegal vector
> > APIC error on CPU0: 40(40), Received illegal vector
> > APIC error on CPU0: 40(40), Received illegal vector
> > APIC error on CPU0: 40(40), Received illegal vector
> >
> > That prevents Xen from booting.
> 
>  And I expect no RTE is in ExtInt mode, so one might conclude that
>  firmware meant to set up RTE 0 that way. Mainly as a remark, albeit
>  of course there's then the question whether to change the RTE
>  rather than masking it. What do ACPI tables say?
> >>>
> >>> There's one relevant override:
> >>>
> >>> [668h 1640   1]Subtable Type : 02 [Interrupt Source 
> >>> Override]
> >>> [669h 1641   1]   Length : 0A
> >>> [66Ah 1642   1]  Bus : 00
> >>> [66Bh 1643   1]   Source : 00
> >>> [66Ch 1644   4]Interrupt : 0002
> >>> [670h 1648   2]Flags (decoded below) : 
> >>> Polarity : 0
> >>> Trigger Mode : 0
> >>>
> >>> So IRQ 0 -> GSI 2, so it's likely pin 0 is the one the i8259 is
> >>> connected to.
> >>
> >> Then wouldn't we be better off converting that RTE to ExtInt? That
> >> would allow PIC IRQs (not likely to exist, but still) to work
> >> (without undue other side effects afaics), whereas masking this RTE
> >> would not.
> > 
> > I'm kind of worry of trying to automate this logic.  Should we always
> > convert pin 0 to ExtInt if it's found unmasked, with and invalid
> > vector and there's a source override entry for the IRQ?
> > 
> > It seems weird to infer this just from the fact that pin 0 is all
> > zeroed out.
> 
> As you say in the earlier paragraph, it wouldn't be just that. It's
> unmasked + bad vector + present source override (indicating that
> nothing except perhaps a PIC is connected to the pin).

I can do this as a separate patch, but not really here IMO.  The
purpose of this patch is strictly to perform the IO-APIC sanitation
ahead of enabling the local APIC.  I will add a followup patch to the
series, albeit I'm unconvinced we want to infer IO-APIC pin
configuration based on firmware miss configurations.

Thanks, Roger.

[PATCH v3] xen/arm: pci: fix check in pci_check_bar()

[Stewart Hildebrand]

When mapping BARs for vPCI, it's valid for a BAR mfn_t start to equal the BAR
mfn_t end (i.e. start == end) since end is inclusive. However, pci_check_bar()
currently returns false in this case, which results in Xen not mapping the BAR
in the guest 2nd stage page tables. In this example boot log, Linux has mapped
the BARs in the 1st stage, but since Xen did not map them in the 2nd stage,
Linux encounters a data abort and panics:

[2.593300] pci :00:00.0: BAR 0: assigned [mem 0x50008000-0x50008fff]
[2.593682] pci :00:00.0: BAR 2: assigned [mem 0x50009000-0x50009fff]
[2.594066] pci :00:00.0: BAR 4: assigned [mem 0x5000a000-0x5000afff]
...
[2.810502] virtio-pci :00:00.0: enabling device ( -> 0002)
(XEN) :00:00.0: not mapping BAR [50008, 50008] invalid position
(XEN) :00:00.0: not mapping BAR [50009, 50009] invalid position
(XEN) :00:00.0: not mapping BAR [5000a, 5000a] invalid position
[2.817502] virtio-pci :00:00.0: virtio_pci: leaving for legacy driver
[2.817853] virtio-pci :00:00.0: enabling bus mastering
(XEN) arch/arm/traps.c:1992:d0v0 HSR=0x0093010045 pc=0x889507d4 
gva=0x8c46d012 gpa=0x0050008012
[2.818397] Unable to handle kernel ttbr address size fault at virtual 
address 8c46d012
...

Adjust the end physical address e to account for the full page when converting
from mfn, at which point s and e cannot be equal, so drop the equality check in
the condition.

Note that adjusting e to account for the full page also increases the accuracy
of the subsequent is_bar_valid check.

Fixes: cc80e2bab0d0 ("xen/pci: replace call to is_memory_hole to pci_check_bar")
Signed-off-by: Stewart Hildebrand 
Reviewed-by: Roger Pau Monné 
---
v2->v3:
* re-word commit message slightly
* add Roger's R-b

v1->v2:
* adjust e to include full page (e is still inclusive)
* add comment at the top of the function to document that end is inclusive
---
 xen/arch/arm/pci/pci-host-common.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/pci/pci-host-common.c 
b/xen/arch/arm/pci/pci-host-common.c
index 7cdfc89e5211..c0faf0f43675 100644
--- a/xen/arch/arm/pci/pci-host-common.c
+++ b/xen/arch/arm/pci/pci-host-common.c
@@ -393,20 +393,24 @@ static int is_bar_valid(const struct dt_device_node *dev,
 return 0;
 }
 
-/* TODO: Revisit this function when ACPI PCI passthrough support is added. */
+/*
+ * The MFN range [start, end] is inclusive.
+ *
+ * TODO: Revisit this function when ACPI PCI passthrough support is added.
+ */
 bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
 {
 int ret;
 const struct dt_device_node *dt_node;
 paddr_t s = mfn_to_maddr(start);
-paddr_t e = mfn_to_maddr(end);
+paddr_t e = mfn_to_maddr(mfn_add(end, 1)) - 1; /* inclusive */
 struct pdev_bar_check bar_data =  {
 .start = s,
 .end = e,
 .is_valid = false
 };
 
-if ( s >= e )
+if ( s > e )
 return false;
 
 dt_node = pci_find_host_bridge_node(pdev);

base-commit: 0a834e953b01ec25c412369d7a5b8b57d340ac60
-- 
2.41.0

Re: [PATCH 01/32] block: Provide blkdev_get_handle_* functions

[Haris Iqbal]

On Thu, Jul 6, 2023 at 5:38 PM Christoph Hellwig  wrote:

> On Tue, Jul 04, 2023 at 02:21:28PM +0200, Jan Kara wrote:
> > Create struct bdev_handle that contains all parameters that need to be
> > passed to blkdev_put() and provide blkdev_get_handle_* functions that
> > return this structure instead of plain bdev pointer. This will
> > eventually allow us to pass one more argument to blkdev_put() without
> > too much hassle.
>
> Can we use the opportunity to come up with better names?  blkdev_get_*
> was always a rather horrible naming convention for something that
> ends up calling into ->open.
>
> What about:
>
> struct bdev_handle *bdev_open_by_dev(dev_t dev, blk_mode_t mode, void
> *holder,
> const struct blk_holder_ops *hops);
> struct bdev_handle *bdev_open_by_path(dev_t dev, blk_mode_t mode,
> void *holder, const struct blk_holder_ops *hops);
> void bdev_release(struct bdev_handle *handle);
>

+1 to this.
Also, if we are removing "handle" from the function, should the name of the
structure it returns also change? Would something like bdev_ctx be better?


>
> ?
>

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Uwe Kleine-König]

Hello Maxime,

On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > Background is that this makes merge conflicts easier to handle and detect.
> > 
> > Really?
> 
> FWIW, I agree with Christian here.
> 
> > Each file (apart from include/drm/drm_crtc.h) is only touched once. So
> > unless I'm missing something you don't get less or easier conflicts by
> > doing it all in a single patch. But you gain the freedom to drop a
> > patch for one driver without having to drop the rest with it.
> 
> Not really, because the last patch removed the union anyway. So you have
> to revert both the last patch, plus that driver one. And then you need
> to add a TODO to remove that union eventually.

Yes, with a single patch you have only one revert (but 194 files changed,
1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1
file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit
bigger). (And maybe you get away with just reverting the last patch.)

With a single patch the TODO after a revert is "redo it all again (and
prepare for a different set of conflicts)" while with the split series
it's only "fix that one driver that was forgotten/borked" + reapply that
10 line patch. As the one who gets that TODO, I prefer the latter.

So in sum: If your metric is "small count of reverted commits", you're
right. If however your metric is: Better get 95% of this series' change
in than maybe 0%, the split series is the way to do it.

With me having spend ~3h on this series' changes, it's maybe
understandable that I did it the way I did.

FTR: This series was created on top of v6.5-rc1. If you apply it to
drm-misc-next you get a (trivial) conflict in patch #2. If I consider to
be the responsible maintainer who applies this series, I like being able
to just do git am --skip then. 

FTR#2: In drm-misc-next is a new driver
(drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for
now might indeed be a good idea.

> > So I still like the split version better, but I'm open to a more
> > verbose reasoning from your side.
> 
> You're doing only one thing here, really: you change the name of a
> structure field. If it was shared between multiple maintainers, then
> sure, splitting that up is easier for everyone, but this will go through
> drm-misc, so I can't see the benefit it brings.

I see your argument, but I think mine weights more.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH] docs: Fix style in misc/arm/silicon-errata.txt table

[Luca Fancellu]

> On 12 Jul 2023, at 14:04, Michal Orzel  wrote:
> 
> Hi Luca,
> 
> On 12/07/2023 14:04, Luca Fancellu wrote:
>> 
>> 
>> Fix the right border of the silicon-errata.txt table
>> 
>> Fixes: 1814a626fb58 ("xen/arm: Update silicon-errata.txt with the Neovers AT 
>> erratum")
> Fixes tag is for bugs and this one is clearly not.
> With that removed:
> Reviewed-by: Michal Orzel 

Thank you, yeah well I discovered it can be used also on back-ports, so I’ve 
added it, anyway
If maintainer are ok, it can be addressed on commit

> 
> ~Michal
> 

Re: [PATCH] docs: Fix style in misc/arm/silicon-errata.txt table

[Michal Orzel]

Hi Luca,

On 12/07/2023 14:04, Luca Fancellu wrote:
> 
> 
> Fix the right border of the silicon-errata.txt table
> 
> Fixes: 1814a626fb58 ("xen/arm: Update silicon-errata.txt with the Neovers AT 
> erratum")
Fixes tag is for bugs and this one is clearly not.
With that removed:
Reviewed-by: Michal Orzel 

~Michal

Re: [PATCH 1/3] x86: allow Kconfig control over psABI level

[Jan Beulich]

On 12.07.2023 14:33, Jan Beulich wrote:
> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -36,6 +36,10 @@ CFLAGS += -mno-red-zone -fpic
>  # the SSE setup for variadic function calls.
>  CFLAGS += -mno-mmx -mno-sse $(call cc-option,$(CC),-mskip-rax-setup)
>  
> +# Enable the selected baseline ABI, if supported by the compiler.
> +CFLAGS-$(CONFIG_X86_64_V2) += $(call cc-option,$(CC),-march=x86-64-v2)
> +CFLAGS-$(CONFIG_X86_64_V3) += $(call cc-option,$(CC),-march=x86-64-v3)

Hmm, I should have remembered that this won't work with older gcc,
because of how $(cc-option ...) works. I recall someone else already
fell into this trap a few years ago, but then they weren't following
up on the suggestions on how to make their somewhat fragile workaround
more robust. Now I'm on the hook ...

Jan

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Maxime Ripard]

On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > Background is that this makes merge conflicts easier to handle and detect.
> 
> Really?

FWIW, I agree with Christian here.

> Each file (apart from include/drm/drm_crtc.h) is only touched once. So
> unless I'm missing something you don't get less or easier conflicts by
> doing it all in a single patch. But you gain the freedom to drop a
> patch for one driver without having to drop the rest with it.

Not really, because the last patch removed the union anyway. So you have
to revert both the last patch, plus that driver one. And then you need
to add a TODO to remove that union eventually.

> So I still like the split version better, but I'm open to a more
> verbose reasoning from your side.

You're doing only one thing here, really: you change the name of a
structure field. If it was shared between multiple maintainers, then
sure, splitting that up is easier for everyone, but this will go through
drm-misc, so I can't see the benefit it brings.

Maxime


signature.asc
Description: PGP signature

Re: Violations of mandatory MISRA C:2012 Rule 19.1 in X86_64 build

[Simone Ballarin]

Il giorno mer 12 lug 2023 alle ore 14:50 Jan Beulich  ha
scritto:

> On 11.07.2023 18:40, Roberto Bagnara wrote:
> > Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> > overlapping object) is directly targeted at two undefined behaviors,
> > one of which is the subject of 6.5.16.1p3, namely:
> >
> >If the value being stored in an object is read from another object
> >that overlaps in any way the storage of the first object, then the
> >overlap shall be exact and the two objects shall have qualified or
> >unqualified versions of a compatible type; otherwise, the behavior
> >is undefined.
> >
> > You can see a number of definite violations in the X86_64 build
> > at this link:
> >
> >
> https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/origin/staging/X86_64-Set1/149/PROJECT.ecd;/by_service/MC3R1.R19.1.html
>
> Hmm, gives me "Unauthorized".
>

Please try again, now it should work.

Simone Ballarin, M.Sc.

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

Re: Violations of mandatory MISRA C:2012 Rule 19.1 in X86_64 build

[Jan Beulich]

On 11.07.2023 18:40, Roberto Bagnara wrote:
> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> overlapping object) is directly targeted at two undefined behaviors,
> one of which is the subject of 6.5.16.1p3, namely:
> 
>If the value being stored in an object is read from another object
>that overlaps in any way the storage of the first object, then the
>overlap shall be exact and the two objects shall have qualified or
>unqualified versions of a compatible type; otherwise, the behavior
>is undefined.
> 
> You can see a number of definite violations in the X86_64 build
> at this link:
> 
>
> https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/origin/staging/X86_64-Set1/149/PROJECT.ecd;/by_service/MC3R1.R19.1.html

Hmm, gives me "Unauthorized".

> As the rule is mandatory, it cannot be deviated.

Which is odd, and that's in turn because the C spec is overly strict
imo. Considering the one example we looked at yesterday, I have a hard
time seeing what UB there would be on little-endian hardware. Both
fields (rip and eip) don't overlap exactly, but their low halves (which
is all we care about here) do. With this I cannot come up with a way in
which the compiler could screw us up, even if it wanted to.

Jan

[linux-linus test] 181768: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 guest-saverestore.2 fail in 
181765 pass in 181768
 test-amd64-amd64-xl-credit1 20 guest-localmigrate/x10 fail in 181765 pass in 
181768
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 16 guest-localmigrate fail in 
181765 pass in 181768
 test-amd64-amd64-dom0pvh-xl-amd 22 guest-start/debian.repeat fail in 181765 
pass in 181768
 test-amd64-amd64-freebsd11-amd64 21 guest-start/freebsd.repeat fail in 181765 
pass in 181768
 test-arm64-arm64-xl-credit2 18 guest-start/debian.repeat fail in 181765 pass 
in 181768
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 18 guest-localmigrate/x10 fail in 
181765 pass in 181768
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 18 
guest-localmigrate/x10 fail in 181765 pass in 181768
 test-amd64-amd64-xl-multivcpu 22 guest-start/debian.repeat fail pass in 181765
 test-amd64-amd64-xl-credit2  20 guest-localmigrate/x10 fail pass in 181765
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 15 guest-saverestore fail 
pass in 181765
 test-amd64-amd64-xl-shadow   22 guest-start/debian.repeat  fail pass in 181765
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 18 guest-localmigrate/x10 
fail pass in 181765
 test-amd64-amd64-dom0pvh-xl-intel 22 guest-start/debian.repeat fail pass in 
181765

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

version targeted for testing:
 linux3f01e9fed8454dcd89727016c3e5b2fbb8f8e50c
baseline version:
 linux6c538e1adbfc696ac4747fb10d63e704344f763d

Last test of basis   180278  2023-04-16 19:41:46 Z   86 days
Failing since180281  2023-04-17 06:24:36 Z   86 days  172 attempts
Testing same since   181755  2023-07-10 17:42:07 Z1 days4 attempts


3736 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass   

[PATCH 3/3] x86: short-circuit certain cpu_has_* when x86-64-v{2,3} are in effect

[Jan Beulich]

Certain fallback code can be made subject to DCE this way. Note that
CX16 has no compiler provided manifest constant, so CONFIG_* are used
there instead. Note also that we don't have cpu_has_movbe nor
cpu_has_lzcnt (aka cpu_has_abm).

Signed-off-by: Jan Beulich 
---
Of course we could use IS_ENABLED(CONFIG_X86_64_V) everywhere, but as
CX16 shows this isn't necessarily better than the #if/#else approach
based on compiler-provided manifest constants. While not really intended
to be used that way, it looks as if we could also use
IS_ENABLED(__POPCNT__) and alike.

We could go further and also short-circuit SSE*, AVX and alike, which we
don't use outside of the emulator.

--- a/xen/arch/x86/include/asm/cpufeature.h
+++ b/xen/arch/x86/include/asm/cpufeature.h
@@ -76,13 +76,19 @@ static inline bool boot_cpu_has(unsigned
 #define cpu_has_eistboot_cpu_has(X86_FEATURE_EIST)
 #define cpu_has_ssse3   boot_cpu_has(X86_FEATURE_SSSE3)
 #define cpu_has_fma boot_cpu_has(X86_FEATURE_FMA)
-#define cpu_has_cx16boot_cpu_has(X86_FEATURE_CX16)
+#define cpu_has_cx16(IS_ENABLED(CONFIG_X86_64_V2) || \
+ IS_ENABLED(CONFIG_X86_64_V3) || \
+ boot_cpu_has(X86_FEATURE_CX16))
 #define cpu_has_pdcmboot_cpu_has(X86_FEATURE_PDCM)
 #define cpu_has_pcidboot_cpu_has(X86_FEATURE_PCID)
 #define cpu_has_sse4_1  boot_cpu_has(X86_FEATURE_SSE4_1)
 #define cpu_has_sse4_2  boot_cpu_has(X86_FEATURE_SSE4_2)
 #define cpu_has_x2apic  boot_cpu_has(X86_FEATURE_X2APIC)
+#ifdef __POPCNT__
+#define cpu_has_popcnt  true
+#else
 #define cpu_has_popcnt  boot_cpu_has(X86_FEATURE_POPCNT)
+#endif
 #define cpu_has_aesni   boot_cpu_has(X86_FEATURE_AESNI)
 #define cpu_has_xsave   boot_cpu_has(X86_FEATURE_XSAVE)
 #define cpu_has_avx boot_cpu_has(X86_FEATURE_AVX)
@@ -114,11 +120,19 @@ static inline bool boot_cpu_has(unsigned
 #define cpu_has_xsaves  boot_cpu_has(X86_FEATURE_XSAVES)
 
 /* CPUID level 0x0007:0.ebx */
+#ifdef __BMI__
+#define cpu_has_bmi1true
+#else
 #define cpu_has_bmi1boot_cpu_has(X86_FEATURE_BMI1)
+#endif
 #define cpu_has_hle boot_cpu_has(X86_FEATURE_HLE)
 #define cpu_has_avx2boot_cpu_has(X86_FEATURE_AVX2)
 #define cpu_has_smepboot_cpu_has(X86_FEATURE_SMEP)
+#ifdef __BMI2__
+#define cpu_has_bmi2true
+#else
 #define cpu_has_bmi2boot_cpu_has(X86_FEATURE_BMI2)
+#endif
 #define cpu_has_invpcid boot_cpu_has(X86_FEATURE_INVPCID)
 #define cpu_has_rtm boot_cpu_has(X86_FEATURE_RTM)
 #define cpu_has_pqe boot_cpu_has(X86_FEATURE_PQE)

[PATCH 2/3] x86: use POPCNT for hweight() when available

[Jan Beulich]

This is faster than using the software implementation, and the insn is
available on all half-way recent hardware. Use the respective compiler
builtins when available.

Signed-off-by: Jan Beulich 
---
v3: Re-do in a much simpler manner, without alternatives patching.
v2: Also suppress UB sanitizer instrumentation. Reduce macroization in
hweight.c. Exclude clang builds.

--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -475,9 +475,16 @@ static inline int fls(unsigned int x)
  *
  * The Hamming Weight of a number is the total number of bits set in it.
  */
+#ifdef __POPCNT__
+#define hweight64(x) __builtin_popcountll(x)
+#define hweight32(x) __builtin_popcount(x)
+#define hweight16(x) __builtin_popcount((uint16_t)(x))
+#define hweight8(x)  __builtin_popcount((uint8_t)(x))
+#else
 #define hweight64(x) generic_hweight64(x)
 #define hweight32(x) generic_hweight32(x)
 #define hweight16(x) generic_hweight16(x)
 #define hweight8(x) generic_hweight8(x)
+#endif
 
 #endif /* _X86_BITOPS_H */

[PATCH 1/3] x86: allow Kconfig control over psABI level

[Jan Beulich]

Newer hardware offers more efficient and/or flexible and/or capable
instructions, some of which we can make good use of in the hypervisor
as well. Allow a basic way (no alternatives patching) of enabling their
use. Of course this means that hypervisors thus built won't work
anymore on older, less capable hardware.

Signed-off-by: Jan Beulich 
---
TBD: Should we, just like for NX, add an early check in assembly code,
 to have a "clean" failure rather than a random crash?

Whereas the baseline -> v2 step isn't much of a difference (we'll gain
more there by a subsequent patch), v2 -> v3, while presumably (or shall
I say hopefully) faster, yields an overall growth of .text size by (in
my build) about 2k. The primary reason for this appear to be conversions
of SHL-by-immediate to SHLX.

--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -118,6 +118,36 @@ config HVM
 
  If unsure, say Y.
 
+choice
+   prompt "base psABI level"
+   default X86_64_BASELINE
+   help
+ The psABI defines 4 levels of ISA extension sets as a coarse granular
+ way of identifying advanced functionality that would be uniformly
+ available in respectively newer hardware.  While v4 is not really of
+ interest for Xen, the others can be selected here, making the
+ resulting Xen no longer work on older hardware.  This option won't
+ have any effect if the toolchain doesn't support the distinction.
+
+ If unsure, stick to the default.
+
+config X86_64_BASELINE
+   bool "baseline"
+
+config X86_64_V2
+   bool "v2"
+   help
+ This enables POPCNT and CX16, besides other extensions which are of
+ no interest here.
+
+config X86_64_V3
+   bool "v3"
+   help
+ This enables BMI, BMI2, LZCNT, and MOVBE, besides other extensions
+ which are of no interest here.
+
+endchoice
+
 config XEN_SHSTK
bool "Supervisor Shadow Stacks"
depends on HAS_AS_CET_SS
--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -36,6 +36,10 @@ CFLAGS += -mno-red-zone -fpic
 # the SSE setup for variadic function calls.
 CFLAGS += -mno-mmx -mno-sse $(call cc-option,$(CC),-mskip-rax-setup)
 
+# Enable the selected baseline ABI, if supported by the compiler.
+CFLAGS-$(CONFIG_X86_64_V2) += $(call cc-option,$(CC),-march=x86-64-v2)
+CFLAGS-$(CONFIG_X86_64_V3) += $(call cc-option,$(CC),-march=x86-64-v3)
+
 ifeq ($(CONFIG_INDIRECT_THUNK),y)
 # Compile with gcc thunk-extern, indirect-branch-register if available.
 CFLAGS-$(CONFIG_CC_IS_GCC) += -mindirect-branch=thunk-extern

[PATCH 0/3] x86: allow Kconfig control over psABI level

[Jan Beulich]

As discussed in Prague, with some minor add-ons (patch 2 replacing a much
older patch under the same title).

1: allow Kconfig control over psABI level
2: use POPCNT for hweight() when available
3: short-circuit certain cpu_has_* when x86-64-v{2,3} are in effect

Jan

[PATCH] docs: Fix style in misc/arm/silicon-errata.txt table

[Luca Fancellu]

Fix the right border of the silicon-errata.txt table

Fixes: 1814a626fb58 ("xen/arm: Update silicon-errata.txt with the Neovers AT 
erratum")
Signed-off-by: Luca Fancellu 
---
 docs/misc/arm/silicon-errata.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 1925d8fd4ee0..a7abcc1ba16c 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -56,6 +56,6 @@ stable hypervisors.
 | ARM| Cortex-A73  | #858921 | ARM_ERRATUM_858921  
|
 | ARM| Cortex-A76  | #1165522| N/A 
|
 | ARM| Cortex-A76  | #1286807| ARM64_ERRATUM_1286807   
|
-| ARM| Neoverse-N1 | #1165522| N/A
+| ARM| Neoverse-N1 | #1165522| N/A 
|
 | ARM| Neoverse-N1 | #1286807| ARM64_ERRATUM_1286807   
|
 | ARM| MMU-500 | #842869 | N/A 
|
-- 
2.34.1

Re: [RFC PATCH] pci: introduce per-domain PCI rwlock

[Jan Beulich]

On 12.07.2023 13:09, Volodymyr Babchuk wrote:
> Jan Beulich  writes:
> 
>> Up front remark: I'm sorry for some possibly unhelpful replies below. I,
>> for one, am of the opinion that some of the issues you ask about are to
>> be looked into by whoever wants / needs to rework the locking model.
>> After all this (likely) is why nobody has dared to make an attempt before
>> the need became apparent.
> 
> I have no great need desire or need to rework the locking model. I was
> perfectly fine with much narrower vpci_lock. As you remember, it is
> Roger who suggested to extend this lock to the include the whole PCI
> device.
> 
> I already tried something like this as part of the another patch series:
> "[RFC,01/10] xen: pci: add per-domain pci list lock" [1], with the same
> result: it was considered very hard to do this properly, so I dropped
> that effort. I am not so familiar with x86-specific code as a whole and
> IOMMU drivers in particular to be 100% sure that I am doing correct
> changes. Without support from x86 guys I can't do proper patches and
> looks like x86 guys are not interested in this.

That's not the case, no. The problem is time: I don't have the time to
take on this effort myself. I'm willing to help where necessary, within
reasonable bounds. But I can't realistically do large parts of the
analysis that is inevitably needed. (I'm also a little sick of doing
code audits for other, unrelated reasons.) Hence that earlier "up front"
remark.

> So, this is dead end.
> 
> Roger, in [2] I proposed another approach to fix ABBA in modify_bars():
> store copy of BARs in the domain structure. Taking into account that my
> effort to introduce d->pci_lock basically failed (again), I am proposing
> to return back to d->vpci_lock + BARs shadow copy in the domain
> struct. What do you think? And you, Jan?

I support Roger's earlier request, and I think that doing what you
propose would move us further away from where we want to arrive at some
point.

I'm sorry that this is all pretty unpleasant.

Jan

> [1] 
> https://lore.kernel.org/all/20220831141040.13231-2-volodymyr_babc...@epam.com/
> [2] https://lore.kernel.org/all/87ilbfnqmo@epam.com/
> 

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Javier Martinez Canillas]

Uwe Kleine-König  writes:

[dropping some recipients since my SMTP server was complaining about the size]

> Hello Thomas,
>
> On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote:
>> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
>> > Hello,
>> > 
>> > while I debugged an issue in the imx-lcdc driver I was constantly
>> > irritated about struct drm_device pointer variables being named "dev"
>> > because with that name I usually expect a struct device pointer.
>> > 
>> > I think there is a big benefit when these are all renamed to "drm_dev".
>> 
>> If you rename drm_crtc.dev, you should also address *all* other data
>> structures.
>
> Yes. Changing drm_crtc::dev was some effort, so I thought to send that
> one out before doing the same to
>
>   drm_dp_mst_topology_mgr
>   drm_atomic_state
>   drm_master
>   drm_bridge
>   drm_client_dev
>   drm_connector
>   drm_debugfs_entry
>   drm_encoder
>   drm_fb_helper
>   drm_minor
>   drm_framebuffer
>   drm_gem_object
>   drm_plane
>   drm_property
>   drm_property_blob
>   drm_vblank_crtc
>
> when in the end the intention isn't welcome.
>
>> > I have no strong preference here though, so "drmdev" or "drm" are fine
>> > for me, too. Let the bikesheding begin!
>> 
>> We've discussed this to death. IIRC 'drm' would be the prefered choice.
>
> "drm" at least has the advantage to be the 2nd most common name. With
> Paul Kocialkowski prefering "drm_dev" there is no clear favourite yet.

I think that either "drm" or "drm_dev" would be more clear than "dev",
which I also found it confusing and thinking about a "struct device".

Probably leaning to "drm", since as you said is the second most used name
in drivers that assign crtc->dev to a local variable.

> Maybe all the other people with strong opinions are dead if this was
> "discussed to death" before? :-)
>
> Best regards
> Uwe
>
> -- 
> Pengutronix e.K.   | Uwe Kleine-König|
> Industrial Linux Solutions | https://www.pengutronix.de/ |

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Andrzej Hajda]

On 12.07.2023 13:07, Julia Lawall wrote:


On Wed, 12 Jul 2023, Uwe Kleine-König wrote:


On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:

Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:

Hello,

while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.

I think there is a big benefit when these are all renamed to "drm_dev".
I have no strong preference here though, so "drmdev" or "drm" are fine
for me, too. Let the bikesheding begin!

Some statistics:

$ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | 
sort -n
1 struct drm_device *adev_to_drm
1 struct drm_device *drm_
1 struct drm_device  *drm_dev
1 struct drm_device*drm_dev
1 struct drm_device *pdev
1 struct drm_device *rdev
1 struct drm_device *vdev
2 struct drm_device *dcss_drv_dev_to_drm
2 struct drm_device **ddev
2 struct drm_device *drm_dev_alloc
2 struct drm_device *mock
2 struct drm_device *p_ddev
5 struct drm_device *device
9 struct drm_device * dev
   25 struct drm_device *d
   95 struct drm_device *
  216 struct drm_device *ddev
  234 struct drm_device *drm_dev
  611 struct drm_device *drm
 4190 struct drm_device *dev

This series starts with renaming struct drm_crtc::dev to drm_dev. If
it's not only me and others like the result of this effort it should be
followed up by adapting the other structs and the individual usages in
the different drivers.

To make this series a bit easier handleable, I first added an alias for
drm_crtc::dev, then converted the drivers one after another and the last
patch drops the "dev" name. This has the advantage of being easier to
review, and if I should have missed an instance only the last patch must
be dropped/reverted. Also this series might conflict with other patches,
in this case the remaining patches can still go in (apart from the last
one of course). Maybe it also makes sense to delay applying the last
patch by one development cycle?

When you automatically generate the patch (with cocci for example) I usually
prefer a single patch instead.

Maybe I'm too stupid, but only parts of this patch were created by
coccinelle. I failed to convert code like

-   spin_lock_irq(&crtc->dev->event_lock);
+   spin_lock_irq(&crtc->drm_dev->event_lock);

Added Julia to Cc, maybe she has a hint?!

A priori, I see no reason why the rule below should not apply to the above
code.  Is there a parsing problem in the containing function?  You can run

spatch --parse-c file.c

If there is a paring problem, please let me know and i will try to fix it
so the while thing can be done automatically.


I guess some clever macros can fool spatch, at least I observe such 
things in i915 which often uses custom iterators.


Regards
Andrzej



julia


(Up to now it's only

@@
struct drm_crtc *crtc;
@@
-crtc->dev
+crtc->drm_dev

)


Background is that this makes merge conflicts easier to handle and detect.

Really? Each file (apart from include/drm/drm_crtc.h) is only touched
once. So unless I'm missing something you don't get less or easier
conflicts by doing it all in a single patch. But you gain the freedom to
drop a patch for one driver without having to drop the rest with it. So
I still like the split version better, but I'm open to a more verbose
reasoning from your side.


When you have multiple patches and a merge conflict because of some added
lines using the old field the build breaks only on the last patch which
removes the old field.

Then you can revert/drop the last patch without having to respin the
whole single patch and thus caring for still more conflicts that arise
until the new version is sent.

Best regards
Uwe

--
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |

>

Re: [RFC PATCH] pci: introduce per-domain PCI rwlock

[Volodymyr Babchuk]

Hi Jan, Roger,

Jan Beulich  writes:

> Up front remark: I'm sorry for some possibly unhelpful replies below. I,
> for one, am of the opinion that some of the issues you ask about are to
> be looked into by whoever wants / needs to rework the locking model.
> After all this (likely) is why nobody has dared to make an attempt before
> the need became apparent.

I have no great need desire or need to rework the locking model. I was
perfectly fine with much narrower vpci_lock. As you remember, it is
Roger who suggested to extend this lock to the include the whole PCI
device.

I already tried something like this as part of the another patch series:
"[RFC,01/10] xen: pci: add per-domain pci list lock" [1], with the same
result: it was considered very hard to do this properly, so I dropped
that effort. I am not so familiar with x86-specific code as a whole and
IOMMU drivers in particular to be 100% sure that I am doing correct
changes. Without support from x86 guys I can't do proper patches and
looks like x86 guys are not interested in this. So, this is dead end.

Roger, in [2] I proposed another approach to fix ABBA in modify_bars():
store copy of BARs in the domain structure. Taking into account that my
effort to introduce d->pci_lock basically failed (again), I am proposing
to return back to d->vpci_lock + BARs shadow copy in the domain
struct. What do you think? And you, Jan?

[1] 
https://lore.kernel.org/all/20220831141040.13231-2-volodymyr_babc...@epam.com/
[2] https://lore.kernel.org/all/87ilbfnqmo@epam.com/

-- 
WBR, Volodymyr

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Julia Lawall]

On Wed, 12 Jul 2023, Uwe Kleine-König wrote:

> On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > > Hello,
> > >
> > > while I debugged an issue in the imx-lcdc driver I was constantly
> > > irritated about struct drm_device pointer variables being named "dev"
> > > because with that name I usually expect a struct device pointer.
> > >
> > > I think there is a big benefit when these are all renamed to "drm_dev".
> > > I have no strong preference here though, so "drmdev" or "drm" are fine
> > > for me, too. Let the bikesheding begin!
> > >
> > > Some statistics:
> > >
> > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq 
> > > -c | sort -n
> > >1 struct drm_device *adev_to_drm
> > >1 struct drm_device *drm_
> > >1 struct drm_device  *drm_dev
> > >1 struct drm_device*drm_dev
> > >1 struct drm_device *pdev
> > >1 struct drm_device *rdev
> > >1 struct drm_device *vdev
> > >2 struct drm_device *dcss_drv_dev_to_drm
> > >2 struct drm_device **ddev
> > >2 struct drm_device *drm_dev_alloc
> > >2 struct drm_device *mock
> > >2 struct drm_device *p_ddev
> > >5 struct drm_device *device
> > >9 struct drm_device * dev
> > >   25 struct drm_device *d
> > >   95 struct drm_device *
> > >  216 struct drm_device *ddev
> > >  234 struct drm_device *drm_dev
> > >  611 struct drm_device *drm
> > > 4190 struct drm_device *dev
> > >
> > > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > > it's not only me and others like the result of this effort it should be
> > > followed up by adapting the other structs and the individual usages in
> > > the different drivers.
> > >
> > > To make this series a bit easier handleable, I first added an alias for
> > > drm_crtc::dev, then converted the drivers one after another and the last
> > > patch drops the "dev" name. This has the advantage of being easier to
> > > review, and if I should have missed an instance only the last patch must
> > > be dropped/reverted. Also this series might conflict with other patches,
> > > in this case the remaining patches can still go in (apart from the last
> > > one of course). Maybe it also makes sense to delay applying the last
> > > patch by one development cycle?
> >
> > When you automatically generate the patch (with cocci for example) I usually
> > prefer a single patch instead.
>
> Maybe I'm too stupid, but only parts of this patch were created by
> coccinelle. I failed to convert code like
>
> -   spin_lock_irq(&crtc->dev->event_lock);
> +   spin_lock_irq(&crtc->drm_dev->event_lock);
>
> Added Julia to Cc, maybe she has a hint?!

A priori, I see no reason why the rule below should not apply to the above
code.  Is there a parsing problem in the containing function?  You can run

spatch --parse-c file.c

If there is a paring problem, please let me know and i will try to fix it
so the while thing can be done automatically.

julia

>
> (Up to now it's only
>
> @@
> struct drm_crtc *crtc;
> @@
> -crtc->dev
> +crtc->drm_dev
>
> )
>
> > Background is that this makes merge conflicts easier to handle and detect.
>
> Really? Each file (apart from include/drm/drm_crtc.h) is only touched
> once. So unless I'm missing something you don't get less or easier
> conflicts by doing it all in a single patch. But you gain the freedom to
> drop a patch for one driver without having to drop the rest with it. So
> I still like the split version better, but I'm open to a more verbose
> reasoning from your side.
>
> > When you have multiple patches and a merge conflict because of some added
> > lines using the old field the build breaks only on the last patch which
> > removes the old field.
>
> Then you can revert/drop the last patch without having to respin the
> whole single patch and thus caring for still more conflicts that arise
> until the new version is sent.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.   | Uwe Kleine-König|
> Industrial Linux Solutions | https://www.pengutronix.de/ |
>

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Uwe Kleine-König]

On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> > 
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> > 
> > I think there is a big benefit when these are all renamed to "drm_dev".
> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
> > 
> > Some statistics:
> > 
> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq 
> > -c | sort -n
> >1 struct drm_device *adev_to_drm
> >1 struct drm_device *drm_
> >1 struct drm_device  *drm_dev
> >1 struct drm_device*drm_dev
> >1 struct drm_device *pdev
> >1 struct drm_device *rdev
> >1 struct drm_device *vdev
> >2 struct drm_device *dcss_drv_dev_to_drm
> >2 struct drm_device **ddev
> >2 struct drm_device *drm_dev_alloc
> >2 struct drm_device *mock
> >2 struct drm_device *p_ddev
> >5 struct drm_device *device
> >9 struct drm_device * dev
> >   25 struct drm_device *d
> >   95 struct drm_device *
> >  216 struct drm_device *ddev
> >  234 struct drm_device *drm_dev
> >  611 struct drm_device *drm
> > 4190 struct drm_device *dev
> > 
> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > it's not only me and others like the result of this effort it should be
> > followed up by adapting the other structs and the individual usages in
> > the different drivers.
> > 
> > To make this series a bit easier handleable, I first added an alias for
> > drm_crtc::dev, then converted the drivers one after another and the last
> > patch drops the "dev" name. This has the advantage of being easier to
> > review, and if I should have missed an instance only the last patch must
> > be dropped/reverted. Also this series might conflict with other patches,
> > in this case the remaining patches can still go in (apart from the last
> > one of course). Maybe it also makes sense to delay applying the last
> > patch by one development cycle?
> 
> When you automatically generate the patch (with cocci for example) I usually
> prefer a single patch instead.

Maybe I'm too stupid, but only parts of this patch were created by
coccinelle. I failed to convert code like

-   spin_lock_irq(&crtc->dev->event_lock);
+   spin_lock_irq(&crtc->drm_dev->event_lock);

Added Julia to Cc, maybe she has a hint?!

(Up to now it's only 

@@
struct drm_crtc *crtc;
@@
-crtc->dev
+crtc->drm_dev

)

> Background is that this makes merge conflicts easier to handle and detect.

Really? Each file (apart from include/drm/drm_crtc.h) is only touched
once. So unless I'm missing something you don't get less or easier
conflicts by doing it all in a single patch. But you gain the freedom to
drop a patch for one driver without having to drop the rest with it. So
I still like the split version better, but I'm open to a more verbose
reasoning from your side.

> When you have multiple patches and a merge conflict because of some added
> lines using the old field the build breaks only on the last patch which
> removes the old field.

Then you can revert/drop the last patch without having to respin the
whole single patch and thus caring for still more conflicts that arise
until the new version is sent.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [XEN PATCH v3 15/15] xen: fix violations of MISRA C:2012 Rule 7.2

[Jan Beulich]

On 12.07.2023 12:32, Simone Ballarin wrote:
> From: Gianluca Luparini 
> 
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline states:
> "A 'u' or 'U' suffix shall be applied to all integer constants
> that are represented in an unsigned type".
> 
> Add the 'U' suffix to integers literals with unsigned type.
> 
> Fot the sake of uniformity, the following changes are made:
> - add the 'U' suffix to all integer constants before the
>   '?' operator in 'bitops.h'
> 
> Signed-off-by: Gianluca Luparini 
> Signed-off-by: Simone Ballarin 
> Reviewed-by: Stefano Stabellini 

Acked-by: Jan Beulich 
with ...

> --- a/xen/lib/muldiv64.c
> +++ b/xen/lib/muldiv64.c
> @@ -27,7 +27,7 @@ uint64_t muldiv64(uint64_t a, uint32_t b, uint32_t c)
>  rh = (uint64_t)u.l.high * (uint64_t)b;
>  rh += (rl >> 32);
>  res.l.high = rh / c;
> -res.l.low = (((rh % c) << 32) + (rl & 0x)) / c;
> +res.l.low = (((rh % c) << 32) + ((uint32_t)rl)) / c;

... the excess pair of parentheses here dropped (which I'll do while
committing).

Jan

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Uwe Kleine-König]

Hello Thomas,

On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> > 
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> > 
> > I think there is a big benefit when these are all renamed to "drm_dev".
> 
> If you rename drm_crtc.dev, you should also address *all* other data
> structures.

Yes. Changing drm_crtc::dev was some effort, so I thought to send that
one out before doing the same to

drm_dp_mst_topology_mgr
drm_atomic_state
drm_master
drm_bridge
drm_client_dev
drm_connector
drm_debugfs_entry
drm_encoder
drm_fb_helper
drm_minor
drm_framebuffer
drm_gem_object
drm_plane
drm_property
drm_property_blob
drm_vblank_crtc

when in the end the intention isn't welcome.

> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
> 
> We've discussed this to death. IIRC 'drm' would be the prefered choice.

"drm" at least has the advantage to be the 2nd most common name. With
Paul Kocialkowski prefering "drm_dev" there is no clear favourite yet.
Maybe all the other people with strong opinions are dead if this was
"discussed to death" before? :-)

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [XEN PATCH v3 14/15] ACPI/APEI: fix violations of MISRA C:2012 Rule 7.2

[Jan Beulich]

On 12.07.2023 12:32, Simone Ballarin wrote:
> From: Gianluca Luparini 
> 
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline states:
> "A 'u' or 'U' suffix shall be applied to all integer constants
> that are represented in an unsigned type".
> 
> Add the 'U' suffix to integers literals with unsigned type.
> 
> For the sake of uniformity, the following changes are made:
> - add the 'U' suffix to all first macro's arguments in 'cper.h'
> 
> Signed-off-by: Gianluca Luparini 
> Signed-off-by: Simone Ballarin 

Acked-by: Jan Beulich 

Re: [XEN PATCH v3 10/15] x86/monitor: fix violations of MISRA C:2012 Rule 7.2

[Jan Beulich]

On 12.07.2023 12:32, Simone Ballarin wrote:
> From: Gianluca Luparini 
> 
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline states:
> "A 'u' or 'U' suffix shall be applied to all integer constants
> that are represented in an unsigned type".
> 
> Add the 'U' suffix to integers literals with unsigned type and also to other
> literals used in the same contexts or near violations, when their positive
> nature is immediately clear. The latter changes are done for the sake of
> uniformity.
> 
> Signed-off-by: Gianluca Luparini 
> Signed-off-by: Simone Ballarin 
> Reviewed-by: Stefano Stabellini 

Looks like you've lost Tamas'es ack here.

Jan

Re: [XEN PATCH v3 07/15] x86/vmx: fix violations of MISRA C:2012 Rule 7.2

[Jan Beulich]

On 12.07.2023 12:32, Simone Ballarin wrote:
> From: Gianluca Luparini 
> 
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline states:
> "A 'u' or 'U' suffix shall be applied to all integer constants
> that are represented in an unsigned type".
> 
> Add the 'U' suffix to integers literals with unsigned type.
> 
> For the sake of uniformity, the following changes are made:
> - add the 'U' suffix to macros near
>   'CPU_BASED_ACTIVATE_SECONDARY_CONTROLS' and
>   'SECONDARY_EXEC_NOTIFY_VM_EXITING' macros in 'vmcs.h'
> - add the 'U' suffix to macros near 'INTR_INFO_VALID_MASK'
>   macro in 'vmx.h'
> 
> Signed-off-by: Gianluca Luparini 
> Signed-off-by: Simone Ballarin 
> Reviewed-by: Stefano Stabellini 
> ---
> Changes in v3:
> - change 'Signed-off-by' ordering
> - change commit message
> - remove unnecessary changes in 'vvmx.c'
> - add 'uint32_t' casts in 'vvmx.c'
> - add missing 'U' in 'vmcs.h' macros
> - change macro to '(1u << 31)' in 'vmx.h'
> - remove unnecessary changes to 'vmx.h'

With this many changes I don't think you can retain an R-b, unless
the person it came from really explicitly agreed with at least all
not purely cosmetic changes (which I don't think was the case here).

Irrespective:
Reviewed-by: Jan Beulich 

Jan

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Christian König]

Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:

Hello,

while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.

I think there is a big benefit when these are all renamed to "drm_dev".
I have no strong preference here though, so "drmdev" or "drm" are fine
for me, too. Let the bikesheding begin!

Some statistics:

$ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | 
sort -n
   1 struct drm_device *adev_to_drm
   1 struct drm_device *drm_
   1 struct drm_device  *drm_dev
   1 struct drm_device*drm_dev
   1 struct drm_device *pdev
   1 struct drm_device *rdev
   1 struct drm_device *vdev
   2 struct drm_device *dcss_drv_dev_to_drm
   2 struct drm_device **ddev
   2 struct drm_device *drm_dev_alloc
   2 struct drm_device *mock
   2 struct drm_device *p_ddev
   5 struct drm_device *device
   9 struct drm_device * dev
  25 struct drm_device *d
  95 struct drm_device *
 216 struct drm_device *ddev
 234 struct drm_device *drm_dev
 611 struct drm_device *drm
4190 struct drm_device *dev

This series starts with renaming struct drm_crtc::dev to drm_dev. If
it's not only me and others like the result of this effort it should be
followed up by adapting the other structs and the individual usages in
the different drivers.

To make this series a bit easier handleable, I first added an alias for
drm_crtc::dev, then converted the drivers one after another and the last
patch drops the "dev" name. This has the advantage of being easier to
review, and if I should have missed an instance only the last patch must
be dropped/reverted. Also this series might conflict with other patches,
in this case the remaining patches can still go in (apart from the last
one of course). Maybe it also makes sense to delay applying the last
patch by one development cycle?


When you automatically generate the patch (with cocci for example) I 
usually prefer a single patch instead.


Background is that this makes merge conflicts easier to handle and detect.

When you have multiple patches and a merge conflict because of some 
added lines using the old field the build breaks only on the last patch 
which removes the old field.


In such cases reviewing the patch just means automatically re-generating 
it and double checking that you don't see anything funky.


Apart from that I honestly absolutely don't care what the name is.

Cheers,
Christian.



The series was compile tested for arm, arm64, powerpc and amd64 using an
allmodconfig (though I only build drivers/gpu/).

Best regards
Uwe

Uwe Kleine-König (52):
   drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
   drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/armada: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/aspeed: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/exynos: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/gma500: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/hyperv: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/ingenic: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/logicvc: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/mediatek: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/meson: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/mgag200: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/nouveau: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/pl111: Use struct d

Re: [XEN PATCH v3 06/15] xen/efi: fix violations of MISRA C:2012 Rule 7.2

[Jan Beulich]

On 12.07.2023 12:32, Simone Ballarin wrote:
> From: Gianluca Luparini 
> 
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline states:
> "A 'u' or 'U' suffix shall be applied to all integer constants
> that are represented in an unsigned type".
> 
> Add the 'U' suffix to integers literals with unsigned type.
> 
> For the sake of uniformity, the following changes are made:
> - add the 'U' suffix to all first macro's arguments in 'boot.c'
> - add the 'U' suffix near '0x3fff' in 'runtime.c'
> 
> Signed-off-by: Gianluca Luparini 
> Signed-off-by: Simone Ballarin 
> Reviewed-by: Luca Fancellu 
> Reviewed-by: Stefano Stabellini 

Acked-by: Jan Beulich 

Re: [XEN PATCH v3 03/15] x86/svm: fix violations of MISRA C:2012 Rule 7.2

[Jan Beulich]

On 12.07.2023 12:32, Simone Ballarin wrote:
> --- a/xen/arch/x86/hvm/svm/asid.c
> +++ b/xen/arch/x86/hvm/svm/asid.c
> @@ -16,7 +16,7 @@ void svm_asid_init(const struct cpuinfo_x86 *c)
>  
>  /* Check for erratum #170, and leave ASIDs disabled if it's present. */
>  if ( !cpu_has_amd_erratum(c, AMD_ERRATUM_170) )
> -nasids = cpuid_ebx(0x800A);
> +nasids = cpuid_ebx(0x800AU);

When resubmitting it would be really nice if you made changes that earlier
on were indicated could otherwise be done while committing.

Jan

Re: [XEN PATCH v3 00/15] xen: fix violations of MISRA C:2012 Rule 7.2

[Jan Beulich]

On 12.07.2023 12:32, Simone Ballarin wrote:
> Changes to macros 'X86_CR0_PG' and 'MSR_EFER' in files
> "xen/arch/x86/include/asm/x86-defns.h" and 
> "xen/arch/x86/include/asm/msr-index.h"
> are not made since they are used also in assembly files.

I guess I overlooked this in earlier versions. There's no need to skip
such headers. You just can't attach U unconditionally; you need to use
_AC() (from xen/const.h), as msr-index.h already does in certain places.

Jan

[XEN PATCH v3 11/15] xen/vpci: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Stefano Stabellini 
---
Changes in v3:
- change 'Signed-off-by' ordering
- add 'uint32_t' casts in 'msi.c' and 'msix.c'

Changes in v2:
- minor change to commit title
- change commit message
---
 xen/drivers/vpci/msi.c  | 2 +-
 xen/drivers/vpci/msix.c | 2 +-
 xen/drivers/vpci/vpci.c | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index 8f2b59e61a..bf5fe2f981 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -124,7 +124,7 @@ static void cf_check address_hi_write(
 struct vpci_msi *msi = data;
 
 /* Clear and update high part. */
-msi->address &= 0x;
+msi->address  = (uint32_t)msi->address;
 msi->address |= (uint64_t)val << 32;
 
 update_msi(pdev, msi);
diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 25bde77586..2090168f42 100644
--- a/xen/drivers/vpci/msix.c
+++ b/xen/drivers/vpci/msix.c
@@ -531,7 +531,7 @@ static int cf_check msix_write(
 
 case PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET:
 entry->updated = true;
-entry->addr &= 0x;
+entry->addr  = (uint32_t)entry->addr;
 entry->addr |= (uint64_t)data << 32;
 break;
 
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index d73fa76302..3bec9a4153 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -319,7 +319,7 @@ static void vpci_write_hw(pci_sbdf_t sbdf, unsigned int 
reg, unsigned int size,
 static uint32_t merge_result(uint32_t data, uint32_t new, unsigned int size,
  unsigned int offset)
 {
-uint32_t mask = 0x >> (32 - 8 * size);
+uint32_t mask = 0xU >> (32 - 8 * size);
 
 return (data & ~(mask << (offset * 8))) | ((new & mask) << (offset * 8));
 }
@@ -402,7 +402,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, 
unsigned int size)
 data = merge_result(data, tmp_data, size - data_offset, data_offset);
 }
 
-return data & (0x >> (32 - 8 * size));
+return data & (0xU >> (32 - 8 * size));
 }
 
 /*
@@ -427,7 +427,7 @@ static void vpci_write_helper(const struct pci_dev *pdev,
 data = merge_result(val, data, size, offset);
 }
 
-r->write(pdev, r->offset, data & (0x >> (32 - 8 * r->size)),
+r->write(pdev, r->offset, data & (0xU >> (32 - 8 * r->size)),
  r->private);
 }
 
-- 
2.41.0

[XEN PATCH v3 12/15] xen/x86: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type.

For the sake of uniformity, the following changes are made:
- add the 'U' suffix to all first macro's arguments in 'mce-apei.c'
- add the 'U' suffix to switch cases in 'cpuid.c'
- add 'U' suffixes to 'mask16' in 'stdvga.c'
- add the 'U' suffix to macros in 'pci.h'

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
---
Changes in v3:
- change 'Signed-off-by' ordering
- change commit message
- add 'UL' in 'extable.c'
- fix indentation in 'cpu-policy.c'
- remove excessive suffixes in 'mce-apei.c'
- add 'UL' in 'x86-defns.h'
- remove changes to 'sr_mask' and 'gr_mask' in 'stdvga.c'
- move 'viridian.c' and 'hyperv-tlfs.h' in a separate commit

Changes in v2:
- minor change to commit title
- change commit message
- remove comments from 'gr_mask' in 'stdvga.c'
- correct code style in 'trace.h'
- add fix in 'extable.c'
- remove changes in 'x86-defns.h', 'msr-index.h' and 'xen-x86_64.h'
---
 xen/arch/x86/apic.c|   2 +-
 xen/arch/x86/cpu-policy.c  |  18 +--
 xen/arch/x86/cpu/mcheck/mce-apei.c |   4 +-
 xen/arch/x86/cpuid.c   |   8 +-
 xen/arch/x86/efi/efi-boot.h|   6 +-
 xen/arch/x86/extable.c |   2 +-
 xen/arch/x86/hvm/hypercall.c   |   2 +-
 xen/arch/x86/hvm/irq.c |   2 +-
 xen/arch/x86/hvm/pmtimer.c |   4 +-
 xen/arch/x86/hvm/stdvga.c  |  50 +++---
 xen/arch/x86/hvm/vlapic.c  |   6 +-
 xen/arch/x86/include/asm/apicdef.h |   2 +-
 xen/arch/x86/include/asm/config.h  |   2 +-
 xen/arch/x86/include/asm/hpet.h|   2 +-
 xen/arch/x86/include/asm/hvm/trace.h   |   4 +-
 xen/arch/x86/include/asm/hvm/vioapic.h |   2 +-
 xen/arch/x86/include/asm/msi.h |   2 +-
 xen/arch/x86/include/asm/msr-index.h   | 202 -
 xen/arch/x86/include/asm/pci.h |   8 +-
 xen/arch/x86/include/asm/x86-defns.h   |   2 +-
 xen/arch/x86/percpu.c  |   2 +-
 xen/arch/x86/psr.c |   2 +-
 xen/arch/x86/spec_ctrl.c   |   8 +-
 xen/arch/x86/x86_64/acpi_mmcfg.c   |   2 +-
 xen/arch/x86/x86_64/pci.c  |   2 +-
 xen/arch/x86/x86_emulate/x86_emulate.h |   2 +-
 xen/lib/x86/cpuid.c|   8 +-
 xen/lib/x86/policy.c   |   2 +-
 28 files changed, 179 insertions(+), 179 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index f71474d47d..03c5c0f2ee 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1211,7 +1211,7 @@ static void __init calibrate_APIC_clock(void)
  * Setup the APIC counter to maximum. There is no way the lapic
  * can underflow in the 100ms detection time frame.
  */
-__setup_APIC_LVTT(0x);
+__setup_APIC_LVTT(0xU);
 
 bus_freq = calibrate_apic_timer();
 if ( !bus_freq )
diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index f40eeb8be8..5977e21a07 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -321,7 +321,7 @@ static void recalculate_misc(struct cpu_policy *p)
 p->extd.vendor_edx = p->basic.vendor_edx;
 
 p->extd.raw_fms = p->basic.raw_fms;
-p->extd.raw[0x1].b &= 0xff00;
+p->extd.raw[0x1].b &= 0xff00U;
 p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
 
 p->extd.raw[0x8].a &= 0x; /* GuestMaxPhysAddr hidden. */
@@ -378,10 +378,10 @@ static void __init calculate_host_policy(void)
  * this information.
  */
 if ( cpu_has_lfence_dispatch )
-max_extd_leaf = max(max_extd_leaf, 0x8021);
+max_extd_leaf = max(max_extd_leaf, 0x8021U);
 
-p->extd.max_leaf = 0x8000 | min_t(uint32_t, max_extd_leaf & 0x,
-  ARRAY_SIZE(p->extd.raw) - 1);
+p->extd.max_leaf = 0x8000U | min_t(uint32_t, max_extd_leaf & 0xU,
+   ARRAY_SIZE(p->extd.raw) - 1);
 
 x86_cpu_featureset_to_policy(boot_cpu_data.x86_capability, p);
 recalculate_xstate(p);
@@ -768,11 +768,11 @@ void recalculate_cpuid_policy(struct domain *d)
 
 p->basic.max_leaf   = min(p->basic.max_leaf,   max->basic.max_leaf);
 p->feat.max_subleaf = min(p->feat.max_subleaf, max->feat.max_subleaf);
-p->extd.max_leaf= 0x8000 | min(p->extd.max_leaf & 0x,
-   ((p->x86_vendor & (X86_VENDOR_AMD |
-  
X86_VENDOR_HYGON))
-? CPUID_GUEST_NR_EXTD_AMD
-: CPUID_GUEST_NR_EXTD_INTEL) - 1);
+p->extd.max_leaf= 0x8000U | m

[XEN PATCH v3 13/15] x86/viridian: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
---
Changes in v3:
- create this commit for 'viridian.c' and 'hyperv-tlfs.h'
---
 xen/arch/x86/hvm/viridian/viridian.c |  2 +-
 xen/arch/x86/include/asm/guest/hyperv-tlfs.h | 28 ++--
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian/viridian.c 
b/xen/arch/x86/hvm/viridian/viridian.c
index 7405c117bc..61171e3363 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -291,7 +291,7 @@ static void enable_hypercall_page(struct domain *d)
  * calling convention) to differentiate Xen and Viridian hypercalls.
  */
 *(u8  *)(p + 0) = 0x0d; /* orl $0x8000, %eax */
-*(u32 *)(p + 1) = 0x8000;
+*(u32 *)(p + 1) = 0x8000U;
 *(u8  *)(p + 5) = 0x0f; /* vmcall/vmmcall */
 *(u8  *)(p + 6) = 0x01;
 *(u8  *)(p + 7) = (cpu_has_vmx ? 0xc1 : 0xd9);
diff --git a/xen/arch/x86/include/asm/guest/hyperv-tlfs.h 
b/xen/arch/x86/include/asm/guest/hyperv-tlfs.h
index 38f997a0c8..a6915ad731 100644
--- a/xen/arch/x86/include/asm/guest/hyperv-tlfs.h
+++ b/xen/arch/x86/include/asm/guest/hyperv-tlfs.h
@@ -471,30 +471,30 @@ typedef struct _HV_REFERENCE_TSC_PAGE {
 
 /* Define hypervisor message types. */
 enum hv_message_type {
-   HVMSG_NONE  = 0x,
+   HVMSG_NONE  = 0xU,
 
/* Memory access messages. */
-   HVMSG_UNMAPPED_GPA  = 0x8000,
-   HVMSG_GPA_INTERCEPT = 0x8001,
+   HVMSG_UNMAPPED_GPA  = 0x8000U,
+   HVMSG_GPA_INTERCEPT = 0x8001U,
 
/* Timer notification messages. */
-   HVMSG_TIMER_EXPIRED = 0x8010,
+   HVMSG_TIMER_EXPIRED = 0x8010U,
 
/* Error messages. */
-   HVMSG_INVALID_VP_REGISTER_VALUE = 0x8020,
-   HVMSG_UNRECOVERABLE_EXCEPTION   = 0x8021,
-   HVMSG_UNSUPPORTED_FEATURE   = 0x8022,
+   HVMSG_INVALID_VP_REGISTER_VALUE = 0x8020U,
+   HVMSG_UNRECOVERABLE_EXCEPTION   = 0x8021U,
+   HVMSG_UNSUPPORTED_FEATURE   = 0x8022U,
 
/* Trace buffer complete messages. */
-   HVMSG_EVENTLOG_BUFFERCOMPLETE   = 0x8040,
+   HVMSG_EVENTLOG_BUFFERCOMPLETE   = 0x8040U,
 
/* Platform-specific processor intercept messages. */
-   HVMSG_X64_IOPORT_INTERCEPT  = 0x8001,
-   HVMSG_X64_MSR_INTERCEPT = 0x80010001,
-   HVMSG_X64_CPUID_INTERCEPT   = 0x80010002,
-   HVMSG_X64_EXCEPTION_INTERCEPT   = 0x80010003,
-   HVMSG_X64_APIC_EOI  = 0x80010004,
-   HVMSG_X64_LEGACY_FP_ERROR   = 0x80010005
+   HVMSG_X64_IOPORT_INTERCEPT  = 0x8001U,
+   HVMSG_X64_MSR_INTERCEPT = 0x80010001U,
+   HVMSG_X64_CPUID_INTERCEPT   = 0x80010002U,
+   HVMSG_X64_EXCEPTION_INTERCEPT   = 0x80010003U,
+   HVMSG_X64_APIC_EOI  = 0x80010004U,
+   HVMSG_X64_LEGACY_FP_ERROR   = 0x80010005U
 };
 
 /* Define synthetic interrupt controller message flags. */
-- 
2.41.0

[XEN PATCH v3 15/15] xen: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type.

Fot the sake of uniformity, the following changes are made:
- add the 'U' suffix to all integer constants before the
  '?' operator in 'bitops.h'

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Stefano Stabellini 
---
Changes in v3:
- change 'Signed-off-by' ordering
- change commit message
- fix in 'muldiv64.c'
- add changes to 'bitops.h' macros
- move 'cper.h' in a separate commit

Changes in v2:
- minor change to commit title
- change commit message
- add '(uint32_t)' in 'muldiv64.c' for consistency
- add fix in 'vesa.c'
---
 xen/common/gunzip.c  |  2 +-
 xen/common/xmalloc_tlsf.c|  2 +-
 xen/drivers/char/ehci-dbgp.c |  4 ++--
 xen/drivers/video/vesa.c |  2 +-
 xen/include/public/memory.h  |  2 +-
 xen/include/public/sysctl.h  |  4 ++--
 xen/include/xen/bitops.h | 10 +-
 xen/lib/muldiv64.c   |  2 +-
 8 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/common/gunzip.c b/xen/common/gunzip.c
index 71ec5f26be..b810499be2 100644
--- a/xen/common/gunzip.c
+++ b/xen/common/gunzip.c
@@ -11,7 +11,7 @@ static unsigned char *__initdata window;
 static memptr __initdata free_mem_ptr;
 static memptr __initdata free_mem_end_ptr;
 
-#define WSIZE   0x8000
+#define WSIZE   0x8000U
 
 static unsigned char *__initdata inbuf;
 static unsigned int __initdata insize;
diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
index 75bdf18c4e..c21bf71e88 100644
--- a/xen/common/xmalloc_tlsf.c
+++ b/xen/common/xmalloc_tlsf.c
@@ -46,7 +46,7 @@
 #define BHDR_OVERHEAD   (sizeof(struct bhdr) - MIN_BLOCK_SIZE)
 
 #define PTR_MASK(sizeof(void *) - 1)
-#define BLOCK_SIZE_MASK (0x - PTR_MASK)
+#define BLOCK_SIZE_MASK (0xU - PTR_MASK)
 
 #define GET_NEXT_BLOCK(addr, r) ((struct bhdr *) \
 ((char *)(addr) + (r)))
diff --git a/xen/drivers/char/ehci-dbgp.c b/xen/drivers/char/ehci-dbgp.c
index bb9d3198d9..4d8d765122 100644
--- a/xen/drivers/char/ehci-dbgp.c
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -375,12 +375,12 @@ static inline u32 dbgp_pid_write_update(u32 x, u32 tok)
 static u8 data0 = USB_PID_DATA1;
 
 data0 ^= USB_PID_DATA0 ^ USB_PID_DATA1;
-return (x & 0x) | (data0 << 8) | (tok & 0xff);
+return (x & 0xU) | (data0 << 8) | (tok & 0xffU);
 }
 
 static inline u32 dbgp_pid_read_update(u32 x, u32 tok)
 {
-return (x & 0xff00) | (tok & 0xff);
+return (x & 0xff00U) | (tok & 0xffU);
 }
 
 static inline void dbgp_set_data(struct ehci_dbg_port __iomem *ehci_debug,
diff --git a/xen/drivers/video/vesa.c b/xen/drivers/video/vesa.c
index c41f6b8d40..b007ff5678 100644
--- a/xen/drivers/video/vesa.c
+++ b/xen/drivers/video/vesa.c
@@ -123,7 +123,7 @@ void __init vesa_init(void)
 if ( vlfb_info.bits_per_pixel > 8 )
 {
 /* Light grey in truecolor. */
-unsigned int grey = 0x;
+unsigned int grey = 0xU;
 lfbp.pixel_on =
 ((grey >> (32 - vlfb_info.  red_size)) << vlfb_info.  red_pos) |
 ((grey >> (32 - vlfb_info.green_size)) << vlfb_info.green_pos) |
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5f0d31e23..5e545ae9a4 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -234,7 +234,7 @@ struct xen_add_to_physmap {
 
 unsigned int space; /* => enum phys_map_space */
 
-#define XENMAPIDX_grant_table_status 0x8000
+#define XENMAPIDX_grant_table_status 0x8000U
 
 /* Index into space being mapped. */
 xen_ulong_t idx;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 33e86ace51..fa7147de47 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -384,7 +384,7 @@ struct xen_sysctl_pm_op {
 struct xen_set_cpufreq_para set_para;
 uint64_aligned_t get_avgfreq;
 uint32_tset_sched_opt_smt;
-#define XEN_SYSCTL_CX_UNLIMITED 0x
+#define XEN_SYSCTL_CX_UNLIMITED 0xU
 uint32_tget_max_cstate;
 uint32_tset_max_cstate;
 } u;
@@ -547,7 +547,7 @@ struct xen_sysctl_numainfo {
 #define XEN_SYSCTL_CPUPOOL_OP_RMCPU 5  /* R */
 #define XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN6  /* M */
 #define XEN_SYSCTL_CPUPOOL_OP_FREEINFO  7  /* F */
-#define XEN_SYSCTL_CPUPOOL_PAR_ANY 0x
+#define XEN_SYSCTL_CPUPOOL_PAR_ANY 0xU
 struct xen_sysctl_cpupool_op {
 uint32_t op;  /* IN */
 uint32_t cpupool_id;  /* IN: CDIARM OUT: CI */
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index 4cd0310789..e926047932 

[XEN PATCH v3 14/15] ACPI/APEI: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type.

For the sake of uniformity, the following changes are made:
- add the 'U' suffix to all first macro's arguments in 'cper.h'

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
---
Changes in v3:
- create this commit for 'cper.h'
---
 xen/include/xen/cper.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/include/xen/cper.h b/xen/include/xen/cper.h
index f8e5272bc1..7c6a4c45ce 100644
--- a/xen/include/xen/cper.h
+++ b/xen/include/xen/cper.h
@@ -56,7 +56,7 @@ static inline uint64_t cper_next_record_id(void)
 #define CPER_SIG_RECORD"CPER"
 #define CPER_SIG_SIZE  4
 /* Used in signature_end field in struct cper_record_header */
-#define CPER_SIG_END   0x
+#define CPER_SIG_END   0xU
 
 /*
  * CPER record header revision, used in revision field in struct
@@ -80,35 +80,35 @@ static inline uint64_t cper_next_record_id(void)
  * Corrected Machine Check
  */
 #define CPER_NOTIFY_CMC
\
-   UUID_LE(0x2DCE8BB1, 0xBDD7, 0x450e, 0xB9, 0xAD, 0x9C, 0xF4, \
+   UUID_LE(0x2DCE8BB1U, 0xBDD7, 0x450e, 0xB9, 0xAD, 0x9C, 0xF4,\
0xEB, 0xD4, 0xF8, 0x90)
 /* Corrected Platform Error */
 #define CPER_NOTIFY_CPE
\
-   UUID_LE(0x4E292F96, 0xD843, 0x4a55, 0xA8, 0xC2, 0xD4, 0x81, \
+   UUID_LE(0x4E292F96U, 0xD843, 0x4a55, 0xA8, 0xC2, 0xD4, 0x81,\
0xF2, 0x7E, 0xBE, 0xEE)
 /* Machine Check Exception */
 #define CPER_NOTIFY_MCE
\
-   UUID_LE(0xE8F56FFE, 0x919C, 0x4cc5, 0xBA, 0x88, 0x65, 0xAB, \
+   UUID_LE(0xE8F56FFEU, 0x919C, 0x4cc5, 0xBA, 0x88, 0x65, 0xAB,\
0xE1, 0x49, 0x13, 0xBB)
 /* PCI Express Error */
 #define CPER_NOTIFY_PCIE   \
-   UUID_LE(0xCF93C01F, 0x1A16, 0x4dfc, 0xB8, 0xBC, 0x9C, 0x4D, \
+   UUID_LE(0xCF93C01FU, 0x1A16, 0x4dfc, 0xB8, 0xBC, 0x9C, 0x4D,\
0xAF, 0x67, 0xC1, 0x04)
 /* INIT Record (for IPF) */
 #define CPER_NOTIFY_INIT   \
-   UUID_LE(0xCC5263E8, 0x9308, 0x454a, 0x89, 0xD0, 0x34, 0x0B, \
+   UUID_LE(0xCC5263E8U, 0x9308, 0x454a, 0x89, 0xD0, 0x34, 0x0B,\
0xD3, 0x9B, 0xC9, 0x8E)
 /* Non-Maskable Interrupt */
 #define CPER_NOTIFY_NMI
\
-   UUID_LE(0x5BAD89FF, 0xB7E6, 0x42c9, 0x81, 0x4A, 0xCF, 0x24, \
+   UUID_LE(0x5BAD89FFU, 0xB7E6, 0x42c9, 0x81, 0x4A, 0xCF, 0x24,\
0x85, 0xD6, 0xE9, 0x8A)
 /* BOOT Error Record */
 #define CPER_NOTIFY_BOOT   \
-   UUID_LE(0x3D61A466, 0xAB40, 0x409a, 0xA6, 0x98, 0xF3, 0x62, \
+   UUID_LE(0x3D61A466U, 0xAB40, 0x409a, 0xA6, 0x98, 0xF3, 0x62,\
0xD4, 0x64, 0xB3, 0x8F)
 /* DMA Remapping Error */
 #define CPER_NOTIFY_DMAR   \
-   UUID_LE(0x667DD791, 0xC6B3, 0x4c27, 0x8A, 0x6B, 0x0F, 0x8E, \
+   UUID_LE(0x667DD791U, 0xC6B3, 0x4c27, 0x8A, 0x6B, 0x0F, 0x8E,\
0x72, 0x2D, 0xEB, 0x41)
 
 /*
-- 
2.41.0

[XEN PATCH v3 10/15] x86/monitor: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Stefano Stabellini 
---
Changes in v3:
- change 'Signed-off-by' ordering

Changes in v2:
- change commit title to make it unique
- change commit message
---
 xen/arch/x86/monitor.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index d4857faf8a..dc336c239a 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -48,17 +48,17 @@ static unsigned long *monitor_bitmap_for_msr(const struct 
domain *d, u32 *msr)
 
 switch ( *msr )
 {
-case 0 ... 0x1fff:
+case 0 ... 0x1fffU:
 BUILD_BUG_ON(sizeof(d->arch.monitor.msr_bitmap->low) * 8 <= 0x1fff);
 return d->arch.monitor.msr_bitmap->low;
 
-case 0x4000 ... 0x40001fff:
+case 0x4000U ... 0x40001fffU:
 BUILD_BUG_ON(
 sizeof(d->arch.monitor.msr_bitmap->hypervisor) * 8 <= 0x1fff);
 *msr &= 0x1fff;
 return d->arch.monitor.msr_bitmap->hypervisor;
 
-case 0xc000 ... 0xc0001fff:
+case 0xc000U ... 0xc0001fffU:
 BUILD_BUG_ON(sizeof(d->arch.monitor.msr_bitmap->high) * 8 <= 0x1fff);
 *msr &= 0x1fff;
 return d->arch.monitor.msr_bitmap->high;
-- 
2.41.0

[XEN PATCH v3 07/15] x86/vmx: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type.

For the sake of uniformity, the following changes are made:
- add the 'U' suffix to macros near
  'CPU_BASED_ACTIVATE_SECONDARY_CONTROLS' and
  'SECONDARY_EXEC_NOTIFY_VM_EXITING' macros in 'vmcs.h'
- add the 'U' suffix to macros near 'INTR_INFO_VALID_MASK'
  macro in 'vmx.h'

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Stefano Stabellini 
---
Changes in v3:
- change 'Signed-off-by' ordering
- change commit message
- remove unnecessary changes in 'vvmx.c'
- add 'uint32_t' casts in 'vvmx.c'
- add missing 'U' in 'vmcs.h' macros
- change macro to '(1u << 31)' in 'vmx.h'
- remove unnecessary changes to 'vmx.h'

Changes in v2:
- minor change to commit title
- change commit message
- remove unnecessary changes in 'vpmu_intel.c' and 'vmx.h'
- add 'ULL' suffix in 'vpmu_intel.c'
- add zero-padding to constants in 'vmx.h'
- add missing 'U' in 'vmx.h'
---
 xen/arch/x86/cpu/vpmu_intel.c   |  2 +-
 xen/arch/x86/hvm/vmx/vmcs.c |  6 +-
 xen/arch/x86/hvm/vmx/vvmx.c |  8 +--
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 84 -
 xen/arch/x86/include/asm/hvm/vmx/vmx.h  | 16 ++---
 5 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index fa5b40c65c..6330c89b47 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -945,7 +945,7 @@ const struct arch_vpmu_ops *__init core2_vpmu_init(void)
 fixed_counters_mask = ~((1ull << core2_get_bitwidth_fix_count()) - 1);
 global_ctrl_mask = ~1ULL << fixed_pmc_cnt) - 1) << 32) |
  ((1ULL << arch_pmc_cnt) - 1));
-global_ovf_ctrl_mask = ~(0xC000 |
+global_ovf_ctrl_mask = ~(0xC000ULL |
  (((1ULL << fixed_pmc_cnt) - 1) << 32) |
  ((1ULL << arch_pmc_cnt) - 1));
 if ( version > 2 )
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index b209563625..d5a2b847a9 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -911,7 +911,7 @@ void vmx_clear_msr_intercept(struct vcpu *v, unsigned int 
msr,
 if ( type & VMX_MSR_W )
 clear_bit(msr, msr_bitmap->write_low);
 }
-else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
+else if ( (msr >= 0xc000U) && (msr <= 0xc0001fffU) )
 {
 msr &= 0x1fff;
 if ( type & VMX_MSR_R )
@@ -939,7 +939,7 @@ void vmx_set_msr_intercept(struct vcpu *v, unsigned int msr,
 if ( type & VMX_MSR_W )
 set_bit(msr, msr_bitmap->write_low);
 }
-else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
+else if ( (msr >= 0xc000U) && (msr <= 0xc0001fffU) )
 {
 msr &= 0x1fff;
 if ( type & VMX_MSR_R )
@@ -957,7 +957,7 @@ bool vmx_msr_is_intercepted(struct vmx_msr_bitmap 
*msr_bitmap,
 if ( msr <= 0x1fff )
 return test_bit(msr, is_write ? msr_bitmap->write_low
   : msr_bitmap->read_low);
-else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
+else if ( (msr >= 0xc000U) && (msr <= 0xc0001fffU) )
 return test_bit(msr & 0x1fff, is_write ? msr_bitmap->write_high
: msr_bitmap->read_high);
 else
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 16b0ef82b6..b7be424afb 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -263,7 +263,7 @@ uint64_t get_vvmcs_virtual(void *vvmcs, uint32_t 
vmcs_encoding)
 res >>= 32;
 break;
 case VVMCS_WIDTH_32:
-res &= 0x;
+res = (uint32_t)res;
 break;
 case VVMCS_WIDTH_NATURAL:
 default:
@@ -315,14 +315,14 @@ void set_vvmcs_virtual(void *vvmcs, uint32_t 
vmcs_encoding, uint64_t val)
 case VVMCS_WIDTH_64:
 if ( enc.access_type )
 {
-res &= 0x;
+res = (uint32_t)res;
 res |= val << 32;
 }
 else
 res = val;
 break;
 case VVMCS_WIDTH_32:
-res = val & 0x;
+res = (uint32_t)val;
 break;
 case VVMCS_WIDTH_NATURAL:
 default:
@@ -2306,7 +2306,7 @@ int nvmx_msr_read_intercept(unsigned int msr, u64 
*msr_content)
 break;
 case MSR_IA32_VMX_CR0_FIXED1:
 /* allow 0-settings for all bits */
-data = 0x;
+data = 0xU;
 break;
 case MSR_IA32_VMX_CR4_FIXED0:
 /* VMXE bit must be 1 in VMX operation */
diff --git a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h 
b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
index d07fcb2b

[XEN PATCH v3 09/15] xen/public: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type.

For the sake of uniformity, the following changes are made:
- add the 'U' suffix to integer constants before the '?' operator

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Juergen Gross 
Reviewed-by: Stefano Stabellini 
---
Changes in v3:
- change 'Signed-off-by' ordering
- change commit message

Changes in v2:
- minor change to commit title
- change commit message
- correct macros code style
---
 xen/include/public/io/ring.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 025939278b..0cae4367be 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -36,11 +36,11 @@
 typedef unsigned int RING_IDX;
 
 /* Round a 32-bit unsigned constant down to the nearest power of two. */
-#define __RD2(_x)  (((_x) & 0x0002) ? 0x2  : ((_x) & 0x1))
-#define __RD4(_x)  (((_x) & 0x000c) ? __RD2((_x)>>2)<<2: __RD2(_x))
-#define __RD8(_x)  (((_x) & 0x00f0) ? __RD4((_x)>>4)<<4: __RD4(_x))
-#define __RD16(_x) (((_x) & 0xff00) ? __RD8((_x)>>8)<<8: __RD8(_x))
-#define __RD32(_x) (((_x) & 0x) ? __RD16((_x)>>16)<<16 : __RD16(_x))
+#define __RD2(x)  (((x) & 0x0002U) ? 0x2 : ((x) & 0x1))
+#define __RD4(x)  (((x) & 0x000cU) ? __RD2((x) >> 2) << 2: __RD2(x))
+#define __RD8(x)  (((x) & 0x00f0U) ? __RD4((x) >> 4) << 4: __RD4(x))
+#define __RD16(x) (((x) & 0xff00U) ? __RD8((x) >> 8) << 8: __RD8(x))
+#define __RD32(x) (((x) & 0xU) ? __RD16((x) >> 16) << 16 : __RD16(x))
 
 /*
  * Calculate size of a shared ring, given the total available space for the
-- 
2.41.0

[XEN PATCH v3 06/15] xen/efi: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type.

For the sake of uniformity, the following changes are made:
- add the 'U' suffix to all first macro's arguments in 'boot.c'
- add the 'U' suffix near '0x3fff' in 'runtime.c'

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Luca Fancellu 
Reviewed-by: Stefano Stabellini 
---
Changes in v3:
- change 'Signed-off-by' ordering
- change commit message
- remove excessive suffixes in 'boot.c'

Changes in v2:
- minor change to commit title
- change commit message
- remove changes in 'efibind.h', 'efiapi.h', 'efidef.h' and 'efiprot.h'
---
 xen/common/efi/boot.c| 8 
 xen/common/efi/runtime.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index c5850c26af..24169b7b50 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -34,13 +34,13 @@
 #define EFI_REVISION(major, minor) (((major) << 16) | (minor))
 
 #define SMBIOS3_TABLE_GUID \
-  { 0xf2fd1544, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 
0x94} }
+  { 0xf2fd1544U, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3, 
0x94} }
 #define SHIM_LOCK_PROTOCOL_GUID \
-  { 0x605dab50, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 
0x23} }
+  { 0x605dab50U, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 
0x23} }
 #define APPLE_PROPERTIES_PROTOCOL_GUID \
-  { 0x91bd12fe, 0xf6c3, 0x44fb, { 0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 
0xe0} }
+  { 0x91bd12feU, 0xf6c3, 0x44fb, {0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 
0xe0} }
 #define EFI_SYSTEM_RESOURCE_TABLE_GUID\
-  { 0xb122a263, 0x3661, 0x4f68, {0x99, 0x29, 0x78, 0xf8, 0xb0, 0xd6, 0x21, 
0x80} }
+  { 0xb122a263U, 0x3661, 0x4f68, {0x99, 0x29, 0x78, 0xf8, 0xb0, 0xd6, 0x21, 
0x80} }
 #define EFI_SYSTEM_RESOURCE_TABLE_FIRMWARE_RESOURCE_VERSION 1
 
 typedef struct {
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 13b0975866..5cb7504c96 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -698,7 +698,7 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
 #ifndef COMPAT
 op->status = status;
 #else
-op->status = (status & 0x3fff) | ((status >> 32) & 0xc000);
+op->status = (status & 0x3fffU) | ((status >> 32) & 0xc000U);
 #endif
 
 return rc;
-- 
2.41.0

[XEN PATCH v3 08/15] xen/pci: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
Changes in v3:
- change 'Signed-off-by' ordering

Changes in v2:
- minor change to commit title
- change commit message
---
 xen/drivers/passthrough/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 07d1986d33..95846e84f2 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -990,8 +990,8 @@ bool_t __init pci_device_detect(u16 seg, u8 bus, u8 dev, u8 
func)
 
 vendor = pci_conf_read32(PCI_SBDF(seg, bus, dev, func), PCI_VENDOR_ID);
 /* some broken boards return 0 or ~0 if a slot is empty: */
-if ( (vendor == 0x) || (vendor == 0x) ||
- (vendor == 0x) || (vendor == 0x) )
+if ( (vendor == 0xU) || (vendor == 0xU) ||
+ (vendor == 0xU) || (vendor == 0xU) )
 return 0;
 return 1;
 }
-- 
2.41.0

[XEN PATCH v3 04/15] xen/arm: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
---
Changes in v3:
- change 'Signed-off-by' ordering
- add 'ULL' instead of 'U' in 'efibind.h' and 'vgic-v3.c'
- remove excessive suffixes in 'efi-boot.h' and 'smccc.h'

Changes in v2:
- minor change to commit title
- change commit message
- fix in 'domain_build.c' file for consistency
- fix typo in 'gic-v2.c' file
- fix in 'insn.h' file for consistency
- add fixes in 'gic-v3.c', 'traps.c' and 'vgic-v3.c'
---
 xen/arch/arm/domain_build.c  |  4 ++--
 xen/arch/arm/efi/efi-boot.h  |  2 +-
 xen/arch/arm/gic-v2.c|  6 +++---
 xen/arch/arm/gic-v3.c| 10 +-
 xen/arch/arm/include/asm/arm64/brk.h |  2 +-
 xen/arch/arm/include/asm/arm64/efibind.h | 10 +-
 xen/arch/arm/include/asm/arm64/insn.h| 16 
 xen/arch/arm/include/asm/vreg.h  |  2 +-
 xen/arch/arm/kernel.c|  2 +-
 xen/arch/arm/traps.c | 14 +++---
 xen/arch/arm/vgic-v2.c   |  2 +-
 xen/arch/arm/vgic-v3.c   |  2 +-
 xen/include/public/arch-arm/smccc.h  |  4 ++--
 13 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d0d6be922d..d58604ef4a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3751,8 +3751,8 @@ static int __init construct_domain(struct domain *d, 
struct kernel_info *kinfo)
  * r1 = machine nr, r2 = atags or dtb pointer.
  *...
  */
-regs->r0 = 0; /* SBZ */
-regs->r1 = 0x; /* We use DTB therefore no machine id */
+regs->r0 = 0U; /* SBZ */
+regs->r1 = 0xU; /* We use DTB therefore no machine id */
 regs->r2 = kinfo->dtb_paddr;
 }
 #ifdef CONFIG_ARM_64
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index bb64925d70..3daa63a40d 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -46,7 +46,7 @@ static int get_module_file_index(const char *name, unsigned 
int name_len);
 static void PrintMessage(const CHAR16 *s);
 
 #define DEVICE_TREE_GUID \
-{0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0}}
+{0xb1b621d5U, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0}}
 
 static struct file __initdata dtbfile;
 static void __initdata *fdt;
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 6476ff4230..cf392bfd1c 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -386,9 +386,9 @@ static void gicv2_cpu_init(void)
 /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
  * even though they are controlled with GICD registers, they must
  * be set up here with the other per-cpu state. */
-writel_gicd(0x, GICD_ICACTIVER); /* Diactivate PPIs and SGIs */
-writel_gicd(0x, GICD_ICENABLER); /* Disable all PPI */
-writel_gicd(0x, GICD_ISENABLER); /* Enable all SGI */
+writel_gicd(0xU, GICD_ICACTIVER); /* De-activate PPIs and SGIs */
+writel_gicd(0xU, GICD_ICENABLER); /* Disable all PPI */
+writel_gicd(0xU, GICD_ISENABLER); /* Enable all SGI */
 
 /* Set SGI priorities */
 for ( i = 0; i < 16; i += 4 )
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 4e6c98bada..95e4f020fe 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -619,8 +619,8 @@ static void __init gicv3_dist_init(void)
 /* Disable/deactivate all global interrupts */
 for ( i = NR_GIC_LOCAL_IRQS; i < nr_lines; i += 32 )
 {
-writel_relaxed(0x, GICD + GICD_ICENABLER + (i / 32) * 4);
-writel_relaxed(0x, GICD + GICD_ICACTIVER + (i / 32) * 4);
+writel_relaxed(0xU, GICD + GICD_ICENABLER + (i / 32) * 4);
+writel_relaxed(0xU, GICD + GICD_ICACTIVER + (i / 32) * 4);
 }
 
 /*
@@ -832,13 +832,13 @@ static int gicv3_cpu_init(void)
  * The activate state is unknown at boot, so make sure all
  * SGIs and PPIs are de-activated.
  */
-writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICACTIVER0);
+writel_relaxed(0xU, GICD_RDIST_SGI_BASE + GICR_ICACTIVER0);
 /*
  * Disable all PPI interrupts, ensure all SGI interrupts are
  * enabled.
  */
-writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICENABLER0);
-writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ISENAB

[XEN PATCH v3 01/15] x86/cpufreq: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
Changes in v3:
- change 'Signed-off-by' ordering

Changes in v2:
- change commit title to make it unique
- change commit message
---
 xen/arch/x86/acpi/cpufreq/powernow.c  | 14 +++---
 xen/include/acpi/cpufreq/processor_perf.h |  2 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c 
b/xen/arch/x86/acpi/cpufreq/powernow.c
index d4c7dcd5d9..8e0784b69c 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -32,14 +32,14 @@
 #include 
 #include 
 
-#define HW_PSTATE_MASK  0x0007
-#define HW_PSTATE_VALID_MASK0x8000
-#define HW_PSTATE_MAX_MASK  0x00f0
+#define HW_PSTATE_MASK  0x0007U
+#define HW_PSTATE_VALID_MASK0x8000U
+#define HW_PSTATE_MAX_MASK  0x00f0U
 #define HW_PSTATE_MAX_SHIFT 4
-#define MSR_PSTATE_DEF_BASE 0xc0010064 /* base of Pstate MSRs */
-#define MSR_PSTATE_STATUS   0xc0010063 /* Pstate Status MSR */
-#define MSR_PSTATE_CTRL 0xc0010062 /* Pstate control MSR */
-#define MSR_PSTATE_CUR_LIMIT0xc0010061 /* pstate current limit MSR */
+#define MSR_PSTATE_DEF_BASE 0xc0010064U /* base of Pstate MSRs */
+#define MSR_PSTATE_STATUS   0xc0010063U /* Pstate Status MSR */
+#define MSR_PSTATE_CTRL 0xc0010062U /* Pstate control MSR */
+#define MSR_PSTATE_CUR_LIMIT0xc0010061U /* pstate current limit MSR */
 #define MSR_HWCR_CPBDIS_MASK0x0200ULL
 
 #define ARCH_CPU_FLAG_RESUME   1
diff --git a/xen/include/acpi/cpufreq/processor_perf.h 
b/xen/include/acpi/cpufreq/processor_perf.h
index d8a1ba68a6..8b5a1b9bde 100644
--- a/xen/include/acpi/cpufreq/processor_perf.h
+++ b/xen/include/acpi/cpufreq/processor_perf.h
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-#define XEN_PX_INIT 0x8000
+#define XEN_PX_INIT 0x8000U
 
 int powernow_cpufreq_init(void);
 unsigned int powernow_register_driver(void);
-- 
2.41.0

[XEN PATCH v3 00/15] xen: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose headline
states:
"A 'u' or 'U' suffix shall be applied to all integer constants that are
represented in an unsigned type".

These violations are caused by the missing "u" or "U" suffix in unsigned
integer constants, such as:

xen/arch/x86/hvm/hypercall.c:132.17-132.26
if ( (eax & 0x8000) && is_viridian_domain(currd) )

If a rule is not met, fixes are needed in order to achieve compliance.
The patches in this series achieve compliance for MISRA C:2012 Rule 7.2 by
adding the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Changes to macros 'X86_CR0_PG' and 'MSR_EFER' in files
"xen/arch/x86/include/asm/x86-defns.h" and 
"xen/arch/x86/include/asm/msr-index.h"
are not made since they are used also in assembly files.

---
Changes in v3:
- fixes following review comments
- change some commit messages
- change 'Signed-off-by' ordering
- create two new commits

Changes in v2:
- fixes following review comments
- change title and commit messages
- remove changes in out of scope files
- remove changes in some macros

Gianluca Luparini (15):
  x86/cpufreq: fix violations of MISRA C:2012 Rule 7.2
  AMD/IOMMU: fix violations of MISRA C:2012 Rule 7.2
  x86/svm: fix violations of MISRA C:2012 Rule 7.2
  xen/arm: fix violations of MISRA C:2012 Rule 7.2
  xen/device-tree: fix violations of MISRA C:2012 Rule 7.2
  xen/efi: fix violations of MISRA C:2012 Rule 7.2
  x86/vmx: fix violations of MISRA C:2012 Rule 7.2
  xen/pci: fix violations of MISRA C:2012 Rule 7.2
  xen/public: fix violations of MISRA C:2012 Rule 7.2
  x86/monitor: fix violations of MISRA C:2012 Rule 7.2
  xen/vpci: fix violations of MISRA C:2012 Rule 7.2
  xen/x86: fix violations of MISRA C:2012 Rule 7.2
  x86/viridian: fix violations of MISRA C:2012 Rule 7.2
  ACPI/APEI: fix violations of MISRA C:2012 Rule 7.2
  xen: fix violations of MISRA C:2012 Rule 7.2

 xen/arch/arm/domain_build.c  |   4 +-
 xen/arch/arm/efi/efi-boot.h  |   2 +-
 xen/arch/arm/gic-v2.c|   6 +-
 xen/arch/arm/gic-v3.c|  10 +-
 xen/arch/arm/include/asm/arm64/brk.h |   2 +-
 xen/arch/arm/include/asm/arm64/efibind.h |  10 +-
 xen/arch/arm/include/asm/arm64/insn.h|  16 +-
 xen/arch/arm/include/asm/vreg.h  |   2 +-
 xen/arch/arm/kernel.c|   2 +-
 xen/arch/arm/traps.c |  14 +-
 xen/arch/arm/vgic-v2.c   |   2 +-
 xen/arch/arm/vgic-v3.c   |   2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c |  14 +-
 xen/arch/x86/apic.c  |   2 +-
 xen/arch/x86/cpu-policy.c|  18 +-
 xen/arch/x86/cpu/mcheck/mce-apei.c   |   4 +-
 xen/arch/x86/cpu/vpmu_intel.c|   2 +-
 xen/arch/x86/cpuid.c |   8 +-
 xen/arch/x86/efi/efi-boot.h  |   6 +-
 xen/arch/x86/extable.c   |   2 +-
 xen/arch/x86/hvm/hypercall.c |   2 +-
 xen/arch/x86/hvm/irq.c   |   2 +-
 xen/arch/x86/hvm/pmtimer.c   |   4 +-
 xen/arch/x86/hvm/stdvga.c|  50 ++---
 xen/arch/x86/hvm/svm/asid.c  |   2 +-
 xen/arch/x86/hvm/svm/svm.c   |   8 +-
 xen/arch/x86/hvm/viridian/viridian.c |   2 +-
 xen/arch/x86/hvm/vlapic.c|   6 +-
 xen/arch/x86/hvm/vmx/vmcs.c  |   6 +-
 xen/arch/x86/hvm/vmx/vvmx.c  |   8 +-
 xen/arch/x86/include/asm/apicdef.h   |   2 +-
 xen/arch/x86/include/asm/config.h|   2 +-
 xen/arch/x86/include/asm/guest/hyperv-tlfs.h |  28 +--
 xen/arch/x86/include/asm/hpet.h  |   2 +-
 xen/arch/x86/include/asm/hvm/trace.h |   4 +-
 xen/arch/x86/include/asm/hvm/vioapic.h   |   2 +-
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h  |  84 
 xen/arch/x86/include/asm/hvm/vmx/vmx.h   |  16 +-
 xen/arch/x86/include/asm/msi.h   |   2 +-
 xen/arch/x86/include/asm/msr-index.h | 202 +--
 xen/arch/x86/include/asm/pci.h   |   8 +-
 xen/arch/x86/include/asm/x86-defns.h |   2 +-
 xen/arch/x86/monitor.c   |   6 +-
 xen/arch/x86/percpu.c|   2 +-
 xen/arch/x86/psr.c   |   2 +-
 xen/arch/x86/spec_ctrl.c |   8 +-
 xen/arch/x86/x86_64/acpi_mmcfg.c |   2 +-
 xen/arch/x86/x86_64/pci.c|   2 +-
 xen/arch/x86/x86_emulate/x86_emulate.h   |   2 +-
 xen/common/device_tree.c |   4 +-
 xen/common/efi/boot.c|   8 +-
 xen/common/efi/runtime.c |   2 

[XEN PATCH v3 05/15] xen/device-tree: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Luca Fancellu 
Reviewed-by: Stefano Stabellini 
---
Changes in v3:
- change 'Signed-off-by' ordering

Changes in v2:
- change commit title to the right one
- change commit message
- change maintainers in Cc
- remove changes in 'libfdt'
---
 xen/common/device_tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 8da1052911..0677193ab3 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -2115,7 +2115,7 @@ static void __init __unflatten_device_tree(const void 
*fdt,
 /* Allocate memory for the expanded device tree */
 mem = (unsigned long)_xmalloc (size + 4, __alignof__(struct 
dt_device_node));
 
-((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeef);
+((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeefU);
 
 dt_dprintk("  unflattening %lx...\n", mem);
 
@@ -2125,7 +2125,7 @@ static void __init __unflatten_device_tree(const void 
*fdt,
 if ( be32_to_cpup((__be32 *)start) != FDT_END )
 printk(XENLOG_WARNING "Weird tag at end of tree: %08x\n",
   *((u32 *)start));
-if ( be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeef )
+if ( be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeefU )
 printk(XENLOG_WARNING "End of tree marker overwritten: %08x\n",
   be32_to_cpu(((__be32 *)mem)[size / 4]));
 *allnextp = NULL;
-- 
2.41.0

[XEN PATCH v3 02/15] AMD/IOMMU: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
Changes in v3:
- change 'Signed-off-by' ordering

Changes in v2:
- minor change to commit title
- change commit message
---
 xen/drivers/passthrough/amd/iommu-defs.h | 122 +++
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu-defs.h 
b/xen/drivers/passthrough/amd/iommu-defs.h
index 35de548e3a..c145248f9a 100644
--- a/xen/drivers/passthrough/amd/iommu-defs.h
+++ b/xen/drivers/passthrough/amd/iommu-defs.h
@@ -38,49 +38,49 @@
 ((uint64_t)(offset) << (12 + (PTE_PER_TABLE_SHIFT * ((level) - 1
 
 /* IOMMU Capability */
-#define PCI_CAP_ID_MASK0x00FF
+#define PCI_CAP_ID_MASK0x00FFU
 #define PCI_CAP_ID_SHIFT   0
-#define PCI_CAP_NEXT_PTR_MASK  0xFF00
+#define PCI_CAP_NEXT_PTR_MASK  0xFF00U
 #define PCI_CAP_NEXT_PTR_SHIFT 8
-#define PCI_CAP_TYPE_MASK  0x0007
+#define PCI_CAP_TYPE_MASK  0x0007U
 #define PCI_CAP_TYPE_SHIFT 16
-#define PCI_CAP_REV_MASK   0x00F8
+#define PCI_CAP_REV_MASK   0x00F8U
 #define PCI_CAP_REV_SHIFT  19
-#define PCI_CAP_IOTLB_MASK 0x0100
+#define PCI_CAP_IOTLB_MASK 0x0100U
 #define PCI_CAP_IOTLB_SHIFT24
-#define PCI_CAP_HT_TUNNEL_MASK 0x0200
+#define PCI_CAP_HT_TUNNEL_MASK 0x0200U
 #define PCI_CAP_HT_TUNNEL_SHIFT25
-#define PCI_CAP_NP_CACHE_MASK  0x0400
+#define PCI_CAP_NP_CACHE_MASK  0x0400U
 #define PCI_CAP_NP_CACHE_SHIFT 26
 #define PCI_CAP_EFRSUP_SHIFT27
-#define PCI_CAP_RESET_MASK 0x8000
+#define PCI_CAP_RESET_MASK 0x8000U
 #define PCI_CAP_RESET_SHIFT31
 
 #define PCI_CAP_TYPE_IOMMU 0x3
 
 #define PCI_CAP_MMIO_BAR_LOW_OFFSET0x04
 #define PCI_CAP_MMIO_BAR_HIGH_OFFSET   0x08
-#define PCI_CAP_MMIO_BAR_LOW_MASK  0xC000
+#define PCI_CAP_MMIO_BAR_LOW_MASK  0xC000U
 #define IOMMU_MMIO_REGION_LENGTH   0x4000
 
 #define PCI_CAP_RANGE_OFFSET   0x0C
-#define PCI_CAP_BUS_NUMBER_MASK0xFF00
+#define PCI_CAP_BUS_NUMBER_MASK0xFF00U
 #define PCI_CAP_BUS_NUMBER_SHIFT   8
-#define PCI_CAP_FIRST_DEVICE_MASK  0x00FF
+#define PCI_CAP_FIRST_DEVICE_MASK  0x00FFU
 #define PCI_CAP_FIRST_DEVICE_SHIFT 16
-#define PCI_CAP_LAST_DEVICE_MASK   0xFF00
+#define PCI_CAP_LAST_DEVICE_MASK   0xFF00U
 #define PCI_CAP_LAST_DEVICE_SHIFT  24
 
-#define PCI_CAP_UNIT_ID_MASK0x001F
+#define PCI_CAP_UNIT_ID_MASK0x001FU
 #define PCI_CAP_UNIT_ID_SHIFT   0
 #define PCI_CAP_MISC_INFO_OFFSET0x10
-#define PCI_CAP_MSI_NUMBER_MASK 0x001F
+#define PCI_CAP_MSI_NUMBER_MASK 0x001FU
 #define PCI_CAP_MSI_NUMBER_SHIFT0
 
 /* Device Table */
 #define IOMMU_DEV_TABLE_BASE_LOW_OFFSET0x00
 #define IOMMU_DEV_TABLE_BASE_HIGH_OFFSET   0x04
-#define IOMMU_DEV_TABLE_SIZE_MASK  0x01FF
+#define IOMMU_DEV_TABLE_SIZE_MASK  0x01FFU
 #define IOMMU_DEV_TABLE_SIZE_SHIFT 0
 
 #define IOMMU_DEV_TABLE_ENTRIES_PER_BUS256
@@ -159,13 +159,13 @@ struct amd_iommu_dte {
 #define IOMMU_CMD_BUFFER_BASE_HIGH_OFFSET  0x0C
 #define IOMMU_CMD_BUFFER_HEAD_OFFSET   0x2000
 #define IOMMU_CMD_BUFFER_TAIL_OFFSET   0x2008
-#define IOMMU_CMD_BUFFER_LENGTH_MASK   0x0F00
+#define IOMMU_CMD_BUFFER_LENGTH_MASK   0x0F00U
 #define IOMMU_CMD_BUFFER_LENGTH_SHIFT  24
 
 #define IOMMU_CMD_BUFFER_ENTRY_ORDER4
 #define IOMMU_CMD_BUFFER_MAX_ENTRIES(1u << 15)
 
-#define IOMMU_CMD_OPCODE_MASK  0xF000
+#define IOMMU_CMD_OPCODE_MASK  0xF000U
 #define IOMMU_CMD_OPCODE_SHIFT 28
 #define IOMMU_CMD_COMPLETION_WAIT  0x1
 #define IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY  0x2
@@ -178,50 +178,50 @@ struct amd_iommu_dte {
 /* COMPLETION_WAIT command */
 #define IOMMU_COMP_WAIT_DATA_BUFFER_SIZE   8
 #define IOMMU_COMP_WAIT_DATA_BUFFER_ALIGNMENT  8
-#define IOMMU_COMP_WAIT_S_FLAG_MASK0x0001
-#define IOMMU_COMP_WAIT_I_FLAG_MASK0x0002
-#define IOMMU_COMP_WAIT_F_FLAG_MASK0x0004
-#define IOMMU_COMP_WAIT_ADDR_LOW_MASK  0xFFF8
+#define IOMMU_COMP_WAIT_S_FLAG_MASK0x0001U
+#define IOMMU_COMP_WAIT_I_FLAG_MASK0x0002U
+#define IOMMU_COMP_WAIT_F

[XEN PATCH v3 03/15] x86/svm: fix violations of MISRA C:2012 Rule 7.2

[Simone Ballarin]

From: Gianluca Luparini 

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".

Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.

Signed-off-by: Gianluca Luparini 
Signed-off-by: Simone Ballarin 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
Changes in v3:
- change 'Signed-off-by' ordering

Changes in v2:
- change commit title to make it unique
- change commit message
---
 xen/arch/x86/hvm/svm/asid.c | 2 +-
 xen/arch/x86/hvm/svm/svm.c  | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/asid.c b/xen/arch/x86/hvm/svm/asid.c
index 09f8c23fd9..56306d1a16 100644
--- a/xen/arch/x86/hvm/svm/asid.c
+++ b/xen/arch/x86/hvm/svm/asid.c
@@ -16,7 +16,7 @@ void svm_asid_init(const struct cpuinfo_x86 *c)
 
 /* Check for erratum #170, and leave ASIDs disabled if it's present. */
 if ( !cpu_has_amd_erratum(c, AMD_ERRATUM_170) )
-nasids = cpuid_ebx(0x800A);
+nasids = cpuid_ebx(0x800AU);
 
 hvm_asid_init(nasids);
 }
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 59a6e88dff..56cb2f61bb 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -269,9 +269,9 @@ svm_msrbit(unsigned long *msr_bitmap, uint32_t msr)
  */
 if ( msr <= 0x1fff )
 msr_bit = msr_bitmap + 0x / BYTES_PER_LONG;
-else if ( (msr >= 0xc000) && (msr <= 0xc0001fff) )
+else if ( (msr >= 0xc000U) && (msr <= 0xc0001fffU) )
 msr_bit = msr_bitmap + 0x0800 / BYTES_PER_LONG;
-else if ( (msr >= 0xc001) && (msr <= 0xc0011fff) )
+else if ( (msr >= 0xc001U) && (msr <= 0xc0011fffU) )
 msr_bit = msr_bitmap + 0x1000 / BYTES_PER_LONG;
 
 return msr_bit;
@@ -2539,8 +2539,8 @@ const struct hvm_function_table * __init start_svm(void)
 
 setup_vmcb_dump();
 
-if ( boot_cpu_data.extended_cpuid_level >= 0x800a )
-svm_feature_flags = cpuid_edx(0x800a);
+if ( boot_cpu_data.extended_cpuid_level >= 0x800aU )
+svm_feature_flags = cpuid_edx(0x800aU);
 
 printk("SVM: Supported advanced features:\n");
 
-- 
2.41.0

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

[Peter Hoyes]

From: Peter Hoyes 

Dom0 may be accessed via telnet, meaning the default escape character
(which is the same as telnet's) cannot be directly used to exit the
console. It would be helpful to make the escape character customizable
in such use cases.

Add --escape argument to console tool for this purpose.

Add argument to getopt options, parse and validate the escape character
and pass value to console_loop.

If --escape is not specified, it falls back to the existing behavior
using DEFAULT_ESCAPE_SEQUENCE.

Signed-off-by: Peter Hoyes 
---
Changes in v5:
- Add this changelog

Changes in v4:
- Improve validation of the escape_character optarg

Changes in v3:
- Re-add the Reviewed-By tag accidentally removed in v2

Changes in v2:
- Drop the tags intended only for internal use at Arm

 tools/console/client/main.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/tools/console/client/main.c b/tools/console/client/main.c
index 6775006488..d2dcc3ddca 100644
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -42,7 +42,7 @@
 #include 
 #include "xenctrl.h"
 
-#define ESCAPE_CHARACTER 0x1d
+#define DEFAULT_ESCAPE_CHARACTER 0x1d
 
 static volatile sig_atomic_t received_signal = 0;
 static char lockfile[sizeof (XEN_LOCK_DIR "/xenconsole.") + 8] = { 0 };
@@ -77,6 +77,7 @@ static void usage(const char *program) {
   "  -n, --num N  use console number N\n"
   "  --type TYPE  console type. must be 'pv', 'serial' or 
'vuart'\n"
   "  --start-notify-fd N file descriptor used to notify parent\n"
+  "  --escape E   escape sequence to exit console\n"
   , program);
 }
 
@@ -174,7 +175,7 @@ static void restore_term(int fd, struct termios *old)
 }
 
 static int console_loop(int fd, struct xs_handle *xs, char *pty_path,
-   bool interactive)
+   bool interactive, char escape_character)
 {
int ret, xs_fd = xs_fileno(xs), max_fd = -1;
 
@@ -215,7 +216,7 @@ static int console_loop(int fd, struct xs_handle *xs, char 
*pty_path,
char msg[60];
 
len = read(STDIN_FILENO, msg, sizeof(msg));
-   if (len == 1 && msg[0] == ESCAPE_CHARACTER) {
+   if (len == 1 && msg[0] == escape_character) {
return 0;
} 
 
@@ -335,6 +336,7 @@ int main(int argc, char **argv)
{ "help",0, 0, 'h' },
{ "start-notify-fd", 1, 0, 's' },
{ "interactive", 0, 0, 'i' },
+   { "escape",  1, 0, 'e' },
{ 0 },
 
};
@@ -345,6 +347,7 @@ int main(int argc, char **argv)
console_type type = CONSOLE_INVAL;
bool interactive = 0;
const char *console_names = "serial, pv, vuart";
+   char escape_character = DEFAULT_ESCAPE_CHARACTER;
 
while((ch = getopt_long(argc, argv, sopt, lopt, &opt_ind)) != -1) {
switch(ch) {
@@ -375,6 +378,16 @@ int main(int argc, char **argv)
case 'i':
interactive = 1;
break;
+   case 'e':
+   if (optarg[0] == '^' && optarg[1] && optarg[2] == '\0')
+   escape_character = optarg[1] & 0x1f;
+   else if (optarg[0] && optarg[1] == '\0')
+   escape_character = optarg[0];
+   else {
+   fprintf(stderr, "Invalid escape argument\n");
+   exit(EINVAL);
+   }
+   break;
default:
fprintf(stderr, "Invalid argument\n");
fprintf(stderr, "Try `%s --help' for more 
information.\n", 
@@ -493,7 +506,7 @@ int main(int argc, char **argv)
close(start_notify_fd);
}
 
-   console_loop(spty, xs, path, interactive);
+   console_loop(spty, xs, path, interactive, escape_character);
 
free(path);
free(dom_path);
-- 
2.34.1

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

[Peter Hoyes]

From: Peter Hoyes 

Add -e argument to xl console and pass to new escape_character argument
of libxl_console_exec.

Introduce a new API version to support this new argument and advertise
the new functionality in libxl.h

In libxl_console_exec, there are currently two call sites to execl,
which uses varargs, in order to support optionally passing
'start-notify-fd' to the console client. In order to support passing
the 'escape' argument optionally too, refactor to instead have a single
call site to execv, which has the same behavior but takes an array of
arguments.

If -e is not specified, --escape is not passed to the console client and
the existing value (^]) is used as a default.

Update the xl docs.

Signed-off-by: Peter Hoyes 
---
Changes in v5:
- Add this changelog
- Fix comment style in libxl_console_exec

Changes in v4:
- Document xl console -e argument in xl.1.pod.in
- Add changes for libxl API version compatibility

Changes in v3:
- Re-add the Reviewed-By tag accidentally removed in v2

Changes in v2:
- Drop the tags intended only for internal use at Arm

 docs/man/xl.1.pod.in |  8 ++-
 tools/include/libxl.h| 39 +---
 tools/libs/light/libxl_console.c | 30 +---
 tools/xl/xl_cmdtable.c   |  3 ++-
 tools/xl/xl_console.c| 10 +---
 tools/xl/xl_vmcontrol.c  |  2 +-
 6 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 101e14241d..9ba22a8fa2 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -222,7 +222,8 @@ Attach to the console of a domain specified by 
I.  If you've set up
 your domains to have a traditional login console this will look much like a
 normal text login screen.
 
-Use the key combination Ctrl+] to detach from the domain console.
+Use the escape character key combination (default Ctrl+]) to detach from the
+domain console.
 
 B
 
@@ -239,6 +240,11 @@ emulated serial for HVM guests and PV console for PV 
guests.
 
 Connect to console number I. Console numbers start from 0.
 
+=item I<-e escapechar>
+
+Customize the escape sequence used to detach from the domain console to
+I. If not specified, the value "^]" is used.
+
 =back
 
 =item B [I] I
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index cac641a7eb..21e43cc839 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
@@ -81,6 +81,15 @@
  */
 #define LIBXL_HAVE_CONSOLE_NOTIFY_FD 1
 
+/* LIBXL_HAVE_CONSOLE_ESCAPE_CHARACTER
+ *
+ * If this is defined, libxl_console_exec and
+ * libxl_primary_console_exe take an escape_character parameter. That
+ * parameter will be used to modify the escape sequence used to exit the
+ * console.
+ */
+#define LIBXL_HAVE_CONSOLE_ESCAPE_CHARACTER 1
+
 /* LIBXL_HAVE_CONST_COPY_AND_LENGTH_FUNCTIONS
  *
  * If this is defined, the copy functions have constified src parameter and the
@@ -790,7 +799,8 @@ typedef struct libxl__ctx libxl_ctx;
 #if LIBXL_API_VERSION != 0x040200 && LIBXL_API_VERSION != 0x040300 && \
 LIBXL_API_VERSION != 0x040400 && LIBXL_API_VERSION != 0x040500 && \
 LIBXL_API_VERSION != 0x040700 && LIBXL_API_VERSION != 0x040800 && \
-LIBXL_API_VERSION != 0x041300 && LIBXL_API_VERSION != 0x041400
+LIBXL_API_VERSION != 0x041300 && LIBXL_API_VERSION != 0x041400 && \
+LIBXL_API_VERSION != 0x041800
 #error Unknown LIBXL_API_VERSION
 #endif
 #endif
@@ -1958,7 +1968,8 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, 
int autopass);
  * the caller that it has connected to the guest console.
  */
 int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
-   libxl_console_type type, int notify_fd);
+   libxl_console_type type, int notify_fd,
+   char* escape_character);
 /* libxl_primary_console_exec finds the domid and console number
  * corresponding to the primary console of the given vm, then calls
  * libxl_console_exec with the right arguments (domid might be different
@@ -1968,9 +1979,12 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, 
int cons_num,
  * guests using pygrub.
  * If notify_fd is not -1, xenconsole will write 0x00 to it to nofity
  * the caller that it has connected to the guest console.
+ * If escape_character is not NULL, the provided value is used to exit
+ * the guest console.
  */
 int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm,
-   int notify_fd);
+   int notify_fd,
+   char* escape_character);
 
 #if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040800
 
@@ -1989,6 +2003,25 @@ static inline int 
libxl_primary_console_exec_0x040700(libxl_ctx *ctx,
 }
 #define libxl_primary_console_exec libxl_primary_console_exec_0x040700
 
+#elif defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x041800
+
+static inline int libxl_console_exec_0x041800(libxl_ctx *ctx, uint32_t domid

[PATCH v5 0/2] Add escape character argument to Xen console

[Peter Hoyes]

From: Peter Hoyes 


Dom0 may be accessed via telnet, meaning the default escape character
(which is the same as telnet's) cannot be directly used to exit the
console. It would be helpful to make the escape character customizable
in such use cases, falling back to the existing value if not set.

Make the necessary changes to the console client, libxl and the xl
console sub-command to support this.

Peter Hoyes (2):
  tools/console: Add escape argument to configure escape character
  xl: Add escape character argument to xl console

 docs/man/xl.1.pod.in |  8 ++-
 tools/console/client/main.c  | 21 +
 tools/include/libxl.h| 39 +---
 tools/libs/light/libxl_console.c | 30 +---
 tools/xl/xl_cmdtable.c   |  3 ++-
 tools/xl/xl_console.c| 10 +---
 tools/xl/xl_vmcontrol.c  |  2 +-
 7 files changed, 92 insertions(+), 21 deletions(-)

-- 
2.34.1

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Thomas Zimmermann]

Hi

Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:

Hello,

while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.

I think there is a big benefit when these are all renamed to "drm_dev".


If you rename drm_crtc.dev, you should also address *all* other data 
structures.



I have no strong preference here though, so "drmdev" or "drm" are fine
for me, too. Let the bikesheding begin!


We've discussed this to death. IIRC 'drm' would be the prefered choice.

Best regards
Thomas



Some statistics:

$ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | 
sort -n
   1 struct drm_device *adev_to_drm
   1 struct drm_device *drm_
   1 struct drm_device  *drm_dev
   1 struct drm_device*drm_dev
   1 struct drm_device *pdev
   1 struct drm_device *rdev
   1 struct drm_device *vdev
   2 struct drm_device *dcss_drv_dev_to_drm
   2 struct drm_device **ddev
   2 struct drm_device *drm_dev_alloc
   2 struct drm_device *mock
   2 struct drm_device *p_ddev
   5 struct drm_device *device
   9 struct drm_device * dev
  25 struct drm_device *d
  95 struct drm_device *
 216 struct drm_device *ddev
 234 struct drm_device *drm_dev
 611 struct drm_device *drm
4190 struct drm_device *dev

This series starts with renaming struct drm_crtc::dev to drm_dev. If
it's not only me and others like the result of this effort it should be
followed up by adapting the other structs and the individual usages in
the different drivers.

To make this series a bit easier handleable, I first added an alias for
drm_crtc::dev, then converted the drivers one after another and the last
patch drops the "dev" name. This has the advantage of being easier to
review, and if I should have missed an instance only the last patch must
be dropped/reverted. Also this series might conflict with other patches,
in this case the remaining patches can still go in (apart from the last
one of course). Maybe it also makes sense to delay applying the last
patch by one development cycle?

The series was compile tested for arm, arm64, powerpc and amd64 using an
allmodconfig (though I only build drivers/gpu/).

Best regards
Uwe

Uwe Kleine-König (52):
   drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
   drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/armada: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/aspeed: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/exynos: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/gma500: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/hyperv: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/ingenic: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/logicvc: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/mediatek: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/meson: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/mgag200: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/nouveau: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/pl111: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
   drm/radeon: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/renesas: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/rockchip: Use struct drm_crtc::drm_dev instead of struct
 drm_crtc::dev
   drm/solomon: Use stru

Re: [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Paul Kocialkowski]

Hi Uwe,

On Wed 12 Jul 23, 11:46, Uwe Kleine-König wrote:
> Hello,
> 
> while I debugged an issue in the imx-lcdc driver I was constantly
> irritated about struct drm_device pointer variables being named "dev"
> because with that name I usually expect a struct device pointer.

Well personally I usually expect that the "dev" member of a subsystem-specific
struct refers to a device of that subsystem, so for me having "dev" refer to
a drm_device for e.g. drm_crtc makes good sense.

I would only expect dev to refer to a struct device in the subsystem-specific
device structure (drm_device). I don't think it makes much sense to carry
the struct device in any other subsystem-specific structure anyway.

So IMO things are fine as-is but this is not a very strong opinion either.

> I think there is a big benefit when these are all renamed to "drm_dev".
> I have no strong preference here though, so "drmdev" or "drm" are fine
> for me, too. Let the bikesheding begin!

I would definitely prefer "drm_dev" over "drmdev" (hard to read, feels like
aborted camelcase, pretty ugly) or "drm" (too vague).

Cheers,

Paul

> Some statistics:
> 
> $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c 
> | sort -n
>   1 struct drm_device *adev_to_drm
>   1 struct drm_device *drm_
>   1 struct drm_device  *drm_dev
>   1 struct drm_device*drm_dev
>   1 struct drm_device *pdev
>   1 struct drm_device *rdev
>   1 struct drm_device *vdev
>   2 struct drm_device *dcss_drv_dev_to_drm
>   2 struct drm_device **ddev
>   2 struct drm_device *drm_dev_alloc
>   2 struct drm_device *mock
>   2 struct drm_device *p_ddev
>   5 struct drm_device *device
>   9 struct drm_device * dev
>  25 struct drm_device *d
>  95 struct drm_device *
> 216 struct drm_device *ddev
> 234 struct drm_device *drm_dev
> 611 struct drm_device *drm
>4190 struct drm_device *dev
> 
> This series starts with renaming struct drm_crtc::dev to drm_dev. If
> it's not only me and others like the result of this effort it should be
> followed up by adapting the other structs and the individual usages in
> the different drivers.
> 
> To make this series a bit easier handleable, I first added an alias for
> drm_crtc::dev, then converted the drivers one after another and the last
> patch drops the "dev" name. This has the advantage of being easier to
> review, and if I should have missed an instance only the last patch must
> be dropped/reverted. Also this series might conflict with other patches,
> in this case the remaining patches can still go in (apart from the last
> one of course). Maybe it also makes sense to delay applying the last
> patch by one development cycle?
> 
> The series was compile tested for arm, arm64, powerpc and amd64 using an
> allmodconfig (though I only build drivers/gpu/).
> 
> Best regards
> Uwe
> 
> Uwe Kleine-König (52):
>   drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
>   drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/armada: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/aspeed: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/exynos: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/gma500: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/hyperv: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/ingenic: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/logicvc: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/mediatek: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/meson: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/mgag200: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
>   drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc::dev
>   drm/nouveau: Use struct drm_crtc::drm_dev instead of struct
> drm_crtc

[PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev

[Uwe Kleine-König]

Hello,

while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.

I think there is a big benefit when these are all renamed to "drm_dev".
I have no strong preference here though, so "drmdev" or "drm" are fine
for me, too. Let the bikesheding begin!

Some statistics:

$ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | 
sort -n
  1 struct drm_device *adev_to_drm
  1 struct drm_device *drm_
  1 struct drm_device  *drm_dev
  1 struct drm_device*drm_dev
  1 struct drm_device *pdev
  1 struct drm_device *rdev
  1 struct drm_device *vdev
  2 struct drm_device *dcss_drv_dev_to_drm
  2 struct drm_device **ddev
  2 struct drm_device *drm_dev_alloc
  2 struct drm_device *mock
  2 struct drm_device *p_ddev
  5 struct drm_device *device
  9 struct drm_device * dev
 25 struct drm_device *d
 95 struct drm_device *
216 struct drm_device *ddev
234 struct drm_device *drm_dev
611 struct drm_device *drm
   4190 struct drm_device *dev

This series starts with renaming struct drm_crtc::dev to drm_dev. If
it's not only me and others like the result of this effort it should be
followed up by adapting the other structs and the individual usages in
the different drivers.

To make this series a bit easier handleable, I first added an alias for
drm_crtc::dev, then converted the drivers one after another and the last
patch drops the "dev" name. This has the advantage of being easier to
review, and if I should have missed an instance only the last patch must
be dropped/reverted. Also this series might conflict with other patches,
in this case the remaining patches can still go in (apart from the last
one of course). Maybe it also makes sense to delay applying the last
patch by one development cycle?

The series was compile tested for arm, arm64, powerpc and amd64 using an
allmodconfig (though I only build drivers/gpu/).

Best regards
Uwe

Uwe Kleine-König (52):
  drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
  drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/armada: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/aspeed: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/exynos: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/gma500: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/hyperv: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/ingenic: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/logicvc: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/mediatek: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/meson: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/mgag200: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/nouveau: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/pl111: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/radeon: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/renesas: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/rockchip: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/solomon: Use struct drm_crtc::drm_dev instead of struct
drm_crtc::dev
  drm/sprd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/sti: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/stm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
  drm/sun4i: Use struct drm_crtc::drm_

Re: [PATCH] x86/ioapic: sanitize IO-APIC pins before enabling the local APIC

[Jan Beulich]

On 11.07.2023 15:02, Roger Pau Monné wrote:
> On Tue, Jul 11, 2023 at 12:53:31PM +0200, Jan Beulich wrote:
>> On 10.07.2023 16:43, Roger Pau Monné wrote:
>>> On Mon, Jul 10, 2023 at 12:56:27PM +0200, Jan Beulich wrote:
 On 07.07.2023 11:53, Roger Pau Monne wrote:
> The current logic to init the local APIC and the IO-APIC does init the
> former first before doing any kind of sanitation on the IO-APIC pin
> configuration.  It's already noted on enable_IO_APIC() that Xen
> shouldn't trust the IO-APIC being empty at bootup.
>
> At XenServer we have a system where the IO-APIC 0 is handed to Xen
> with pin 0 unmasked, set to Fixed delivery mode, edge triggered and
> with a vector of 0 (all fields of the RTE are zeroed).  Once the local
> APIC is enabled periodic injections from such pin cause a storm of
> errors:
>
> APIC error on CPU0: 00(40), Received illegal vector
> APIC error on CPU0: 40(40), Received illegal vector
> APIC error on CPU0: 40(40), Received illegal vector
> APIC error on CPU0: 40(40), Received illegal vector
> APIC error on CPU0: 40(40), Received illegal vector
> APIC error on CPU0: 40(40), Received illegal vector
>
> That prevents Xen from booting.

 And I expect no RTE is in ExtInt mode, so one might conclude that
 firmware meant to set up RTE 0 that way. Mainly as a remark, albeit
 of course there's then the question whether to change the RTE
 rather than masking it. What do ACPI tables say?
>>>
>>> There's one relevant override:
>>>
>>> [668h 1640   1]Subtable Type : 02 [Interrupt Source 
>>> Override]
>>> [669h 1641   1]   Length : 0A
>>> [66Ah 1642   1]  Bus : 00
>>> [66Bh 1643   1]   Source : 00
>>> [66Ch 1644   4]Interrupt : 0002
>>> [670h 1648   2]Flags (decoded below) : 
>>> Polarity : 0
>>> Trigger Mode : 0
>>>
>>> So IRQ 0 -> GSI 2, so it's likely pin 0 is the one the i8259 is
>>> connected to.
>>
>> Then wouldn't we be better off converting that RTE to ExtInt? That
>> would allow PIC IRQs (not likely to exist, but still) to work
>> (without undue other side effects afaics), whereas masking this RTE
>> would not.
> 
> I'm kind of worry of trying to automate this logic.  Should we always
> convert pin 0 to ExtInt if it's found unmasked, with and invalid
> vector and there's a source override entry for the IRQ?
> 
> It seems weird to infer this just from the fact that pin 0 is all
> zeroed out.

As you say in the earlier paragraph, it wouldn't be just that. It's
unmasked + bad vector + present source override (indicating that
nothing except perhaps a PIC is connected to the pin).

> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -1476,6 +1476,10 @@ int __init APIC_init_uniprocessor (void)
>  return -1;
>  }
>  
> +if ( smp_found_config && !skip_ioapic_setup && nr_ioapics )
> +/* Sanitize the IO-APIC pins before enabling the local APIC. */
> +sanitize_IO_APIC();

 I'm a little puzzled by the smp_found_config part of the check here,
 but not in smp_prepare_cpus(). What's the reason for (a) the check
 and (b) the difference?
>>>
>>> This just mimics what gates the call to setup_IO_APIC() in that same
>>> function.  It makes no sense to call sanitize_IO_APIC() if
>>> setup_IO_APIC() is not called, and I wasn't planning on changing the
>>> logic that gates the call setup_IO_APIC() in this patch.
>>>
>>> I did note the difference with smp_prepare_cpus(), and I think we
>>> should look at unifying those paths, but didn't want to do it as part
>>> of this fix.
>>
>> Well, consistency is one valid goal. But masking RTEs may need to be
>> done more aggressively than setting up the IO-APICs. In particular
>> if we're not to use them, we still want to mask all RTEs. Otherwise
>> we're likely to observe each IRQ to arrive via two separate routes
>> (once through the 8259 and once from an unmasked IO-APIC pin).
> 
> So avoid the smp_found_config check here and use the same condition as in
> smp_prepare_cpus(), I will adjust the patch to that effect.
> 
> I do wonder why we don't simply mandate IO-APIC usage and get rid of
> the code to handle the 8259.  Is it only to cope with systems that
> have a broken IO-APIC configuration?  Because I don't think there are
> x86 64bit systems without an IO-APIC?

There shouldn't be, yes. And Andrew has been suggesting the same on a
number of occasions, iirc. Yet trying to remove that code is perhaps
more risky than simply keeping it, which may be (besides time
constraints) why nobody has made an attempt so far.

 Isn't checking nr_ioapics sufficient in this
 regard? (b) probably could be addressed by moving the code to the
 beginning of verify_local_APIC(), immediately ahead 

Re: [XEN PATCH v9 02/24] xen/arm: add TEE teardown to arch_domain_teardown()

[Julien Grall]

Hi Jens,

On 05/07/2023 10:34, Jens Wiklander wrote:

Adds a progress state for tee_domain_teardown() to be called from
arch_domain_teardown(). tee_domain_teardown() calls the new callback
domain_teardown() in struct tee_mediator_ops.

An empty domain_teardown() callback is added to the OP-TEE mediator.

Signed-off-by: Andrew Cooper 
Co-developed-by: Andrew Cooper 


I am a bit confused with the tags ordering. The first signed-off-by 
indicates that Andrew is the author but he co-developped with himself? 
Did you indent to put your signed-off-by first?



Signed-off-by: Jens Wiklander 

---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Bertrand Marquis 
CC: Jens Wiklander 
---
  xen/arch/arm/domain.c  | 36 ++
  xen/arch/arm/include/asm/tee/tee.h |  7 ++
  xen/arch/arm/tee/optee.c   |  6 +
  xen/arch/arm/tee/tee.c |  8 +++
  4 files changed, 57 insertions(+)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 15d9709a97d2..18171decdc66 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -795,6 +795,42 @@ fail:
  
  int arch_domain_teardown(struct domain *d)

  {
+int ret = 0;
+
+BUG_ON(!d->is_dying);
+
+/* See domain_teardown() for an explanation of all of this magic. */
+switch ( d->teardown.arch_val )
+{
+#define PROGRESS(x) \
+d->teardown.arch_val = PROG_ ## x;  \
+fallthrough;\
+case PROG_ ## x
+
+enum {
+PROG_none,
+PROG_tee,
+PROG_done,
+};
+
+case PROG_none:
+BUILD_BUG_ON(PROG_none != 0);
+
+PROGRESS(tee):
+ret = tee_domain_teardown(d);
+if ( ret )
+return ret;
+break;
+
+PROGRESS(done):
+break;
+
+#undef PROGRESS
+
+default:
+BUG();
+}
+
  return 0;
  }
  
diff --git a/xen/arch/arm/include/asm/tee/tee.h b/xen/arch/arm/include/asm/tee/tee.h

index f483986385c8..da324467e130 100644
--- a/xen/arch/arm/include/asm/tee/tee.h
+++ b/xen/arch/arm/include/asm/tee/tee.h
@@ -34,6 +34,7 @@ struct tee_mediator_ops {
   * guest and create own structures for the new domain.
   */
  int (*domain_init)(struct domain *d);
+int (*domain_teardown)(struct domain *d);
  
  /*

   * Called during domain destruction to relinquish resources used
@@ -62,6 +63,7 @@ struct tee_mediator_desc {
  
  bool tee_handle_call(struct cpu_user_regs *regs);

  int tee_domain_init(struct domain *d, uint16_t tee_type);
+int tee_domain_teardown(struct domain *d);
  int tee_relinquish_resources(struct domain *d);
  uint16_t tee_get_type(void);
  
@@ -93,6 +95,11 @@ static inline int tee_relinquish_resources(struct domain *d)

  return 0;
  }
  
+static inline int tee_domain_teardown(struct domain *d)

+{
+return 0;
+}
+
  static inline uint16_t tee_get_type(void)
  {
  return XEN_DOMCTL_CONFIG_TEE_NONE;
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 301d205a36c5..c91bd7d5ac25 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -268,6 +268,11 @@ static int optee_domain_init(struct domain *d)
  return 0;
  }
  
+static int optee_domain_teardown(struct domain *d)

+{
+return 0;


I think for OP-TEE, we also need to moved the smc call to destroy the VM 
here. I am OK if this is not handled here, but it would be worth 
mentioning in the commit message.



+}
+
  static uint64_t regpair_to_uint64(register_t reg0, register_t reg1)
  {
  return ((uint64_t)reg0 << 32) | (uint32_t)reg1;
@@ -1732,6 +1737,7 @@ static const struct tee_mediator_ops optee_ops =
  {
  .probe = optee_probe,
  .domain_init = optee_domain_init,
+.domain_teardown = optee_domain_teardown,
  .relinquish_resources = optee_relinquish_resources,
  .handle_call = optee_handle_call,
  };
diff --git a/xen/arch/arm/tee/tee.c b/xen/arch/arm/tee/tee.c
index 3964a8a5cddf..ddd17506a9ff 100644
--- a/xen/arch/arm/tee/tee.c
+++ b/xen/arch/arm/tee/tee.c
@@ -52,6 +52,14 @@ int tee_domain_init(struct domain *d, uint16_t tee_type)
  return cur_mediator->ops->domain_init(d);
  }
  
+int tee_domain_teardown(struct domain *d)

+{
+if ( !cur_mediator )
+return 0;
+
+return cur_mediator->ops->domain_teardown(d);


NIT: I would consider to check if the callback is NULL. This would avoid 
providing dummy helper.



+}
+
  int tee_relinquish_resources(struct domain *d)
  {
  if ( !cur_mediator )


Cheers,

--
Julien Grall