flight 167466 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167466/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 167452
test-armhf-armhf-libvirt 16 sav
flight 167464 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167464/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 167455
test-amd64-i386-xl
On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:
> This is the implementation of SCI interface, called SCMI-SMC driver,
> which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
> This allows devices from the Domains to work with clocks, resets and
> power-domains without access t
flight 167461 linux-linus real [real]
flight 167469 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167461/
http://logs.test-lab.xenproject.org/osstest/logs/167469/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
flight 167459 linux-5.4 real [real]
flight 167468 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167459/
http://logs.test-lab.xenproject.org/osstest/logs/167468/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd6
On Fri, 17 Dec 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 16/12/2021 21:15, Stefano Stabellini wrote:
> > On Thu, 16 Dec 2021, Stefano Stabellini wrote:
> > > On Thu, 16 Dec 2021, Juergen Gross wrote:
> > > > On 16.12.21 03:10, Stefano Stabellini wrote:
> > > > > On Wed, 15 Dec 2021, Juergen G
On Fri, 17 Dec 2021, Juergen Gross wrote:
> On 17.12.21 11:41, Julien Grall wrote:
> > Hi Juergen,
> >
> > On 17/12/2021 08:50, Juergen Gross wrote:
> > > On 17.12.21 08:45, Jan Beulich wrote:
> > > > On 17.12.2021 06:34, Juergen Gross wrote:
> > > > > On 16.12.21 22:15, Stefano Stabellini wrote:
Hi Thomas,
On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Replace open coded MSI descriptor chasing and use the proper accessor
> functions instead.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorp
flight 167467 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167467/
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
flight 167465 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167465/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ee1f8262b83dd88b30091e6e81221ff299796099
baseline version:
ovmf ab5ab2f60348138a4b7b1
On 17/12/2021 23:34, Daniel P. Smith wrote:
> From: Christopher Clark
>
> There were several instances of open-coded domid range checking. This commit
> replaces those with the is_system_domain inline function.
>
> Signed-off-by: Christopher Clark
> Signed-off-by: Daniel P. Smith
Ah - probably
This commit introduces into x86 start_xen the detection and parsing of a
hyperlaunch DTB file and then using that information to construct the domains
contained in the hyperlaunch configuration.
Signed-off-by: Daniel P. Smith
Reviewed-by: Christopher Clark
---
xen/arch/x86/setup.c | 54
This commit is for the RFC only to enable a quick demonstration of starting Xen
via hyperlaunch. Final version of hyperlaunch will have its own domain
construction function that will replace the RFC usage of create_dom0.
Signed-off-by: Daniel P. Smith
Reviewed-by: Christopher Clark
---
xen/arch
This commit introduces the skeleton of hyperlaunch domain construction
mechanics and adds the preliminary ability to construct dom0.
Signed-off-by: Daniel P. Smith
Reviewed-by: Christopher Clark
---
xen/common/setup.c | 77 +
xen/include/xen/setup.h
This commit implements the parsing of a hyperlaunch device tree. It is
implemented to support a device tree containing any number of Config nodes and
Domain nodes.
RFC Note: Xen supports working with flattened device trees (FDT), DTB files,
and unflattened device trees, in-memory structures. The l
Hyperlaunch builds from dom0less' `struct bootmodule` as the representation of
a boot module provided by a bootloader. From there it expands to cover the
representations proposed in the hyperlaunch design documentation.
Signed-off-by: Daniel P. Smith
Reviewed-by: Christopher Clark
---
xen/inclu
This commit is to update the hyperlaunch device tree documentation to align
with the DTB parsing implementation.
Signed-off-by: Daniel P. Smith
Reviewed-by: Christopher Clark
---
.../designs/launch/hyperlaunch-devicetree.rst | 448 +++---
1 file changed, 278 insertions(+), 170 delet
This commit is purely for RFC to highlight some concerns and changes necessary
in order for hyperlaunch to utilize device tree as the boot configuration
container.
Despite being in common, the core device tree support enabled through
CONFIG_HAS_DEVICE_TREE will not build for an x86 configuration.
Hyperlaunch will require multiple modules to be allocated headroom. Therefore a
headroom variable has been added to module_t for tracking headroom on a per
module_t basis. To provide backwards compatibility with multiboot, the
reserved field was bitfield split to allow it to continue to be used to
From: Christopher Clark
There were several instances of open-coded domid range checking. This commit
replaces those with the is_system_domain inline function.
Signed-off-by: Christopher Clark
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/cpu/vpmu.c | 2 +-
xen/common/domctl.c | 2 +-
xe
From: Christopher Clark
Add a CONFIG_HYPERLAUNCH to allow enabling/disabling the hyperlaunch code
paths. Introduce an initial use of the hyperlaunch_enabled variable to suppress
the warning about multiple initrd candidates when multiboot modules are
detected when the hyperlaunch boolean is true.
This RFC is to provide the base approach of how hyperlaunch would integrate
into the x86 start sequence with the specific intention to vet the
implementation approach early. What this RFC provides is a working
implementation of hyperlaunch for x86 that is capable of strictly starting a
Dom0 configu
On 12/17/21 2:19 PM, Oleksandr wrote:
On 17.12.21 21:13, Boris Ostrovsky wrote:
Hi Boris
On 12/16/21 5:02 PM, Oleksandr wrote:
On 09.12.21 22:05, Oleksandr Tyshchenko wrote:
Hello Juergen, Boris
May I please ask, are you happy (or otherwise) with current patch series (I
assume, espe
On 17.12.21 21:13, Boris Ostrovsky wrote:
Hi Boris
On 12/16/21 5:02 PM, Oleksandr wrote:
On 09.12.21 22:05, Oleksandr Tyshchenko wrote:
Hello Juergen, Boris
May I please ask, are you happy (or otherwise) with current patch
series (I assume, especially with commits #3-4)?
I think I
On 12/16/21 5:02 PM, Oleksandr wrote:
On 09.12.21 22:05, Oleksandr Tyshchenko wrote:
Hello Juergen, Boris
May I please ask, are you happy (or otherwise) with current patch series (I
assume, especially with commits #3-4)?
LGTM, I have no more comments.
-boris
On 12/16/21 5:02 PM, Oleksandr wrote:
On 09.12.21 22:05, Oleksandr Tyshchenko wrote:
Hello Juergen, Boris
May I please ask, are you happy (or otherwise) with current patch series (I
assume, especially with commits #3-4)?
I think I mentioned last time, in patch 4:
+ if (target_r
flight 167462 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167462/
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
flight 167463 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167463/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ab5ab2f60348138a4b7b1c95ad6f5d0954fb96f1
baseline version:
ovmf b451c6908878c448c2a2a
On 17.12.21 17:26, Juergen Gross wrote:
Hi Juergen, all.
On 15.12.21 22:36, Oleksandr wrote:
On 15.12.21 17:58, Juergen Gross wrote:
Hi Juergen
On 15.12.21 16:02, Oleksandr wrote:
On 15.12.21 08:08, Juergen Gross wrote:
Hi Juergen
On 14.12.21 18:44, Oleksandr wrote:
On 14.12.2
On 17/12/2021 13:58, Oleksii Moisieiev wrote:
Hi Julien,
Hi,
On Fri, Dec 17, 2021 at 01:37:35PM +, Julien Grall wrote:
Hi,
On 17/12/2021 13:23, Oleksii Moisieiev wrote:
+static int map_memory_to_domain(struct domain *d, uint64_t addr, uint64_t len)
+{
+return iomem_permit_access
Hi Andrew,
On 17/12/2021 15:56, Andrew Cooper wrote:
On 16/11/2021 00:41, Andrew Cooper wrote:
On 16/11/2021 00:36, Stefano Stabellini wrote:
On Thu, 11 Nov 2021, Julien Grall wrote:
On 11/11/2021 17:57, Andrew Cooper wrote:
There are exactly 3 callers of sort() in the hypervisor.
Both arm
On 16/11/2021 00:41, Andrew Cooper wrote:
> On 16/11/2021 00:36, Stefano Stabellini wrote:
>> On Thu, 11 Nov 2021, Julien Grall wrote:
>>> On 11/11/2021 17:57, Andrew Cooper wrote:
There are exactly 3 callers of sort() in the hypervisor.
Both arm callers pass in NULL for the swap fun
On 15.12.21 22:36, Oleksandr wrote:
On 15.12.21 17:58, Juergen Gross wrote:
Hi Juergen
On 15.12.21 16:02, Oleksandr wrote:
On 15.12.21 08:08, Juergen Gross wrote:
Hi Juergen
On 14.12.21 18:44, Oleksandr wrote:
On 14.12.21 18:03, Anthony PERARD wrote:
Hi Anthony
On Wed, Dec 08, 20
flight 167455 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167455/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167448
test-armhf-armhf-libvirt 16 save
On 03/12/2021 12:07, Jan Beulich wrote:
> This table must not have got updated in quite a while; tmem_op for
> example has managed to not only appear since then, but also disappear
> again (adding a name for it nevertheless, to make more obvious that
> something strange is going on if the slot woul
Hi!
Is there any update on this issue? How should we move forward?
Thank you,
On 11/08/2021, 12:09, "Dario Faggioli" wrote:
On Mon, 2021-08-09 at 21:38 +0100, Julien Grall wrote:
> On 09/08/2021 18:35, Julien Grall wrote:
> >
> > This implies that a pCPU may temporarily be a
On 03/12/2021 12:06, Jan Beulich wrote:
> This has gone out of sync over time, resulting in NPF and XSETBV exits
> incrementing the same counter. Introduce a simplistic mechanism to
> hopefully keep things in better sync going forward.
>
> Signed-off-by: Jan Beulich
> ---
> Given their large (and
On 03/12/2021 12:05, Jan Beulich wrote:
> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
> @@ -220,6 +220,8 @@ static inline void pi_clear_sn(struct pi
> #define EXIT_REASON_XSAVES 63
> #define EXIT_REASON_XRSTORS 64
>
> +#define EXIT_
Hi Julien
> On 17 Dec 2021, at 2:32 pm, Julien Grall wrote:
>
> Hi Jan,
>
> On 16/12/2021 13:37, Jan Beulich wrote:
>> On 16.12.2021 12:01, Roger Pau Monné wrote:
>>> On Thu, Dec 16, 2021 at 10:18:32AM +, Rahul Singh wrote:
Hi Roger,
Thanks for reviewing the code.
flight 167460 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167460/
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
Hi Jan,
On 10/12/2021 09:39, Jan Beulich wrote:
This allows properly tying together INVALID_{G,M}FN and
INVALID_{G,M}FN_INITIALIZER as well as using the actual values in
compile time constant expressions (or even preprocessor dirctives).
Since INVALID_PFN is unused, and with x86'es paging_mark_
Hi Jan,
On 24/09/2021 10:43, Jan Beulich wrote:
Generic code will use this information to determine what order values
can legitimately be passed to the ->{,un}map_page() hooks. For now all
ops structures simply get to announce 4k mappings (as base page size),
and there is (and always has been) a
Hi Jan,
On 24/09/2021 10:44, Jan Beulich wrote:
Or really, in the case of ->map_page(), accommodate it in the existing
"flags" parameter. All call sites will pass 0 for now.
Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
For the Arm bits:
Acked-by: Julien Grall
Cheers,
--
Julien Gra
On 24/09/2021 10:53, Jan Beulich wrote:
Having a separate flush-all hook has always been puzzling me some. We
will want to be able to force a full flush via accumulated flush flags
from the map/unmap functions. Introduce a respective new flag and fold
all flush handling to use the single remai
On 03/12/2021 12:04, Jan Beulich wrote:
> There's no point including them when the respective functionality isn't
> enabled in the build. Note that this covers only larger groups; more
> fine grained exclusion may want to be done later on.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Hi Jan,
On 16/12/2021 13:37, Jan Beulich wrote:
On 16.12.2021 12:01, Roger Pau Monné wrote:
On Thu, Dec 16, 2021 at 10:18:32AM +, Rahul Singh wrote:
Hi Roger,
Thanks for reviewing the code.
On 14 Dec 2021, at 12:37 pm, Roger Pau Monné wrote:
On Tue, Dec 14, 2021 at 10:45:17AM +, R
On 17/12/2021 14:22, Stewart Hildebrand wrote:
> On Friday, December 17, 2021 9:20 AM, Andrew Cooper wrote:
>> On 22/11/2021 14:54, Stewart Hildebrand wrote:
>>> On Monday, November 22, 2021 9:39 AM, From: Jan Beulich wrote:
On 22.11.2021 15:17, Stewart Hildebrand wrote:
> Josh works at an
On Friday, December 17, 2021 9:20 AM, Andrew Cooper wrote:
> On 22/11/2021 14:54, Stewart Hildebrand wrote:
> > On Monday, November 22, 2021 9:39 AM, From: Jan Beulich wrote:
> >> On 22.11.2021 15:17, Stewart Hildebrand wrote:
> >>> Josh works at another company now
> >> You don't happen to know hi
On 22/11/2021 14:54, Stewart Hildebrand wrote:
> On Monday, November 22, 2021 9:39 AM, From: Jan Beulich wrote:
>> On 22.11.2021 15:17, Stewart Hildebrand wrote:
>>> Josh works at another company now
>> You don't happen to know his email there, do you? Else if would have been
>> good to Cc him so h
Hi Julien,
On Fri, Dec 17, 2021 at 01:37:35PM +, Julien Grall wrote:
> Hi,
>
> On 17/12/2021 13:23, Oleksii Moisieiev wrote:
> > > > +static int map_memory_to_domain(struct domain *d, uint64_t addr,
> > > > uint64_t len)
> > > > +{
> > > > +return iomem_permit_access(d, paddr_to_pfn(addr
Hi Jan,
On Fri, Dec 17, 2021 at 08:16:05AM +0100, Jan Beulich wrote:
> On 17.12.2021 08:12, Jan Beulich wrote:
> > On 16.12.2021 18:36, Oleksii Moisieiev wrote:
> >> On Tue, Dec 14, 2021 at 10:41:30AM +0100, Jan Beulich wrote:
> >>> On 14.12.2021 10:34, Oleksii Moisieiev wrote:
> --- a/xen/in
Hi,
On 17/12/2021 13:23, Oleksii Moisieiev wrote:
+static int map_memory_to_domain(struct domain *d, uint64_t addr, uint64_t len)
+{
+return iomem_permit_access(d, paddr_to_pfn(addr),
+paddr_to_pfn(PAGE_ALIGN(addr + len -1)));
+}
+
+static int unmap_memory_from_domain(struct
Hi Michal,
On 17/12/2021 11:52, Michal Orzel wrote:
On 17.12.2021 11:01, Julien Grall wrote:
On 17/12/2021 07:21, Michal Orzel wrote:
to hypervisor when switching from AArch32 state.
According to section D1.20.2 of Arm Arm(DDI 0487A.j):
"If the general-purpose register was accessible from AAr
Hi Oleksandr,
On Fri, Dec 17, 2021 at 01:35:35PM +0200, Oleksandr wrote:
>
> On 14.12.21 11:34, Oleksii Moisieiev wrote:
>
>
> Hi Oleksii
>
> > This is the implementation of SCI interface, called SCMI-SMC driver,
> > which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
flight 167451 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167451/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167438
test-amd64-amd64-qemuu-nested-amd 20
flight 167452 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167452/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 167443
Tests which did not succee
Hi Stefano,
On Thu, Dec 16, 2021 at 06:45:11PM -0800, Stefano Stabellini wrote:
> On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:
> > This patch adds the basic framework for SCI mediator.
> > SCI is System Control Interface, which is designed to redirect
> > requests for the Hardware (such as power-
Hi Oleksandr,
On Thu, Dec 16, 2021 at 02:33:28AM +0200, Oleksandr wrote:
>
> On 14.12.21 11:34, Oleksii Moisieiev wrote:
>
>
> Hi Oleksii
>
> > Introducing the feature, called SCI mediator.
> > It's purpose is to redirect SCMI requests from the domains to firmware
> > (SCP, ATF etc), which con
Hi Oleksandr,
On Thu, Dec 16, 2021 at 02:04:35AM +0200, Oleksandr wrote:
>
> On 14.12.21 11:34, Oleksii Moisieiev wrote:
>
> Hi Oleksii
>
> > Integration of the SCMI mediator with xen libs:
> > - add hypercalls to aquire SCI channel and set device permissions
> > for DomUs;
> > - add SCMI_SMC n
flight 167457 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167457/
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
Hi Julien,
On 17.12.2021 11:01, Julien Grall wrote:
> Hi,
>
> On 17/12/2021 07:21, Michal Orzel wrote:
>> to hypervisor when switching from AArch32 state.
>>
>> According to section D1.20.2 of Arm Arm(DDI 0487A.j):
>> "If the general-purpose register was accessible from AArch32 state the
>> upper
flight 167458 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167458/
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 14.12.21 11:34, Oleksii Moisieiev wrote:
Hi Oleksii
This is the implementation of SCI interface, called SCMI-SMC driver,
which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
This allows devices from the Domains to work with clocks, resets and
power-domains without
Hi Rahul,
I have a few comments on top of what Stefano already wrote.
On 14/12/2021 10:45, Rahul Singh wrote:
IO ports on ARM don't exist so all IO ports related hypercalls are going
to fail on ARM when we passthrough a PCI device.
Well. Arm doesn't have specific instructions to access I/O po
On 17.12.21 11:41, Julien Grall wrote:
Hi Juergen,
On 17/12/2021 08:50, Juergen Gross wrote:
On 17.12.21 08:45, Jan Beulich wrote:
On 17.12.2021 06:34, Juergen Gross wrote:
On 16.12.21 22:15, Stefano Stabellini wrote:
On Thu, 16 Dec 2021, Stefano Stabellini wrote:
On Thu, 16 Dec 2021, Juerg
Hi Oleksandr,
On Wed, Dec 15, 2021 at 11:51:01PM +0200, Oleksandr wrote:
>
> On 14.12.21 11:34, Oleksii Moisieiev wrote:
>
>
> Hi Oleksii
>
> > This enumeration sets SCI type for the domain. Currently there is
> > two possible options: either 'none' or 'scmi_smc'.
> >
> > 'none' is the defaul
Hi Oleksandr,
On Wed, Dec 15, 2021 at 11:57:29AM +0200, Oleksandr Tyshchenko wrote:
> On Tue, Dec 14, 2021 at 11:35 AM Oleksii Moisieiev <
> oleksii_moisie...@epam.com> wrote:
>
> Hi Oleksii
>
> [sorry for the possible format issues]
>
> Implementation includes platform-specific smc handler for
Hi Julien,
On Wed, Dec 15, 2021 at 09:39:32AM +, Julien Grall wrote:
> Hi,
>
> Looking at the rest of the series, this is going to be replaced in patch #2
> with:
>
> return sci_handle_call();
>
> SCMI is not specific to RCAR3. So I would expect the function to be called
> from common code.
Hi Juergen,
On 17/12/2021 07:50, Juergen Gross wrote:
Since several years now xenstored is no longer capable to run under
SunOS, as the needed libxengnttab interfaces are not available there.
Several attempts to let the SunOS maintainers address this situation
didn't change anything in this reg
Hi Juergen,
On 17/12/2021 08:50, Juergen Gross wrote:
On 17.12.21 08:45, Jan Beulich wrote:
On 17.12.2021 06:34, Juergen Gross wrote:
On 16.12.21 22:15, Stefano Stabellini wrote:
On Thu, 16 Dec 2021, Stefano Stabellini wrote:
On Thu, 16 Dec 2021, Juergen Gross wrote:
On 16.12.21 03:10, Stef
Hi Stefano,
On 16/12/2021 21:15, Stefano Stabellini wrote:
On Thu, 16 Dec 2021, Stefano Stabellini wrote:
On Thu, 16 Dec 2021, Juergen Gross wrote:
On 16.12.21 03:10, Stefano Stabellini wrote:
On Wed, 15 Dec 2021, Juergen Gross wrote:
On 14.12.21 18:36, Julien Grall wrote:
Hi,
On 08/12/202
Hi Juergen,
On 15/12/2021 07:03, Juergen Gross wrote:
On 14.12.21 18:36, Julien Grall wrote:
Hi,
On 08/12/2021 15:55, Juergen Gross wrote:
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.
So on
Hi,
On 17/12/2021 07:21, Michal Orzel wrote:
to hypervisor when switching from AArch32 state.
According to section D1.20.2 of Arm Arm(DDI 0487A.j):
"If the general-purpose register was accessible from AArch32 state the
upper 32 bits either become zero, or hold the value that the same
architectu
On 17/12/2021 07:50, Juergen Gross wrote:
> Since several years now xenstored is no longer capable to run under
> SunOS, as the needed libxengnttab interfaces are not available there.
>
> Several attempts to let the SunOS maintainers address this situation
> didn't change anything in this regard.
>
Hi Stefano,
> On 16 Dec 2021, at 9:48 pm, Stefano Stabellini wrote:
>
> On Thu, 16 Dec 2021, Rahul Singh wrote:
>> Hi Stefano,
>>
>>> On 16 Dec 2021, at 2:33 am, Stefano Stabellini
>>> wrote:
>>>
>>> On Tue, 14 Dec 2021, Rahul Singh wrote:
IO ports on ARM don't exist so all IO ports rel
On 17.12.21 08:45, Jan Beulich wrote:
On 17.12.2021 06:34, Juergen Gross wrote:
On 16.12.21 22:15, Stefano Stabellini wrote:
On Thu, 16 Dec 2021, Stefano Stabellini wrote:
On Thu, 16 Dec 2021, Juergen Gross wrote:
On 16.12.21 03:10, Stefano Stabellini wrote:
The case of XENMEM_maximum_ram_pa
76 matches
Mail list logo
