Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

On Wed, Oct 25, 2017 at 04:21:48PM +0200, Jiri Slaby wrote: > Hi, > > On 10/06/2017, 03:21 PM, Mark Rutland wrote: > > If the aim of this series is to introduce something that architectures > > use consistently, then can we please actually poke other architectures &g

Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

Hi Jiri, I can see that these serve a useful purpose (as they are necessary for asm validation encessary for livepatching), and I am not personally averse to the new annotations. However, I am concerned that as-is, this is going to create more problems for !x86 architectures. More on that below.

Re: [Xen-devel] Duplicated memory node in the Device-Tree (WAS [XEN] Re: Duplicated memory nodes cause the BUG())

On Tue, Jul 25, 2017 at 06:27:31PM +0300, Andrii Anisov wrote: > On 25.07.17 17:23, Julien Grall wrote: > >I think this is by chance rather than by design. The first > >question to answer is why a Firmware would specify twice the same > >memory banks? Is it valid from the specification? > Yep,

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

[Adding the EFI maintainers] Tl;DR: Xen's EFI wrappery doesn't implement reset_system, so when invoked on arm64 we get a NULL dereference. On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote: > On 06/04/17 16:20, Daniel Kiper wrote: > >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen

Re: [Xen-devel] [PATCH V8 1/3] irq: Add flags to request_percpu_irq function

Hi Daniel, On Thu, Mar 23, 2017 at 06:42:01PM +0100, Daniel Lezcano wrote: > In the next changes, we track the interrupts but we discard the timers as > that does not make sense. The next interrupt on a timer is predictable. Sorry, but I could not parse this. [...] > diff --git

Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

On Wed, Mar 22, 2017 at 10:54:11AM -0700, Stefano Stabellini wrote: > When we receive an SError in Xen, we determine if it should be injected > into the guest or "handled" in Xen (by "handle" I mean crash the > system). In case it should be injected into the guest, we set the > relevant bit in

Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

On Wed, Mar 22, 2017 at 12:16:20PM +, Julien Grall wrote: > (CC Mark for the TLB question) [Adding Marc since he should understand this better than I do] I've trimmed a lot of context here, since it wasn't clear if it was relevant to the question. If there's something I've missed, please

Re: [Xen-devel] [PATCH v3 0/5] boot-wrapper: arm64: Xen support

On Thu, Dec 15, 2016 at 12:27:13PM +, Andre Przywara wrote: > These patches allow to include a Xen hypervisor binary into a boot-wrapper > ELF file, so that a Foundation Platform or a Fast Model can boot a Xen > system (including a Dom0 kernel). Thanks! I've applied the series and pushed it

Re: [Xen-devel] [PATCH v3 4/5] Xen: Select correct dom0 console

On Thu, Dec 15, 2016 at 12:27:17PM +, Andre Przywara wrote: > From: Ian Campbell > > If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to > the usual ttyAMA0 otherwise. > > Signed-off-by: Ian Campbell > Signed-off-by:

Re: [Xen-devel] [PATCH v2 4/4] Explicitly clean linux-system.axf and xen-system.axf

On Mon, Dec 12, 2016 at 02:50:20PM +, Andre Przywara wrote: > Hi Konrad, > > On 12/12/16 14:47, Konrad Rzeszutek Wilk wrote: > > On Tue, Nov 22, 2016 at 03:09:17PM +, Andre Przywara wrote: > >> From: Christoffer Dall > >> > >> When doing a make clean, only

Re: [Xen-devel] [PATCHv5 00/11] CONFIG_DEBUG_VIRTUAL for arm64

t; > With a few more acks I think this should be ready to go. More testing is > always appreciated though. I've given the whole series a go with kasan, kexec, and hibernate (using test_resume with the disk target), and everything looks happy. So FWIW, for the series: Reviewed-by: Mark Ru

Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

