Commit Graph

155 Commits

Author SHA1 Message Date
Jan Kiszka 9b8c692435 memory: Return -1 again on reads from unsigned regions
This restore the behavior prior to b018ddf633 which accidentally changed
the return code to 0. Specifically guests probing for register existence
were affected by this.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-18 06:03:25 +02:00
Paolo Bonzini b4afea11aa memory: actually set the owner
Brown paper bag for me.  Originally commit 803c0816 came before commit
2c9b15c.  When the order was inverted, I left in the NULL initialization
of mr->owner.

Reviewed-by: Hu Tao <hutao@cn.fujitsu.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-18 06:03:25 +02:00
Andreas Färber 4917cf4432 cpu: Replace cpu_single_env with CPUState current_cpu
Move it to qom/cpu.h.

Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-07-09 21:20:28 +02:00
Paolo Bonzini 856d72454f memory: add reference counting to FlatView
With this change, a FlatView can be used even after a concurrent
update has replaced it.  Because we do not yet have RCU, we use a
mutex to protect the small critical sections that read/write the
as->current_map pointer.  Accesses to the FlatView can be done
outside the mutex.

If a MemoryRegion will be used after the FlatView is unref-ed (or after
a MemoryListener callback is returned), a reference has to be added to
that MemoryRegion. memory_region_find already does it for the region
that it returns.  The same will be done for address_space_translate
as soon as the dispatch tree is also converted to RCU-style.

Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:49 +02:00
Paolo Bonzini a9a0c06dd7 memory: use a new FlatView pointer on every topology update
This is the first step towards converting as->current_map to
RCU-style updates, where the FlatView updates run concurrently
with uses of an old FlatView.

Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:49 +02:00
Paolo Bonzini 99e86347fe memory: access FlatView from a local variable
We will soon require accesses to as->current_map to be placed under
a lock (with reference counting so as to keep the critical section
small).  To simplify this change, always fetch as->current_map into
a local variable and access it through that variable.

Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:49 +02:00
Paolo Bonzini dfde4e6e1a memory: add ref/unref calls
Add ref/unref calls at the following places:

- places where memory regions are stashed by a listener and
  used outside the BQL (including in Xen or KVM).

- memory_region_find callsites

- creation of aliases and containers (only the aliased/contained
  region gets a reference to avoid loops)

- around calls to del_subregion/add_subregion, where the region
  could disappear after the first call

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:45 +02:00
Paolo Bonzini 3ce10901ca memory: introduce memory_region_present
This new API will avoid having too many memory_region_ref/unref
in paths that currently use memory_region_find.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:45 +02:00
Paolo Bonzini 46637be269 memory: add ref/unref
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:45 +02:00
Paolo Bonzini 803c0816a7 memory: add getter for owner
Whenever memory regions are accessed outside the BQL, they need to be
preserved against hot-unplug.  MemoryRegions actually do not have their
own reference count; they piggyback on a QOM object, their "owner".
The owner is set at creation time, and there is a function to retrieve
the owner.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:45 +02:00
Paolo Bonzini 2c9b15cab1 memory: add owner argument to initialization functions
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:44 +02:00
Jan Kiszka b40acf99be ioport: Switch dispatching to memory core layer
The current ioport dispatcher is a complex beast, mostly due to the
need to deal with old portio interface users. But we can overcome it
without converting all portio users by embedding the required base
address of a MemoryRegionPortio access into that data structure. That
removes the need to have the additional MemoryRegionIORange structure
in the loop on every access.

To handle old portio memory ops, we simply install dispatching handlers
for portio memory regions when registering them with the memory core.
This removes the need for the old_portio field.

We can drop the additional aliasing of ioport regions and also the
special address space listener. cpu_in and cpu_out now simply call
address_space_read/write. And we can concentrate portio handling in a
single source file.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-07-04 17:42:44 +02:00
Andreas Färber c658b94f6e cpu: Turn cpu_unassigned_access() into a CPUState hook
Use it for all targets, but be careful not to pass invalid CPUState.
cpu_single_env can be NULL, e.g. on Xen.

Signed-off-by: Andreas Färber <afaerber@suse.de>
2013-06-28 13:25:13 +02:00
Peter Crosthwaite 2eb74e1a1e memory: render_memory_region: factor out fr constant setters
These 4 replicated lines set properties of fr that are constant over
the course of the function. Factor out their repeated setting (and also
guards against them being set multiple times in the loop below).

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20 16:39:52 +02:00
Peter Crosthwaite 41a6e477fd memory: as_update_topology_pass: Improve comments
These comments were a little difficult to read. First one had
incorrect parenthesis. The part about attributes changing is
really applicable to the region being 'in both' rather than 'in
new'

