date:20170810

On Thu, Aug 10, 2017 at 01:24:27PM +0200, Juergen Gross wrote:
> When the record length for sending the p2m frames in a migration
> stream is too large, the issued error message is not very helpful:
> 
> xc: Record (0x0003, x86 PV P2M frames) length 0x8 exceeds max
> (0x80): Internal error
> 
> When printing the error use the size which was tested instead that of
> the record header length.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xsm/flask: Fix build following "xsm: correct AVC lookups for two sysctls"

On 10/08/17 15:09, Daniel De Graaf wrote:
> On 08/10/2017 09:17 AM, Andrew Cooper wrote:
>> avc_current_has_perm() takes 4 arguments, not 3.  Spotted by a Travis
>> randconfig run which actually turned XSM on.
>>
>> Signed-off-by: Andrew Cooper 
>
> Whoops, looks like I sent the non-build-tested patch by accident.
> Thanks for catching this!
>
> Acked-by: Daniel De Graaf 

Thanks.

While you are here, any input on
https://www.mail-archive.com/xen-devel@lists.xen.org/msg112930.html ?

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH v1 2/7] iommu/arm: ipmmu-vmsa: Add Xen changes for main driver


Hi,

On 10/08/17 15:27, Oleksandr Tyshchenko wrote:

On Tue, Aug 8, 2017 at 2:34 PM, Julien Grall  wrote:

On 26/07/17 16:09, Oleksandr Tyshchenko wrote:

@@ -355,6 +557,10 @@ static struct hw_register
*root_pgtable[IPMMU_CTX_MAX] = {

 static bool ipmmu_is_root(struct ipmmu_vmsa_device *mmu)
 {
+   /* Xen: Fix */



Hmmm. Can we get a bit more details?


These is a case when ipmmu_is_root is called with "mmu" being NULL.
https://github.com/otyshchenko1/xen/blob/fc231a0f2edb3d01d178fb5c27dd6c1065807c81/xen/drivers/passthrough/arm/ipmmu-vmsa.c#L2330

In ipmmu_vmsa_alloc_page_table() we need to find "root mmu", but we
doesn't have argument to pass.
So, I had two options:

1. Add code searching for it.
...
spin_lock(_devices_lock);
list_for_each_entry(mmu, _devices, list) {
   if (ipmmu_is_root(mmu))
  break;
}
spin_unlock(_devices_lock);
...

2. Use existing ipmmu_find_root() with adding this check for a valid value.
So, if we call ipmmu_find_root() with argument being NULL we will
actually get searching the list.

I decided to use 2 option.


Can you please expand the comment then?






+   if (!mmu)
+   return false;
+
if (mmu->features->has_cache_leaf_nodes)
return mmu->is_leaf ? false : true;
else
@@ -405,14 +611,28 @@ static void ipmmu_ctx_write(struct ipmmu_vmsa_domain
*domain, unsigned int reg,
ipmmu_write(domain->root, domain->context_id * IM_CTX_SIZE + reg,
data);
 }

-static void ipmmu_ctx_write2(struct ipmmu_vmsa_domain *domain, unsigned
int reg,
+/* Xen: Write the context for cache IPMMU only. */



Same here. Why does it need to be different with Xen?


Well, let me elaborate a bit more about this.

I feel that I need to explain in a few words about IPMMU itself:
Generally speaking,
The IPMMU hardware (R-Car Gen3) has 8 context banks and consists of next parts:
- root IPMMU
- a number of cache IPMMUs

Each cache IPMMU is connected to root IPMMU and has uTLB ports the
master devices can be tied to.
Something, like this:

master device1 ---> cache IPMMU1 [8 ctx] ---> root IPMMU [8 ctx] -> memory
   |  |
master device2 --  |
  |
master device3 ---> cache IPMMU2 [8 ctx] --

Each context bank has registers.
Some registers exist for both root IPMMU and cache IPMMUs -> IMCTR
Some registers exist only for root IPMMU -> IMTTLBRx/IMTTUBRx, IMMAIR0, etc

So, original driver has two helpers:
1. ipmmu_ctx_write() - is intended to write a register in context bank
N* for root IPMMU only.
2. ipmmu_ctx_write2() - is intended to write a register in context
bank N for both root IPMMU and cache IPMMU.
*where N=0-7

AFAIU, original Linux driver provides each IOMMU domain with a
separate IPMMU context:
master device1 + master device2 are in IOMMU domain1 and use IPMMU context 0
master device3 is in IOMMU domain2 and uses IPMMU context 1

So, when attaching device to new IOMMU domain in Linux we have to
initialize context for root IPMMU and enable context (IMCTR register)
for both root and cache IPMMUs.
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/drivers/iommu/ipmmu-vmsa.c?h=v4.9/rcar-3.5.3#n620

In Xen we need additional helper "ipmmu_ctx_write1" for writing a
register in context bank N for cache IPMMU only.
The reason is that we need a way to control cache IPMMU separately
since we have a little bit another model.

All IOMMU domains within a single Xen domain (dom_iommu(d)->arch.priv)
use the same IPMMU context N
which was initialized and enabled at the domain creation time. This
means that all master devices
that are assigned to the guest domain "d" use only this IPMMU context
N which actually contains P2M mapping for domain "d":
master device1 + master device2 are in IOMMU domain1 and use IPMMU context 0
master device3 is in IOMMU domain2 and also uses IPMMU context 0

So, when attaching device to new IOMMU domain in Xen we don't have to
initialize and enable context,
because it has been already done at domain initialization time:
https://github.com/otyshchenko1/xen/blob/ipmmu_v2/xen/drivers/passthrough/arm/ipmmu-vmsa.c#L2380
we just have to enable context for corresponding cache IPMMU only:
https://github.com/otyshchenko1/xen/blob/ipmmu_v2/xen/drivers/passthrough/arm/ipmmu-vmsa.c#L1083

This is the main difference between drivers in Linux and Xen.

So, as you can see there is a need to manipulate context registers for
cache IPMMU without touching root IPMMU,
that's why I added this helper.

Does this make sense?


I think it does.







+static void ipmmu_ctx_write1(struct ipmmu_vmsa_domain *domain, unsigned
int reg,
 u32 data)
 {
if (domain->mmu != domain->root)
-   ipmmu_write(domain->mmu,
-   domain->context_id * IM_CTX_SIZE + reg, data);
+

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen

On Thu, Aug 10, 2017 at 03:26:07PM +0100, Julien Grall wrote:
> 
> 
> On 09/08/17 11:58, Bhupinder Thakur wrote:
> > Hi Julien,
> 
> Hi Bhupinder,
> 
> > Thanks for the testing.
> > 
> > On 8 August 2017 at 21:29, Julien Grall  wrote:
> > > Hi Bhupinder,
> > > 
> > > I gave another and I have a couple of comments.
> > > 
> > > Booting Linux with earlycon enabled take quite a while. I can see the
> > > characters coming slower than on the minitel. It seems to be a bit better
> > > after switching off the bootconsole. Overall Linux is taking ~20 times to
> > > boot with pl011 vs HVC console.
> > > 
> > > I do agree that pl011 is emulated and therefore you have to trap after 
> > > each
> > > character. But 20 times sounds far too much.
> > > 
> > I think this slowness could be due to ratelimiting of the pl011 events
> > in xenconosle. Currently, the rate limit is
> > set to 30 events per 200 msecs (see RATE_LIMIT_ALLOWANCE/RATE_LIMIT_PERIOD).
> > 
> > I increased the rate limit to 600 events (30 * 20) per 200 msecs. With
> > this change,
> > I see that the the find command is running faster and smoother.
> > Earlier the find output would be jerky.
> 
> I think there might be another solution avoiding increasing the rate limit.
> 
> If you look at the earlycon code for pl011 in Linux:
> 
> static void pl011_putc(struct uart_port *port, int c)
> {
>   while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
>   cpu_relax();
>   if (port->iotype == UPIO_MEM32)
>   writel(c, port->membase + UART01x_DR);
>   else
>   writeb(c, port->membase + UART01x_DR);
>   while (readl(port->membase + UART01x_FR) & UART01x_FR_BUSY)
>   cpu_relax();
> }
> 
> Linux will wait the UART to be idle before sending a new character.
> 
> Now looking at vpl011 emulation, the busy bit set when a new character is
> queued (see vpl011_write_data). This bit will only be cleared when the
> console daemon will raise an event and the queue is empty (see
> vpl011_data_avail).
> 
> This means for earlycon, you will need a round trip Guest -> Xen -> Dom0 ->
> Xen -> Guest for each single character. This is a bit counterproductive and
> combined with the limit it makes it worse.
> 
> I would take a different approach on the BUSY bit. We can consider the queue
> between Xen and xenconsoled as outside of the UART. If the character is
> queued, then job done. I think this would improve quite a lot of the
> performance.

Yes. This.

The guest sees a register, which is essentially a synchronous interface
to the guest. The current code, as you already see, will issue one event
for every character. That's excessive.

The interface between Xen and xenconsoled can be asynchronous, it can
opt to queue X characters before sending an event, also setup a oneshot
timer to avoid hanging.

This however has some other implications -- it might not be as reliable
as the original method because data is not guaranteed to hit backend. If
the guest crashes very early on, depending the actual implementation you
might not be able get the data.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 46/52] xen: carve out a generic parsing function from _cmdline_parse()

On Wed, Aug 09, 2017 at 09:07:00AM +0200, Juergen Gross wrote:
> In order to support generic parameter parsing carve out the parser from
> _cmdline_parse(). As this generic function might be called after boot
> remove the __init annotations from all called sub-functions.
> 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Bug] 4.12 kernel dom0 always reboot on xen 4.9 efi

>>> On 10.08.17 at 13:09,  wrote:
> On my SKL/KBL machine,  upstream 4.12 kernel dom0 couldn't boot up using 
> xen.efi which is xen 4.9
> 
> 
> (1) Upstream 4.11 kernel doesn't have such issue.
> 
> (2) Upstream 4.12 kernel on my native uefi machine could boot up.
> 
> After some debug, I have some finding:
> firmware/efi.c: Reinit efi global variable
> 
> efi is a global variable, some of efi members is initialized to
> INVALID_TABLE_ADDR when efi is defined. But efi is zero when
> setup_arch() begin running for unknown reason.

Well, I don't think that's a precise description, but anyway the
problem has been discussed before, and a patch is available
(but may not have landed in the 4.12.x stable tree yet, as
originally it was assumed to only be cosmetic) - look for
"x86/xen/efi: Initialize only the EFI struct members used by
Xen".

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] x86/vsmp: remove vsmp paravirt support

2017-08-10 Thread Shai Fultheim (s...@scalemp.com)

NACK.  This is needed and used by thousands of installations.



Shai Fultheim | M +1 (408) 480-1612 | E s...@scalemp.com

This email message and any attachments to it are ScaleMP confidential 
information.

-Original Message-
From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Juergen Gross
Sent: Thursday, August 10, 2017 15:53
To: linux-ker...@vger.kernel.org; xen-de...@lists.xenproject.org; 
x...@kernel.org
Cc: h...@zytor.com; mi...@redhat.com; t...@linutronix.de; 
boris.ostrov...@oracle.com; ru...@rustcorp.com.au; lgu...@lists.ozlabs.org; 
Juergen Gross 
Subject: [PATCH 3/3] x86/vsmp: remove vsmp paravirt support

vSMP has seen its last functional patch more than 3 years ago. It is
not clear whether the vSMP paravirtualized irq functions are still
needed.

Remove them as they seem to be optional and their existence is blocking
some simplification work of paravirt infrastructure.

Signed-off-by: Juergen Gross 
---
 arch/x86/Kconfig  |  1 -
 arch/x86/kernel/vsmp_64.c | 69 +--
 2 files changed, 1 insertion(+), 69 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3fac2570a2e1..13a3d8744ae4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -495,7 +495,6 @@ config X86_NUMACHIP
 config X86_VSMP
bool "ScaleMP vSMP"
select HYPERVISOR_GUEST
-   select PARAVIRT
depends on X86_64 && PCI
depends on X86_EXTENDED_PLATFORM
depends on SMP
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index b034b1b14b9c..5d392b809ee4 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define TOPOLOGY_REGISTER_OFFSET 0x10
@@ -29,64 +28,7 @@
 /* Flag below is initialized once during vSMP PCI initialization. */
 static int irq_routing_comply = 1;
 
-#if defined CONFIG_PCI && defined CONFIG_PARAVIRT
-/*
- * Interrupt control on vSMPowered systems:
- * ~AC is a shadow of IF.  If IF is 'on' AC should be 'off'
- * and vice versa.
- */
-
-asmlinkage __visible unsigned long vsmp_save_fl(void)
-{
-   unsigned long flags = native_save_fl();
-
-   if (!(flags & X86_EFLAGS_IF) || (flags & X86_EFLAGS_AC))
-   flags &= ~X86_EFLAGS_IF;
-   return flags;
-}
-PV_CALLEE_SAVE_REGS_THUNK(vsmp_save_fl);
-
-__visible void vsmp_restore_fl(unsigned long flags)
-{
-   if (flags & X86_EFLAGS_IF)
-   flags &= ~X86_EFLAGS_AC;
-   else
-   flags |= X86_EFLAGS_AC;
-   native_restore_fl(flags);
-}
-PV_CALLEE_SAVE_REGS_THUNK(vsmp_restore_fl);
-
-asmlinkage __visible void vsmp_irq_disable(void)
-{
-   unsigned long flags = native_save_fl();
-
-   native_restore_fl((flags & ~X86_EFLAGS_IF) | X86_EFLAGS_AC);
-}
-PV_CALLEE_SAVE_REGS_THUNK(vsmp_irq_disable);
-
-asmlinkage __visible void vsmp_irq_enable(void)
-{
-   unsigned long flags = native_save_fl();
-
-   native_restore_fl((flags | X86_EFLAGS_IF) & (~X86_EFLAGS_AC));
-}
-PV_CALLEE_SAVE_REGS_THUNK(vsmp_irq_enable);
-
-static unsigned __init vsmp_patch(u8 type, u16 clobbers, void *ibuf,
- unsigned long addr, unsigned len)
-{
-   switch (type) {
-   case PARAVIRT_PATCH(pv_irq_ops.irq_enable):
-   case PARAVIRT_PATCH(pv_irq_ops.irq_disable):
-   case PARAVIRT_PATCH(pv_irq_ops.save_fl):
-   case PARAVIRT_PATCH(pv_irq_ops.restore_fl):
-   return paravirt_patch_default(type, clobbers, ibuf, addr, len);
-   default:
-   return native_patch(type, clobbers, ibuf, addr, len);
-   }
-
-}
-
+#if defined CONFIG_PCI
 static void __init set_vsmp_pv_ops(void)
 {
void __iomem *address;
@@ -115,15 +57,6 @@ static void __init set_vsmp_pv_ops(void)
}
 #endif
 
-   if (cap & ctl & (1 << 4)) {
-   /* Setup irq ops and turn on vSMP  IRQ fastpath handling */
-   pv_irq_ops.irq_disable = PV_CALLEE_SAVE(vsmp_irq_disable);
-   pv_irq_ops.irq_enable  = PV_CALLEE_SAVE(vsmp_irq_enable);
-   pv_irq_ops.save_fl  = PV_CALLEE_SAVE(vsmp_save_fl);
-   pv_irq_ops.restore_fl  = PV_CALLEE_SAVE(vsmp_restore_fl);
-   pv_init_ops.patch = vsmp_patch;
-   ctl &= ~(1 << 4);
-   }
writel(ctl, address + 4);
ctl = readl(address + 4);
pr_info("vSMP CTL: control set to:0x%08x\n", ctl);
-- 
2.12.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] x86/vsmp: remove vsmp paravirt support

On 10/08/17 17:28, Shai Fultheim (s...@scalemp.com) wrote:
> NACK.  This is needed and used by thousands of installations.

Okay, thanks for reacting so fast. Will drop the patch.


Juergen

> 
> 
> 
> Shai Fultheim | M +1 (408) 480-1612 | E s...@scalemp.com
> 
> This email message and any attachments to it are ScaleMP confidential 
> information.
> 
> -Original Message-
> From: Ingo Molnar [mailto:mingo.kernel@gmail.com] On Behalf Of Juergen 
> Gross
> Sent: Thursday, August 10, 2017 15:53
> To: linux-ker...@vger.kernel.org; xen-de...@lists.xenproject.org; 
> x...@kernel.org
> Cc: h...@zytor.com; mi...@redhat.com; t...@linutronix.de; 
> boris.ostrov...@oracle.com; ru...@rustcorp.com.au; lgu...@lists.ozlabs.org; 
> Juergen Gross 
> Subject: [PATCH 3/3] x86/vsmp: remove vsmp paravirt support
> 
> vSMP has seen its last functional patch more than 3 years ago. It is
> not clear whether the vSMP paravirtualized irq functions are still
> needed.
> 
> Remove them as they seem to be optional and their existence is blocking
> some simplification work of paravirt infrastructure.
> 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/Kconfig  |  1 -
>  arch/x86/kernel/vsmp_64.c | 69 
> +--
>  2 files changed, 1 insertion(+), 69 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 3fac2570a2e1..13a3d8744ae4 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -495,7 +495,6 @@ config X86_NUMACHIP
>  config X86_VSMP
>   bool "ScaleMP vSMP"
>   select HYPERVISOR_GUEST
> - select PARAVIRT
>   depends on X86_64 && PCI
>   depends on X86_EXTENDED_PLATFORM
>   depends on SMP
> diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
> index b034b1b14b9c..5d392b809ee4 100644
> --- a/arch/x86/kernel/vsmp_64.c
> +++ b/arch/x86/kernel/vsmp_64.c
> @@ -21,7 +21,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #define TOPOLOGY_REGISTER_OFFSET 0x10
> @@ -29,64 +28,7 @@
>  /* Flag below is initialized once during vSMP PCI initialization. */
>  static int irq_routing_comply = 1;
>  
> -#if defined CONFIG_PCI && defined CONFIG_PARAVIRT
> -/*
> - * Interrupt control on vSMPowered systems:
> - * ~AC is a shadow of IF.  If IF is 'on' AC should be 'off'
> - * and vice versa.
> - */
> -
> -asmlinkage __visible unsigned long vsmp_save_fl(void)
> -{
> - unsigned long flags = native_save_fl();
> -
> - if (!(flags & X86_EFLAGS_IF) || (flags & X86_EFLAGS_AC))
> - flags &= ~X86_EFLAGS_IF;
> - return flags;
> -}
> -PV_CALLEE_SAVE_REGS_THUNK(vsmp_save_fl);
> -
> -__visible void vsmp_restore_fl(unsigned long flags)
> -{
> - if (flags & X86_EFLAGS_IF)
> - flags &= ~X86_EFLAGS_AC;
> - else
> - flags |= X86_EFLAGS_AC;
> - native_restore_fl(flags);
> -}
> -PV_CALLEE_SAVE_REGS_THUNK(vsmp_restore_fl);
> -
> -asmlinkage __visible void vsmp_irq_disable(void)
> -{
> - unsigned long flags = native_save_fl();
> -
> - native_restore_fl((flags & ~X86_EFLAGS_IF) | X86_EFLAGS_AC);
> -}
> -PV_CALLEE_SAVE_REGS_THUNK(vsmp_irq_disable);
> -
> -asmlinkage __visible void vsmp_irq_enable(void)
> -{
> - unsigned long flags = native_save_fl();
> -
> - native_restore_fl((flags | X86_EFLAGS_IF) & (~X86_EFLAGS_AC));
> -}
> -PV_CALLEE_SAVE_REGS_THUNK(vsmp_irq_enable);
> -
> -static unsigned __init vsmp_patch(u8 type, u16 clobbers, void *ibuf,
> -   unsigned long addr, unsigned len)
> -{
> - switch (type) {
> - case PARAVIRT_PATCH(pv_irq_ops.irq_enable):
> - case PARAVIRT_PATCH(pv_irq_ops.irq_disable):
> - case PARAVIRT_PATCH(pv_irq_ops.save_fl):
> - case PARAVIRT_PATCH(pv_irq_ops.restore_fl):
> - return paravirt_patch_default(type, clobbers, ibuf, addr, len);
> - default:
> - return native_patch(type, clobbers, ibuf, addr, len);
> - }
> -
> -}
> -
> +#if defined CONFIG_PCI
>  static void __init set_vsmp_pv_ops(void)
>  {
>   void __iomem *address;
> @@ -115,15 +57,6 @@ static void __init set_vsmp_pv_ops(void)
>   }
>  #endif
>  
> - if (cap & ctl & (1 << 4)) {
> - /* Setup irq ops and turn on vSMP  IRQ fastpath handling */
> - pv_irq_ops.irq_disable = PV_CALLEE_SAVE(vsmp_irq_disable);
> - pv_irq_ops.irq_enable  = PV_CALLEE_SAVE(vsmp_irq_enable);
> - pv_irq_ops.save_fl  = PV_CALLEE_SAVE(vsmp_save_fl);
> - pv_irq_ops.restore_fl  = PV_CALLEE_SAVE(vsmp_restore_fl);
> - pv_init_ops.patch = vsmp_patch;
> - ctl &= ~(1 << 4);
> - }
>   writel(ctl, address + 4);
>   ctl = readl(address + 4);
>   pr_info("vSMP CTL: control set to:0x%08x\n", ctl);
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC




On 10/08/17 16:33, Volodymyr Babchuk wrote:

Hi Julien,

On 09.08.17 13:10, Julien Grall wrote:

Hi Volodymyr,

CC "THE REST" maintainers to get an opinion on the public headers.

On 08/08/17 21:08, Volodymyr Babchuk wrote:

SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to a
different
firmware functions. Thus, for example PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such calls.
Besides functional calls there are query calls, which allows underling
OS determine version, UID and number of functions provided by service
provider.

This patch adds new file `vsmc.c`, which handles both generic SMCs
and HVC according to SMC. At this moment it implements only one
service: Standard Hypervisor Service.

Standard Hypervisor Service only supports query calls, so caller can
ask about hypervisor UID and determine that it is XEN running.

This change allows more generic handling for SMCs and HVCs and it can
be easily extended to support new services and functions.

But, before SMC is forwarded to standard SMCCC handler, it can be routed
to a domain monitor, if one is installed.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko 
Reviewed-by: Oleksandr Tyshchenko 
---
 - Updated description to indicate that this patch affects only SMC
call path.
 - added "xen_" prefix to definitions in include/public/arch-arm/smc.h
 - moved do_trap_smc() into vsmc.c from traps.c
 - replaced all tabs with spaces


I would have really appreciated a summary of the discussion we had on
the previous version regarding the bindings. This is a real blocker
for this series and should not be ignored.



While I agree that question about bindings is important, I can't see how
it affects this patch series. This patch series does not break anything.
Because

1. This series add only new feature: generic hypervisor service with no
immediate use. All ARM guests are already aware that they are running on
XEN. All ARM guests know that they call *only* PSCI.

2. I see importance of this patch series for embedded platforms, where
developer exactly knows what software of which version he/she will run.
I doubt that server platforms will need something beyond PSCI, which I
preserved as is.


I disagree here. SMCCC could be used to provide Dom0 a way to interact 
with the firmware if necessary.




A I'm not denying importance of SMC bindings, but I think it is not
blocker for my patches. We can add bindings later, when there will be
consensus on how they should look. In meantime SMC handler can be used
by anyone who knows that is available.


I am not in favor on getting something merged in Xen until we agree on 
the way for the guest to know it is there. It means you have to carry 
hack in your kernel in order to use SMC. Maybe this is fine for you, but 
I don't want to make this assumption on Xen upstream today.


This is a change in the interface that should be notified to the guest. 
If we expose it without providing a bindings (or something), we have no 
way to revert/disable it. Imagine we want to disable SMC in the future. 
How a guest will know that

- until Xen 4.10 SMC was not existing,
- between Xen 4.10 and Xen 4.x you can use them
- after Xen 4.y they can be disabled.

All changes should be detected through the firmware tables (DT, ACPI) or 
another Xen method (i.e XENFEAT_*). For instance, the guest has to parse 
the firmware tables in order to know PSCI is available.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 39/52] xen: check parameter validity when parsing command line

On 10/08/17 15:32, Jan Beulich wrote:
 On 10.08.17 at 15:24,  wrote:
>> @@ -176,7 +200,8 @@ int __init parse_bool(const char *s)
>>   !strcmp("on", s) ||
>>   !strcmp("true", s) ||
>>   !strcmp("enable", s) ||
>> - !strcmp("1", s) )
>> + !strcmp("1", s) ||
>> + !strcmp("", s) )
> 
> But not strcmp() please in such a case - !*s is quite sufficient there.

Okay.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 5/5] xen: RCU: avoid busy waiting until the end of grace period.

2017-08-10 Thread Dario Faggioli

On Wed, 2017-08-09 at 19:34 +0200, Dario Faggioli wrote:
> On Mon, 2017-08-07 at 02:54 -0600, Jan Beulich wrote:
> > > > > Dario Faggioli  07/27/17 10:01 AM
> > > +/*
> > > + * Timer for making sure the CPU where a callback is queued does
> > > + * periodically poke rcu_pedning(), so that it will invoke the
> > > callback
> > > + * not too late after the end of the grace period.
> > > + */
> > > +void rcu_idle_timer_start()
> > > +{
> > > +struct rcu_data *rdp = _cpu(rcu_data);
> > > +
> > > +if (likely(!rdp->curlist))
> > > +return;
> > 
> > I would have expected this to be the inverse of the original
> > condition in
> > rcu_needs_cpu() - why is there no rcu_pending() invocation here?
> > 
> 
> [...]
>
> Actually, it's entirely possible that it is having rcu_pending(cpu)
> in
> rcu_needs_cpu() is, for us, redundant. In fact, although it does make
> sense in Linux, both code inspection and some investigation I've just
> done, makes me believe that there won't be cases where a CPU is
> denied
> going offline because it sees rcu_pending() returning 1.
> 
> In fact, when we call rcu_pending(), within cpu_is_haltable(), we
> have
> already gone through it before. And if there were pending work, we've
> raised the softirq and dealt with it. If there weren't, neither there
> is now.
> 
> I'm therefore leaning toward removing rcu_pending() from the
> rcu_needs_cpu() check as well. At that point, we'll indeed have the
> check inside rcu_start_idle_timer(), be the opposite of the original
> check in rcu_needs_cpu(). :-)
> 
FTR, I'm not so sure of this last thing any longer. I mean, the
analysis I provided is still correct, but I'm investigating the other
possible race existing in the code that Tim has hinted at in his mail,
and I think it could be useful to have rcu_pending() checked in here,
to solve/avoid that one.