On Tue, Aug 02, 2016 at 10:58:00AM +0100, Julien Grall wrote: > On 01/08/2016 19:22, Mark Rutland wrote: > >On Mon, Aug 01, 2016 at 06:26:54PM +0100, Mark Rutland wrote: > >>On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote: > >>>however we only need

Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

Hi, I realised I made a confusing mistake in my last reply; clarification below. On Mon, Aug 01, 2016 at 06:26:54PM +0100, Mark Rutland wrote: > On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote: > > however we only need one TLBI instruction (assuming there is > &g

Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote: > On 01/08/16 17:34, Mark Rutland wrote: > >On Mon, Aug 01, 2016 at 04:40:50PM +0100, Julien Grall wrote: > >>After I read again multiple time the ARM ARM (D4-1732 in ARM DDI > >>0487A.i) and spoke with

Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

Hi Julien, On Mon, Aug 01, 2016 at 04:40:50PM +0100, Julien Grall wrote: > Hi Razvan, > > On 28/07/16 16:04, Razvan Cojocaru wrote: > >On 07/28/2016 05:51 PM, Julien Grall wrote: > >>The function p2m_set_mem_access can be re-implemented using the generic > >>functions p2m_get_entry and

Re: [Xen-devel] [PATCH v2] xen/arm: register clocks used by the hypervisor

On Wed, Jul 06, 2016 at 02:16:18PM +0100, Stefano Stabellini wrote: > On Wed, 6 Jul 2016, Julien Grall wrote: > > On 06/07/16 02:34, Michael Turquette wrote: > > > Hi! > > > > Hello Michael, > > > > > Quoting Dirk Behme (2016-06-30 03:32:32) > > > > Some clocks might be used by the Xen

Re: [Xen-devel] [PATCH v2] xen/arm: register clocks used by the hypervisor

Hi, On Tue, Jul 05, 2016 at 12:45:34PM +0200, Dirk Behme wrote: > On 05.07.2016 12:39, Mark Rutland wrote: > >On Tue, Jul 05, 2016 at 08:50:23AM +0200, Dirk Behme wrote: > >>+- clocks: one or more clocks to be registered. > >>+ Xen hypervisor drivers might replac

Re: [Xen-devel] [PATCH v2] xen/arm: register clocks used by the hypervisor

Hi, On Tue, Jul 05, 2016 at 08:50:23AM +0200, Dirk Behme wrote: > Some clocks might be used by the Xen hypervisor and not by the Linux > kernel. If these are not registered by the Linux kernel, they might be > disabled by clk_disable_unused() as the kernel doesn't know that they > are used. The

Re: [Xen-devel] [PATCH v2] xen/arm: register clocks used by the hypervisor

Hi, On Thu, Jun 30, 2016 at 04:56:40PM +0200, Dirk Behme wrote: > On 30.06.2016 16:21, Mark Rutland wrote: > >On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote: > >>+- clocks: one or more clocks to be registered. > >>+ Xen hypervisor drivers might replac

Re: [Xen-devel] [PATCH v2] xen/arm: register clocks used by the hypervisor

On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote: > Some clocks might be used by the Xen hypervisor and not by the Linux > kernel. If these are not registered by the Linux kernel, they might be > disabled by clk_disable_unused() as the kernel doesn't know that they > are used. The clock

Re: [Xen-devel] [PATCH] xen/arm: register clocks used by the hypervisor

On Wed, Jun 22, 2016 at 04:26:46PM +0100, Julien Grall wrote: > Hello Dirk, > > On 21/06/16 11:16, Dirk Behme wrote: > >Some clocks might be used by the Xen hypervisor and not by the Linux > >kernel. If these are not registered by the Linux kernel, they might be > >disabled by

Re: [Xen-devel] [PATCH v11 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

rectly under the root node; we'll * catch its parent instead. */ if (depth != 1) return 0; if (strcmp(uname, "chosen") == 0) return 0; if (strcmp(uname, "hypervisor") == 0 && of_flat_dt_is_compatibl

Re: [Xen-devel] [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

On Thu, Mar 31, 2016 at 01:44:08PM +0200, Ard Biesheuvel wrote: > The heuristic is there to decide whether some DTB image contains a > complete description of the platform, or only some data handed over by > the bootloader. Arguably, a DT containing both /chosen and /hypervisor > but nothing else

Re: [Xen-devel] [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote: > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote: > > When it's a Xen domain0 booting with ACPI, it will supply a /chosen and > > a /hypervisor node in DT. So check if it needs to enable ACPI. > > > > Signed-off-by:

Re: [Xen-devel] [PATCH v3 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

On Mon, Jan 25, 2016 at 03:50:52PM +, Stefano Stabellini wrote: > On Sat, 23 Jan 2016, Shannon Zhao wrote: > > From: Shannon Zhao > > > > Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could > > scan this to get the UEFI information. > > > >

Re: [Xen-devel] [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

On Tue, Jan 19, 2016 at 09:43:59PM +0800, Shannon Zhao wrote: > > On 2016/1/19 21:13, Mark Rutland wrote: > >On Tue, Jan 19, 2016 at 12:23:17PM +, Stefano Stabellini wrote: > >>>On Tue, 19 Jan 2016, Mark Rutland wrote: > >>>> >On Tue, Jan 19, 20

Re: [Xen-devel] [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

On Tue, Jan 19, 2016 at 06:25:25PM +0800, Shannon Zhao wrote: > > > On 2016/1/19 1:34, Stefano Stabellini wrote: > > On Mon, 18 Jan 2016, Mark Rutland wrote: > >> On Fri, Jan 15, 2016 at 02:55:25PM +0800, Shannon Zhao wrote: > >>> From: Shannon Zhao <s

Re: [Xen-devel] [PATCH v2 16/16] ARM64: XEN: Initialize Xen specific UEFI runtime services

On Tue, Jan 19, 2016 at 12:03:59PM +, Stefano Stabellini wrote: > On Mon, 18 Jan 2016, Mark Rutland wrote: > > On Mon, Jan 18, 2016 at 05:45:24PM +, Stefano Stabellini wrote: > > > On Mon, 18 Jan 2016, Mark Rutland wrote: > > > > On Fri, Jan 15, 2016 at 02:55:

Re: [Xen-devel] [PATCH v2 14/16] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Tue, Jan 19, 2016 at 09:19:05PM +0800, Shannon Zhao wrote: > > > On 2016/1/18 23:41, Stefano Stabellini wrote: > >CC'ing Matt Fleming > > > >On Fri, 15 Jan 2016, Shannon Zhao wrote: > >>From: Shannon Zhao > >>@@ -520,15 +531,28 @@ static int __init

Re: [Xen-devel] [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

On Tue, Jan 19, 2016 at 12:23:17PM +, Stefano Stabellini wrote: > On Tue, 19 Jan 2016, Mark Rutland wrote: > > On Tue, Jan 19, 2016 at 06:25:25PM +0800, Shannon Zhao wrote: > > > >> We don't do this in Documentation/arm/uefi.txt, and I don't see why we &g

Re: [Xen-devel] [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

On Fri, Jan 15, 2016 at 02:55:25PM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could > scan this to get the UEFI information. > > Signed-off-by: Shannon Zhao > --- >

Re: [Xen-devel] [PATCH v2 01/16] Xen: ACPI: Hide UART used by Xen

On Fri, Jan 15, 2016 at 02:55:14PM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > ACPI 6.0 introduces a new table STAO to list the devices which are used > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical > UART is used by Xen. So here it

Re: [Xen-devel] [PATCH v2 11/16] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

On Fri, Jan 15, 2016 at 02:55:24PM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > When it's a Xen domain0 booting with ACPI, it will supply a /chosen and > a /hypervisor node in DT. So check if it needs to enable ACPI. > > Signed-off-by: Shannon Zhao

Re: [Xen-devel] [PATCH v2 16/16] ARM64: XEN: Initialize Xen specific UEFI runtime services

On Mon, Jan 18, 2016 at 05:45:24PM +, Stefano Stabellini wrote: > On Mon, 18 Jan 2016, Mark Rutland wrote: > > On Fri, Jan 15, 2016 at 02:55:29PM +0800, Shannon Zhao wrote: > > > +void __init xen_efi_runtime_setup(void) > > > +{ > > > + efi.get_tim

Re: [Xen-devel] [PATCH v2 14/16] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Fri, Jan 15, 2016 at 02:55:27PM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > Add a new function to parse DT parameters for Xen specific UEFI just > like the way for normal UEFI. Then it could reuse the existing codes. > > Signed-off-by: Shannon Zhao

Re: [Xen-devel] [PATCH v2 16/16] ARM64: XEN: Initialize Xen specific UEFI runtime services

On Fri, Jan 15, 2016 at 02:55:29PM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > When running on Xen hypervisor, runtime services are supported through > hypercall. So call Xen specific function to initialize runtime services. > > Signed-off-by: Shannon Zhao

Re: [Xen-devel] [PATCH v2 13/16] ARM: XEN: Set EFI_PARAVIRT if Xen supports EFI

On Fri, Jan 15, 2016 at 02:55:26PM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > Check if there is "uefi" node in the DT. If so, set EFI_PARAVIRT flag. > > Signed-off-by: Shannon Zhao > --- > arch/arm/xen/enlighten.c | 23

Re: [Xen-devel] [PATCH v3 20/62] arm/acpi: Add ACPI support for SMP initialization

On Mon, Jan 04, 2016 at 02:51:51PM +, Stefano Stabellini wrote: > On Wed, 30 Dec 2015, Shannon Zhao wrote: > > On 2015/11/30 22:57, Julien Grall wrote: > > > Hi Shannon, > > > > > > On 17/11/15 09:40, shannon.z...@linaro.org wrote: > > >> > diff --git a/xen/arch/arm/psci.c

Re: [Xen-devel] [PATCH v3 20/62] arm/acpi: Add ACPI support for SMP initialization

On Mon, Jan 04, 2016 at 03:00:45PM +, Mark Rutland wrote: > On Mon, Jan 04, 2016 at 02:51:51PM +, Stefano Stabellini wrote: > > On Wed, 30 Dec 2015, Shannon Zhao wrote: > > > I check this again. There are not limitations of supporting PSCI version > > > in ACPI S

Re: [Xen-devel] [PATCH v3 20/62] arm/acpi: Add ACPI support for SMP initialization

On Wed, Dec 30, 2015 at 11:11:08AM +0800, Shannon Zhao wrote: > > > On 2015/11/30 22:57, Julien Grall wrote: > > Hi Shannon, > > > > On 17/11/15 09:40, shannon.z...@linaro.org wrote: > >> > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c > >> > index d800cb6..dede0e1 100644 > >> > ---

Re: [Xen-devel] [PATCH 08/13] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Tue, Nov 17, 2015 at 12:25:58PM +0100, Ard Biesheuvel wrote: > On 17 November 2015 at 10:57, wrote: > > From: Shannon Zhao > > > > Add a new function to parse DT parameters for Xen specific UEFI just > > like the way for normal UEFI. Then it

Re: [Xen-devel] [PATCH 1/3] xen/arm: introduce xen_read_wallclock

> + delta = arch_timer_read_counter(); /* time since system boot */ > + delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec; The arch counter value is not a number of nanoseconds (unless CNTFRQ reads as 100), so this doesn't look right; the units don't match. Thanks, Mark.

Re: [Xen-devel] [PATCH v11 5/5] xen/arm: account for stolen ticks

On Fri, Nov 06, 2015 at 11:41:49AM +, David Vrabel wrote: > On 06/11/15 11:39, Stefano Stabellini wrote: > > On Thu, 5 Nov 2015, Mark Rutland wrote: > >>> static void xen_percpu_init(void) > >>> { > >>> struct vcpu_register_vcpu_inf

Re: [Xen-devel] [PATCH v11 1/5] xen: move xen_setup_runstate_info and get_runstate_snapshot to drivers/xen/time.c

On Fri, Nov 06, 2015 at 11:11:40AM +, Stefano Stabellini wrote: > On Thu, 5 Nov 2015, Mark Rutland wrote: > > Hi, > > > > > +static u64 get64(const u64 *p) > > > +{ > > > + u64 ret; > > > + > > > + if (BITS_PER_LONG < 64)

Re: [Xen-devel] [PATCH v11 5/5] xen/arm: account for stolen ticks

> static void xen_percpu_init(void) > { > struct vcpu_register_vcpu_info info; > @@ -104,6 +120,8 @@ static void xen_percpu_init(void) > BUG_ON(err); > per_cpu(xen_vcpu, cpu) = vcpup; > > + xen_setup_runstate_info(cpu); Does the runstate memory area get unregsitered when

Re: [Xen-devel] [PATCH v11 1/5] xen: move xen_setup_runstate_info and get_runstate_snapshot to drivers/xen/time.c

Hi, > +static u64 get64(const u64 *p) > +{ > + u64 ret; > + > + if (BITS_PER_LONG < 64) { > + u32 *p32 = (u32 *)p; > + u32 h, l; > + > + /* > + * Read high then low, and then make sure high is > + * still the same; this will

Re: [Xen-devel] [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux

> > Just to check, would this be expected to work with a 16K DomU (e.g. > > [2])? > > > > From a quick scan it looks like the relaxations provided by this series > > should work so long as PAGE_SIZE % XEN_PAGE_SIZE == 0, assuming I > > haven't missed something. > > Correct, this series is able

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote: > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote: > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > >

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote: > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote: > > > > C) When you could go: > > > > > > > >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACP

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> It feels like this discussion is going in circles. > > When we discussed this six months ago, we already concluded that, > since UEFI is the only specified way that the presence of ACPI is > advertised on an ARM system, we need to emulate UEFI to some extent. My understanding from the last

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> >> Considering that the EFI support is just for Dom0, and Dom0 (at > >> the time) had to be PV anyway, it was the more natural solution to > >> expose the interface via hypercalls, the more that this allows better > >> control over what is and primarily what is not being exposed to > >> Dom0.

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

Hi, I'm not necessarily opposed to the renaming, but I think that this is the least important thing to standardize for this to work. On Thu, Sep 10, 2015 at 09:41:56AM +0100, Shannon Zhao wrote: > From: Shannon Zhao > > These EFI stub parameters are used to internal

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > interface? > > Xen talks to EFI itself but the interface provided to dom0 is somewhat > different: there are no BootServices (Xen calls ExitBootServices before > running the kernel), and the RuntimeServices go via

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI > > > > interface? > > > > > > Xen talks to EFI itself b

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote: > >>> On 10.09.15 at 13:37, <stefano.stabell...@eu.citrix.com> wrote: > > On Thu, 10 Sep 2015, Mark Rutland wrote: > >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g. > &g

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote: > On Thu, 10 Sep 2015, Mark Rutland wrote: > > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote: > > > On Thu, 10 Sep 2015, Mark Rutland wrote: > > > > > > Does Xen not talk

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> > C) When you could go: > > > >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI > > discovery > > I take you mean discovering Xen with the usual Xen hypervisor node on > device tree. I think that C) is a good option actually. I like it. Not > sure why we didn't think

Re: [Xen-devel] [PATCH for-4.6] efi: introduce efi_arch_flush_dcache_area

On Mon, Sep 07, 2015 at 05:06:36PM +0100, Ian Campbell wrote: > On Mon, 2015-09-07 at 16:08 +0100, Stefano Stabellini wrote: > > On Mon, 7 Sep 2015, Jan Beulich wrote: > > > > > > On 07.09.15 at 16:13, wrote: > > > > Objects loaded by FileHandle->Read need to be