Second comment has an obscure parenthetic about 'Logging may have
changed'. Made clearer, as this if is supposed to handle the case where
the memory region is unchanged (with the notable exception re logging).

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20 16:39:52 +02:00
Peter Crosthwaite 8508e024cb memory: Fix comment typo
s/ajacent/adjacent

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20 16:39:52 +02:00
Alexey Kardashevskiy 7dca8043f3 memory: give name to every AddressSpace
The "info mtree" command in QEMU console prints only "memory" and "I/O"
address spaces while there are actually a lot more other AddressSpace
structs created by PCI and VIO devices. Those devices do not normally
have names and therefore not present in "info mtree" output.

The patch fixes this.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20 16:39:52 +02:00
David Gibson 068665757d memory: Add iommu map/unmap notifiers
This patch adds a NotifierList to MemoryRegions which represent IOMMUs
allowing other parts of the code to register interest in mappings or
unmappings from the IOMMU.  All IOMMU implementations will need to call
memory_region_notify_iommu() to inform those waiting on the notifier list,
whenever an IOMMU mapping is made or removed.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20 16:32:47 +02:00
Avi Kivity 3095115744 memory: iommu support
Add a new memory region type that translates addresses it is given,
then forwards them to a target address space.  This is similar to
an alias, except that the mapping is more flexible than a linear
translation and trucation, and also less efficient since the
translation happens at runtime.

