On 09.08.2023 01:59, Daniel P. Smith wrote:
> On 8/8/23 11:30, Jan Beulich wrote:
>> On 01.08.2023 22:20, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -907,6 +907,10 @@ static struct domain *__init create_dom0(const
>>> module_t *image,
>>>
>>>
On 08.08.2023 21:19, Shawn Anastasio wrote:
> On 8/7/23 11:13 AM, Jan Beulich wrote:
>> On 03.08.2023 01:02, Shawn Anastasio wrote:
>>> Implement atomic.h for PPC, based off of the original Xen 3.2
>>> implementation.
>>
>> Since likely that originally came from Linux, did you cross check that
>> L
On 08.08.2023 18:49, Shawn Anastasio wrote:
> On 8/7/23 10:39 AM, Jan Beulich wrote:
>> On 03.08.2023 01:02, Shawn Anastasio wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -28,6 +28,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #incl
On 08.08.2023 18:58, Daniel P. Smith wrote:
> On 8/4/23 03:49, Jan Beulich wrote:
>> On 03.08.2023 18:31, Daniel P. Smith wrote:
>>> On 8/3/23 11:56, Jan Beulich wrote:
On 03.08.2023 14:56, Daniel P. Smith wrote:
> On 8/2/23 07:01, Jan Beulich wrote:
>> On 01.08.2023 18:06, Daniel P. S
On 08.08.2023 22:15, Stefano Stabellini wrote:
> On Tue, 8 Aug 2023, Jan Beulich wrote:
>> On 04.08.2023 23:39, Stefano Stabellini wrote:
>>> Hi Tamas,
>>>
>>> May I have your ack on this change?
>>
>> I see you committed this, and there is an ack in the commit, but I can't
>> see any ack on list (
On 08.08.2023 18:43, Daniel P. Smith wrote:
> On 8/4/23 02:08, Jan Beulich wrote:
>> Have these in one place, for all architectures to use. Also use the C99
>> types as the "original" ones, and derive the Linux compatible ones
>> (which we're trying to phase out). For __s, seeing that no uses exist
On 09.08.2023 01:22, Stefano Stabellini wrote:
> On Tue, 8 Aug 2023, Jan Beulich wrote:
>> On 08.08.2023 10:47, Federico Serafini wrote:
>>> Hello everyone.
>>>
>>> I would like to to ask your opinion about the auto-generated file
>>> xen/include/xen/hypercall-defs.h which contains some violations
On 08.08.2023 23:14, Stefano Stabellini wrote:
> On Tue, 8 Aug 2023, Julien Grall wrote:
>> On 08/08/2023 16:53, Nicola Vetrini wrote:
> ... "return" alone already tells the compiler that "break" is
> unreachable. You don't need unreachable() for that. As said before,
> "break" like thi
flight 182243 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182243/
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 1
On Tue, 8 Aug 2023, Daniel P. Smith wrote:
> > Thanks for the example, it is finally clear!
> >
> > I don't think we should add hardware_dom=1 to the command line (I don't
> > know if it was just an example to make it easier to understand for me).
> > Instead it should a property on device tree. h
On Tue, 8 Aug 2023, Julien Grall wrote:
> > +
> > +role = <9>;
>
> Reading this, I wonder if using number is actually a good idea. While this is
> machine friendly, this is not human friendly.
+1
> The most human friendly interface would be to use string, but I understand
>
On Tue, 8 Aug 2023, Daniel P. Smith wrote:
> On 8/4/23 03:06, Michal Orzel wrote:
> > Hi Daniel,
> >
> > On 03/08/2023 18:57, Daniel P. Smith wrote:
> > >
> > >
> > > On 8/3/23 07:45, Michal Orzel wrote:
> > > > Hi Daniel,
> > > >
> > > > On 03/08/2023 12:44, Daniel P. Smith wrote:
> > > > >
>
On Tue, 8 Aug 2023, Julien Grall wrote:
> On 08/08/2023 21:49, Daniel P. Smith wrote:
> > On 8/4/23 05:03, Julien Grall wrote:
> > > Hi Daniel,
> > >
> > > On 03/08/2023 11:44, Daniel P. Smith wrote:
> > > > +compatible
> > > > + Identifies which hypervisors the configuration is compatible.
> > >
On Tue, 8 Aug 2023, Daniel P. Smith wrote:
> On 8/3/23 20:09, Stefano Stabellini wrote:
> > On Thu, 3 Aug 2023, Stefano Stabellini wrote:
> > > On Thu, 3 Aug 2023, Daniel P. Smith wrote:
> > > > > Also, what is the plan for the existing dom0less dt properties?
> > > > > Will they need to be moved t
On Tue, 8 Aug 2023, Daniel P. Smith wrote:
> On 8/3/23 19:38, Stefano Stabellini wrote:
> > On Thu, 3 Aug 2023, Daniel P. Smith wrote:
> > > > Also, what is the plan for the existing dom0less dt properties?
> > > > Will they need to be moved to new /hypervisor node or we will have to
> > > > parse
On 8/8/23 19:38, Stefano Stabellini wrote:
On Tue, 8 Aug 2023, Daniel P. Smith wrote:
On 8/3/23 16:19, Stefano Stabellini wrote:
On Thu, 3 Aug 2023, Daniel P. Smith wrote:
On 8/1/23 20:54, Stefano Stabellini wrote:
On Tue, 1 Aug 2023, Daniel P. Smith wrote:
The existing concepts such as unbo
flight 182231 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182231/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 18
test-amd64-amd64-xl-qemuu-win7-amd6
On 8/8/23 11:30, Jan Beulich wrote:
On 01.08.2023 22:20, Daniel P. Smith wrote:
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -164,48 +164,46 @@ static void set_cpuid_faulting(bool enable)
void ctxt_switch_levelling(const struct vcpu *next)
{
- const struct dom
On Tue, 8 Aug 2023, Daniel P. Smith wrote:
> On 8/3/23 16:19, Stefano Stabellini wrote:
> > On Thu, 3 Aug 2023, Daniel P. Smith wrote:
> > > On 8/1/23 20:54, Stefano Stabellini wrote:
> > > > On Tue, 1 Aug 2023, Daniel P. Smith wrote:
> > > > > The existing concepts such as unbounded domain, ie. al
On 8/8/23 11:24, Jan Beulich wrote:
On 01.08.2023 22:20, Daniel P. Smith wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -472,8 +472,8 @@ struct domain
#define ROLE_HARDWARE_DOMAIN (1U<<2)
#define ROLE_XENSTORE_DOMAIN (1U<<3)
uint8_t role;
-/* Can
On Tue, 8 Aug 2023, Jan Beulich wrote:
> On 08.08.2023 10:47, Federico Serafini wrote:
> > Hello everyone.
> >
> > I would like to to ask your opinion about the auto-generated file
> > xen/include/xen/hypercall-defs.h which contains some violations of
> > MISRA C:2012 Rule 8.3:
> > "All declaratio
On 8/3/23 17:03, Julien Grall wrote:
Hi,
Greetings
On 01/08/2023 21:20, Daniel P. Smith wrote:
The field `is_console` suggests that the field represents a state of
being or
posession, not that it reflects the privilege to access the console.
In this
patch the field is renamed to capabilitie
flight 182227 xen-unstable real [real]
flight 182240 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182227/
http://logs.test-lab.xenproject.org/osstest/logs/182240/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 8/3/23 17:24, Julien Grall wrote:
Hi Daniel,
On 03/08/2023 16:41, Daniel P. Smith wrote:
On 8/1/23 21:01, Stefano Stabellini wrote:
On Tue, 1 Aug 2023, Daniel P. Smith wrote:
patch the field is renamed to capabilities to encapsulate the
capabilities a
domain has been granted. The first
On 8/8/23 11:15, Jan Beulich wrote:
On 01.08.2023 22:20, Daniel P. Smith wrote:
@@ -1076,7 +1076,8 @@ static always_inline bool is_hardware_domain(const struct
domain *d)
if ( IS_ENABLED(CONFIG_PV_SHIM_EXCLUSIVE) )
return false;
-return evaluate_nospec(d == hardware_domai
On 8/3/23 16:19, Stefano Stabellini wrote:
On Thu, 3 Aug 2023, Daniel P. Smith wrote:
On 8/1/23 20:54, Stefano Stabellini wrote:
On Tue, 1 Aug 2023, Daniel P. Smith wrote:
The existing concepts such as unbounded domain, ie. all powerful, control
domain and hardware domain are, effectively, rol
Hi,
On 03/08/2023 11:44, Daniel P. Smith wrote:
+This node describes a boot module loaded by the boot loader. A ``module`` node
+will often appear repeatedly and will require a unique and DTB compliant name
+for each instance.
For clarification, do you mean module@? or somethi
Hi Daniel,
On 08/08/2023 21:49, Daniel P. Smith wrote:
On 8/4/23 05:03, Julien Grall wrote:
Hi Daniel,
On 03/08/2023 11:44, Daniel P. Smith wrote:
+compatible
+ Identifies which hypervisors the configuration is compatible.
Required.
- hypervisor {
- compatible = “hypervisor,xen”
flight 182238 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182238/
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 1
On 8/3/23 16:36, Andrew Cooper wrote:
The opensuse-tumbleweed build jobs currently fail with:
/builds/xen-project/xen/stubdom/tpm_emulator-x86_64/crypto/rsa.c: In
function 'rsa_private':
/builds/xen-project/xen/stubdom/tpm_emulator-x86_64/crypto/rsa.c:56:7:
error: the comparison will alw
On Tue, 8 Aug 2023, Stefano Stabellini wrote:
> On Tue, 8 Aug 2023, Jan Beulich wrote:
> > On 08.08.2023 09:08, Nicola Vetrini wrote:
> > > On 07/08/2023 11:10, Jan Beulich wrote:
> > >> On 07.08.2023 10:59, Nicola Vetrini wrote:
> > >>> On 07/08/2023 10:09, Jan Beulich wrote:
> > On 04.08.202
On Tue, 8 Aug 2023, Luca Fancellu wrote:
> > On 8 Aug 2023, at 09:50, Michal Orzel wrote:
> >
> > It was observed that smoke.serial file (used to store boot logs) is
> > missing in artifacts of qemu based arm32 jobs. This is because the
> > artifacts:paths listing smoke.serial specifies paths rel
On Tue, 8 Aug 2023, Jan Beulich wrote:
> On 08.08.2023 09:08, Nicola Vetrini wrote:
> > On 07/08/2023 11:10, Jan Beulich wrote:
> >> On 07.08.2023 10:59, Nicola Vetrini wrote:
> >>> On 07/08/2023 10:09, Jan Beulich wrote:
> On 04.08.2023 17:27, Nicola Vetrini wrote:
> > The variable declar
On 8/4/23 03:06, Michal Orzel wrote:
Hi Daniel,
On 03/08/2023 18:57, Daniel P. Smith wrote:
On 8/3/23 07:45, Michal Orzel wrote:
Hi Daniel,
On 03/08/2023 12:44, Daniel P. Smith wrote:
With on going development of hyperlaunch, changes to the device tree definitions
has been necessary. Thi
On Tue, 8 Aug 2023, Julien Grall wrote:
> On 08/08/2023 16:53, Nicola Vetrini wrote:
> > > > ... "return" alone already tells the compiler that "break" is
> > > > unreachable. You don't need unreachable() for that. As said before,
> > > > "break" like this simply want purging (and Misra is wrong to
On 8/4/23 00:10, Henry Wang wrote:
Hi Daniel,
Hey Henry!
-Original Message-
Subject: [PATCH v2 2/2] fdt: make fdt handling reusable across arch
This refactors reusable code from Arm's bootfdt.c and device-tree.h that is
general fdt handling code. The Kconfig parameter CORE_DEVICE
On 8/3/23 16:37, Luca Fancellu wrote:
Regarding the coding style, I think it’s better to keep the style you’ve found
in the original file,
and change only some bits when the code is not following it.
I know there is nothing enforcing parameters on the same line of the function
definition
On Tue, 8 Aug 2023, Luca Fancellu wrote:
> > On 8 Aug 2023, at 12:07, Michal Orzel wrote:
> >
> > Instead of repeating the same sequence of instructions to flush the TLBs
> > in various places, introduce a macro flush_xen_tlb_local and make use of
> > it. This is similar to what was done for arm3
On 8/4/23 05:03, Julien Grall wrote:
Hi Daniel,
On 03/08/2023 11:44, Daniel P. Smith wrote:
+compatible
+ Identifies which hypervisors the configuration is compatible.
Required.
- hypervisor {
- compatible = “hypervisor,xen”
+ Format: "hypervisor,", e.g "hypervisor,xen"
I read "
On Tue, 8 Aug 2023, Luca Fancellu wrote:
> > On 8 Aug 2023, at 13:02, Jan Beulich wrote:
> >
> > When !MEM_SHARING no useful output is produced. Move the function into
> > mm/mem_sharing.c while conditionalizing the call to it, thus allowing to
> > drop it altogether from Arm (and eliminating the
On Tue, 8 Aug 2023, Jan Beulich wrote:
> On 04.08.2023 23:39, Stefano Stabellini wrote:
> > Hi Tamas,
> >
> > May I have your ack on this change?
>
> I see you committed this, and there is an ack in the commit, but I can't
> see any ack on list (incl when checking mail archives, to exclude an
> i
On 8/3/23 20:09, Stefano Stabellini wrote:
On Thu, 3 Aug 2023, Stefano Stabellini wrote:
On Thu, 3 Aug 2023, Daniel P. Smith wrote:
Also, what is the plan for the existing dom0less dt properties?
Will they need to be moved to new /hypervisor node or we will have to parse
both /chosen and /hyper
On 8/8/23 3:36 AM, Jan Beulich wrote:
> On 03.08.2023 01:03, Shawn Anastasio wrote:
>> Implement bitops.h, based on Linux's implementation as of commit
>> 5321d1b1afb9a17302c6cec79f0cbf823eb0d3fc
>
> But with PPC32 bits dropped afaics, and with leading hard tabs replaced
> by four spaces - which i
On 8/7/23 11:13 AM, Jan Beulich wrote:
> On 03.08.2023 01:02, Shawn Anastasio wrote:
>> Implement atomic.h for PPC, based off of the original Xen 3.2
>> implementation.
>
> Since likely that originally came from Linux, did you cross check that
> Linux hasn't gained any bug fixes in the meantime?
On 8/3/23 19:38, Stefano Stabellini wrote:
On Thu, 3 Aug 2023, Daniel P. Smith wrote:
Also, what is the plan for the existing dom0less dt properties?
Will they need to be moved to new /hypervisor node or we will have to parse
both /chosen and /hypervisor nodes?
In the proposal I sent to xen-de
On 8/7/23 10:51 AM, Jan Beulich wrote:
> On 03.08.2023 01:02, Shawn Anastasio wrote:
>> Signed-off-by: Shawn Anastasio
>> ---
>> xen/include/public/arch-ppc.h | 140 ++
>> 1 file changed, 140 insertions(+)
>> create mode 100644 xen/include/public/arch-ppc.h
>>
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2023-20569 / XSA-434
x86/AMD: Speculative Return Stack Overflow
ISSUE DESCRIPTION
=
Researchers from ETH Zurich have extended their prior research (XSA-422,
Branch Type Confusion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-40982 / XSA-435
x86/Intel: Gather Data Sampling
ISSUE DESCRIPTION
=
A researcher has discovered Gather Data Sampling, a transient execution
side-channel whereby the AVX
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2023-34319 / XSA-432
version 2
Linux: buffer overrun in netback due to unusual packet
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
===
On 8/4/23 03:49, Jan Beulich wrote:
On 03.08.2023 18:31, Daniel P. Smith wrote:
On 8/3/23 11:56, Jan Beulich wrote:
On 03.08.2023 14:56, Daniel P. Smith wrote:
On 8/2/23 07:01, Jan Beulich wrote:
On 01.08.2023 18:06, Daniel P. Smith wrote:
+{
+for_each_domain(next)
What
On 8/7/23 10:39 AM, Jan Beulich wrote:
> On 03.08.2023 01:02, Shawn Anastasio wrote:
>> A few files treewide depend on defininitions in headers that they
>> don't include. This works when arch headers end up including the
>> required headers by chance, but broke on ppc64 with only minimal/stub
>> a
On 8/4/23 02:08, Jan Beulich wrote:
Have these in one place, for all architectures to use. Also use the C99
types as the "original" ones, and derive the Linux compatible ones
(which we're trying to phase out). For __s, seeing that no uses exist
anymore, move them to a new Linux compatibility head
flight 182225 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182225/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 broken
test-armhf-armhf-libvirt-qcow2 5 host-i
On 08/08/2023 16:53, Nicola Vetrini wrote:
... "return" alone already tells the compiler that "break" is
unreachable. You don't need unreachable() for that. As said before,
"break" like this simply want purging (and Misra is wrong to demand
"break" everywhere - it should instead demand no [
... "return" alone already tells the compiler that "break" is
unreachable. You don't need unreachable() for that. As said before,
"break" like this simply want purging (and Misra is wrong to demand
"break" everywhere - it should instead demand no [unannotated]
fall-through, which can also be a
Hi,
On 08/08/2023 16:36, Jan Beulich wrote:
On 08.08.2023 17:25, Julien Grall wrote:
On 02/08/2023 15:38, Nicola Vetrini wrote:
The break statement after the return statement is definitely unreachable.
As such, an call to the ASSERT_UNREACHABLE() macro is added to signal
the intentionality of
On 08.08.2023 17:25, Julien Grall wrote:
> On 02/08/2023 15:38, Nicola Vetrini wrote:
>> The break statement after the return statement is definitely unreachable.
>> As such, an call to the ASSERT_UNREACHABLE() macro is added to signal
>> the intentionality of such construct.
>
> How about using u
On 01.08.2023 22:20, Daniel P. Smith wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -164,48 +164,46 @@ static void set_cpuid_faulting(bool enable)
>
> void ctxt_switch_levelling(const struct vcpu *next)
> {
> - const struct domain *nextd = next ? next->domai
Hi,
On 02/08/2023 15:38, Nicola Vetrini wrote:
The break statement after the return statement is definitely unreachable.
As such, an call to the ASSERT_UNREACHABLE() macro is added to signal
the intentionality of such construct.
How about using unreachable() rather than ASSERT_UNREACHABLE()? T
On 01.08.2023 22:20, Daniel P. Smith wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -472,8 +472,8 @@ struct domain
> #define ROLE_HARDWARE_DOMAIN (1U<<2)
> #define ROLE_XENSTORE_DOMAIN (1U<<3)
> uint8_t role;
> -/* Can this guest access the Xen c
On 01.08.2023 22:20, Daniel P. Smith wrote:
> @@ -1076,7 +1076,8 @@ static always_inline bool is_hardware_domain(const
> struct domain *d)
> if ( IS_ENABLED(CONFIG_PV_SHIM_EXCLUSIVE) )
> return false;
>
> -return evaluate_nospec(d == hardware_domain);
> +return evaluate_nos
The patch series introduces things necessary to implement identity mapping:
1. Make identity mapping for the entire Xen.
2. Enable MMU.
3. Jump to the virtual address world
4. Remove identity mapping.
Also current patch series introduces the calculation of physical offset before
MMU is ena
The way how switch to virtual address was implemented in the
commit e66003e7be ("xen/riscv: introduce setup_initial_pages")
isn't safe enough as:
* enable_mmu() depends on hooking all exceptions
and pagefault.
* Any exception other than pagefault, or not taking a pagefault
causes it to malfunct
The function was introduced to calculate and save physical
offset before MMU is enabled because access to start() is
PC-relative and in case of linker_addr != load_addr it will
result in incorrect value in phys_offset.
Signed-off-by: Oleksii Kurochko
---
Changes in V7:
- nothing changed. only re
> On 8 Aug 2023, at 13:02, Jan Beulich wrote:
>
> When !MEM_SHARING no useful output is produced. Move the function into
> mm/mem_sharing.c while conditionalizing the call to it, thus allowing to
> drop it altogether from Arm (and eliminating the need to introduce stubs
> on PPC and RISC-V).
>
Commit a92336a1176b ("xen/pciback: Drop two backends, squash and cleanup some
code.")
declared but never implemented these functions.
Signed-off-by: Yue Haibing
---
drivers/xen/xen-pciback/conf_space_quirks.h | 2 --
drivers/xen/xen-pciback/pciback.h | 3 ---
2 files changed, 5 deleti
On Tue, Aug 08, 2023 at 10:26:38AM +0200, Greg KH wrote:
> On Sun, Aug 06, 2023 at 11:15:51AM -0400, Alan Stern wrote:
> > On Sun, Aug 06, 2023 at 04:27:27PM +0200, Greg KH wrote:
> > > On Sun, Aug 06, 2023 at 10:11:43PM +0800, Zhang Shurong wrote:
> > > > 在 2023年7月1日星期六 CST 下午11:51:43，Zhang Shuron
> On 8 Aug 2023, at 12:07, Michal Orzel wrote:
>
> Instead of repeating the same sequence of instructions to flush the TLBs
> in various places, introduce a macro flush_xen_tlb_local and make use of
> it. This is similar to what was done for arm32 by the commit:
> dea9dddeceec8a1d68da24b14d5b2
flight 182232 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182232/
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 1
On 08.08.2023 13:08, Nicola Vetrini wrote:
> The macros defined 'xen/include/public/arch-x86/xen-mca.h' are revised
> to address the following concerns:
> - needless underscore prefixes for parameter names;
> - the variable 'i' in function 'mce_action' that is shadowed
> by the local variable in
On 08.08.2023 13:08, Nicola Vetrini wrote:
> Rename the local variables s/xsave/xstate/ to avoid clashing
> with function 'xsave' defined in 'xen/arch/x86/include/asm/xstate.h'.
s/defined/declared/ (in some areas of Misra the distinction looks to
be quite relevant, so being precise everywhere is h
On 08.08.2023 13:08, Nicola Vetrini wrote:
> Variable 'mpc_default_type' in 'xen/arch/x86/include/asm/mpspec.h'
> has no uses and causes shadowing with function parameter names
> in 'mpparse.c'. Therefore, it is removed.
Personally I'd again wish this could be expressed more precisely than
just "v
On 08.08.2023 15:56, Jan Beulich wrote:
> On 08.08.2023 13:08, Nicola Vetrini wrote:
>> --- a/xen/include/xen/delay.h
>> +++ b/xen/include/xen/delay.h
>> @@ -4,7 +4,12 @@
>> /* Copyright (C) 1993 Linus Torvalds */
>>
>> #include
>> -#define mdelay(n) (\
>> -{unsigned long msec=(n); while (
On 08.08.2023 13:08, Nicola Vetrini wrote:
> --- a/xen/include/xen/delay.h
> +++ b/xen/include/xen/delay.h
> @@ -4,7 +4,12 @@
> /* Copyright (C) 1993 Linus Torvalds */
>
> #include
> -#define mdelay(n) (\
> - {unsigned long msec=(n); while (msec--) udelay(1000);})
> +
> +static inline void
@@ -462,7 +462,7 @@ static void del_msixtbl_entry(struct
msixtbl_entry
*entry)
int msixtbl_pt_register(struct domain *d, struct pirq *pirq,
uint64_t
gtable)
{
-struct irq_desc *irq_desc;
+struct irq_desc *irqd;
This one indeed wants renaming, but then - consistent within the f
On Tue, Aug 08, 2023 at 03:22:19PM +0200, Juergen Gross wrote:
> In case Xen has been configured with "--disable-pygrub", don't accept
> the domain config option "bootloader=pygrub".
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Juergen Gross
I'm unsure about this patch, but I guess we kind
On 08.08.2023 15:36, Juergen Gross wrote:
> On 08.08.23 15:32, Jan Beulich wrote:
>> On 08.08.2023 15:22, Juergen Gross wrote:
>>> --- a/tools/xl/xl_parse.c
>>> +++ b/tools/xl/xl_parse.c
>>> @@ -1692,6 +1692,15 @@ void parse_config_data(const char *config_source,
>>> xlu_cfg_get_defbool(confi
On 08.08.2023 15:38, Nicola Vetrini wrote:
> On 08/08/2023 15:22, Jan Beulich wrote:
>> On 08.08.2023 14:22, Nicola Vetrini wrote:
>>> The local variables 'irq_desc' shadow the homonymous global variable,
>>> declared in 'xen/arch/x86/include/asm/irq.h', therefore they are
>>> renamed
>>> 'irqd' f
On 08.08.2023 13:08, Nicola Vetrini wrote:
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -543,27 +543,27 @@ static void __init machine_specific_memory_setup(struct
> e820map *raw)
> clip_to_limit(top_of_ram, "MTRRs do not cover all of memory.");
> }
>
> -/* This function
On Tue, Aug 08, 2023 at 03:22:18PM +0200, Juergen Gross wrote:
> The only in-tree user of libfsimage is pygrub. Now that it is possible
> to disable the build of pygrub, the same should be possible for
> libfsimage.
>
> Add an option for controlling the build of libfsimage. The default is
> on if
On Tue, Aug 08, 2023 at 03:22:17PM +0200, Juergen Gross wrote:
> Add a "--disable-pygrub" option for being able to disable the build
> and installation of pygrub.
>
> There are two main reasons to do so:
>
> - A main reason to use pygrub is to allow a PV guest to choose its
> bitness (32- or 64
On 08/08/2023 15:22, Jan Beulich wrote:
On 08.08.2023 14:22, Nicola Vetrini wrote:
The local variables 'irq_desc' shadow the homonymous global variable,
declared in 'xen/arch/x86/include/asm/irq.h', therefore they are
renamed
'irqd' for consistency with ARM code. Other variables of the same ty
On 08.08.23 15:32, Jan Beulich wrote:
On 08.08.2023 15:22, Juergen Gross wrote:
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -1692,6 +1692,15 @@ void parse_config_data(const char *config_source,
xlu_cfg_get_defbool(config, "acpi", &b_info->acpi, 0);
xlu_cfg_replace_strin
On 08.08.2023 15:22, Juergen Gross wrote:
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -1692,6 +1692,15 @@ void parse_config_data(const char *config_source,
> xlu_cfg_get_defbool(config, "acpi", &b_info->acpi, 0);
>
> xlu_cfg_replace_string (config, "bootloader", &b_info
Hi,
On Tue, Aug 08, 2023 at 03:08:04PM +0200, Jan Beulich wrote:
> On 08.08.2023 15:03, Alejandro Vallejo wrote:
> > --- a/xen/arch/x86/cpu/microcode/core.c
> > +++ b/xen/arch/x86/cpu/microcode/core.c
> > @@ -867,10 +867,23 @@ int __init early_microcode_init(unsigned long
> > *module_map,
> >
On 08.08.2023 14:22, Nicola Vetrini wrote:
> The parameters in the function declaration 'construct_dom0' violate
> Rule 8.3:
> "All declarations of an object or function shall use the same names
> and type qualifiers", but also cause shadowing inside the declaration
> scope with the variable "stati
The only in-tree user of libfsimage is pygrub. Now that it is possible
to disable the build of pygrub, the same should be possible for
libfsimage.
Add an option for controlling the build of libfsimage. The default is
on if pygrub is being built, and off if it isn't. Without pygrub the
build of lib
In case Xen has been configured with "--disable-pygrub", don't accept
the domain config option "bootloader=pygrub".
Suggested-by: Andrew Cooper
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
tools/xl/xl_parse.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/xl/xl_parse
Add two additional configure options for controlling the build of
pygrub and libfsimage.
Changes in V2:
- add check for --enable-pygrub --disable-libfsimage
- new patch 3
Juergen Gross (3):
tools: add configure option for disabling pygrub
tools: add configure option for libfsimage
tools/xl:
Add a "--disable-pygrub" option for being able to disable the build
and installation of pygrub.
There are two main reasons to do so:
- A main reason to use pygrub is to allow a PV guest to choose its
bitness (32- or 64-bit). Pygrub allows that by looking into the boot
image and to start the g
On 08.08.2023 14:22, Nicola Vetrini wrote:
> The local variables 'irq_desc' shadow the homonymous global variable,
> declared in 'xen/arch/x86/include/asm/irq.h', therefore they are renamed
> 'irqd' for consistency with ARM code. Other variables of the same type
> in the file are also renamed 'irqd
On 03.08.2023 01:03, Shawn Anastasio wrote:
> Bring ppc's Makefile and arch.mk in line with arm and x86 to disable the
> build overrides and enable the full Xen build.
>
> Signed-off-by: Shawn Anastasio
Reviewed-by: Jan Beulich
On 08.08.2023 15:08, Jan Beulich wrote:
> On 08.08.2023 15:03, Alejandro Vallejo wrote:
>> --- a/xen/arch/x86/cpu/microcode/core.c
>> +++ b/xen/arch/x86/cpu/microcode/core.c
>> @@ -867,10 +867,23 @@ int __init early_microcode_init(unsigned long
>> *module_map,
>> return -ENODEV;
>> }
On 08.08.2023 15:03, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -867,10 +867,23 @@ int __init early_microcode_init(unsigned long
> *module_map,
> return -ENODEV;
> }
>
> -microcode_grab_module(module_map, mb
If IA32_MSR_MCU_CONTROL exists then it's possible a CPU may be unable to
perform microcode updates. This is controlled through the DIS_MCU_LOAD bit
and is intended for baremetal clouds where the owner may not trust the
tenant to choose the microcode version in use. If we notice that bit being
set t
Move MSR_ARCH_CAPS read code from tsx_init() to early_cpu_init(). Because
microcode updates might make them that MSR to appear/have different values
we also must reload it after a microcode update in early_microcode_init().
Signed-off-by: Alejandro Vallejo
Reviewed-by: Jan Beulich
---
v7:
* No
Under certain conditions a CPU may not be able to perform microcode updates
even if hardware exists to that effect. In particular:
* If Xen runs under certain hypervisors they won't allow microcode
updates, and will signal this fact by reporting a microcode revision of
-1.
* If the DIS_MCU
Some hypervisors report ~0 as the microcode revision to mean "don't issue
microcode updates". Ignore the microcode loading interface in that case.
Signed-off-by: Alejandro Vallejo
---
v7:
* Removed R-by tag. It wasn't meant to be there!
* Fix wrong substring inserted in printk statement
* R
The next patch compiles out compression-related chunks, and it's helpful to
have them grouped together beforehand.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Julien Grall
---
v3:
* No changes
---
xen/common/pdx.c | 58 +-
xen/include/xen/pdx.h |
Currently there's a CONFIG_HAS_PDX Kconfig option, but it's impossible to
disable it because the whole codebase performs unconditional
compression/decompression operations on addresses. This has the
unfortunate side effect that systems without a need for compression still
have to pay the performanc
1 - 100 of 172 matches
Mail list logo
