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
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
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
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 |
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,
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
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,
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 +
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
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(+)
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
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
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
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
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
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
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
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 @@
#-
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 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.
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
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
>>> 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
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 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
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
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
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
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
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
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 ("[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
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
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/
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 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
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
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
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 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/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 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
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 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
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
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
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
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-
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/
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
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
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
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 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
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 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 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
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 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
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 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
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 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
101 - 173 of 173 matches
Mail list logo