The implementation uses an AddressSpace mapping the target region to
avoid hierarchical dispatch all the way to the resolved region; only
iommu regions are looked up dynamically.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Avi Kivity <avi.kivity@gmail.com>
[Modified to put translation in address_space_translate; assume
 IOMMUs are not reachable from TCG. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20 16:32:47 +02:00
Paolo Bonzini 052e87b073 memory: make section size a 128-bit integer
So far, the size of all regions passed to listeners could fit in 64 bits,
because artificial regions (containers and aliases) are eliminated by
the memory core, leaving only device regions which have reasonable sizes

An IOMMU however cannot be eliminated by the memory core, and may have
an artificial size, hence we may need 65 bits to represent its size.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-06-20 16:32:47 +02:00
Paolo Bonzini 791af8c861 memory: propagate errors on I/O dispatch
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29 16:27:32 +02:00
Paolo Bonzini 968a5627c8 memory: correctly handle endian-swapped 64-bit accesses
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29 16:27:26 +02:00
Paolo Bonzini ce5d2f331e memory: split accesses even when the old MMIO callbacks are used
This is useful for 64-bit memory accesses.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29 16:27:24 +02:00
Paolo Bonzini 08521e28c7 memory: add big endian support to access_with_adjusted_size
This will be used to split 8-byte access down to two four-byte accesses.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29 16:27:22 +02:00
Paolo Bonzini a014ed07bd memory: accept mismatching sizes in memory_region_access_valid
The memory API is able to use smaller/wider accesses than requested,
match that in memory_region_access_valid.  Of course, the accepts
callback is still free to reject those accesses.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29 16:27:19 +02:00
Paolo Bonzini d2702032b4 memory: export memory_region_access_valid to exec.c
We'll use it to implement address_space_access_valid.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29 16:27:11 +02:00
Paolo Bonzini 2cdfcf272d memory: assign MemoryRegionOps to all regions
This allows to remove the checks on section->readonly.  Simply,
write accesses to ROM will not be considered "direct" and will
go through mr->ops without any special intervention.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29 16:26:58 +02:00
Paolo Bonzini d197063fcf memory: move unassigned_mem_ops to memory.c
reservation_ops is already doing the same thing.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29 16:26:56 +02:00
Paolo Bonzini b018ddf633 memory: dispatch unassigned accesses based on .valid.accepts
This provides the basics for detecting accesses to unassigned memory
as soon as they happen, and also for a simple implementation of
address_space_access_valid.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-29 16:26:47 +02:00
Paolo Bonzini f43793c7ca memory: populate FlatView for new address spaces
Even a new address space might have a non-empty FlatView.  In order
to initialize it properly, address_space_init should (a) call
memory_region_transaction_commit after the address space is inserted
into the list; (b) force memory_region_transaction_commit to do something.

This bug was latent so far because all address spaces started empty, including
the PCI address space where the bus master region is initially disabled.
However, the target address space of an IOMMU is usually rooted at
get_system_memory(), which might not be empty at the time the IOMMU is created.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24 18:43:42 +02:00
Avi Kivity 4c19eb721a memory: fix address space initialization/destruction
A couple of fields were left uninitialized.  This was not observed earlier
because all address spaces were statically allocated.  Also free allocation
for those fields.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Avi Kivity <avi.kivity@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24 18:43:25 +02:00
Paolo Bonzini 1d671369c3 memory: make memory_global_sync_dirty_bitmap take an AddressSpace
Since this is a MemoryListener operation, it only makes sense
on an AddressSpace granularity.

Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24 18:42:51 +02:00
Paolo Bonzini 5553e3a5c9 memory: do not duplicate memory_region_destructor_none
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24 18:42:48 +02:00
Jan Kiszka 5f9a5ea1c0 memory: Rename readable flag to romd_mode
"Readable" is a very unfortunate name for this flag because even a
rom_device region will always be readable from the guest POV. What
differs is the mapping, just like the comments had to explain already.
Also, readable could currently be understood as being a generic region
flag, but it only applies to rom_device regions.

So rename the flag and the function to modify it after the original term
"ROMD" which could also be interpreted as "ROM direct", i.e. ROM mode
with direct access. In any case, the scope of the flag is clearer now.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24 18:42:46 +02:00
Paolo Bonzini 73034e9e08 memory: allow memory_region_find() to run on non-root memory regions
memory_region_find() is similar to registering a MemoryListener and
checking for the MemoryRegionSections that come from a particular
region.  There is no reason for this to be limited to a root memory
region.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-05-24 18:42:33 +02:00
Hu Tao 2c7cfd65b3 memory: fix a bug of detection of memory region collision
The collision reports before and after this patch are:

before:

warning: subregion collision cfc/4 (pci-conf-data) vs cf8/4 (pci-conf-idx)
warning: subregion collision 8000000/f8000000 (pci-hole) vs 0/8000000 (ram-below-4g)
warning: subregion collision 100000000/4000000000000000 (pci-hole64) vs 8000000/f8000000 (pci-hole)
warning: subregion collision 4d1/1 (kvm-elcr) vs 4d0/1 (kvm-elcr)
warning: subregion collision fec00000/1000 (kvm-ioapic) vs 8000000/f8000000 (pci-hole)
warning: subregion collision 80/1 (ioport80) vs 7e/2 (kvmvapic)
warning: subregion collision fed00000/400 (hpet) vs 8000000/f8000000 (pci-hole)
warning: subregion collision 81/3 (dma-page) vs 80/1 (ioport80)
warning: subregion collision 8/8 (dma-cont) vs 0/8 (dma-chan)
warning: subregion collision d0/10 (dma-cont) vs c0/10 (dma-chan)
warning: subregion collision 0/80 (ich9-pm) vs 8/8 (dma-cont)
warning: subregion collision 0/80 (ich9-pm) vs 0/8 (dma-chan)
warning: subregion collision 0/80 (ich9-pm) vs 64/1 (i8042-cmd)
warning: subregion collision 0/80 (ich9-pm) vs 60/1 (i8042-data)
warning: subregion collision 0/80 (ich9-pm) vs 61/1 (elcr)
warning: subregion collision 0/80 (ich9-pm) vs 40/4 (kvm-pit)
warning: subregion collision 0/80 (ich9-pm) vs 70/2 (rtc)
warning: subregion collision 0/80 (ich9-pm) vs 20/2 (kvm-pic)
warning: subregion collision 0/80 (ich9-pm) vs 7e/2 (kvmvapic)
warning: subregion collision 4/2 (acpi-cnt) vs 0/4 (acpi-evt)
warning: subregion collision 30/8 (apci-smi) vs 20/10 (apci-gpe0)
warning: subregion collision b0000000/10000000 (pcie-mmcfg) vs 8000000/f8000000 (pci-hole)

after:

warning: subregion collision fec00000/1000 (kvm-ioapic) vs 8000000/f8000000 (pci-hole)
warning: subregion collision fed00000/400 (hpet) vs 8000000/f8000000 (pci-hole)
warning: subregion collision 0/80 (ich9-pm) vs 8/8 (dma-cont)
warning: subregion collision 0/80 (ich9-pm) vs 0/8 (dma-chan)
warning: subregion collision 0/80 (ich9-pm) vs 64/1 (i8042-cmd)
warning: subregion collision 0/80 (ich9-pm) vs 60/1 (i8042-data)
warning: subregion collision 0/80 (ich9-pm) vs 61/1 (elcr)
warning: subregion collision 0/80 (ich9-pm) vs 40/4 (kvm-pit)
warning: subregion collision 0/80 (ich9-pm) vs 70/2 (rtc)
warning: subregion collision 0/80 (ich9-pm) vs 20/2 (kvm-pic)
warning: subregion collision 0/80 (ich9-pm) vs 7e/2 (kvmvapic)
warning: subregion collision b0000000/10000000 (pcie-mmcfg) vs 8000000/f8000000 (pci-hole)

Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-03-22 13:21:28 +01:00
Richard Henderson 5bbf90be97 memory: Use non-bitops ctzl
A memory size of zero is invalid, and so that edge condition
does not occur.

Signed-off-by: Richard Henderson <rth@twiddle.net>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2013-02-16 11:12:13 +00:00
Paolo Bonzini fbeadf50f2 bitops: unify bitops_ffsl with the one in host-utils.h, call it bitops_ctzl
We had two copies of a ffs function for longs with subtly different
semantics and, for the one in bitops.h, a confusing name: the result
was off-by-one compared to the library function ffsl.

Unify the functions into one, and solve the name problem by calling
the 0-based functions "bitops_ctzl" and "bitops_ctol" respectively.

This also fixes the build on platforms with ffsl, including Mac OS X
and Windows.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Andreas Färber <afaerber@suse.de>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2013-02-02 20:16:00 +00:00
Juan Quintela 6c279db8ee memory: introduce memory_region_test_and_clear_dirty
This function avoids having to do two calls, one to test the dirty bit, and
other to reset it.

Signed-off-by: Juan Quintela <quintela@redhat.com>
2012-12-20 23:09:39 +01:00
Paolo Bonzini 9c17d615a6 softmmu: move include files to include/sysemu/
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19 08:32:45 +01:00
Paolo Bonzini 1de7afc984 misc: move include files to include/qemu/
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19 08:32:39 +01:00
Paolo Bonzini 022c62cbbc exec: move include files to include/exec/
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19 08:31:31 +01:00
Jan Kiszka 7ea692b240 memory: Don't dump disabled regions
This makes "info mtree" output readable again.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2012-11-10 13:24:39 +00:00
Jan Kiszka 22bde71454 memory: Reintroduce dirty flag to optimize changes on disabled regions
Cirrus is triggering this, e.g. during Win2k boot: Changes only on
disabled regions require no topology update when transaction depth drops
to 0 again.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2012-11-10 12:30:12 +00:00
Avi Kivity d26a8caea3 memory: fix rendering of a region obscured by another
The memory core drops regions that are hidden by another region (for example,
during BAR sizing), but it doesn't do so correctly if the lower address of the
existing range is below the lower address of the new range.

Example (qemu-system-mips -M malta -kernel vmlinux-2.6.32-5-4kc-malta
         -append "console=ttyS0"  -nographic -vga cirrus):

Existing range: 10000000-107fffff
New range:      100a0000-100bffff

Correct behaviour: drop new range
Incorrect behaviour: add new range

Fix by taking this case into account (previously we only considered
equal lower boundaries).

Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-10-29 14:32:00 -05:00
Avi Kivity a8170e5e97 Rename target_phys_addr_t to hwaddr
target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
reserved) and its purpose doesn't match the name (most target_phys_addr_t
addresses are not target specific).  Replace it with a finger-friendly,
standards conformant hwaddr.

