Re: [Xen-devel] [RFC 3/6] Introduce _xrealloc

2017-06-08 Thread Stefano Stabellini 
On Thu, 8 Jun 2017, Sameer Goel wrote:
> Introduce a memory realloc function.
> 
> Signed-off-by: Sameer Goel 
> ---
>  xen/common/xmalloc_tlsf.c | 13 +
>  xen/include/xen/xmalloc.h |  1 +
>  2 files changed, 14 insertions(+)
> 
> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
> index b256dc5..52385a8 100644
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -612,6 +612,19 @@ void *_xzalloc(unsigned long size, unsigned long align)
>  return p ? memset(p, 0, size) : p;
>  }
>  
> +void *_xrealloc(void *p, unsigned long new_size, unsigned long align)
> +{
> +void *new_p = _xmalloc(new_size, align);

It might be best to handle the case where new_size is 0 explicitly, and
only free p.


> +if(new_p && p)
> +{
> +memcpy(new_p, p, new_size);
> +xfree(p);
> +}
> +
> +return new_p;
> +}
> +
>  void xfree(void *p)
>  {
>  struct bhdr *b;
> diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
> index 24a99ac..41a9b2f 100644
> --- a/xen/include/xen/xmalloc.h
> +++ b/xen/include/xen/xmalloc.h
> @@ -29,6 +29,7 @@ extern void xfree(void *);
>  /* Underlying functions */
>  extern void *_xmalloc(unsigned long size, unsigned long align);
>  extern void *_xzalloc(unsigned long size, unsigned long align);
> +extern void *_xrealloc(void *p, unsigned long new_size, unsigned long align);
>  
>  static inline void *_xmalloc_array(
>  unsigned long size, unsigned long align, unsigned long num)
> -- 
> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
> Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
> Linux Foundation Collaborative Project.
> 

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

Re: [Xen-devel] [RFC 2/6] arm64: Add definitions for fwnode_handle

2017-06-08 Thread Stefano Stabellini 
On Thu, 8 Jun 2017, Goel, Sameer wrote:
> >> diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
> >> new file mode 100644
> >> index 000..db65b15
> >> --- /dev/null
> >> +++ b/xen/include/xen/fwnode.h
> >> @@ -0,0 +1,35 @@
> >> +/*
> >> + * fwnode.h - Firmware device node object handle type definition.
> >> + *
> >> + * Copyright (C) 2015, Intel Corporation
> >> + * Author: Rafael J. Wysocki 
> >> + *
> >> + * 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.
> >> + *
> >> + * Ported from Linux include/linux/fwnode.h
> >> + *  => commit ce793486e23e0162a732c605189c8028e0910e86
> >> + *
> >> + * No functional Xen modifications.
> >> + */
> >> +
> >> +#ifndef __XEN_FWNODE_H_
> >> +#define __XEN_FWNODE_H_
> >> +
> >> +enum fwnode_type {
> >> +FWNODE_INVALID = 0,
> >> +FWNODE_OF,
> >> +FWNODE_ACPI,
> >> +FWNODE_ACPI_DATA,
> >> +FWNODE_ACPI_STATIC,
> >> +FWNODE_PDATA,
> >> +FWNODE_IRQCHIP
> > 
> > Do you really need to introduce all of them?
> > 
> Not really. We are interested in OF and ACPI_STATIC for now. Since the 
> verbatim file from Linux applied ok, I did not remove the other entries.
> What's your recommendation?

Usually we keep the imported Linux definitions as-is.


> >> +};
> >> +
> >> +struct fwnode_handle {
> >> +enum fwnode_type type;
> >> +struct fwnode_handle *secondary;
> >> +};
> >> +
> >> +#endif
> >>

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

[Xen-devel] linux-next: bad commit in the xen-tip tree

2017-06-08 Thread Stephen Rothwell 
Hi all,

The current top commit of the xen-tip tree

  9e925824eccd ("xen: avoid type warning in xchg_xen_ulong")

has no Signed-off-by for its committer.

-- 
Cheers,
Stephen Rothwell

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

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

2017-06-08 Thread Andrew Cooper 
On 08/06/2017 22:17, Boris Ostrovsky wrote:
> On 06/08/2017 05:02 PM, Tom Lendacky wrote:
>> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote:
> What may be needed is making sure X86_FEATURE_SME is not set for PV
> guests.
 And that may be something that Xen will need to control through either
 CPUID or MSR support for the PV guests.
>>>
>>> Only on newer versions of Xen. On earlier versions (2-3 years old) leaf
>>> 0x8007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG.
>> The SME feature is in leaf 0x801f, is that leaf passed to the guest
>> unchanged?
> Oh, I misread the patch where X86_FEATURE_SME is defined. Then all
> versions, including the current one, pass it unchanged.
>
> All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in
> xen_init_capabilities().

AMD processors still don't support CPUID Faulting (or at least, I
couldn't find any reference to it in the latest docs), so we cannot
actually hide SME from a guest which goes looking at native CPUID. 
Furthermore, I'm not aware of any CPUID masking support covering that leaf.

However, if Linux is using the paravirtual cpuid hook, things are
slightly better.

On Xen 4.9 and later, no guests will see the feature.  On earlier
versions of Xen (before I fixed the logic), plain domUs will not see the
feature, while dom0 will.

For safely, I'd recommend unilaterally clobbering the feature as Boris
suggested.  There is no way SME will be supportable on a per-PV guest
basis, although (as far as I am aware) Xen as a whole would be able to
encompass itself and all of its PV guests inside one single SME instance.

~Andrew

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

Re: [Xen-devel] linux-next: bad commit in the xen-tip tree

2017-06-08 Thread Stefano Stabellini 
On Fri, 9 Jun 2017, Stephen Rothwell wrote:
> Hi all,
> 
> The current top commit of the xen-tip tree
> 
>   9e925824eccd ("xen: avoid type warning in xchg_xen_ulong")
> 
> has no Signed-off-by for its committer.

Fixed, thanks for pointing it out.

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

Re: [Xen-devel] [RFC 6/6] acpi:arm64: Add support for parsing IORT table

2017-06-08 Thread Stefano Stabellini 
CCing Jan

On Thu, 8 Jun 2017, Sameer Goel wrote:
> Add limited support for parsing IORT table to initialize SMMU devices.
> 
> Signed-off-by: Sameer Goel 
> ---
>  xen/arch/arm/setup.c|   3 +
>  xen/drivers/acpi/Makefile   |   1 +
>  xen/drivers/acpi/arm/Makefile   |   1 +
>  xen/drivers/acpi/arm/iort.c | 232 
> +++-
>  xen/drivers/passthrough/arm/iommu.c |  15 +--
>  xen/include/acpi/acpi.h |   1 +
>  xen/include/acpi/acpi_iort.h|  25 ++--
>  xen/include/asm-arm/device.h|   2 +
>  xen/include/xen/acpi.h  |  21 
>  xen/include/xen/lib.h   |   7 +-
>  xen/include/xen/pci.h   |   1 +
>  11 files changed, 184 insertions(+), 125 deletions(-)
>  create mode 100644 xen/drivers/acpi/arm/Makefile

This patch doesn't apply with "git am" and doesn't build on x86 with:

In file included from /local/repos/xen-upstream/xen/include/xen/iommu.h:24:0,
 from /local/repos/xen-upstream/xen/include/asm/hvm/domain.h:23,
 from /local/repos/xen-upstream/xen/include/asm/domain.h:7,
 from /local/repos/xen-upstream/xen/include/xen/domain.h:8,
 from /local/repos/xen-upstream/xen/include/xen/sched.h:11,
 from x86_64/asm-offsets.c:9:
/local/repos/xen-upstream/xen/include/xen/pci.h:91:19: error: field ‘dev’ has 
incomplete type
 struct device dev;
   ^
In file included from /local/repos/xen-upstream/xen/include/acpi/acpi.h:63:0,
 from /local/repos/xen-upstream/xen/include/xen/acpi.h:33,
 from /local/repos/xen-upstream/xen/include/asm/fixmap.h:21,
 from x86_64/asm-offsets.c:12:
/local/repos/xen-upstream/xen/include/acpi/acpi_iort.h:60:23: error: expected 
‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘iort_iommu_configure’
 acpi_status iommu_ops iort_iommu_configure(struct device *dev)
   ^
make[3]: *** [asm-offsets.s] Error 1


And it doesn't build on arm64 with:

/local/repos/xen-upstream/xen/arch/arm/setup.c:765: undefined reference to 
`acpi_iort_init'
/local/repos/gcc-linaro-4.9-2014.05-aarch64-linux-gnu-x86_64-linux-gnu/bin/aarch64-linux-gnu-ld:
 /local/repos/xen-upstream/xen/.xen-syms.0: hidden symbol `acpi_iort_init' 
isn't defined
/local/repos/gcc-linaro-4.9-2014.05-aarch64-linux-gnu-x86_64-linux-gnu/bin/aarch64-linux-gnu-ld:
 final link failed: Bad value
make[3]: *** [/local/repos/xen-upstream/xen/xen-syms] Error 1


> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 92a2de6..5dc93ff 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -753,6 +753,9 @@ void __init start_xen(unsigned long boot_phys_offset,
>  /* Parse the ACPI tables for possible boot-time configuration */
>  acpi_boot_table_init();
>  
> +/* Initialize the IORT tables */
> +acpi_iort_init();
> +
>  if ( acpi_disabled )
>  printk("Booting using Device Tree\n");
>  else
> diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
> index 444b11d..4165318 100644
> --- a/xen/drivers/acpi/Makefile
> +++ b/xen/drivers/acpi/Makefile
> @@ -1,5 +1,6 @@
>  subdir-y += tables
>  subdir-y += utilities
> +subdir-$(CONFIG_ARM_64) += arm
>  subdir-$(CONFIG_X86) += apei
>  
>  obj-bin-y += tables.init.o
> diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
> new file mode 100644
> index 000..7c039bb
> --- /dev/null
> +++ b/xen/drivers/acpi/arm/Makefile
> @@ -0,0 +1 @@
> +obj-y += iort.o
> diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
> index 4a5bb96..c22ec31 100644
> --- a/xen/drivers/acpi/arm/iort.c
> +++ b/xen/drivers/acpi/arm/iort.c
> @@ -14,29 +14,40 @@
>   * This file implements early detection/parsing of I/O mapping
>   * reported to OS through firmware via I/O Remapping Table (IORT)
>   * IORT document number: ARM DEN 0049A
> + *
> + * Based on Linux drivers/acpi/arm64/iort.c
> + * => commit ca78d3173cff3503bcd15723b049757f75762d15
> + *
> + * Xen modification:
> + * Sameer Goel 
> + * Copyright (C) 2017, The Linux Foundation, All rights reserved.
> + *
>   */
>  
> -#define pr_fmt(fmt)  "ACPI: IORT: " fmt
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
>  
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
>  
>  #define IORT_TYPE_MASK(type) (1 << (type))
>  #define IORT_MSI_TYPE(1 << ACPI_IORT_NODE_ITS_GROUP)
>  #define IORT_IOMMU_TYPE  ((1 << ACPI_IORT_NODE_SMMU) |   \
>   (1 << ACPI_IORT_NODE_SMMU_V3))
>  
> +#if 0
>  struct iort_its_msi_chip {
>   struct list_headlist;
>   struct fwnode_handle*fw_node;
>   u32 translation_id;
>  };
>  
> +#endif
> +
>  struct iort_fwnode {
>   struct list_head list;
>

Re: [Xen-devel] [PATCH 0/4] xenfb: Add vkbd-only option

2017-06-08 Thread Stefano Stabellini 
On Thu, 8 Jun 2017, Owen Smith wrote:
> Adds the ability for a vkbd device to connect without the
> QemuConsole, in order to support a standalone PV mouse and
> keyboard frontend.
> This series adds a new feature flag, which will need adding
> to the xen's include/public/io/kbdif.h

Please do so, I would like that change to be applied to xen before this
series is applied to QEMU.


> "feature-vkbd-standalone" is set to 1 by backends that allow 
> the vkbd device model to connect without requiring a vfb device
> connected. The vkbd device will only bypass the check for
> the vfb device if the frontend sets "request-vkbd-standalone"
> to 1.
> The last 2 patches add a couple of missing input handler
> functions, and uses these to remove a leak in the vkbd device
> model.
> 
> Owen Smith (4):
>   xenfb: Add feature-vkbd-standalone
>   xenfb: Activate mouse handler
>   ui/input: Add activate/remove for keyboard handlers
>   xenfb: Fix leak by adding/removing keyboard handler
> 
>  hw/display/xenfb.c   | 44 
>  include/ui/console.h |  2 ++
>  ui/input-legacy.c| 12 
>  3 files changed, 46 insertions(+), 12 deletions(-)
> 
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH 1/4] xenfb: Add feature-vkbd-standalone

2017-06-08 Thread Stefano Stabellini 
On Thu, 8 Jun 2017, Owen Smith wrote:
> Advertise "feature-vkbd-standalone" to indicate the backend
> can connect without a vfb device connection.
> When "request-vkbd-standalone" is set to 1, the backend does
> not wait for a QemuConsole to be setup before connecting the 
> vkbd device. This also means that absolute coordinates cannot
> be scaled to the non-existent QemuConsole's sizes, and remain
> unscaled, in the range [0, 0x7FFF].
> 
> Signed-off-by: Owen Smith 
> ---
>  hw/display/xenfb.c | 32 ++--
>  1 file changed, 22 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index e76c0d8..2ebc81b 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -52,6 +52,7 @@ struct common {
>  struct XenInput {
>  struct common c;
>  int abs_pointer_wanted; /* Whether guest supports absolute pointer */
> +int vkbd_standalone;/* Guest supports vkbd without vfb device */
>  int button_state;   /* Last seen pointer button state */
>  int extended;
>  QEMUPutMouseEntry *qmouse;
> @@ -306,18 +307,22 @@ static void xenfb_mouse_event(void *opaque,
> int dx, int dy, int dz, int button_state)
>  {
>  struct XenInput *xenfb = opaque;
> -DisplaySurface *surface = qemu_console_surface(xenfb->c.con);
> -int dw = surface_width(surface);
> -int dh = surface_height(surface);
> -int i;
> +int i, x, y;
> +if (xenfb->c.con != NULL) {
> +DisplaySurface *surface = qemu_console_surface(xenfb->c.con);
> +int dw = surface_width(surface);
> +int dh = surface_height(surface);
> +x = dx * (dh - 1) / 0x7fff;
> +y = dy * (dw - 1) / 0x7fff;
> +} else {
> +x = dx;
> +y = dy;
> +}
>  
>  trace_xenfb_mouse_event(opaque, dx, dy, dz, button_state,
>  xenfb->abs_pointer_wanted);
>  if (xenfb->abs_pointer_wanted)
> - xenfb_send_position(xenfb,
> - dx * (dw - 1) / 0x7fff,
> - dy * (dh - 1) / 0x7fff,
> - dz);
> +xenfb_send_position(xenfb, x, y, dz);
>  else
>   xenfb_send_motion(xenfb, dx, dy, dz);
>  
> @@ -336,6 +341,7 @@ static void xenfb_mouse_event(void *opaque,
>  static int input_init(struct XenDevice *xendev)
>  {
>  xenstore_write_be_int(xendev, "feature-abs-pointer", 1);
> +xenstore_write_be_int(xendev, "feature-vkbd-standalone", 1);
>  return 0;
>  }
>  
> @@ -345,8 +351,14 @@ static int input_initialise(struct XenDevice *xendev)
>  int rc;
>  
>  if (!in->c.con) {
> -xen_pv_printf(xendev, 1, "ds not set (yet)\n");
> -return -1;
> +if (xenstore_read_fe_int(xendev, "request-vkbd-standalone",
> + >vkbd_standalone) == -1) {
> +in->vkbd_standalone = 0;
> +}
> +if (in->vkbd_standalone == 0) {
> +xen_pv_printf(xendev, 1, "ds not set (yet)\n");
> +return -1;
> +}

In your changes to include/public/io/kbdif.h, make sure to write when
(at what xenstore status stage) the frontend needs to write
request-vkbd-standalone. 

This patch looks good:

Reviewed-by: Stefano Stabellini 



>  }
>  
>  rc = common_bind(>c);

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

Re: [Xen-devel] [PATCH 2/4] xenfb: Activate mouse handler

2017-06-08 Thread Stefano Stabellini 
On Thu, 8 Jun 2017, Owen Smith wrote:
> Mouse events are only delivered to the first handler in the chain.
> Activating the xenfb mouse event handler so that mouse events can
> be passed over the shared ring protocol.
> Note: The keyboard handler is activated internally by the add
> call.

I am not sure I follow: why do we need this now? How is it working
today?


> Signed-off-by: Owen Smith 
> ---
>  hw/display/xenfb.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 2ebc81b..b0a5726 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -385,6 +385,7 @@ static void input_connected(struct XenDevice *xendev)
>  in->qmouse = qemu_add_mouse_event_handler(xenfb_mouse_event, in,
> in->abs_pointer_wanted,
> "Xen PVFB Mouse");
> +qemu_activate_mouse_event_handler(in->qmouse);
>  }
>  
>  static void input_disconnect(struct XenDevice *xendev)
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [for-4.9] Re: HVM guest performance regression

2017-06-08 Thread Dario Faggioli 
Bringing in Konrad because...

On Thu, 2017-06-08 at 11:37 +0200, Juergen Gross wrote:
> On 07/06/17 20:19, Stefano Stabellini wrote:
> > On Wed, 7 Jun 2017, Juergen Gross wrote:
> > > On 06/06/17 21:08, Stefano Stabellini wrote:
> > > > 
> > > > 2) PV suspend/resume
> > > > 3) vector callback
> > > > 4) interrupt remapping
> > > > 
> > > > 2) is not on the hot path.
> > > > I did individual measurements of 3) at some points and it was a
> > > > clear win.
> > > 
> > > That might depend on the hardware. Could it be newer processors
> > > are
> > > faster here?
> > 
> > I don't think so: the alternative it's an emulated interrupt. It's
> > slower under all points of view.
> 
> What about APIC virtualization of modern processors? Are you sure
> e.g.
> timer interrupts aren't handled completely by the processor? I guess
> this might be faster than letting it be handled by the hypervisor and
> then use the callback into the guest.
> 
... I kind of remember an email exchange we had, not here on the list,
but in private, about some apparently weird scheduling behavior you
were seeing, there at Oracle, on a particular benchmark/customer's
workload.

