On Mon, Nov 08, 2021 at 10:37:31AM +, Julien Grall wrote:
Hi Julien,
> Hi Vikram,
>
> On 05/11/2021 21:28, Vikram Garhwal wrote:
> >Update libfdt to v1.6.1 of libfdt taken from git://github.com/dgibson/dtc.
> >This update is done to support device tree overlays.
> >
> >A few minor changes are
Add remove_device callback for removing the device entry from smmu-master using
following steps:
1. Find if SMMU master exists for the device node.
2. Remove the SMMU master
Signed-off-by: Vikram Garhwal
---
xen/drivers/passthrough/device_tree.c | 30 ++
xen/
Introduce sysctl XEN_SYSCTL_overlay to remove device-tree nodes added using
device tree overlay.
xl overlay remove file.dtbo:
Removes all the nodes in a given dtbo.
First, removes IRQ permissions and MMIO accesses. Next, it finds the nodes
in dt_host and delete the device node entries
Add fdt_ prefix to overlay_get_target() and remove static type. This is done to
get the target path for all the overlay nodes. This is useful to find which
nodes are to be added/removed in dt_host.
Also, sending this patch to dtc mailing list to avoid the divergence.
Signed-off-by: Vikram Garhwal
Add remove_device callback for removing the device entry from smmu-master using
following steps:
1. Find if SMMU master exists for the device node.
2. Remove the SMMU master
Signed-off-by: Vikram Garhwal
---
xen/drivers/passthrough/arm/smmu.c | 54 ++
1 file c
xc_dt_overlay() sends the device tree binary overlay, size of .dtbo and overlay
operation type i.e. add or remove to xen.
Signed-off-by: Vikram Garhwal
---
tools/include/xenctrl.h | 5 +
tools/libs/ctrl/Makefile | 1 +
tools/libs/ctrl/xc_overlay.c | 51
Signed-off-by: Vikram Garhwal
---
xen/arch/arm/Kconfig | 8
1 file changed, 8 insertions(+)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index ecfa682..895f0ee 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -46,6 +46,14 @@ config HAS_ITS
bool "GICv3
This is done to access fdt library function which are required for adding device
tree overlay nodes for dynamic programming of nodes.
Signed-off-by: Vikram Garhwal
---
xen/common/libfdt/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt
Signed-off-by: Vikram Garhwal
---
tools/xl/xl.h | 8
tools/xl/xl_cmdtable.c | 8
tools/xl/xl_vmcontrol.c | 47 +++
3 files changed, 63 insertions(+)
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 7e23f30..2ee75a0 100644
Signed-off-by: Vikram Garhwal
---
tools/include/libxl.h| 5
tools/libs/light/Makefile| 3 ++
tools/libs/light/libxl_overlay.c | 65
3 files changed, 73 insertions(+)
create mode 100644 tools/libs/light/libxl_overlay.c
diff --gi
Change function type of following function to access during runtime:
1. map_irq_to_domain()
2. handle_device_interrupt()
3. map_range_to_domain()
4. unflatten_dt_node()
5. unflatten_device_tree()
Move map_irq_to_domain(), handle_device_interrupt() and map_range_to_domain() to
d
Hi,
This RFC patch series is for introducing dynamic programming i.e. add/remove the
devices during run time. Using "xl overlay" a device can be added/removed with
dtbo.
For adding a node using dynamic programming:
1. flatten device tree overlay node will be added to a fdt
2. Updated fdt
Update sysctl XEN_SYSCTL_overlay to enable support for dtbo nodes addition using
device tree overlay.
xl overlay add file.dtbo:
Each time overlay nodes are added using .dtbo, a new fdt(memcpy of
device_tree_flattened) is created and updated with overlay nodes. This
updated fdt is furth
Add _dt_find_by_path() to find a matching node with path for a dt_device_node.
Signed-off-by: Vikram Garhwal
---
xen/common/device_tree.c | 10 --
xen/include/xen/device_tree.h | 9 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/xen/common/device_tree.c b
flight 166090 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166090/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8c1b1fe634a233ad7570f2243027d6be8a7849a1
baseline version:
ovmf fd42dcb1fc416b85bbbee
flight 166086 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166086/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 8 xen-boot fail REGR. vs. 165976
test-armhf-armhf-li
Hi,
Really sorry for late. I saw this patch in my mailbox just before. Seems I
missed it due to a typo, exynox.
I will review and apply this patch ASAP.
Thanks,
Inki Dae
21. 11. 8. 오후 7:28에 Thomas Zimmermann 이(가) 쓴 글:
> Moving the driver-specific mmap code into a GEM object function allows
> fo
On Mon, 8 Nov 2021, Jan Beulich wrote:
> On 05.11.2021 16:33, Stefano Stabellini wrote:
> > On Fri, 5 Nov 2021, Jan Beulich wrote:
> >> On 04.11.2021 22:50, Stefano Stabellini wrote:
> >>> On Thu, 4 Nov 2021, Luca Fancellu wrote:
> > On 4 Nov 2021, at 21:35, Stefano Stabellini
> > wrote:
From: Stefano Stabellini
DomUs static-mem ranges are added to the reserved_mem array for
accounting, but they shouldn't be assigned to dom0 as the other regular
reserved-memory ranges in device tree.
In make_memory_nodes, fix the error by skipping banks with xen_domain
set to true in the reserve
On Sat, 6 Nov 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 05/11/2021 23:05, Stefano Stabellini wrote:
> > On Fri, 5 Nov 2021, Stefano Stabellini wrote:
> > > On Fri, 5 Nov 2021, Stefano Stabellini wrote:
> > > > The scenario is extremely simple; you can see the full device tree
> > > > configur
flight 166087 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166087/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fd42dcb1fc416b85bbbee1d546abfb7ac758b5c1
baseline version:
ovmf b5d4a35d90771ec86ce9c
Hi Oleksandr, Julien,
I discovered a bug caused by the recent changes to introduce extended
regions in make_hypervisor_node (more logs appended):
(XEN) d1 BANK[0] 0x004000-0x007e80 (1000MB)
(XEN) d1 BANK[1] 0x02-0x02 (0MB)
(XEN) DEBUG find_unallocated_memo
flight 166084 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166084/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 166075
test-armhf-armhf-libvirt 16 sav
On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
> Is there really any reason for returning an error code? For example, is
> it anticipated that at some point in the future these registration calls
> might fail?
>
> Currently, the only reason for failing...
Right, I believe with not
flight 166085 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166085/
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 Mon, Nov 08, 2021 at 05:21:45PM +0100, Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 05:12:16PM +0100, Geert Uytterhoeven wrote:
> > Returning void is the other extreme ;-)
> >
> > There are 3 levels (ignoring BUG_ON()/panic () inside the callee):
> > 1. Return void: no one can check succe
Hi Roman,
On 04/10/2021 10:54, Roman Skakun wrote:
From: Roman Skakun
Xen is not exposing any IOMMU properties to Dom0.
So Dom0 assumes that all it's devices are not protected by IOMMU.
To make Dom0 aware of IOMMU-protected devices, we need to mark
them somehow. With this approach Dom0 Linux
Xen 4.16 RC2 is now available.
It is available from git:
git clone https://xenbits.xenproject.org/git-http/xen.git -b 4.16.0-rc2
For your convenience a tarball is available:
https://downloads.xenproject.org/release/xen/4.16.0-rc2/xen-4.16.0-rc2.tar.gz
https://downloads.xenproject.org/relea
flight 166079 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166079/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 8 xen-boot fail REGR. vs. 165976
test-armhf-armhf-xl
On 11/8/21 10:11 AM, Peter Zijlstra wrote:
On Tue, Nov 02, 2021 at 07:36:36PM -0400, Boris Ostrovsky wrote:
Commit 66558b730f25 ("sched: Add cluster scheduler level for x86")
introduced cpu_l2c_shared_map mask which is expected to be initialized
by smp_op.smp_prepare_cpus(). That commit only u
On Mon, Nov 08, 2021 at 11:23:13AM -0500, Steven Rostedt wrote:
> Question, how often does this warning trigger? Is it common to see in
> development?
Yeah, haven't seen it myself yet.
But we hashed it out over IRC. :-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-ne
On 08.11.21 12:14, Arnd Bergmann wrote:
From: Arnd Bergmann
In configurations with CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=n
and CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y, gcc warns about an
unused variable:
drivers/xen/balloon.c:83:12: error: 'xen_hotplug_unpopulated' defined but not
used [-Werror=unuse
On Mon, 8 Nov 2021 15:35:50 +0100
Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote:
> > I guess I can add another indirection to notifier_chain_register() and
> > avoid touching all the call sites.
>
> IOW, something like this below.
>
> This way I won'
On Mon, Nov 08, 2021 at 05:12:16PM +0100, Geert Uytterhoeven wrote:
> Returning void is the other extreme ;-)
>
> There are 3 levels (ignoring BUG_ON()/panic () inside the callee):
> 1. Return void: no one can check success or failure,
> 2. Return an error code: up to the caller to decide,
>
Hi Borislav,
On Mon, Nov 8, 2021 at 4:59 PM Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 04:25:47PM +0100, Geert Uytterhoeven wrote:
> > I'm not against returning proper errors codes. I'm against forcing
> > callers to check things that cannot fail and to add individual error
> > printing to
On Mon, Nov 08, 2021 at 04:25:47PM +0100, Geert Uytterhoeven wrote:
> I'm not against returning proper errors codes. I'm against forcing
> callers to check things that cannot fail and to add individual error
> printing to each and every caller.
If you're against checking things at the callers, th
On Mon, Nov 08, 2021 at 11:28:44AM +0100, Thomas Zimmermann wrote:
> Moving the driver-specific mmap code into a GEM object function allows
> for using DRM helpers for various mmap callbacks.
>
> The respective exynos functions are being removed. The file_operations
> structure exynos_drm_driver_f
On 08.11.21 16:23, Roger Pau Monné wrote:
> On Mon, Nov 08, 2021 at 11:16:42AM +, Oleksandr Andrushchenko wrote:
>>
>> On 08.11.21 13:10, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
--- a/xen/arch/arm/vpci.c
+++ b/xen/arch/arm/vpci.c
@@ -41,6 +41,
Hi Borislav,
On Mon, Nov 8, 2021 at 3:21 PM Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 03:07:03PM +0100, Geert Uytterhoeven wrote:
> > I think the addition of __must_check is overkill, leading to the
> > addition of useless error checks and message printing.
>
> See the WARN in notifier_cha
On 08.11.2021 16:04, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2 1/6][4.16?] x86/x2APIC: defer probe until
> after IOMMU ACPI table parsing"):
>> On 05.11.2021 16:47, Ian Jackson wrote:
>>> This part confused me. Under what circumstances would we backport
>>> this ? AIUI it would be
I have collected the acks and pushed these.
While doing so I found this in the thread:
Ian Jackson writes ("Re: [PATCH for-4.16 v6] gnttab: allow setting max version
per-domain"):
> Roger Pau Monne writes ("[PATCH for-4.16 v6] gnttab: allow setting max
> version per-domain"):
> > NB: the stubdo
On Tue, Nov 02, 2021 at 07:36:36PM -0400, Boris Ostrovsky wrote:
> Commit 66558b730f25 ("sched: Add cluster scheduler level for x86")
> introduced cpu_l2c_shared_map mask which is expected to be initialized
> by smp_op.smp_prepare_cpus(). That commit only updated
> native_smp_prepare_cpus() version
On Mon, Nov 08, 2021 at 03:00:57PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH for-4.16 v6] gnttab: allow setting max
> version per-domain"):
> > This needs to be applied on top of Andrew's:
> >
> > xen: Report grant table v1/v2 capabilities to the toolstack
> > https://lore.kerne
Jan Beulich writes ("Re: [PATCH v2 1/6][4.16?] x86/x2APIC: defer probe until
after IOMMU ACPI table parsing"):
> On 05.11.2021 16:47, Ian Jackson wrote:
> > This part confused me. Under what circumstances would we backport
> > this ? AIUI it would be backporting a potentially-fragile and
> > not
Roger Pau Monne writes ("[PATCH for-4.16 v6] gnttab: allow setting max version
per-domain"):
> This needs to be applied on top of Andrew's:
>
> xen: Report grant table v1/v2 capabilities to the toolstack
> https://lore.kernel.org/xen-devel/20211029173813.23002-1-andrew.coop...@citrix.com/
OK. T
On Mon, Nov 08, 2021 at 02:46:39PM +, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH for-4.16 v6] gnttab: allow setting max
> version per-domain"):
> > Overall I think it's best to
> > express supported grant versions independently, and we might wish to
> > also allow to select a di
On 08.11.2021 15:42, Juergen Gross wrote:
> On 03.11.21 16:42, Jan Beulich wrote:
>> On 03.11.2021 11:20, Juergen Gross wrote:
>>> +# Generate the output
>>> +END {
>>> +# Verbatim generated lines
>>> +for (i = 1; i <= e; i++)
>>> +printf("%s\n", emit[i]);
>>> +printf("\n");
>>>
Roger Pau Monné writes ("Re: [PATCH for-4.16 v6] gnttab: allow setting max
version per-domain"):
> Overall I think it's best to
> express supported grant versions independently, and we might wish to
> also allow to select a discrete set of grant versions that a domain
> supports. IMO it might be
On 03.11.21 16:42, Jan Beulich wrote:
On 03.11.2021 11:20, Juergen Gross wrote:
Instead of repeating similar data multiple times use a single source
file and a generator script for producing prototypes and call sequences
of the hypercalls.
As the script already knows the number of parameters us
On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote:
> I guess I can add another indirection to notifier_chain_register() and
> avoid touching all the call sites.
IOW, something like this below.
This way I won't have to touch all the callsites and the registration
routines would still
On Mon, Nov 08, 2021 at 09:17:03AM -0500, Alan Stern wrote:
> What reason is there for moving the check into the callers? It seems
> like pointless churn. Why not add the error return code, change the
> WARN to pr_warn, and leave the callers as they are? Wouldn't that end
> up having exactly
On Mon, Nov 08, 2021 at 11:16:42AM +, Oleksandr Andrushchenko wrote:
>
>
> On 08.11.21 13:10, Jan Beulich wrote:
> > On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> >> --- a/xen/arch/arm/vpci.c
> >> +++ b/xen/arch/arm/vpci.c
> >> @@ -41,6 +41,15 @@ static int vpci_mmio_read(struct vcpu
On Mon, Nov 08, 2021 at 03:07:03PM +0100, Geert Uytterhoeven wrote:
> I think the addition of __must_check is overkill, leading to the
> addition of useless error checks and message printing.
See the WARN in notifier_chain_register() - it will already do "message
printing".
> Many callers call th
On Mon, Nov 08, 2021 at 11:19:24AM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Hi all,
>
> this is a huge patchset for something which is really trivial - it
> changes the notifier registration routines to return an error value
> if a notifier callback is already present on the res
Hi Borislav,
On Mon, Nov 8, 2021 at 11:13 AM Borislav Petkov wrote:
> From: Borislav Petkov
>
> The notifier registration routine doesn't return a proper error value
> when a callback has already been registered, leading people to track
> whether that registration has happened at the call site:
On 08.11.21 09:36, Jan Beulich wrote:
On 05.11.2021 15:18, Andrew Cooper wrote:
On 01/11/2021 15:20, Juergen Gross wrote:
In order to avoid indirect function calls on the hypercall path as
much as possible this series is removing the hypercall function tables
and is replacing the hypercall hand
flight 166080 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166080/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-credit2 8 xen-boot fail pass in 166073
Tests which did not succeed, but
On Mon, Nov 08, 2021 at 12:40:59PM +0100, Jan Beulich wrote:
> While commit 46c4061cd2bf ("x86/IOMMU: mark IOMMU / intremap not in use
> when ACPI tables are missing") deals with apic_x2apic_probe() as called
> from x2apic_bsp_setup(), the check_x2apic_preenabled() path is similarly
> affected: The
While commit 46c4061cd2bf ("x86/IOMMU: mark IOMMU / intremap not in use
when ACPI tables are missing") deals with apic_x2apic_probe() as called
from x2apic_bsp_setup(), the check_x2apic_preenabled() path is similarly
affected: The call needs to occur after acpi_iommu_init(), such that
iommu_intrema
08.11.2021 14:22, Jonathan Neuschäfer пишет:
> On Sun, Nov 07, 2021 at 08:42:33PM +0300, Dmitry Osipenko wrote:
> [...]
>> EC drivers tend to use higher priority in general. Jonathan, could you
>> please confirm that NTXEC driver is a more preferable restart method
>> than the watchdog?
>
> Yes. T
Hi
Am 08.11.21 um 11:46 schrieb Oleksandr Andrushchenko:
Hi, Thomas!
On 08.11.21 12:28, Thomas Zimmermann wrote:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective xen functions are being removed. The file_op
On Sun, Nov 07, 2021 at 08:42:33PM +0300, Dmitry Osipenko wrote:
[...]
> EC drivers tend to use higher priority in general. Jonathan, could you
> please confirm that NTXEC driver is a more preferable restart method
> than the watchdog?
Yes. The original firmware uses the NTXEC to restart, and it w
On 08.11.2021 12:02, Roger Pau Monné wrote:
> On Fri, Nov 05, 2021 at 01:34:12PM +0100, Jan Beulich wrote:
>> The hook functions have been empty forever (x2APIC) or issuing merely a
>> printk() for a long time (xAPIC). Since that printk() is (a) generally
>> useful (i.e. also in the x2APIC case) an
On 08.11.21 13:10, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> --- a/xen/arch/arm/vpci.c
>> +++ b/xen/arch/arm/vpci.c
>> @@ -41,6 +41,15 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t
>> *info,
>> /* data is needed to prevent a pointer cast on 32bi
From: Arnd Bergmann
In configurations with CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=n
and CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y, gcc warns about an
unused variable:
drivers/xen/balloon.c:83:12: error: 'xen_hotplug_unpopulated' defined but not
used [-Werror=unused-variable]
Since this is always zero whe
On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
> --- a/xen/arch/arm/vpci.c
> +++ b/xen/arch/arm/vpci.c
> @@ -41,6 +41,15 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t
> *info,
> /* data is needed to prevent a pointer cast on 32bit */
> unsigned long data;
>
> +#ifdef CO
flight 166083 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166083/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b5d4a35d90771ec86ce9cf28727f471ee589fb78
baseline version:
ovmf d79df34bebdd87aa01ccf
On Fri, Nov 05, 2021 at 01:34:12PM +0100, Jan Beulich wrote:
> The hook functions have been empty forever (x2APIC) or issuing merely a
> printk() for a long time (xAPIC). Since that printk() is (a) generally
> useful (i.e. also in the x2APIC case) and (b) would better only be
> issued once the fina
Hi, Thomas!
On 08.11.21 12:28, Thomas Zimmermann wrote:
> Moving the driver-specific mmap code into a GEM object function allows
> for using DRM helpers for various mmap callbacks.
>
> The respective xen functions are being removed. The file_operations
> structure fops is now being created by the
Hi Vikram,
On 05/11/2021 21:28, Vikram Garhwal wrote:
Update libfdt to v1.6.1 of libfdt taken from git://github.com/dgibson/dtc.
This update is done to support device tree overlays.
A few minor changes are done to make it compatible with Xen:
fdt_overlay.c: overlay_fixup_phandle()
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective xen functions are being removed. The file_operations
structure fops is now being created by the helper macro
DEFINE_DRM_GEM_FOPS().
Signed-off-by: Thomas Zimmerm
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective exynos functions are being removed. The file_operations
structure exynos_drm_driver_fops is now being created by the helper macro
DEFINE_DRM_GEM_FOPS().
Signed-o
The hook gem_prime_mmap in struct drm_driver is deprecated. Document
the new requirements.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/todo.rst | 11 ---
include/drm/drm_drv.h | 11 +++
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/Documentation/
(Resending the patchset from [1]. Most drivers have already been updated and
only two drivers are left.)
Replace all remaining implementations of struct drm_driver.gem_prime_mmap
with use drm_gem_prime_mmap(). For each affected driver, put the mmap code
into struct drm_gem_object_funcs.mmap. With
From: Borislav Petkov
Hi all,
this is a huge patchset for something which is really trivial - it
changes the notifier registration routines to return an error value
if a notifier callback is already present on the respective list of
callbacks. For more details scroll to the last patch.
Everythi
flight 166082 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166082/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
From: Borislav Petkov
The notifier registration routine doesn't return a proper error value
when a callback has already been registered, leading people to track
whether that registration has happened at the call site:
https://lore.kernel.org/amd-gfx/20210512013058.6827-1-mukul.jo...@amd.com/
From: Borislav Petkov
Avoid homegrown notifier registration checks.
No functional changes.
Signed-off-by: Borislav Petkov
Cc: xen-devel@lists.xenproject.org
---
drivers/xen/manage.c | 3 ++-
drivers/xen/xenbus/xenbus_probe.c | 8 +---
2 files changed, 7 insertions(+), 4 delet
From: Borislav Petkov
Avoid homegrown notifier registration checks.
No functional changes.
Signed-off-by: Borislav Petkov
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/enlighten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/
On 08.11.2021 10:36, Roger Pau Monné wrote:
> On Mon, Nov 08, 2021 at 08:40:59AM +0100, Jan Beulich wrote:
>> On 05.11.2021 16:38, Roger Pau Monné wrote:
>>> On Fri, Nov 05, 2021 at 01:32:18PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1699,6
On 05.11.2021 14:55, Andrew Cooper wrote:
> Currently, __HYPERVISOR_xsm_op enters xsm_ops.do_{xsm,compat}_op() which means
> that if any other XSM module registers a handler, we'll break the hypercall
> ABI totally by having the behaviour depend on the selected XSM module.
>
> There are 2 options:
On Mon, Nov 08, 2021 at 08:40:59AM +0100, Jan Beulich wrote:
> On 05.11.2021 16:38, Roger Pau Monné wrote:
> > On Fri, Nov 05, 2021 at 01:32:18PM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/setup.c
> >> +++ b/xen/arch/x86/setup.c
> >> @@ -1699,6 +1699,13 @@ void __init noreturn __start_xen(un
On 05.11.2021 14:55, Andrew Cooper wrote:
> With alternative_call() capable of handling compound types, the three
> remaining hooks can be optimised at boot time too.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Daniel De Graaf
> CC: Daniel Smith
>
> I'm on the fence as to whether to declare t
On 05.11.2021 14:55, Andrew Cooper wrote:
> +void __init xsm_fixup_ops(struct xsm_ops *ops)
> +{
> +/*
> + * We make some simplifying assumptions about struct xsm_ops; that it is
> + * made exclusively of function pointers to non-init text.
> + *
> + * This allows us to walk ove
flight 166081 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166081/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d79df34bebdd87aa01ccf78f541b4ae4c9f68f74
baseline version:
ovmf 4050c873b51f59cb6fcd7
Hi Jan,
> On 8 Nov 2021, at 08:41, Jan Beulich wrote:
>
> On 05.11.2021 15:43, Bertrand Marquis wrote:
>>> On 4 Nov 2021, at 06:19, Vikram Garhwal wrote:
>>>
>>> Update libfdt to v1.6.1 of libfdt taken from git://github.com/dgibson/dtc.
>>> This update is done to support device tree overlays.
On 05.11.2021 15:43, Bertrand Marquis wrote:
>> On 4 Nov 2021, at 06:19, Vikram Garhwal wrote:
>>
>> Update libfdt to v1.6.1 of libfdt taken from git://github.com/dgibson/dtc.
>> This update is done to support device tree overlays.
>>
>> A few minor changes are done to make it compatible with Xen:
On 05.11.2021 15:18, Andrew Cooper wrote:
> On 01/11/2021 15:20, Juergen Gross wrote:
>> In order to avoid indirect function calls on the hypercall path as
>> much as possible this series is removing the hypercall function tables
>> and is replacing the hypercall handler calls via the function arra
88 matches
Mail list logo
