Hi, Paul!
On 7/2/20 11:42 AM, Jürgen Groß wrote:
> On 02.07.20 09:59, Oleksandr Andrushchenko wrote:
>>
>> On 7/2/20 10:20 AM, Jürgen Groß wrote:
>>> On 01.07.20 14:07, Oleksandr Andrushchenko wrote:
On 7/1/20 1:46 PM, Jürgen Groß wrote:
> On 01.07.20 09:19, Oleksandr Andrushchenko wrote:
On 07.07.20 21:30, John Hubbard wrote:
On 2020-07-07 04:43, Jürgen Groß wrote:
On 07.07.20 13:30, Souptick Joarder wrote:
On Tue, Jul 7, 2020 at 3:08 PM Jürgen Groß wrote:
...
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 33677ea..f6c1543 100644
--- a/drivers/xen/privcmd.c
Daniel P. Berrangé writes:
> On Mon, Jul 06, 2020 at 06:23:00PM +0200, Christophe de Dinechin wrote:
>> There are a number of unnecessary trailing whitespaces that have
>> accumulated over time in the source code. They cause stray changes
>> in patches if you use tools that automatically remove t
On 07.07.20 21:23, osstest service owner wrote:
flight 151705 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151705/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
...
build-i386-pvops 6 kernel-b
flight 151714 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151714/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-amd64-l
On Tue, Jul 7, 2020 at 5:15 PM Jürgen Groß wrote:
>
> On 07.07.20 13:40, Souptick Joarder wrote:
> > On Tue, Jul 7, 2020 at 3:05 PM Jürgen Groß wrote:
> >>
> >> On 06.07.20 20:16, Souptick Joarder wrote:
> >>> Previously, if lock_pages() end up partially mapping pages, it used
> >>> to return -ER
flight 151713 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151713/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail
REGR. vs. 1512
flight 151712 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151712/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12
Vladimir Sementsov-Ogievskiy writes:
> 07.07.2020 19:50, Markus Armbruster wrote:
>> From: Vladimir Sementsov-Ogievskiy
>>
>> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
>> functions with an errp OUT parameter.
>>
>> It has three goals:
>>
>> 1. Fix issue with error_fatal an
Eric Blake writes:
> On 7/7/20 11:50 AM, Markus Armbruster wrote:
>> From: Vladimir Sementsov-Ogievskiy
>>
>> Script adds ERRP_AUTO_PROPAGATE macro invocation where appropriate and
>> does corresponding changes in code (look for details in
>> include/qapi/error.h)
>>
>> Usage example:
>> spatch
07.07.2020 19:50, Markus Armbruster wrote:
From: Vladimir Sementsov-Ogievskiy
Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with an errp OUT parameter.
It has three goals:
1. Fix issue with error_fatal and error_prepend/error_append_hint: user
can't see this addit
Eric Blake writes:
> On 7/7/20 11:50 AM, Markus Armbruster wrote:
>> From: Vladimir Sementsov-Ogievskiy
>>
>> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
>> functions with an errp OUT parameter.
>>
>> It has three goals:
>>
>> 1. Fix issue with error_fatal and error_prepend
On 7/7/20 11:50 AM, Markus Armbruster wrote:
From: Vladimir Sementsov-Ogievskiy
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == &error_fatal
(the program will exit pri
From: Michal Leszczynski
Add an demonstration tool that uses xc_vmtrace_* calls in order
to manage external IPT monitoring for DomU.
Signed-off-by: Michal Leszczynski
---
tools/proctrace/Makefile| 45 +
tools/proctrace/proctrace.c | 179
2 file
From: Michal Leszczynski
Implement necessary changes in common code/HVM to support
processor trace features. Define vmtrace_pt_* API and
implement trace buffer allocation/deallocation in common
code.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/domain.c | 21 +
From: Michal Leszczynski
Allow to specify the size of per-vCPU trace buffer upon
domain creation. This is zero by default (meaning: not enabled).
Signed-off-by: Michal Leszczynski
---
docs/man/xl.cfg.5.pod.in | 13 +
tools/golang/xenlight/helpers.gen.go | 2 ++
tools/g
From: Michal Leszczynski
Allow to map processor trace buffer using
acquire_resource().
Signed-off-by: Michal Leszczynski
---
xen/common/memory.c | 31 +++
xen/include/public/memory.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/xen/common/memory.c
From: Michal Leszczynski
Add functions in libxc that use the new XEN_DOMCTL_vmtrace interface.
Signed-off-by: Michal Leszczynski
---
tools/libxc/Makefile | 1 +
tools/libxc/include/xenctrl.h | 40
tools/libxc/xc_vmtrace.c | 87 +++
From: Michal Leszczynski
Use Intel Processor Trace feature to provide vmtrace_pt_*
interface for HVM/VMX.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/vmx/vmx.c | 110 +
xen/include/asm-x86/hvm/vmx/vmcs.h | 3 +
xen/include/asm-x86/hvm/vmx/vmx.h
From: Michal Leszczynski
Implement domctl to manage the runtime state of
processor trace feature.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/domctl.c | 50 +
xen/include/public/domctl.h | 28 +
2 files changed, 78 insertions
Intel Processor Trace is an architectural extension available in modern Intel
family CPUs. It allows recording the detailed trace of activity while the
processor executes the code. One might use the recorded trace to reconstruct
the code flow. It means, to find out the executed code paths, deter
From: Michal Leszczynski
Add vmtrace_pt_size domain parameter in live domain and
vmtrace_pt_order parameter in xen_domctl_createdomain.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/domain.c | 6 ++
xen/common/domain.c | 9 +
xen/include/public/domctl.h | 1 +
xe
From: Michal Leszczynski
Allow to acquire large resources by allowing acquire_resource()
to process items in batches, using hypercall continuation.
Be aware that this modifies the behavior of acquire_resource
call with frame_list=NULL. While previously it would return
the size of internal array
From: Michal Leszczynski
Check if Intel Processor Trace feature is supported by current
processor. Define vmtrace_supported global variable.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/vmx/vmcs.c | 15 ++-
xen/common/domain.c | 2
From: Michal Leszczynski
Define constants related to Intel Processor Trace features.
Signed-off-by: Michal Leszczynski
Acked-by: Andrew Cooper
---
xen/include/asm-x86/msr-index.h | 24
1 file changed, 24 insertions(+)
diff --git a/xen/include/asm-x86/msr-index.h b/xe
On 7/7/20 11:50 AM, Markus Armbruster wrote:
From: Vladimir Sementsov-Ogievskiy
Script adds ERRP_AUTO_PROPAGATE macro invocation where appropriate and
does corresponding changes in code (look for details in
include/qapi/error.h)
Usage example:
spatch --sp-file scripts/coccinelle/auto-propagate
On 2020-07-07 04:43, Jürgen Groß wrote:
On 07.07.20 13:30, Souptick Joarder wrote:
On Tue, Jul 7, 2020 at 3:08 PM Jürgen Groß wrote:
...
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 33677ea..f6c1543 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -612,8 +
flight 151705 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151705/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
build-i386-pvops
On 7/7/20 11:50 AM, Markus Armbruster wrote:
From: Vladimir Sementsov-Ogievskiy
Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with an errp OUT parameter.
It has three goals:
1. Fix issue with error_fatal and error_prepend/error_append_hint: user
the user
can'
On 7/7/20 11:50 AM, Markus Armbruster wrote:
To speed things up, I'm taking the liberty to respin Vladimir's series
with my documentation amendments.
After my documentation work, I'm very much inclined to rename
ERRP_AUTO_PROPAGATE() to ERRP_GUARD(). The fact that it propagates
below the hood i
07.07.2020 19:50, Markus Armbruster wrote:
To speed things up, I'm taking the liberty to respin Vladimir's series
with my documentation amendments.
Thank you!
After my documentation work, I'm very much inclined to rename
ERRP_AUTO_PROPAGATE() to ERRP_GUARD(). The fact that it propagates
bel
flight 151704 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151704/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 15106
From: Vladimir Sementsov-Ogievskiy
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == &error_fatal
(the program will exit prior to the error_append_hint() or
error_prepend(
From: Vladimir Sementsov-Ogievskiy
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == &error_fatal
(the program will exit prior to the error_append_hint() or
error_prepend(
From: Vladimir Sementsov-Ogievskiy
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == &error_fatal
(the program will exit prior to the error_append_hint() or
error_prepend(
From: Vladimir Sementsov-Ogievskiy
Script adds ERRP_AUTO_PROPAGATE macro invocation where appropriate and
does corresponding changes in code (look for details in
include/qapi/error.h)
Usage example:
spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
--macro-file scripts/cocci-macr
From: Vladimir Sementsov-Ogievskiy
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == &error_fatal
(the program will exit prior to the error_append_hint() or
error_prepend(
From: Vladimir Sementsov-Ogievskiy
Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with an errp OUT parameter.
It has three goals:
1. Fix issue with error_fatal and error_prepend/error_append_hint: user
can't see this additional information, because exit() happens in
From: Vladimir Sementsov-Ogievskiy
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == &error_fatal
(the program will exit prior to the error_append_hint() or
error_prepend(
To speed things up, I'm taking the liberty to respin Vladimir's series
with my documentation amendments.
After my documentation work, I'm very much inclined to rename
ERRP_AUTO_PROPAGATE() to ERRP_GUARD(). The fact that it propagates
below the hood is detail. What matters to its users is that it
From: Vladimir Sementsov-Ogievskiy
If we want to add some info to errp (by error_prepend() or
error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
Otherwise, this info will not be added when errp == &error_fatal
(the program will exit prior to the error_append_hint() or
error_prepend(
flight 151711 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151711/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 151707 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151707/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 2dd14fbcf9d03fdc300491939aeac75d3eb9e05f
baseline version:
xtf 2a8859e87761a0efc11977
Hello Bertrand,
Thank you. I will try a fresh build with dunfell branch. All layers in the
sense [poky, meta-openembedded, meta-linaro, meta-rensas, meta-virtualisation,
meta-selinux, xen-troops] right?
Also, Can I use the same proprietary drivers which I used for
yocto2.19[R-Car_Gen3_Series_E
On 07.07.2020 11:35, Jan Beulich wrote:
> gcc 9.3 started to re-order top level blocks by default when optimizing.
> This re-ordering results in all our .type directives to get emitted to
> the assembly file first, followed by gcc's. The assembler warns about
> attempts to change the type of a symb
flight 151698 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 151496
test-amd64-i38
Hello Bertrand,
Thanks for your quick response. I tired switching to dunfell branch and build
gives parse error as below.
bitbake core-image-weston
ERROR: ParseError in
/home/manikandan/yocto_2.19/build/meta-virtualization/classes/: not a BitBake
file
Is there any additional changes required
Hello Oleksandr Andrushchenko,
Thanks for your quick response. I am using the yocto version[yocto_2.19]
mentioned in the link. Still I face the issue.
Mit freundlichen Grüßen / Best regards
Chockalingam Manikandan
ES-CM Core fn,ADIT (RBEI/ECF3)
Robert Bosch GmbH | Postfach 10 60 50 | 70049 St
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-debianhvm-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git
flight 151696 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151696/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151661
test-amd64-amd64-xl-qemuu-ws16-amd64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-15564 / XSA-327
version 3
Missing alignment check in VCPUOP_register_vcpu_info
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-15567 / XSA-328
version 3
non-atomic modification of live EPT PTE
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-15563 / XSA-319
version 3
inverted code paths in x86 dirty VRAM tracking
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-15566 / XSA-317
version 3
Incorrect error handling in event channel port allocation
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
Hello Team,
I am trying to build xen hypervisor for RCAR and following the
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
steps.
But am facing the following issues
1. SRC_URI="http://v3.sk/~lkundrak/dev86/archive/Dev86src-${PV}.tar.gz in
recipes-extend
> On 7 Jul 2020, at 11:18, Manikandan Chockalingam (RBEI/ECF3)
> wrote:
>
> Hello Bertrand,
>
> Thank you. I will try a fresh build with dunfell branch. All layers in the
> sense [poky, meta-openembedded, meta-linaro, meta-rensas,
> meta-virtualisation, meta-selinux, xen-troops] right?
ri
On 06.07.20 20:16, Souptick Joarder wrote:
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information. This is case 5 as per document [1].
[1] Documentation/core-api/pin_user_pages.rst
[2]
On 07.07.20 13:40, Souptick Joarder wrote:
On Tue, Jul 7, 2020 at 3:05 PM Jürgen Groß wrote:
On 06.07.20 20:16, Souptick Joarder wrote:
Previously, if lock_pages() end up partially mapping pages, it used
to return -ERRNO due to which unlock_pages() have to go through
each pages[i] till *nr_pa
On 07.07.20 13:30, Souptick Joarder wrote:
On Tue, Jul 7, 2020 at 3:08 PM Jürgen Groß wrote:
On 06.07.20 20:16, Souptick Joarder wrote:
pages need to be marked as dirty before unpinned it in
unlock_pages() which was oversight. This is fixed now.
Signed-off-by: Souptick Joarder
Suggested-by:
On Tue, Jul 7, 2020 at 3:05 PM Jürgen Groß wrote:
>
> On 06.07.20 20:16, Souptick Joarder wrote:
> > Previously, if lock_pages() end up partially mapping pages, it used
> > to return -ERRNO due to which unlock_pages() have to go through
> > each pages[i] till *nr_pages* to validate them. This can
- 7 lip 2020 o 13:21, Jan Beulich jbeul...@suse.com napisał(a):
> On 07.07.2020 13:17, Michał Leszczyński wrote:
>> So would it be OK to use uint32_t everywhere and to store the trace buffer
>> size as number of kB? I think this is the most straightforward option.
>>
>> I would also stick wit
On Tue, Jul 7, 2020 at 3:08 PM Jürgen Groß wrote:
>
> On 06.07.20 20:16, Souptick Joarder wrote:
> > pages need to be marked as dirty before unpinned it in
> > unlock_pages() which was oversight. This is fixed now.
> >
> > Signed-off-by: Souptick Joarder
> > Suggested-by: John Hubbard
> > Cc: Jo
On 07.07.2020 13:17, Michał Leszczyński wrote:
> So would it be OK to use uint32_t everywhere and to store the trace buffer
> size as number of kB? I think this is the most straightforward option.
>
> I would also stick with the name "processor_trace_buf_size"
> everywhere, both in the hypervisor,
- 7 lip 2020 o 11:16, Julien Grall jul...@xen.org napisał(a):
> On 07/07/2020 10:10, Jan Beulich wrote:
>> On 07.07.2020 10:44, Julien Grall wrote:
>>> Hi,
>>>
>>> On 06/07/2020 09:46, Jan Beulich wrote:
On 04.07.2020 19:23, Julien Grall wrote:
> Hi,
>
> On 03/07/2020 11:11, R
On Mon, Jul 06, 2020 at 06:23:00PM +0200, Christophe de Dinechin wrote:
> There are a number of unnecessary trailing whitespaces that have
> accumulated over time in the source code. They cause stray changes
> in patches if you use tools that automatically remove them.
>
> Tested by doing a `git d
Le 06/07/2020 à 18:23, Christophe de Dinechin a écrit :
> There are a number of unnecessary trailing whitespaces that have
> accumulated over time in the source code. They cause stray changes
> in patches if you use tools that automatically remove them.
>
> Tested by doing a `git diff -w` after th
On 06.07.20 20:16, Souptick Joarder wrote:
pages need to be marked as dirty before unpinned it in
unlock_pages() which was oversight. This is fixed now.
Signed-off-by: Souptick Joarder
Suggested-by: John Hubbard
Cc: John Hubbard
Cc: Boris Ostrovsky
Cc: Paul Durrant
---
drivers/xen/privcmd
gcc 9.3 started to re-order top level blocks by default when optimizing.
This re-ordering results in all our .type directives to get emitted to
the assembly file first, followed by gcc's. The assembler warns about
attempts to change the type of a symbol when it was already set (and
when there's no
On 06.07.20 20:16, Souptick Joarder wrote:
Previously, if lock_pages() end up partially mapping pages, it used
to return -ERRNO due to which unlock_pages() have to go through
each pages[i] till *nr_pages* to validate them. This can be avoided
by passing correct number of partially mapped pages &
Hi,
> On 7 Jul 2020, at 10:28, Manikandan Chockalingam (RBEI/ECF3)
> wrote:
>
> Hello Bertrand,
>
> Thanks for your quick response. I tired switching to dunfell branch and build
> gives parse error as below.
>
> bitbake core-image-weston
> ERROR: ParseError in
> /home/manikandan/yocto_2.19/
On Mon, Jul 06, 2020 at 06:23:00PM +0200, Christophe de Dinechin wrote:
> There are a number of unnecessary trailing whitespaces that have
> accumulated over time in the source code. They cause stray changes
> in patches if you use tools that automatically remove them.
>
> Tested by doing a `git d
flight 151690 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
build-i386-pvops
On 07/07/2020 10:10, Jan Beulich wrote:
On 07.07.2020 10:44, Julien Grall wrote:
Hi,
On 06/07/2020 09:46, Jan Beulich wrote:
On 04.07.2020 19:23, Julien Grall wrote:
Hi,
On 03/07/2020 11:11, Roger Pau Monné wrote:
On Fri, Jul 03, 2020 at 11:56:38AM +0200, Jan Beulich wrote:
On 03.07.202
On 07.07.2020 10:44, Julien Grall wrote:
> Hi,
>
> On 06/07/2020 09:46, Jan Beulich wrote:
>> On 04.07.2020 19:23, Julien Grall wrote:
>>> Hi,
>>>
>>> On 03/07/2020 11:11, Roger Pau Monné wrote:
On Fri, Jul 03, 2020 at 11:56:38AM +0200, Jan Beulich wrote:
> On 03.07.2020 11:44, Roger Pau
> On 7 Jul 2020, at 08:58, Manikandan Chockalingam (RBEI/ECF3)
> wrote:
>
> Hello Team,
>
> I am trying to build xen hypervisor for RCAR and following the
> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
> steps.
>
> But am facing the following issues
flight 151685 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151685/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 15106
Hi,
On 06/07/2020 09:46, Jan Beulich wrote:
On 04.07.2020 19:23, Julien Grall wrote:
Hi,
On 03/07/2020 11:11, Roger Pau Monné wrote:
On Fri, Jul 03, 2020 at 11:56:38AM +0200, Jan Beulich wrote:
On 03.07.2020 11:44, Roger Pau Monné wrote:
On Thu, Jul 02, 2020 at 06:23:28PM +0200, Michał Lesz
On 7/7/20 10:58 AM, Manikandan Chockalingam (RBEI/ECF3) wrote:
>
> Hello Team,
>
> I am trying to build xen hypervisor for RCAR and following the
> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
> steps.
>
> But am facing the following issues
>
> 1.SRC_URI="ht
Hi all,
Xen 4.14 RC5 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.14.0-rc5
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.14.0-rc5/xen-4.14.0-rc5.tar.gz
And the signature is at:
https://downloads.xenproject.org/
79 matches
Mail list logo