It's also possible that I'll actually remove it from rcu_needs_cpu(),
but to move it somewhere else... As I said, I'm still looking into the
problem.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH v2 01/22] ARM: vGIC: introduce and initialize pending_irq lock


Hi Andre,

On 21/07/17 20:59, Andre Przywara wrote:

Currently we protect the pending_irq structure with the corresponding
VGIC VCPU lock. There are problems in certain corner cases (for
instance if an IRQ is migrating), so let's introduce a per-IRQ lock,
which will protect the consistency of this structure independent from
any VCPU.
For now this just introduces and initializes the lock, also adds
wrapper macros to simplify its usage (and help debugging).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c|  1 +
 xen/include/asm-arm/vgic.h | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 1e5107b..38dacd3 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -69,6 +69,7 @@ void vgic_init_pending_irq(struct pending_irq *p, unsigned 
int virq)
 memset(p, 0, sizeof(*p));
 INIT_LIST_HEAD(>inflight);
 INIT_LIST_HEAD(>lr_queue);
+spin_lock_init(>lock);
 p->irq = virq;
 p->lpi_vcpu_id = INVALID_VCPU_ID;
 }
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index d4ed23d..1c38b9a 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -90,6 +90,14 @@ struct pending_irq
  * TODO: when implementing irq migration, taking only the current
  * vgic lock is not going to be enough. */
 struct list_head lr_queue;
+/* The lock protects the consistency of this structure. A single status bit
+ * can be read and/or set without holding the lock using the atomic
+ * set_bit/clear_bit/test_bit functions, however accessing multiple bits or
+ * relating to other members in this struct requires the lock.
+ * The list_head members are protected by their corresponding VCPU lock,
+ * it is not sufficient to hold this pending_irq lock here to query or
+ * change list order or affiliation. */


Coding style:

/*
 * Foo
 * Bar
 */


+spinlock_t lock;
 };

 #define NR_INTERRUPT_PER_RANK   32
@@ -156,6 +164,9 @@ struct vgic_ops {
 #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
 #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)

+#define vgic_irq_lock(p, flags) spin_lock_irqsave(&(p)->lock, flags)
+#define vgic_irq_unlock(p, flags) spin_unlock_irqrestore(&(p)->lock, flags)
+
 #define vgic_lock_rank(v, r, flags)   spin_lock_irqsave(&(r)->lock, flags)
 #define vgic_unlock_rank(v, r, flags) spin_unlock_irqrestore(&(r)->lock, flags)




Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 112544: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 112544 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112544/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112536
 build-arm64   2 hosts-allocate  broken like 112536
 build-arm64-xsm   3 capture-logsbroken like 112536
 build-arm64-pvops 2 hosts-allocate  broken like 112536
 build-arm64-pvops 3 capture-logsbroken like 112536
 build-arm64   3 capture-logsbroken like 112536
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112536
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112536
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112536
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112536
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112536
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112536
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112536
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  f5c3e78b5c61e7dfb05749c7a0c862ec18c86384
baseline version:
 xen  f9c7a0ee87f23ae408a1ac4f948b96f51b911564

Last test of basis   112536  2017-08-09 13:55:12 Z1 days
Testing same since   112544  2017-08-10 04:20:44 Z0 days1 attempts


People who touched revisions under test:
  Olaf Hering 
  Wei Liu 

jobs:

Re: [Xen-devel] [PATCH] xsm/flask: Fix build following "xsm: correct AVC lookups for two sysctls"

On 10/08/17 14:17, Andrew Cooper wrote:
> avc_current_has_perm() takes 4 arguments, not 3.  Spotted by a Travis
> randconfig run which actually turned XSM on.

Sorry - I intended to add this link to the commit message.

~Andrew

https://travis-ci.org/xen-project/xen/jobs/263063220

>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Daniel De Graaf 
> ---
>  xen/xsm/flask/hooks.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 17560b1..9114627 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -815,11 +815,11 @@ static int flask_sysctl(int cmd)
>  
>  case XEN_SYSCTL_get_cpu_levelling_caps:
>  return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
> -XEN2__GET_CPU_LEVELLING_CAPS);
> +XEN2__GET_CPU_LEVELLING_CAPS, NULL);
>  
>  case XEN_SYSCTL_get_cpu_featureset:
>  return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
> -XEN2__GET_CPU_FEATURESET);
> +XEN2__GET_CPU_FEATURESET, NULL);
>  
>  case XEN_SYSCTL_livepatch_op:
>  return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 39/52] xen: check parameter validity when parsing command line

On Thu, Aug 10, 2017 at 03:24:05PM +0200, Juergen Gross wrote:
> On 10/08/17 15:02, Wei Liu wrote:
> > On Wed, Aug 09, 2017 at 09:06:53AM +0200, Juergen Gross wrote:
> >> Where possible check validity of parameters in _cmdline_parse() and
> >> issue a warning message in case of an error detected.
> >>
> >> Cc: Andrew Cooper 
> >> Cc: George Dunlap 
> >> Cc: Ian Jackson 
> >> Cc: Jan Beulich 
> >> Cc: Konrad Rzeszutek Wilk 
> >> Cc: Stefano Stabellini 
> >> Cc: Tim Deegan 
> >> Cc: Wei Liu 
> >> Signed-off-by: Juergen Gross 
> >> ---
> >>  xen/common/kernel.c | 44 ++--
> >>  1 file changed, 34 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> >> index ce7cb8adb5..3fd3abe79c 100644
> >> --- a/xen/common/kernel.c
> >> +++ b/xen/common/kernel.c
> >> @@ -23,9 +23,11 @@ enum system_state system_state = SYS_STATE_early_boot;
> >>  xen_commandline_t saved_cmdline;
> >>  static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
> >>  
> >> -static void __init assign_integer_param(
> >> +static int __init assign_integer_param(
> >>  const struct kernel_param *param, uint64_t val)
> >>  {
> >> +unsigned int bits = param->len * 8;
> >> +
> > 
> > BITS_PER_BYTE here.
> 
> Okay.
> 
> > 
> > Otherwise:
> > 
> > Reviewed-by: Wei Liu 
> 
> BTW: I've spotted a problem with parse_bool() in my patch: It should
> accept an empty string as "true", as specifying e.g. "sync_console"
> should set this option instead of issuing an error message.
> 
> Does your R-b: still stand with the correction below?
> 

Yes (with Jan's comment addressed)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH v2 01/22] ARM: vGIC: introduce and initialize pending_irq lock


Hi,

On 21/07/17 20:59, Andre Przywara wrote:

Currently we protect the pending_irq structure with the corresponding
VGIC VCPU lock. There are problems in certain corner cases (for
instance if an IRQ is migrating), so let's introduce a per-IRQ lock,
which will protect the consistency of this structure independent from
any VCPU.
For now this just introduces and initializes the lock, also adds
wrapper macros to simplify its usage (and help debugging).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c|  1 +
 xen/include/asm-arm/vgic.h | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 1e5107b..38dacd3 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -69,6 +69,7 @@ void vgic_init_pending_irq(struct pending_irq *p, unsigned 
int virq)
 memset(p, 0, sizeof(*p));
 INIT_LIST_HEAD(>inflight);
 INIT_LIST_HEAD(>lr_queue);
+spin_lock_init(>lock);
 p->irq = virq;
 p->lpi_vcpu_id = INVALID_VCPU_ID;
 }
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index d4ed23d..1c38b9a 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -90,6 +90,14 @@ struct pending_irq
  * TODO: when implementing irq migration, taking only the current
  * vgic lock is not going to be enough. */
 struct list_head lr_queue;
+/* The lock protects the consistency of this structure. A single status bit
+ * can be read and/or set without holding the lock using the atomic
+ * set_bit/clear_bit/test_bit functions, however accessing multiple bits or
+ * relating to other members in this struct requires the lock.
+ * The list_head members are protected by their corresponding VCPU lock,
+ * it is not sufficient to hold this pending_irq lock here to query or
+ * change list order or affiliation. */


Actually, I have on question here. Do the vCPU lock sufficient to 
protect the list_head members. Or do you also mandate the pending_irq to 
be locked as well?


Also, it would be good to have the locking order documented maybe in 
docs/misc?



+spinlock_t lock;
 };

 #define NR_INTERRUPT_PER_RANK   32
@@ -156,6 +164,9 @@ struct vgic_ops {
 #define vgic_lock(v)   spin_lock_irq(&(v)->domain->arch.vgic.lock)
 #define vgic_unlock(v) spin_unlock_irq(&(v)->domain->arch.vgic.lock)

+#define vgic_irq_lock(p, flags) spin_lock_irqsave(&(p)->lock, flags)
+#define vgic_irq_unlock(p, flags) spin_unlock_irqrestore(&(p)->lock, flags)
+
 #define vgic_lock_rank(v, r, flags)   spin_lock_irqsave(&(r)->lock, flags)
 #define vgic_unlock_rank(v, r, flags) spin_unlock_irqrestore(&(r)->lock, flags)




Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xsm/flask: Fix build following "xsm: correct AVC lookups for two sysctls"

avc_current_has_perm() takes 4 arguments, not 3.  Spotted by a Travis
randconfig run which actually turned XSM on.

Signed-off-by: Andrew Cooper 
---
CC: Daniel De Graaf 
---
 xen/xsm/flask/hooks.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 17560b1..9114627 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -815,11 +815,11 @@ static int flask_sysctl(int cmd)
 
 case XEN_SYSCTL_get_cpu_levelling_caps:
 return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
-XEN2__GET_CPU_LEVELLING_CAPS);
+XEN2__GET_CPU_LEVELLING_CAPS, NULL);
 
 case XEN_SYSCTL_get_cpu_featureset:
 return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
-XEN2__GET_CPU_FEATURESET);
+XEN2__GET_CPU_FEATURESET, NULL);
 
 case XEN_SYSCTL_livepatch_op:
 return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xen: remove struct domain and vcpu declarations from types.h

They don't belong there. Removing them causes build error in compat.h.
Add a struct domain declaration there because including sched.h
doesn't work.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/xen/compat.h | 1 +
 xen/include/xen/types.h  | 3 ---
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h
index ce6245c10f..895e2ff68d 100644
--- a/xen/include/xen/compat.h
+++ b/xen/include/xen/compat.h
@@ -227,6 +227,7 @@ void xlat_start_info(struct start_info *, enum 
XLAT_start_info_console);
 struct vcpu_runstate_info;
 void xlat_vcpu_runstate_info(struct vcpu_runstate_info *);
 
+struct domain;
 int switch_compat(struct domain *);
 
 #else
diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index 170e993558..b1dbb8720a 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -42,9 +42,6 @@ typedef __s32   int32_t;
 typedef __u64   uint64_t;
 typedef __s64   int64_t;
 
-struct domain;
-struct vcpu;
-
 typedef __u16 __le16;
 typedef __u16 __be16;
 typedef __u32 __le32;
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 39/52] xen: check parameter validity when parsing command line

On 10/08/17 15:02, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 09:06:53AM +0200, Juergen Gross wrote:
>> Where possible check validity of parameters in _cmdline_parse() and
>> issue a warning message in case of an error detected.
>>
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Tim Deegan 
>> Cc: Wei Liu 
>> Signed-off-by: Juergen Gross 
>> ---
>>  xen/common/kernel.c | 44 ++--
>>  1 file changed, 34 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
>> index ce7cb8adb5..3fd3abe79c 100644
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -23,9 +23,11 @@ enum system_state system_state = SYS_STATE_early_boot;
>>  xen_commandline_t saved_cmdline;
>>  static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
>>  
>> -static void __init assign_integer_param(
>> +static int __init assign_integer_param(
>>  const struct kernel_param *param, uint64_t val)
>>  {
>> +unsigned int bits = param->len * 8;
>> +
> 
> BITS_PER_BYTE here.

Okay.

> 
> Otherwise:
> 
> Reviewed-by: Wei Liu 

BTW: I've spotted a problem with parse_bool() in my patch: It should
accept an empty string as "true", as specifying e.g. "sync_console"
should set this option instead of issuing an error message.

Does your R-b: still stand with the correction below?

@@ -176,7 +200,8 @@ int __init parse_bool(const char *s)
  !strcmp("on", s) ||
  !strcmp("true", s) ||
  !strcmp("enable", s) ||
- !strcmp("1", s) )
+ !strcmp("1", s) ||
+ !strcmp("", s) )
 return 1;

 return -1;


Thanks,


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH v1 2/7] iommu/arm: ipmmu-vmsa: Add Xen changes for main driver

2017-08-10 Thread Oleksandr Tyshchenko

Hi, Julien

On Tue, Aug 8, 2017 at 2:34 PM, Julien Grall  wrote:
> Hi,
>
> On 26/07/17 16:09, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko 
>>
>> Modify the Linux IPMMU driver to be functional inside Xen.
>> All devices within a single Xen domain must use the same
>> IOMMU context no matter what IOMMU domains they are attached to.
>> This is the main difference between drivers in Linux
>> and Xen. Having 8 separate contexts allow us to passthrough
>> devices to 8 guest domain at the same time.
>>
>> Also wrap following code in #if 0:
>> - All DMA related stuff
>> - Linux PM callbacks
>> - Driver remove callback
>> - iommu_group management
>>
>> Maybe, it would be more correct to move different Linux2Xen wrappers,
>> define-s, helpers from IPMMU-VMSA and SMMU to some common file
>> before introducing IPMMU-VMSA patch series. And this common file
>> might be reused by possible future IOMMUs on ARM.
>
>
> Yes please if we go forward with the Linux way.
OK. I will keep it in mind.

>
>
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> CC: Julien Grall 
>> CC: Stefano Stabellini 
>> ---
>>  xen/drivers/passthrough/arm/ipmmu-vmsa.c | 984
>> +--
>>  1 file changed, 948 insertions(+), 36 deletions(-)
>>
>> diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> index 2b380ff..e54b507 100644
>> --- a/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> +++ b/xen/drivers/passthrough/arm/ipmmu-vmsa.c
>> @@ -6,31 +6,212 @@
>>   * This program is free software; you can redistribute it and/or modify
>>   * it under the terms of the GNU General Public License as published by
>>   * the Free Software Foundation; version 2 of the License.
>> + *
>> + * Based on Linux drivers/iommu/ipmmu-vmsa.c
>> + * => commit f4747eba89c9b5d90fdf0a5458866283c47395d8
>> + * (iommu/ipmmu-vmsa: Restrict IOMMU Domain Geometry to 32-bit address
>> space)
>> + *
>> + * Xen modification:
>> + * Oleksandr Tyshchenko 
>> + * Copyright (C) 2016-2017 EPAM Systems Inc.
>>   */
>>
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -#include 
>> -
>> -#if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
>> -#include 
>> -#include 
>> -#endif
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>
>>  #include "io-pgtable.h"
>>
>> +/* TODO:
>> + * 1. Optimize xen_domain->lock usage.
>> + * 2. Show domain_id in every printk which is per Xen domain.
>> + *
>> + */
>> +
>> +/* Start of Xen specific code */
>> +
>> +#define IOMMU_READ (1 << 0)
>> +#define IOMMU_WRITE(1 << 1)
>> +#define IOMMU_CACHE(1 << 2) /* DMA cache coherency */
>> +#define IOMMU_NOEXEC   (1 << 3)
>> +#define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
>> +
>> +#define __fls(x) (fls(x) - 1)
>> +#define __ffs(x) (ffs(x) - 1)
>> +
>> +#define IO_PGTABLE_QUIRK_ARM_NSBIT(0)
>> +
>> +#define ioread32 readl
>> +#define iowrite32 writel
>> +
>> +#define dev_info dev_notice
>> +
>> +#define devm_request_irq(unused, irq, func, flags, name, dev) \
>> +   request_irq(irq, flags, func, name, dev)
>> +
>> +/* Alias to Xen device tree helpers */
>> +#define device_node dt_device_node
>> +#define of_phandle_args dt_phandle_args
>> +#define of_device_id dt_device_match
>> +#define of_match_node dt_match_node
>> +#define of_parse_phandle_with_args dt_parse_phandle_with_args
>> +#define of_find_property dt_find_property
>> +#define of_count_phandle_with_args dt_count_phandle_with_args
>> +
>> +/* Xen: Helpers to get device MMIO and IRQs */
>> +struct resource
>> +{
>> +   u64 addr;
>> +   u64 size;
>> +   unsigned int type;
>> +};
>> +
>> +#define resource_size(res) (res)->size;
>> +
>> +#define platform_device dt_device_node
>> +
>> +#define IORESOURCE_MEM 0
>> +#define IORESOURCE_IRQ 1
>> +
>> +static struct resource *platform_get_resource(struct platform_device
>> *pdev,
>> + unsigned int type,
>> + unsigned int num)
>> +{
>> +   /*
>> +* The resource is only used between 2 calls of
>> platform_get_resource.
>> +* It's quite ugly but it's avoid to add too much code in the part
>> +* imported from Linux
>> +*/
>> +   static struct resource res;
>> +   int ret = 0;
>> +
>> +   res.type = type;
>> +
>> +   switch (type) {
>> +   case IORESOURCE_MEM:
>> +   ret = dt_device_get_address(pdev, num, ,
>> );
>> +
>> +   return

Re: [Xen-devel] [PATCH 39/52] xen: check parameter validity when parsing command line

>>> On 10.08.17 at 15:24,  wrote:
> @@ -176,7 +200,8 @@ int __init parse_bool(const char *s)
>   !strcmp("on", s) ||
>   !strcmp("true", s) ||
>   !strcmp("enable", s) ||
> - !strcmp("1", s) )
> + !strcmp("1", s) ||
> + !strcmp("", s) )

But not strcmp() please in such a case - !*s is quite sufficient there.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen Grant table frames for granting access permissions

2017-08-10 Thread Waseem, Amna

Hello All,

I am struggling with fixing the allocation of pages to some known physical 
pages used for mapping and granting access between guests.

I want to fix the allocation of pages i.e. their frame numbers to be be mapped 
to fixed physical pages. I only want to do this for pages shared between guests 
for mapping,c opying and transferring data.

Is there any way in linux to change mapping of already allocated pages to some 
fixed physical pages?
I want to change the mapping of pages allocated in kernel used by xen frontend 
and backend drivers to some fixed phsical address range.

I have looked into mremap functionality but it is used by user space 
applications, not by kernel drivers. ioremap maps a physcial address to a 
kernel virtual address space. But I want already allocated virtual address of 
page to a fixed physical page. I want to update its page table entry to point 
to fixed physical page.

Thanks
Amna 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen Grant table frames for granting access permissions

2017-08-10 Thread Waseem, Amna

Hello All,

I am struggling with fixing the allocation of pages to some known physical 
pages used for mapping and granting access between guests.

I want to fix the allocation of pages i.e. their frame numbers to be be mapped 
to fixed physical pages. I only want to do this for pages shared between guests 
for mapping,c opying and transferring data.

Is there any way in linux to change mapping of already allocated pages to some 
fixed physical pages?
I want to change the mapping of pages allocated in kernel used by xen frontend 
and backend drivers to some fixed phsical address range.

I have looked into mremap functionality but it is used by user space 
applications, not by kernel drivers. ioremap maps a physcial address to a 
kernel virtual address space. But I want already allocated virtual address of 
page to a fixed physical page. I want to update its page table entry to point 
to fixed physical page.

Thanks
Amna 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 112543: regressions - trouble: blocked/broken/fail/pass

flight 112543 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112543/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112456

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112456
 build-arm64   2 hosts-allocate  broken like 112456
 build-arm64-xsm   3 capture-logsbroken like 112456
 build-arm64   3 capture-logsbroken like 112456
 build-arm64-pvops 2 hosts-allocate  broken like 112456
 build-arm64-pvops 3 capture-logsbroken like 112456
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112456
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112456
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112456
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112456
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112456
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu54affb3a3623b1d36c95e34faa722a5831323a74
baseline version:
 qemuuac44ed2afb7c60255e989b163301479f5b4ecd04

Last test of basis   112456  2017-08-05 00:17:41 Z5 days
Failing since112506  2017-08-07 09:39:19 Z3 days6 attempts
Testing same since   112527  2017-08-09 02:02:47 Z1 days3 attempts


People who touched revisions under test:
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Cleber Rosa 
  Cornelia Huck 
  Daniel P. Berrange 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Greg Kurz

[Xen-devel] [ovmf test] 112547: regressions - FAIL

flight 112547 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112547/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm6 xen-buildfail REGR. vs. 112539
 build-i3866 xen-buildfail REGR. vs. 112539
 build-amd64-xsm   6 xen-buildfail REGR. vs. 112539
 build-amd64   6 xen-buildfail REGR. vs. 112539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 95cc9a51e1057ace27ef09b5e19fa45d3e66ef2b
baseline version:
 ovmf 7ef0dae092afcfb6fab7e8372c78097672168c4a

Last test of basis   112539  2017-08-09 16:46:45 Z0 days
Failing since112545  2017-08-10 04:47:25 Z0 days2 attempts
Testing same since   112547  2017-08-10 09:52:48 Z0 days1 attempts


People who touched revisions under test:
  Chris Ruffin 
  Huajing Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit 95cc9a51e1057ace27ef09b5e19fa45d3e66ef2b
Author: Chris Ruffin 
Date:   Thu Aug 3 23:37:42 2017 +0800

BaseTools/edksetup.sh: fix invalid test for current working directory

edksetup.sh implements a test that requires the current working
directory to contain the edksetup.sh script.  This test has the side
effect of requiring the WORKSPACE to be set to the same directory as
the edksetup.sh.  In a multiple workspace configuration, it is
required to be able to have a WORKSPACE that is different from the
directory that contains edksetup.sh.  This changeset skips this test
if PACKAGE_PATH is set.

Change-Id: Ie6f16a08c012baf4e650c48cc8e91cdc466d05f2
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chris Ruffin 
Reviewed-by: Yonghong Zhu 

commit d506d8db7168c2c12a9e7afe0bf9047d14ec4c54
Author: Huajing Li 
Date:   Mon Aug 7 15:51:43 2017 +0800

ShellPkg/driver: Show "-" in non-SFO mode

The patch shows "X"/"-" instead of "Y"/"N" in column "CFG"
and "DIAG".
The patch shows "-" instead of "0" in column "#D" and "#C".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Huajing Li 
Reviewed-by: Ruiyu Ni 

commit 416d48f755518fd1d202b97be2e9944df6e8f0d4
Author: Huajing Li 
Date:   Wed Aug 9 10:54:32 2017 +0800

ShellPkg/drivers: Show Image Name in non-SFO mode

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Huajing Li 
Reviewed-by: Ruiyu Ni 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen


Hi,

On 10/08/17 14:01, Wei Liu wrote:

On Thu, Aug 10, 2017 at 01:40:07PM +0100, Julien Grall wrote:

Hi Wei,

On 10/08/17 12:40, Wei Liu wrote:

On Thu, Aug 10, 2017 at 01:29:04PM +0530, Bhupinder Thakur wrote:

Hi Wei,

On 9 August 2017 at 16:33, Wei Liu  wrote:

On Wed, Aug 09, 2017 at 04:28:14PM +0530, Bhupinder Thakur wrote:

Hi Julien,

Thanks for the testing.

On 8 August 2017 at 21:29, Julien Grall  wrote:

Hi Bhupinder,

I gave another and I have a couple of comments.

Booting Linux with earlycon enabled take quite a while. I can see the
characters coming slower than on the minitel. It seems to be a bit better
after switching off the bootconsole. Overall Linux is taking ~20 times to
boot with pl011 vs HVC console.

I do agree that pl011 is emulated and therefore you have to trap after each
character. But 20 times sounds far too much.


I think this slowness could be due to ratelimiting of the pl011 events
in xenconosle. Currently, the rate limit is
set to 30 events per 200 msecs (see RATE_LIMIT_ALLOWANCE/RATE_LIMIT_PERIOD).

I increased the rate limit to 600 events (30 * 20) per 200 msecs. With
this change,
I see that the the find command is running faster and smoother.
Earlier the find output would be jerky.


Please consider batching the events instead of bumping the limit.


If I try to batch the events then it may delay per character
processing (if no further characters are coming) since we will wait
for more events to come to batch them together. By keeping the rate
limit high, it is ensured that it can handle large burst of events. If
there is sporadic data then the rate limit is not hit.


But do you really need to send an event for every character (that's my
reading of your patch, please correct me if I'm wrong)? Suppose you have
a buffer you can send one event when the buffer is processed.


I am not sure what you mean by buffer here. The interface with the guest is
a single data register. So characters are written one by one.


Yes, that's what the guest sees, but that is not necessarily what
xenconsoled sees.


I am a bit confused here. What are you suggesting? To send a 
notification every N characters?


In that case when do you assume that the buffer need to be flushed 
before N characters (e.g for the prompt)?


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 00/13] introduce the Xen PV Calls frontend

2017-08-10 Thread Boris Ostrovsky

On 07/31/2017 06:57 PM, Stefano Stabellini wrote:
> Hi all,
>
> this series introduces the frontend for the newly introduced PV Calls
> procotol.
>
> PV Calls is a paravirtualized protocol that allows the implementation of
> a set of POSIX functions in a different domain. The PV Calls frontend
> sends POSIX function calls to the backend, which implements them and
> returns a value to the frontend and acts on the function call.
>
> For more information about PV Calls, please read:
>
> https://xenbits.xen.org/docs/unstable/misc/pvcalls.html
>
> This patch series only implements the frontend driver. It doesn't
> attempt to redirect POSIX calls to it. The functions exported in
> pvcalls-front.h are meant to be used for that. A separate patch series
> will be sent to use them and hook them into the system.

Stefano,


Should this be reviewed or are you going to send another version?

-boris




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen

On Thu, Aug 10, 2017 at 03:31:57PM +0100, Julien Grall wrote:
> Hi,
> 
> On 10/08/17 14:01, Wei Liu wrote:
> > On Thu, Aug 10, 2017 at 01:40:07PM +0100, Julien Grall wrote:
> > > Hi Wei,
> > > 
> > > On 10/08/17 12:40, Wei Liu wrote:
> > > > On Thu, Aug 10, 2017 at 01:29:04PM +0530, Bhupinder Thakur wrote:
> > > > > Hi Wei,
> > > > > 
> > > > > On 9 August 2017 at 16:33, Wei Liu  wrote:
> > > > > > On Wed, Aug 09, 2017 at 04:28:14PM +0530, Bhupinder Thakur wrote:
> > > > > > > Hi Julien,
> > > > > > > 
> > > > > > > Thanks for the testing.
> > > > > > > 
> > > > > > > On 8 August 2017 at 21:29, Julien Grall  
> > > > > > > wrote:
> > > > > > > > Hi Bhupinder,
> > > > > > > > 
> > > > > > > > I gave another and I have a couple of comments.
> > > > > > > > 
> > > > > > > > Booting Linux with earlycon enabled take quite a while. I can 
> > > > > > > > see the
> > > > > > > > characters coming slower than on the minitel. It seems to be a 
> > > > > > > > bit better
> > > > > > > > after switching off the bootconsole. Overall Linux is taking 
> > > > > > > > ~20 times to
> > > > > > > > boot with pl011 vs HVC console.
> > > > > > > > 
> > > > > > > > I do agree that pl011 is emulated and therefore you have to 
> > > > > > > > trap after each
> > > > > > > > character. But 20 times sounds far too much.
> > > > > > > > 
> > > > > > > I think this slowness could be due to ratelimiting of the pl011 
> > > > > > > events
> > > > > > > in xenconosle. Currently, the rate limit is
> > > > > > > set to 30 events per 200 msecs (see 
> > > > > > > RATE_LIMIT_ALLOWANCE/RATE_LIMIT_PERIOD).
> > > > > > > 
> > > > > > > I increased the rate limit to 600 events (30 * 20) per 200 msecs. 
> > > > > > > With
> > > > > > > this change,
> > > > > > > I see that the the find command is running faster and smoother.
> > > > > > > Earlier the find output would be jerky.
> > > > > > 
> > > > > > Please consider batching the events instead of bumping the limit.
> > > > > 
> > > > > If I try to batch the events then it may delay per character
> > > > > processing (if no further characters are coming) since we will wait
> > > > > for more events to come to batch them together. By keeping the rate
> > > > > limit high, it is ensured that it can handle large burst of events. If
> > > > > there is sporadic data then the rate limit is not hit.
> > > > 
> > > > But do you really need to send an event for every character (that's my
> > > > reading of your patch, please correct me if I'm wrong)? Suppose you have
> > > > a buffer you can send one event when the buffer is processed.
> > > 
> > > I am not sure what you mean by buffer here. The interface with the guest 
> > > is
> > > a single data register. So characters are written one by one.
> > 
> > Yes, that's what the guest sees, but that is not necessarily what
> > xenconsoled sees.
> 
> I am a bit confused here. What are you suggesting? To send a notification

I think the other email you just sent is quite close to what I would
suggest. I will reply there.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen




On 10/08/17 17:00, Wei Liu wrote:

On Thu, Aug 10, 2017 at 03:26:07PM +0100, Julien Grall wrote:



On 09/08/17 11:58, Bhupinder Thakur wrote:

Hi Julien,


Hi Bhupinder,


Thanks for the testing.

On 8 August 2017 at 21:29, Julien Grall  wrote:

Hi Bhupinder,

I gave another and I have a couple of comments.

Booting Linux with earlycon enabled take quite a while. I can see the
characters coming slower than on the minitel. It seems to be a bit better
after switching off the bootconsole. Overall Linux is taking ~20 times to
boot with pl011 vs HVC console.

I do agree that pl011 is emulated and therefore you have to trap after each
character. But 20 times sounds far too much.


I think this slowness could be due to ratelimiting of the pl011 events
in xenconosle. Currently, the rate limit is
set to 30 events per 200 msecs (see RATE_LIMIT_ALLOWANCE/RATE_LIMIT_PERIOD).

I increased the rate limit to 600 events (30 * 20) per 200 msecs. With
this change,
I see that the the find command is running faster and smoother.
Earlier the find output would be jerky.


I think there might be another solution avoiding increasing the rate limit.

If you look at the earlycon code for pl011 in Linux:

static void pl011_putc(struct uart_port *port, int c)
{
while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
cpu_relax();
if (port->iotype == UPIO_MEM32)
writel(c, port->membase + UART01x_DR);
else
writeb(c, port->membase + UART01x_DR);
while (readl(port->membase + UART01x_FR) & UART01x_FR_BUSY)
cpu_relax();
}

Linux will wait the UART to be idle before sending a new character.

Now looking at vpl011 emulation, the busy bit set when a new character is
queued (see vpl011_write_data). This bit will only be cleared when the
console daemon will raise an event and the queue is empty (see
vpl011_data_avail).

This means for earlycon, you will need a round trip Guest -> Xen -> Dom0 ->
Xen -> Guest for each single character. This is a bit counterproductive and
combined with the limit it makes it worse.

I would take a different approach on the BUSY bit. We can consider the queue
between Xen and xenconsoled as outside of the UART. If the character is
queued, then job done. I think this would improve quite a lot of the
performance.


Yes. This.

The guest sees a register, which is essentially a synchronous interface
to the guest. The current code, as you already see, will issue one event
for every character. That's excessive.


I am actually not suggesting to modify that at the moment. I think you 
may have other trouble with the interaction between the user and th 
console by doing that. Imagine you want to print the prompt, it may lag 
a bit before getting it.


The only thing I suggest is to not set the BUSY bit in the UART 
everytime a character is queued.




The interface between Xen and xenconsoled can be asynchronous, it can
opt to queue X characters before sending an event, also setup a oneshot
timer to avoid hanging.

This however has some other implications -- it might not be as reliable
as the original method because data is not guaranteed to hit backend. If
the guest crashes very early on, depending the actual implementation you
might not be able get the data.


Would it be possible to ask xenconsoled to dump everything on domain 
crash? Some kind of synchronization.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Ping: [PATCH] x86emul: correct VEX.W handling for non-64-bit VPINSRD

>>> On 10.07.17 at 09:24,  wrote:
> Going though the XED commits from the last couple of months made me
> notice that VPINSRD, other than VPEXTRD, does not clear VEX.W for non-
> 64-bit modes, leading to an insertion of stray 32-bits of zero in case
> the original instruction had the bit set.
> 
> Also remove a pointless fall-through in VPEXTRW handling, bringing
> things in line with VPINSRW.
> 
> Signed-off-by: Jan Beulich 

Together with this one also
x86emul: correct VEX.L handling for VCVT{,T}S{S,D}2SI
x86emul: correct EVEX register extension bit handling for non-64-bit modes
(not to speak of the AVX etc series sent even longer ago)

Jan

> ---
> Correcting this made me further notice that the SDM states that
> VPEXTR{B,W} and VPINSR{B,W} require VEX.W to be clear in other than
> their EVEX encodings (which we don't support so far). XED and reality
> disagree, so things are being left unchanged there.
> 
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -6730,10 +6730,9 @@ x86_emulate(
>  ea.type = OP_MEM;
>  goto simd_0f_int_imm8;
>  
> +CASE_SIMD_PACKED_INT(0x0f, 0xc5):  /* pextrw $imm8,{,x}mm,reg */
>  case X86EMUL_OPC_VEX_66(0x0f, 0xc5):   /* vpextrw $imm8,xmm,reg */
>  generate_exception_if(vex.l, EXC_UD);
> -/* fall through */
> -CASE_SIMD_PACKED_INT(0x0f, 0xc5):  /* pextrw $imm8,{,x}mm,reg */
>  opc = init_prefixes(stub);
>  opc[0] = b;
>  /* Convert GPR destination to %rAX. */
> @@ -7512,6 +7511,8 @@ x86_emulate(
>  case X86EMUL_OPC_VEX_66(0x0f3a, 0x20): /* vpinsrb $imm8,r32/m8,xmm,xmm 
> */
>  case X86EMUL_OPC_VEX_66(0x0f3a, 0x22): /* vpinsr{d,q} $imm8,r/m,xmm,xmm 
> */
>  generate_exception_if(vex.l, EXC_UD);
> +if ( !mode_64bit() )
> +vex.w = 0;
>  memcpy(mmvalp, , op_bytes);
>  ea.type = OP_MEM;
>  op_bytes = src.bytes;
> 
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> https://lists.xen.org/xen-devel 




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Ping: [PATCH v3] x86/HVM: don't #GP/#SS on wrapping virt->linear translations

>>> On 10.07.17 at 12:39,  wrote:
> Real hardware wraps silently in most cases, so we should behave the
> same. Also split real and VM86 mode handling, as the latter really
> ought to have limit checks applied.
> 
> Signed-off-by: Jan Beulich 
> ---
> v3: Restore 32-bit wrap check for AMD.
> v2: Extend to non-64-bit modes. Reduce 64-bit check to a single
> is_canonical_address() invocation.
> 
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2416,16 +2416,21 @@ bool_t hvm_virtual_to_linear_addr(
>   */
>  ASSERT(seg < x86_seg_none);
>  
> -if ( !(curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) ||
> - (guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) )
> +if ( !(curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) )
>  {
>  /*
> - * REAL/VM86 MODE: Don't bother with segment access checks.
> + * REAL MODE: Don't bother with segment access checks.
>   * Certain of them are not done in native real mode anyway.
>   */
>  addr = (uint32_t)(addr + reg->base);
> -last_byte = (uint32_t)addr + bytes - !!bytes;
> -if ( last_byte < addr )
> +}
> +else if ( (guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) &&
> +  is_x86_user_segment(seg) )
> +{
> +/* VM86 MODE: Fixed 64k limits on all user segments. */
> +addr = (uint32_t)(addr + reg->base);
> +last_byte = (uint32_t)offset + bytes - !!bytes;
> +if ( max(offset, last_byte) >> 16 )
>  goto out;
>  }
>  else if ( hvm_long_mode_active(curr) &&
> @@ -2447,8 +2452,7 @@ bool_t hvm_virtual_to_linear_addr(
>  addr += reg->base;
>  
>  last_byte = addr + bytes - !!bytes;
> -if ( !is_canonical_address(addr) || last_byte < addr ||
> - !is_canonical_address(last_byte) )
> +if ( !is_canonical_address((long)addr < 0 ? addr : last_byte) )
>  goto out;
>  }
>  else
> @@ -2498,8 +2502,11 @@ bool_t hvm_virtual_to_linear_addr(
>  if ( (offset <= reg->limit) || (last_byte < offset) )
>  goto out;
>  }
> -else if ( (last_byte > reg->limit) || (last_byte < offset) )
> -goto out; /* last byte is beyond limit or wraps 0x */
> +else if ( last_byte > reg->limit )
> +goto out; /* last byte is beyond limit */
> +else if ( last_byte < offset &&
> +  curr->domain->arch.cpuid->x86_vendor == X86_VENDOR_AMD )
> +goto out; /* access wraps */
>  }
>  
>  /* All checks ok. */




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] IOMMU/PCI: properly annotate setup_one_hwdom_device()

Its sole caller is __hwdom_init, so it can be such itself, too.

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1026,8 +1026,8 @@ struct setup_hwdom {
 int (*handler)(u8 devfn, struct pci_dev *);
 };
 
-static void setup_one_hwdom_device(const struct setup_hwdom *ctxt,
-  struct pci_dev *pdev)
+static void __hwdom_init setup_one_hwdom_device(const struct setup_hwdom *ctxt,
+struct pci_dev *pdev)
 {
 u8 devfn = pdev->devfn;
 




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

>>> On 09.08.17 at 23:39,  wrote:
> On 09.08.17 14:58, Jan Beulich wrote:
> On 09.08.17 at 12:10,  wrote:
>>> On 08/08/17 21:08, Volodymyr Babchuk wrote:
 +#ifndef __XEN_PUBLIC_ARCH_ARM_SMC_H__
 +#define __XEN_PUBLIC_ARCH_ARM_SMC_H__
 +
 +typedef struct {
 +uint32_t a[4];
 +} xen_arm_smccc_uid;
>> 
>> This is not the normal way of encoding a UID type.
> Just to be clear: you are proposing to store UID in such struct
> struct uuid_t {
>  unsigned32  time_low;
>  unsigned16  time_mid;
>  unsigned16  time_hi_and_version;
>  unsigned8   clock_seq_hi_and_reserved;
>  unsigned8   clock_seq_low;
>  bytenode[6];
> };
> right?

Type-wise yes; the names of the fields look uncommon to me.

 +#define XEN_ARM_SMCCC_UID(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)  \
 +((xen_arm_smccc_uid) {{(a), ((b) << 16 | (c) ), \
>>
>> This is not C89 compatible.
> Oops, sorry. Didn't knew that XEN should be C89 compatible.
> Is there any guide for novices? I didn't found anything useful in docs/ 
> (not even coding style document). On wiki I have found only 
> "Submitting_Xen_Project_Patches" page, which is very helpful, but it 
> does not cover topics like which C standard to use.

The public headers are required to the C89 compatible; Xen
code in general is fine to use extensions.

 +((d0) << 24 | (d1) << 16 | (d2) << 8 | (d3) << 0),  \
 +((d4) << 24 | (d5) << 16 | (d6) << 8 | (d7) << 0)}})
 +
 +/*
 + * Hypervisor Service version.
 + *
 + * We can't use XEN version here, because of SMCCC requirements:
 + * Major revision should change every time SMC/HVC function is removed.
 + * Minor revision should change every time SMC/HVC function is added.
 + * So, it is SMCCC protocol revision code, not XEN version.
>> 
>> I don't understand this explanation - how is the situation here
>> different from some arbitrary, non-toolstack-only hypercall?
> Because this is generic interface that should be supported by all 
> hypervisors, including XEN. Think about this as a way for a guest to 
> determine under which hypervisor it operates, and which functions it 
> provides.

In which case - why the XEN_ prefixes?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] common/domain_page: Drop domain_mmap_cache infrastructure

>>> On 09.08.17 at 20:21,  wrote:
> This infrastructure is used exclusively by the x86 do_mmu_update() hypercall.
> Mapping and unmapping domain pages is probably not the slow part of that
> function, but even with an opencoded caching implementation, Bloat-o-meter
> reports:
> 
>   function old new   delta
>   do_mmu_update   68156573-242
> 
> The !CONFIG_DOMAIN_PAGE stub code has a mismatch between mapping and
> unmapping, which is a latent bug.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 112545: regressions - FAIL

flight 112545 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112545/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm6 xen-buildfail REGR. vs. 112539
 build-i3866 xen-buildfail REGR. vs. 112539
 build-amd64-xsm   6 xen-buildfail REGR. vs. 112539
 build-amd64   6 xen-buildfail REGR. vs. 112539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf d506d8db7168c2c12a9e7afe0bf9047d14ec4c54
baseline version:
 ovmf 7ef0dae092afcfb6fab7e8372c78097672168c4a

Last test of basis   112539  2017-08-09 16:46:45 Z0 days
Testing same since   112545  2017-08-10 04:47:25 Z0 days1 attempts


People who touched revisions under test:
  Huajing Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit d506d8db7168c2c12a9e7afe0bf9047d14ec4c54
Author: Huajing Li 
Date:   Mon Aug 7 15:51:43 2017 +0800

ShellPkg/driver: Show "-" in non-SFO mode

The patch shows "X"/"-" instead of "Y"/"N" in column "CFG"
and "DIAG".
The patch shows "-" instead of "0" in column "#D" and "#C".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Huajing Li 
Reviewed-by: Ruiyu Ni 

commit 416d48f755518fd1d202b97be2e9944df6e8f0d4
Author: Huajing Li 
Date:   Wed Aug 9 10:54:32 2017 +0800

ShellPkg/drivers: Show Image Name in non-SFO mode

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Huajing Li 
Reviewed-by: Ruiyu Ni 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/HVM: fix boundary check in hvmemul_insn_fetch() (again)

2017-08-10 Thread Paul Durrant

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 10 August 2017 08:28
> To: xen-devel 
> Cc: Andrew Cooper ; Paul Durrant
> 
> Subject: [PATCH] x86/HVM: fix boundary check in hvmemul_insn_fetch()
> (again)
> 
> Commit 5a992b670b ("x86/hvm: Fix boundary check in
> hvmemul_insn_fetch()") went a little too far in its correction to
> commit 0943a03037 ("x86/hvm: Fixes to hvmemul_insn_fetch()"): Keep the
> start offset check, but restore the original end offset one.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -959,7 +959,7 @@ int hvmemul_insn_fetch(
>   * which means something went wrong with instruction decoding...
>   */
>  if ( insn_off >= sizeof(hvmemul_ctxt->insn_buf) ||
> - (insn_off + bytes) >= sizeof(hvmemul_ctxt->insn_buf) )
> + insn_off + bytes > sizeof(hvmemul_ctxt->insn_buf) )

I thought it was generally good style to have brackets in clauses such as this. 
Anyway...

Reviewed-by: Paul Durrant 

>  {
>  ASSERT_UNREACHABLE();
>  return X86EMUL_UNHANDLEABLE;
> 
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-blkfront: use a right index when checking requests

2017-08-10 Thread Roger Pau Monne

On Wed, Aug 09, 2017 at 03:31:40PM -0700, Munehisa Kamata wrote:
> Since commit d05d7f40791c ("Merge branch 'for-4.8/core' of
> git://git.kernel.dk/linux-block") and 3fc9d690936f ("Merge branch
> 'for-4.8/drivers' of git://git.kernel.dk/linux-block"), blkfront_resume()
> has been using an index for iterating ring_info to check request when
> iterating blk_shadow in an inner loop. This seems to have been
> accidentally introduced during the massive rewrite of the block layer
> macros in the commits.
> 
> This may cause crash like this:
> 
> [11798.057074] BUG: unable to handle kernel NULL pointer dereference at 
> 0048
> [11798.058832] IP: [] blkfront_resume+0x10a/0x610
> 
> [11798.061063] Call Trace:
> [11798.061063]  [] xenbus_dev_resume+0x53/0x140
> [11798.061063]  [] ? xenbus_dev_probe+0x150/0x150
> [11798.061063]  [] dpm_run_callback+0x3e/0x110
> [11798.061063]  [] device_resume+0x88/0x190
> [11798.061063]  [] dpm_resume+0x100/0x2d0
> [11798.061063]  [] dpm_resume_end+0x11/0x20
> [11798.061063]  [] do_suspend+0xe8/0x1a0
> [11798.061063]  [] shutdown_handler+0xfd/0x130
> [11798.061063]  [] ? split+0x110/0x110
> [11798.061063]  [] xenwatch_thread+0x86/0x120
> [11798.061063]  [] ? prepare_to_wait_event+0x110/0x110
> [11798.061063]  [] kthread+0xd7/0xf0
> [11798.061063]  [] ? kfree+0x121/0x170
> [11798.061063]  [] ? kthread_park+0x60/0x60
> [11798.061063]  [] ?  
> call_usermodehelper_exec_work+0xb0/0xb0
> [11798.061063]  [] ?  
> call_usermodehelper_exec_async+0x13a/0x140
> [11798.061063]  [] ret_from_fork+0x25/0x30
> 
> Use the right index in the inner loop.
> 
> Fixes: d05d7f40791c ("Merge branch 'for-4.8/core' of 
> git://git.kernel.dk/linux-block")
> Fixes: 3fc9d690936f ("Merge branch 'for-4.8/drivers' of 
> git://git.kernel.dk/linux-block")
> Signed-off-by: Munehisa Kamata 
> Reviewed-by: Thomas Friebel 
> Reviewed-by: Eduardo Valentin 
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Roger Pau Monne 
> Cc: xen-de...@lists.xenproject.org
> Cc: sta...@vger.kernel.org

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] x86/HVM: fix boundary check in hvmemul_insn_fetch() (again)

Commit 5a992b670b ("x86/hvm: Fix boundary check in
hvmemul_insn_fetch()") went a little too far in its correction to
commit 0943a03037 ("x86/hvm: Fixes to hvmemul_insn_fetch()"): Keep the
start offset check, but restore the original end offset one.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -959,7 +959,7 @@ int hvmemul_insn_fetch(
  * which means something went wrong with instruction decoding...
  */
 if ( insn_off >= sizeof(hvmemul_ctxt->insn_buf) ||
- (insn_off + bytes) >= sizeof(hvmemul_ctxt->insn_buf) )
+ insn_off + bytes > sizeof(hvmemul_ctxt->insn_buf) )
 {
 ASSERT_UNREACHABLE();
 return X86EMUL_UNHANDLEABLE;




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/mm: make various hotplug related functions static

On 10/08/2017 08:27, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] IOMMU/PCI: properly annotate setup_one_hwdom_device()

On 10/08/2017 08:25, Jan Beulich wrote:
> Its sole caller is __hwdom_init, so it can be such itself, too.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen Backend for sound sharing for arm

2017-08-10 Thread ajmalmalib4u

Hi,
I need to do sound sharing in RCar H3.I am currently using Xen 4.8.0. I tried to patch the guest kernel(v 4.6.0) using the patch series [[RESEND1,01/12] ALSA: vsnd: Introduce Xen para-virtualized sound frontend driver] to add the support for Xen para-virtualized sound frontend driver which was made available a few days ago.

I got some errors which I guess were due to the old kernel version. So I downloaded the current stable Linux 4.12.5 from kernel.org and tried to add the patches to it. But the patch failed due to missing fields in snd_pcm_ops in pcm.h. As such, I had to patch the kernel with a different patch series[[v2,02/27] ALSA: pcm: Introduce copy_user, copy_kernel and fill_silence ops],[ALSA: sound/isa: constify snd_kcontrol_new structures][ALSA: gus: remove unused local flag] to add the new fields to pcm.h. Also, I had to copy an SoC specific firmware file[r8a779x_usb3_v2.dlmem] to the firmware directory of the kernel directory. Finally after applying all these patches to v4.12.5 and building the kernel, I got the snd-xen-front.ko file in sound/drivers/.

How can I test whether the sound frontend is working? Is the backend for sound available for sndif.h?

 

Regards,

Ajmal

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/3] Qemu: Add Xen vIOMMU interrupt remapping function support

2017-08-10 Thread Paolo Bonzini

On 09/08/2017 22:51, Lan Tianyu wrote:
> This patchset is to deal with MSI interrupt remapping request when guest
> updates MSI registers.
> 
> Chao Gao (3):
>   i386/msi: Correct mask of destination ID in MSI address
>   xen-pt: bind/unbind interrupt remapping format MSI
>   msi: Handle remappable format interrupt request
> 
>  configure |  4 +++-
>  hw/i386/xen/xen-hvm.c |  8 ++-
>  hw/pci/msi.c  |  5 +++--
>  hw/pci/msix.c |  4 +++-
>  hw/xen/xen_pt_msi.c   | 52 
> +++
>  include/hw/i386/apic-msidef.h |  3 ++-
>  include/hw/xen/xen.h  |  2 +-
>  include/hw/xen/xen_common.h   | 25 +
>  stubs/xen-hvm.c   |  2 +-
>  9 files changed, 83 insertions(+), 22 deletions(-)
> 

Non-Xen parts look good (though I cannot ack them).

Paolo

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/3] Qemu: Add Xen vIOMMU interrupt remapping function support

2017-08-10 Thread Lan Tianyu

On 2017年08月10日 17:04, Paolo Bonzini wrote:
> On 09/08/2017 22:51, Lan Tianyu wrote:
>> This patchset is to deal with MSI interrupt remapping request when guest
>> updates MSI registers.
>>
>> Chao Gao (3):
>>   i386/msi: Correct mask of destination ID in MSI address
>>   xen-pt: bind/unbind interrupt remapping format MSI
>>   msi: Handle remappable format interrupt request
>>
>>  configure |  4 +++-
>>  hw/i386/xen/xen-hvm.c |  8 ++-
>>  hw/pci/msi.c  |  5 +++--
>>  hw/pci/msix.c |  4 +++-
>>  hw/xen/xen_pt_msi.c   | 52 
>> +++
>>  include/hw/i386/apic-msidef.h |  3 ++-
>>  include/hw/xen/xen.h  |  2 +-
>>  include/hw/xen/xen_common.h   | 25 +
>>  stubs/xen-hvm.c   |  2 +-
>>  9 files changed, 83 insertions(+), 22 deletions(-)
>>
> 
> Non-Xen parts look good (though I cannot ack them).
> 
> Paolo
> 

Never minder. Thanks for your review.

-- 
Best regards
Tianyu Lan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

2017-08-10 Thread Oleksandr Andrushchenko


Hi,

thank you very much for valuable comments and your time!

On 08/10/2017 06:14 AM, Takashi Sakamoto wrote:

Hi,

On Aug 7 2017 21:22, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Thank you,
Oleksandr

Resending because of rebase onto [2] + added missing patch

[1] https://xenproject.org/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-next


Oleksandr Andrushchenko (12):
   ALSA: vsnd: Introduce Xen para-virtualized sound frontend driver
   ALSA: vsnd: Implement driver's probe/remove
   ALSA: vsnd: Implement Xen bus state handling
   ALSA: vsnd: Read sound driver configuration from Xen store
   ALSA: vsnd: Implement Xen event channel handling
   ALSA: vsnd: Implement handling of shared buffers
   ALSA: vsnd: Introduce ALSA virtual sound driver
   ALSA: vsnd: Initialize virtul sound card
   ALSA: vsnd: Add timer for period interrupt emulation
   ALSA: vsnd: Implement ALSA PCM operations
   ALSA: vsnd: Implement communication with backend
   ALSA: vsnd: Introduce Kconfig option to enable Xen PV sound

  sound/drivers/Kconfig |   12 +
  sound/drivers/Makefile|2 +
  sound/drivers/xen-front.c | 2107 
+

  3 files changed, 2121 insertions(+)
  create mode 100644 sound/drivers/xen-front.c


For this patchset, I have the same concern which Clemens Ladisch
denoted[1]. If I can understand your explanation about queueing between
Dom0/DomU stuffs, the concern can be described in short words; this
driver works without any synchronization to data transmission by actual
sound hardwares.


Yes, both your concerns and understanding are correct

In design of ALSA PCM core, drivers are expected to synchronize to
actual hardwares for semi-realtime data transmission. The
synchronization is done by two points:
1) Interrupts to respond events from actual hardwares.
2) Positions of actual data transmission in any serial sound interfaces
   of actual hardwares.

These two points comes from typical designs of actual hardwares, thus
they doesn't come from unfair, unreasonable, intrusive demands from
software side.


This clear, thank you

In design of typical stuffs on para-virtualization, Dom0 stuffs are hard
to give enough abstraction of sound hardwares in these two points for
DomU stuffs. Especially, it cannot abstract point 2) at all because the
value of position should be accurate against actual time frame, while
there's an overhead for DomU stuffs to read it. When DomU stuffs handles
the value, the value is enough past due to context switches between
Dom0/DomU. Therefore, this driver must rely on point 1) to synchronize
to actual sound hardwares.

Which will also introduce some latency too: time needed to deliver and
handle interrupt from Dom0 to DomU

Typically, drivers configure hardwares to
generate interrupts per period of PCM buffer. This means that this
driver should notify to Dom0 about the value of period size requested
by applications.

In 'include/xen/interface/io/sndif.h', there's no functionalities I
described the above:
1. notifications from DomU to Dom0 about the size of period for
   interrupts from actual hardwares. Or no way from Dom0 to DomU about
   the configured size of the period.

Ok, then on "open" command I will pass from DomU to Dom0 an additional
parameter, period size. Then Dom0 will respond with actual period size
for DomU to use. So, this way period size will be negotiated.
Does the above look ok to you?

2. notifications of the interrupts from actual hardwares to DomU.


Ok, I will introduce an event from Dom0 to DomU to signal period elapsed.

Taking into account the fact that period size may be as small as,
say, 1ms, do you think we can/need to mangle period size in 1) on Dom0 side
to be reasonable, so we do not flood with interrupts/events from Dom0 to 
DomU?

Do you see any "formula" to determine that reasonable/acceptable
period limit, so both Dom0 and DomU are happy?


For the reasons, your driver used kernel's timer interface to generate
'pseudo' interrupts for the purpose. However, it depends on Dom0's
abstraction different from sound hardwares and Linux kernel's
abstraction for timer functionality. In this case, gap between 'actual'
interrupts from hardware and the 'pseudo' interrupts from a combination
of several components brings unexpected result on several situations.


You are right

I think this is defects of 'sndif' interface in Xen side. I think it
better for you to work in

Re: [Xen-devel] [PATCH] IOMMU/PCI: properly annotate setup_one_hwdom_device()

2017-08-10 Thread Roger Pau Monné

On Thu, Aug 10, 2017 at 01:25:35AM -0600, Jan Beulich wrote:
> Its sole caller is __hwdom_init, so it can be such itself, too.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Roger Pau Monné 

Had the same patch in my queue, but you beat it to me.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] x86/mm: make various hotplug related functions static

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -106,7 +106,7 @@ struct mem_hotadd_info
 unsigned long cur;
 };
 