Outstanding patchsets can be fixed up with the command

  git rebase -i --exec 'find -name "*.[ch]"
                        | xargs s/target_phys_addr_t/hwaddr/g' origin

Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-10-23 08:58:25 -05:00
Anthony Liguori 50d2b4d93f Merge remote-tracking branch 'qemu-kvm/memory/urgent' into staging
* qemu-kvm/memory/urgent:
  memory: abort if a memory region is destroyed during a transaction
  i440fx: avoid destroying memory regions within a transaction
  memory: Make eventfd adhere to device endianness
2012-10-22 14:49:18 -05:00
Avi Kivity 83f3c25142 memory: add address_space_destroy()
Since address spaces can be created dynamically by device hotplug, they
can also be destroyed dynamically.

Signed-off-by: Avi Kivity <avi@redhat.com>
2012-10-22 14:50:08 +02:00
Avi Kivity ac1970fbe8 memory: per-AddressSpace dispatch
Currently we use a global radix tree to dispatch memory access.  This only
works with a single address space; to support multiple address spaces we
make the radix tree a member of AddressSpace (via an intermediate structure
AddressSpaceDispatch to avoid exposing too many internals).

A side effect is that address_space_io also gains a dispatch table.  When
we remove all the pre-memory-API I/O registrations, we can use that for
dispatching I/O and get rid of the original I/O dispatch.

Signed-off-by: Avi Kivity <avi@redhat.com>
2012-10-22 14:50:08 +02:00
Avi Kivity f6790af6bc memory: use AddressSpace for MemoryListener filtering
Using the AddressSpace type reduces confusion, as you can't accidentally
supply the MemoryRegion you're interested in.

Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
2012-10-22 14:50:07 +02:00