Not that this is directly related, but I seem to also recall that you
managed to find out that some of the perf difference (between baremetal
and guest) was due to vAPIC being faster than the PV path we were
taking? What I don't recall, though, is whether your guest was PV or
(PV)HVM... Do you remember anything more precisely than this?

It was like one or two years ago... (I'll dig in the archives for the
emails.)

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] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

2017-06-08 Thread Tom Lendacky 

On 6/8/2017 3:51 PM, Boris Ostrovsky wrote:





What may be needed is making sure X86_FEATURE_SME is not set for PV
guests.


And that may be something that Xen will need to control through either
CPUID or MSR support for the PV guests.



Only on newer versions of Xen. On earlier versions (2-3 years old) leaf
0x8007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG.


The SME feature is in leaf 0x801f, is that leaf passed to the guest
unchanged?

Thanks,
Tom



-boris



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

Re: [Xen-devel] [RFC 2/6] arm64: Add definitions for fwnode_handle

2017-06-08 Thread Goel, Sameer 
On 6/8/2017 1:59 PM, Julien Grall wrote:
> 
> 
> On 08/06/2017 20:30, Sameer Goel wrote:
>> This will be used as a device property to match the DMA capable devices
>> with the associated SMMU. The header file is a port from linux.
>>
>> Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
>> companions using fwnode_handle
>>
>> Signed-off-by: Sameer Goel 
>> ---
>>  xen/include/asm-arm/device.h |  2 ++
>>  xen/include/xen/fwnode.h | 35 +++
>>  2 files changed, 37 insertions(+)
>>  create mode 100644 xen/include/xen/fwnode.h
>>
>> diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
>> index 6734ae8..78c38fe 100644
>> --- a/xen/include/asm-arm/device.h
>> +++ b/xen/include/asm-arm/device.h
>> @@ -2,6 +2,7 @@
>>  #define __ASM_ARM_DEVICE_H
>>
>>  #include 
>> +#include 
>>
>>  enum device_type
>>  {
>> @@ -19,6 +20,7 @@ struct device
>>  #ifdef CONFIG_HAS_DEVICE_TREE
>>  struct dt_device_node *of_node; /* Used by drivers imported from Linux 
>> */
>>  #endif
>> +struct fwnode_handle *fwnode; /*fw device node identifier */
> 
> I am a bit surprised you don't rework struct dev. As of_node is now redundant 
> with fwnode.

I agree that this will eventually be removed. I have kept this in now just to 
maintain compatibility
(compilation and otherwise) with smmuv2 driver. I will add a comment to 
indicate this. So that it can 
be easily identified and remove when we do a final cleanup. Can I prefix the 
comment with with XEN:TODO:? 

> 
>>  struct dev_archdata archdata;
>>  };
>>
>> diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
>> new file mode 100644
>> index 000..db65b15
>> --- /dev/null
>> +++ b/xen/include/xen/fwnode.h
>> @@ -0,0 +1,35 @@
>> +/*
>> + * fwnode.h - Firmware device node object handle type definition.
>> + *
>> + * Copyright (C) 2015, Intel Corporation
>> + * Author: Rafael J. Wysocki 
>> + *
>> + * 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.
>> + *
>> + * Ported from Linux include/linux/fwnode.h
>> + *  => commit ce793486e23e0162a732c605189c8028e0910e86
>> + *
>> + * No functional Xen modifications.
>> + */
>> +
>> +#ifndef __XEN_FWNODE_H_
>> +#define __XEN_FWNODE_H_
>> +
>> +enum fwnode_type {
>> +FWNODE_INVALID = 0,
>> +FWNODE_OF,
>> +FWNODE_ACPI,
>> +FWNODE_ACPI_DATA,
>> +FWNODE_ACPI_STATIC,
>> +FWNODE_PDATA,
>> +FWNODE_IRQCHIP
> 
> Do you really need to introduce all of them?
> 
Not really. We are interested in OF and ACPI_STATIC for now. Since the verbatim 
file from Linux applied ok, I did not remove the other entries.
What's your recommendation?

>> +};
>> +
>> +struct fwnode_handle {
>> +enum fwnode_type type;
>> +struct fwnode_handle *secondary;
>> +};
>> +
>> +#endif
>>
> 
> Cheers,
> 

