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: Shannon
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 c
urn 0;
if (strcmp(uname, "chosen") == 0)
return 0;
if (strcmp(uname, "hypervisor") == 0 &&
of_flat_dt_is_compatible(node, "xen,xen"))
return 0;
/*
* This node at depth 1 is neither
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.
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
> >
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, that
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 a/drivers/perf/
[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 Gr
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 __p2m_set
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 vari
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
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 one TL
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
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 the output image currently confi
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: Christoffer Dall
> Signed-off-by: Andre Przywara
>
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 o
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 poin
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 vcpu
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 onl
> 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
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
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)
> + 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.
___
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 could reuse the existing codes.
> >
> > Signed-off-
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 clk_disable_unused()
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 o
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 replace n
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 cl
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 replace n
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 hypervisor
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 b/xen/arch/arm/psci.
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
> >> > --- a/x
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
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 hides UART from Dom0.
>
> Si
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
> ---
> arch/arm64/kernel/acpi.c | 12
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
> ---
> Documentation/devicetree/bindings/arm/xen.txt | 42
>
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 +++
> arch/arm64/kernel/efi.c | 5 +
>
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
> ---
> drivers/firmware/efi/efi.c
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
> ---
> arch/arm/xen/enlighte
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
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
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:
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
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 fdt_find_uefi_params(unsigned long
> >>node
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
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.
> >
> > Signed-off-by: Shannon Zhao
>
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 communication between EFI
>
> > 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 hyperca
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
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 to
On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote:
> >>> On 10.09.15 at 13:37, wrote:
> > On Thu, 10 Sep 2015, Mark Rutland wrote:
> >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g.
> >> create pages of RuntimeServicesCode t
> > 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 about
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
> 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 time
> >> 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. Wit
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:
>
>
On Wed, Sep 30, 2015 at 11:45:15AM +0100, Julien Grall wrote:
> Hi all,
Hi,
> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
> hypercall interface and PV protocol are always based on 4KB page granularity.
>
> Any attempt to boot a Linux guest with 64KB pages enabled
> > 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 to
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 flushed to dcache,
> > > > otherwis
[1]), but it's
only necessary to allow us to describe PSCI 1.0 implementations which
are not strictly PSCI 0.2 compatible. Otherwise it's harmless to add for
PSCI 1.0 compatible systems, but "arm,psci-0.2" should be sufficient.
Thanks,
Mark.
[1]
http://lists.infradead.org/piperma
60 matches
Mail list logo
