flight 181472 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 180691
build-arm64
flight 181473 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181473/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
flight 181462 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181462/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-armhf-armhf-xl
flight 181470 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 5
On Thu, Jun 15, 2023 at 12:57 AM Hugh Dickins wrote:
>
> On Mon, 12 Jun 2023, Vishal Moola (Oracle) wrote:
>
> > Currently, page table information is stored within struct page. As part
> > of simplifying struct page, create struct ptdesc for page table
> > information.
> >
> > Signed-off-by:
flight 181463 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181463/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 180691
build-arm64
flight 181460 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181460/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd broken
Tests which did not
On 6/16/23 3:27 PM, Andrew Cooper wrote:
> Sorry, I also meant to ask. How prevalent is Big Endian in practice in
> the Power world?
Modern systems support operating in either endianness, but historically
most operating systems targeted Big Endian-only, and some older systems
didn't support
On Fri, 16 Jun 2023, Nicola Vetrini wrote:
> On 16/06/23 09:19, Jan Beulich wrote:
> > On 15.06.2023 18:39, nicola wrote:
> > > while investigating possible patches regarding Mandatory Rule 9.1, I
> > > found the following pattern, that is likely to results in a lot possible
> > > positives from
Hi,
On 15/06/2023 22:52, Jiatong Shen wrote:
Thank you for your answer! Adding console=hvc0 indeed provides kernel
output serial console. Looking at the log message,
I found dom0 kernel failed to initialize a lot of device drivers (network
cards, raid cards, etc).
Is it related to
Hi Jan,
Sorry for the late reply.
On 26/04/2022 11:27, Jan Beulich wrote:
Let's try to avoid giving the impression that 32-bit tool stacks are as
capable as 64-bit ones.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--
Julien Grall
On Fri, 16 Jun 2023, Roberto Bagnara wrote:
> > > + * - Implicit conversion from a pointer to an incompatible pointer
> > > + - ARM64, X86_64
> > > + - Non-documented GCC extension.
> >
> > Is this related to -Wincompatible-pointer-types?
>
> In my opinion, this does not specify what
flight 181467 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181467/
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
Hi,
On 16/06/2023 21:24, Andrew Cooper wrote:
--- /dev/null
+++ b/xen/arch/ppc/ppc64/head.S
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+.section .text.header, "ax", %progbits
+
+ENTRY(start)
+/*
+ * Depending on how we were booted, the CPU could be running in
On Thu, Jun 15, 2023 at 12:57:19AM -0700, Hugh Dickins wrote:
> Probably just trivial collisions in most architectures, which either
> of us can easily adjust to the other; powerpc likely to be more awkward,
> but fairly easily resolved; s390 quite a problem.
>
> I've so far been unable to post a
On 16/06/2023 08:59, Michal Orzel wrote:
Hi Julien,
On 15/06/2023 22:32, Julien Grall wrote:
Hi Michal,
I notice you posted some comments but didn't add a Acked-by/Reviewed-by.
Can you indicate if you are happy with the patch so long your comments
are addressed?
If so, are you OK if I
Hi,
On 15/06/2023 09:05, Michal Orzel wrote:
/*
* Restrict "p2m_ipa_bits" if needed. As P2M table is always configured
* with IPA bits == PA bits, compare against "pabits".
@@ -2291,6 +2299,7 @@ void __init setup_virt_paging(void)
*/
if (
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
> diff --git a/xen/arch/ppc/ppc64/head.S b/xen/arch/ppc/ppc64/head.S
> new file mode 100644
> index 00..0b289c713a
> --- /dev/null
> +++ b/xen/arch/ppc/ppc64/head.S
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
>
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
> Add build jobs to cross-compile Xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
Acked-by: Andrew Cooper
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
> Add the build system changes required to build for ppc64le (POWER8+).
> As of now the resulting image simply boots to an infinite loop.
>
> $ make XEN_TARGET_ARCH=ppc64 -C xen openpower_defconfig
> $ make XEN_TARGET_ARCH=ppc64 SUBSYSTEMS=xen -C xen
On Fri, 16 Jun 2023, Luca Fancellu wrote:
> > On 15 Jun 2023, at 22:27, Stefano Stabellini wrote:
> >
> > From: Stefano Stabellini
> >
> > Also add a comment at the top of the file to say rules.rst could be
> > changed.
> >
> > Signed-off-by: Stefano Stabellini
>
> Hi Stefano,
>
>
On 6/16/23 2:49 PM, Andrew Cooper wrote:
> On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
>> Add a container for cross-compiling xen for ppc64le.
>>
>> Signed-off-by: Shawn Anastasio
>> Acked-by: Andrew Cooper
> Just to say that I already committed this patch, when rebuilding the
> container. We
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
> Add a container for cross-compiling xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
> Acked-by: Andrew Cooper
Just to say that I already committed this patch, when rebuilding the
container. We likely raced given the time you posted the
On 15/06/2023 4:31 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 406445a358..fa97d4 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -307,6 +307,22 @@ config MEM_SHARING
> bool "Xen memory sharing support
On 15/06/2023 4:31 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 09bebf8635..ce62eae6f3 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -142,8 +142,8 @@ efi_platform:
>
> .section .init.text, "ax",
On Fri, 16 Jun 2023, Shawn Anastasio wrote:
> Add build jobs to cross-compile Xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
Acked-by: Stefano Stabellini
> ---
> automation/gitlab-ci/build.yaml | 60 +
> 1 file changed, 60 insertions(+)
>
> diff --git
On Fri, 16 Jun 2023, Shawn Anastasio wrote:
> Add a container for cross-compiling xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
> Acked-by: Andrew Cooper
Acked-by: Stefano Stabellini
> ---
> .../build/debian/bullseye-ppc64le.dockerfile | 28 +++
>
The asm forming early error handling is a mix of local and non-local symbols,
and has some pointless comments. Drop the "# Error message" comments,
tweaking the style on modified lines, and make the symbols local.
However, leave behind one real symbol so this logic disassembles nicely
without
Signed-off-by: Shawn Anastasio
---
MAINTAINERS | 4
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1bb7a6a839..25139fe4a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -460,6 +460,10 @@ X: xen/arch/x86/acpi/lib.c
F: xen/drivers/cpufreq/
F:
Add a container for cross-compiling xen for ppc64le.
Signed-off-by: Shawn Anastasio
Acked-by: Andrew Cooper
---
.../build/debian/bullseye-ppc64le.dockerfile | 28 +++
automation/scripts/containerize | 1 +
2 files changed, 29 insertions(+)
create mode 100644
Add the build system changes required to build for ppc64le (POWER8+).
As of now the resulting image simply boots to an infinite loop.
$ make XEN_TARGET_ARCH=ppc64 -C xen openpower_defconfig
$ make XEN_TARGET_ARCH=ppc64 SUBSYSTEMS=xen -C xen build
This port targets POWER8+ CPUs running in Little
Hello all,
This patch series adds support for building a minimal image
for Power ISA 2.07B+ (POWER8+) systems. In addition to a patch adding
support to the build system and a simple infinite loop at the
entrypoint, patches to add ppc64le support to the CI as well as a
MAINTAINERS update are
Add build jobs to cross-compile Xen for ppc64le.
Signed-off-by: Shawn Anastasio
---
automation/gitlab-ci/build.yaml | 60 +
1 file changed, 60 insertions(+)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index
flight 181466 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181466/
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 Thu Jun 15, 2023 at 1:47 AM CDT, Jan Beulich wrote:
> On 14.06.2023 18:36, Shawn Anastasio wrote:
> > On Wed Jun 14, 2023 at 10:51 AM CDT, Jan Beulich wrote:
> >> On 13.06.2023 16:50, Shawn Anastasio wrote:
> >>> +DECL_SECTION(.bss) { /* BSS */
> >>> +__bss_start
On Tue, Jun 13, 2023 at 10:32:26AM +, Volodymyr Babchuk wrote:
> From: Oleksandr Andrushchenko
>
> Introduce a per-domain read/write lock to check whether vpci is present,
> so we are sure there are no accesses to the contents of the vpci struct
> if not. This lock can be used (and in a few
On 16/06/2023 4:37 pm, Olaf Hering wrote:
> Fri, 16 Jun 2023 15:22:24 +0100 George Dunlap :
>
>> I agree; the clear implication is that with smt=0, you might have
>> num_online_cpus() return 4, but cpuids that look like {1, 3, 5, 7}; so you
>> need the trace buffer array to be of size 8.
> I see.
On 16/06/23 01:26, Stefano Stabellini wrote:
On Thu, 15 Jun 2023, Roberto Bagnara wrote:
This document specifies the C language dialect used by Xen and
the assumptions Xen makes on the translation toolchain.
Signed-off-by: Roberto Bagnara
Thanks Roberto for the amazing work of research and
Fri, 16 Jun 2023 15:22:24 +0100 George Dunlap :
> I agree; the clear implication is that with smt=0, you might have
> num_online_cpus() return 4, but cpuids that look like {1, 3, 5, 7}; so you
> need the trace buffer array to be of size 8.
I see. Apparently some remapping is required to map a
On 13/06/2023 3:49 pm, Shawn Anastasio wrote:
> Add a container for cross-compiling xen for ppc64le.
>
> Signed-off-by: Shawn Anastasio
Acked-by: Andrew Cooper
I've built and deployed this container properly, replacing the prototype
from earlier.
On 16/06/23 12:03, Jan Beulich wrote:
On 16.06.2023 09:45, Roberto Bagnara wrote:
On 16/06/23 08:53, Jan Beulich wrote:
On 16.06.2023 01:26, Stefano Stabellini wrote:
+ * - Unspecified escape sequence is encountered in a character constant or a
string literal token
+ - X86_64
+ -
On Wed, Jun 14, 2023 at 03:57:11PM -0400, Jason Andryuk wrote:
> Hi, Roger,
>
> On Mon, Nov 21, 2022 at 10:04 AM Roger Pau Monné wrote:
> >
> > On Mon, Nov 21, 2022 at 03:10:36PM +0100, Jan Beulich wrote:
> > > On 21.11.2022 11:21, Roger Pau Monne wrote:
> > > > ---
On Fri, Jun 16, 2023 at 12:52 PM Jan Beulich wrote:
> On 16.06.2023 13:47, Olaf Hering wrote:
> > Wed, 31 May 2023 11:05:52 +0200 Jan Beulich :
> >
> >> As said before, num_online_cpus() will under-report for the purpose
> >> here, as CPUs may have been brought offline, and may be brought online
On Thu, Jun 15, 2023 at 04:56:22PM +0200, Jan Beulich wrote:
> For an approach like that used in "x86: detect PIT aliasing on ports
> other than 0x4[0-3]" [1] to work, channel 2 may not (appear to) continue
> counting when "gate" is low. Record the time when "gate" goes low, and
> adjust
The current implementation in libxl_cpuid_parse_config() requires
keeping a list of cpuid feature bits that should be mostly in sync
with the contents of cpufeatureset.h.
Avoid such duplication by using the automatically generated list of
cpuid features in INIT_FEATURE_NAMES in order to map
Introduce support for handling MSR features in
libxl_cpuid_parse_config(). The MSR policies are added to the
libxl_cpuid_policy like the CPUID one, which gets passed to
xc_cpuid_apply_policy().
This allows existing users of libxl to provide MSR related features as
key=value pairs to
Like it's done with CPUID, introduce support for passing MSR values to
xc_cpuid_apply_policy(). The chosen format for expressing MSR policy
data matches the current one used for CPUID. Note that existing
callers of xc_cpuid_apply_policy() can pass NULL as the value for the
newly introduced 'msr'
Move the CPUID value parsers out of libxl_cpuid_parse_config() into a
newly created cpuid_add() local helper. This is in preparation for
also adding MSR feature parsing support.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/libs/light/libxl_cpuid.c | 120
Add a new array field to libxl_cpuid_policy in order to store the MSR
policies.
Note that libxl_cpuid_policy_list_{copy,length,parse_json,gen_json}
are not adjusted to deal with the new MSR array now part of
libxl_cpuid_policy_list.
Adding the MSR data in the libxl_cpuid_policy_list type is done
On 16/06/2023 1:12 pm, Jan Beulich wrote:
> On 15.06.2023 20:17, Andrew Cooper wrote:
>> On 15/06/2023 1:13 pm, Jan Beulich wrote:
>>> On 15.06.2023 12:41, Andrew Cooper wrote:
On 15/06/2023 9:30 am, Jan Beulich wrote:
> On 14.06.2023 20:12, Andrew Cooper wrote:
>> On 13/06/2023 10:59
Currently libxl_cpuid_policy_list is an opaque type to the users of
libxl, and internally it's an array of xc_xend_cpuid objects.
Change the type to instead be a structure that contains one array for
CPUID policies, in preparation for it also holding another array for
MSR policies.
Rename xc_cpuid_xend_policy to xc_cpu_policy_apply_cpuid and make it
public. Modify the function internally to use the new xc_cpu_policy_*
set of functions. Also don't apply the passed policy to a domain
directly, and instead modify the provided xc_cpu_policy_t. The caller
will be responsible of
Further changes to the function will require a host policy, hence
switch usages now in order to avoid having both a host featureset and
a host policy in the same context.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/libs/guest/xg_cpuid_x86.c | 27
Introduce an interface that returns a specific MSR entry from a cpu
policy in xen_msr_entry_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Use such helper in order to replace the code in
x86_msr_copy_from_buffer. Note the introduced helper should not be
directly called and instead x86_msr_get_entry should be used that will
properly deal with const and non-const inputs.
Note this requires making the raw fields uint64_t so that it can
Introduce an interface that returns a specific leaf/subleaf from a cpu
policy in xen_cpuid_leaf_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Introduce a local xc_cpu_policy_t and use it to simplify some of the
logic in the function:
* Populate the introduced xc_cpu_policy_t with the current domain
policy, which will already be the default for the given domain
type. This avoids fetching and processing any default policy.
*
Introduce a helper based on the current Xen guest_cpuid code in order
to fetch a cpuid leaf from a policy. The newly introduced function in
cpuid.c should not be directly called and instead the provided
x86_cpuid_get_leaf macro should be used that will properly deal with
const and non-const
Hello,
The following series adds support for handling guest MSR features as
defined in arch-x86/cpufeatureset.h.
The end result is the user being able to use such features with the
xl.cfg(5) cpuid option. This also involves adding support to all the
underlying layers, so both libxl and libxc
The single caller of next_record already checked for
tb_init_done. The functions are called with t_lock
held. The call stack look like this:
__trace_var
tb_init_done?
insert_wrap_record
insert_lost_records
__insert_record
next_record
tb_init_done?
Signed-off-by: Olaf
On Mon, Jun 12, 2023 at 02:03:53PM -0700, Vishal Moola (Oracle) wrote:
> Currently, page table information is stored within struct page. As part
> of simplifying struct page, create struct ptdesc for page table
> information.
>
> Signed-off-by: Vishal Moola (Oracle)
> ---
>
On 16.06.2023 14:33, Jan Beulich wrote:
> Only %LV should continue on to S handling; avoid emitting a stray 'l'
> (typically) in suffix-always mode.
Oops, I'm sorry, confusion of mailing lists.
Jan
Only %LV should continue on to S handling; avoid emitting a stray 'l'
(typically) in suffix-always mode.
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -11067,19 +11067,20 @@ putop (instr_info *ins, const char *in_t
*ins->obufp++ = ' ';
break;
On 15.06.2023 20:17, Andrew Cooper wrote:
> On 15/06/2023 1:13 pm, Jan Beulich wrote:
>> On 15.06.2023 12:41, Andrew Cooper wrote:
>>> On 15/06/2023 9:30 am, Jan Beulich wrote:
On 14.06.2023 20:12, Andrew Cooper wrote:
> On 13/06/2023 10:59 am, Jan Beulich wrote:
>> On 12.06.2023
On 16.06.2023 13:47, Olaf Hering wrote:
> Wed, 31 May 2023 11:05:52 +0200 Jan Beulich :
>
>> As said before, num_online_cpus() will under-report for the purpose
>> here, as CPUs may have been brought offline, and may be brought online
>> again later (independent of the use of "maxcpus=").
>
> It
Wed, 31 May 2023 11:05:52 +0200 Jan Beulich :
> As said before, num_online_cpus() will under-report for the purpose
> here, as CPUs may have been brought offline, and may be brought online
> again later (independent of the use of "maxcpus=").
It turned out, commit
On 16.06.2023 12:29, Anthony PERARD wrote:
> Update to OVMF's latest stable tag.
>
> This is been prompt by trying to build Xen on Debian Bookworm,
> where edk2-stable202108 doesn't build. Also, it's been too long since
> the last update.
Hmm, yes, almost 2 years.
> Signed-off-by: Anthony
On 16.06.2023 12:22, Olaf Hering wrote:
> Fri, 16 Jun 2023 12:07:20 +0200 Jan Beulich :
>
>> ... you're removing the line that's actually verifying this is the case.
>
> Yeah, because it disappeared. I think the other approach is to teach
> the python tool about __attribute__(()).
>
> Let me
flight 181456 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181456/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 180278
build-armhf-pvops
Update to OVMF's latest stable tag.
This is been prompt by trying to build Xen on Debian Bookworm,
where edk2-stable202108 doesn't build. Also, it's been too long since
the last update.
Signed-off-by: Anthony PERARD
---
I've tested it in osstest, so the update should be fine:
Fri, 16 Jun 2023 12:07:20 +0200 Jan Beulich :
> ... you're removing the line that's actually verifying this is the case.
Yeah, because it disappeared. I think the other approach is to teach
the python tool about __attribute__(()).
Let me know which way is preferred.
Olaf
pgpghOyGFRHEO.pgp
On 16.06.2023 11:51, Olaf Hering wrote:
> Wed, 14 Jun 2023 11:49:35 +0200 Jan Beulich :
>
>> However, if you're after adding packed attributes, and if you're
>> meaning to only communicate between Xen and the tool stack, then
>> the requirement above doesn't exist. Yet then I would also wonder
>>
On 16.06.2023 09:45, Roberto Bagnara wrote:
> On 16/06/23 08:53, Jan Beulich wrote:
>> On 16.06.2023 01:26, Stefano Stabellini wrote:
>> Another is that it's
>> hard to tell how to convince oneself of this being an exhaustive
>> enumeration. One extension we use extensively yet iirc is missing
Wed, 14 Jun 2023 11:49:35 +0200 Jan Beulich :
> However, if you're after adding packed attributes, and if you're
> meaning to only communicate between Xen and the tool stack, then
> the requirement above doesn't exist. Yet then I would also wonder
> whether you need any compat translation in the
On 16/06/23 09:19, Jan Beulich wrote:
On 15.06.2023 18:39, nicola wrote:
while investigating possible patches regarding Mandatory Rule 9.1, I
found the following pattern, that is likely to results in a lot possible
positives from many (all) static analysis tools for this rule.
This is the
Hi Julien,
On 15/06/2023 22:32, Julien Grall wrote:
>
>
> Hi Michal,
>
> I notice you posted some comments but didn't add a Acked-by/Reviewed-by.
> Can you indicate if you are happy with the patch so long your comments
> are addressed?
>
> If so, are you OK if I deal with them on commit?
I
On 16/06/23 08:53, Jan Beulich wrote:
On 16.06.2023 01:26, Stefano Stabellini wrote:
On Thu, 15 Jun 2023, Roberto Bagnara wrote:
I have a few comments below, mostly to clarify the description of some
of the less documented GCC extensions, for the purpose of having all
community members be able
On 15.06.2023 18:39, nicola wrote:
> while investigating possible patches regarding Mandatory Rule 9.1, I
> found the following pattern, that is likely to results in a lot possible
> positives from many (all) static analysis tools for this rule.
>
> This is the current status (taken from
> On 15 Jun 2023, at 22:27, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Also add a comment at the top of the file to say rules.rst could be
> changed.
>
> Signed-off-by: Stefano Stabellini
Hi Stefano,
Reviewed-by: Luca Fancellu
While I was testing the patch with our
Hi Stefano,
> On 15 Jun 2023, at 23:27, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> Also add a comment at the top of the file to say rules.rst could be
> changed.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
>
> ---
> Changes in v2:
Hi Stefano,
> On 15 Jun 2023, at 23:19, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> For Dir 1.1, a document describing all implementation-defined behaviour
> (i.e. gcc-specific behavior) will be added to docs/misra, also including
> implementation-specific (gcc-specific)
On 16.06.2023 01:26, Stefano Stabellini wrote:
> On Thu, 15 Jun 2023, Roberto Bagnara wrote:
> I have a few comments below, mostly to clarify the description of some
> of the less documented GCC extensions, for the purpose of having all
> community members be able to understand what they can and
First of all move PV-only ELF notes inside the XEN_PV conditional; note
that
- HV_START_LOW is dropped altogether, as it was meaningful for 32-bit PV
only,
- the 32-bit instance of VIRT_BASE is dropped, as it would be dead code
once inside the conditional,
- while PADDR_OFFSET is not exactly
83 matches
Mail list logo
