On 26.10.2023 03:16, Stefano Stabellini wrote:
> On Wed, 25 Oct 2023, Jan Beulich wrote:
>> On 25.10.2023 03:15, Stefano Stabellini wrote:
>>> And if we can find a clear general comment about the usage of leading
>>> underscores in Xen I am happy to add it too (e.g. header guards), but
>>> from MIS
/src/consumer/arch/x86/kernel/traps.c:642)
[ 1.960101][ T0] ? exc_bounds (kbuild/src/consumer/arch/x86/kernel/traps.c:642)
[ 1.960579][ T0] ? handle_exception
(kbuild/src/consumer/arch/x86/entry/entry_32.S:1049)
The kernel config and materials to reproduce are available at:
https://download.01
Hi,
On 26/10/2023 07:46, Jun Nie wrote:
>
>
> Signed-off-by: Jun Nie
> ---
> xen/arch/arm/Kconfig.debug | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
> index 842d768280..fefe8ac4df 100644
> --- a/xen/arch/arm/Kconfig.debu
On 25.10.2023 23:12, Stefano Stabellini wrote:
> On Wed, 25 Oct 2023, Julien Grall wrote:
>> On 25/10/2023 17:01, Jan Beulich wrote:
>>> On 25.10.2023 17:58, Julien Grall wrote:
On 25/10/2023 09:18, Jan Beulich wrote:
> On 24.10.2023 21:59, Stefano Stabellini wrote:
>> If I understood
9026][ T0] ? die_addr
> (kbuild/src/consumer/arch/x86/kernel/dumpstack.c:421
> kbuild/src/consumer/arch/x86/kernel/dumpstack.c:460)
> [ 1.959480][ T0] ? exc_general_protection
> (kbuild/src/consumer/arch/x86/kernel/traps.c:697
> kbuild/src/consumer/arch/x86/kernel/traps.c:642)
>
Michal Orzel 于2023年10月26日周四 15:02写道：
>
> Hi,
>
> On 26/10/2023 07:46, Jun Nie wrote:
> >
> >
> > Signed-off-by: Jun Nie
> > ---
> > xen/arch/arm/Kconfig.debug | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
> > index 842
On 26/10/2023 09:22, Jun Nie wrote:
>
>
> Michal Orzel 于2023年10月26日周四 15:02写道：
>>
>> Hi,
>>
>> On 26/10/2023 07:46, Jun Nie wrote:
>>>
>>>
>>> Signed-off-by: Jun Nie
>>> ---
>>> xen/arch/arm/Kconfig.debug | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/Kconf
On 26.10.2023 08:45, Xenia Ragiadakou wrote:
> Given that start < kernel_end and end > kernel_start, the logic that
> determines the best placement for dom0 initrd and metadata, does not
> take into account the two cases below:
> (1) start > kernel_start && end > kernel_end
> (2) start < kernel_sta
On 25.10.2023 20:06, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -847,25 +847,19 @@ int __init early_microcode_init(unsigned long
> *module_map,
> {
> const struct cpuinfo_x86 *c = &boot_cpu_data;
> int rc = 0;
> -boo
On 25.10.2023 20:06, Andrew Cooper wrote:
> We eventually want to be able to build a stripped down Xen for a single
> platform. Make a start with CONFIG_{AMD,INTEL} (hidden behind EXPERT, but
> available to randconfig), and adjust the microcode logic.
Linux uses different names for the Kconfig sy
On 24.10.2023 16:53, Roger Pau Monne wrote:
> Sporadically we have seen the following during AP bringup on AMD platforms
> only:
>
> microcode: CPU59 updated from revision 0x830107a to 0x830107a, date =
> 2023-05-17
> microcode: CPU60 updated from revision 0x830104d to 0x830107a, date =
> 2023-0
On 26.10.2023 00:41, Shawn Anastasio wrote:
> Implement a basic exception handler that dumps the CPU state to the
> console, as well as the code required to set the correct exception
> vector table's base address in setup.c.
>
> Signed-off-by: Shawn Anastasio
Despite me being unhappy about the d
On 26/10/2023 08:49, Jan Beulich wrote:
On 26.10.2023 00:34, Stefano Stabellini wrote:
On Wed, 25 Oct 2023, Jan Beulich wrote:
On 24.10.2023 22:30, Stefano Stabellini wrote:
On Tue, 24 Oct 2023, Nicola Vetrini wrote:
As specified in rules.rst, these constants can be used
in the code.
Signed-
Hi guys,
This is a new question.
Has anyone tried networking communication in Xen Cache Coloring mode ?
I mean connect from one DomU to another one DomU for example ?
It may be achieved by xl command.
Or maybe a goto device which has xen with Dom0 in CC mode from the host ?
Regards,
Oleg
As specified in rules.rst, these constants can be used
in the code.
Signed-off-by: Nicola Vetrini
---
Changes in v2:
- replace some SAF deviations with configurations
Changes in v3:
- refine configurations and justifications
Changes in v4:
- updated deviation record comment.
---
automation/eclai
Am 25.10.2023 um 20:56 hat Andrew Cooper geschrieben:
> On 25/10/2023 7:26 pm, David Woodhouse wrote:
> > On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote:
> >> On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote:
> >>> +
> >>> +Booting Xen PV guests
> >>> +-
> >>
On 26/10/23 10:35, Jan Beulich wrote:
On 26.10.2023 08:45, Xenia Ragiadakou wrote:
Given that start < kernel_end and end > kernel_start, the logic that
determines the best placement for dom0 initrd and metadata, does not
take into account the two cases below:
(1) start > kernel_start && end > k
On Thu, May 11, 2023 at 02:06:46PM +0200, Jan Beulich wrote:
> ... in order to also deny Dom0 access through the alias ports. Without
> this it is only giving the impression of denying access to both PICs.
> Unlike for CMOS/RTC, do detection very early, to avoid disturbing normal
> operation later
On 26.10.2023 10:18, Nicola Vetrini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -85,10 +85,12 @@ conform to the directive."
> # Series 7.
> #
>
> --doc_begin="Usage of the following constants is safe, since they a
Hi,
On 25/10/2023 18:59, Michal Orzel wrote:
Hi Ayan,
On 25/10/2023 19:03, Ayan Kumar Halder wrote:
Before the MMU is turned on, the address returned for any symbol will always be
physical address. Thus, one can use adr_l instead of load_paddr.
create_table_entry() now takes an extra argument
On 26.10.2023 10:34, Xenia Ragiadakou wrote:
> On 26/10/23 10:35, Jan Beulich wrote:
>> On 26.10.2023 08:45, Xenia Ragiadakou wrote:
>>> Given that start < kernel_end and end > kernel_start, the logic that
>>> determines the best placement for dom0 initrd and metadata, does not
>>> take into accoun
Hi Julien,
On 26/10/2023 10:40, Julien Grall wrote:
>
>
> Hi,
>
> On 25/10/2023 18:59, Michal Orzel wrote:
>> Hi Ayan,
>>
>> On 25/10/2023 19:03, Ayan Kumar Halder wrote:
>>> Before the MMU is turned on, the address returned for any symbol will
>>> always be
>>> physical address. Thus, one can
On 26.10.2023 10:34, Roger Pau Monné wrote:
> On Thu, May 11, 2023 at 02:06:46PM +0200, Jan Beulich wrote:
>> ... in order to also deny Dom0 access through the alias ports. Without
>> this it is only giving the impression of denying access to both PICs.
>> Unlike for CMOS/RTC, do detection very ear
On Thu, 2023-10-26 at 10:26 +0200, Kevin Wolf wrote:
>
> > > > > +.. parsed-literal::
> > > > > +
> > > > > + |qemu_system| --accel kvm,xen-version=0x40011,kernel-irqchip=split
> > > > > \\
> > > > > + -chardev stdio,id=char0 -device xen-console,chardev=char0 \\
> > > > > + -display
Hi Mykyta,
On 2023/10/25 18:13, Mykyta Poturai wrote:
We will need GICv3 code to access get/put irq to inject LPIs for new
VGIC similar to how the old one uses irq_to_pending now. So move
get/put irq to the same header file.
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/include/asm/vgic.h
Hi Mykyta,
On 2023/10/25 18:13, Mykyta Poturai wrote:
Add support for basic GICv3 functionality to new vgic. The code is
ported from Kernel version 6.0. The distributor, redistributor and
CPU interface are ported and hooked up to the XEN interfaces.
The code is adapted to Xen coding style and co
Hi,
On 25/10/2023 18:03, Ayan Kumar Halder wrote:
Before the MMU is turned on, the address returned for any symbol will always be
physical address. Thus, one can use adr_l instead of load_paddr.
create_table_entry() now takes an extra argument to denote if it is called after
the mmu is turned o
On 26/10/2023 00:36, Stefano Stabellini wrote:
On Wed, 25 Oct 2023, Nicola Vetrini wrote:
On 24/10/2023 21:50, Stefano Stabellini wrote:
> On Tue, 24 Oct 2023, Nicola Vetrini wrote:
> > On 24/10/2023 10:14, Jan Beulich wrote:
> > > On 24.10.2023 10:01, Nicola Vetrini wrote:
> > > > On 24/10/2023
On 26/10/23 11:45, Jan Beulich wrote:
On 26.10.2023 10:34, Xenia Ragiadakou wrote:
On 26/10/23 10:35, Jan Beulich wrote:
On 26.10.2023 08:45, Xenia Ragiadakou wrote:
Given that start < kernel_end and end > kernel_start, the logic that
determines the best placement for dom0 initrd and metadata
Hi Julien,
On 25.10.23 13:22, Julien Grall wrote:
> Looking at the change, you mainly add #ifdef in the code. The goal of
> gic-v3-lpi.c was to be agnostic from the different vGIC. So please
> abstract it.
Would it be okay to add something like "typedef struct vgic_irq
pending_irq" to deal w
flight 183536 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183536/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8765f3eb428f86974033215fe08f8d3d85deedae
baseline version:
ovmf 9bb5ef1287c6765c477fb
Update ECLAIR configuration to deviate Rule 8.3 ("All declarations of
an object or function shall use the same names and type qualifiers")
for the following functions: guest_walk_tables_[0-9]+_levels().
Update file docs/misra/deviations.rst accordingly.
No functional change.
Signed-off-by: Federic
Hi,
On 26/10/2023 11:04, Federico Serafini wrote:
Update ECLAIR configuration to deviate Rule 8.3 ("All declarations of
an object or function shall use the same names and type qualifiers")
for the following functions: guest_walk_tables_[0-9]+_levels().
Update file docs/misra/deviations.rst accor
On Thu, May 11, 2023 at 02:07:12PM +0200, Jan Beulich wrote:
> ... in order to also deny Dom0 access through the alias ports. Without
> this it is only giving the impression of denying access to PIT. Unlike
> for CMOS/RTC, do detection pretty early, to avoid disturbing normal
> operation later on (
On 26/10/2023 9:34 am, Xenia Ragiadakou wrote:
> On 26/10/23 10:35, Jan Beulich wrote:
>> On 26.10.2023 08:45, Xenia Ragiadakou wrote:
>>> Given that start < kernel_end and end > kernel_start, the logic that
>>> determines the best placement for dom0 initrd and metadata, does not
>>> take into acco
On 26/10/2023 08:52, Jan Beulich wrote:
On 26.10.2023 00:38, Stefano Stabellini wrote:
On Wed, 25 Oct 2023, Jan Beulich wrote:
On 25.10.2023 16:50, Nicola Vetrini wrote:
Ok, I'll send a revised version using MASK_LOWEST_BIT, taking into
account also the
other comments about the explanation on
Rework the exclusion_file_list.py code to have the function
load_exclusion_file_list() detached from the xen-analysis.py tool,
in a way so that other modules can use the function.
The xen-analysis tool and in particular its module cppcheck_analysis.py
will use a new function cppcheck_exclusion_file
This serie is generalising the exclude-list.json so that it can be used by
multiple checkers that might want to have a list of excluded files to be removed
from their computation.
Luca Fancellu (2):
cppcheck: rework exclusion_file_list.py code
exclude-list: generalise exclude-list
docs/misra
Currently exclude-list.json is used by the xen-analysis tool to
remove from the report (cppcheck for now) violations from the
files listed in it, however that list can be used by different
users that might want to exclude some of the files from their
computation for many reasons.
So add a new fiel
On Thu, May 11, 2023 at 02:07:40PM +0200, Jan Beulich wrote:
> This controls the driving of IGNNE# (if such emulation is enabled in
> hardware), and hence would need proper handling in the hypervisor to be
> safe to use by Dom0 (and fully emulating for PVH/HVM DomU-s).
>
> Signed-off-by: Jan Beuli
On Thu, May 11, 2023 at 02:08:09PM +0200, Jan Beulich wrote:
> Much like the other PIC ports, Dom0 has no business touching these. Even
> our own uses are somewhat questionable, as the corresponding IO-APIC
> code in Linux is enclosed in a CONFIG_EISA conditional; I don't think
> there are any x86-
On 26/10/2023 8:55 am, Jan Beulich wrote:
> On 25.10.2023 20:06, Andrew Cooper wrote:
>> We eventually want to be able to build a stripped down Xen for a single
>> platform. Make a start with CONFIG_{AMD,INTEL} (hidden behind EXPERT, but
>> available to randconfig), and adjust the microcode logic.
Before the MMU is turned on, PC uses physical address. Thus, one can use adr_l
instead of load_paddr to obtain the physical address of a symbol.
The only exception (for this replacement) is create_table_entry() which is
called before and after MMU is turned on.
Also, in lookup_processor_type() "r
On 26/10/2023 10:40, Julien Grall wrote:
Hi,
Hi Julien/Michal,
On 25/10/2023 18:03, Ayan Kumar Halder wrote:
Before the MMU is turned on, the address returned for any symbol will
always be
physical address. Thus, one can use adr_l instead of load_paddr.
create_table_entry() now takes an e
Hi,
Title: This reads as you replace all adr_l with load_paddr. So how about:
xen/arm32: head: Replace load_paddr with adr_l when they are equivalent
On 26/10/2023 12:12, Ayan Kumar Halder wrote:
Before the MMU is turned on, PC uses physical address. Thus, one can use adr_l
instead of load_pad
On 26/10/2023 8:45 am, Jan Beulich wrote:
> On 25.10.2023 20:06, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/microcode/core.c
>> +++ b/xen/arch/x86/cpu/microcode/core.c
>> @@ -847,25 +847,19 @@ int __init early_microcode_init(unsigned long
>> *module_map,
>> {
>> const struct cpuinfo_x86
On Thu, Oct 26, 2023 at 09:59:42AM +0200, Jan Beulich wrote:
> On 24.10.2023 16:53, Roger Pau Monne wrote:
> > Sporadically we have seen the following during AP bringup on AMD platforms
> > only:
> >
> > microcode: CPU59 updated from revision 0x830107a to 0x830107a, date =
> > 2023-05-17
> > micr
On 26.10.2023 13:10, Andrew Cooper wrote:
> On 26/10/2023 8:55 am, Jan Beulich wrote:
>> On 25.10.2023 20:06, Andrew Cooper wrote:
>>> We eventually want to be able to build a stripped down Xen for a single
>>> platform. Make a start with CONFIG_{AMD,INTEL} (hidden behind EXPERT, but
>>> available
Hi,
On 26/10/2023 11:32, Nicola Vetrini wrote:
On 26/10/2023 08:52, Jan Beulich wrote:
On 26.10.2023 00:38, Stefano Stabellini wrote:
On Wed, 25 Oct 2023, Jan Beulich wrote:
On 25.10.2023 16:50, Nicola Vetrini wrote:
Ok, I'll send a revised version using MASK_LOWEST_BIT, taking into
account
On 26.10.2023 12:31, Andrew Cooper wrote:
> On 26/10/2023 9:34 am, Xenia Ragiadakou wrote:
>> On 26/10/23 10:35, Jan Beulich wrote:
>>> On 26.10.2023 08:45, Xenia Ragiadakou wrote:
Given that start < kernel_end and end > kernel_start, the logic that
determines the best placement for dom0
On 26.10.2023 11:46, Xenia Ragiadakou wrote:
> On 26/10/23 11:45, Jan Beulich wrote:
>> On 26.10.2023 10:34, Xenia Ragiadakou wrote:
>>> On 26/10/23 10:35, Jan Beulich wrote:
On 26.10.2023 08:45, Xenia Ragiadakou wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom
Make function definitions and declarations consistent.
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/x86_64/cpu_idle.c | 5 ++--
xen/arch/x86/x86_64/cpufreq.c | 6 ++--
xen/drivers/cpufreq/cpufreq.c | 52 --
xen/include/xen/pmstat.h
On 26/10/23 14:41, Jan Beulich wrote:
On 26.10.2023 12:31, Andrew Cooper wrote:
On 26/10/2023 9:34 am, Xenia Ragiadakou wrote:
On 26/10/23 10:35, Jan Beulich wrote:
On 26.10.2023 08:45, Xenia Ragiadakou wrote:
Given that start < kernel_end and end > kernel_start, the logic that
determines the
On 26/10/23 12:25, Julien Grall wrote:
Hi,
On 26/10/2023 11:04, Federico Serafini wrote:
Update ECLAIR configuration to deviate Rule 8.3 ("All declarations of
an object or function shall use the same names and type qualifiers")
for the following functions: guest_walk_tables_[0-9]+_levels().
Upd
flight 183534 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183534/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt 7 xen-install fail in 183529 pass in 183534
test-amd64-amd64-dom0pvh-xl-inte
On 26.10.2023 12:25, Roger Pau Monné wrote:
> On Thu, May 11, 2023 at 02:07:12PM +0200, Jan Beulich wrote:
>> ... in order to also deny Dom0 access through the alias ports. Without
>> this it is only giving the impression of denying access to PIT. Unlike
>> for CMOS/RTC, do detection pretty early,
On 25/10/2023 09:56, Jan Beulich wrote:
On 24.10.2023 22:27, Stefano Stabellini wrote:
On Tue, 24 Oct 2023, Jan Beulich wrote:
On 24.10.2023 16:31, Nicola Vetrini wrote:
Partially explicitly initalized .matches arrays result in violations
of Rule 9.3; this is resolved by using designated initi
On 26.10.2023 14:09, Xenia Ragiadakou wrote:
> On 26/10/23 14:41, Jan Beulich wrote:
>> On 26.10.2023 12:31, Andrew Cooper wrote:
>>> On 26/10/2023 9:34 am, Xenia Ragiadakou wrote:
On 26/10/23 10:35, Jan Beulich wrote:
> On 26.10.2023 08:45, Xenia Ragiadakou wrote:
>> Given that start
On 26/10/23 14:51, Jan Beulich wrote:
On 26.10.2023 11:46, Xenia Ragiadakou wrote:
On 26/10/23 11:45, Jan Beulich wrote:
On 26.10.2023 10:34, Xenia Ragiadakou wrote:
On 26/10/23 10:35, Jan Beulich wrote:
On 26.10.2023 08:45, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++
On 26.10.2023 14:35, Xenia Ragiadakou wrote:
>
>
> On 26/10/23 14:51, Jan Beulich wrote:
>> On 26.10.2023 11:46, Xenia Ragiadakou wrote:
>>> On 26/10/23 11:45, Jan Beulich wrote:
On 26.10.2023 10:34, Xenia Ragiadakou wrote:
> On 26/10/23 10:35, Jan Beulich wrote:
>> On 26.10.2023 08:
On 26.10.2023 14:32, Nicola Vetrini wrote:
> On 25/10/2023 09:56, Jan Beulich wrote:
>> On 24.10.2023 22:27, Stefano Stabellini wrote:
>>> On Tue, 24 Oct 2023, Jan Beulich wrote:
On 24.10.2023 16:31, Nicola Vetrini wrote:
> Partially explicitly initalized .matches arrays result in violatio
On 26.10.2023 13:02, Roger Pau Monné wrote:
> On Thu, May 11, 2023 at 02:08:09PM +0200, Jan Beulich wrote:
>> Much like the other PIC ports, Dom0 has no business touching these. Even
>> our own uses are somewhat questionable, as the corresponding IO-APIC
>> code in Linux is enclosed in a CONFIG_EIS
On 26/10/2023 12:35 pm, Jan Beulich wrote:
> On 26.10.2023 13:10, Andrew Cooper wrote:
>> On 26/10/2023 8:55 am, Jan Beulich wrote:
>>> On 25.10.2023 20:06, Andrew Cooper wrote:
We eventually want to be able to build a stripped down Xen for a single
platform. Make a start with CONFIG_{AM
On Thu, Oct 26, 2023 at 11:03:42AM +0200, Jan Beulich wrote:
> On 26.10.2023 10:34, Roger Pau Monné wrote:
> > On Thu, May 11, 2023 at 02:06:46PM +0200, Jan Beulich wrote:
> >> ... in order to also deny Dom0 access through the alias ports. Without
> >> this it is only giving the impression of denyi
flight 183535 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183535/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 183521
test-armhf-armhf-libvirt-raw 15 saveresto
Hi Ayan,
On 26/10/2023 13:19, Julien Grall wrote:
>
>
> Hi,
>
> Title: This reads as you replace all adr_l with load_paddr. So how about:
>
> xen/arm32: head: Replace load_paddr with adr_l when they are equivalent
>
> On 26/10/2023 12:12, Ayan Kumar Halder wrote:
>> Before the MMU is turned o
Hi,
On 26/10/2023 13:13, Federico Serafini wrote:
On 26/10/23 12:25, Julien Grall wrote:
Hi,
On 26/10/2023 11:04, Federico Serafini wrote:
Update ECLAIR configuration to deviate Rule 8.3 ("All declarations of
an object or function shall use the same names and type qualifiers")
for the followi
On Thu, Oct 26, 2023 at 02:31:27PM +0200, Jan Beulich wrote:
> On 26.10.2023 12:25, Roger Pau Monné wrote:
> > On Thu, May 11, 2023 at 02:07:12PM +0200, Jan Beulich wrote:
> >> ... in order to also deny Dom0 access through the alias ports. Without
> >> this it is only giving the impression of denyi
On 26/10/23 15:37, Jan Beulich wrote:
On 26.10.2023 14:35, Xenia Ragiadakou wrote:
On 26/10/23 14:51, Jan Beulich wrote:
On 26.10.2023 11:46, Xenia Ragiadakou wrote:
On 26/10/23 11:45, Jan Beulich wrote:
On 26.10.2023 10:34, Xenia Ragiadakou wrote:
On 26/10/23 10:35, Jan Beulich wrote:
On 26/10/23 15:54, Julien Grall wrote:
Hi,
On 26/10/2023 13:13, Federico Serafini wrote:
On 26/10/23 12:25, Julien Grall wrote:
Hi,
On 26/10/2023 11:04, Federico Serafini wrote:
Update ECLAIR configuration to deviate Rule 8.3 ("All declarations of
an object or function shall use the same nam
Hi,
On 26/10/2023 15:04, Federico Serafini wrote:
On 26/10/23 15:54, Julien Grall wrote:
Hi,
On 26/10/2023 13:13, Federico Serafini wrote:
On 26/10/23 12:25, Julien Grall wrote:
Hi,
On 26/10/2023 11:04, Federico Serafini wrote:
Update ECLAIR configuration to deviate Rule 8.3 ("All declarat
On 26.10.2023 15:58, Xenia Ragiadakou wrote:
>
> On 26/10/23 15:37, Jan Beulich wrote:
>> On 26.10.2023 14:35, Xenia Ragiadakou wrote:
>>>
>>>
>>> On 26/10/23 14:51, Jan Beulich wrote:
On 26.10.2023 11:46, Xenia Ragiadakou wrote:
> On 26/10/23 11:45, Jan Beulich wrote:
>> On 26.10.202
On Thu, Oct 26, 2023 at 03:09:04PM +0300, Xenia Ragiadakou wrote:
> On 26/10/23 14:41, Jan Beulich wrote:
> > On 26.10.2023 12:31, Andrew Cooper wrote:
> > > On 26/10/2023 9:34 am, Xenia Ragiadakou wrote:
> > > > On 26/10/23 10:35, Jan Beulich wrote:
> > > > > On 26.10.2023 08:45, Xenia Ragiadakou
On Thu, Oct 26, 2023 at 04:55:36PM +0200, Jan Beulich wrote:
> On 26.10.2023 15:58, Xenia Ragiadakou wrote:
> >
> > On 26/10/23 15:37, Jan Beulich wrote:
> >> On 26.10.2023 14:35, Xenia Ragiadakou wrote:
> >>>
> >>>
> >>> On 26/10/23 14:51, Jan Beulich wrote:
> On 26.10.2023 11:46, Xenia Ragi
On 26.10.2023 15:24, Roger Pau Monné wrote:
> On Thu, Oct 26, 2023 at 11:03:42AM +0200, Jan Beulich wrote:
>> On 26.10.2023 10:34, Roger Pau Monné wrote:
>>> On Thu, May 11, 2023 at 02:06:46PM +0200, Jan Beulich wrote:
... in order to also deny Dom0 access through the alias ports. Without
On 26.10.2023 15:57, Roger Pau Monné wrote:
> On Thu, Oct 26, 2023 at 02:31:27PM +0200, Jan Beulich wrote:
>> On 26.10.2023 12:25, Roger Pau Monné wrote:
>>> On Thu, May 11, 2023 at 02:07:12PM +0200, Jan Beulich wrote:
... in order to also deny Dom0 access through the alias ports. Without
On Thu, Oct 26, 2023 at 05:10:41PM +0200, Jan Beulich wrote:
> On 26.10.2023 15:57, Roger Pau Monné wrote:
> > On Thu, Oct 26, 2023 at 02:31:27PM +0200, Jan Beulich wrote:
> >> On 26.10.2023 12:25, Roger Pau Monné wrote:
> >>> On Thu, May 11, 2023 at 02:07:12PM +0200, Jan Beulich wrote:
> ...
On Thu, Oct 26, 2023 at 05:07:18PM +0200, Jan Beulich wrote:
> On 26.10.2023 15:24, Roger Pau Monné wrote:
> > On Thu, Oct 26, 2023 at 11:03:42AM +0200, Jan Beulich wrote:
> >> On 26.10.2023 10:34, Roger Pau Monné wrote:
> >>> On Thu, May 11, 2023 at 02:06:46PM +0200, Jan Beulich wrote:
> ...
On Wed, 2023-10-25 at 18:23 -0700, Stefano Stabellini wrote:
> On Thu, 26 Oct 2023, David Woodhouse wrote:
> > On Wed, 2023-10-25 at 14:24 -0700, Vikram Garhwal wrote:
> > > From: Juergen Gross
> > >
> > > Virtio devices should never be unplugged at boot time, as they are
> > > similar to pci pas
On Thu, 2023-10-26 at 10:25 +0100, David Woodhouse wrote:
>
> > So it would have been entirely possible to use -initrd 'bzImage
> > console=hvc0 root=/dev/xvda1' if Xen worked like that.
>
> Xen does allow that too. I didn't realise our multiboot loader did though.
>
> So yes, you *can* use -in
> On 25 Oct 2023, at 21:59, Andrew Cooper wrote:
>
> On 25/10/2023 8:29 pm, Edwin Török wrote:
>> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
>> index 483b5e4f70..b3cd851d9d 100644
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -584,6 +584,13 @@ int guest_wrmsr(struct v
> On 25 Oct 2023, at 21:33, Andrew Cooper wrote:
>
> On 25/10/2023 8:29 pm, Edwin Török wrote:
>> From: Edwin Török
>>
>> Xen forbids writes to the various turbo control MSRs, however
>> MSR_PLATFORM_INFO claims that these MSRs are writable.
>> Override MSR_PLATFORM_INFO bits to indicate la
On 26/10/23 17:55, Jan Beulich wrote:
On 26.10.2023 15:58, Xenia Ragiadakou wrote:
On 26/10/23 15:37, Jan Beulich wrote:
On 26.10.2023 14:35, Xenia Ragiadakou wrote:
On 26/10/23 14:51, Jan Beulich wrote:
On 26.10.2023 11:46, Xenia Ragiadakou wrote:
On 26/10/23 11:45, Jan Beulich wrote:
On Thu, Oct 26, 2023 at 04:45:21PM +0100, David Woodhouse wrote:
> On Wed, 2023-10-25 at 18:23 -0700, Stefano Stabellini wrote:
> > On Thu, 26 Oct 2023, David Woodhouse wrote:
> > > On Wed, 2023-10-25 at 14:24 -0700, Vikram Garhwal wrote:
> > > > From: Juergen Gross
> > > >
> > > > Virtio devices
flight 183539 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183539/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fe43b426762c31c2f1958444d3aca388ec8d4702
baseline version:
ovmf 8765f3eb428f869740332
> On 25 Oct 2023, at 15:04, Jan Beulich wrote:
>
> On 25.10.2023 15:52, Edwin Török wrote:
>> --- a/tools/ocaml/Makefile.rules
>> +++ b/tools/ocaml/Makefile.rules
>> @@ -37,7 +37,7 @@ ALL_OCAML_OBJS ?= $(OBJS)
>> $(call quiet-command, $(OCAMLYACC) -q $<,MLYACC,$@)
>>
>> %.o: %.c
>> - $(call q
> On 25 Oct 2023, at 15:02, Christian Lindig wrote:
>
>
>
>> On 25 Oct 2023, at 14:52, Edwin Török wrote:
>>
>> From: Edwin Török
>>
>> The code currently uses GCC to compile OCaml C stubs directly,
>> and although in most cases this works, it is not entirely correct.
>>
>> This will fa
On 10/26/23 3:03 AM, Jan Beulich wrote:
> On 26.10.2023 00:41, Shawn Anastasio wrote:
>> Implement a basic exception handler that dumps the CPU state to the
>> console, as well as the code required to set the correct exception
>> vector table's base address in setup.c.
>>
>> Signed-off-by: Shawn An
On Thu, 26 Oct 2023, Luca Fancellu wrote:
> Rework the exclusion_file_list.py code to have the function
> load_exclusion_file_list() detached from the xen-analysis.py tool,
> in a way so that other modules can use the function.
> The xen-analysis tool and in particular its module cppcheck_analysis.
On Thu, 26 Oct 2023, Luca Fancellu wrote:
> Currently exclude-list.json is used by the xen-analysis tool to
> remove from the report (cppcheck for now) violations from the
> files listed in it, however that list can be used by different
> users that might want to exclude some of the files from thei
flight 183542 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183542/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 74c687cc2f2f29d3bdd454a416624f0ca5a86566
baseline version:
ovmf fe43b426762c31c2f1958
On 26/10/2023 11:01, Mykyta Poturai wrote:
Hi Julien,
Hi,
On 25.10.23 13:22, Julien Grall wrote:
Looking at the change, you mainly add #ifdef in the code. The goal of
gic-v3-lpi.c was to be agnostic from the different vGIC. So please
abstract it.
Would it be okay to add something like
Hi Stewart,
On 25/10/2023 20:05, Stewart Hildebrand wrote:
On 10/20/23 13:25, Julien Grall wrote:
On 09/10/2023 20:57, Stewart Hildebrand wrote:
Add a flag to struct xen_arch_domainconfig to allow specifying at domain
creation time whether the domain uses vPCI.
Add a corresponding flag to str
A fix to the recent Ucode changes which I ultimately didn't insist on owing to
the Xen 4.18 timeline, and enough of the start on the CPU Kconfig to allow
randconfig to check the boundary.
There are many more ucode fixes to come...
Andrew Cooper (2):
x86/ucode: Move vendor specifics back out of
I know it was me who dropped microcode_init_{intel,amd}() in c/s
dd5f07997f29 ("x86/ucode: Rationalise startup and family/model checks"), but
times have moved on. We've gained new conditional support, and a wish to
compile-time specialise Xen to single platform.
(Re)introduce ucode_probe_{amd,int
We eventually want to be able to build a stripped down Xen for a single
platform. Make a start with CONFIG_{AMD,INTEL} (hidden behind EXPERT, but
available to randconfig), and adjust the microcode logic.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
On 26/10/2023 5:39 pm, Edwin Torok wrote:
>> On 25 Oct 2023, at 21:59, Andrew Cooper wrote:
>>
>> On 25/10/2023 8:29 pm, Edwin Török wrote:
>>> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
>>> index 483b5e4f70..b3cd851d9d 100644
>>> --- a/xen/arch/x86/msr.c
>>> +++ b/xen/arch/x86/msr.c
>>>
On Thu, 26 Oct 2023, Jan Beulich wrote:
> On 26.10.2023 03:16, Stefano Stabellini wrote:
> > On Wed, 25 Oct 2023, Jan Beulich wrote:
> >> On 25.10.2023 03:15, Stefano Stabellini wrote:
> >>> And if we can find a clear general comment about the usage of leading
> >>> underscores in Xen I am happy to
On Thu, 26 Oct 2023, Jan Beulich wrote:
> On 25.10.2023 23:12, Stefano Stabellini wrote:
> > On Wed, 25 Oct 2023, Julien Grall wrote:
> >> On 25/10/2023 17:01, Jan Beulich wrote:
> >>> On 25.10.2023 17:58, Julien Grall wrote:
> On 25/10/2023 09:18, Jan Beulich wrote:
> > On 24.10.2023 21:5
On Thu, 26 Oct 2023, Nicola Vetrini wrote:
> On 26/10/2023 00:36, Stefano Stabellini wrote:
> > On Wed, 25 Oct 2023, Nicola Vetrini wrote:
> > > On 24/10/2023 21:50, Stefano Stabellini wrote:
> > > > On Tue, 24 Oct 2023, Nicola Vetrini wrote:
> > > > > On 24/10/2023 10:14, Jan Beulich wrote:
> > >
1 - 100 of 109 matches
Mail list logo
