flight 183544 linux-linus real [real]
flight 183550 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183544/
http://logs.test-lab.xenproject.org/osstest/logs/183550/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
flight 183548 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183548/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7e08d17a4a535a7abfa58a0606ca1a0e7f5862ad
baseline version:
ovmf ca32f75fc6ba4a41a65b5
On 26.10.2023 18:55, Xenia Ragiadakou wrote:
>
>
> 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:
>> O
On 26.10.2023 19:38, Edwin Torok wrote:
>> 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 $<,
flight 183546 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183546/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ca32f75fc6ba4a41a65b5ea83eaa21d209bae570
baseline version:
ovmf f945b72331d7e9eed7f84
flight 183545 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183545/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f945b72331d7e9eed7f84c71052f198377ac3950
baseline version:
ovmf 74c687cc2f2f29d3bdd45
On Thu, 26 Oct 2023, Julien Grall wrote:
> 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,
On Thu, 26 Oct 2023, Federico Serafini wrote:
> Make function definitions and declarations consistent.
> No functional change.
>
> Signed-off-by: Federico Serafini
Great job at taking the opportunity to improve the code style with this
patch. Only one comment below.
> ---
> xen/arch/x86/x86_6
+Roger
See below
On Thu, 26 Oct 2023, Julien Grall wrote:
> 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 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:
> > >
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, 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 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
>>>
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é
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
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
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
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
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 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
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 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 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 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
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 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
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 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 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 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 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, 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 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 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 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 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 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 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
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/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
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 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
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
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
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
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
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 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 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 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/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: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 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 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,
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/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
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
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.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
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
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 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
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 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
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 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
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 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.
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 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
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
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
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
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
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 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 (
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
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
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
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
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
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
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
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 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
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
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
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, 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,
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: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
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/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
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
> >>> +-
> >>
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
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
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-
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 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 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
1 - 100 of 109 matches
Mail list logo
