On Mon, 2018-05-21 at 14:10 +0200, Roger Pau Monné wrote:
>
> Hm, I think I might have fixed this issue, see:
>
> https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2
Hm, thanks. We'll look at porting that change to qemu-traditional which
still doesn't do it.
smi
flight 122991 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122991/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 122866
Tests which are
>>> On 22.05.18 at 19:10, wrote:
> On 05/22/2018 12:32 PM, Jan Beulich wrote:
> On 22.05.18 at 18:20, wrote:
>>> We are loading virtual address for $canary so we will always have EDX
>>> set to 0x. Isn't that what we want?
>> Oh, that's rather confusing - we're still running on the lo
On Tue, May 22, 2018 at 09:47:45PM +0200, Marek Marczykowski-Górecki wrote:
> Older gcc does not support #pragma GCC diagnostics, so use alternative
> approach - change variable type to uint32_t (this code handle 32-bit
> requests only anyway), which apparently also avoid gcc complaining about
> th
>>> On 22.05.18 at 22:08, wrote:
> On Tue, 22 May 2018, Jan Beulich wrote:
>> >>> On 22.05.18 at 02:53, wrote:
>> > + $(eval tmpfile := $(shell mktemp))
>> > + $(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
>> > + $(eval path := $(dir $(f))) \
>> > + $(eval name := $(she
Hi Stefano
On 23.05.18 00:00, Stefano Stabellini wrote:
On Tue, 22 May 2018, Julien Grall wrote:
It might be easier to maintain if we provide a per platform config option (e.g
CONFIG_RCAR3) that will select driver for that specific board.
The user is then free to select other components (e.g s
On Tue, May 22, 2018 at 11:58:35AM +0100, Andrew Cooper wrote:
> On 22/05/18 07:57, Juergen Gross wrote:
> > Are there any patches for 4.11 still pending?
> >
> > Are any important patches missing my Release-ack?
> >
> > I'd like to have a final rc this Friday and hope OSStest will catch up
> > in
On Wed, May 23, 2018 at 08:48:12AM +0100, Wei Liu wrote:
> On Tue, May 22, 2018 at 09:47:45PM +0200, Marek Marczykowski-Górecki wrote:
> > Older gcc does not support #pragma GCC diagnostics, so use alternative
> > approach - change variable type to uint32_t (this code handle 32-bit
> > requests onl
On Wed, May 23, 2018 at 10:28:47AM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, May 23, 2018 at 08:48:12AM +0100, Wei Liu wrote:
> > On Tue, May 22, 2018 at 09:47:45PM +0200, Marek Marczykowski-Górecki wrote:
> > > Older gcc does not support #pragma GCC diagnostics, so use alternative
> > > a
>>> On 22.05.18 at 18:45, wrote:
> The 4.10 release preparation was significantly more hairy than ideal.
> (We seem to have a good overall outcome despite, rather than because
> of, our approach.)
>
> This is the second time (at least) that we have come close to failure
> by committing to a relea
flight 74735 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74735/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
74720
test-amd64-i386-i386
On 21/05/18 09:39, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Building for a 32-bit target results in warnings from casting
> between a 32-bit pointer and a 64-bit integer. Fix the warnings
> by casting those pointers to uintptr_t first.
>
> Signed-off-by: Oleksandr Andru
On 05/23/2018 12:19 PM, Juergen Gross wrote:
On 21/05/18 09:39, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Building for a 32-bit target results in warnings from casting
between a 32-bit pointer and a 64-bit integer. Fix the warnings
by casting those pointers to uintptr_t firs
flight 122997 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122997/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail
in 122923 pass in 122997
tes
Now we're using docker to build. They shouldn't be a problem anymore.
Signed-off-by: Wei Liu
---
RFC because I haven't tested if other dockerfiles need changes.
---
automation/scripts/build | 8
1 file changed, 8 deletions(-)
diff --git a/automation/scripts/build b/automation/scripts/b
Signed-off-by: Wei Liu
---
automation/build/debian/stretch-i386.dockerfile | 50 +
1 file changed, 50 insertions(+)
create mode 100644 automation/build/debian/stretch-i386.dockerfile
diff --git a/automation/build/debian/stretch-i386.dockerfile
b/automation/build/debian/
Stubdom build requires that.
Signed-off-by: Wei Liu
---
automation/build/debian/jessie.dockerfile | 1 +
automation/build/debian/stretch.dockerfile | 1 +
2 files changed, 2 insertions(+)
diff --git a/automation/build/debian/jessie.dockerfile
b/automation/build/debian/jessie.dockerfile
index
RFC because I haven't tested all dockerfiles.
Wei Liu (3):
automation: install texinfo in debian
automation: build stubdom and rombios, and tools on 32 bit
automation: introduce stretch-i386.dockerfile
automation/build/debian/jessie.dockerfile | 1 +
automation/build/debian/stretch-
flight 123093 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123093/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen fc5805daef091240cd5fc06634a8bcdb2f3bb843
baseline version:
xen e041
I am trying to commission some new test boxes. One of my test flights
experienced a weird build failure:
http://logs.test-lab.xenproject.org/osstest/logs/123046/build-i386-libvirt/6.ts-libvirt-build.log
For your convenience, log snippet below. I think this is probably a
make -j race in the li
On 23/05/18 12:00, Oleksandr Andrushchenko wrote:
> On 05/23/2018 12:19 PM, Juergen Gross wrote:
>> On 21/05/18 09:39, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Building for a 32-bit target results in warnings from casting
>>> between a 32-bit pointer and a 64-bit in
On 05/23/2018 02:06 PM, Juergen Gross wrote:
On 23/05/18 12:00, Oleksandr Andrushchenko wrote:
On 05/23/2018 12:19 PM, Juergen Gross wrote:
On 21/05/18 09:39, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Building for a 32-bit target results in warnings from casting
between a
From: Oleksandr Andrushchenko
Building for a 32-bit target results in warnings from casting
between a 32-bit pointer and a 64-bit integer. Fix the warnings
by casting those pointers to uintptr_t first.
Signed-off-by: Oleksandr Andrushchenko
---
Changes since v1:
- remove unneeded u64 and phys_
On 23/05/18 13:36, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Building for a 32-bit target results in warnings from casting
> between a 32-bit pointer and a 64-bit integer. Fix the warnings
> by casting those pointers to uintptr_t first.
>
> Signed-off-by: Oleksandr Andru
On 22/05/2018, 12:45, "Ian Jackson" wrote:
CC: Lars Kurth
CC: Julien Grall
Acked-by: Juergen Gross
Signed-off-by: Ian Jackson
---
docs/process/xen-release-management.pandoc | 5 +
1 file changed, 5 insertions(+)
diff --git a/docs/process/xen-re
>>> On 22.05.18 at 17:52, wrote:
> XPTI speed-ups?
I now do have backports to 4.8 as well as 4.7, so including them is now an
option (also for 4.7.6), the more that we still need to apply the XSA-263
patches there anyway, and there's also still this feature leveling regression
on both branches th
On 22/05/18 05:54, Boris Ostrovsky wrote:
> We are making calls to C code (e.g. xen_prepare_pvh()) which may use
> stack canary (stored in GS segment).
>
> Signed-off-by: Boris Ostrovsky
With the clearing of EDX (instead using CDQ) you can add my
Reviewed-by: Juergen Gross
Juergen
_
On 22/05/18 05:54, Boris Ostrovsky wrote:
> We don't need to share PVH GDT layout with other GDTs, especially
> since we now have a PVH-speciific entry (for stack canary segment).
>
> Define PVH's own selectors.
>
> (As a side effect of this change we are also fixing improper
> reference to __KER
flight 123003 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123003/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1e35fcc9ee8b6b991535d9d6731d0e04169b99c0
baseline version:
ovmf 7ebad830d6ab61f0395f6
We don't need to share PVH GDT layout with other GDTs, especially
since we now have a PVH-speciific entry (for stack canary segment).
Define PVH's own selectors.
(As a side effect of this change we are also fixing improper
reference to __KERNEL_CS)
Signed-off-by: Boris Ostrovsky
Reviewed-by: Ju
Fix stack canary handling (in the first patch) and re-index PVH GDT to
make it explicit that the GDT PVH-specific
v5:
- Load canary's physical address and clear %edx for 64-bit mode
Boris Ostrovsky (2):
xen/PVH: Set up GS segment for stack canary
xen/PVH: Make GDT selectors PVH-specific
arc
We are making calls to C code (e.g. xen_prepare_pvh()) which may use
stack canary (stored in GS segment).
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
---
arch/x86/xen/xen-pvh.S | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/x86/
Juergen Gross writes ("Re: [Xen-devel] [PATCH v2 2/2]
docs/process/xen-release-management: Lesson to learn"):
> On 22/05/18 18:45, Ian Jackson wrote:
> > +7. Do not commit to a release date until
> > +
> > +* The exact xen.git commit id to be released is known.
> > +* That commit id has be
Ian Jackson writes ("[PATCH v2 0/2] Release process: lesson to learn"):
> This is my third attempt to get consensus for this. We had a
> discussion about this in December and again in April.
I think I have enough acks now, so I intend to push this staging,
subject to checking with Juergen about t
Now that we have a per-domain flag we can and should control sync-ing in
a more fine grained manner: Only domains having XPTI enabled need the
sync to occur.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3765,7 +3765,7 @@
break;
Ian Jackson writes ("Mysterious one-off libvirt build failure"):
> I am trying to commission some new test boxes. One of my test flights
> experienced a weird build failure:
>
>
> http://logs.test-lab.xenproject.org/osstest/logs/123046/build-i386-libvirt/6.ts-libvirt-build.log
>
> For your con
tl;dr:
I think there is a bug in libvirt's build system which, with
low probability, causes a build failure containing this message:
/usr/bin/ld: cannot find -lvirt
Complete build logs of two attempts:
http://logs.test-lab.xenproject.org/osstest/logs/123046/build-i386-libvirt/6.ts-libvirt-b
From: Huaisheng Ye
Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.
Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks,
the bottom three bits of GFP mask is reserved for storing encoded
zone number.
The encoding method is XOR. Get zone number from enum zone_ty
From: Huaisheng Ye
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM).
In function xen_swiotlb_alloc_coherent, it is obvious that __GFP_DMA32
is not the expecting zone type.
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mas
From: Huaisheng Ye
Changes since v2: [2]
* According to Christoph's suggestion, rebase patches to current
mainline from v4.16.
* Follow the advice of Matthew, create macros like GFP_NORMAL and
GFP_NORMAL_UNMOVABLE to clear bottom 3 and 4 bits of GFP bitmask.
* Delete some patches because of
On 23/05/18 15:24, Jan Beulich wrote:
> Now that we have a per-domain flag we can and should control sync-ing in
> a more fine grained manner: Only domains having XPTI enabled need the
> sync to occur.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
From: Huaisheng Ye
GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE,
modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD.
Signed-off-by: Huaisheng Ye
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc: Philippe Ombredanne
Cc: Christoph Hellwig
---
i
>>> On 23.05.18 at 16:30, wrote:
> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
> /* 64-bit entry point. */
> .code64
> 1:
> + /* Set base address in stack canary descriptor. */
> + mov $MSR_GS_BASE,%ecx
> + mov $_pa(canary), %rax
> + xor %rdx, %rdx
Why rax and rdx instea
On Tue, May 22, 2018 at 12:20:38PM +0100, Andrew Cooper wrote:
> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
> b/xen/include/asm-x86/hvm/vmx/vmcs.h
> index 06c3179..c8a1f89 100644
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -514,9 +514,6 @@ enum v
From: Michal Hocko [mailto:mho...@kernel.org]
Sent: Wednesday, May 23, 2018 2:37 AM
>
> On Mon 21-05-18 23:20:21, Huaisheng Ye wrote:
> > From: Huaisheng Ye
> >
> > Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.
> >
> > Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GF
This will allow us to exclude certain hosts. For example, right now,
we have no support for booting FreeBSD on UEFI hosts.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
make-flight | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/make-flight b/make-flight
index 6b53c94.
make-*-flight is going to want this.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
mg-anoint | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/mg-anoint b/mg-anoint
index 522cbdd..d09124b 100755
--- a/mg-anoint
+++ b/mg-anoint
@@ -15,10 +15,12 @@
#-
stretch still needs some of this, in particular the XSM changes.
Signed-off-by: Ian Jackson
---
overlay-jessie/etc/grub.d/20_linux_xen | 220
overlay-stretch/etc/grub.d/20_linux_xen | 220
overlay-wheezy/etc/grub.d/20_linux_xen
This must occur before mknetbootdir, or mknetbootdir does not set
things up for UEFI booting.
Signed-off-by: Ian Jackson
---
README.dev | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/README.dev b/README.dev
index de04b98..a2e46f9 100644
--- a/README.dev
+++ b/README.dev
This table was erroneously never used. Also, the value for arm64 is
wrong: it should be AA64. We fix the table value, and substitute it
in, for no overall change on amd64. On other arches we now do not
hardcode the wrong value.
Signed-off-by: Ian Jackson
CC: Julien Grall
---
Osstest/TestSupp
Signed-off-by: Ian Jackson
---
README.dev | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.dev b/README.dev
index ddfac30..de04b98 100644
--- a/README.dev
+++ b/README.dev
@@ -30,8 +30,8 @@ Keeps running for the duration, so run it in a screen on the
osstest VM.
Some versions of the bootloader scripts will make menu entries for
`.config' files, containing the hypervisor config. These should be
ignored.
(It is not clear to me, given our 20_linux_xen hack, whether this is
in fact an upstream bug, or a bug in 20_linux_xen.)
Signed-off-by: Ian Jackson
---
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 125d499..8e72405 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -821,6 +821,7 @@ sub debian_overlays
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index b9891b6..16b47c5 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -830,8 +830,11 @@ sub debian_overlays ($$) {
die "debian_overl
This suppresses:
Partition disks
---
This machine's firmware has started the installer in UEFI mode but it looks
like there may be existing operating systems already installed using "BIOS
compatibility mode". If you continue to install Debian in UEFI mode, it might
b
This makes them better for cutting-and-pasting.
Signed-off-by: Ian Jackson
---
README.dev | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/README.dev b/README.dev
index a2e46f9..a8bfbb5 100644
--- a/README.dev
+++ b/README.dev
@@ -112,9 +112,10 @@ Firstly, a basic
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 8f798a3..cebeb0d 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2635,7 +2635,10 @@ sub setup_ne
Previously, `make-*-flight' would not work unless FREEBSD_*_BUILDJOB
was set. Now we use the anointed values if we can find them.
If we can't, mg-anoint retrieve will print a warning.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
mfi-common | 8
1 file changed, 8 insertions(+)
Three more files which missed out on
dea987c5ab11 "PERLLIB, @INC: Use BEGIN { }"
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
mg-anoint | 2 +-
ts-examine-hostprops-save | 2 +-
ts-freebsd-host-install | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --gi
I think, no change with any reasonable configs.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8e72405..b9891b6 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -830,8 +830,
This variable is not used, and is shadowed by the one which is
initialised a few lines later. This produces a warning.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 1 -
1 file changed, 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index b46d222..eafc6cd 100644
--- a/Os
grub2 from stretch cannot boot Xen under UEFI. But that from buster
can, and it can be simply installed, even on jessie. So do that.
I have copied the binaries for 2.02+dfsg1-4 to
images/grub2-uefi-amd64-2018-04-01 in Massachusetts.
Signed-off-by: Ian Jackson
---
production-config | 5 +
This means that it is now OK not to have an `overlay-local'.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 0185761..125d499 100644
--- a/Osstest/Debian.pm
+++ b/Oss
Logically, the final branch of the if should be qualified with a check
for the emptiness of FreeBSDDist. This is awkward in the current
structure, since we really want to do the distpath lookup only if
needed. (This is not very important right now, but we are about to
add another case which will
This is necessary for UEFI. The patch is similar in spirit to the
upstream commit
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=b4d709b6ee789cdaf3fa7a80fd90c721a16f48c2
A backport of that commit to Debian buster was requested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898947
No functional change.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 6 +++---
ts-debian-fixup | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 2f5135d..019893d 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -813,
From: Ian Jackson
I am trying to commission some new hosts. These patches fix problems
I encountered. There are fixes to:
* Better support UEFI x86 hosts.
* Improve the commissioning instructions in README.dev.
* Handle the new FreeBSD anointments system in make-*-flight in
production (E
We are going to sometimes switch to the multiboot2 protocol, which has
different directives with very similar effect.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 97d451
This makes `mg-anoint' in standalone mode a view onto an empty set of
anointments. So now it becomes ok to call mg-anoint in make-*-flight.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
Osstest/JobDB/Executive.pm | 2 ++
Osstest/JobDB/Standalone.pm | 2 ++
mg-anoint |
On Tue, May 22, 2018 at 12:20:39PM +0100, Andrew Cooper wrote:
> * Use an arch_vmx_struct local variable to reduce later code volume.
> * Use start/total instead of msr_area/msr_count. This is in preparation for
>more finegrained handling with later changes.
> * Use ent/end pointers (again
From: Huaisheng Ye
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA32 | __GFP_HIGHMEM).
In function alloc_extent_state, it is obvious that __GFP_DMA is not
the expecting zone type.
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is res
From: Huaisheng Ye
Changes since v2: [2]
* According to Christoph's suggestion, rebase patches to current
mainline from v4.16.
* Follow the advice of Matthew, create macros like GFP_NORMAL and
GFP_NORMAL_UNMOVABLE to clear bottom 3 and 4 bits of GFP bitmask.
* Delete some patches because of
From: Huaisheng Ye
Replace GFP_ZONE_TABLE and GFP_ZONE_BAD with encoded zone number.
Delete ___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 from GFP bitmasks,
the bottom three bits of GFP mask is reserved for storing encoded
zone number.
The encoding method is XOR. Get zone number from enum zone_ty
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 sh
On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote:
> Instead of having multiple algorithms searching the MSR lists, implement a
> single one. It has the semantics required by vmx_add_msr(), to identify the
> position in which an MSR should live, if it isn't already present.
>
> There
On 23/05/18 17:28, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:39PM +0100, Andrew Cooper wrote:
>> * Use an arch_vmx_struct local variable to reduce later code volume.
>> * Use start/total instead of msr_area/msr_count. This is in preparation for
>>more finegrained handling with l
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM).
In function xen_swiotlb_alloc_coherent, it is obvious that __GFP_DMA32
is not the expecting zone type.
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mas
On 23/05/18 17:39, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:40PM +0100, Andrew Cooper wrote:
>> Instead of having multiple algorithms searching the MSR lists, implement a
>> single one. It has the semantics required by vmx_add_msr(), to identify the
>> position in which an MSR should
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA32 | __GFP_HIGHMEM).
In function alloc_extent_state, it is obvious that __GFP_DMA is not
the expecting zone type.
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is res
On 5/18/2018 4:31 AM, Paolo Bonzini wrote:
On 16/05/2018 22:27, Maran Wilson wrote:
Friendly ping. I am hopeful one of the x86 and/or KVM maintainers has a
few cycles to spare to look this over.
And thanks to everyone who has helped thus far by providing valuable
feedback and reviewing.
ht
On 05/23/2018 11:41 AM, Jan Beulich wrote:
On 23.05.18 at 16:30, wrote:
>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>> /* 64-bit entry point. */
>> .code64
>> 1:
>> +/* Set base address in stack canary descriptor. */
>> +mov $MSR_GS_BASE,%ecx
>> +mov $_pa(canary), %rax
On 23/05/18 17:01, Roger Pau Monné wrote:
> On Tue, May 22, 2018 at 12:20:38PM +0100, Andrew Cooper wrote:
>> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
>> b/xen/include/asm-x86/hvm/vmx/vmcs.h
>> index 06c3179..c8a1f89 100644
>> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
>> +++ b/xen/include/as
From: Huaisheng Ye
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE
From: Huaisheng Ye
GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE,
modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD.
Signed-off-by: Huaisheng Ye
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc: Philippe Ombredanne
Cc: Christoph Hellwig
---
i
From: Huaisheng Ye
GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE,
modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD.
Signed-off-by: Huaisheng Ye
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: x...@kernel
From: Huaisheng Ye
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE
flight 123010 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123010/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122962
test-armhf-armhf-libvirt 14 saveresto
From: Huaisheng Ye
Use __GFP_ZONE_MOVABLE to replace (__GFP_HIGHMEM | __GFP_MOVABLE).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_ZONE_MOVABLE contains encoded ZONE_MOVABLE
Hello Stefano,
On 22.05.18 02:45, Stefano Stabellini wrote:
I am not sure I understand your suggestion. But I think we are heading
in the direction you are hinting toward with Juergen's suggestion to
only keep kconfig options that are not "default". If you give a look at
v2, the rcar3.config is
flight 123009 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123009/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail REGR. vs.
122512
Tests which
Hello Stefano,
On 23.05.18 03:25, Stefano Stabellini wrote:
Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
---
Changes in v3:
- rename SMMUv2 to ARM_SMMU
- improve help message
- use if ARM
Changes in v2:
- rename HAS
Committers,
Please don't push any new patch to staging because osstest should
catch up to do a push.
Another email will be sent once the moratorium is lifted.
Juergen Gross
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenpr
Hi all,
Following up from previous conversations with the committers, I am
appending a proposal for a new Xen Project sub-project aimed at embedded
and IoT.
Sponsors are very welcome! :-)
Cheers,
Stefano
Changes in v2:
- clarify the x86_64 requirement
---
# ViryaOS
## Mission
To create an
On Wed, 23 May 2018, Jan Beulich wrote:
> >>> On 22.05.18 at 22:08, wrote:
> > On Tue, 22 May 2018, Jan Beulich wrote:
> >> >>> On 22.05.18 at 02:53, wrote:
> >> > +$(eval tmpfile := $(shell mktemp))
> >> > +$(foreach f, $(shell find $(BASEDIR) -name *.o.d), \
> >> > +
From: Huaisheng Ye
GFP_HIGHUSER_MOVABLE doesn't equal to GFP_HIGHUSER | __GFP_MOVABLE,
modify it to adapt patch of getting rid of GFP_ZONE_TABLE/BAD.
Signed-off-by: Huaisheng Ye
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: x...@kernel
From: Huaisheng Ye
Use __GFP_ZONE_MASK to replace (__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32).
___GFP_DMA, ___GFP_HIGHMEM and ___GFP_DMA32 have been deleted from GFP
bitmasks, the bottom three bits of GFP mask is reserved for storing
encoded zone number.
__GFP_DMA, __GFP_HIGHMEM and __GFP_DMA32 sh
flight 123118 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123118/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
examine-fiano02 hosts-allocate broken REGR. vs. 122584
ex
On Wed, 23 May 2018, Andrii Anisov wrote:
> Hello Stefano,
>
>
> On 23.05.18 03:25, Stefano Stabellini wrote:
> > Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: jbeul...@suse.com
> >
> > ---
> > Changes in v3:
> > - rename SMM
1 - 100 of 173 matches
Mail list logo