-int hotadd_mem_valid(unsigned long pfn, struct mem_hotadd_info *info)
+static int hotadd_mem_valid(unsigned long pfn, struct mem_hotadd_info *info)
 {
 return (pfn < info->epfn && pfn >= info->spfn);
 }
@@ -156,7 +156,7 @@ static int m2p_mapped(unsigned long spfn
 return M2P_NO_MAPPED;
 }
 
-int share_hotadd_m2p_table(struct mem_hotadd_info *info)
+static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
 {
 unsigned long i, n, v, m2p_start_mfn = 0;
 l3_pgentry_t l3e;
@@ -257,7 +257,7 @@ static void destroy_compat_m2p_mapping(s
 return;
 }
 
-void destroy_m2p_mapping(struct mem_hotadd_info *info)
+static void destroy_m2p_mapping(struct mem_hotadd_info *info)
 {
 l3_pgentry_t *l3_ro_mpt;
 unsigned long i, va, rwva;
@@ -712,7 +712,7 @@ void free_compat_arg_xlat(struct vcpu *v
   PFN_UP(COMPAT_ARG_XLAT_SIZE));
 }
 
-void cleanup_frame_table(struct mem_hotadd_info *info)
+static void cleanup_frame_table(struct mem_hotadd_info *info)
 {
 unsigned long sva, eva;
 l3_pgentry_t l3e;
@@ -1272,7 +1272,7 @@ unsigned int domain_clamp_alloc_bitsize(
 return min(d->arch.physaddr_bitsize, bits);
 }
 
-int transfer_pages_to_heap(struct mem_hotadd_info *info)
+static int transfer_pages_to_heap(struct mem_hotadd_info *info)
 {
 unsigned long i;
 struct page_info *pg;
@@ -1292,7 +1292,7 @@ int transfer_pages_to_heap(struct mem_ho
 return 0;
 }
 
-int mem_hotadd_check(unsigned long spfn, unsigned long epfn)
+static int mem_hotadd_check(unsigned long spfn, unsigned long epfn)
 {
 unsigned long s, e, length, sidx, eidx;
 




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen

2017-08-10 Thread Bhupinder Thakur

Hi Wei,

On 9 August 2017 at 16:33, Wei Liu  wrote:
> On Wed, Aug 09, 2017 at 04:28:14PM +0530, Bhupinder Thakur wrote:
>> Hi Julien,
>>
>> Thanks for the testing.
>>
>> On 8 August 2017 at 21:29, Julien Grall  wrote:
>> > Hi Bhupinder,
>> >
>> > I gave another and I have a couple of comments.
>> >
>> > Booting Linux with earlycon enabled take quite a while. I can see the
>> > characters coming slower than on the minitel. It seems to be a bit better
>> > after switching off the bootconsole. Overall Linux is taking ~20 times to
>> > boot with pl011 vs HVC console.
>> >
>> > I do agree that pl011 is emulated and therefore you have to trap after each
>> > character. But 20 times sounds far too much.
>> >
>> I think this slowness could be due to ratelimiting of the pl011 events
>> in xenconosle. Currently, the rate limit is
>> set to 30 events per 200 msecs (see RATE_LIMIT_ALLOWANCE/RATE_LIMIT_PERIOD).
>>
>> I increased the rate limit to 600 events (30 * 20) per 200 msecs. With
>> this change,
>> I see that the the find command is running faster and smoother.
>> Earlier the find output would be jerky.
>
> Please consider batching the events instead of bumping the limit.

If I try to batch the events then it may delay per character
processing (if no further characters are coming) since we will wait
for more events to come to batch them together. By keeping the rate
limit high, it is ensured that it can handle large burst of events. If
there is sporadic data then the rate limit is not hit.

I am thinking of making the rate limit configuration per console.

Regards,
Bhupinder

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/4] ARM: ACPI: ITS: Add ITS Support for ACPI hardware domain




On 08/10/2017 02:00 PM, Manish Jaggi wrote:

HI Julien,

On 8/10/2017 5:43 PM, Julien Grall wrote:



On 10/08/17 13:00, Manish Jaggi wrote:

Hi Julien,

On 8/10/2017 4:58 PM, Julien Grall wrote:



On 10/08/17 12:21, Manish Jaggi wrote:

Hi Julien,

On 6/21/2017 6:53 PM, Julien Grall wrote:

Hi Manish,

On 21/06/17 02:01, Manish Jaggi wrote:

This patch series adds the support of ITS for ACPI hardware domain.
It is tested on staging branch with has ITS v12 patchset by Andre.

I have tried to incorporate the review comments on the RFC v1/v2
patch.
The single patch in RFC is now split into 4 patches.


I will comment here rather than on each patches.



Patch1: ARM: ITS: Add translation_id to host_its
 Adds translation_id in host_its data structure, which is populated
from
 translation_id read from firmwar MADT. This value is then 
programmed

into
 local MADT created for hardware domain in patch 4.


I don't see any reason to store value that will only be used for
generating the MADT which BTW is just a copy for the ITS. Instead we
should copy over the MADT entries.


There are two approaches,

If I use the standard API  acpi_table_parse_madt which would iterate
over ACPI_MADT_TYPE_GENERIC_TRANSLATOR entries, I have to maintain the
addr and translation_id in some data structure, to be filled later in
the hwdomain copy of madt generic translator.

If I don't use the standard API I have to add code to manually 
parse all

the translator entries.


There are a 3rd approach I suggested and ignored... The ITS entries
for Dom0 is exactly the same as the host entries.

Yes, and if not passed properly dom0 wont get device interrupts...

So you only need to do a verbatim copy of the entry...


Can you please check patch 4/2, the translation_id and address are
passed verbatim, the other values are reserved in
acpi_madt_generic_translator.


For ACPI, we took the approach to only rewrite what's necessary and 
give the rest to Dom0 as it is. If newer version of ACPI re-used those 
fields, then they will be copied over to Dom0. I don't consider it as 
an issue because the problem would be the same if those fields have an 
important meaning for the platform.

Few thoughts...
If we follow this approach, few points needs to be considered
- If ACPI may use the reserved information later it could be equally 
important for dom0 and Xen,

  so it might be useful to keep reserved in xen as well.


I already covered that in my previous e-mail.



- For platforms which use dt, translation_id is not required to be 
stored in struct host_its, similarly for platforms which use acpi

dt_node pointer might be of no use.

So we can have struct host_its having a union with dt_device_node * for 
dt and acpi_madt_generic_translator * for acpi.

IMHO this could be an approach we can take.

struct host_its {
  struct list_head entry;
-const struct dt_device_node *dt_node;
+   union {
+const struct dt_device_node *dt_node;
+const struct acpi_madt_generic_translator *acpi_its_entry;
+};
 paddr_t addr;


What don't you get in my previous e-mail? A no is a no, full stop.

Just do what we do in *_make_hwdom_madt. That will work here with no 
need of a union or anything else. Even the DT code can be reworked to 
avoid storing the node.


We could even have the common code go through the MADT entry one by one 
and let the specific driver updating what's necessary avoid ACPI_MEMCPY 
duplication in each bit. But this is a longer term thoughts than for.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: remove struct domain and vcpu declarations from types.h

>>> On 10.08.17 at 15:24,  wrote:
> They don't belong there. Removing them causes build error in compat.h.
> Add a struct domain declaration there because including sched.h
> doesn't work.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xsm/flask: Fix build following "xsm: correct AVC lookups for two sysctls"

2017-08-10 Thread Daniel De Graaf


On 08/10/2017 09:17 AM, Andrew Cooper wrote:

avc_current_has_perm() takes 4 arguments, not 3.  Spotted by a Travis
randconfig run which actually turned XSM on.

Signed-off-by: Andrew Cooper 


Whoops, looks like I sent the non-build-tested patch by accident.
Thanks for catching this!

Acked-by: Daniel De Graaf 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 112554: tolerable trouble: broken/pass - PUSHED

flight 112554 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112554/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112549
 build-arm64   2 hosts-allocate  broken like 112549
 build-arm64-pvops 3 capture-logsbroken like 112549
 build-arm64   3 capture-logsbroken like 112549
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  a19faa0100708c70a179eb5cf23a7b7789dab5e3
baseline version:
 xen  d73168728c49a21da88989e548f01c5947a5b538

Last test of basis   112549  2017-08-10 11:01:34 Z0 days
Testing same since   112554  2017-08-10 13:01:16 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=a19faa0100708c70a179eb5cf23a7b7789dab5e3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
a19faa0100708c70a179eb5cf23a7b7789dab5e3
+ branch=xen-unstable-smoke
+ revision=a19faa0100708c70a179eb5cf23a7b7789dab5e3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' xa19faa0100708c70a179eb5cf23a7b7789dab5e3 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ :

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

2017-08-10 Thread Volodymyr Babchuk


Hi Julien,

On 09.08.17 13:10, Julien Grall wrote:

Hi Volodymyr,

CC "THE REST" maintainers to get an opinion on the public headers.

On 08/08/17 21:08, Volodymyr Babchuk wrote:

SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to a 
different

firmware functions. Thus, for example PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such calls.
Besides functional calls there are query calls, which allows underling
OS determine version, UID and number of functions provided by service
provider.

This patch adds new file `vsmc.c`, which handles both generic SMCs
and HVC according to SMC. At this moment it implements only one
service: Standard Hypervisor Service.

Standard Hypervisor Service only supports query calls, so caller can
ask about hypervisor UID and determine that it is XEN running.

This change allows more generic handling for SMCs and HVCs and it can
be easily extended to support new services and functions.

But, before SMC is forwarded to standard SMCCC handler, it can be routed
to a domain monitor, if one is installed.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko 
Reviewed-by: Oleksandr Tyshchenko 
---
 - Updated description to indicate that this patch affects only SMC 
call path.

 - added "xen_" prefix to definitions in include/public/arch-arm/smc.h
 - moved do_trap_smc() into vsmc.c from traps.c
 - replaced all tabs with spaces


I would have really appreciated a summary of the discussion we had on 
the previous version regarding the bindings. This is a real blocker for 
this series and should not be ignored.




While I agree that question about bindings is important, I can't see how 
it affects this patch series. This patch series does not break anything.

Because

1. This series add only new feature: generic hypervisor service with no 
immediate use. All ARM guests are already aware that they are running on 
XEN. All ARM guests know that they call *only* PSCI.


2. I see importance of this patch series for embedded platforms, where 
developer exactly knows what software of which version he/she will run. 
I doubt that server platforms will need something beyond PSCI, which I 
preserved as is.


A I'm not denying importance of SMC bindings, but I think it is not 
blocker for my patches. We can add bindings later, when there will be 
consensus on how they should look. In meantime SMC handler can be used 
by anyone who knows that is available.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 112558: regressions - FAIL

flight 112558 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112558/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm6 xen-buildfail REGR. vs. 112539
 build-i3866 xen-buildfail REGR. vs. 112539
 build-amd64-xsm   6 xen-buildfail REGR. vs. 112539
 build-amd64   6 xen-buildfail REGR. vs. 112539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 95cc9a51e1057ace27ef09b5e19fa45d3e66ef2b
baseline version:
 ovmf 7ef0dae092afcfb6fab7e8372c78097672168c4a

Last test of basis   112539  2017-08-09 16:46:45 Z0 days
Failing since112545  2017-08-10 04:47:25 Z0 days3 attempts
Testing same since   112547  2017-08-10 09:52:48 Z0 days2 attempts


People who touched revisions under test:
  Chris Ruffin 
  Huajing Li 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit 95cc9a51e1057ace27ef09b5e19fa45d3e66ef2b
Author: Chris Ruffin 
Date:   Thu Aug 3 23:37:42 2017 +0800

BaseTools/edksetup.sh: fix invalid test for current working directory

edksetup.sh implements a test that requires the current working
directory to contain the edksetup.sh script.  This test has the side
effect of requiring the WORKSPACE to be set to the same directory as
the edksetup.sh.  In a multiple workspace configuration, it is
required to be able to have a WORKSPACE that is different from the
directory that contains edksetup.sh.  This changeset skips this test
if PACKAGE_PATH is set.

Change-Id: Ie6f16a08c012baf4e650c48cc8e91cdc466d05f2
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chris Ruffin 
Reviewed-by: Yonghong Zhu 

commit d506d8db7168c2c12a9e7afe0bf9047d14ec4c54
Author: Huajing Li 
Date:   Mon Aug 7 15:51:43 2017 +0800

ShellPkg/driver: Show "-" in non-SFO mode

The patch shows "X"/"-" instead of "Y"/"N" in column "CFG"
and "DIAG".
The patch shows "-" instead of "0" in column "#D" and "#C".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Huajing Li 
Reviewed-by: Ruiyu Ni 

commit 416d48f755518fd1d202b97be2e9944df6e8f0d4
Author: Huajing Li 
Date:   Wed Aug 9 10:54:32 2017 +0800

ShellPkg/drivers: Show Image Name in non-SFO mode

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Huajing Li 
Reviewed-by: Ruiyu Ni 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 52/52] xen: make some console related parameters settable at runtime

On Wed, Aug 09, 2017 at 09:07:06AM +0200, Juergen Gross wrote:
> Support modifying conswitch, console_timestamps, loglvl and
> guest_loglvl at runtime.
> 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen-unstable / Qemu-upstream: QMP server: Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set

2017-08-10 Thread Anthony PERARD

On Thu, Aug 10, 2017 at 03:00:56PM +0100, Anthony PERARD wrote:
> On Wed, Aug 09, 2017 at 06:34:43PM +0200, Sander Eikelenboom wrote:
> > L.S.,
> > 
> > It seems the xen qemu-upstream tree got updated from qemu upstream last 
> > week. 
> > Unfortunately a change breaks pci-passthrough for HVM's:
> > libxl: error: libxl_qmp.c:287:qmp_handle_error_response: Domain 
> > 20:received an error message from QMP server: Unsupported bus. Bus doesn't 
> > have property 'acpi-pcihp-bsel' set
> > libxl: error: libxl_pci.c:1293:libxl__add_pcidevs: Domain 
> > 20:libxl_device_pci_add failed: -3
> > libxl: error: libxl_create.c:1458:domcreate_attach_devices: Domain 
> > 20:unable to add pci devices
> > libxl: error: libxl_domain.c:1003:libxl__destroy_domid: Domain 
> > 20:Non-existant domain
> > libxl: error: libxl_domain.c:962:domain_destroy_callback: Domain 
> > 20:Unable to destroy guest
> > libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain 
> > 20:Destruction of domain failed
> > 
> > The culprit is commit: "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice" 
> > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > I verified that reverting this commit fixes the issue.
> 
> Thanks, I'll look into this.

Can you try with this patch?

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 6b7bade183..8cac3b3de3 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2857,6 +2857,8 @@ void acpi_setup(void)
 AcpiBuildState *build_state;
 Object *vmgenid_dev;
 
+acpi_set_pci_info();
+
 if (!pcms->fw_cfg) {
 ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n");
 return;
@@ -2874,8 +2876,6 @@ void acpi_setup(void)
 
 build_state = g_malloc0(sizeof *build_state);
 
-acpi_set_pci_info();
-
 acpi_build_tables_init();
 acpi_build(, MACHINE(pcms));
 


-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 9/9] vpci/msix: add MSI-X handlers

2017-08-10 Thread Roger Pau Monné

On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote:
> >>> Roger Pau Monne  06/30/17 5:01 PM >>>
> >Note that accesses to the Table Offset, Table BIR, PBA Offset and PBA
> >BIR are not trapped by Xen at the moment.
> 
> They're mandated r/o by the spec anyway.

> 
> >@@ -113,6 +148,35 @@ static int vpci_modify_bar(struct domain *d, const 
> >struct vpci_bar *bar,
> >if ( IS_ERR(mem) )
> >return -PTR_ERR(mem);
>  >
> >+/*
> >+ * Make sure the MSI-X regions of the BAR are not mapped into the domain
> >+ * p2m, or else the MSI-X handlers are useless. Only do this when 
> >mapping,
> >+ * since that's when the memory decoding on the device is enabled.
> >+ */
> >+for ( i = 0; map && i < ARRAY_SIZE(bar->msix); i++ )
> >+{
> >+struct vpci_msix_mem *msix = bar->msix[i];
> >+
> >+if ( !msix || msix->addr == INVALID_PADDR )
> >+continue;
> >+
> >+rc = vpci_unmap_msix(d, msix);
> 
> Why do you need this, instead of being able to simply rely on the rangeset
> based (un)mapping?

This is because the series that I've sent called: "x86/pvh: implement
iommu_inclusive_mapping for PVH Dom0" will map the MSI-X memory areas
into the guest, and thus we need to make sure they are not mapped
here for the emulation path to work.

https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg02849.html

> >@@ -405,7 +475,20 @@ static int vpci_init_bars(struct pci_dev *pdev)
> >continue;
> >}
>  >
> >-bars[i].addr = (cmd & PCI_COMMAND_MEMORY) ? addr : INVALID_PADDR;
> >+if ( cmd & PCI_COMMAND_MEMORY )
> >+{
> >+unsigned int j;
> >+
> >+bars[i].addr = addr;
> >+
> >+for ( j = 0; j < ARRAY_SIZE(bars[i].msix); j++ )
> >+if ( bars[i].msix[j] )
> >+bars[i].msix[j]->addr = bars[i].addr +
> >+bars[i].msix[j]->offset;
> >+}
> >+else
> >+bars[i].addr = INVALID_PADDR;
> 
> As (I think) mentioned elsewhere already, this init-time special case looks
> dangerous (and unnecessary) to me (or else I'd expect you to also zap
> the field when the memory decode bit is being cleared).

OK, so I'm simply going to set this to addr + offset, regardless of
whether the BAR has memory decoding enabled of not. If the BAR is not
yet positioned Dom0 will have to position it anyway before enabling
memory decoding.

> >+for ( i = 0; i < msix->max_entries; i++ )
> >+{
> >+if ( msix->entries[i].masked )
> >+continue;
> 
> Why is the mask bit relevant here, but not the mask-all one?

Not taking the mask-all into account here is wrong, since setting
mask-all from 1 to 0 should force a recalculation of all the entries
address and data fields. I will fix this in the next version.

> >+rc = vpci_msix_arch_enable(>entries[i].arch, pdev,
> >+   msix->entries[i].addr,
> >+   msix->entries[i].data,
> >+   msix->entries[i].nr, table_base);
> >+if ( rc )
> >+{
> >+gdprintk(XENLOG_ERR,
> <+ "%04x:%02x:%02x.%u: unable to update entry %u: 
> %d\n",
> >+ seg, bus, slot, func, i, rc);
> >+return;
> >+}
> >+
> >+vpci_msix_arch_mask(>entries[i].arch, pdev, false);
> 
> Same question here.

This is needed because after a vpci_msix_arch_enable the pirq is still
masked, and hence needs to be unmasked to match the guest's view.

> >+}
> >+}
> >+else if ( msix->enabled && !new_enabled )
> >+{
> >+/* MSI-X disabled. */
> >+for ( i = 0; i < msix->max_entries; i++ )
> >+{
> >+rc = vpci_msix_arch_disable(>entries[i].arch, pdev);
> >+if ( rc )
> >+{
> >+gdprintk(XENLOG_ERR,
> >+ "%04x:%02x:%02x.%u: unable to disable entry %u: 
> >%d\n",
> >+ seg, bus, slot, func, i, rc);
> >+return;
> >+}
> >+}
> >+}
> >+
> >+if ( (new_enabled != msix->enabled || new_masked != msix->masked) &&
> >+ pci_msi_conf_write_intercept(pdev, reg, 2, ) >= 0 )
> >+pci_conf_write16(seg, bus, slot, func, reg, val.u32);
> 
> DYM val.u16 here?

Now this is simply val, since the union has been removed.

> >+static struct vpci_msix *vpci_msix_find(struct domain *d, unsigned long 
> >addr)
> >+{
> >+struct vpci_msix *msix;
> >+
> >+ASSERT(vpci_locked(d));
> >+list_for_each_entry ( msix,  >arch.hvm_domain.msix_tables, next )
> >+{
> >+uint8_t seg = msix->pdev->seg, bus = msix->pdev->bus;
> >+uint8_t slot = PCI_SLOT(msix->pdev->devfn);
> >+uint8_t func = PCI_FUNC(msix->pdev->devfn);
> >+uint16_t cmd = pci_conf_read16(seg, bus, slot,

Re: [Xen-devel] [PATCH 47/52] xen: add basic support for runtime parameter changing

On 10/08/17 18:17, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 09:07:01AM +0200, Juergen Gross wrote:
>> Add the needed infrastructure for runtime parameter changing similar
>> to that used at boot time via cmdline. We are using the same parsing
>> functions as for cmdline parsing, but with a different array of
>> parameter definitions.
>>
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Tim Deegan 
>> Cc: Wei Liu 
>> Signed-off-by: Juergen Gross 
>> ---
>>  xen/arch/x86/xen.lds.S |  4 
>>  xen/common/kernel.c|  5 +
>>  xen/include/xen/init.h | 22 --
>>  xen/include/xen/lib.h  |  1 +
>>  4 files changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
>> index ff08bbe42a..5bd7912759 100644
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -226,6 +226,10 @@ SECTIONS
>> __start_schedulers_array = .;
>> *(.data.schedulers)
>> __end_schedulers_array = .;
>> +   . = ALIGN(POINTER_ALIGN);
>> +   __param_start = .;
>> +   *(.data.param)
>> +   __param_end = .;
> 
> Missing modification to arm/xen/lds.S

Indeed. Thanks for pointing it out.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen




On 10/08/17 17:38, Wei Liu wrote:

On Thu, Aug 10, 2017 at 05:11:52PM +0100, Julien Grall wrote:



On 10/08/17 17:00, Wei Liu wrote:

On Thu, Aug 10, 2017 at 03:26:07PM +0100, Julien Grall wrote:



On 09/08/17 11:58, Bhupinder Thakur wrote:

Hi Julien,


Hi Bhupinder,


Thanks for the testing.

On 8 August 2017 at 21:29, Julien Grall  wrote:

Hi Bhupinder,

I gave another and I have a couple of comments.

Booting Linux with earlycon enabled take quite a while. I can see the
characters coming slower than on the minitel. It seems to be a bit better
after switching off the bootconsole. Overall Linux is taking ~20 times to
boot with pl011 vs HVC console.

I do agree that pl011 is emulated and therefore you have to trap after each
character. But 20 times sounds far too much.


I think this slowness could be due to ratelimiting of the pl011 events
in xenconosle. Currently, the rate limit is
set to 30 events per 200 msecs (see RATE_LIMIT_ALLOWANCE/RATE_LIMIT_PERIOD).

I increased the rate limit to 600 events (30 * 20) per 200 msecs. With
this change,
I see that the the find command is running faster and smoother.
Earlier the find output would be jerky.


I think there might be another solution avoiding increasing the rate limit.

If you look at the earlycon code for pl011 in Linux:

static void pl011_putc(struct uart_port *port, int c)
{
while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
cpu_relax();
if (port->iotype == UPIO_MEM32)
writel(c, port->membase + UART01x_DR);
else
writeb(c, port->membase + UART01x_DR);
while (readl(port->membase + UART01x_FR) & UART01x_FR_BUSY)
cpu_relax();
}

Linux will wait the UART to be idle before sending a new character.

Now looking at vpl011 emulation, the busy bit set when a new character is
queued (see vpl011_write_data). This bit will only be cleared when the
console daemon will raise an event and the queue is empty (see
vpl011_data_avail).

This means for earlycon, you will need a round trip Guest -> Xen -> Dom0 ->
Xen -> Guest for each single character. This is a bit counterproductive and
combined with the limit it makes it worse.

I would take a different approach on the BUSY bit. We can consider the queue
between Xen and xenconsoled as outside of the UART. If the character is
queued, then job done. I think this would improve quite a lot of the
performance.


Yes. This.

The guest sees a register, which is essentially a synchronous interface
to the guest. The current code, as you already see, will issue one event
for every character. That's excessive.


I am actually not suggesting to modify that at the moment. I think you may
have other trouble with the interaction between the user and th console by
doing that. Imagine you want to print the prompt, it may lag a bit before
getting it.

The only thing I suggest is to not set the BUSY bit in the UART everytime a
character is queued.



Did you come to that conclusion that this would work by looking at the
spec or Linux source code? I think it should conform to the spec, not a
specific guest. But you're the maintainer, you have the final say.


I read both the spec and the code. From the spec:

"UART busy. If this bit is set to 1, the UART is busy transmitting data. 
This bit remains set until the
complete byte, including all the stop bits, has been sent from the shift 
register.
This bit is set as soon as the transmit FIFO becomes non-empty, 
regardless of whether the UART is

enabled or not."

Currently, we considered that the shared ring is the FIFO of the UART. 
Meaning that the BUSY bit is set until xenconsoled read everything.


I don't think implementing a FIFO is highly critical in an emulation 
(QEMU does not implement it for instance). And definitely using the 
shared ring brings slow down (involve multiple context switch).


I would suggest to take a different approach where the BUSY is only set 
if we can't add more data in the shared ring. This would be clear as 
soon as the ring has space.


If we really we could implement is small FIFO (the SBSA requested a 
least 32-entry separate for transmit and receive). But I don't think 
this is critically for a first approach.






The interface between Xen and xenconsoled can be asynchronous, it can
opt to queue X characters before sending an event, also setup a oneshot
timer to avoid hanging.

This however has some other implications -- it might not be as reliable
as the original method because data is not guaranteed to hit backend. If
the guest crashes very early on, depending the actual implementation you
might not be able get the data.


Would it be possible to ask xenconsoled to dump everything on domain crash?
Some kind of synchronization.



No, not at the moment. If the data is still in Xen and destroyed,
xenconsoled can't do anything.


The vUART emulation is directly queuing the data, there are no 
intermediate buffer. So all

[Xen-devel] [xtf test] 112552: all pass - PUSHED

flight 112552 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112552/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  11ae3010a30c89a6aef762dd03727a5b49e9d8d8
baseline version:
 xtf  0e04400b8575048ed0b10e4ac571c63e0769dfac

Last test of basis   112538  2017-08-09 15:47:18 Z1 days
Testing same since   112552  2017-08-10 12:27:05 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xtf
+ revision=11ae3010a30c89a6aef762dd03727a5b49e9d8d8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xtf 
11ae3010a30c89a6aef762dd03727a5b49e9d8d8
+ branch=xtf
+ revision=11ae3010a30c89a6aef762dd03727a5b49e9d8d8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x11ae3010a30c89a6aef762dd03727a5b49e9d8d8 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-4.9
++ : tested/linux-arm-xen
++ '['

Re: [Xen-devel] [PATCH 47/52] xen: add basic support for runtime parameter changing

On Wed, Aug 09, 2017 at 09:07:01AM +0200, Juergen Gross wrote:
> Add the needed infrastructure for runtime parameter changing similar
> to that used at boot time via cmdline. We are using the same parsing
> functions as for cmdline parsing, but with a different array of
> parameter definitions.
> 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 
> ---
>  xen/arch/x86/xen.lds.S |  4 
>  xen/common/kernel.c|  5 +
>  xen/include/xen/init.h | 22 --
>  xen/include/xen/lib.h  |  1 +
>  4 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index ff08bbe42a..5bd7912759 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -226,6 +226,10 @@ SECTIONS
> __start_schedulers_array = .;
> *(.data.schedulers)
> __end_schedulers_array = .;
> +   . = ALIGN(POINTER_ALIGN);
> +   __param_start = .;
> +   *(.data.param)
> +   __param_end = .;

Missing modification to arm/xen/lds.S

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] paravirt,xen: remove xen_patch()

2017-08-10 Thread Josh Poimboeuf

On Thu, Aug 10, 2017 at 02:52:52PM +0200, Juergen Gross wrote:
> Xen's paravirt patch function xen_patch() does some special casing for
> irq_ops functions to apply relocations when those functions can be
> patched inline instead of calls.
> 
> Unfortunately none of the special case function replacements is small
> enough to be patches inline, so the special case never applies.
> 
> As xen_patch() will call paravirt_patch_default() in all cases it can
> be just dropped.
> 
> Signed-off-by: Juergen Gross 

Can the ENDPATCH and RELOC macros can also be removed, along with their
usages in xen-asm.S and xen-asm_64.S?

-- 
Josh

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 51/52] xl: add new xl command set-parameters

On Wed, Aug 09, 2017 at 09:07:05AM +0200, Juergen Gross wrote:
> Add a new xl command "set-parameters" to set hypervisor parameters at
> runtime similar to boot time parameters via command line.
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] paravirt,xen: remove xen_patch()

2017-08-10 Thread Peter Zijlstra

On Thu, Aug 10, 2017 at 06:24:53PM +0200, Peter Zijlstra wrote:
> -ENTRY(xen_irq_enable_direct)
> - FRAME_BEGIN
> - /* Unmask events */
> - movb $0, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_mask
> -
> - /*
> -  * Preempt here doesn't matter because that will deal with any
> -  * pending interrupts.  The pending check may end up being run
> -  * on the wrong CPU, but that doesn't hurt.
> -  */
> -
> - /* Test for pending */
> - testb $0xff, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
> - jz 1f
> -
> -2:   call check_events
> -1:
> -ENDPATCH(xen_irq_enable_direct)
> - FRAME_END
> - ret
> - ENDPROC(xen_irq_enable_direct)
> - RELOC(xen_irq_enable_direct, 2b+1)

Oh my bad, part of that is still used.

arch/x86/xen/enlighten_pv.c:pv_irq_ops.irq_enable = 
__PV_IS_CALLEE_SAVE(xen_irq_enable_direct);

It just needs cleanups for the ENDPATCH and such.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 50/52] libxl: add libxl_set_parameters() function

On Wed, Aug 09, 2017 at 09:07:04AM +0200, Juergen Gross wrote:
> Add a new libxl function to set hypervisor parameters at runtime
> similar to boot time parameters via command line.
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 
> ---
>  tools/libxl/libxl.c | 14 ++
>  tools/libxl/libxl.h | 11 +++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 0ef874406f..f370e445de 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -652,6 +652,20 @@ int libxl_send_debug_keys(libxl_ctx *ctx, char *keys)
>  return 0;
>  }
>  
> +int libxl_set_parameters(libxl_ctx *ctx, char *params)
> +{
> +int ret;
> +GC_INIT(ctx);
> +ret = xc_set_parameters(ctx->xch, params);
> +if ( ret < 0 ) {

Extraneous spaces.

> +LOGE(ERROR, "setting parameters");
> +GC_FREE;
> +return ERROR_FAIL;
> +}
> +GC_FREE;
> +return 0;
> +}
> +
>  static int fd_set_flags(libxl_ctx *ctx, int fd,
>  int fcntlgetop, int fcntlsetop, const char *fl,
>  int flagmask, int set_p)
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 229e289750..e8262501c2 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1051,6 +1051,13 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
> const libxl_mac *src);
>   */
>  #define LIBXL_HAVE_QED 1
>  
> +/*
> + * LIBXL_HAVE_SET_PARAMETERS
> + *
> + * If this is defined setting hypervisor parameters is supported.
> + */
> +#define LIBXL_HAVE_SET_PARAMETERS 1
> +
>  typedef char **libxl_string_list;
>  void libxl_string_list_dispose(libxl_string_list *sl);
>  int libxl_string_list_length(const libxl_string_list *sl);
> @@ -2106,6 +2113,10 @@ int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
>  int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
>  int libxl_send_debug_keys(libxl_ctx *ctx, char *keys);
>  
> +#ifdef LIBXL_HAVE_SET_PARAMETERS
> +int libxl_set_parameters(libxl_ctx *ctx, char *params);
> +#endif
> +

