AFAIU we don't need special actions on rpm update to switch to using
virt-guest-shutdown.target. Domains started before update will
stay depend upon libvirt-guests.service, newly started domains
will depend upon virt-guest-shutdown.target. On reboot/shutdown
systemd will order stopping both old and
It is already discussed in "[RFC] daemon: remove hardcode dep on
libvirt-guests" [1].
Mgmt can use means to save/restore domains on system shutdown/boot other then
libvirt-guests.service. Thus we need to specify appropriate ordering dependency
between
libvirtd, domains and save/restore service.
On Fri, Oct 14, 2016 at 11:52:22AM +1100, Sam Bobroff wrote:
On Thu, Oct 13, 2016 at 11:34:43AM +0200, Martin Kletzander wrote:
On Thu, Oct 13, 2016 at 11:34:16AM +1100, Sam Bobroff wrote:
>On Wed, Oct 12, 2016 at 10:27:50AM +0200, Martin Kletzander wrote:
>>On Wed, Oct 12, 2016 at 03:04:53PM +1
So that you can see nice report on migration:
"error: operation failed: migration of disk sda failed: No space left on device"
diff from v1:
1. drop 1 patch. Avoiding default label in switches is desired style.
2. drop 2 patch. I do not investigate enough to touch that place.
3. fix 3 patch
a)
---
src/qemu/qemu_blockjob.c | 13 +--
src/qemu/qemu_blockjob.h | 3 ++-
src/qemu/qemu_domain.c | 1 +
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_driver.c | 4 ++--
src/qemu/qemu_migration.c| 54 +++-
src/qemu/qemu_
From: Chen Hanxiao
If we failed to unlink old dom cfg file, we goto rollback.
But inside rollback, we fogot to unlink the new dom cfg file.
This patch fixes this issue.
Signed-off-by: Chen Hanxiao
---
src/qemu/qemu_driver.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/q
On 10/04/2016 09:06 AM, Nitesh Konkar wrote:
> Currently the migration stream references the memory
> blocks by name (which is supplied by libvirt) rather
> than by there order. With the current code that is
> assigning aliases for memory backend objects this
> won't happen and since qemu is trea
On Thu, 2016-09-29 at 15:20 -0400, Laine Stump wrote:
> For machinetypes with a pci-root bus (all legacy PCI), libvirt will
> make a "fake" reservation for one extra slot prior to assigning
> addresses to unaddressed PCI endpoint devices in the domain. This will
> trigger auto-adding of a pci-bridg
On Thu, 2016-09-29 at 15:20 -0400, Laine Stump wrote:
> In the absense of anything configurable, we will need to pick a number
> though. I've done that here, and now we can argue about it (or not :-)
Ján raised an interesting point: whatever number we choose,
no matter how wrong doing so is, some
[...]
>>
>> I have written this lines as a part of GPLv2+ boilerplate:
>> https://www.redhat.com/archives/libvir-list/2016-August/msg01160.html,
>> which I took from
>> other libvirt parts. And I guess it was naturally to change name and
>> company, don't you?
>> And again, if you insist I can le
On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wrote:
> Add an optional "tls='yes'" option for a TCP chardev for the
> express purpose to enable setting up TLS for the chardev. This
> will assume that the qemu.conf settings have been adjusted as
> well as the environment configured properly.
On 10/05/2016 10:43 AM, Nikolay Shirokovskiy wrote:
> adding cc
>
> On 26.09.2016 13:36, Nikolay Shirokovskiy wrote:
>>
>> On 26.09.2016 13:04, Peter Krempa wrote:
>>> On Mon, Sep 26, 2016 at 12:15:42 +0300, Nikolay Shirokovskiy wrote:
On 26.09.2016 12:01, Peter Krempa wrote:
>>> [...]
>>>
>>>
On 10/14/2016 09:18 AM, Pavel Hrdina wrote:
> On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wrote:
>> Add an optional "tls='yes'" option for a TCP chardev for the
>> express purpose to enable setting up TLS for the chardev. This
>> will assume that the qemu.conf settings have been adjuste
On 10/14/2016 09:13 AM, Andrea Bolognani wrote:
On Thu, 2016-09-29 at 15:20 -0400, Laine Stump wrote:
In the absense of anything configurable, we will need to pick a number
though. I've done that here, and now we can argue about it (or not :-)
Ján raised an interesting point: whatever number we
On Fri, Oct 14, 2016 at 09:32:45AM -0400, John Ferlan wrote:
>
>
> On 10/14/2016 09:18 AM, Pavel Hrdina wrote:
> > On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wrote:
> >> Add an optional "tls='yes'" option for a TCP chardev for the
> >> express purpose to enable setting up TLS for the c
On Fri, Oct 07, 2016 at 12:20:19PM -0400, John Ferlan wrote:
On 09/27/2016 08:24 AM, Martin Kletzander wrote:
QEMU added support for ivshmem-plain and ivshmem-doorbell. Those are
reworked varians of legacy ivshmem that are compatible from the guest
POV, but not from host's POV and have sane s
Add an internal variable to mark the FD as "not owned" by the
virNetSocket, in case the internal implementation takes the actual
ownership of the descriptor; this avoids a warning when closing the
socket, as the FD would be invalid.
---
src/rpc/virnetsocket.c | 5 -
1 file changed, 4 insertion
Hi,
this series introduces a new libssh transport in libvirt, based on the
libssh C library. This library supports what libssh2 does, and more:
- easier API for known_hosts handling (there's a ticket upstream to
request extensions for it, but what is implemented now works well)
- potential GSSA
Implement a new libssh transport, which uses libssh to communicate with
remote hosts, and use it in virNetSockets.
This new transport supports all the common ssh authentication methods,
making use of libvirt's auth callbacks for interaction with the user.
Most of the functionalities and implement
On Fri, Oct 07, 2016 at 01:05:29PM -0400, John Ferlan wrote:
On 09/27/2016 08:24 AM, Martin Kletzander wrote:
This is needed in order to migrate a domain with shmem devices as that
is not allowed to migrate.
Sure, but how would anyone know since the migration fails... Not sure
where could/sh
On 10/14/2016 09:49 AM, Pavel Hrdina wrote:
> On Fri, Oct 14, 2016 at 09:32:45AM -0400, John Ferlan wrote:
>>
>>
>> On 10/14/2016 09:18 AM, Pavel Hrdina wrote:
>>> On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wrote:
Add an optional "tls='yes'" option for a TCP chardev for the
e
On Fri, Feb 5, 2016 at 2:56 PM, Gromak Yuriy wrote:
> Qemu is latest from master branch.
> Tryingto start a domain, which is connected toa blankcdrom:
>
>
>
>
>
>
>
>
> But I get an error:
>
> qemu-system-x86_64: -drive
> if=none,id=dri
[...]
>>> +int
>>> +qemuDomainDetachShmemDevice(virQEMUDriverPtr driver,
>>> +virDomainObjPtr vm,
>>> +virDomainDeviceDefPtr dev)
>>> +{
>>> +int ret = -1;
>>> +ssize_t idx = -1;
>>> +virErrorPtr orig_err = NULL;
>>> +virDom
[...]
>>> +char *
>>> +qemuBuildShmemDevStr(virDomainDefPtr def,
>>> + virDomainShmemDefPtr shmem,
>>> + virQEMUCapsPtr qemuCaps)
>>> +{
>>> +virBuffer buf = VIR_BUFFER_INITIALIZER;
>>> +
>>> +virBufferAsprintf(&buf, "%s",
>>> virDomainShmemModelType
This is not a blurb.
Ján Tomko (4):
qemuBuildHostNetStr: use type_sep earlier
qemuBuildHostNetStr: do not start options with a comma
qemuBuildHostNetStr: move stray VIR_DOMAIN_NET_TYPE_INTERNAL
qemuBuildHostNetStr: remove dead code
src/qemu/qemu_command.c | 49 +--
Put the comma at the end and trim it later for consistency.
---
src/qemu/qemu_command.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index eba7ba9..80ebe51 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/q
This network type is only used by the vbox driver and it does not
make sense to group it with VIR_DOMAIN_NET_TYPE_USER.
Introduced by commit 1dcbef8.
---
src/qemu/qemu_command.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
When hotplugging networks with ancient QEMUs not supporting
QEMU_CAPS_NETDEV, we use space instead of a comma as the separator
between the network type and other options.
Except for "user", all the network types pass other options
and use up the first separator by the time we get to the section
th
This function is never called for VIR_DOMAIN_NET_TYPE_HOSTDEV,
and the dead code comment agrees.
Introduced by commit 1dcbef8a.
---
src/qemu/qemu_command.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 19ee652..a
On Fri, Oct 14, 2016 at 10:16:19AM -0400, John Ferlan wrote:
>
>
> On 10/14/2016 09:49 AM, Pavel Hrdina wrote:
> > On Fri, Oct 14, 2016 at 09:32:45AM -0400, John Ferlan wrote:
> >>
> >>
> >> On 10/14/2016 09:18 AM, Pavel Hrdina wrote:
> >>> On Fri, Oct 07, 2016 at 07:00:26AM -0400, John Ferlan wr
On Fri, Oct 14, 2016 at 10:25:26AM -0400, John Ferlan wrote:
[...]
+int
+qemuDomainDetachShmemDevice(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+virDomainDeviceDefPtr dev)
+{
+int ret = -1;
+ssize_t idx = -1;
+virErrorPtr
On Fri, Oct 14, 2016 at 10:19:58AM -0400, John Ferlan wrote:
[...]
+char *
+qemuBuildShmemDevStr(virDomainDefPtr def,
+ virDomainShmemDefPtr shmem,
+ virQEMUCapsPtr qemuCaps)
+{
+virBuffer buf = VIR_BUFFER_INITIALIZER;
+
+virBufferAsprintf(&buf, "
On Fri, Oct 07, 2016 at 07:00:27AM -0400, John Ferlan wrote:
> Add a new qemu.conf variables to store the UUID for the secret that could
> be used to present credentials to access the TLS chardev. Since this will
> be a server level and it's possible to use some sort of default, introduce
> both t
On Fri, Oct 14, 2016 at 03:13:16PM +0200, Andrea Bolognani wrote:
On Thu, 2016-09-29 at 15:20 -0400, Laine Stump wrote:
In the absense of anything configurable, we will need to pick a number
though. I've done that here, and now we can argue about it (or not :-)
Ján raised an interesting point:
[...]
>>
>> UGH... mea culpa - in my mind the TLS hadn't been added to the chardev
>> yet and that was the rest of this series... Of course the rest of this
>> series is adding the passphrase for the environment ().
>>
>> If I could have got that review earlier, then this situation wouldn't be
>>
On 14/10/16 16:15, John Ferlan wrote:
[...]
I have written this lines as a part of GPLv2+ boilerplate:
https://www.redhat.com/archives/libvir-list/2016-August/msg01160.html,
which I took from
other libvirt parts. And I guess it was naturally to change name and
company, don't you?
And again, if
On Tue, Oct 11, 2016 at 01:41:30PM +0200, Igor Mammedov wrote:
[...]
> >
> > Oops, leftover from v5. Thanks for spotting that! Fixup below.
> >
> > Signed-off-by: Eduardo Habkost
> Reviewed-by: Igor Mammedov
Thanks. Patch + fixup applied to x86-next.
--
Eduardo
--
libvir-list mailing list
l
On Tue, Oct 11, 2016 at 04:13:44PM +0200, Igor Mammedov wrote:
> On Fri, 7 Oct 2016 17:29:02 -0300
> Eduardo Habkost wrote:
>
> > Fill the "unavailable-features" field on the x86 implementation
> > of query-cpu-definitions.
> >
> > Cc: Jiri Denemark
> > Cc: libvir-list@redhat.com
> > Signed-of
On 10/07/2016 12:43 PM, Jiri Denemark wrote:
> GCC on s390 complains
>
> util/virconf.c: In function 'virConfGetValueSizeT':
> util/virconf.c:1220:9: error: format '%zu' expects argument of type
> 'size_t', but argument 9 has type 'unsigned int' [-Werror=format=]
>
> Signed-off-by: Jiri Denemark
On 10/07/2016 12:43 PM, Jiri Denemark wrote:
> GCC on s390 complains
>
> util/virconf.c: In function 'virConfGetValueSizeT':
> util/virconf.c:1220:9: error: format '%zu' expects argument of type
> 'size_t', but argument 9 has type 'unsigned int' [-Werror=format=]
>
> Signed-off-by: Jiri Denemark
On Fri, Oct 14, 2016 at 10:58:12AM -0400, John Ferlan wrote:
> [...]
> >>
> >> UGH... mea culpa - in my mind the TLS hadn't been added to the chardev
> >> yet and that was the rest of this series... Of course the rest of this
> >> series is adding the passphrase for the environment ().
> >>
> >> I
On Fri, 2016-10-14 at 16:54 +0200, Ján Tomko wrote:
> Also, would it be possible to make this feature of leaving
> free hot-pluggable slots opt-in?
>
> E.g. a without an index
> would be considered a port where we should not put devices
> with auto-assigned addresses.
>
> (This might actually be
On Thu, 2016-10-13 at 13:43 -0400, Laine Stump wrote:
> > > > > +if (nbuses > 0 && !addrs->buses[0].model) {
> > > > > +if
(virDomainPCIAddressBusSetModel(&addrs->buses[0],
> > > > > +
> > > > > VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT) < 0)
> > >
On 10/14/2016 01:20 PM, Andrea Bolognani wrote:
On Thu, 2016-10-13 at 13:43 -0400, Laine Stump wrote:
+if (nbuses > 0 && !addrs->buses[0].model) {
+if (virDomainPCIAddressBusSetModel(&addrs->buses[0],
+ VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT)
Although the migration port is immediately released in the
finish phase of migration, it was never set in the domain
private object when allocated in the prepare phase. So
libxlDomainMigrationFinish() always released a 0-initialized
migrationPort, leaking any allocated port. After enough
migrations
On 10/13/2016 11:44 AM, Andrea Bolognani wrote:
The code is entirely correct, but it still managed to trip me
up when I first ran into it because I did not realize right away
that VIR_PCI_CONNECT_TYPES_ENDPOINT was not a single flag, but
rather a mask including both VIR_PCI_CONNECT_TYPE_PCI_DEVIC
On 10/14/2016 11:30 AM, Pavel Hrdina wrote:
> On Fri, Oct 14, 2016 at 10:58:12AM -0400, John Ferlan wrote:
>> [...]
UGH... mea culpa - in my mind the TLS hadn't been added to the chardev
yet and that was the rest of this series... Of course the rest of this
series is adding t
There's no functional change here. This pointer was just used so many
times that the extra long lines became annoying.
---
Change: added more instances of the same change.
src/qemu/qemu_domain_address.c | 208 ++---
1 file changed, 111 insertions(+), 97 deleti
These functions provide a simple one line method of learning if the
current domain has a pci-root or pcie-root bus.
---
Changes: "reversed polarity" of 2nd if clause as suggested by Andrea.
src/qemu/qemu_domain.c | 30 ++
src/qemu/qemu_domain.h | 2 ++
2 files change
This patch cleans up the connect flags for certain types/models of
devices that aren't PCI to return 0. In the future that may be used as
an indicator to the caller about whether or not a device needs a PCI
address. For now it's just ignored, except for in
virDomainPCIAddressEnsureAddr() - called d
I'm undecided if it is worthwhile to add this...
Up until now it has been legal to have something like this in the xml:
(for example, see the existing test case
"usb-controller-default-q35"). This is handled in
qemuDomainPCIAddressSetCreate() when it's adding in controllers to
fill holes
Andrea had the right idea when he disabled the "reserve an extra
unused slot" bit for aarch64/virt. For *any* PCI Express-based
machine, it is pointless since 1) an extra legacy-PCI slot can't be
used for hotplug, since hotplug into legacy PCI slots doesn't work on
PCI Express machinetypes, and 2)
The lowest level function of this trio
(qemuDomainDeviceCalculatePCIConnectFlags()) aims to be the single
authority for the virDomainPCIConnectFlags to use for any given device
using a particular arch/machinetype/qemu-binary.
qemuDomainFillDevicePCIConnectFlags() sets info->pciConnectFlags in a
si
There is an existing virDomainPCIAddressReserveNextSlot() which will
reserve all functions of the next available PCI slot. One place in the
qemu PCI address assignment code requires reserving a *single*
function of the next available PCI slot. This patch modifies and
renames virDomainPCIAddressRese
More occurences of repeatedly dereferencing the same pointer stored in
an array are replaced with the definition of a temporary pointer that
is then used directly. No functional change.
---
src/qemu/qemu_domain_address.c | 41 +++--
1 file changed, 23 insertions
The latest version of patches to auto-assign appropriate devices in
PCIe-capable domains to PCIe slots rather than legacy PCI, and to also
auto-add pcie-root-ports as necessary to make this easier.
I *think* I've dealt with all of Andrea's great critiques of V3,
either in my email responses or in
An upcoming commit will remove the "flag" argument from all the calls
to reserve the next available address|slot, but I don't want to change
the arguments in the hypervisor-agnostic
virDomainPCIAddressReserveNext*() functions, so this patch places a
simple qemu-specific wrapper around those functio
Previously libvirt would only add pci-bridge devices automatically
when an address was requested for a device that required a legacy PCI
slot and none was available. This patch expands that support to
dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a
machine with a pcie-root), an
Before now, all the qemu hotplug functions assumed that all devices to
be hotplugged were legacy PCI endpoint devices
(VIR_PCI_CONNECT_TYPE_PCI_DEVICE). This worked out "okay", because all
devices *are* legacy PCI endpoint devices on x86/440fx machinetypes,
and hotplug didn't work properly on machi
from virDomainDefPtr to virDomainObjPtr so that the function has
access to the other parts of the virDomainObjPtr. Take advantage of
this by removing the "priv" arg and retrieving it from the
virDomainObjPtr instead.
No functional change.
---
src/qemu/qemu_hotplug.c | 7 ---
1 file changed, 4
libvirt previously assigned nearly all devices to a "hotpluggable"
legacy PCI slot even on machines with a PCIe root bus (and even though
most such machines don't even support hotplug on legacy PCI slots!)
Forcing all devices onto legacy PCI slots means that the domain will
need a dmi-to-pci-bridge
Set pciConnectFlags in each device's DeviceInfo and then use those
flags later when validating existing addresses in
qemuDomainCollectPCIAddress() and when assigning new addresses with
qemuDomainPCIAddressReserveNextAddr() (rather than scattering the
logic about which devices need which type of slo
This function is no longer needed outside of domain_addr.c.
---
src/conf/domain_addr.c | 2 +-
src/conf/domain_addr.h | 5 -
src/libvirt_private.syms | 1 -
3 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 1710220..3a9e474
Real Q35 hardware has an ICH9 chip that includes several integrated
devices at particular addresses (see the file docs/q35-chipset.cfg in
the qemu source). libvirt already attempts to put the first two sets
of ich9 USB2 controllers it finds at 00:1D.* and 00:1A.* to match the
real hardware. This pa
Previously we added a set of EHCI+UHCI controllers to Q35 machines to
mimic real hardware as closely as possible, but recent discussions
have pointed out that the nec-usb-xhci (USB3) controller is much more
virtualization-friendly (uses less CPU), so this patch switches the
default for Q35 machinet
The e1000e is an emulated network device based on the Intel 82574,
present in qemu 2.7.0 and later. Among other differences from the
e1000, it presents itself as a PCIe device rather than legacy PCI. In
order to get it assigned to a PCIe controller, this patch updates the
flags setting for network
For some reason the values of memballoon model are set using an
anonymous enum, making it impossible to perform nice tricks like
demanding there are cases for all possible values in a switch. This
patch turns the anonymous enum into virDomainMemBalloonModel.
---
src/conf/domain_conf.h | 4 ++--
1
For machinetypes with a pci-root bus (all legacy PCI), libvirt will
make a "fake" reservation for one extra slot prior to assigning
addresses to unaddressed PCI endpoint devices in the domain. This will
trigger auto-adding of a pci-bridge for the final device to be
assigned an address *if that devi
The nec-usb-xhci device (which is a USB3 controller) has always
presented itself as a PCI device when plugged into a legacy PCI slot,
and a PCIe device when plugged into a PCIe slot, but libvirt has
always auto-assigned it to a legacy PCI slot.
This patch changes that behavior to auto-assign to a
This is already set by virDomainPCIAddressSetAlloc().
---
src/qemu/qemu_domain_address.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index d2a3237..3926b18 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_
This error should only ever be seen by a developer anyway, but the
existing message made even less sense that this new version.
---
src/qemu/qemu_domain_address.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
ind
instead of calling virDomainPCIAddressGetNextSlot() (which I want to
turn into a local static in domain_addr.c).
---
Change: fixed line length
src/qemu/qemu_domain_address.c | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/src/qemu/qemu_doma
Now the a dmi-to-pci-bridge is automatically added just as it's needed
(when a pci-bridge is being added), we no longer have any need to
force-add one to every single Q35 domain.
---
src/qemu/qemu_domain.c | 12
tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args |
On 10/14/2016 10:53 AM, Pavel Hrdina wrote:
> On Fri, Oct 07, 2016 at 07:00:27AM -0400, John Ferlan wrote:
>> Add a new qemu.conf variables to store the UUID for the secret that could
>> be used to present credentials to access the TLS chardev. Since this will
>> be a server level and it's possi
https://bugzilla.redhat.com/show_bug.cgi?id=1300776
Complete the implementation of support for TLS encryption on
chardev TCP transports by adding the hotplug ability of a secret
to generate the passwordid for the TLS object
Likewise, add the ability to hot unplug that secret object as well
Signe
v8: http://www.redhat.com/archives/libvir-list/2016-October/msg00306.html
Differences to v8
1. Alter patch 1 such that it's not choosing to add the tls object based
on both a config and domain xml setting, rather that the decision point
is to avoid adding the config setting if the domain is
Add a new qemu.conf variables to store the UUID for the secret that could
be used to present credentials to access the TLS chardev. Since this will
be a server level and it's possible to use some sort of default, introduce
both the default and chardev logic at the same time making the setting of
t
Add an optional "tls='yes|no'" attribute for a TCP chardev for the
express purpose to disable setting up TLS for the specific chardev in
the event the qemu.conf settings have enabled hypervisor wide TLS for
serial TCP chardevs.
Signed-off-by: John Ferlan
---
docs/formatdomain.html.in
Modeled after the qemuDomainHostdevPrivatePtr (commit id '27726d8c'),
create a privateData pointer in the _virDomainChardevDef to allow storage
of private data for a hypervisor in order to at least temporarily store
secret data for usage during qemuBuildCommandLine.
NB: Since the qemu_parse_comman
Add the secret object prior to the chardev tcp so the 'passwordid=' can
be added if the domain XML has a for the chardev TLS.
Signed-off-by: John Ferlan
---
src/qemu/qemu_command.c| 32 ++-
src/qemu/qemu_command.h| 1 +
src/qemu/qemu_
80 matches
Mail list logo