On 13/11/2024 23:41, Stefano Stabellini wrote:
>
>
> On Wed, 13 Nov 2024, Julien Grall wrote:
>> On 13/11/2024 15:40, Michal Orzel wrote:
>>> On 13/11/2024 15:40, Julien Grall wrote:
On 13/11/2024 14:19, Michal Orzel wrote:
> On 13/11/2024 14:50, Julien Grall wrote:
>> On 06/11/20
On Wed, 13 Nov 2024, Jan Beulich wrote:
> On 13.11.2024 10:38, Alessandro Zucchelli wrote:
> > This addresses violations of MISRA C:2012 Rule 5.4 which states as
> > following: Macro identifiers shall be distinct.
> >
> > This deviation aims to address violations of Rule 5.4 regarding
> > identifi
On Wed, 13 Nov 2024, Jan Beulich wrote:
> On 13.11.2024 04:15, Stefano Stabellini wrote:
> > It is challenging to create a solution that satisfies everyone for this
> > patch. However, we should add R8.3 to the clean list as soon as possible
> > to enable rule blocking in GitLab-CI. Failing to do s
On Wed, 13 Nov 2024, Jan Beulich wrote:
> On 13.11.2024 11:48, Alessandro Zucchelli wrote:
> > At this link you can see all the violations of Rule 5.2:
> >
> > https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/people/bugseng/xen/ECLAIR_normal/40_characters/X86_64/8143
On Wed, 12 Nov 2024, Alessandro Zucchelli wrote:
> MISRA C:2012 Directive 4.10 states as following: Precautions shall be
> taken in order to prevent the contents of a header file being included
> more than once.
>
> This commit updates the documentation to describe the behavior defined
> for the c
On 2024-11-13 11:48, Andrew Cooper wrote:
Split out of yet-more microcode cleanup work.
Signed-off-by: Andrew Cooper
Reviewed-by: Jason Andryuk
On 2024-11-13 13:51, Andrew Cooper wrote:
Both require xen/types.h.
Change multiboot.h to include const.h by it's more normal path, and swap u32
for uint32_t.
Signed-off-by: Andrew Cooper
Reviewed-by: Jason Andryuk
On Wed, 13 Nov 2024, Julien Grall wrote:
> On 13/11/2024 15:40, Michal Orzel wrote:
> > On 13/11/2024 15:40, Julien Grall wrote:
> > > On 13/11/2024 14:19, Michal Orzel wrote:
> > > > On 13/11/2024 14:50, Julien Grall wrote:
> > > > > On 06/11/2024 15:07, Michal Orzel wrote:
> > > > > > On 06/11/20
On 13.11.24 18:25, Elliott Mitchell wrote:
On Tue, Jul 09, 2024 at 08:36:18AM +, Andrei Semenov wrote:
After some investigations we notices a huge performances drop (perfs divided
by
factor of 5) starting from 5.10.88 Linux kernel version on the AMD EPYC
platforms. The patch introduced in t
Both require xen/types.h.
Change multiboot.h to include const.h by it's more normal path, and swap u32
for uint32_t.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/include/xen/multiboot.h | 68 +++-
xen/include/xen/multiboot2.h |
On Tue, Jul 09, 2024 at 08:36:18AM +, Andrei Semenov wrote:
>
> After some investigations we notices a huge performances drop (perfs divided
> by
> factor of 5) starting from 5.10.88 Linux kernel version on the AMD EPYC
> platforms. The patch introduced in this kernel version that allows to
>
On 13/11/2024 16:56, Michal Orzel wrote:
For things that Xen can be interested in, only region for ramdisk for dom0 can
match the /memreserve/ region.
Providing a generic solution (like Luca did) would want providing an example of
sth else that can match which I'm not aware of.
I would arg
Split out of yet-more microcode cleanup work.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/include/xen/earlycpio.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/xen/earlycpio.h b/xen/include/xen/earlycpio.h
index d4992035982d..b1dafc3b0b75 10
On 13/11/2024 17:41, Julien Grall wrote:
>
>
> Hi,
>
> On 13/11/2024 15:40, Michal Orzel wrote:
>>
>>
>> On 13/11/2024 15:40, Julien Grall wrote:
>>>
>>>
>>> Hi,
>>>
>>> On 13/11/2024 14:19, Michal Orzel wrote:
On 13/11/2024 14:50, Julien Grall wrote:
>
>
> Hi Micha
Hi Julien,
-}
+
+if ( (allow_match_type != MEMBANK_NONE) &&
+ (region_start == bank_start) && (region_end == bank_end) &&
>>>
>>> Why is this only an exact match?
>> Apparently what we are fixing is only a case where memreserve regions
>> matches
Hi,
On 13/11/2024 15:40, Michal Orzel wrote:
On 13/11/2024 15:40, Julien Grall wrote:
Hi,
On 13/11/2024 14:19, Michal Orzel wrote:
On 13/11/2024 14:50, Julien Grall wrote:
Hi Michal,
On 06/11/2024 15:07, Michal Orzel wrote:
On 06/11/2024 14:41, Luca Fancellu wrote:
There are s
On Wed, Nov 13 2024 at 13:41, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. This hybrid nature is undesirable.
>
> Since all users of pci_intx() have by now been ported either to
> always-managed pcim_intx() or never-managed pci_intx_unman
On Wed, 2024-11-13 at 17:04 +0100, Thomas Gleixner wrote:
> On Wed, Nov 13 2024 at 13:41, Philipp Stanner wrote:
> > +/**
> > + * pci_intx_unmanaged - enables/disables PCI INTx for device dev,
> > + * unmanaged version
> > + * @pdev: the PCI device to operate on
> > + * @enable: boolean: whether to
On Wed, Nov 13 2024 at 13:41, Philipp Stanner wrote:
> +/**
> + * pci_intx_unmanaged - enables/disables PCI INTx for device dev,
> + * unmanaged version
> + * @pdev: the PCI device to operate on
> + * @enable: boolean: whether to enable or disable PCI INTx
Except that the argument is of type int,
This addresses violations of MISRA C:2012 Rule 5.2 which states as
following: Identifiers declared in the same scope and name space shall
be distinct.
This deviation addresses violations of Rule 5.2 arising from
identifiers generated through token pasting macros CHECK_NAME_ and
DEFINE_COMPAT_HANDL
On 13/11/2024 2:43 pm, oleksii.kuroc...@gmail.com wrote:
> On Wed, 2024-11-13 at 10:48 +0100, Jan Beulich wrote:
>> On 12.11.2024 17:16, Oleksii Kurochko wrote:
>>> https://lore.kernel.org/xen-devel/20241106003938.3453243-1-andrew.coop...@citrix.com/T/#mdf923bdf63b034a6493bf62beeead280b92a38ed
>>>
On 13/11/2024 15:40, Julien Grall wrote:
>
>
> Hi,
>
> On 13/11/2024 14:19, Michal Orzel wrote:
>>
>>
>> On 13/11/2024 14:50, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 06/11/2024 15:07, Michal Orzel wrote:
On 06/11/2024 14:41, Luca Fancellu wrote:
>
>
>
On 13.11.24 16:20, Andrew Cooper wrote:
On 12/11/2024 1:00 pm, Jan Beulich wrote:
All,
the release is due by the end of the month. Please point out backports you find
missing from the respective staging branch, but which you consider relevant.
Looking over the XenServer patchqueue:
...
Th
Hi,
> On 13 Nov 2024, at 14:51, oleksii.kuroc...@gmail.com wrote:
>
> Hi Bertrand,
>
> On Wed, 2024-11-13 at 13:02 +, Bertrand Marquis wrote:
>> Hi Oleksii,
>>
>>> On 12 Nov 2024, at 16:16, Oleksii Kurochko
>>> wrote:
>>>
>>> Hello everyone,
>>>
>>> This email only tracks big items for x
On 11/13/24 5:41 AM, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
>
> hw/amd and how/intel enable th
On 12/11/2024 1:00 pm, Jan Beulich wrote:
> All,
>
> the release is due by the end of the month. Please point out backports you
> find
> missing from the respective staging branch, but which you consider relevant.
Looking over the XenServer patchqueue:
These are all bugfixes, some that came from
Hi,
On 13/11/2024 14:19, Michal Orzel wrote:
On 13/11/2024 14:50, Julien Grall wrote:
Hi Michal,
On 06/11/2024 15:07, Michal Orzel wrote:
On 06/11/2024 14:41, Luca Fancellu wrote:
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memo
On 13/11/2024 14:33, Luca Fancellu wrote:
Hi Julien,
Hi,
On 13 Nov 2024, at 14:01, Julien Grall wrote:
Hi Luca,
On 06/11/2024 13:41, Luca Fancellu wrote:
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memory node, in this case the
cu
On Wed, 2024-11-13 at 14:25 +0100, Jürgen Groß wrote:
> On 12.11.24 17:16, Oleksii Kurochko wrote:
> > Hello everyone,
> >
> > This email only tracks big items for xen.git tree. Please reply for
> > items you
> > would like to see in 4.20 so that people have an idea what is going
> > on and
> > pr
The pseudo keyword fallthrough shall be used to make explicit the
fallthrough intention at the end of a case statement (doing this
using comments is deprecated).
A definition of such pseudo keyword is already present in the
Xen build. This auxiliary definition makes it available also for
for test
On Wed, 2024-11-13 at 10:48 +0100, Jan Beulich wrote:
> On 12.11.2024 17:16, Oleksii Kurochko wrote:
> > === x86 ===
> >
> > * Expose consistent topology to guests (v7)
> > - Alejandro Vallejo
> > -
> > https://lore.kernel.org/xen-devel/20241021154600.11745-1-alejandro.vall...@cloud.com/T/#m
Hi Bertrand,
On Wed, 2024-11-13 at 13:02 +, Bertrand Marquis wrote:
> Hi Oleksii,
>
> > On 12 Nov 2024, at 16:16, Oleksii Kurochko
> > wrote:
> >
> > Hello everyone,
> >
> > This email only tracks big items for xen.git tree. Please reply for
> > items you
> > would like to see in 4.20 so t
Hi Julien,
> On 13 Nov 2024, at 14:01, Julien Grall wrote:
>
> Hi Luca,
>
> On 06/11/2024 13:41, Luca Fancellu wrote:
>> There are some cases where the device tree exposes a memory range
>> in both /memreserve/ and reserved-memory node, in this case the
>> current code will stop Xen to boot sin
On 13/11/2024 14:50, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 06/11/2024 15:07, Michal Orzel wrote:
>>
>>
>> On 06/11/2024 14:41, Luca Fancellu wrote:
>>>
>>>
>>> There are some cases where the device tree exposes a memory range
>>> in both /memreserve/ and reserved-memory node, in this ca
On 13/11/2024 11:21 am, Jan Beulich wrote:
> Originally only twobyte_table[0x3a] determined what part of generic
> operand fetching (near the top of x86_emulate()) comes into play. When
> ext0f3a_table[] was added, ->desc was updated to properly describe the
> ModR/M byte's function. With that gene
On 13/11/2024 8:01 am, Jan Beulich wrote:
> On 13.11.2024 01:24, Andrew Cooper wrote:
>> On 12/11/2024 3:00 pm, Jan Beulich wrote:
>>> While result values and other status flags are unaffected as long as we
>>> can ignore the case of registers having their upper 32 bits non-zero
>>> outside of 64-b
Hi Luca,
On 06/11/2024 13:41, Luca Fancellu wrote:
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memory node, in this case the
current code will stop Xen to boot since it will find that the
latter range is clashing with the already recorded /
Hi Michal,
On 06/11/2024 15:07, Michal Orzel wrote:
On 06/11/2024 14:41, Luca Fancellu wrote:
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memory node, in this case the
current code will stop Xen to boot since it will find that the
latt
On Wed, Nov 13, 2024 at 11:19 AM Andrew Cooper
wrote:
>
> On 13/11/2024 10:20 am, Jan Beulich wrote:
> > On 13.11.2024 10:30, Andrew Cooper wrote:
> >> This is, to the best of my knowledge, accurate. I am providing no comment
> >> on
> >> how sane I believe it to be.
> >>
> >> At the time of wri
On Wed, Nov 13, 2024 at 12:01:23PM +0100, Jan Beulich wrote:
> On 13.11.2024 11:56, Roger Pau Monné wrote:
> > On Wed, Nov 13, 2024 at 11:36:46AM +0100, Jan Beulich wrote:
> >> On 13.11.2024 11:30, Roger Pau Monné wrote:
> >>> On Wed, Nov 13, 2024 at 10:00:33AM +, Chen, Jiqian wrote:
> On
On 13/11/2024 1:31 pm, Andrew Cooper wrote:
> On 13/11/2024 8:01 am, Jan Beulich wrote:
>> On 13.11.2024 01:24, Andrew Cooper wrote:
>>> On 12/11/2024 3:00 pm, Jan Beulich wrote:
While result values and other status flags are unaffected as long as we
can ignore the case of registers havin
On 12.11.24 17:16, Oleksii Kurochko wrote:
Hello everyone,
This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.20 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the
Hi Oleksii,
> On 12 Nov 2024, at 16:16, Oleksii Kurochko wrote:
>
> Hello everyone,
>
> This email only tracks big items for xen.git tree. Please reply for items you
> would like to see in 4.20 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to pro
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
hw/amd and how/intel enable their PCI-Device with pci_enable_device().
Thus, they need
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
All users of amd_mp2_pci_remove(), where pci_intx() is used, call
pcim_enable_device(),
On Wed, Nov 13, 2024 at 12:29:11PM +0100, Jan Beulich wrote:
> On 13.11.2024 12:24, Roger Pau Monné wrote:
> > On Wed, Nov 13, 2024 at 12:01:23PM +0100, Jan Beulich wrote:
> >> On 13.11.2024 11:56, Roger Pau Monné wrote:
> >>> On Wed, Nov 13, 2024 at 11:36:46AM +0100, Jan Beulich wrote:
> On 1
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
cardreader/rtsx_pcr.c and tifm_7xx1.c enable their PCI-Device with
pci_enable_device().
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
vfio enables its PCI-Device with pci_enable_device(). Thus, it
needs the never-managed
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
All users in ata enable their PCI-Device with pcim_enable_device(). Thus,
they need the
On 13.11.2024 09:17, Federico Serafini wrote:
> Tag MISRA C:2012 Rule 16.3 as clean for both architectures:
> new violations will cause a failure of the CI/CD pipeline.
>
> Signed-off-by: Federico Serafini
> ---
> No changes from v1.
> ---
> automation/eclair_analysis/ECLAIR/tagging.ecl | 3 ++-
pci_intx() is a hybrid function which sometimes performs devres
operations, depending on whether pcim_enable_device() has been used to
enable the pci_dev. This sometimes-managed nature of the function is
problematic. Notably, it causes the function to allocate under some
circumstances which makes i
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
broadcom/bnx2x and brocade/bna enable their PCI-Device with
pci_enable_device(). Thus,
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
MSI sets up its own separate devres callback implicitly in
pcim_setup_msi_release(). Th
pci_intx() is a hybrid function which can sometimes be managed through
devres. This hybrid nature is undesirable.
Since all users of pci_intx() have by now been ported either to
always-managed pcim_intx() or never-managed pci_intx_unmanaged(), the
devres functionality can be removed from pci_intx(
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
qtnfmac enables its PCI-Device with pcim_enable_device(). Thus, it needs
the always-man
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
xen enables its PCI-Device with pci_enable_device(). Thus, it
needs the never-managed v
@Driver-Maintainers: Your driver might be touched by patch "Remove
devres from pci_intx()". You might want to take a look.
Changes in v2:
- Drop pci_intx() deprecation patch.
- ata: Add RB from Sergey and Niklas.
- wifi: Add AB by Kalle.
- Drop INTx deprecation patch
- Drop ALSA / hda_in
On 13/11/2024 10:14 am, Luca Fancellu wrote:
> Hi all,
>
>> On 12 Nov 2024, at 16:11, Julien Grall wrote:
>>
>> Hi,
>>
>> On 12/11/2024 16:00, Stewart Hildebrand wrote:
>>> On 11/12/24 08:00, Jan Beulich wrote:
All,
the release is due by the end of the month. Please point out
b
On 13.11.2024 12:36, Andrew Cooper wrote:
> On 13/11/2024 9:30 am, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
>> index 7930b7c73892..9d3f2b71447e 100644
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -633,7 +633,7
The logic is far more sane to follow with a total size, and the position of
the end of the heap. Remove or fix the the remaining descriptions of how the
trampoline is laid out.
No functional change. The compiled binary is identical.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger P
On 13.11.2024 12:24, Roger Pau Monné wrote:
> On Wed, Nov 13, 2024 at 12:01:23PM +0100, Jan Beulich wrote:
>> On 13.11.2024 11:56, Roger Pau Monné wrote:
>>> On Wed, Nov 13, 2024 at 11:36:46AM +0100, Jan Beulich wrote:
On 13.11.2024 11:30, Roger Pau Monné wrote:
> On Wed, Nov 13, 2024 at 1
On 13.11.2024 12:19, Andrew Cooper wrote:
> On 13/11/2024 10:20 am, Jan Beulich wrote:
>> On 13.11.2024 10:30, Andrew Cooper wrote:
>>> This is, to the best of my knowledge, accurate. I am providing no comment
>>> on
>>> how sane I believe it to be.
>>>
>>> At the time of writing, the sizes of th
On Wed, Nov 13, 2024 at 11:36 AM Andrew Cooper
wrote:
>
> On 13/11/2024 9:30 am, Andrew Cooper wrote:
> > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> > index 7930b7c73892..9d3f2b71447e 100644
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
>
On 13.11.2024 12:52, Andrew Cooper wrote:
> On 13/11/2024 10:23 am, Jan Beulich wrote:
>> On 13.11.2024 10:30, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/include/asm/config.h
>>> +++ b/xen/arch/x86/include/asm/config.h
>>> @@ -51,8 +51,9 @@
>>>
>>> #define IST_SHSTK_SIZE 1024
>>>
>>> -#define
On 13/11/2024 10:23 am, Jan Beulich wrote:
> On 13.11.2024 10:30, Andrew Cooper wrote:
>> --- a/xen/arch/x86/include/asm/config.h
>> +++ b/xen/arch/x86/include/asm/config.h
>> @@ -51,8 +51,9 @@
>>
>> #define IST_SHSTK_SIZE 1024
>>
>> -#define TRAMPOLINE_STACK_SPACE PAGE_SIZE
>> -#define TRAMP
On 13/11/2024 9:30 am, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 7930b7c73892..9d3f2b71447e 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -633,7 +633,7 @@ static void __init efi_arch_memory_setup(void)
On Tue, 2024-11-12 at 12:22 +0100, Jan Beulich wrote:
> On 11.11.2024 19:16, Oleksii Kurochko wrote:
> > @@ -25,8 +27,11 @@
> >
> > static inline void *maddr_to_virt(paddr_t ma)
> > {
> > - BUG_ON("unimplemented");
> > - return NULL;
> > + unsigned long va_offset = maddr_to_directmapof
On 13.11.2024 12:19, Andrew Cooper wrote:
> On 13/11/2024 10:20 am, Jan Beulich wrote:
>> On 13.11.2024 10:30, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/include/asm/trampoline.h
>>> +++ b/xen/arch/x86/include/asm/trampoline.h
>>> @@ -37,12 +37,63 @@
>>> * manually as part of placement.
>>> */
Originally only twobyte_table[0x3a] determined what part of generic
operand fetching (near the top of x86_emulate()) comes into play. When
ext0f3a_table[] was added, ->desc was updated to properly describe the
ModR/M byte's function. With that generic source operand fetching came
into play for RORX
On 13/11/2024 10:20 am, Jan Beulich wrote:
> On 13.11.2024 10:30, Andrew Cooper wrote:
>> This is, to the best of my knowledge, accurate. I am providing no comment on
>> how sane I believe it to be.
>>
>> At the time of writing, the sizes of the regions are:
>>
>> offset size
>> AP:
On 13/11/24 10:57, Jan Beulich wrote:
On 13.11.2024 09:17, Federico Serafini wrote:
Tag MISRA C:2012 Rule 16.3 as clean for both architectures:
new violations will cause a failure of the CI/CD pipeline.
Signed-off-by: Federico Serafini
---
No changes from v1.
---
automation/eclair_analysis/E
On 13.11.2024 10:30, Andrew Cooper wrote:
> --- a/xen/arch/x86/include/asm/config.h
> +++ b/xen/arch/x86/include/asm/config.h
> @@ -51,8 +51,9 @@
>
> #define IST_SHSTK_SIZE 1024
>
> -#define TRAMPOLINE_STACK_SPACE PAGE_SIZE
> -#define TRAMPOLINE_SPACE(KB(64) - TRAMPOLINE_STACK_SPACE)
On 13.11.2024 11:56, Roger Pau Monné wrote:
> On Wed, Nov 13, 2024 at 11:36:46AM +0100, Jan Beulich wrote:
>> On 13.11.2024 11:30, Roger Pau Monné wrote:
>>> On Wed, Nov 13, 2024 at 10:00:33AM +, Chen, Jiqian wrote:
On 2024/11/13 17:30, Roger Pau Monné wrote:
> On Wed, Nov 13, 2024 at
On Wed, Nov 13, 2024 at 10:18 AM Frediano Ziglio
wrote:
>
> On Wed, Nov 13, 2024 at 9:31 AM Andrew Cooper
> wrote:
> >
> > The logic is far more sane to follow with a total size, and the position of
> > the end of the heap. Remove or fix the the remaining descriptions of how
> > the
>
> typo:
On Wed, Nov 13, 2024 at 11:36:46AM +0100, Jan Beulich wrote:
> On 13.11.2024 11:30, Roger Pau Monné wrote:
> > On Wed, Nov 13, 2024 at 10:00:33AM +, Chen, Jiqian wrote:
> >> On 2024/11/13 17:30, Roger Pau Monné wrote:
> >>> On Wed, Nov 13, 2024 at 04:00:27PM +0800, Jiqian Chen wrote:
> Som
On 13.11.2024 11:48, Alessandro Zucchelli wrote:
> At this link you can see all the violations of Rule 5.2:
>
> https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/people/bugseng/xen/ECLAIR_normal/40_characters/X86_64/8143097084/PROJECT.ecd;/by_service/MC3R1.R5.2.html
Hi Jan,
At this link you can see all the violations of Rule 5.2:
https://saas.eclairit.com:3787/fs/var/local/eclair/xen-project.ecdf/xen-project/people/bugseng/xen/ECLAIR_normal/40_characters/X86_64/8143097084/PROJECT.ecd;/by_service/MC3R1.R5.2.html
By deviating the two macros CHECK_NAME_ and DE
Hi All,
On 07.11.24 11:42, Grygorii Strashko wrote:
On 06.11.24 17:16, Luca Fancellu wrote:
Hi Michal,
So we have 2 separate issues. I don't particularly like the concept of
introducing MEMBANK_NONE
and the changes below look a bit too much for me, given that for boot modules
we can onl
On 13.11.2024 10:38, Alessandro Zucchelli wrote:
> This addresses violations of MISRA C:2012 Rule 5.4 which states as
> following: Macro identifiers shall be distinct.
>
> This deviation aims to address violations of Rule 5.4 regarding
> identifiers XLAT_hvm_altp2m_set_mem_access_multi_HNDL_pfn_li
On 13.11.2024 11:30, Roger Pau Monné wrote:
> On Wed, Nov 13, 2024 at 10:00:33AM +, Chen, Jiqian wrote:
>> On 2024/11/13 17:30, Roger Pau Monné wrote:
>>> On Wed, Nov 13, 2024 at 04:00:27PM +0800, Jiqian Chen wrote:
Some devices, like discrete GPU of amd, support resizable bar capability,
On 13.11.2024 09:41, Alessandro Zucchelli wrote:
> This addresses violations of MISRA C:2012 Rule 5.2 which states as
> following: Identifiers declared in the same scope and name space shall
> be distinct.
>
> This deviation addresses violations of Rule 5.2 arising from
> identifiers generated thr
On Wed, Nov 13, 2024 at 10:00:33AM +, Chen, Jiqian wrote:
> On 2024/11/13 17:30, Roger Pau Monné wrote:
> > On Wed, Nov 13, 2024 at 04:00:27PM +0800, Jiqian Chen wrote:
> >> Some devices, like discrete GPU of amd, support resizable bar capability,
> >> but vpci of Xen doesn't support this featu
On 13.11.2024 10:30, Andrew Cooper wrote:
> This is, to the best of my knowledge, accurate. I am providing no comment on
> how sane I believe it to be.
>
> At the time of writing, the sizes of the regions are:
>
> offset size
> AP: 0x 0x00b0
> S3: 0x00b0 0x0140
> B
On Wed, Nov 13, 2024 at 9:31 AM Andrew Cooper wrote:
>
> The logic is far more sane to follow with a total size, and the position of
> the end of the heap. Remove or fix the the remaining descriptions of how the
typo: the the
> trampoline is laid out.
>
> No functional change. The compiled bin
Hi all,
On 12 Nov 2024, at 16:11, Julien Grall wrote:
Hi,
On 12/11/2024 16:00, Stewart Hildebrand wrote:
On 11/12/24 08:00, Jan Beulich wrote:
All,
the release is due by the end of the month. Please point out backports you find
missing from the respective staging branch, but which you consider
On Wed, Nov 13, 2024 at 04:00:27PM +0800, Jiqian Chen wrote:
> Some devices, like discrete GPU of amd, support resizable bar capability,
> but vpci of Xen doesn't support this feature, so they fail to resize bars
> and then cause probing failure.
>
> According to PCIe spec, each bar that support r
Andrew Cooper (2):
x86/trampoline: Document how the trampoline is laid out
x86/trampoline: Rationalise the constants to describe the size
xen/arch/x86/boot/head.S | 21 +-
xen/arch/x86/boot/reloc.c | 5 +--
xen/arch/x86/efi/efi-boot.h | 2 +-
xen/a
On 2024-11-13 10:38, Alessandro Zucchelli wrote:
This addresses violations of MISRA C:2012 Rule 5.4 which states as
following: Macro identifiers shall be distinct.
This deviation aims to address violations of Rule 5.4 regarding
identifiers XLAT_hvm_altp2m_set_mem_access_multi_HNDL_pfn_list and
X
On 13.11.2024 09:17, Federico Serafini wrote:
> Make explicit the fallthrough intention by adding the pseudo keyword
> where missing and replace fallthrough comments not following the
> agreed syntax.
>
> This satisfies the requirements to deviate violations of
> MISRA C:2012 Rule 16.3 "An uncondi
This is, to the best of my knowledge, accurate. I am providing no comment on
how sane I believe it to be.
At the time of writing, the sizes of the regions are:
offset size
AP: 0x 0x00b0
S3: 0x00b0 0x0140
Boot: 0x01f0 0x1780
Heap: 0x1970 0xe690
Stack: 0xf
On 2024/11/13 17:30, Roger Pau Monné wrote:
> On Wed, Nov 13, 2024 at 04:00:27PM +0800, Jiqian Chen wrote:
>> Some devices, like discrete GPU of amd, support resizable bar capability,
>> but vpci of Xen doesn't support this feature, so they fail to resize bars
>> and then cause probing failure.
>>
This addresses violations of MISRA C:2012 Rule 5.4 which states as
following: Macro identifiers shall be distinct.
This deviation aims to address violations of Rule 5.4 regarding
identifiers XLAT_hvm_altp2m_set_mem_access_multi_HNDL_pfn_list and
XLAT_hvm_altp2m_set_mem_access_multi_HNDL_access_lis
MISRA C:2012 Directive 4.10 states as following: Precautions shall be
taken in order to prevent the contents of a header file being included
more than once.
This commit updates the documentation to describe the behavior defined
for the checker.
No functional change.
Signed-off-by: Alessandro Zuc
On 13.11.2024 09:17, Federico Serafini wrote:
> --- a/tools/tests/x86_emulator/x86-emulate.h
> +++ b/tools/tests/x86_emulator/x86-emulate.h
> @@ -70,6 +70,16 @@
> extern uint32_t mxcsr_mask;
> extern struct cpu_policy cpu_policy;
>
> +/*
> + * Pseudo keyword 'fallthrough' to make explicit the f
Hi,
On 18/10/2024 16:51, Ayan Kumar Halder wrote:
From: Michal Orzel
Add requirements for dom0less domain creation.
Signed-off-by: Michal Orzel
Signed-off-by: Ayan Kumar Halder
---
.../arm64/dom0less_domain_config.rst | 267 ++
docs/fusa/reqs/market-reqs/reqs.rst
On 12.11.2024 17:16, Oleksii Kurochko wrote:
> === x86 ===
>
> * Expose consistent topology to guests (v7)
> - Alejandro Vallejo
> -
> https://lore.kernel.org/xen-devel/20241021154600.11745-1-alejandro.vall...@cloud.com/T/#m6033f95c660675039d7789d3af1ba2f292a3a69b
>
> * Boot modules for Hy
On 13.11.2024 04:15, Stefano Stabellini wrote:
> It is challenging to create a solution that satisfies everyone for this
> patch. However, we should add R8.3 to the clean list as soon as possible
> to enable rule blocking in GitLab-CI. Failing to do so risks introducing
> regressions, as recently o
Make explicit the fallthrough intention by adding the pseudo keyword
where missing and replace fallthrough comments not following the
agreed syntax.
This satisfies the requirements to deviate violations of
MISRA C:2012 Rule 16.3 "An unconditional break statement shall
terminate every switch-clause
Define pseudo keyword fallthrough for the x86 emulator,
use it and tag the rule as clean.
Federico Serafini (3):
x86/emul: auxiliary definition of pseudo keyword fallthrough
x86/emul: use pseudo keyword fallthrough
automation/eclair: tag Rule 16.3 as clean
automation/eclair_analysis/ECLAIR
Tag MISRA C:2012 Rule 16.3 as clean for both architectures:
new violations will cause a failure of the CI/CD pipeline.
Signed-off-by: Federico Serafini
---
No changes from v1.
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
1 - 100 of 102 matches
Mail list logo