Thanks,
Sameer
-- 
 Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

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

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

2017-06-08 Thread Boris Ostrovsky 

>
>> What may be needed is making sure X86_FEATURE_SME is not set for PV
>> guests.
>
> And that may be something that Xen will need to control through either
> CPUID or MSR support for the PV guests.


Only on newer versions of Xen. On earlier versions (2-3 years old) leaf
0x8007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG.

-boris

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

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

2017-06-08 Thread Boris Ostrovsky 
On 06/08/2017 05:02 PM, Tom Lendacky wrote:
> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote:
>>
>>>
 What may be needed is making sure X86_FEATURE_SME is not set for PV
 guests.
>>>
>>> And that may be something that Xen will need to control through either
>>> CPUID or MSR support for the PV guests.
>>
>>
>> Only on newer versions of Xen. On earlier versions (2-3 years old) leaf
>> 0x8007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG.
>
> The SME feature is in leaf 0x801f, is that leaf passed to the guest
> unchanged?

Oh, I misread the patch where X86_FEATURE_SME is defined. Then all
versions, including the current one, pass it unchanged.

All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in
xen_init_capabilities().


-boris

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

Re: [Xen-devel] [PATCH 0/5] xen/pvh*: Support > 32 VCPUs at restore

2017-06-08 Thread Konrad Rzeszutek Wilk 
On Thu, Jun 08, 2017 at 10:28:15AM +0200, Juergen Gross wrote:
> On 03/06/17 02:05, Ankur Arora wrote:
> > This patch series fixes a bunch of issues in the xen_vcpu setup
> > logic.
> > 
> > Simplify xen_vcpu related code: code refactoring in advance of the
> > rest of the patch series.
> > 
> > Support > 32 VCPUs at restore: unify all vcpu restore logic in
> > xen_vcpu_restore() and support > 32 VCPUs for PVH*.
> > 
> > Remove vcpu info placement from restore (!SMP): some pv_ops are
> > marked RO after init so lets not redo xen_setup_vcpu_info_placement
> > at restore.
> > 
> > Handle xen_vcpu_setup() failure in hotplug: handle vcpu_info
> > registration failures by propagating them from the cpuhp-prepare
> > callback back up to the cpuhp logic.
> > 
> > Handle xen_vcpu_setup() failure at boot: pull CPUs (> MAX_VIRT_CPUS)
> > down if we fall back to xen_have_vcpu_info_placement = 0.
> > 
> > Tested with various combinations of PV/PVHv2/PVHVM save/restore
> > and cpu-hotadd-hotremove. Also tested by simulating failure in
> > VCPUOP_register_vcpu_info.
> > 
> > Please review.
> 
> Just a question regarding the sequence of tags (Reviewed-by: and
> Signed-off-by:) in the patches:
> 
> It seems a little bit odd to have the Reviewed-by: tag before the
> S-o-b: tag. This suggests the review was done before you wrote the
> patches, which is hard to believe. :-)

