On 24.04.2024 05:34, Henry Wang wrote:
> --- a/xen/common/dt-overlay.c
> +++ b/xen/common/dt-overlay.c
> @@ -381,9 +381,14 @@ static int remove_node_resources(struct dt_device_node
> *device_node)
> {
> if ( dt_device_is_protected(device_node) )
> {
> +
On 23.04.2024 16:59, Jan Beulich wrote:
> On 22.04.2024 20:14, Andrew Cooper wrote:
>> --- a/xen/arch/x86/alternative.c
>> +++ b/xen/arch/x86/alternative.c
>> @@ -244,10 +244,31 @@ static void init_or_livepatch
>> _apply_alternatives(struct alt_instr *start,
>>
>> memcpy(buf, repl,
flight 185781 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185781/
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
From: Vikram Garhwal
Add 3 new command line parameters to the xl overlay command: overlay
name, type and partial. Pass these paramters to the domU via xenstore.
Also introduce support for "operation" in xenstore: it can be "add" or
"remove". In case of "remove", the overlay is to be removed
From: Vikram Garhwal
Retrieve 4 new parameters from xenstore: overlay name, type, whether it
is a partial overlay and operation. Operation can be "add" or "remove".
Add correspond to existing mode of operation. Remove introduces support
for removing an overlay from a domU.
Signed-off-by:
From: Vikram Garhwal
This user level application copies the overlay dtbo shared by dom0 while doing
overlay node assignment operation. It uses xenstore to communicate with dom0.
More information on the protocol is writtien in docs/misc/overlay.txt file.
Signed-off-by: Vikram Garhwal
From: Vikram Garhwal
Introduce a shell script that runs in the background and calls
get_overlay to retrive overlays and add them (or remove them) to Linux
device tree (running as a domU).
Signed-off-by: Vikram Garhwal
Signed-off-by: Stefano Stabellini
Signed-off-by: Henry Wang
---
From: Vikram Garhwal
Following changes are done to enable dtbo assignment to a running vm with given
domain_id:
1. Support for irq map and unmap for running domain. We store the IRQ nums for
each overlay and while removing those IRQ nums are removed.
2. Support iommu assign/reassign to
From: Vikram Garhwal
Signed-off-by: Vikram Garhwal
Signed-off-by: Stefano Stabellini
Signed-off-by: Henry Wang
---
docs/misc/arm/overlay.txt | 172 ++
1 file changed, 172 insertions(+)
create mode 100644 docs/misc/arm/overlay.txt
diff --git
From: Vikram Garhwal
Move struct range, rangeset and removed static from first_range and
next_range().
IRQs and IOMEMs for nodes are stored as rangeset in the dynamic node addition
part. While removing the nodes we need to access every IRQ and IOMEM ranges to
unmap IRQ and IOMEM from the
From: Vikram Garhwal
Add support for modifying dtbo to make it suitable for DomU Linux. This is
done for '-e expert' mode.
Signed-off-by: Vikram Garhwal
Signed-off-by: Stefano Stabellini
Signed-off-by: Henry Wang
---
tools/libs/light/libxl_dt_overlay.c | 73 +
1
From: Vikram Garhwal
Add domid to enable assigning the node to a running VMs.
Add expert mode option to share the overlay dtbo with domU. In this mode dom0
communicates with domid domain to share the overlay dtbo. This is done via
xenstore.
Signed-off-by: Vikram Garhwal
Signed-off-by: Stewart
From: Vikram Garhwal
Add domain_id and expert mode for overlay assignment. This enables dynamic
programming of nodes during runtime.
Take the opportunity to fix the name mismatch in the xl command, the
command name should be "dt-overlay" instead of "dt_overlay".
Signed-off-by: Vikram Garhwal
From: Vikram Garhwal
Increase number of spi to 160 i.e. gic_number_lines() for Xilinx ZynqMP - 32.
This was done to allocate and assign IRQs to a running domain.
Signed-off-by: Vikram Garhwal
Signed-off-by: Stefano Stabellini
Signed-off-by: Henry Wang
---
tools/libs/light/libxl_arm.c | 3
From: Vikram Garhwal
For overlay with iommu functionality to work with running VMs, we need
to enable IOMMU when iomem presents for the domains.
Signed-off-by: Vikram Garhwal
Signed-off-by: Henry Wang
---
tools/libs/light/libxl_arm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
From: Vikram Garhwal
For overlay with iommu functionality to work with running VMs, we need to enable
IOMMU by default for the domains.
Signed-off-by: Vikram Garhwal
Signed-off-by: Stefano Stabellini
Signed-off-by: Henry Wang
---
xen/arch/arm/dom0less-build.c | 3 ++-
1 file changed, 2
If CONFIG_DEBUG=y, below assertion will be triggered:
(XEN) Assertion 'rw_is_locked(_host_lock)' failed at
drivers/passthrough/device_tree.c:146
(XEN) [ Xen-4.19-unstable arm64 debug=y Not tainted ]
(XEN) CPU: 0
(XEN) PC: 0a257418 iommu_remove_dt_device+0x8c/0xd4
(XEN)
Hi all,
This is the remaining series for the full functional "dynamic node
programming using overlay dtbo" feature. The first part [1] has
already been merged.
Quoting from the original series, the first part has already made
Xen aware of new device tree node which means updating the dt_host
From: Vikram Garhwal
Enable interrupt assign/remove for running VMs in CONFIG_OVERLAY_DTB.
Currently, irq_route and mapping is only allowed at the domain creation. Adding
exception for CONFIG_OVERLAY_DTB.
Signed-off-by: Vikram Garhwal
Signed-off-by: Stefano Stabellini
Signed-off-by: Henry
flight 185769 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185769/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 185433
build-arm64-xsm
flight 185775 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185775/
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
flight 185768 linux-linus real [real]
flight 185778 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185768/
http://logs.test-lab.xenproject.org/osstest/logs/185778/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 185776 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185776/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d97f964f7ce063f9861f4d21cc6352f6861f95a8
baseline version:
ovmf
On Sun, Apr 14, 2024 at 2:21 PM Petr Beneš wrote:
>
> From: Petr Beneš
>
> Reorder the condition checks within the HVM_MONITOR_SINGLESTEP_BREAKPOINT
> case to enable fast singlestepping independently of the singlestep monitor
> being enabled. Previously, fast singlestepping required the
On 23/04/2024 3:31 pm, Jan Beulich wrote:
> The latest as of e2b2ff677958 ("x86/P2M: split out init/teardown
> functions") the function is obviously unreachable for PV guests.
This doesn't parse. Do you mean "Since e2b2ff677958 ..." ?
> Hence
> the paging_mode_enabled(d) check is pointless.
>
flight 185773 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185773/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e3fa6986ae8521275fc6ca161f7394a3809f8723
baseline version:
ovmf
flight 185770 xen-unstable-smoke real [real]
flight 185772 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185770/
http://logs.test-lab.xenproject.org/osstest/logs/185772/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 185767 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185767/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-pvshim 13 debian-fixup fail in 185762 pass in 185767
test-armhf-armhf-xl-rtds 8
On Tue, Apr 23, 2024 at 04:26:53PM +0100, Fouad Hilly wrote:
> On Mon, Apr 22, 2024 at 6:57 PM Anthony PERARD
> wrote:
> > On Tue, Apr 16, 2024 at 10:15:46AM +0100, Fouad Hilly wrote:
> > > diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c
> > > index e3c1943e3633..4178fd2221ea 100644
On Tue, Apr 23, 2024 at 04:16:10PM +0100, Fouad Hilly wrote:
> On Mon, Apr 22, 2024 at 6:48 PM Anthony PERARD
> wrote:
> > On Tue, Apr 16, 2024 at 10:15:45AM +0100, Fouad Hilly wrote:
> > > +if ( argc != 2 )
> > > +goto ext_err;
> >
> > Why only two arguments allowed? And why check
At the moment, all the Arm64 Qemu tests use GICv2 which is the default
GIC version used by Qemu. Improve the coverage by adding a new test in
which Qemu will be configured to have GICv3.
Rename host device tree name to "virt.dtb" to be GIC version agnostic.
Use "gic-version" Qemu option to select
Introduce qemu based Arm earlyprintk test and build jobs to cover this
feature in debug variant. The tests simply check for the presence of the
last message printed by the bootstrap code before entering the C world.
Signed-off-by: Michal Orzel
---
automation/gitlab-ci/build.yaml
This came up as part of the following discussion:
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2402291108290.853156@ubuntu-linux-20-04-desktop/
Michal Orzel (3):
automation: Drop some of the non-debug variants of the same Arm jobs
automation: Add arm{64,32} earlyprintk jobs
To save some bandwith that can be later on used to increase the test
coverage by adding new tests, drop the following non-debug test/build
jobs existing in both debug and non-debug variants:
- static memory (arm64, arm32)
- static shared memory (arm64)
- static heap (arm64)
- boot cpupools
On 23.04.2024 16:53, Fouad Hilly wrote:
> On Mon, Apr 8, 2024 at 10:16 AM Jan Beulich wrote:
>> On 05.04.2024 14:11, Fouad Hilly wrote:
>>> @@ -708,11 +712,13 @@ static long cf_check microcode_update_helper(void
>>> *data)
>>> return ret;
>>> }
>>>
>>> -int
On 23.04.2024 17:03, Roger Pau Monné wrote:
> On Tue, Apr 23, 2024 at 04:28:59PM +0200, Jan Beulich wrote:
>> On 23.04.2024 16:26, Roger Pau Monné wrote:
>>> On Tue, Apr 23, 2024 at 03:44:42PM +0200, Jan Beulich wrote:
On 23.04.2024 15:12, Roger Pau Monne wrote:
> Livepatch payloads
On 23.04.2024 17:52, Federico Serafini wrote:
> On 23/04/24 12:26, Jan Beulich wrote:
>> On 23.04.2024 12:02, Federico Serafini wrote:
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -302,6 +302,19 @@ Deviations related to MISRA C:2012 Rules:
>>> leave such
On Tue, Apr 23, 2024 at 03:12:47PM +0200, Roger Pau Monne wrote:
> Introduce a xen-livepatch tool --force option, that's propagated into the
> hyerpvisor for livepatch operations. The intention is for the option to be
> used to bypass some checks that would otherwise prevent the patch from being
On 23/04/24 12:26, Jan Beulich wrote:
On 23.04.2024 12:02, Federico Serafini wrote:
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -302,6 +302,19 @@ Deviations related to MISRA C:2012 Rules:
leave such files as is.
- Tagged as `deliberate` for ECLAIR.
+
Hi Julien,
On Mon, Apr 22, 2024 at 1:40 PM Julien Grall wrote:
>
> Hi Jens,
>
> This is not a full review of the code. I will let Bertrand doing it.
>
> On 22/04/2024 08:37, Jens Wiklander wrote:
> > +void ffa_notif_init(void)
> > +{
> > +const struct arm_smccc_1_2_regs arg = {
> > +
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
On Mon, Apr 22, 2024 at 6:57 PM Anthony PERARD wrote:
>
> On Tue, Apr 16, 2024 at 10:15:46AM +0100, Fouad Hilly wrote:
> > Introduce --force option to xen-ucode to force skipping microcode version
> > check, which allows the user to update x86 microcode even if both versions
> > are the same.
> >
Hi Julien,
> On 23 Apr 2024, at 17:16, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 23/04/2024 16:12, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 22 Apr 2024, at 13:40, Julien Grall wrote:
>>>
>>> Hi Jens,
>>>
>>> This is not a full review of the code. I will let Bertrand doing it.
>>>
>>>
On Mon, Apr 22, 2024 at 6:48 PM Anthony PERARD wrote:
>
> On Tue, Apr 16, 2024 at 10:15:45AM +0100, Fouad Hilly wrote:
> > diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c
> > index 0c0b2337b4ea..e3c1943e3633 100644
> > --- a/tools/misc/xen-ucode.c
> > +++ b/tools/misc/xen-ucode.c
> >
Hi Bertrand,
On 23/04/2024 16:12, Bertrand Marquis wrote:
Hi Julien,
On 22 Apr 2024, at 13:40, Julien Grall wrote:
Hi Jens,
This is not a full review of the code. I will let Bertrand doing it.
On 22/04/2024 08:37, Jens Wiklander wrote:
+void ffa_notif_init(void)
+{
+const struct
From: Simone Ballarin
Introduce accepted_guidelines.sh: a script to autogenerate the
configuration file accepted.ecl from docs/misra/rules.rst which enables
all accepted guidelines.
Introduce monitored.ecl: a manual selection of accepted guidelines
which are clean or almost clean, it is
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
Hi all,
this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted
The count_args_ macro violates Rule 20.7, but it can't be made
compliant with Rule 20.7 without breaking its functionality. Since
it's very unlikely for this macro to be misused, it is deviated.
No functional change.
Signed-off-by: Nicola Vetrini
---
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly
Hi Julien,
> On 22 Apr 2024, at 13:40, Julien Grall wrote:
>
> Hi Jens,
>
> This is not a full review of the code. I will let Bertrand doing it.
>
> On 22/04/2024 08:37, Jens Wiklander wrote:
>> +void ffa_notif_init(void)
>> +{
>> +const struct arm_smccc_1_2_regs arg = {
>> +.a0 =
On Tue, Apr 23, 2024 at 04:28:59PM +0200, Jan Beulich wrote:
> On 23.04.2024 16:26, Roger Pau Monné wrote:
> > On Tue, Apr 23, 2024 at 03:44:42PM +0200, Jan Beulich wrote:
> >> On 23.04.2024 15:12, Roger Pau Monne wrote:
> >>> Livepatch payloads containing symbols that belong to init sections can
On 22.04.2024 20:14, Andrew Cooper wrote:
> A subsequent patch is going to insert a loop, which interferes with the
> continue in the devirtualisation logic.
>
> Replace it with a goto, and a paragraph explaining why we intentionally avoid
> setting a->priv = 1.
>
> No functional change.
>
>
On 22.04.2024 20:14, Andrew Cooper wrote:
> ... to make subsequent patches legible.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
even if (perhaps due to changes in the "real" patch) some of this re-
indenting wants doing differently, just with ...
> ---
On Thu, Apr 18, 2024 at 11:05 AM Andrew Cooper
wrote:
>
> On 16/04/2024 10:15 am, Fouad Hilly wrote:
> > Update microcode version check at Intel and AMD Level by:
> > Preventing the low level code from sending errors if the microcode
> > version provided is not a newer version. Other errors will
On Mon, Apr 22, 2024 at 3:09 PM Jan Beulich wrote:
>
> On 16.04.2024 11:15, Fouad Hilly wrote:
> > Update microcode version check at Intel and AMD Level by:
> > Preventing the low level code from sending errors if the microcode
> > version provided is not a newer version.
>
> And why is this
On 22.04.2024 20:14, Andrew Cooper wrote:
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -244,10 +244,31 @@ static void init_or_livepatch
> _apply_alternatives(struct alt_instr *start,
>
> memcpy(buf, repl, a->repl_len);
>
> +/* Walk buf[] and
On Tue, Apr 23, 2024 at 1:05 PM Julien Grall wrote:
>
>
>
> On 23/04/2024 10:35, Jens Wiklander wrote:
> > Hi Julien,
>
> Hi Jens,
>
> > On Mon, Apr 22, 2024 at 12:57 PM Julien Grall wrote:
> >>
> >> Hi Jens,
> >>
> >> On 22/04/2024 08:37, Jens Wiklander wrote:
> >>> Updates so request_irq() can
On Mon, Apr 8, 2024 at 10:16 AM Jan Beulich wrote:
>
> On 05.04.2024 14:11, Fouad Hilly wrote:
> > @@ -708,11 +712,13 @@ static long cf_check microcode_update_helper(void
> > *data)
> > return ret;
> > }
> >
> > -int microcode_update(XEN_GUEST_HANDLE(const_void) buf, unsigned long len)
> >
Hi,
On Tue, Apr 23, 2024 at 4:28 PM Julien Grall wrote:
>
> Hi Bertrand,
>
> On 23/04/2024 14:23, Bertrand Marquis wrote:
> > Hi Julien,
> >
> >> On 23 Apr 2024, at 14:37, Bertrand Marquis
> >> wrote:
> >>
> >> Hi Julien,
> >>
> >>> On 23 Apr 2024, at 13:05, Julien Grall wrote:
> >>>
> >>>
>
Pavel Begunkov wrote:
> We'll need to associate additional callbacks with ubuf_info, introduce
> a structure holding ubuf_info callbacks. Apart from a more smarter
> io_uring notification management introduced in next patches, it can be
> used to generalise msg_zerocopy_put_abort() and also store
Pavel Begunkov wrote:
> At the moment an skb can only have one ubuf_info associated with it,
> which might be a performance problem for zerocopy sends in cases like
> TCP via io_uring. Add a callback for assigning ubuf_info to skb, this
> way we will implement smarter assignment later like linking
On 22.04.2024 20:14, Andrew Cooper wrote:
> In debug builds, walk all alternative replacements with x86_decode_lite().
>
> This checks that we can decode all instructions, and also lets us check that
> disp8's don't leave the replacement block.
>
> Signed-off-by: Andrew Cooper
With pointed-to
On Mon, Apr 22, 2024 at 3:18 PM Jan Beulich wrote:
>
> On 16.04.2024 11:15, Fouad Hilly wrote:
> > Refactor microcode_update() hypercall by adding flags field.
> > Introduce XENPF_microcode_update2 hypercall to handle flags field.
> > struct xenpf_microcode_update updated to have uint32_t flags
On 23.04.2024 16:31, Roger Pau Monné wrote:
> On Tue, Apr 23, 2024 at 03:51:31PM +0200, Jan Beulich wrote:
>> On 23.04.2024 15:12, Roger Pau Monne wrote:
>>> Ensure the entries of a payload exception table only apply to text regions
>>> in
>>> the payload itself. Since the payload exception
As of the commit referenced below the update_paging_modes() hook is per-
domain and hence also set (already) during domain construction.
Fixes: d0816a9085b5 ("x86/paging: move update_paging_modes() hook")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++
... thanks to paging_vcpu_init() being part of vCPU creation. Further
if paging is enabled on a domain, it's also guaranteed to be either HAP
or shadow. Drop respective unnecessary (parts of) conditionals.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
Drop the inner scope that was left from earlier if/else removal. Take
the opportunity and make the paging_unlock() invocation common to
success and error paths, though.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -110,49 +110,43 @@ static int
The latest as of e2b2ff677958 ("x86/P2M: split out init/teardown
functions") the function is obviously unreachable for PV guests. Hence
the paging_mode_enabled(d) check is pointless.
Further host mode of a vCPU is always set, by virtue of
paging_vcpu_init() being part of vCPU creation. Hence the
On Tue, Apr 23, 2024 at 03:51:31PM +0200, Jan Beulich wrote:
> On 23.04.2024 15:12, Roger Pau Monne wrote:
> > Ensure the entries of a payload exception table only apply to text regions
> > in
> > the payload itself. Since the payload exception table needs to be loaded
> > and
> > active even
1: P2M: write_p2m_entry() is HVM-only anyway
2: P2M: un-indent write_p2m_entry()
3: paging: vCPU host mode is always set
4: shadow: correct shadow_vcpu_init()'s comment
Jan
On 23.04.2024 16:26, Roger Pau Monné wrote:
> On Tue, Apr 23, 2024 at 03:44:42PM +0200, Jan Beulich wrote:
>> On 23.04.2024 15:12, Roger Pau Monne wrote:
>>> Livepatch payloads containing symbols that belong to init sections can only
>>> lead to page faults later on, as by the time the livepatch
Hi Bertrand,
On 23/04/2024 14:23, Bertrand Marquis wrote:
Hi Julien,
On 23 Apr 2024, at 14:37, Bertrand Marquis wrote:
Hi Julien,
On 23 Apr 2024, at 13:05, Julien Grall wrote:
On 23/04/2024 10:35, Jens Wiklander wrote:
Hi Julien,
Hi Jens,
On Mon, Apr 22, 2024 at 12:57 PM Julien
On Tue, Apr 23, 2024 at 03:44:42PM +0200, Jan Beulich wrote:
> On 23.04.2024 15:12, Roger Pau Monne wrote:
> > Livepatch payloads containing symbols that belong to init sections can only
> > lead to page faults later on, as by the time the livepatch is loaded init
> > sections have already been
On Tue, Apr 23, 2024 at 03:33:36PM +0200, Jan Beulich wrote:
> On 23.04.2024 15:12, Roger Pau Monne wrote:
> > It's incorrect to restrict strncmp to the length of the command line input
> > parameter, as then a user passing a rune like:
> >
> > % xen-livepatch up foo.livepatch
> >
> > Would
On 23.04.2024 15:12, Roger Pau Monne wrote:
> Ensure the entries of a payload exception table only apply to text regions in
> the payload itself. Since the payload exception table needs to be loaded and
> active even before a patch is applied (because hooks might already rely on
> it),
> make
On 23.04.2024 15:12, Roger Pau Monne wrote:
> Livepatch payloads containing symbols that belong to init sections can only
> lead to page faults later on, as by the time the livepatch is loaded init
> sections have already been freed.
>
> Refuse to resolve such symbols and return an error instead.
On 23.04.2024 15:12, Roger Pau Monne wrote:
> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -2125,7 +2125,8 @@ int livepatch_op(struct xen_sysctl_livepatch_op
> *livepatch)
> {
> int rc;
>
> -if ( livepatch->pad )
> +if ( livepatch->flags & ~LIVEPATCH_FLAGS_MASK
On 23.04.2024 15:12, Roger Pau Monne wrote:
> It's incorrect to restrict strncmp to the length of the command line input
> parameter, as then a user passing a rune like:
>
> % xen-livepatch up foo.livepatch
>
> Would match against the "upload" command, because the string comparison has
> been
Hi Julien,
> On 23 Apr 2024, at 14:37, Bertrand Marquis wrote:
>
> Hi Julien,
>
>> On 23 Apr 2024, at 13:05, Julien Grall wrote:
>>
>>
>>
>> On 23/04/2024 10:35, Jens Wiklander wrote:
>>> Hi Julien,
>>
>> Hi Jens,
>>
>>> On Mon, Apr 22, 2024 at 12:57 PM Julien Grall wrote:
Hi
On Tue, Apr 23, 2024 at 02:25:16PM +0200, Jan Beulich wrote:
> On 19.04.2024 12:02, Roger Pau Monne wrote:
> Then I wonder why it was this rather than ...
>
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -5,6 +5,7 @@
> > #include
> > #include
> > #include
> > +#include
It's incorrect to restrict strncmp to the length of the command line input
parameter, as then a user passing a rune like:
% xen-livepatch up foo.livepatch
Would match against the "upload" command, because the string comparison has
been truncated to the length of the input argument. Instead the
Livepatch payloads containing symbols that belong to init sections can only
lead to page faults later on, as by the time the livepatch is loaded init
sections have already been freed.
Refuse to resolve such symbols and return an error instead.
Note such resolutions are only relevant for symbols
Ensure the entries of a payload exception table only apply to text regions in
the payload itself. Since the payload exception table needs to be loaded and
active even before a patch is applied (because hooks might already rely on it),
make sure the exception table (if any) only contains fixups
Introduce a xen-livepatch tool --force option, that's propagated into the
hyerpvisor for livepatch operations. The intention is for the option to be
used to bypass some checks that would otherwise prevent the patch from being
loaded.
Re purpose the pad field in xen_sysctl_livepatch_op to be a
Hello,
Following series contain some minor bugfixes and improvements for
livepatch logic, both inside the hypervisor and on the command line
tool.
Thanks, Roger.
Roger Pau Monne (4):
xen-livepatch: fix parameter name parsing
livepatch: introduce --force option
livepatch: refuse to resolve
Hello,
I am introducing a proposal for a PV-IOMMU hypercall interface.
Some operating systems want to use IOMMU to implement various features (e.g
VFIO) or DMA protection. This proposal aims to provide to guests (notably Dom0)
a way to access a paravirtualized one.
This proposal is based on
Hello,
This RFC patch introduce a design proposal for changes in the IOMMU subsystem
to allow existence of "IOMMU contexts" (aka hardware IOMMU domains) within
a single Xen domain.
In addition to this, redesign and simplify the existing Xen IOMMU subsystem
with these new uses in mind, using IOMMU
flight 185765 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185765/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 185433
build-arm64-xsm
Hi Julien,
> On 23 Apr 2024, at 13:05, Julien Grall wrote:
>
>
>
> On 23/04/2024 10:35, Jens Wiklander wrote:
>> Hi Julien,
>
> Hi Jens,
>
>> On Mon, Apr 22, 2024 at 12:57 PM Julien Grall wrote:
>>>
>>> Hi Jens,
>>>
>>> On 22/04/2024 08:37, Jens Wiklander wrote:
Updates so
On 19.04.2024 12:02, Roger Pau Monne wrote:
> Start by declaring the beginning and end of the init section.
>
> No functional change intended.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
> ---
> xen/arch/arm/mmu/setup.c | 3 +--
> xen/arch/x86/setup.c | 3 +--
>
The PVH entry is available for 32-bit KVM guests, and 32-bit KVM guests
do not depend on CONFIG_X86_PAE. However, mk_early_pgtbl_32() builds
different pagetables depending on whether CONFIG_X86_PAE is set.
Therefore, enabling PAE mode for 32-bit KVM guests without
CONFIG_X86_PAE being set would
On 23/04/2024 10:35, Jens Wiklander wrote:
Hi Julien,
Hi Jens,
On Mon, Apr 22, 2024 at 12:57 PM Julien Grall wrote:
Hi Jens,
On 22/04/2024 08:37, Jens Wiklander wrote:
Updates so request_irq() can be used with a dynamically assigned SGI irq
as input. This prepares for a later patch
On 23.04.2024 12:27, Andrew Cooper wrote:
> On 23/04/2024 10:17 am, Jan Beulich wrote:
>> On 22.04.2024 20:14, Andrew Cooper wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/x86_emulate/decode-lite.c
>>> @@ -0,0 +1,245 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +
>>> +#include
1 - 100 of 127 matches
Mail list logo