No need to have this enclosed in macro.

>  typedef struct libxl__xen_console_reader libxl_xen_console_reader;
>  
>  libxl_xen_console_reader *
> -- 
> 2.12.3
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] xen: remove struct domain and vcpu declarations from types.h

They don't belong there. Removing them causes build errors in several
places. Add the forward declarations in those places.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Julien Grall 
---
 xen/include/asm-arm/processor.h | 1 +
 xen/include/asm-x86/xenoprof.h  | 2 ++
 xen/include/xen/compat.h| 1 +
 xen/include/xen/types.h | 3 ---
 4 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 855ded1b07..ab5225fa6c 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -699,6 +699,7 @@ void show_registers(struct cpu_user_regs *regs);
 
 void noreturn do_unexpected_trap(const char *msg, struct cpu_user_regs *regs);
 
+struct vcpu;
 void vcpu_regs_hyp_to_user(const struct vcpu *vcpu,
struct vcpu_guest_core_regs *regs);
 void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
diff --git a/xen/include/asm-x86/xenoprof.h b/xen/include/asm-x86/xenoprof.h
index 3a1b001edb..1d2464804a 100644
--- a/xen/include/asm-x86/xenoprof.h
+++ b/xen/include/asm-x86/xenoprof.h
@@ -68,6 +68,8 @@ void passive_domain_destroy(struct vcpu *v);
 
 #else
 
+struct vcpu;
+
 static inline int passive_domain_do_rdmsr(unsigned int msr,
   uint64_t *msr_content)
 {
diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h
index ce6245c10f..895e2ff68d 100644
--- a/xen/include/xen/compat.h
+++ b/xen/include/xen/compat.h
@@ -227,6 +227,7 @@ void xlat_start_info(struct start_info *, enum 
XLAT_start_info_console);
 struct vcpu_runstate_info;
 void xlat_vcpu_runstate_info(struct vcpu_runstate_info *);
 
+struct domain;
 int switch_compat(struct domain *);
 
 #else
diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h
index 170e993558..b1dbb8720a 100644
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -42,9 +42,6 @@ typedef __s32   int32_t;
 typedef __u64   uint64_t;
 typedef __s64   int64_t;
 
-struct domain;
-struct vcpu;
-
 typedef __u16 __le16;
 typedef __u16 __be16;
 typedef __u32 __le32;
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 07/23] x86: relocate_kernel - Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/relocate_kernel_64.S | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/relocate_kernel_64.S 
b/arch/x86/kernel/relocate_kernel_64.S
index 307d3bac5f04..2ecbdcbe985b 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -200,9 +200,11 @@ identity_mapped:
movq%rax, %cr3
lea PAGE_SIZE(%r8), %rsp
callswap_pages
-   movq$virtual_mapped, %rax
-   pushq   %rax
-   ret
+   jmp *virtual_mapped_addr(%rip)
+
+   /* Absolute value for PIE support */
+virtual_mapped_addr:
+   .quad virtual_mapped
 
 virtual_mapped:
movqRSP(%r8), %rsp
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 12/23] x86/boot/64: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Early at boot, the kernel is mapped at a temporary address while preparing
the page table. To know the changes needed for the page table with KASLR,
the boot code calculate the difference between the expected address of the
kernel and the one chosen by KASLR. It does not work with PIE because all
symbols in code are relatives. Instead of getting the future relocated
virtual address, you will get the current temporary mapping. The solution
is using global variables that will be relocated as expected.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/head_64.S | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 513cbb012ecc..09579e0714ce 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -85,8 +85,23 @@ startup_64:
popq%rsi
 
/* Form the CR3 value being sure to include the CR3 modifier */
-   addq$(early_top_pgt - __START_KERNEL_map), %rax
+   addq_early_top_pgt_offset(%rip), %rax
jmp 1f
+
+   /*
+* Position Independent Code takes only relative references in code
+* meaning a global variable address is relative to RIP and not its
+* future virtual address. Global variables can be used instead as they
+* are still relocated on the expected kernel mapping address.
+*/
+   .align 8
+_early_top_pgt_offset:
+   .quad early_top_pgt - __START_KERNEL_map
+_init_top_offset:
+   .quad init_top_pgt - __START_KERNEL_map
+_va_jump:
+   .quad 2f
+
 ENTRY(secondary_startup_64)
/*
 * At this point the CPU runs in 64bit mode CS.L = 1 CS.D = 0,
@@ -114,7 +129,7 @@ ENTRY(secondary_startup_64)
popq%rsi
 
/* Form the CR3 value being sure to include the CR3 modifier */
-   addq$(init_top_pgt - __START_KERNEL_map), %rax
+   addq_init_top_offset(%rip), %rax
 1:
 
/* Enable PAE mode, PGE and LA57 */
@@ -129,9 +144,8 @@ ENTRY(secondary_startup_64)
movq%rax, %cr3
 
/* Ensure I am executing from virtual addresses */
-   movq$1f, %rax
-   jmp *%rax
-1:
+   jmp *_va_jump(%rip)
+2:
 
/* Check if nx is implemented */
movl$0x8001, %eax
@@ -227,11 +241,12 @@ ENTRY(secondary_startup_64)
 *  REX.W + FF /5 JMP m16:64 Jump far, absolute indirect,
 *  address given in m16:64.
 */
-   pushq   $.Lafter_lret   # put return address on stack for unwinder
+   leaq.Lafter_lret(%rip), %rax
+   pushq   %rax# put return address on stack for unwinder
xorq%rbp, %rbp  # clear frame pointer
-   movqinitial_code(%rip), %rax
+   leaqinitial_code(%rip), %rax
pushq   $__KERNEL_CS# set correct cs
-   pushq   %rax# target address in negative space
+   pushq   (%rax)  # target address in negative space
lretq
 .Lafter_lret:
 ENDPROC(secondary_startup_64)
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 04/23] x86: Add macro to get symbol address for PIE support

Add a new _ASM_GET_PTR macro to fetch a symbol address. It will be used
to replace "_ASM_MOV $, %dst" code construct that are not compatible
with PIE.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/asm.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 7a9df3beb89b..bf2842cfb583 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -55,6 +55,19 @@
 # define CC_OUT(c) [_cc_ ## c] "=qm"
 #endif
 
+/* Macros to get a global variable address with PIE support on 64-bit */
+#ifdef CONFIG_X86_32
+#define __ASM_GET_PTR_PRE(_src) __ASM_FORM_COMMA(movl $##_src)
+#else
+#ifdef __ASSEMBLY__
+#define __ASM_GET_PTR_PRE(_src) __ASM_FORM_COMMA(leaq (_src)(%rip))
+#else
+#define __ASM_GET_PTR_PRE(_src) __ASM_FORM_COMMA(leaq (_src)(%%rip))
+#endif
+#endif
+#define _ASM_GET_PTR(_src, _dst) \
+   __ASM_GET_PTR_PRE(_src) __ASM_FORM(_dst)
+
 /* Exception table entry */
 #ifdef __ASSEMBLY__
 # define _ASM_EXTABLE_HANDLE(from, to, handler)\
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 23/23] x86/kaslr: Add option to extend KASLR range from 1GB to 3GB

Add a new CONFIG_RANDOMIZE_BASE_LARGE option to benefit from PIE
support. It increases the KASLR range from 1GB to 3GB. The new range
stars at 0x just above the EFI memory region. This
option is off by default.

The boot code is adapted to create the appropriate page table spanning
three PUD pages.

The relocation table uses 64-bit integers generated with the updated
relocation tool with the large-reloc option.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Kconfig | 21 +
 arch/x86/boot/compressed/Makefile|  5 +
 arch/x86/boot/compressed/misc.c  | 10 +-
 arch/x86/include/asm/page_64_types.h |  9 +
 arch/x86/kernel/head64.c | 18 ++
 arch/x86/kernel/head_64.S| 11 ++-
 6 files changed, 68 insertions(+), 6 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2b69be667543..f3027000ec60 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2149,6 +2149,27 @@ config X86_MODULE_PLTS
select X86_MODULE_MODEL_LARGE
select HAVE_MOD_ARCH_SPECIFIC
 
+config RANDOMIZE_BASE_LARGE
+   bool "Increase the randomization range of the kernel image"
+   depends on X86_64 && RANDOMIZE_BASE
+   select X86_PIE
+   select X86_MODULE_PLTS if MODULES
+   default n
+   ---help---
+ Build the kernel as a Position Independent Executable (PIE) and
+ increase the available randomization range from 1GB to 3GB.
+
+ This option impacts performance on kernel CPU intensive workloads up
+ to 10% due to PIE generated code. Impact on user-mode processes and
+ typical usage would be significantly less (0.50% when you build the
+ kernel).
+
+ The kernel and modules will generate slightly more assembly (1 to 2%
+ increase on the .text sections). The vmlinux binary will be
+ significantly smaller due to less relocations.
+
+ If unsure say N
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 8a958274b54c..94dfee5a7cd2 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -112,7 +112,12 @@ $(obj)/vmlinux.bin: vmlinux FORCE
 
 targets += $(patsubst $(obj)/%,%,$(vmlinux-objs-y)) vmlinux.bin.all 
vmlinux.relocs
 
+# Large randomization require bigger relocation table
+ifeq ($(CONFIG_RANDOMIZE_BASE_LARGE),y)
+CMD_RELOCS = arch/x86/tools/relocs --large-reloc
+else
 CMD_RELOCS = arch/x86/tools/relocs
+endif
 quiet_cmd_relocs = RELOCS  $@
   cmd_relocs = $(CMD_RELOCS) $< > $@;$(CMD_RELOCS) --abs-relocs $<
 $(obj)/vmlinux.relocs: vmlinux FORCE
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index c20cdc7cbd61..82a0ea17c9dc 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -170,10 +170,18 @@ void __puthex(unsigned long value)
 }
 
 #if CONFIG_X86_NEED_RELOCS
+
+/* Large randomization go lower than -2G and use large relocation table */
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+typedef long rel_t;
+#else
+typedef int rel_t;
+#endif
+
 static void handle_relocations(void *output, unsigned long output_len,
   unsigned long virt_addr)
 {
-   int *reloc;
+   rel_t *reloc;
unsigned long delta, map, ptr;
unsigned long min_addr = (unsigned long)output;
unsigned long max_addr = min_addr + (VO___bss_start - VO__text);
diff --git a/arch/x86/include/asm/page_64_types.h 
b/arch/x86/include/asm/page_64_types.h
index 3f5f08b010d0..6b65f846dd64 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -48,7 +48,11 @@
 #define __PAGE_OFFSET   __PAGE_OFFSET_BASE
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define __START_KERNEL_map _AC(0x, UL)
+#else
 #define __START_KERNEL_map _AC(0x8000, UL)
+#endif /* CONFIG_RANDOMIZE_BASE_LARGE */
 
 /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
 #ifdef CONFIG_X86_5LEVEL
@@ -65,9 +69,14 @@
  * 512MiB by default, leaving 1.5GiB for modules once the page tables
  * are fully set up. If kernel ASLR is configured, it can extend the
  * kernel page table mapping, reducing the size of the modules area.
+ * On PIE, we relocate the binary 2G lower so add this extra space.
  */
 #if defined(CONFIG_RANDOMIZE_BASE)
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define KERNEL_IMAGE_SIZE  (_AC(3, UL) * 1024 * 1024 * 1024)
+#else
 #define KERNEL_IMAGE_SIZE  (1024 * 1024 * 1024)
+#endif
 #else
 #define KERNEL_IMAGE_SIZE  (512 * 1024 * 1024)
 #endif
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index e71f27a20576..7e817e804e89 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -39,6 +39,7 @@ static

[Xen-devel] [RFC v2 15/23] x86/boot/64: Use _text in a global for PIE support

By default PIE generated code create only relative references so _text
points to the temporary virtual address. Instead use a global variable
so the relocation is done as expected.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/head64.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 925b2928f377..e71f27a20576 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -45,8 +45,14 @@ static void __head *fixup_pointer(void *ptr, unsigned long 
physaddr)
return ptr - (void *)_text + (void *)physaddr;
 }
 
-unsigned long __head __startup_64(unsigned long physaddr,
- struct boot_params *bp)
+/*
+ * Use a global variable to properly calculate _text delta on PIE. By default
+ * a PIE binary do a RIP relative difference instead of the relocated address.
+ */
+unsigned long _text_offset = (unsigned long)(_text - __START_KERNEL_map);
+
+unsigned long __head notrace __startup_64(unsigned long physaddr,
+ struct boot_params *bp)
 {
unsigned long load_delta, *p;
unsigned long pgtable_flags;
@@ -64,7 +70,7 @@ unsigned long __head __startup_64(unsigned long physaddr,
 * Compute the delta between the address I am compiled to run at
 * and the address I am actually running at.
 */
-   load_delta = physaddr - (unsigned long)(_text - __START_KERNEL_map);
+   load_delta = physaddr - _text_offset;
 
/* Is the address not 2M aligned? */
if (load_delta & ~PMD_PAGE_MASK)
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 18/23] x86/relocs: Handle DYN relocations for PIE support

Change the relocation tool to correctly handle DYN/PIE kernel where
the relocation table does not reference symbols and percpu support is
not needed. Also add support for R_X86_64_RELATIVE relocations that can
be handled like a 64-bit relocation due to the usage of -Bsymbolic.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c | 74 +++--
 1 file changed, 65 insertions(+), 9 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 73eb7fd4aec4..70f523dd68ff 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -642,6 +642,13 @@ static void add_reloc(struct relocs *r, uint32_t offset)
r->offset[r->count++] = offset;
 }
 
