flight 168830 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168830/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 168816
Tests which did not succeed,
flight 168834 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168834/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168828 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168828/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168791
test-armhf-armhf-libvirt 16 sav
flight 168832 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168832/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Stefano,
> -Original Message-
> From: Xen-devel On Behalf Of
> Stefano Stabellini
> Sent: 2022年3月25日 9:01
> To: xen-devel@lists.xenproject.org
> Cc: jul...@xen.org; sstabell...@kernel.org; Bertrand Marquis
> ; volodymyr_babc...@epam.com; Stefano Stabellini
>
> Subject: [PATCH] xen/arm
On Thu, 24 Mar 2022, Bertrand Marquis wrote:
> cppcheck can be used to check Xen code quality.
>
> To create a report do "make cppcheck" on a built tree adding any options
> you added during the process you used to build xen (like CROSS_COMPILE
> or XEN_TARGET_ARCH). This will generate an xml repo
flight 168831 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168831/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
# Proposal for Porting Xen to Armv8-R64
This proposal will introduce the PoC work of porting Xen to Armv8-R64,
which includes:
- The changes of current Xen capability, like Xen build system, memory
management, domain management, vCPU context switch.
- The expanded Xen capability, like static-all
On 3/24/22 18:21, Marek Marczykowski-Górecki wrote:
> On Thu, Mar 24, 2022 at 11:49:14AM -0400, Demi Marie Obenour wrote:
>> On 3/24/22 10:11, Roger Pau Monné wrote:
>>> On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
As per private discussion with Theo de Raadt, OpenBSD do
From: Stefano Stabellini
The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
kernel, certain versions of Linux will use an UNPREDICATABLE NOP
encoding, sometimes resulting in an unbootable kernel. Whether the
resulting kernel is bootable or not depends on the processor. See c
On Wed, 23 Mar 2022, Jan Beulich wrote:
> On 23.03.2022 01:22, Stefano Stabellini wrote:
> > On Tue, 15 Mar 2022, Daniel P. Smith wrote:
> >> On 1/28/22 16:33, Stefano Stabellini wrote:
> >>> From: Luca Miccio
> >>>
> >>> The xenstore event channel will be allocated for dom0less domains. It is
> >
flight 168825 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168825/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168815
test-armhf-armhf-libvirt 16 save
On Thu, Mar 24, 2022 at 11:49:14AM -0400, Demi Marie Obenour wrote:
> On 3/24/22 10:11, Roger Pau Monné wrote:
> > On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
> >> As per private discussion with Theo de Raadt, OpenBSD does not consider
> >> bugs in its xnf(4) that allow a ba
flight 168829 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168829/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168827 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Thu, Mar 24, 2022 at 12:44 PM Roger Pau Monné wrote:
>
> On Thu, Mar 24, 2022 at 12:22:49PM -0400, Tamas K Lengyel wrote:
> > On Thu, Mar 24, 2022 at 12:04 PM Roger Pau Monné
> > wrote:
> > >
> > > On Thu, Mar 24, 2022 at 11:52:38AM -0400, Tamas K Lengyel wrote:
> > > > On Thu, Mar 24, 2022 a
On Thu, Mar 24, 2022 at 12:22:49PM -0400, Tamas K Lengyel wrote:
> On Thu, Mar 24, 2022 at 12:04 PM Roger Pau Monné wrote:
> >
> > On Thu, Mar 24, 2022 at 11:52:38AM -0400, Tamas K Lengyel wrote:
> > > On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Tue, Mar 22,
flight 168826 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168826/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Thu, Mar 24, 2022 at 11:51 AM Roger Pau Monné wrote:
>
> On Thu, Mar 24, 2022 at 11:15:08AM -0400, Tamas K Lengyel wrote:
> > On Thu, Mar 24, 2022 at 10:50 AM Roger Pau Monné
> > wrote:
> > >
> > > On Tue, Mar 22, 2022 at 01:41:37PM -0400, Tamas K Lengyel wrote:
> > > > Add option to the fork
On Thu, Mar 24, 2022 at 12:04 PM Roger Pau Monné wrote:
>
> On Thu, Mar 24, 2022 at 11:52:38AM -0400, Tamas K Lengyel wrote:
> > On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné
> > wrote:
> > >
> > > On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> > > > diff --git a/xen/inclu
On Thu, Mar 24, 2022 at 11:52:38AM -0400, Tamas K Lengyel wrote:
> On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné wrote:
> >
> > On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> > > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > > index 208d8dcbd9..3
On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné wrote:
>
> On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index 208d8dcbd9..30ce23c5a7 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/includ
On Thu, Mar 24, 2022 at 11:15:08AM -0400, Tamas K Lengyel wrote:
> On Thu, Mar 24, 2022 at 10:50 AM Roger Pau Monné wrote:
> >
> > On Tue, Mar 22, 2022 at 01:41:37PM -0400, Tamas K Lengyel wrote:
> > > Add option to the fork memop to skip populating the fork with special
> > > pages.
> > > These
On 3/24/22 10:11, Roger Pau Monné wrote:
> On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
>> As per private discussion with Theo de Raadt, OpenBSD does not consider
>> bugs in its xnf(4) that allow a backend to cause mischief to be security
>> issues. I believe the same applie
On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index 208d8dcbd9..30ce23c5a7 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -541,12 +541,14 @@ struct xen_mem_sharing_op {
On 3/22/22 20:22, Stefano Stabellini wrote:
> On Tue, 15 Mar 2022, Daniel P. Smith wrote:
>> On 1/28/22 16:33, Stefano Stabellini wrote:
>>> From: Luca Miccio
>>>
>>> The xenstore event channel will be allocated for dom0less domains. It is
>>> necessary to have access to the evtchn_alloc_unbound f
On Thu, Mar 24, 2022 at 10:50 AM Roger Pau Monné wrote:
>
> On Tue, Mar 22, 2022 at 01:41:37PM -0400, Tamas K Lengyel wrote:
> > Add option to the fork memop to skip populating the fork with special pages.
> > These special pages are only necessary when setting up forks to be fully
> > functional
flight 168821 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168821/
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, Mar 22, 2022 at 01:41:37PM -0400, Tamas K Lengyel wrote:
> Add option to the fork memop to skip populating the fork with special pages.
> These special pages are only necessary when setting up forks to be fully
> functional with a toolstack. For short-lived forks where no toolstack is
> ac
flight 168824 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168824/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
> As per private discussion with Theo de Raadt, OpenBSD does not consider
> bugs in its xnf(4) that allow a backend to cause mischief to be security
> issues. I believe the same applies to its xbf(4). Should the support
> documen
Introduce a way to create different cpupools at boot time, this is
particularly useful on ARM big.LITTLE system where there might be the
need to have different cpupools for each type of core, but also
systems using NUMA can have different cpu pools for each node.
The feature on arm relies on a spe
Currently cpupool0 can use only the default scheduler, and
cpupool_create has an hardcoded behavior when creating the pool 0
that doesn't allocate new memory for the scheduler, but uses the
default scheduler structure in memory.
With this commit it is possible to allocate a different scheduler for
Introduce domain-cpupool property of a xen,domain device tree node,
that specifies the cpupool device tree handle of a xen,cpupool node
that identifies a cpupool created at boot time where the guest will
be assigned on creation.
Add member to the xen_domctl_createdomain public interface so the
XEN
With the introduction of boot time cpupools, Xen can create many
different cpupools at boot time other than cpupool with id 0.
Since these newly created cpupools can't have an
entry in Xenstore, create the entry using xen-init-dom0
helper with the usual convention: Pool-.
Given the change, remove
Add a static function to retrieve the scheduler pointer using the
scheduler name.
Add a public function to retrieve the scheduler id by the scheduler
name that makes use of the new static function.
Take the occasion to replace open coded scheduler search with the
new static function in scheduler_
This serie introduces a feature for Xen to create cpu pools at boot time, the
feature is enabled using a configurable that is disabled by default.
The boot time cpupool feature relies on the device tree to describe the cpu
pools.
Another feature is introduced by the serie, the possibility to assign
Create new public function to create cpupools, can take as parameter
the scheduler id or a negative value that means the default Xen
scheduler will be used.
Signed-off-by: Luca Fancellu
---
Changes in v4:
- no changes
Changes in v3:
- Fixed comment (Andrew)
Changes in v2:
- cpupool_create_pool do
flight 168818 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168818/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.
This makes the calls of the handlers type safe.
For deprecated hypercalls define stub functions.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Tested-by: Michal Orzel
---
V2:
-
Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.
This is beneficial to performance and avoids speculation issues.
With calling the handlers using the correct number of parameters now
it is possible to do the parameter register clobbering i
Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel P. Smith # xsm parts
Acked-by: Jan Beulich
Tested-by: Téo Couprie Diaz
---
V4:
- new patch
---
xen/arch/x8
Remove the hypercall handler's prototypes in the related header files
and use the generated ones instead.
Some handlers having been static before need to be made globally
visible.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Acked-by: Julien Grall
---
xen/arch/arm/include/asm/hypercall.
Instead of including asm/hypercall.h always use xen/hypercall.h.
Additionally include xen/hypercall.h from all sources containing a
hypercall handler.
This prepares for generating the handlers' prototypes at build time.
Add a guard in asm/hypercall.h to catch direct inclusion.
Signed-off-by: Jue
The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common handler. This leads to the
weird call hierarchy:
do_arm_v
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 used add generating
a macro for populating an array with the number of parameters per
The definition of compat_platform_op_t is in compat/platform.h
already, so include that file from hypercall.h instead of repeating
the typedef.
This allows to remove the related include statement from
arch/x86/x86_64/platform_hypercall.c.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
V
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 array
by automatically generated call macros.
Another by-product of generating the call macros is
Today most hypercall handlers have a return type of long, while the
compat ones return an int. There are a few exceptions from that rule,
however.
Get rid of the exceptions by letting compat handlers always return int
and others always return long, with the exception of the Arm specific
physdev_op
On 24.03.2022 12:19, Juergen Gross wrote:
> On 24.03.22 11:57, Jan Beulich wrote:
>> On 24.03.2022 09:13, Juergen Gross wrote:
>>> Today most hypercall handlers have a return type of long, while the
>>> --- a/xen/arch/x86/x86_64/platform_hypercall.c
>>> +++ b/xen/arch/x86/x86_64/platform_hypercall.
As per private discussion with Theo de Raadt, OpenBSD does not consider
bugs in its xnf(4) that allow a backend to cause mischief to be security
issues. I believe the same applies to its xbf(4). Should the support
document be updated?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Thi
When the data abort is caused due to cache maintenance for an address,
there are three scenarios:-
1. Address belonging to a non emulated region - For this, Xen should
set the corresponding bit in the translation table entry to valid and
return to the guest to retry the instruction. This can happe
flight 168823 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168823/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 24.03.2022 14:06, Andrew Cooper wrote:
> On 24/03/2022 11:04, Bertrand Marquis wrote:
>> cppcheck can be used to check Xen code quality.
>>
>> To create a report do "make cppcheck" on a built tree adding any options
>> you added during the process you used to build xen (like CROSS_COMPILE
>>
Hi Andrew,
> On 24 Mar 2022, at 14:06, Andrew Cooper wrote:
>
> On 24/03/2022 11:04, Bertrand Marquis wrote:
>> cppcheck can be used to check Xen code quality.
>>
>> To create a report do "make cppcheck" on a built tree adding any options
>> you added during the process you used to build xen (l
On 24/03/2022 11:04, Bertrand Marquis wrote:
> cppcheck can be used to check Xen code quality.
>
> To create a report do "make cppcheck" on a built tree adding any options
> you added during the process you used to build xen (like CROSS_COMPILE
> or XEN_TARGET_ARCH). This will generate an xml repor
Hi Julien,
> On 24 Mar 2022, at 13:00, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 24/03/2022 11:04, Bertrand Marquis wrote:
>> cppcheck can be used to check Xen code quality.
>
> Is there anything we should be concerned of in the initial report?
Nothing major no.
Michal will soon push a seri
flight 168816 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168816/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168807
test-armhf-armhf-libvirt 16 saver
On Wed 23-03-22 14:04:04, Jason Gunthorpe wrote:
> On Wed, Mar 23, 2022 at 05:49:43PM +0100, Michal Hocko wrote:
> > > The bug here is that prior to commit a81461b0546c ("xen/gntdev: update
> > > to new mmu_notifier semantic") wired the mn_invl_range_start() which
> > > takes a mutex to invalidate_
On 23/03/2022 15:43, Rahul Singh wrote:
in dom0less system. This patch introduce the new feature to support the
signaling between two domUs in dom0less system.
Signed-off-by: Rahul Singh
---
docs/designs/dom0less-evtchn.md | 96 +
1 file changed, 96 inserti
flight 168822 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168822/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Bertrand,
On 24/03/2022 11:04, Bertrand Marquis wrote:
cppcheck can be used to check Xen code quality.
Is there anything we should be concerned of in the initial report?
To create a report do "make cppcheck" on a built tree adding any options
you added during the process you used to buil
Hello Jan,
Thanks for reviewing the design.
> On 23 Mar 2022, at 4:07 pm, Jan Beulich wrote:
>
> On 23.03.2022 16:43, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less system.
>>
>> Signed-off-by: Rahul Sing
flight 168820 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168820/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168815 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168815/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168794
test-armhf-armhf-libvirt 16 save
On 24.03.22 11:57, Jan Beulich wrote:
On 24.03.2022 09:13, Juergen Gross wrote:
Today most hypercall handlers have a return type of long, while the
--- a/xen/arch/x86/x86_64/platform_hypercall.c
+++ b/xen/arch/x86/x86_64/platform_hypercall.c
@@ -4,6 +4,7 @@
EMIT_FILE;
+#include
#incl
cppcheck can be used to check Xen code quality.
To create a report do "make cppcheck" on a built tree adding any options
you added during the process you used to build xen (like CROSS_COMPILE
or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml.
To create a html report do "make
On 24.03.2022 09:13, Juergen Gross wrote:
> Today most hypercall handlers have a return type of long, while the
> --- a/xen/arch/x86/x86_64/platform_hypercall.c
> +++ b/xen/arch/x86/x86_64/platform_hypercall.c
> @@ -4,6 +4,7 @@
>
> EMIT_FILE;
>
> +#include
> #include
> #include
> #includ
Hi Juergen,
On 24/03/2022 08:13, Juergen Gross wrote:
The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common han
Hi Stefano,
Thanks a lot for the detailed answers.
> On 24 Mar 2022, at 03:05, Stefano Stabellini wrote:
>
> On Wed, 23 Mar 2022, Bertrand Marquis wrote:
>>> On 22 Mar 2022, at 21:28, Stefano Stabellini wrote:
>>>
>>> From: Stefano Stabellini
>>>
>>> The first 32 bytes of zImage are NOPs. W
do_physdev_op() prototypes on Arm and x86 differ in their return type,
so rename the Arm one in order to prepare using a common generated
header file.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
---
V4:
- new patch
---
xen/arch/arm/include/asm/hypercall.h | 2 +-
xen/arch/arm/physdev.c
Remove the hypercall handler's prototypes in the related header files
and use the generated ones instead.
Some handlers having been static before need to be made globally
visible.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Acked-by: Julien Grall
---
xen/arch/arm/include/asm/hypercall.
Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel P. Smith # xsm parts
Acked-by: Jan Beulich
Tested-by: Téo Couprie Diaz
---
V4:
- new patch
---
xen/arch/x8
Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.
This makes the calls of the handlers type safe.
For deprecated hypercalls define stub functions.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Tested-by: Michal Orzel
---
V2:
-
The definition of compat_platform_op_t is in compat/platform.h
already, so include that file from hypercall.h instead of repeating
the typedef.
This allows to remove the related include statement from
arch/x86/x86_64/platform_hypercall.c.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
V
Instead of using a function table use the generated macros for calling
the appropriate hypercall handlers.
This is beneficial to performance and avoids speculation issues.
With calling the handlers using the correct number of parameters now
it is possible to do the parameter register clobbering i
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 used add generating
a macro for populating an array with the number of parameters per
Instead of including asm/hypercall.h always use xen/hypercall.h.
Additionally include xen/hypercall.h from all sources containing a
hypercall handler.
This prepares for generating the handlers' prototypes at build time.
Add a guard in asm/hypercall.h to catch direct inclusion.
Signed-off-by: Jue
Today most hypercall handlers have a return type of long, while the
compat ones return an int. There are a few exceptions from that rule,
however.
Get rid of the exceptions by letting compat handlers always return int
and others always return long, with the exception of the Arm specific
physdev_op
The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common handler. This leads to the
weird call hierarchy:
do_arm_v
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 array
by automatically generated call macros.
Another by-product of generating the call macros is
81 matches
Mail list logo
