On 14.11.2023 23:37, Stefano Stabellini wrote:
> [PATCH v2] docs/misra: add R11.1 R11.2 R11.3 R11.6
>
> Add MISRA C Rules 11.1, 11.2, 11.3, 11.6 as discussed.
>
> Explicitly add in the notes that conversions to integer types are
> permitted if the destination type has enough bits to hold the
On 14.11.23 19:16, Oleksandr Tyshchenko wrote:
On 16.10.23 09:28, Juergen Gross wrote:
Hello Juergen
Instead of the IRQ number user the struct irq_info pointer as parameter
in the internal pirq related functions. This allows to drop some calls
of info_for_irq().
Signed-off-by: Juergen
flight 183758 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183758/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3db76e6476e493d3cda45b81bba99a645180cf35
baseline version:
ovmf
On 14.11.23 21:57, Julien Grall wrote:
Hi Juergen,
On 14/11/2023 09:20, Juergen Gross wrote:
On 14.11.23 10:05, Julien Grall wrote:
Hi,
On 14/11/2023 06:45, Juergen Gross wrote:
On 13.11.23 23:40, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
With 9pfs being
On 14.11.23 21:53, Julien Grall wrote:
Hi Juergen,
On 14/11/2023 09:26, Juergen Gross wrote:
On 14.11.23 10:10, Julien Grall wrote:
Hi Juergen,
On 14/11/2023 06:45, Juergen Gross wrote:
On 13.11.23 23:25, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
Add some
On 14.11.23 21:48, Julien Grall wrote:
Hi,
On 14/11/2023 09:12, Juergen Gross wrote:
On 14.11.23 09:56, Julien Grall wrote:
Hi,
On 14/11/2023 06:33, Juergen Gross wrote:
On 13.11.23 23:04, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
When running as stubdom,
flight 183753 xen-4.17-testing real [real]
flight 183757 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183753/
http://logs.test-lab.xenproject.org/osstest/logs/183757/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Pipeline #1072738507 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: stable-4.16 ( https://gitlab.com/xen-project/xen/-/commits/stable-4.16 )
Commit: 4dfe9517 (
https://gitlab.com/xen-project/xen/-/commit/4dfe95177b948d1f3ed27a801f603ed7f1bc36e8
)
Commit Message:
Hi David,
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Fri, 2023-11-10 at 20:42 +, Volodymyr Babchuk wrote:
>> From: Oleksandr Tyshchenko
>>
>> Instead of forcing the owner to domid 0, use XS_PRESERVE_OWNER to save
>> the previous owner of the directory.
>>
>
> You're
flight 183752 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183752/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 183350
I hope that the informations below are correct :
- the imagebuilder config file :
MEMORY_START="0x0"
MEMORY_END="0x8000"
LOAD_CMD="ext2load mmc 1:3"
BOOT_CMD="bootm"
DEVICE_TREE="exynos5250-snow.dtb"
XEN="xen-4.17-armhf"
XEN_CMD="console=dtuart dtuart=serial0 dom0_mem=1152M dom0_max_vcpus=2
Hi Mario,
I think we misunderstood each other :-)
MEMORY_START-MEMORY_END is not supposed to be computed: it is supposed
to come from the memory node in device tree tree (/memory) of the
platform. The idea is that you should not have to do any computations,
but only reuse the same address range
For Rule 16.2 deviate xen/arch/x86/x86_emulate.
For Rule 16.2 allow control flow statements and terminals. For the rest,
request the "fallthrough" psedo-keyword to be used.
Signed-off-by: Stefano Stabellini
---
docs/misra/rules.rst | 14 ++
1 file changed, 14 insertions(+)
diff
---> uboot-script-gen assumes that the memory range specified by
MEMORY_START-MEMORY_END is valid and correct.
Actually Chuck chose 0 as MEMORY_START and 0x80 as MEMORY_END and these
are stable values,they don't change. If you ask me to calculate those
values,it means that we need to compute
Add 21.1 and 21.2, with a longer comment to explain how strategy with
leading underscores and why we think we are safe today.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- remove R14.4
- update note section of 21.1
---
docs/misra/rules.rst | 22 ++
1 file changed,
Hi Mario,
It is difficult to know how to change uboot-script-gen if we don't know
why it is currently going wrong.
uboot-script-gen assumes that the memory range specified by
MEMORY_START-MEMORY_END is valid and correct.
So if you specified a valid and correct memory range in your config file
On Tue, 14 Nov 2023, Jan Beulich wrote:
> On 14.11.2023 00:44, Stefano Stabellini wrote:
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -383,6 +383,38 @@ maintainers if you want to suggest a change.
> >
> > CFLAGS="-Warith-conversion -Wno-error=arith-conversion"
On Tue, 14 Nov 2023, Nicola Vetrini wrote:
> On 2023-11-14 08:19, Jan Beulich wrote:
> > On 14.11.2023 00:58, Stefano Stabellini wrote:
> > > On Mon, 13 Nov 2023, Jan Beulich wrote:
> > > > On 19.10.2023 09:55, Nicola Vetrini wrote:
> > > > > The constant 0 is used instead of NULL in
On Tue, 14 Nov 2023, Federico Serafini wrote:
> Update ECLAIR configuration to take into account the search
> procedure adopted by Unix linkers.
> Update deviations.rst accordingly and tag Rule 8.6 as "clean".
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Tue, 14 Nov 2023, Michal Orzel wrote:
> At the moment, in order to boot 32-bit images, we need to set BOOT_CMD
> to 'bootm' which results in adding a u-boot header on top of an image.
> Add 'bootz' to a list of supported boot commands, so that we can skip
> this extra step. In most cases,
On Tue, 14 Nov 2023, Robin Murphy wrote:
> On 11/11/2023 6:45 pm, Chuck Zmudzinski wrote:
> > Enabling the new option, ARM_DMA_USE_IOMMU_XEN, fixes this error when
> > attaching the Exynos mixer in Linux dom0 on Xen on the Chromebook Snow
> > (and probably on other devices that use the Exynos
flight 183751 xen-4.15-testing real [real]
flight 183756 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183751/
http://logs.test-lab.xenproject.org/osstest/logs/183756/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Pipeline #1072669753 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: stable-4.15 ( https://gitlab.com/xen-project/xen/-/commits/stable-4.15 )
Commit: b918c4cd (
https://gitlab.com/xen-project/xen/-/commit/b918c4cdc7ab2c1c9e9a9b54fa9d9c595913e028
)
Commit Message:
Hi Nicola,
On 14/11/2023 15:36, Nicola Vetrini wrote:
Additional guidance on the formatting of the document for ECLAIR
is supplied.
Signed-off-by: Nicola Vetrini
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi,
On 14/11/2023 15:36, Nicola Vetrini wrote:
To be able to check for the existence of the necessary subsections in
the documentation for MISRA C:2012 Dir 4.1, ECLAIR needs to have a source
file that is built.
This file is generated from 'C-runtime-failures.rst' in docs/misra
and the
On 13/11/2023 12:43 pm, Juergen Gross wrote:
> The "-N" (do not daemonize) command line option is of questionable use:
> its sole purpose seems to be to aid debugging of xenstored by making it
> easier to start xenstored under gdb, or to see any debug messages
> easily.
>
> Debug messages can as
On Tue, 2023-11-14 at 21:32 +, Volodymyr Babchuk wrote:
>
> > I think we want to kill the xen_backend_set_device() function and
> > instead set the backend as a property of the XenDevice *before*
> > realizing it.
>
> Not sure that I got this. Right now device is property of
>
On Tue, 14 Nov 2023, Nicola Vetrini wrote:
> Additional guidance on the formatting of the document for ECLAIR
> is supplied.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Tue, 14 Nov 2023, Nicola Vetrini wrote:
> To be able to check for the existence of the necessary subsections in
> the documentation for MISRA C:2012 Dir 4.1, ECLAIR needs to have a source
> file that is built.
>
> This file is generated from 'C-runtime-failures.rst' in docs/misra
> and the
On Tue, 14 Nov 2023, Roger Pau Monné wrote:
> On Tue, Nov 14, 2023 at 03:00:17PM +, Anthony PERARD wrote:
> > On Tue, Nov 14, 2023 at 10:01:06AM +0100, Roger Pau Monné wrote:
> > > On Mon, Nov 13, 2023 at 04:10:24PM -0800, Stefano Stabellini wrote:
> > > > On Mon, 13 Nov 2023, Roger Pau Monne
Hi Juergen,
On 13/11/2023 12:43, Juergen Gross wrote:
The "-R" (no recovery) command line option enables to omit fixing the
node store in case of detected inconsistencies.
This might have been of interest in the past, when the node data base
was kept in a file, but now the usability of this
Hi David,
David Woodhouse writes:
> On 11 November 2023 16:51:22 GMT-05:00, Andrew Cooper
> wrote:
>>On 11/11/2023 8:18 pm, David Woodhouse wrote:
>>> On 11 November 2023 08:43:40 GMT-05:00, Andrew Cooper
>>> wrote:
Furthermore, the control domain doesn't always have the domid of 0.
On Tue, 2023-11-14 at 10:44 -0500, David Woodhouse wrote:
>
> I believe that if you push your branch to a gitlab tree with the
> right CI variables defined, it'll run all the CI? And I *hope* it
> fails with this patch. It's precisely the kind of thing I was
> *intending* to catch with the
Hi,
On 13/11/2023 12:43, Juergen Gross wrote:
The "-N" (do not daemonize) command line option is of questionable use:
its sole purpose seems to be to aid debugging of xenstored by making it
easier to start xenstored under gdb, or to see any debug messages
easily.
Debug messages can as well be
Hi Juergen,
On 13/11/2023 12:43, Juergen Gross wrote:
The "-P" command line option just results in printing the PID of the
xenstored daemon to stdout before stdout is being closed. The same
information can be retrieved from the PID file via the "-F" option.
I looked at the git history to
Hi Juergen,
On 13/11/2023 12:43, Juergen Gross wrote:
The "-V" (verbose) command line option is nearly completely redundant
with "io" tracing. Just the time of the printed data is a little bit
different, while the tracing is more informative.
The current position of trace_io() is a bit
Hi Juergen,
On 14/11/2023 09:20, Juergen Gross wrote:
On 14.11.23 10:05, Julien Grall wrote:
Hi,
On 14/11/2023 06:45, Juergen Gross wrote:
On 13.11.23 23:40, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
With 9pfs being fully available in Xenstore-stubdom now,
Hi Juergen,
On 14/11/2023 09:26, Juergen Gross wrote:
On 14.11.23 10:10, Julien Grall wrote:
Hi Juergen,
On 14/11/2023 06:45, Juergen Gross wrote:
On 13.11.23 23:25, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
Add some helpers for handling filenames which
Hi,
On 14/11/2023 09:12, Juergen Gross wrote:
On 14.11.23 09:56, Julien Grall wrote:
Hi,
On 14/11/2023 06:33, Juergen Gross wrote:
On 13.11.23 23:04, Julien Grall wrote:
Hi Juergen,
On 10/11/2023 16:08, Juergen Gross wrote:
When running as stubdom, map the stubdom's Xenstore ring page in
Pipeline #1072370735 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging-4.17 (
https://gitlab.com/xen-project/xen/-/commits/staging-4.17 )
Commit: 28f44b60 (
https://gitlab.com/xen-project/xen/-/commit/28f44b603fd86c233726bdc2a11b6325f102471a
)
Commit Message:
Hi Krystian,
Thanks you for sending the series! Just posting some extra data point.
On 14/11/2023 17:49, Krystian Hebel wrote:
Patch series available on this branch:
https://github.com/TrenchBoot/xen/tree/smp_cleanup_upstreaming
This series makes AP bring-up parallel on x86. This reduces
Please ignore this series and review/reply to the other one
([XEN PATCH 0/9] x86: parallelize AP bring-up during boot) instead.
`git send-email` did what I asked it to do instead of what I wanted,
so I accidentally sent WIP version of patches.
Sorry for the noise.
--
Krystian Hebel
Firmware
On 14.11.23 10:35, Juergen Gross wrote:
Hello Juergen
> On 14.11.23 09:20, Oleksandr Tyshchenko wrote:
>>
>>
>> On 16.10.23 09:28, Juergen Gross wrote:
>>
>>
>> Hello Juergen
>>
>>> Instead of having a common function for allocating a single IRQ or a
>>> consecutive number of IRQs, split up
On 16.10.23 09:28, Juergen Gross wrote:
Hello Juergen
> Instead of the IRQ number user the struct irq_info pointer as parameter
> in the internal pirq related functions. This allows to drop some calls
> of info_for_irq().
>
> Signed-off-by: Juergen Gross
Looks good, so
Reviewed-by:
Multiple delays are required when sending IPIs and waiting for
responses. During boot, 4 such IPIs were sent per each AP. With this
change, only one set of broadcast IPIs is sent. This reduces boot time,
especially for platforms with large number of cores.
Single CPU initialization is still
This will be used for parallel AP bring-up.
CPU_STATE_INIT changed direction. It was previously set by BSP and never
consumed by AP. Now it signals that AP got through assembly part of
initialization and waits for BSP to call notifiers that set up data
structures required for further
CPU id is obtained as a side effect of searching for appropriate
stack for AP. It can be used as a parameter to start_secondary().
Coincidentally this also makes further work on making AP bring-up
code parallel easier.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 13
Multiple delays are required when sending IPIs and waiting for
responses. During boot, 4 such IPIs were sent per each AP. With this
change, only one set of broadcast IPIs is sent. This reduces boot time,
especially for platforms with large number of cores.
Single CPU initialization is still
If multiple CPUs called machine_restart() before actual restart took
place, but after boot CPU declared itself not online, ASSERT in
on_selected_cpus() will fail. Few calls later execution would end up
in machine_restart() again, with another frame on call stack for new
exception.
To protect
It used to be called from smp_callin(), however BUG_ON() was invoked on
multiple occasions before that. It may end up calling machine_restart()
which tries to get APIC ID for CPU running this code. If BSP detected
that x2APIC is enabled, get_apic_id() will try to use it for all CPUs.
Enabling
It used to be called from smp_callin(), however BUG_ON() was invoked on
multiple occasions before that. It may end up calling machine_restart()
which tries to get APIC ID for CPU running this code. If BSP detected
that x2APIC is enabled, get_apic_id() will try to use it for all CPUs.
Enabling
Both fields held the same data.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 8 +---
xen/arch/x86/include/asm/asm_defns.h | 2 +-
xen/arch/x86/include/asm/processor.h | 2 ++
xen/arch/x86/include/asm/smp.h | 4
xen/arch/x86/numa.c
Multiple delays are required when sending IPIs and waiting for
responses. During boot, 4 such IPIs were sent per each AP. With this
change, only one set of broadcast IPIs is sent. This reduces boot time,
especially for platforms with large number of cores.
Single CPU initialization is still
Both fields held the same data.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 8 +---
xen/arch/x86/include/asm/asm_defns.h | 2 +-
xen/arch/x86/include/asm/processor.h | 2 ++
xen/arch/x86/include/asm/smp.h | 4
xen/arch/x86/numa.c
This will be used for parallel AP bring-up.
CPU_STATE_INIT changed direction. It was previously set by BSP and never
consumed by AP. Now it signals that AP got through assembly part of
initialization and waits for BSP to call notifiers that set up data
structures required for further
This is done in preparation to move data from x86_cpu_to_apicid[]
elsewhere.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/acpi/cpu_idle.c | 4 ++--
xen/arch/x86/acpi/lib.c | 2 +-
xen/arch/x86/apic.c | 2 +-
xen/arch/x86/cpu/mwait-idle.c | 4 ++--
This is made as first step of making parallel AP bring-up possible. It
should be enough for pre-C code.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/trampoline.S | 20
xen/arch/x86/boot/x86_64.S | 28 +++-
xen/arch/x86/setup.c |
Patch series available on this branch:
https://github.com/TrenchBoot/xen/tree/smp_cleanup_upstreaming
This series makes AP bring-up parallel on x86. This reduces number of
IPIs (and more importantly, delays between them) required to start all
logical processors significantly.
In order to make it
CPU id is obtained as a side effect of searching for appropriate
stack for AP. It can be used as a parameter to start_secondary().
Coincidentally this also makes further work on making AP bring-up
code parallel easier.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 13
This location is easier to access from assembly. Having it close to
other data required during initialization has also positive (although
rather small) impact on prefetching data from RAM.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S| 5 ++---
If multiple CPUs called machine_restart() before actual restart took
place, but after boot CPU declared itself not online, ASSERT in
on_selected_cpus() will fail. Few calls later execution would end up
in machine_restart() again, with another frame on call stack for new
exception.
To protect
This is done in preparation to move data from x86_cpu_to_apicid[]
elsewhere.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/acpi/cpu_idle.c | 4 ++--
xen/arch/x86/acpi/lib.c | 2 +-
xen/arch/x86/apic.c | 2 +-
xen/arch/x86/cpu/mwait-idle.c | 4 ++--
This will be used for parallel AP bring-up.
CPU_STATE_INIT changed direction. It was previously set by BSP and never
consumed by AP. Now it signals that AP got through assembly part of
initialization and waits for BSP to call notifiers that set up data
structures required for further
This is made as first step of making parallel AP bring-up possible. It
should be enough for pre-C code.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/trampoline.S | 20
xen/arch/x86/boot/x86_64.S | 28 +++-
xen/arch/x86/setup.c |
From: Andrew Cooper
Before speculation defences, some paths in Xen could genuinely get away with
being IRQs-on at entry. But XPTI invalidated this property on most paths, and
attempting to maintain it on the remaining paths was a mistake.
Fast forward, and DO_SPEC_CTRL_COND_IBPB (protection
This location is easier to access from assembly. Having it close to
other data required during initialization has also positive (although
rather small) impact on prefetching data from RAM.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S| 5 ++---
On 14.11.2023 16:16, Oleksii Kurochko wrote:
> Ifdef-ing inclusion of allows to avoid
> generation of empty for cases when
> CONFIG_GRANT_TABLE is not enabled.
>
> The following changes were done for Arm:
> should be included directly because it contains
> gnttab_dom0_frames() macros which is
On 14.11.2023 16:13, Oleksii Kurochko wrote:
> ifdefing inclusion of in
> allows to avoid generation of empty header
> for the case when !CONFIG_MEM_ACCESS.
>
> For Arm it was explicitly added inclusion of for p2m.c
> and traps.c because they require some functions from which
> aren't
On Tue, Nov 14, 2023 at 03:00:17PM +, Anthony PERARD wrote:
> On Tue, Nov 14, 2023 at 10:01:06AM +0100, Roger Pau Monné wrote:
> > On Mon, Nov 13, 2023 at 04:10:24PM -0800, Stefano Stabellini wrote:
> > > On Mon, 13 Nov 2023, Roger Pau Monne wrote:
> > > > Pass the desired architecture of the
xen_arch_set_memory() is not arch-specific anymore. Being
called once, inline it in xen_set_memory().
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/xen/xen-hvm-common.h | 3 -
hw/xen/xen-hvm-common.c | 104
2 files changed, 51 insertions(+), 56
Update ECLAIR configuration to take into account the search
procedure adopted by Unix linkers.
Update deviations.rst accordingly and tag Rule 8.6 as "clean".
Signed-off-by: Federico Serafini
---
Changes is v2:
- deviation is based on xen/lib/*;
- justification improved;
- reflected changes
Pipeline #1071977342 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging-4.17 (
https://gitlab.com/xen-project/xen/-/commits/staging-4.17 )
Commit: 0527bab0 (
https://gitlab.com/xen-project/xen/-/commit/0527bab0901b800e3f1be2e7836c5346b6e08809
)
Commit Message:
hw/i386/xen/xen-hvm-common.c content is target agnostic,
and should be common to all targets. Merge both files.
Remove the now unnecessary xen_register_framebuffer() stub.
ARM targets now inherit the common xen_memory_listener.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/xen_arm.c
xen_read_physmap() is the first function requiring
xen_physmap QLIST being initialized. Move the init
call there.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
Extract non-x86 specific code out of xen-hvm.c,
to xen-hvm-common.c. For now this new file is
only build for x86 targets.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm-common.c | 473 +++
hw/i386/xen/xen-hvm.c| 459
There can only be a single xen_memory_listener definition
in a qemu-system binary.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/xen/xen-hvm-common.h | 1 +
hw/arm/xen_arm.c| 2 +-
hw/i386/xen/xen-hvm.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
We are going to replace TARGET_PAGE_MASK by a
runtime variable. In order to reduce code duplication,
propagate TARGET_PAGE_MASK to get_physmapping() and
xen_phys_offset_to_gaddr().
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm.c | 18 ++
1 file changed, 10
In a pair of commit we are going to call xen_read_physmap()
out of hw/i386/xen/xen-hvm.c.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/xen/xen-hvm-common.h | 1 +
hw/i386/xen/xen-hvm.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git
Hi,
While looking at Xen target-specific code, I noticed some
generic code used by x86 which is not implemented for ARM.
Maybe ARM machines don't need it, I don't know. But I
wanted to see if I can get this common code target agnostic
and build it once, possibly bringing smth useful to ARM.
The
In order to build this file once for all targets, replace:
TARGET_PAGE_BITS -> qemu_target_page_bits()
TARGET_PAGE_SIZE -> qemu_target_page_size()
TARGET_PAGE_MASK -> -qemu_target_page_size()
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm.c | 62
Use TARGET_PAGE_SIZE to calculate TARGET_PAGE_ALIGN.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index f1c30d1384..8aa6a1ec3b 100644
--- a/hw/i386/xen/xen-hvm.c
flight 183750 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183750/
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
On Tue, 2023-11-14 at 16:22 +0100, Philippe Mathieu-Daudé wrote:
>
> If so, possibly few places incorrectly check 'xen_enabled()'
> instead of this 'xen_guest()'.
Sorry, I meant to respond to that one directly. I don't *think* there
are any cases of that. As I added the CONFIG_XEN_EMU support, I
On 2023-11-11 02:13, Stefano Stabellini wrote:
On Fri, 10 Nov 2023, Nicola Vetrini wrote:
Hi everyone,
I trimmed the thread a bit, to make this more readable.
> > > > > IMHO, the only viable option would be to have a configuration to
> > > > > keep
> > > > > ASSERT in production build for
> On 14 Nov 2023, at 15:59, Jan Beulich wrote:
>
> On 14.11.2023 15:59, Luca Fancellu wrote:
>>
>>
>>> On 13 Nov 2023, at 16:27, Jan Beulich wrote:
>>>
>>> On 13.11.2023 16:20, Luca Fancellu wrote:
> On 13 Nov 2023, at 11:31, Jan Beulich wrote:
> On 08.11.2023 10:53, Luca Fancellu
On 14.11.2023 15:59, Luca Fancellu wrote:
>
>
>> On 13 Nov 2023, at 16:27, Jan Beulich wrote:
>>
>> On 13.11.2023 16:20, Luca Fancellu wrote:
On 13 Nov 2023, at 11:31, Jan Beulich wrote:
On 08.11.2023 10:53, Luca Fancellu wrote:
On 14 November 2023 09:38:14 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
>xen-hvm.c calls xc_set_hvm_param() from ,
>so better compile it with Xen CPPFLAGS.
>
>Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: David Woodhouse
On 14 November 2023 09:38:12 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
>Commit eaab4d60d3 ("Introduce Xen PCI Passthrough, qdevice")
>introduced both xen_pt.[ch], but only added the license to
>xen_pt.c. Use the same license for xen_pt.h.
>
>Suggested-by: David Woodhouse
>Signed-off-by:
On 14 November 2023 09:38:06 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
>To avoid a potential global variable shadow in
>hw/i386/pc_piix.c::pc_init1(), rename Xen's
>"ram_memory" as "xen_memory".
>
>Signed-off-by: Philippe Mathieu-Daudé
Well OK, but aren't you going to be coming back later to
On 14 November 2023 10:22:23 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
>On 14/11/23 16:13, David Woodhouse wrote:
>> On 14 November 2023 09:38:02 GMT-05:00, "Philippe Mathieu-Daudé"
>> wrote:
>>> Similarly to the restriction in hw/pci/msix.c (see commit
>>> e1e4bf2252 "msix: fix
On 14/11/23 16:19, David Woodhouse wrote:
On 14 November 2023 10:13:14 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
On 14/11/23 16:08, David Woodhouse wrote:
On 14 November 2023 10:00:09 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
On 14/11/23 15:50, David Woodhouse wrote:
On 14 November
Additional guidance on the formatting of the document for ECLAIR
is supplied.
Signed-off-by: Nicola Vetrini
---
docs/misra/C-runtime-failures.rst | 8
1 file changed, 8 insertions(+)
diff --git a/docs/misra/C-runtime-failures.rst
b/docs/misra/C-runtime-failures.rst
index
This series addresses some concerns raised on patches 2 and 3 from [1].
Note that patch 1 from that series has already been applied.
Patch 1 comprises a modified version of patches 2 and 3 of the previous series.
Patch 2 is brand new, as it merely clarifies how to write such documentation.
[1]
To be able to check for the existence of the necessary subsections in
the documentation for MISRA C:2012 Dir 4.1, ECLAIR needs to have a source
file that is built.
This file is generated from 'C-runtime-failures.rst' in docs/misra
and the configuration is updated accordingly.
Signed-off-by:
On 14 November 2023 09:38:05 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
>Except imported source files, QEMU code base uses
>the QEMU_ALIGNED() macro to align its structures.
>
>Signed-off-by: Philippe Mathieu-Daudé
Can we have a BUILD_BUG_ON(sizeof==) for these please?
On 14 November 2023 09:38:03 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
>Since commit 04b0de0ee8 ("xen: factor out common functions")
>xen_hvm_inject_msi() stub is not required.
>
>Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: David Woodhouse
Hi,
On Tue, Nov 14, 2023 at 02:59:35PM +, Luca Fancellu wrote:
>
>
> > On 13 Nov 2023, at 16:27, Jan Beulich wrote:
> >
> > On 13.11.2023 16:20, Luca Fancellu wrote:
> >>> On 13 Nov 2023, at 11:31, Jan Beulich wrote:
> >>> On 08.11.2023 10:53, Luca Fancellu wrote:
> >>>
On Mon, 2023-11-13 at 17:43 +0100, Jan Beulich wrote:
> On 10.11.2023 17:30, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-generic/device.h
> > @@ -0,0 +1,140 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +#ifndef __ASM_GENERIC_DEVICE_H__
> > +#define
On 14/11/23 16:13, David Woodhouse wrote:
On 14 November 2023 09:38:02 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
Similarly to the restriction in hw/pci/msix.c (see commit
e1e4bf2252 "msix: fix msix_vector_masked"), restrict the
xen_is_pirq_msi() call in msi_is_masked() to Xen.
On 14 November 2023 10:13:14 GMT-05:00, "Philippe Mathieu-Daudé"
wrote:
>On 14/11/23 16:08, David Woodhouse wrote:
>> On 14 November 2023 10:00:09 GMT-05:00, "Philippe Mathieu-Daudé"
>> wrote:
>>> On 14/11/23 15:50, David Woodhouse wrote:
On 14 November 2023 09:37:57 GMT-05:00, "Philippe
1 - 100 of 186 matches
Mail list logo