+/* Relocation found in a DYN binary, support only for 64-bit PIE */
+static int is_dyn_reloc(struct section *sec)
+{
+   return ELF_BITS == 64 && ehdr.e_type == ET_DYN &&
+   sec->shdr.sh_info == SHT_NULL;
+}
+
 static void walk_relocs(int (*process)(struct section *sec, Elf_Rel *rel,
Elf_Sym *sym, const char *symname))
 {
@@ -652,6 +659,7 @@ static void walk_relocs(int (*process)(struct section *sec, 
Elf_Rel *rel,
Elf_Sym *sh_symtab;
struct section *sec_applies, *sec_symtab;
int j;
+   int dyn_reloc = 0;
struct section *sec = [i];
 
if (sec->shdr.sh_type != SHT_REL_TYPE) {
@@ -660,14 +668,20 @@ static void walk_relocs(int (*process)(struct section 
*sec, Elf_Rel *rel,
sec_symtab  = sec->link;
sec_applies = [sec->shdr.sh_info];
if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) {
-   continue;
+   if (!is_dyn_reloc(sec_applies))
+   continue;
+   dyn_reloc = 1;
}
sh_symtab = sec_symtab->symtab;
sym_strtab = sec_symtab->link->strtab;
for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) {
Elf_Rel *rel = >reltab[j];
-   Elf_Sym *sym = _symtab[ELF_R_SYM(rel->r_info)];
-   const char *symname = sym_name(sym_strtab, sym);
+   Elf_Sym *sym = NULL;
+   const char *symname = NULL;
+   if (!dyn_reloc) {
+   sym = _symtab[ELF_R_SYM(rel->r_info)];
+   symname = sym_name(sym_strtab, sym);
+   }
 
process(sec, rel, sym, symname);
}
@@ -746,16 +760,21 @@ static int is_percpu_sym(ElfW(Sym) *sym, const char 
*symname)
strncmp(symname, "init_per_cpu_", 13);
 }
 
-
 static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
  const char *symname)
 {
unsigned r_type = ELF64_R_TYPE(rel->r_info);
ElfW(Addr) offset = rel->r_offset;
-   int shn_abs = (sym->st_shndx == SHN_ABS) && !is_reloc(S_REL, symname);
+   int shn_abs = 0;
+   int dyn_reloc = is_dyn_reloc(sec);
 
-   if (sym->st_shndx == SHN_UNDEF)
-   return 0;
+   if (!dyn_reloc) {
+   shn_abs = (sym->st_shndx == SHN_ABS) &&
+   !is_reloc(S_REL, symname);
+
+   if (sym->st_shndx == SHN_UNDEF)
+   return 0;
+   }
 
/*
 * Adjust the offset if this reloc applies to the percpu section.
@@ -769,6 +788,9 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
break;
 
case R_X86_64_PC32:
+   if (dyn_reloc)
+   die("PC32 reloc in PIE DYN binary");
+
/*
 * PC relative relocations don't need to be adjusted unless
 * referencing a percpu symbol.
@@ -783,7 +805,7 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
/*
 * References to the percpu area don't need to be adjusted.
 */
-   if (is_percpu_sym(sym, symname))
+   if (!dyn_reloc && is_percpu_sym(sym, symname))
break;
 
if (shn_abs) {
@@ -814,6 +836,14 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
add_reloc(, offset);
break;
 
+   case R_X86_64_RELATIVE:
+   /*
+* -Bsymbolic means we don't need the addend and we can reuse
+* the original relocs64.
+*/
+   add_reloc(, offset);
+   break;
+
default:
die("Unsupported relocation type: %s (%d)\n",
rel_type(r_type), r_type);

[Xen-devel] [RFC v2 20/23] x86/pie: Add option to build the kernel as PIE for x86_64

Add the CONFIG_X86_PIE option which builds the kernel as a Position
Independent Executable (PIE). The kernel is currently build with the
mcmodel=kernel option which forces it to stay on the top 2G of the
virtual address space. With PIE, the kernel will be able to move below
the -2G limit increasing the KASLR range from 1GB to 3GB.

The modules do not support PIE due to how they are linked. Disable PIE
for them and default to mcmodel=kernel for now.

The PIE configuration is not yet compatible with XEN_PVH. Xen PVH
generates 32-bit assembly and uses a long jump to transition to 64-bit.
A long jump require an absolute reference that is not compatible with
PIE.

Performance/Size impact:

Hackbench (50% and 1600% loads):
 - PIE disabled: no significant change (-0.50% / +0.50%)
 - PIE enabled: 7% to 8% on half load, 10% on heavy load.

These results are aligned with the different research on user-mode PIE
impact on cpu intensive benchmarks (around 10% on x86_64).

slab_test (average of 10 runs):
 - PIE disabled: no significant change (-1% / +1%)
 - PIE enabled: 3% to 4%

Kernbench (average of 10 Half and Optimal runs):
 Elapsed Time:
 - PIE disabled: no significant change (-0.22% / +0.06%)
 - PIE enabled: around 0.50%
 System Time:
 - PIE disabled: no significant change (-0.99% / -1.28%)
 - PIE enabled: 5% to 6%

Size of vmlinux (Ubuntu configuration):
 File size:
 - PIE disabled: 472928672 bytes (-0.000169% from baseline)
 - PIE enabled: 216878461 bytes (-54.14% from baseline)
 .text sections:
 - PIE disabled: 9373572 bytes (+0.04% from baseline)
 - PIE enabled: 9499138 bytes (+1.38% from baseline)

The big decrease in vmlinux file size is due to the lower number of
relocations appended to the file.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Kconfig  | 7 +++
 arch/x86/Makefile | 9 +
 2 files changed, 16 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2632fa8e8945..a419f4110872 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2132,6 +2132,13 @@ config X86_GLOBAL_STACKPROTECTOR
bool
depends on CC_STACKPROTECTOR
 
+config X86_PIE
+   bool
+   depends on X86_64 && !XEN_PVH
+   select DEFAULT_HIDDEN
+   select MODULE_REL_CRCS if MODVERSIONS
+   select X86_GLOBAL_STACKPROTECTOR if CC_STACKPROTECTOR
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 66af2704f096..05e01588b5af 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -45,8 +45,12 @@ export REALMODE_CFLAGS
 export BITS
 
 ifdef CONFIG_X86_NEED_RELOCS
+ifdef CONFIG_X86_PIE
+LDFLAGS_vmlinux := -pie -shared -Bsymbolic
+else
 LDFLAGS_vmlinux := --emit-relocs
 endif
+endif
 
 #
 # Prevent GCC from generating any FP code by mistake.
@@ -141,7 +145,12 @@ else
 KBUILD_CFLAGS += $(cflags-y)
 
 KBUILD_CFLAGS += -mno-red-zone
+ifdef CONFIG_X86_PIE
+KBUILD_CFLAGS += -fPIC
+KBUILD_CFLAGS_MODULE += -fno-PIC -mcmodel=kernel
+else
 KBUILD_CFLAGS += -mcmodel=kernel
+endif
 
 # -funit-at-a-time shrinks the kernel .text considerably
 # unfortunately it makes reading oopses harder.
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen-unstable / Qemu-upstream: QMP server: Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set

2017-08-10 Thread Sander Eikelenboom

On 10/08/17 18:45, Anthony PERARD wrote:
> On Thu, Aug 10, 2017 at 03:00:56PM +0100, Anthony PERARD wrote:
>> On Wed, Aug 09, 2017 at 06:34:43PM +0200, Sander Eikelenboom wrote:
>>> L.S.,
>>>
>>> It seems the xen qemu-upstream tree got updated from qemu upstream last 
>>> week. 
>>> Unfortunately a change breaks pci-passthrough for HVM's:
>>> libxl: error: libxl_qmp.c:287:qmp_handle_error_response: Domain 
>>> 20:received an error message from QMP server: Unsupported bus. Bus doesn't 
>>> have property 'acpi-pcihp-bsel' set
>>> libxl: error: libxl_pci.c:1293:libxl__add_pcidevs: Domain 
>>> 20:libxl_device_pci_add failed: -3
>>> libxl: error: libxl_create.c:1458:domcreate_attach_devices: Domain 
>>> 20:unable to add pci devices
>>> libxl: error: libxl_domain.c:1003:libxl__destroy_domid: Domain 
>>> 20:Non-existant domain
>>> libxl: error: libxl_domain.c:962:domain_destroy_callback: Domain 
>>> 20:Unable to destroy guest
>>> libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain 
>>> 20:Destruction of domain failed
>>>
>>> The culprit is commit: "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice" 
>>> (f0c9d64a68b776374ec4732424a3e27753ce37b6).
>>> I verified that reverting this commit fixes the issue.
>>
>> Thanks, I'll look into this.
> 
> Can you try with this patch?

Hi Anthony,

Just tested the patch and it works for me, thanks!

--
Sander


> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 6b7bade183..8cac3b3de3 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2857,6 +2857,8 @@ void acpi_setup(void)
>  AcpiBuildState *build_state;
>  Object *vmgenid_dev;
>  
> +acpi_set_pci_info();
> +
>  if (!pcms->fw_cfg) {
>  ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n");
>  return;
> @@ -2874,8 +2876,6 @@ void acpi_setup(void)
>  
>  build_state = g_malloc0(sizeof *build_state);
>  
> -acpi_set_pci_info();
> -
>  acpi_build_tables_init();
>  acpi_build(, MACHINE(pcms));
>  
> 
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] paravirt,xen: remove xen_patch()

2017-08-10 Thread Peter Zijlstra

On Thu, Aug 10, 2017 at 02:52:52PM +0200, Juergen Gross wrote:
> Xen's paravirt patch function xen_patch() does some special casing for
> irq_ops functions to apply relocations when those functions can be
> patched inline instead of calls.
> 
> Unfortunately none of the special case function replacements is small
> enough to be patches inline, so the special case never applies.
> 
> As xen_patch() will call paravirt_patch_default() in all cases it can
> be just dropped.
> 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/xen/enlighten_pv.c | 59 
> +
>  1 file changed, 1 insertion(+), 58 deletions(-)

> - SITE(pv_irq_ops, irq_enable);
> - SITE(pv_irq_ops, irq_disable);
> - SITE(pv_irq_ops, save_fl);
> - SITE(pv_irq_ops, restore_fl);

You forgot to remove the actual ASM that's then never used either.


 arch/x86/xen/Makefile  |   2 +-
 arch/x86/xen/xen-asm.S | 150 -
 arch/x86/xen/xen-ops.h |  12 
 3 files changed, 1 insertion(+), 163 deletions(-)

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index bced7a369a11..551e12ba2a7b 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -14,7 +14,7 @@ CFLAGS_enlighten_pv.o := $(nostackp)
 CFLAGS_mmu_pv.o:= $(nostackp)
 
 obj-y  := enlighten.o multicalls.o mmu.o irq.o \
-   time.o xen-asm.o xen-asm_$(BITS).o \
+   time.o xen-asm_$(BITS).o \
grant-table.o suspend.o platform-pci-unplug.o
 
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
deleted file mode 100644
index eff224df813f..
--- a/arch/x86/xen/xen-asm.S
+++ /dev/null
@@ -1,150 +0,0 @@
-/*
- * Asm versions of Xen pv-ops, suitable for either direct use or
- * inlining.  The inline versions are the same as the direct-use
- * versions, with the pre- and post-amble chopped off.
- *
- * This code is encoded for size rather than absolute efficiency, with
- * a view to being able to inline as much as possible.
- *
- * We only bother with direct forms (ie, vcpu in percpu data) of the
- * operations here; the indirect forms are better handled in C, since
- * they're generally too large to inline anyway.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include "xen-asm.h"
-
-/*
- * Enable events.  This clears the event mask and tests the pending
- * event status with one and operation.  If there are pending events,
- * then enter the hypervisor to get them handled.
- */
-ENTRY(xen_irq_enable_direct)
-   FRAME_BEGIN
-   /* Unmask events */
-   movb $0, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_mask
-
-   /*
-* Preempt here doesn't matter because that will deal with any
-* pending interrupts.  The pending check may end up being run
-* on the wrong CPU, but that doesn't hurt.
-*/
-
-   /* Test for pending */
-   testb $0xff, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
-   jz 1f
-
-2: call check_events
-1:
-ENDPATCH(xen_irq_enable_direct)
-   FRAME_END
-   ret
-   ENDPROC(xen_irq_enable_direct)
-   RELOC(xen_irq_enable_direct, 2b+1)
-
-
-/*
- * Disabling events is simply a matter of making the event mask
- * non-zero.
- */
-ENTRY(xen_irq_disable_direct)
-   movb $1, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_mask
-ENDPATCH(xen_irq_disable_direct)
-   ret
-   ENDPROC(xen_irq_disable_direct)
-   RELOC(xen_irq_disable_direct, 0)
-
-/*
- * (xen_)save_fl is used to get the current interrupt enable status.
- * Callers expect the status to be in X86_EFLAGS_IF, and other bits
- * may be set in the return value.  We take advantage of this by
- * making sure that X86_EFLAGS_IF has the right value (and other bits
- * in that byte are 0), but other bits in the return value are
- * undefined.  We need to toggle the state of the bit, because Xen and
- * x86 use opposite senses (mask vs enable).
- */
-ENTRY(xen_save_fl_direct)
-   testb $0xff, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_mask
-   setz %ah
-   addb %ah, %ah
-ENDPATCH(xen_save_fl_direct)
-   ret
-   ENDPROC(xen_save_fl_direct)
-   RELOC(xen_save_fl_direct, 0)
-
-
-/*
- * In principle the caller should be passing us a value return from
- * xen_save_fl_direct, but for robustness sake we test only the
- * X86_EFLAGS_IF flag rather than the whole byte. After setting the
- * interrupt mask state, it checks for unmasked pending events and
- * enters the hypervisor to get them delivered if so.
- */
-ENTRY(xen_restore_fl_direct)
-   FRAME_BEGIN
-#ifdef CONFIG_X86_64
-   testw $X86_EFLAGS_IF, %di
-#else
-   testb $X86_EFLAGS_IF>>8, %ah
-#endif
-   setz PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_mask
-   /*
-* Preempt here doesn't matter because

Re: [Xen-devel] [RFC PATCH v2 03/22] ARM: vGIC: move gic_raise_inflight_irq() into vgic_vcpu_inject_irq()


Hi Andre,

On 21/07/17 20:59, Andre Przywara wrote:

Currently there is a gic_raise_inflight_irq(), which serves the very
special purpose of handling a newly injected interrupt while an older
one is still handled. This has only one user, in vgic_vcpu_inject_irq().

Now with the introduction of the pending_irq lock this will later on
result in a nasty deadlock, which can only be solved properly by
actually embedding the function into the caller (and dropping the lock
later in-between).

This has the admittedly hideous consequence of needing to export
gic_update_one_lr(), but this will go away in a later stage of a rework.
In this respect this patch is more a temporary kludge.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c| 30 +-
 xen/arch/arm/vgic.c   | 11 ++-
 xen/include/asm-arm/gic.h |  2 +-
 3 files changed, 12 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 2c99d71..5bd66a2 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -44,8 +44,6 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);

 #undef GIC_DEBUG

-static void gic_update_one_lr(struct vcpu *v, int i);
-
 static const struct gic_hw_operations *gic_hw_ops;

 void register_gic_ops(const struct gic_hw_operations *ops)
@@ -416,32 +414,6 @@ void gic_remove_irq_from_queues(struct vcpu *v, struct 
pending_irq *p)
 gic_remove_from_lr_pending(v, p);
 }

-void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
-{
-struct pending_irq *n = irq_to_pending(v, virtual_irq);
-
-/* If an LPI has been removed meanwhile, there is nothing left to raise. */
-if ( unlikely(!n) )
-return;
-
-ASSERT(spin_is_locked(>arch.vgic.lock));
-
-/* Don't try to update the LR if the interrupt is disabled */
-if ( !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
-return;
-
-if ( list_empty(>lr_queue) )
-{
-if ( v == current )
-gic_update_one_lr(v, n->lr);
-}
-#ifdef GIC_DEBUG
-else
-gdprintk(XENLOG_DEBUG, "trying to inject irq=%u into d%dv%d, when it is 
still lr_pending\n",
- virtual_irq, v->domain->domain_id, v->vcpu_id);
-#endif
-}
-
 /*
  * Find an unused LR to insert an IRQ into, starting with the LR given
  * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to
@@ -503,7 +475,7 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int 
virtual_irq,
 gic_add_to_lr_pending(v, p);
 }

-static void gic_update_one_lr(struct vcpu *v, int i)
+void gic_update_one_lr(struct vcpu *v, int i)
 {
 struct pending_irq *p;
 int irq;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 38dacd3..7b122cd 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -536,7 +536,16 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int 
virq)

 if ( !list_empty(>inflight) )
 {
-gic_raise_inflight_irq(v, virq);
+bool update = test_bit(GIC_IRQ_GUEST_ENABLED, >status) &&
+  list_empty(>lr_queue) && (v == current);
+
+if ( update )
+gic_update_one_lr(v, n->lr);
+#ifdef GIC_DEBUG
+else
+gdprintk(XENLOG_DEBUG, "trying to inject irq=%u into d%dv%d, when it is 
still lr_pending\n",
+ n->irq, v->domain->domain_id, v->vcpu_id);


The previous code was only printing this message when the pending_irq is 
queued. Now you will print any time you don't update the LR.



+#endif
 goto out;
 }

diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 6203dc5..cf8b8fb 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -237,12 +237,12 @@ int gic_remove_irq_from_guest(struct domain *d, unsigned 
int virq,

 extern void gic_inject(void);
 extern void gic_clear_pending_irqs(struct vcpu *v);
+extern void gic_update_one_lr(struct vcpu *v, int lr);
 extern int gic_events_need_delivery(void);

 extern void init_maintenance_interrupt(void);
 extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
 unsigned int priority);
-extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);
 extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
 extern void gic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p);




Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 49/52] libxc: add function to set hypervisor parameters

On Wed, Aug 09, 2017 at 09:07:03AM +0200, Juergen Gross wrote:
> Add a new libxc function to set hypervisor parameters at runtime
> similar to boot time parameters via command line.
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/25 v7] SBSA UART emulation support in Xen

On Thu, Aug 10, 2017 at 05:11:52PM +0100, Julien Grall wrote:
> 
> 
> On 10/08/17 17:00, Wei Liu wrote:
> > On Thu, Aug 10, 2017 at 03:26:07PM +0100, Julien Grall wrote:
> > > 
> > > 
> > > On 09/08/17 11:58, Bhupinder Thakur wrote:
> > > > Hi Julien,
> > > 
> > > Hi Bhupinder,
> > > 
> > > > Thanks for the testing.
> > > > 
> > > > On 8 August 2017 at 21:29, Julien Grall  wrote:
> > > > > Hi Bhupinder,
> > > > > 
> > > > > I gave another and I have a couple of comments.
> > > > > 
> > > > > Booting Linux with earlycon enabled take quite a while. I can see the
> > > > > characters coming slower than on the minitel. It seems to be a bit 
> > > > > better
> > > > > after switching off the bootconsole. Overall Linux is taking ~20 
> > > > > times to
> > > > > boot with pl011 vs HVC console.
> > > > > 
> > > > > I do agree that pl011 is emulated and therefore you have to trap 
> > > > > after each
> > > > > character. But 20 times sounds far too much.
> > > > > 
> > > > I think this slowness could be due to ratelimiting of the pl011 events
> > > > in xenconosle. Currently, the rate limit is
> > > > set to 30 events per 200 msecs (see 
> > > > RATE_LIMIT_ALLOWANCE/RATE_LIMIT_PERIOD).
> > > > 
> > > > I increased the rate limit to 600 events (30 * 20) per 200 msecs. With
> > > > this change,
> > > > I see that the the find command is running faster and smoother.
> > > > Earlier the find output would be jerky.
> > > 
> > > I think there might be another solution avoiding increasing the rate 
> > > limit.
> > > 
> > > If you look at the earlycon code for pl011 in Linux:
> > > 
> > > static void pl011_putc(struct uart_port *port, int c)
> > > {
> > >   while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
> > >   cpu_relax();
> > >   if (port->iotype == UPIO_MEM32)
> > >   writel(c, port->membase + UART01x_DR);
> > >   else
> > >   writeb(c, port->membase + UART01x_DR);
> > >   while (readl(port->membase + UART01x_FR) & UART01x_FR_BUSY)
> > >   cpu_relax();
> > > }
> > > 
> > > Linux will wait the UART to be idle before sending a new character.
> > > 
> > > Now looking at vpl011 emulation, the busy bit set when a new character is
> > > queued (see vpl011_write_data). This bit will only be cleared when the
> > > console daemon will raise an event and the queue is empty (see
> > > vpl011_data_avail).
> > > 
> > > This means for earlycon, you will need a round trip Guest -> Xen -> Dom0 
> > > ->
> > > Xen -> Guest for each single character. This is a bit counterproductive 
> > > and
> > > combined with the limit it makes it worse.
> > > 
> > > I would take a different approach on the BUSY bit. We can consider the 
> > > queue
> > > between Xen and xenconsoled as outside of the UART. If the character is
> > > queued, then job done. I think this would improve quite a lot of the
> > > performance.
> > 
> > Yes. This.
> > 
> > The guest sees a register, which is essentially a synchronous interface
> > to the guest. The current code, as you already see, will issue one event
> > for every character. That's excessive.
> 
> I am actually not suggesting to modify that at the moment. I think you may
> have other trouble with the interaction between the user and th console by
> doing that. Imagine you want to print the prompt, it may lag a bit before
> getting it.
> 
> The only thing I suggest is to not set the BUSY bit in the UART everytime a
> character is queued.
> 

Did you come to that conclusion that this would work by looking at the
spec or Linux source code? I think it should conform to the spec, not a
specific guest. But you're the maintainer, you have the final say.

> > 
> > The interface between Xen and xenconsoled can be asynchronous, it can
> > opt to queue X characters before sending an event, also setup a oneshot
> > timer to avoid hanging.
> > 
> > This however has some other implications -- it might not be as reliable
> > as the original method because data is not guaranteed to hit backend. If
> > the guest crashes very early on, depending the actual implementation you
> > might not be able get the data.
> 
> Would it be possible to ask xenconsoled to dump everything on domain crash?
> Some kind of synchronization.
> 

No, not at the moment. If the data is still in Xen and destroyed,
xenconsoled can't do anything.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/52] Support for modifying parameters at runtime

On Wed, Aug 09, 2017 at 09:06:14AM +0200, Juergen Gross wrote:
> Currently parameters of the hypervisor (e.g. console log level) can be
> set via boot command line. Instead of having to reboot the system in
> case another setting is desired, being able to modify many of those
> parameters at runtime would be the better option.
> 
> This patch series addresses this by adding a new xl command
> "xl set-parameters" which takes a string similar to the boot command
> line as parameter and passes this string to the hypervisor which will
> then use the same parsing infrastructure as for the command line in
> order to apply the parameter settings.
> 
> As error checks for invalid parameters or parameter values have been
> very sparse if present at all in the hypervisor, a major part of this
> patch series addresses this problem first: all custom parameter parsing
> functions are being changed to return success or an error. The main
> parsing function tests for generic parameter value errors (like e.g.
> overflow) or invalid parameters and issues a message in case an error
> has been detected. Most error messages in the custom parsing functions
> are removed then.
> 
> While not strictly required for runtime parameter modification I
> believe an improved parameter validation is a win with or without the
> runtime parameter modification support.
> 
> * Patches 1-38 are modifying the custom parameter parsing functions to
>   return success or error

I only skim-read these. They seem rather mechanic so I don't bother
sending Rb one-by-one.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] paravirt,xen: remove xen_patch()

On 10/08/17 18:29, Peter Zijlstra wrote:
> On Thu, Aug 10, 2017 at 06:24:53PM +0200, Peter Zijlstra wrote:
>> -ENTRY(xen_irq_enable_direct)
>> -FRAME_BEGIN
>> -/* Unmask events */
>> -movb $0, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_mask
>> -
>> -/*
>> - * Preempt here doesn't matter because that will deal with any
>> - * pending interrupts.  The pending check may end up being run
>> - * on the wrong CPU, but that doesn't hurt.
>> - */
>> -
>> -/* Test for pending */
>> -testb $0xff, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending
>> -jz 1f
>> -
>> -2:  call check_events
>> -1:
>> -ENDPATCH(xen_irq_enable_direct)
>> -FRAME_END
>> -ret
>> -ENDPROC(xen_irq_enable_direct)
>> -RELOC(xen_irq_enable_direct, 2b+1)
> 
> Oh my bad, part of that is still used.
> 
> arch/x86/xen/enlighten_pv.c:pv_irq_ops.irq_enable = 
> __PV_IS_CALLEE_SAVE(xen_irq_enable_direct);
> 
> It just needs cleanups for the ENDPATCH and such.

Ah yes, of course.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 50/52] libxl: add libxl_set_parameters() function

On 10/08/17 18:28, Wei Liu wrote:
> On Wed, Aug 09, 2017 at 09:07:04AM +0200, Juergen Gross wrote:
>> Add a new libxl function to set hypervisor parameters at runtime
>> similar to boot time parameters via command line.
>>
>> Cc: Ian Jackson 
>> Cc: Wei Liu 
>> Signed-off-by: Juergen Gross 
>> ---
>>  tools/libxl/libxl.c | 14 ++
>>  tools/libxl/libxl.h | 11 +++
>>  2 files changed, 25 insertions(+)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 0ef874406f..f370e445de 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -652,6 +652,20 @@ int libxl_send_debug_keys(libxl_ctx *ctx, char *keys)
>>  return 0;
>>  }
>>  
>> +int libxl_set_parameters(libxl_ctx *ctx, char *params)
>> +{
>> +int ret;
>> +GC_INIT(ctx);
>> +ret = xc_set_parameters(ctx->xch, params);
>> +if ( ret < 0 ) {
> 
> Extraneous spaces.

So the 48 hypervisor patches left some traces...


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

2017-08-10 Thread Volodymyr Babchuk




On 10.08.17 19:11, Julien Grall wrote:



On 10/08/17 16:33, Volodymyr Babchuk wrote:

Hi Julien,

On 09.08.17 13:10, Julien Grall wrote:

Hi Volodymyr,

CC "THE REST" maintainers to get an opinion on the public headers.

On 08/08/17 21:08, Volodymyr Babchuk wrote:

SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to a
different
firmware functions. Thus, for example PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such calls.
Besides functional calls there are query calls, which allows underling
OS determine version, UID and number of functions provided by service
provider.

This patch adds new file `vsmc.c`, which handles both generic SMCs
and HVC according to SMC. At this moment it implements only one
service: Standard Hypervisor Service.

Standard Hypervisor Service only supports query calls, so caller can
ask about hypervisor UID and determine that it is XEN running.

This change allows more generic handling for SMCs and HVCs and it can
be easily extended to support new services and functions.

But, before SMC is forwarded to standard SMCCC handler, it can be 
routed

to a domain monitor, if one is installed.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko 
Reviewed-by: Oleksandr Tyshchenko 
---
 - Updated description to indicate that this patch affects only SMC
call path.
 - added "xen_" prefix to definitions in include/public/arch-arm/smc.h
 - moved do_trap_smc() into vsmc.c from traps.c
 - replaced all tabs with spaces


I would have really appreciated a summary of the discussion we had on
the previous version regarding the bindings. This is a real blocker
for this series and should not be ignored.



While I agree that question about bindings is important, I can't see how
it affects this patch series. This patch series does not break anything.
Because

1. This series add only new feature: generic hypervisor service with no
immediate use. All ARM guests are already aware that they are running on
XEN. All ARM guests know that they call *only* PSCI.

2. I see importance of this patch series for embedded platforms, where
developer exactly knows what software of which version he/she will run.
I doubt that server platforms will need something beyond PSCI, which I
preserved as is.


I disagree here. SMCCC could be used to provide Dom0 a way to interact 
with the firmware if necessary.
AFAIK, Dom0 usually is built with particular version of XEN in mind (or 
at least minimal XEN version).




A I'm not denying importance of SMC bindings, but I think it is not
blocker for my patches. We can add bindings later, when there will be
consensus on how they should look. In meantime SMC handler can be used
by anyone who knows that is available.


I am not in favor on getting something merged in Xen until we agree on 
the way for the guest to know it is there. 
I think that SMC implementation will be the same, regardless the way we 
can tell guest that it is available. At this time guests can safely 
assume that SMCCC is not implemented in XEN. This wouldn't break anything.


It means you have to carry 
hack in your kernel in order to use SMC. Maybe this is fine for you, but 
I don't want to make this assumption on Xen upstream today.
Modern linux kernel uses SMC for PSCI calls and OP-TEE calls. In both 
cases it reads DT to get conduit method (SMC/HVC). So there are already 
bindings for generic uses. Other uses are platform-specific (okay, 
probably there can be a problem).


This is a change in the interface that should be notified to the guest. 
If we expose it without providing a bindings (or something), we have no 
way to revert/disable it. Imagine we want to disable SMC in the future. 
Natural way was to disable Security Extensions in PFR1 register. This 
was not done and now we have curious situation: guest thinks that SMC is 
available, but then it gets Undefined Instruction exception when it 
tries to invoke SMC.



How a guest will know that
 - until Xen 4.10 SMC was not existing,
 - between Xen 4.10 and Xen 4.x you can use them
 - after Xen 4.y they can be disabled.
It is a broader question: how software can know that SMCCC is available 
on a platform? Not SMC, but SMCCC as a protocol. Probably, there should 
be some generic way to tell Linux/Windows/XEN/Windriver Hypervisor/etc 
that they can rely on SMCCC spec. I think that it is question to ARM 
guys (including you), because this affects all ARM machines.


All changes should be detected through the firmware tables (DT, ACPI) or 
another Xen method (i.e XENFEAT_*). For instance, the guest has to parse 
the firmware tables in order to know PSCI is available.
Yep. The same does OP-TEE code. It parses DT to get conduit. Probably, 
this is wrong approach. Should all SMCCC calls use the same conduit?.

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

2017-08-10 Thread Volodymyr Babchuk


Hi,

On 10.08.17 21:18, Julien Grall wrote:

Hi,

On 10/08/17 18:40, Volodymyr Babchuk wrote:



On 10.08.17 19:11, Julien Grall wrote:



On 10/08/17 16:33, Volodymyr Babchuk wrote:

Hi Julien,

On 09.08.17 13:10, Julien Grall wrote:

Hi Volodymyr,

CC "THE REST" maintainers to get an opinion on the public headers.

On 08/08/17 21:08, Volodymyr Babchuk wrote:

SMCCC (SMC Call Convention) describes how to handle both HVCs and
SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to a
different
firmware functions. Thus, for example PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such calls.
Besides functional calls there are query calls, which allows 
underling

OS determine version, UID and number of functions provided by service
provider.

This patch adds new file `vsmc.c`, which handles both generic SMCs
and HVC according to SMC. At this moment it implements only one
service: Standard Hypervisor Service.

Standard Hypervisor Service only supports query calls, so caller can
ask about hypervisor UID and determine that it is XEN running.

This change allows more generic handling for SMCs and HVCs and it can
be easily extended to support new services and functions.

But, before SMC is forwarded to standard SMCCC handler, it can be
routed
to a domain monitor, if one is installed.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko

Reviewed-by: Oleksandr Tyshchenko 
---
 - Updated description to indicate that this patch affects only SMC
call path.
 - added "xen_" prefix to definitions in 
include/public/arch-arm/smc.h

 - moved do_trap_smc() into vsmc.c from traps.c
 - replaced all tabs with spaces


I would have really appreciated a summary of the discussion we had on
the previous version regarding the bindings. This is a real blocker
for this series and should not be ignored.



While I agree that question about bindings is important, I can't see 
how
it affects this patch series. This patch series does not break 
anything.

Because

1. This series add only new feature: generic hypervisor service with no
immediate use. All ARM guests are already aware that they are 
running on

XEN. All ARM guests know that they call *only* PSCI.

2. I see importance of this patch series for embedded platforms, where
developer exactly knows what software of which version he/she will run.
I doubt that server platforms will need something beyond PSCI, which I
preserved as is.


I disagree here. SMCCC could be used to provide Dom0 a way to interact
with the firmware if necessary.

AFAIK, Dom0 usually is built with particular version of XEN in mind (or
at least minimal XEN version).


That's not true. Dom0 is a generic kernel able to probe everything from 
the firmware tables and Xen interface. I use the exact Linux kernel on 
multiple platforms with no issue.

Okay, I was speaking about embedded use case.

The Hypervisor and Dom0 (Linux, FreeBSD) are different projects with 
different release cadence. We provide a stable interface that is 
backward compatible (returning error code for non-existent hypercalls). 
So a Linux released in 10 years should still work on Xen 4.10 and adapt 
to the features available.
I just want to clarify this. At least four hypercalls are not backward 
compatible: platform_op, sysctl, domctl and flask_op. I had a problem 
with this, when played with MiniOS-based monitor. Sure, your kernel will 
boot up, but some well known XEN services will be absent.

This have nothing with SMC bindings problem, though.





A I'm not denying importance of SMC bindings, but I think it is not
blocker for my patches. We can add bindings later, when there will be
consensus on how they should look. In meantime SMC handler can be used
by anyone who knows that is available.


I am not in favor on getting something merged in Xen until we agree on
the way for the guest to know it is there.

I think that SMC implementation will be the same, regardless the way we
can tell guest that it is available. At this time guests can safely
assume that SMCCC is not implemented in XEN. This wouldn't break 
anything.


So you suggest to merge this series but says "The guest should not 
assume the presence of SMC"? This is rather a bit odd...
Basically yes. This is one of the options. If guest knowns for sure that 
SMCCC is available - it can use it. If it is unsure - then it does not 
use it.
In meantime we can develop a generic way to tell guest that SMCCC is 
present on a platform.
I just don't want to bloat up this patch series. There are already 7 
patches and looks like there will be more.
But I can add another patch/two with bindings if you insist. This is not 
a big deal. I just have concerns about this right now.





It means you have to carry hack in your kernel in order to use SMC.
Maybe this is fine for you, but I don't want to make this assumption
on Xen

[Xen-devel] [ovmf test] 112563: regressions - FAIL

flight 112563 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112563/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm6 xen-buildfail REGR. vs. 112539
 build-i3866 xen-buildfail REGR. vs. 112539
 build-amd64-xsm   6 xen-buildfail REGR. vs. 112539
 build-amd64   6 xen-buildfail REGR. vs. 112539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 42750cf1753518ec2260ef8387d34aa8a7616303
baseline version:
 ovmf 7ef0dae092afcfb6fab7e8372c78097672168c4a

Last test of basis   112539  2017-08-09 16:46:45 Z1 days
Failing since112545  2017-08-10 04:47:25 Z0 days4 attempts
Testing same since   112563  2017-08-10 16:48:43 Z0 days1 attempts


People who touched revisions under test:
  Chris Ruffin 
  Huajing Li 
  Michael D Kinney 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit 42750cf1753518ec2260ef8387d34aa8a7616303
Author: Michael D Kinney 
Date:   Wed Aug 9 12:28:40 2017 -0700

QuarkPlatformPkg/Readme.md: Bring Readme.md up to date

The following commit moved the QuarkSocBinPkg from the root
directory of the edk2-non-osi repository to the
Silicon/Intel directory.


https://github.com/tianocore/edk2-non-osi/commit/182e85d04566800fe188de4b1c30a50533dd74b7

The following updates are made to Readme.md:

* PACKAGES_PATH setting for edk2-non-osi directory changes
* Remove use of edk2-FatPkg repository
* Remove use of edk2-BaseTools-win32 repository
* Run python build tools from sources

Cc: Leif Lindholm 
Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
Reviewed-by: Kelly Steele 
Reviewed-by: Leif Lindholm 

commit 8e8cc6881836705818ee9cd70bd48c01823ded62
Author: Michael D Kinney 
Date:   Wed Aug 9 12:19:46 2017 -0700

QuarkSocPkg/MemoryInit: Remove use of memset()/memcpy()

Map the use of memset() and memcpy() to the BaseMemoryLib
functions ZeroMem(), SetMem(), and CopyMem().  This fixes
GCC build issues with this module.

With the remap of the functions, the [BuildOptions] MSFT
CC_FLAGS to enable /Oi can also be removed, so the MSFT
and GCC builds behave the same.

Cc: Kelly Steele 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
Reviewed-by: Kelly Steele 

commit 95cc9a51e1057ace27ef09b5e19fa45d3e66ef2b
Author: Chris Ruffin 
Date:   Thu Aug 3 23:37:42 2017 +0800

BaseTools/edksetup.sh: fix invalid test for current working directory

edksetup.sh implements a test that requires the current working

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC




On 10/08/2017 21:09, Volodymyr Babchuk wrote:

Hi,

On 10.08.17 21:18, Julien Grall wrote:

Hi,

On 10/08/17 18:40, Volodymyr Babchuk wrote:



On 10.08.17 19:11, Julien Grall wrote:



On 10/08/17 16:33, Volodymyr Babchuk wrote:

Hi Julien,

On 09.08.17 13:10, Julien Grall wrote:

Hi Volodymyr,

CC "THE REST" maintainers to get an opinion on the public headers.

On 08/08/17 21:08, Volodymyr Babchuk wrote:

SMCCC (SMC Call Convention) describes how to handle both HVCs and
SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to a
different
firmware functions. Thus, for example PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such
calls.
Besides functional calls there are query calls, which allows
underling
OS determine version, UID and number of functions provided by
service
provider.

This patch adds new file `vsmc.c`, which handles both generic SMCs
and HVC according to SMC. At this moment it implements only one
service: Standard Hypervisor Service.

Standard Hypervisor Service only supports query calls, so caller can
ask about hypervisor UID and determine that it is XEN running.

This change allows more generic handling for SMCs and HVCs and it
can
be easily extended to support new services and functions.

But, before SMC is forwarded to standard SMCCC handler, it can be
routed
to a domain monitor, if one is installed.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko

Reviewed-by: Oleksandr Tyshchenko 
---
 - Updated description to indicate that this patch affects only SMC
call path.
 - added "xen_" prefix to definitions in
include/public/arch-arm/smc.h
 - moved do_trap_smc() into vsmc.c from traps.c
 - replaced all tabs with spaces


I would have really appreciated a summary of the discussion we had on
the previous version regarding the bindings. This is a real blocker
for this series and should not be ignored.



While I agree that question about bindings is important, I can't
see how
it affects this patch series. This patch series does not break
anything.
Because

1. This series add only new feature: generic hypervisor service
with no
immediate use. All ARM guests are already aware that they are
running on
XEN. All ARM guests know that they call *only* PSCI.

2. I see importance of this patch series for embedded platforms, where
developer exactly knows what software of which version he/she will
run.
I doubt that server platforms will need something beyond PSCI, which I
preserved as is.


I disagree here. SMCCC could be used to provide Dom0 a way to interact
with the firmware if necessary.

AFAIK, Dom0 usually is built with particular version of XEN in mind (or
at least minimal XEN version).


That's not true. Dom0 is a generic kernel able to probe everything
from the firmware tables and Xen interface. I use the exact Linux
kernel on multiple platforms with no issue.

Okay, I was speaking about embedded use case.


Bear in mind that Xen is not only embedded. When you upstream a new 
feature you have to think about how this could be used by anyone.





The Hypervisor and Dom0 (Linux, FreeBSD) are different projects with
different release cadence. We provide a stable interface that is
backward compatible (returning error code for non-existent
hypercalls). So a Linux released in 10 years should still work on Xen
4.10 and adapt to the features available.

I just want to clarify this. At least four hypercalls are not backward
compatible: platform_op, sysctl, domctl and flask_op. I had a problem
with this, when played with MiniOS-based monitor. Sure, your kernel will
boot up, but some well known XEN services will be absent.
This have nothing with SMC bindings problem, though.


I am not sure to follow here... Were they ever be supported on ARM? If 
not, then it is no a backward compatibility issue. You cannot assume 
that all the hypercalls existing on x86 will be available on ARM.


For a list of known available/supported hypercalls for ARM see:
public/include/arch-arm.h.

Also bear in mind that some hypercalls are not part of the stable ABI. 
For instance domctls are not stable and it is well-known that you have 
to rebuild your app for every new Xen versions...


But domctls will never be used in Linux Kernel as they only meant to be 
used to control a domain.








A I'm not denying importance of SMC bindings, but I think it is not
blocker for my patches. We can add bindings later, when there will be
consensus on how they should look. In meantime SMC handler can be used
by anyone who knows that is available.


I am not in favor on getting something merged in Xen until we agree on
the way for the guest to know it is there.

I think that SMC implementation will be the same, regardless the way we
can tell guest that it is available. At this time guests can safely
assume that SMCCC is not implemented in XEN. This wouldn't break

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

2017-08-10 Thread Jim Fehlig


On 08/08/2017 09:09 AM, Wei Liu wrote:

Ian and Stefano

Oleksandr discovered that the p9fs array in libxl_domain_config is name
p9 instead of p9s. This causes problem for his work to rework device
framework.

Given that p9fs was added only during last release and the only known
external toolstack libvirt can't possibility use that, maybe we can
rename p9 to p9s. Opinions?


ATM the libvirt libxl driver doesn't use it, but it could by supporting 
libvirt's  device


http://libvirt.org/formatdomain.html#elementsFilesystems

Regards,
Jim

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable baseline-only test] 71960: regressions - trouble: blocked/broken/fail/pass

2017-08-10 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 71960 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71960/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-examine 10 examine-serial/bootloader fail REGR. vs. 71958
 test-armhf-armhf-examine 11 examine-serial/kernel fail REGR. vs. 71958
 test-amd64-i386-libvirt-xsm  18 guest-start/debian.repeat fail REGR. vs. 71958
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-saverestore.2 
fail REGR. vs. 71958
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 71958

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 71958
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 71958
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 71958
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 71958
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 71958
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 71958
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10  fail like 71958
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 71958
 test-amd64-amd64-xl-qemut-win10-i386 16 guest-localmigrate/x10 fail like 71958
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  f5c3e78b5c61e7dfb05749c7a0c862ec18c86384
baseline version:
 xen

[Xen-devel] Building XenGT for Intel embedded board

2017-08-10 Thread Monisha Barooah

Hi Everyone,
I am currently exploring on bringing up XenGT for an Intel embedded board.

I came across this document relating to bringing up XenGT for the Sandy
Bridge/Ivy Bridge/Haswell platform
https://www.intel.com/content/dam/www/public/us/en/documents/guides/xgengt-for-ivi-solutions-dev-kit-getting-started-guide.pdf

Our current Intel embedded board is up with an Yocto image integrated with the
Intel BSP for the board. The board uses ABL boot loader.

I saw in the XenGT document for the Sandy Bridge/Ivy Bridge/Haswell platform,
that there is mention of Qemu alone and no mention of any Intel BSPs. Don't we
require Intel BSP for dom0 kernel to work in the XenGT hypervisor? Or is a
generic version of Intel BSP integrated with the kernel image link
https://github.com/01org/XenGT-Preview-kernel.git.

Also, as we have an Yocto image in the Intel board, we might have to cross
compile the Kernel, Xen and Qemu builds as mentioned in the link above for our
Intel embedded board using a Linaro toolchain. If not, is there a way, we can
link this particular version of XenGT directly with our Yocto image for the
Intel board by including the meta-virtualization layer as mentioned in the link
http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/about/ and doing
'bitbake xen image minimal'?

Please advise which is the correct route to take in this regard.

Thanks
M

__
CONFIDENTIALITY NOTE: This electronic message (including any attachments) may
contain information that is privileged, confidential, and proprietary. If you
are not the intended recipient, you are hereby notified that any disclosure,
copying, distribution, or use of the information contained herein (including
any reliance thereon) is strictly prohibited. If you received this electronic
message in error, please immediately reply to the sender that you have received
this communication and destroy the material in its entirety, whether in
electronic or hard copy format. Although Rivian Automotive Inc. has taken
reasonable precautions to ensure no viruses are present in this email, Rivian
accepts no responsibility for any loss or damage arising from the use of this
email or attachments.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: remove struct domain and vcpu declarations from types.h

On Thu, Aug 10, 2017 at 02:24:04PM +0100, Wei Liu wrote:
> They don't belong there. Removing them causes build error in compat.h.
> Add a struct domain declaration there because including sched.h
> doesn't work.
> 
> Signed-off-by: Wei Liu 

Unfortunately this version is broken on ARM. I will send v2 later.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 14/23] x86/paravirt: Adapt assembly for PIE support

if PIE is enabled, switch the paravirt assembly constraints to be
compatible. The %c/i constrains generate smaller code so is kept by
default.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/paravirt_types.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 9ffc36bfe4cd..6f67c10672ec 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -347,9 +347,17 @@ extern struct pv_lock_ops pv_lock_ops;
 #define PARAVIRT_PATCH(x)  \
(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
 
+#ifdef CONFIG_X86_PIE
+#define paravirt_opptr_call "a"
+#define paravirt_opptr_type "p"
+#else
+#define paravirt_opptr_call "c"
+#define paravirt_opptr_type "i"
+#endif
+
 #define paravirt_type(op)  \
[paravirt_typenum] "i" (PARAVIRT_PATCH(op)),\
-   [paravirt_opptr] "i" (&(op))
+   [paravirt_opptr] paravirt_opptr_type (&(op))
 #define paravirt_clobber(clobber)  \
[paravirt_clobber] "i" (clobber)
 
@@ -403,7 +411,7 @@ int paravirt_disable_iospace(void);
  * offset into the paravirt_patch_template structure, and can therefore be
  * freely converted back into a structure offset.
  */
-#define PARAVIRT_CALL  "call *%c[paravirt_opptr];"
+#define PARAVIRT_CALL  "call *%" paravirt_opptr_call "[paravirt_opptr];"
 
 /*
  * These macros are intended to wrap calls through one of the paravirt
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 01/23] x86/crypto: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/crypto/aes-x86_64-asm_64.S  | 45 -
 arch/x86/crypto/aesni-intel_asm.S| 14 ++--
 arch/x86/crypto/aesni-intel_avx-x86_64.S |  6 +-
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  | 42 ++--
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 ++---
 arch/x86/crypto/camellia-x86_64-asm_64.S |  8 ++-
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S| 50 ---
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S| 44 +++--
 arch/x86/crypto/des3_ede-asm_64.S| 96 ++--
 arch/x86/crypto/ghash-clmulni-intel_asm.S|  4 +-
 arch/x86/crypto/glue_helper-asm-avx.S|  4 +-
 arch/x86/crypto/glue_helper-asm-avx2.S   |  6 +-
 12 files changed, 211 insertions(+), 152 deletions(-)

diff --git a/arch/x86/crypto/aes-x86_64-asm_64.S 
b/arch/x86/crypto/aes-x86_64-asm_64.S
index 8739cf7795de..86fa068e5e81 100644
--- a/arch/x86/crypto/aes-x86_64-asm_64.S
+++ b/arch/x86/crypto/aes-x86_64-asm_64.S
@@ -48,8 +48,12 @@
 #define R10%r10
 #define R11%r11
 
+/* Hold global for PIE suport */
+#define RBASE  %r12
+
 #define prologue(FUNC,KEY,B128,B192,r1,r2,r5,r6,r7,r8,r9,r10,r11) \
ENTRY(FUNC);\
+   pushq   RBASE;  \
movqr1,r2;  \
leaqKEY+48(r8),r9;  \
movqr10,r11;\
@@ -74,54 +78,63 @@
movlr6 ## E,4(r9);  \
movlr7 ## E,8(r9);  \
movlr8 ## E,12(r9); \
+   popqRBASE;  \
ret;\
ENDPROC(FUNC);
 
+#define round_mov(tab_off, reg_i, reg_o) \
+   leaqtab_off(%rip), RBASE; \
+   movl(RBASE,reg_i,4), reg_o;
+
+#define round_xor(tab_off, reg_i, reg_o) \
+   leaqtab_off(%rip), RBASE; \
+   xorl(RBASE,reg_i,4), reg_o;
+
 #define round(TAB,OFFSET,r1,r2,r3,r4,r5,r6,r7,r8,ra,rb,rc,rd) \
movzbl  r2 ## H,r5 ## E;\
movzbl  r2 ## L,r6 ## E;\
-   movlTAB+1024(,r5,4),r5 ## E;\
+   round_mov(TAB+1024, r5, r5 ## E)\
movwr4 ## X,r2 ## X;\
-   movlTAB(,r6,4),r6 ## E; \
+   round_mov(TAB, r6, r6 ## E) \
roll$16,r2 ## E;\
shrl$16,r4 ## E;\
movzbl  r4 ## L,r7 ## E;\
movzbl  r4 ## H,r4 ## E;\
xorlOFFSET(r8),ra ## E; \
xorlOFFSET+4(r8),rb ## E;   \
-   xorlTAB+3072(,r4,4),r5 ## E;\
-   xorlTAB+2048(,r7,4),r6 ## E;\
+   round_xor(TAB+3072, r4, r5 ## E)\
+   round_xor(TAB+2048, r7, r6 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r4 ## E;\
-   movlTAB+1024(,r4,4),r4 ## E;\
+   round_mov(TAB+1024, r4, r4 ## E)\
movwr3 ## X,r1 ## X;\
roll$16,r1 ## E;\
shrl$16,r3 ## E;\
-   xorlTAB(,r7,4),r5 ## E; \
+   round_xor(TAB, r7, r5 ## E) \
movzbl  r3 ## L,r7 ## E;\
movzbl  r3 ## H,r3 ## E;\
-   xorlTAB+3072(,r3,4),r4 ## E;\
-   xorlTAB+2048(,r7,4),r5 ## E;\
+   round_xor(TAB+3072, r3, r4 ## E)\
+   round_xor(TAB+2048, r7, r5 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r3 ## E;\
shrl$16,r1 ## E;\
-   xorlTAB+3072(,r3,4),r6 ## E;\
-   movlTAB+2048(,r7,4),r3 ## E;\
+   round_xor(TAB+3072, r3, r6 ## E)\
+   round_mov(TAB+2048, r7, r3 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r1 ## E;\
-   xorlTAB+1024(,r1,4),r6 ## E;\
-   xorlTAB(,r7,4),r3 ## E; \
+   round_xor(TAB+1024, r1, r6 ## E)\
+   round_xor(TAB, r7, r3 ## E) \
movzbl  r2 ## H,r1 ## E;\
movzbl  r2 ## L,r7 ## E;\
shrl$16,r2 ## E;\
-   xorlTAB+3072(,r1,4),r3 ## E;\
-   xorlTAB+2048(,r7,4),r4 ## E;\
+   round_xor(TAB+3072, r1, r3 ## E)\
+   round_xor(TAB+2048, r7, r4 ## E)\
movzbl  r2 ## H,r1 ## E;\
movzbl  r2 ## L,r2 ## E;\
xorlOFFSET+8(r8),rc ## E;   \
xorlOFFSET+12(r8),rd ## E;  \
-   xorlTAB+1024(,r1,4),r3 ## E;\
-   xorlTAB(,r2,4),r4 ## E;
+   round_xor(TAB+1024, r1, r3 ## E)\
+   round_xor(TAB, r2, r4 ## E)
 
 #define move_regs(r1,r2,r3,r4) \
movlr3 ## E,r1 ## E;\
diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 16627fec80b2..5f73201dff32 100644
---

[Xen-devel] [RFC v2 13/23] x86/power/64: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/power/hibernate_asm_64.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/power/hibernate_asm_64.S 
b/arch/x86/power/hibernate_asm_64.S
index ce8da3a0412c..6fdd7bbc3c33 100644
--- a/arch/x86/power/hibernate_asm_64.S
+++ b/arch/x86/power/hibernate_asm_64.S
@@ -24,7 +24,7 @@
 #include 
 
 ENTRY(swsusp_arch_suspend)
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movq%rsp, pt_regs_sp(%rax)
movq%rbp, pt_regs_bp(%rax)
movq%rsi, pt_regs_si(%rax)
@@ -115,7 +115,7 @@ ENTRY(restore_registers)
movq%rax, %cr4;  # turn PGE back on
 
/* We don't restore %rax, it must be 0 anyway */
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movqpt_regs_sp(%rax), %rsp
movqpt_regs_bp(%rax), %rbp
movqpt_regs_si(%rax), %rsi
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 08/23] x86/entry/64: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/entry/entry_64.S | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index daf8936d0628..a3967a2af6ec 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -199,12 +199,15 @@ entry_SYSCALL_64_fastpath:
ja  1f  /* return -ENOSYS (already in 
pt_regs->ax) */
movq%r10, %rcx
 
+   /* Ensures the call is position independent */
+   leaqsys_call_table(%rip), %r11
+
/*
 * This call instruction is handled specially in stub_ptregs_64.
 * It might end up jumping to the slow path.  If it jumps, RAX
 * and all argument registers are clobbered.
 */
-   call*sys_call_table(, %rax, 8)
+   call*(%r11, %rax, 8)
 .Lentry_SYSCALL_64_after_fastpath_call:
 
movq%rax, RAX(%rsp)
@@ -339,7 +342,8 @@ ENTRY(stub_ptregs_64)
 * RAX stores a pointer to the C function implementing the syscall.
 * IRQs are on.
 */
-   cmpq$.Lentry_SYSCALL_64_after_fastpath_call, (%rsp)
+   leaq.Lentry_SYSCALL_64_after_fastpath_call(%rip), %r11
+   cmpq%r11, (%rsp)
jne 1f
 
/*
@@ -1210,7 +1214,8 @@ ENTRY(error_entry)
movl%ecx, %eax  /* zero extend */
cmpq%rax, RIP+8(%rsp)
je  .Lbstep_iret
-   cmpq$.Lgs_change, RIP+8(%rsp)
+   leaq.Lgs_change(%rip), %rcx
+   cmpq%rcx, RIP+8(%rsp)
jne .Lerror_entry_done
 
/*
@@ -1430,10 +1435,10 @@ ENTRY(nmi)
 * resume the outer NMI.
 */
 
-   movq$repeat_nmi, %rdx
+   leaqrepeat_nmi(%rip), %rdx
cmpq8(%rsp), %rdx
ja  1f
-   movq$end_repeat_nmi, %rdx
+   leaqend_repeat_nmi(%rip), %rdx
cmpq8(%rsp), %rdx
ja  nested_nmi_out
 1:
@@ -1487,7 +1492,8 @@ nested_nmi:
pushq   %rdx
pushfq
pushq   $__KERNEL_CS
-   pushq   $repeat_nmi
+   leaqrepeat_nmi(%rip), %rdx
+   pushq   %rdx
 
/* Put stack back */
addq$(6*8), %rsp
@@ -1526,7 +1532,9 @@ first_nmi:
addq$8, (%rsp)  /* Fix up RSP */
pushfq  /* RFLAGS */
pushq   $__KERNEL_CS/* CS */
-   pushq   $1f /* RIP */
+   pushq   %rax/* Support Position Independent Code */
+   leaq1f(%rip), %rax  /* RIP */
+   xchgq   %rax, (%rsp)/* Restore RAX, put 1f */
INTERRUPT_RETURN/* continues at repeat_nmi below */
UNWIND_HINT_IRET_REGS
 1:
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 16/23] x86/percpu: Adapt percpu for PIE support

Perpcu uses a clever design where the .percu ELF section has a virtual
address of zero and the relocation code avoid relocating specific
symbols. It makes the code simple and easily adaptable with or without
SMP support.

This design is incompatible with PIE because generated code always try to
access the zero virtual address relative to the default mapping address.
It becomes impossible when KASLR is configured to go below -2G. This
patch solves this problem by removing the zero mapping and adapting the GS
base to be relative to the expected address. These changes are done only
when PIE is enabled. The original implementation is kept as-is
by default.

The assembly and PER_CPU macros are changed to use relative references
when PIE is enabled.

The KALLSYMS_ABSOLUTE_PERCPU configuration is disabled with PIE given
percpu symbols are not absolute in this case.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/entry/entry_64.S  |  4 ++--
 arch/x86/include/asm/percpu.h  | 25 +++--
 arch/x86/kernel/cpu/common.c   |  4 +++-
 arch/x86/kernel/head_64.S  |  4 
 arch/x86/kernel/setup_percpu.c |  2 +-
 arch/x86/kernel/vmlinux.lds.S  | 13 +++--
 arch/x86/lib/cmpxchg16b_emu.S  |  8 
 arch/x86/xen/xen-asm.S | 12 ++--
 init/Kconfig   |  2 +-
 9 files changed, 51 insertions(+), 23 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index a3967a2af6ec..c1f9b29d4c24 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -397,7 +397,7 @@ ENTRY(__switch_to_asm)
 
 #ifdef CONFIG_CC_STACKPROTECTOR
movqTASK_stack_canary(%rsi), %rbx
-   movq%rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset
+   movq%rbx, PER_CPU_VAR(irq_stack_union + stack_canary_offset)
 #endif
 
/* restore callee-saved registers */
@@ -831,7 +831,7 @@ apicinterrupt IRQ_WORK_VECTOR   
irq_work_interrupt  smp_irq_work_interrupt
 /*
  * Exception entry points.
  */
-#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss) + (TSS_ist + ((x) - 1) * 8)
+#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss + (TSS_ist + ((x) - 1) * 8))
 
 .macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
 ENTRY(\sym)
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index 9fa03604b2b3..862eb771f0e5 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -4,9 +4,11 @@
 #ifdef CONFIG_X86_64
 #define __percpu_seg   gs
 #define __percpu_mov_opmovq
+#define __percpu_rel   (%rip)
 #else
 #define __percpu_seg   fs
 #define __percpu_mov_opmovl
+#define __percpu_rel
 #endif
 
 #ifdef __ASSEMBLY__
@@ -27,10 +29,14 @@
 #define PER_CPU(var, reg)  \
__percpu_mov_op %__percpu_seg:this_cpu_off, reg;\
lea var(reg), reg
-#define PER_CPU_VAR(var)   %__percpu_seg:var
+/* Compatible with Position Independent Code */
+#define PER_CPU_VAR(var)   %__percpu_seg:(var)##__percpu_rel
+/* Rare absolute reference */
+#define PER_CPU_VAR_ABS(var)   %__percpu_seg:var
 #else /* ! SMP */
 #define PER_CPU(var, reg)  __percpu_mov_op $var, reg
-#define PER_CPU_VAR(var)   var
+#define PER_CPU_VAR(var)   (var)##__percpu_rel
+#define PER_CPU_VAR_ABS(var)   var
 #endif /* SMP */
 
 #ifdef CONFIG_X86_64_SMP
@@ -208,27 +214,34 @@ do {  
\
pfo_ret__;  \
 })
 
+/* Position Independent code uses relative addresses only */
+#ifdef CONFIG_X86_PIE
+#define __percpu_stable_arg __percpu_arg(a1)
+#else
+#define __percpu_stable_arg __percpu_arg(P1)
+#endif
+
 #define percpu_stable_op(op, var)  \
 ({ \
typeof(var) pfo_ret__;  \
switch (sizeof(var)) {  \
case 1: \
-   asm(op "b "__percpu_arg(P1)",%0"\
+   asm(op "b "__percpu_stable_arg ",%0"\
: "=q" (pfo_ret__)  \
: "p" (&(var)));\
break;  \
case 2: \
-   asm(op "w "__percpu_arg(P1)",%0"\
+   asm(op "w "__percpu_stable_arg ",%0"\
: "=r" (pfo_ret__)  \
: "p" (&(var)));\
break;  \
case 4: \
-   asm(op "l "__percpu_arg(P1)",%0"

[Xen-devel] [RFC v2 22/23] x86/module: Add support for mcmodel large and PLTs

With PIE support and KASLR extended range, the modules may be further
away from the kernel than before breaking mcmodel=kernel expectations.

Add an option to build modules with mcmodel=large. The modules generated
code will make no assumptions on placement in memory.

Despite this option, modules still expect kernel functions to be within
2G and generate relative calls. To solve this issue, the PLT arm64 code
was adapted for x86_64. When a relative relocation go outside its range,
a dynamic PLT entry is used to correctly jump to the destination.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Kconfig  |  10 +++
 arch/x86/Makefile |  10 ++-
 arch/x86/include/asm/module.h |  17 
 arch/x86/kernel/Makefile  |   2 +
 arch/x86/kernel/module-plts.c | 198 ++
 arch/x86/kernel/module.c  |  18 ++--
 arch/x86/kernel/module.lds|   4 +
 7 files changed, 252 insertions(+), 7 deletions(-)
 create mode 100644 arch/x86/kernel/module-plts.c
 create mode 100644 arch/x86/kernel/module.lds

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a419f4110872..2b69be667543 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2139,6 +2139,16 @@ config X86_PIE
select MODULE_REL_CRCS if MODVERSIONS
select X86_GLOBAL_STACKPROTECTOR if CC_STACKPROTECTOR
 
+config X86_MODULE_MODEL_LARGE
+   bool
+   depends on X86_64 && X86_PIE
+
+config X86_MODULE_PLTS
+   bool
+   depends on X86_64
+   select X86_MODULE_MODEL_LARGE
+   select HAVE_MOD_ARCH_SPECIFIC
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 05e01588b5af..f980991804f7 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -147,10 +147,18 @@ else
 KBUILD_CFLAGS += -mno-red-zone
 ifdef CONFIG_X86_PIE
 KBUILD_CFLAGS += -fPIC
-KBUILD_CFLAGS_MODULE += -fno-PIC -mcmodel=kernel
+KBUILD_CFLAGS_MODULE += -fno-PIC
 else
 KBUILD_CFLAGS += -mcmodel=kernel
 endif
+ifdef CONFIG_X86_MODULE_MODEL_LARGE
+KBUILD_CFLAGS_MODULE += -mcmodel=large
+else
+KBUILD_CFLAGS_MODULE += -mcmodel=kernel
+endif
+ifdef CONFIG_X86_MODULE_PLTS
+KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/x86/kernel/module.lds
+endif
 
 # -funit-at-a-time shrinks the kernel .text considerably
 # unfortunately it makes reading oopses harder.
diff --git a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
index 9eb7c718aaf8..58d079fb2dc9 100644
--- a/arch/x86/include/asm/module.h
+++ b/arch/x86/include/asm/module.h
@@ -4,12 +4,26 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86_MODULE_PLTS
+struct mod_plt_sec {
+   struct elf64_shdr   *plt;
+   int plt_num_entries;
+   int plt_max_entries;
+};
+#endif
+
+
+
 struct mod_arch_specific {
 #ifdef CONFIG_ORC_UNWINDER
unsigned int num_orcs;
int *orc_unwind_ip;
struct orc_entry *orc_unwind;
 #endif
+#ifdef CONFIG_X86_MODULE_PLTS
+   struct mod_plt_sec  core;
+   struct mod_plt_sec  init;
+#endif
 };
 
 #ifdef CONFIG_X86_64
@@ -70,4 +84,7 @@ struct mod_arch_specific {
 # define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY
 #endif
 
+u64 module_emit_plt_entry(struct module *mod, void *loc, const Elf64_Rela 
*rela,
+ Elf64_Sym *sym);
+
 #endif /* _ASM_X86_MODULE_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 287eac7d207f..df32768cc576 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -140,4 +140,6 @@ ifeq ($(CONFIG_X86_64),y)
 
obj-$(CONFIG_PCI_MMCONFIG)  += mmconf-fam10h_64.o
obj-y   += vsmp_64.o
+
+   obj-$(CONFIG_X86_MODULE_PLTS)   += module-plts.o
 endif
diff --git a/arch/x86/kernel/module-plts.c b/arch/x86/kernel/module-plts.c
new file mode 100644
index ..bbf11771f424
--- /dev/null
+++ b/arch/x86/kernel/module-plts.c
@@ -0,0 +1,198 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Generate PLT entries for out-of-bound PC-relative relocations. It is 
required
+ * when a module can be mapped more than 2G away from the kernel.
+ *
+ * Based on arm64 module-plts implementation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* jmpQWORD PTR [rip+0xfff2] */
+const u8 jmp_target[] = { 0xFF, 0x25, 0xF2, 0xFF, 0xFF, 0xFF };
+
+struct plt_entry {
+   u64 target; /* Hold the target address */
+   u8 jmp[sizeof(jmp_target)]; /* jmp opcode to target */
+};
+
+static bool in_init(const struct module *mod, void *loc)
+{
+   return (u64)loc - (u64)mod->init_layout.base < mod->init_layout.size;
+}
+
+u64 module_emit_plt_entry(struct module *mod,

[Xen-devel] [RFC v2 11/23] x86/acpi: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/acpi/wakeup_64.S | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
index 50b8ed0317a3..472659c0f811 100644
--- a/arch/x86/kernel/acpi/wakeup_64.S
+++ b/arch/x86/kernel/acpi/wakeup_64.S
@@ -14,7 +14,7 @@
 * Hooray, we are in Long 64-bit mode (but still running in low memory)
 */
 ENTRY(wakeup_long64)
-   movqsaved_magic, %rax
+   movqsaved_magic(%rip), %rax
movq$0x123456789abcdef0, %rdx
cmpq%rdx, %rax
jne bogus_64_magic
@@ -25,14 +25,14 @@ ENTRY(wakeup_long64)
movw%ax, %es
movw%ax, %fs
movw%ax, %gs
-   movqsaved_rsp, %rsp
+   movqsaved_rsp(%rip), %rsp
 
-   movqsaved_rbx, %rbx
-   movqsaved_rdi, %rdi
-   movqsaved_rsi, %rsi
-   movqsaved_rbp, %rbp
+   movqsaved_rbx(%rip), %rbx
+   movqsaved_rdi(%rip), %rdi
+   movqsaved_rsi(%rip), %rsi
+   movqsaved_rbp(%rip), %rbp
 
-   movqsaved_rip, %rax
+   movqsaved_rip(%rip), %rax
jmp *%rax
 ENDPROC(wakeup_long64)
 
@@ -45,7 +45,7 @@ ENTRY(do_suspend_lowlevel)
xorl%eax, %eax
callsave_processor_state
 
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movq%rsp, pt_regs_sp(%rax)
movq%rbp, pt_regs_bp(%rax)
movq%rsi, pt_regs_si(%rax)
@@ -64,13 +64,14 @@ ENTRY(do_suspend_lowlevel)
pushfq
popqpt_regs_flags(%rax)
 
-   movq$.Lresume_point, saved_rip(%rip)
+   leaq.Lresume_point(%rip), %rax
+   movq%rax, saved_rip(%rip)
 
-   movq%rsp, saved_rsp
-   movq%rbp, saved_rbp
-   movq%rbx, saved_rbx
-   movq%rdi, saved_rdi
-   movq%rsi, saved_rsi
+   movq%rsp, saved_rsp(%rip)
+   movq%rbp, saved_rbp(%rip)
+   movq%rbx, saved_rbx(%rip)
+   movq%rdi, saved_rdi(%rip)
+   movq%rsi, saved_rsi(%rip)
 
addq$8, %rsp
movl$3, %edi
@@ -82,7 +83,7 @@ ENTRY(do_suspend_lowlevel)
.align 4
 .Lresume_point:
/* We don't restore %rax, it must be 0 anyway */
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movqsaved_context_cr4(%rax), %rbx
movq%rbx, %cr4
movqsaved_context_cr3(%rax), %rbx
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 17/23] compiler: Option to default to hidden symbols

Provide an option to default visibility to hidden except for key
symbols. This option is disabled by default and will be used by x86_64
PIE support to remove errors between compilation units.

Signed-off-by: Thomas Garnier 
---
 arch/x86/boot/boot.h   |  2 +-
 arch/x86/include/asm/setup.h   |  2 +-
 include/asm-generic/sections.h |  6 ++
 include/linux/compiler.h   |  8 
 init/Kconfig   |  7 +++
 kernel/kallsyms.c  | 16 
 6 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index ef5a9cc66fb8..d726c35bdd96 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -193,7 +193,7 @@ static inline bool memcmp_gs(const void *s1, addr_t s2, 
size_t len)
 }
 
 /* Heap -- available for dynamic lists. */
-extern char _end[];
+extern char _end[] __default_visibility;
 extern char *HEAP;
 extern char *heap_end;
 #define RESET_HEAP() ((void *)( HEAP = _end ))
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index a65cf544686a..7e0b54f605c6 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -67,7 +67,7 @@ static inline void x86_ce4100_early_setup(void) { }
  * This is set up by the setup-routine at boot-time
  */
 extern struct boot_params boot_params;
-extern char _text[];
+extern char _text[] __default_visibility;
 
 static inline bool kaslr_enabled(void)
 {
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 532372c6cf15..27c12f6dd6e2 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -28,6 +28,9 @@
  * __entry_text_start, __entry_text_end
  * __ctors_start, __ctors_end
  */
+#ifdef CONFIG_DEFAULT_HIDDEN
+#pragma GCC visibility push(default)
+#endif
 extern char _text[], _stext[], _etext[];
 extern char _data[], _sdata[], _edata[];
 extern char __bss_start[], __bss_stop[];
@@ -42,6 +45,9 @@ extern char __start_rodata[], __end_rodata[];
 
 /* Start and end of .ctors section - used for constructor calls. */
 extern char __ctors_start[], __ctors_end[];
+#ifdef CONFIG_DEFAULT_HIDDEN
+#pragma GCC visibility pop
+#endif
 
 extern __visible const void __nosave_begin, __nosave_end;
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index dfaaeec4a32e..3a79b536cef8 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -78,6 +78,14 @@ extern void __chk_io_ptr(const volatile void __iomem *);
 #include 
 #endif
 
+/* Useful for Position Independent Code to reduce global references */
+#ifdef CONFIG_DEFAULT_HIDDEN
+#pragma GCC visibility push(hidden)
+#define __default_visibility  __attribute__((visibility ("default")))
+#else
+#define __default_visibility
+#endif
+
 /*
  * Generic compiler-dependent macros required for kernel
  * build go below this comment. Actual compiler/compiler version
diff --git a/init/Kconfig b/init/Kconfig
index 482a18a88fb9..a886d73993db 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1640,6 +1640,13 @@ config PROFILING
 config TRACEPOINTS
bool
 
+#
+# Default to hidden visibility for all symbols.
+# Useful for Position Independent Code to reduce global references.
+#
+config DEFAULT_HIDDEN
+   bool
+
 source "arch/Kconfig"
 
 endmenu# General setup
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 127e7cfafa55..252019c8c3a9 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -32,24 +32,24 @@
  * These will be re-linked against their real values
  * during the second link stage.
  */
-extern const unsigned long kallsyms_addresses[] __weak;
-extern const int kallsyms_offsets[] __weak;
-extern const u8 kallsyms_names[] __weak;
+extern const unsigned long kallsyms_addresses[] __weak __default_visibility;
+extern const int kallsyms_offsets[] __weak __default_visibility;
+extern const u8 kallsyms_names[] __weak __default_visibility;
 
 /*
  * Tell the compiler that the count isn't in the small data section if the arch
  * has one (eg: FRV).
  */
 extern const unsigned long kallsyms_num_syms
-__attribute__((weak, section(".rodata")));
+__attribute__((weak, section(".rodata"))) __default_visibility;
 
 extern const unsigned long kallsyms_relative_base
-__attribute__((weak, section(".rodata")));
+__attribute__((weak, section(".rodata"))) __default_visibility;
 
-extern const u8 kallsyms_token_table[] __weak;
-extern const u16 kallsyms_token_index[] __weak;
+extern const u8 kallsyms_token_table[] __weak __default_visibility;
+extern const u16 kallsyms_token_index[] __weak __default_visibility;
 
-extern const unsigned long kallsyms_markers[] __weak;
+extern const unsigned long kallsyms_markers[] __weak __default_visibility;
 
 static inline int is_kernel_inittext(unsigned long addr)
 {
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 21/23] x86/relocs: Add option to generate 64-bit relocations

The x86 relocation tool generates a list of 32-bit signed integers. There
was no need to use 64-bit integers because all addresses where above the 2G
top of the memory.

This change add a large-reloc option to generate 64-bit unsigned integers.
It can be used when the kernel plan to go below the top 2G and 32-bit
integers are not enough.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c| 60 +-
 arch/x86/tools/relocs.h|  4 +--
 arch/x86/tools/relocs_common.c | 15 +++
 3 files changed, 60 insertions(+), 19 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 70f523dd68ff..19b3e6c594b1 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -12,8 +12,14 @@
 
 static Elf_Ehdr ehdr;
 
+#if ELF_BITS == 64
+typedef uint64_t rel_off_t;
+#else
+typedef uint32_t rel_off_t;
+#endif
+
 struct relocs {
-   uint32_t*offset;
+   rel_off_t   *offset;
unsigned long   count;
unsigned long   size;
 };
@@ -627,7 +633,7 @@ static void print_absolute_relocs(void)
printf("\n");
 }
 
-static void add_reloc(struct relocs *r, uint32_t offset)
+static void add_reloc(struct relocs *r, rel_off_t offset)
 {
if (r->count == r->size) {
unsigned long newsize = r->size + 5;
@@ -983,26 +989,48 @@ static void sort_relocs(struct relocs *r)
qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs);
 }
 
-static int write32(uint32_t v, FILE *f)
+static int write32(rel_off_t rel, FILE *f)
 {
-   unsigned char buf[4];
+   unsigned char buf[sizeof(uint32_t)];
+   uint32_t v = (uint32_t)rel;
 
put_unaligned_le32(v, buf);
-   return fwrite(buf, 1, 4, f) == 4 ? 0 : -1;
+   return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
 }
 
-static int write32_as_text(uint32_t v, FILE *f)
+static int write32_as_text(rel_off_t rel, FILE *f)
 {
+   uint32_t v = (uint32_t)rel;
return fprintf(f, "\t.long 0x%08"PRIx32"\n", v) > 0 ? 0 : -1;
 }
 
-static void emit_relocs(int as_text, int use_real_mode)
+static int write64(rel_off_t rel, FILE *f)
+{
+   unsigned char buf[sizeof(uint64_t)];
+   uint64_t v = (uint64_t)rel;
+
+   put_unaligned_le64(v, buf);
+   return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
+}
+
+static int write64_as_text(rel_off_t rel, FILE *f)
+{
+   uint64_t v = (uint64_t)rel;
+   return fprintf(f, "\t.quad 0x%016"PRIx64"\n", v) > 0 ? 0 : -1;
+}
+
+static void emit_relocs(int as_text, int use_real_mode, int use_large_reloc)
 {
int i;
-   int (*write_reloc)(uint32_t, FILE *) = write32;
+   int (*write_reloc)(rel_off_t, FILE *);
int (*do_reloc)(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
const char *symname);
 
+   if (use_large_reloc)
+   write_reloc = write64;
+   else
+   write_reloc = write32;
+
 #if ELF_BITS == 64
if (!use_real_mode)
do_reloc = do_reloc64;
@@ -1013,6 +1041,9 @@ static void emit_relocs(int as_text, int use_real_mode)
do_reloc = do_reloc32;
else
do_reloc = do_reloc_real;
+
+   /* Large relocations only for 64-bit */
+   use_large_reloc = 0;
 #endif
 
/* Collect up the relocations */
@@ -1036,8 +1067,13 @@ static void emit_relocs(int as_text, int use_real_mode)
 * gas will like.
 */
printf(".section \".data.reloc\",\"a\"\n");
-   printf(".balign 4\n");
-   write_reloc = write32_as_text;
+   if (use_large_reloc) {
+   printf(".balign 8\n");
+   write_reloc = write64_as_text;
+   } else {
+   printf(".balign 4\n");
+   write_reloc = write32_as_text;
+   }
}
 
if (use_real_mode) {
@@ -1131,7 +1167,7 @@ static void print_reloc_info(void)
 
 void process(FILE *fp, int use_real_mode, int as_text,
 int show_absolute_syms, int show_absolute_relocs,
-int show_reloc_info)
+int show_reloc_info, int use_large_reloc)
 {
regex_init(use_real_mode);
read_ehdr(fp);
@@ -1153,5 +1189,5 @@ void process(FILE *fp, int use_real_mode, int as_text,
print_reloc_info();
return;
}
-   emit_relocs(as_text, use_real_mode);
+   emit_relocs(as_text, use_real_mode, use_large_reloc);
 }
diff --git a/arch/x86/tools/relocs.h b/arch/x86/tools/relocs.h
index 1d23bf953a4a..cb771cc4412d 100644
--- a/arch/x86/tools/relocs.h
+++ b/arch/x86/tools/relocs.h
@@ -30,8 +30,8 @@ enum symtype {
 
 void process_32(FILE *fp, int use_real_mode, int as_text,
int show_absolute_syms, int show_absolute_relocs,
-   int show_reloc_info);
+   int show_reloc_info, int

[Xen-devel] x86: PIE support and option to extend KASLR randomization

Changes:
 - v2:
   - Add support for global stack cookie while compiler default to fs without
 mcmodel=kernel
   - Change patch 7 to correctly jump out of the identity mapping on kexec load
 preserve.

These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.

Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general.

The patches:
 - 1-3, 5-15: Change in assembly code to be PIE compliant.
 - 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
 - 16: Adapt percpu design to work correctly when PIE is enabled.
 - 17: Provide an option to default visibility to hidden except for key symbols.
   It removes errors between compilation units.
 - 18: Adapt relocation tool to handle PIE binary correctly.
 - 19: Add support for global cookie
 - 20: Add the CONFIG_X86_PIE option (off by default)
 - 21: Adapt relocation tool to generate a 64-bit relocation table.
 - 22: Add options to build modules as mcmodel=large and dynamically create a
   PLT for relative references out of range (adapted from arm64).
 - 23: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
   from 1G to 3G (off by default).

Performance/Size impact:

Hackbench (50% and 1600% loads):
 - PIE disabled: no significant change (-0.50% / +0.50%)
 - PIE enabled: 7% to 8% on half load, 10% on heavy load.

These results are aligned with the different research on user-mode PIE
impact on cpu intensive benchmarks (around 10% on x86_64).

slab_test (average of 10 runs):
 - PIE disabled: no significant change (-1% / +1%)
 - PIE enabled: 3% to 4%

Kernbench (average of 10 Half and Optimal runs):
 Elapsed Time:
 - PIE disabled: no significant change (-0.22% / +0.06%)
 - PIE enabled: around 0.50%
 System Time:
 - PIE disabled: no significant change (-0.99% / -1.28%)
 - PIE enabled: 5% to 6%

Size of vmlinux (Ubuntu configuration):
 File size:
 - PIE disabled: 472928672 bytes (-0.000169% from baseline)
 - PIE enabled: 216878461 bytes (-54.14% from baseline)
 .text sections:
 - PIE disabled: 9373572 bytes (+0.04% from baseline)
 - PIE enabled: 9499138 bytes (+1.38% from baseline)

The big decrease in vmlinux file size is due to the lower number of
relocations appended to the file.

diffstat:
 arch/x86/Kconfig |   42 +
 arch/x86/Makefile|   28 +++
 arch/x86/boot/boot.h |2 
 arch/x86/boot/compressed/Makefile|5 
 arch/x86/boot/compressed/misc.c  |   10 +
 arch/x86/crypto/aes-x86_64-asm_64.S  |   45 +++---
 arch/x86/crypto/aesni-intel_asm.S|   14 +
 arch/x86/crypto/aesni-intel_avx-x86_64.S |6 
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  |   42 ++---
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S |   44 +++---
 arch/x86/crypto/camellia-x86_64-asm_64.S |8 -
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S|   50 +++---
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S|   44 +++---
 arch/x86/crypto/des3_ede-asm_64.S|   96 -
 arch/x86/crypto/ghash-clmulni-intel_asm.S|4 
 arch/x86/crypto/glue_helper-asm-avx.S|4 
 arch/x86/crypto/glue_helper-asm-avx2.S   |6 
 arch/x86/entry/entry_32.S|3 
 arch/x86/entry/entry_64.S|   29 ++-
 arch/x86/include/asm/asm.h   |   13 +
 arch/x86/include/asm/bug.h   |2 
 arch/x86/include/asm/jump_label.h|8 -
 arch/x86/include/asm/kvm_host.h  |6 
 arch/x86/include/asm/module.h|   17 ++
 arch/x86/include/asm/page_64_types.h |9 +
 arch/x86/include/asm/paravirt_types.h|   12 +
 arch/x86/include/asm/percpu.h|   25 ++-
 arch/x86/include/asm/pm-trace.h  |2 
 arch/x86/include/asm/processor.h |   11 -
 arch/x86/include/asm/setup.h |2 
 arch/x86/include/asm/stackprotector.h|   19 +-
 arch/x86/kernel/Makefile |2 
 arch/x86/kernel/acpi/wakeup_64.S |   31 ++--
 arch/x86/kernel/asm-offsets.c|3 
 arch/x86/kernel/asm-offsets_32.c |3 
 arch/x86/kernel/asm-offsets_64.c |3 
 arch/x86/kernel/cpu/common.c |7 
 arch/x86/kernel/head64.c |   30 +++-
 arch/x86/kernel/head_32.S|3 
 arch/x86/kernel/head_64.S|   46 +-
 arch/x86/kernel/kvm.c|6 
 arch/x86/kernel/module-plts.c|  198 +++
 arch/x86/kernel/module.c |   18 +-
 arch/x86/kernel/module.lds   |4

[Xen-devel] [RFC v2 06/23] kvm: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible. The new __ASM_GET_PTR_PRE macro is used to
get the address of a symbol on both 32 and 64-bit with PIE support.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/kvm_host.h | 6 --
 arch/x86/kernel/kvm.c   | 6 --
 arch/x86/kvm/svm.c  | 4 ++--
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7cbaab523f22..276e288da25e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1352,9 +1352,11 @@ asmlinkage void kvm_spurious_fault(void);
".pushsection .fixup, \"ax\" \n" \
"667: \n\t" \
cleanup_insn "\n\t"   \
-   "cmpb $0, kvm_rebooting \n\t" \
+   "cmpb $0, kvm_rebooting" __ASM_SEL(,(%%rip)) " \n\t" \
"jne 668b \n\t"   \
-   __ASM_SIZE(push) " $666b \n\t"\
+   __ASM_SIZE(push) "%%" _ASM_AX " \n\t"   \
+   __ASM_GET_PTR_PRE(666b) "%%" _ASM_AX "\n\t" \
+   "xchg %%" _ASM_AX ", (%%" _ASM_SP ") \n\t"  \
"call kvm_spurious_fault \n\t"\
".popsection \n\t" \
_ASM_EXTABLE(666b, 667b)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index d04e30e3c0ff..cb83745185f2 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -620,8 +620,10 @@ asm(
 ".global __raw_callee_save___kvm_vcpu_is_preempted;"
 ".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
 "__raw_callee_save___kvm_vcpu_is_preempted:"
-"movq  __per_cpu_offset(,%rdi,8), %rax;"
-"cmpb  $0, " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rax);"
+"leaq  __per_cpu_offset(%rip), %rax;"
+"movq  (%rax,%rdi,8), %rax;"
+"addq  " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rip), %rax;"
+"cmpb  $0, (%rax);"
 "setne %al;"
 "ret;"
 ".popsection");
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 4d4743361f1e..6e611f9f6163 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -554,12 +554,12 @@ static u32 svm_msrpm_offset(u32 msr)
 
 static inline void clgi(void)
 {
-   asm volatile (__ex(SVM_CLGI));
+   asm volatile (__ex(SVM_CLGI) : :);
 }
 
 static inline void stgi(void)
 {
-   asm volatile (__ex(SVM_STGI));
+   asm volatile (__ex(SVM_STGI) : :);
 }
 
 static inline void invlpga(unsigned long addr, u32 asid)
-- 
2.14.0.434.g98096fd7a8-goog


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC v2 05/23] xen: Adapt assembly for PIE support