- Changed unprintable characters with %s/\%xA0/ /g
So all the spaces are 0x20 now.
- Added address-cells and size-cells to configuration example.
This resolves the dom0less boot issue in case of arm64.
- Added some notes about xl tools usage in case of dom0less.
- Added extra 0x0 to memory
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, July 3, 2019 7:33 PM
>
> EPT differs from NPT and shadow when translating page orders to levels
> in the physmap page tables. EPT page tables level for order 0 pages is
> 0, while NPT and shadow instead use 1, ie: EPT page
Update ARM code coverage warning about testing gcov on arm
Signed-off-by: Viktor Mitin
---
v2:
updated only part of the warning related to testing on ARM
---
docs/hypervisor-guide/code-coverage.rst | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
flight 138849 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138849/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 133580
On 08.07.2019 15:53, Norbert Manthey wrote:
> On 5/23/19 17:01, Jan Beulich wrote:
> On 21.05.19 at 09:45, wrote:
>>> * gnttab_set_version: all accessible data is allocated for both versions
>> This is not enough for my taste: The very first loop is safe only
>> because nr_grant_entries()
On 08.07.2019 14:58, Norbert Manthey wrote:
> On 5/24/19 13:10, Jan Beulich wrote:
> On 24.05.19 at 11:54, wrote:
>>> On 5/23/19 16:17, Jan Beulich wrote:
>>> On 21.05.19 at 09:45, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -988,9 +988,10 @@
On 09.07.2019 18:51, Andrew Cooper wrote:
> write_full_gdt_ptes() looks suspicious - it is not generally safe to
> iterate over (mfn + i).
I'm still not happy about this (misleading) statement: The safety of
this depends, as said, on how the allocation gets done. And the way
that is done at the
On 09.07.2019 22:13, George Dunlap wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -343,6 +343,11 @@ M: Marek Marczykowski-Górecki
>
> S: Supported
> F: tools/python
>
> +GOLANG BINDINGS
> +M: George Dunlap
> +S: Maintained
> +F: tools/golang
> +
> QEMU-DM
>
On 2019/7/9 22:54, Boris Ostrovsky wrote:
On 7/9/19 12:20 AM, Zhenzhong Duan wrote:
-const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
+static uint32_t __init xen_platform_hvm(void)
+{
+ uint32_t xen_domain = xen_cpuid_base();
+ struct x86_hyper_init *h =
flight 138851 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138851/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8a842b31b93323ee3dc7631059292d30f6179cd3
baseline version:
ovmf
flight 138850 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138850/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 138815
test-armhf-armhf-libvirt-raw 13
flight 138842 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 132889
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
CC: Konrad Wilk
CC: Stefano Stabellini
CC: Julien Grall
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
flight 138829 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138829/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore.2 fail in 138770 pass
in 138829
flight 138867 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138867/
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
Hi,
On 7/9/19 6:05 PM, Viktor Mitin wrote:
On Tue, Jul 9, 2019 at 3:11 PM Julien Grall wrote:
Hi,
Hi Julien,
On 7/9/19 11:56 AM, Viktor Mitin wrote:
Remove obsolete warning about testing gcov on arm.
gcov has been fixed and tested with arm hw previously
See commit 6ac66c9
This
Hi Julien,
On Tue, Jul 9, 2019 at 3:29 PM Julien Grall wrote:
>
> Hi Viktor,
>
> On 7/9/19 8:49 AM, Viktor Mitin wrote:
> > While checking xen dom0less documentation it has been found
> > that domU memory property requires extra 0x0 in case of arm64.
>
> And this matches the binding
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: Wednesday, July 3, 2019 11:39 AM
> To: Zhang, Chen
> Cc: Ian Jackson ; Wei Liu ; xen-
> de...@lists.xenproject.org; Zhang Chen
> Subject: Re: [Xen-devel] [PATCH] tools/libxl: Add iothread support for
Hi,
On Tue, Jul 9, 2019 at 3:15 PM Julien Grall wrote:
>
> Hi,
>
> On 7/9/19 8:23 AM, Viktor Mitin wrote:
> > On Mon, Jul 8, 2019 at 6:45 PM Julien Grall wrote:
> >>
> >> Hello,
> > Hello Julien,
> >
> >>
> >> On 7/8/19 1:35 PM, Viktor Mitin wrote:
> >>> Updated configuration example according
On Tue, Jul 9, 2019 at 3:11 PM Julien Grall wrote:
>
> Hi,
>
Hi Julien,
> On 7/9/19 11:56 AM, Viktor Mitin wrote:
> > Remove obsolete warning about testing gcov on arm.
> > gcov has been fixed and tested with arm hw previously
> >
> > See commit 6ac66c9
>
> This commit...
>
> >
> >
write_full_gdt_ptes() looks suspicious - it is not generally safe to
iterate over (mfn + i). However, the loop is entirely unnecessary, as
NR_RESERVED_GDT_PAGES is 1. Dropping it makes the code substantially
more clear, and with it dropped, write_full_gdt_ptes() becomes more
obviously a poor
xenstored currently requires an libxc and evtchn interface, but leaves
the gnttab interface as optional.
gnttab is ubiquitous these days, and in practice mandatory in all cases
where xenstored isn't running as root in dom0 (due to the inability to
foreign map by MFN).
The toolstack has
This is a vestigial remnent of the pre xenstored stub domain days.
Foreign mapping via MFN is a privileged operation which is not
necessary, because grant details are unconditionally set up during
domain construction. In practice, this means xenstored never uses its
ability to foreign map the
xenstored is currently linked against libxc, and uses unstable interfaces for
exactly two things:
1) Foreign mapping by MFN
2) xc_dom_getinfo(), but only for shutdown information
This series addresses issue 1. Issue 2 is still open, and can take advantage
of loads of us being co-located in
flight 138826 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138826/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-pvshim7 xen-boot fail in 138807 pass in 138826
On 7/9/19 12:20 AM, Zhenzhong Duan wrote:
>
> -const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
> +static uint32_t __init xen_platform_hvm(void)
> +{
> + uint32_t xen_domain = xen_cpuid_base();
> + struct x86_hyper_init *h = _hyper_xen_hvm.init;
> +
> + if
Hi Will,
On 7/9/19 2:22 PM, Will Abele wrote:
From: Will Abele
The root node of a device tree should not have a node name. This is
specified in section 2.2.1 of version 0.2 of the device tree
specification, available from devicetree.org.
Linux Kernel versions prior to 4.15 misinterpret
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-300
Linux: No grant table and foreign mapping limits
ISSUE DESCRIPTION
=
Virtual device backends and device models running in domain 0, or
other backend driver domains,
On 09.07.2019 00:15, Andrew Cooper wrote:
> The OpenSUSE Leap compilers complain about ambiguity:
>
> In file included from grant_table.c:33:
> In file included from ...xen/include/xen/grant_table.h:30:
> ...xen/include/asm/grant_table.h:67:19: error: ambiguous instructions require
> an explicit
From: Will Abele
The root node of a device tree should not have a node name. This is
specified in section 2.2.1 of version 0.2 of the device tree
specification, available from devicetree.org.
Linux Kernel versions prior to 4.15 misinterpret flattened device trees
with a "/" as the name of the
On 08.07.2019 21:27, Julien Grall wrote:
> Hi,
>
> On 7/8/19 7:11 PM, Andrew Cooper wrote:
>> On 07/07/2019 19:42, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> On 7/4/19 8:14 PM, Andrew Cooper wrote:
To allow for further improvements, it is useful to be able to clear
more than
a
The 07/08/2019 17:28, Stefano Stabellini wrote:
> On Sat, 6 Jul 2019, Will Abele wrote:
> > The 07/06/2019 18:19, Julien Grall wrote:
> > >
> > >
> > > On 06/07/2019 19:17, Julien Grall wrote:
> > > >
> > > >
> > > > On 06/07/2019 19:02, Will Abele wrote:
> > > >> From: Will Abele
> > > >>
>
flight 138823 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138823/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 138754
Hi Viktor,
On 7/9/19 8:49 AM, Viktor Mitin wrote:
While checking xen dom0less documentation it has been found
that domU memory property requires extra 0x0 in case of arm64.
And this matches the binding docs/misc/arm/device-tree/booting.txt which
requires a 64-bit value.
There is no need
Hi,
On 7/9/19 8:23 AM, Viktor Mitin wrote:
On Mon, Jul 8, 2019 at 6:45 PM Julien Grall wrote:
Hello,
Hello Julien,
On 7/8/19 1:35 PM, Viktor Mitin wrote:
Updated configuration example according to arm64
and added more cases about known xl limitations.
dom0less is not an arm64 specific
Hi,
On 7/9/19 11:56 AM, Viktor Mitin wrote:
Remove obsolete warning about testing gcov on arm.
gcov has been fixed and tested with arm hw previously
See commit 6ac66c9
This commit...
Signed-off-by: Viktor Mitin
---
docs/hypervisor-guide/code-coverage.rst | 7 ---
1 file changed, 7
Remove obsolete warning about testing gcov on arm.
gcov has been fixed and tested with arm hw previously
See commit 6ac66c9
Signed-off-by: Viktor Mitin
---
docs/hypervisor-guide/code-coverage.rst | 7 ---
1 file changed, 7 deletions(-)
diff --git a/docs/hypervisor-guide/code-coverage.rst
flight 138825 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138825/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR.
vs. 138799
On 22.06.19 02:56, Stefano Stabellini wrote:
Hi, Stefano
Don't allow reserved-memory regions to be remapped into any guests,
until reserved-memory regions are properly supported in Xen. For now,
do not call iomem_permit_access for them.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
-
On Mon, Jul 8, 2019 at 6:12 PM Adam Williamson
wrote:
> On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote:
> > > > > > "The release must boot successfully as Xen DomU with releases
> providing
> > > > > > a functional, supported Xen Dom0 and widely used cloud providers
> > > > > >
- Changed unprintable characters with %s/\%xA0/ /g
So all the spaces are 0x20 now.
- Added address-cells and size-cells to configuration example.
This resolves the dom0less boot issue in case of arm64.
- Added some notes about xl tools usage in case of dom0less.
Signed-off-by: Viktor Mitin
arm64 shares some code under arch/arm/xen, including mm.c.
However ZONE_DMA is removed by commit
ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
So to ARM64, need use __GFP_DMA32.
Signed-off-by: Peng Fan
---
arch/arm/xen/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
While checking xen dom0less documentation it has been found
that domU memory property requires extra 0x0 in case of arm64.
There is no need to keep memory size in u64, 32 bits is
enough for domU memory size.
Tested that in case of arm64 dom0less domU works
without adding extra 0x0 to domU memory
On Mon, Jul 8, 2019 at 6:45 PM Julien Grall wrote:
>
> Hello,
Hello Julien,
>
> On 7/8/19 1:35 PM, Viktor Mitin wrote:
> > Updated configuration example according to arm64
> > and added more cases about known xl limitations.
>
> dom0less is not an arm64 specific feature. It also works on arm32,
Anthony PERARD writes:
> The xen_[rw]?mb() macros defined in ring.h can't be used and the fact
> that there are gated behind __XEN_INTERFACE_VERSION__ means that it
> needs to be defined somewhere. QEMU doesn't implement interfaces with
> the Xen hypervisor so defining __XEN_INTERFACE_VERSION__
45 matches
Mail list logo