That is how the Linux orders the tags, just do 'git log' and you
will see that pattern.
> 
> So please reorder the tags in future patches to be in their logical
> sequence.

While Xen orders it in the other order (SoB first, then Reviewed-by).

> 
> I can fix this up in this series in case there is no need for V2.
> 
> 
> Juergen
> 
> > 
> > Ankur Arora (5):
> >   xen/vcpu: Simplify xen_vcpu related code
> >   xen/pvh*: Support > 32 VCPUs at domain restore
> >   xen/pv: Fix OOPS on restore for a PV, !SMP domain
> >   xen/vcpu: Handle xen_vcpu_setup() failure in hotplug
> >   xen/vcpu: Handle xen_vcpu_setup() failure at boot
> > 
> >  arch/x86/xen/enlighten.c | 154 
> > +++
> >  arch/x86/xen/enlighten_hvm.c |  33 --
> >  arch/x86/xen/enlighten_pv.c  |  87 +++-
> >  arch/x86/xen/smp.c   |  31 +
> >  arch/x86/xen/smp.h   |   2 +
> >  arch/x86/xen/smp_hvm.c   |  14 +++-
> >  arch/x86/xen/smp_pv.c|   6 +-
> >  arch/x86/xen/suspend_hvm.c   |  11 +---
> >  arch/x86/xen/xen-ops.h   |   3 +-
> >  include/xen/xen-ops.h|   2 +
> >  10 files changed, 218 insertions(+), 125 deletions(-)
> > 
> 
> 
> ___
> 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] Delivery Status Notification (Delay)

2017-06-08 Thread f4da1594 

** Delivery incomplete **

There was a temporary problem delivering your message to 
curtiskwo...@gmail.com. Gmail will retry for 47 more hours. You'll be notified 
if the delivery fails permanently.



Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2YAMHECCJDLIBAYAWYAKIAZAQHSMCCWMBLIA4UANQUEIGCIMBKMAZUZ4AAEAACA===@opayq.com
Arrival-Date: Wed, 07 Jun 2017 16:33:33 -0700 (PDT)
X-Original-Message-ID: 

Final-Recipient: rfc822; curtiskwong9@gmail.com
Action: delayed
Status: 4.0.0
Last-Attempt-Date: Thu, 08 Jun 2017 16:35:50 -0700 (PDT)
Will-Retry-Until: Sat, 10 Jun 2017 16:33:33 -0700 (PDT)


[Xen-changelog] [xen master] x86/vlapic: fix two flaws in emulating
Description: Message attachment
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

<    1   2   3