[Xen-devel] [PATCH v2 2/3] arm/xen: add support for vm_assist hypercall

[Juergen Gross]

Add support for the Xen HYPERVISOR_vm_assist hypercall.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
---
 arch/arm/include/asm/xen/hypercall.h | 1 +
 arch/arm/xen/enlighten.c | 1 +
 arch/arm/xen/hypercall.S | 1 +
 arch/arm64/xen/hypercall.S   | 1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/xen/hypercall.h 
b/arch/arm/include/asm/xen/hypercall.h
index b6b962d..9d874db 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -52,6 +52,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
 int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_vm_assist(unsigned int cmd, unsigned int type);
 int HYPERVISOR_platform_op_raw(void *arg);
 static inline int HYPERVISOR_platform_op(struct xen_platform_op *op)
 {
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 71db30c..0f3aa12 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -389,4 +389,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
 EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
+EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
 EXPORT_SYMBOL_GPL(privcmd_call);
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 9a36f4f..a648dfc 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -91,6 +91,7 @@ HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
 HYPERCALL1(platform_op_raw);
 HYPERCALL2(multicall);
+HYPERCALL2(vm_assist);
 
 ENTRY(privcmd_call)
stmdb sp!, {r4}
diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
index 70df80e..329c802 100644
--- a/arch/arm64/xen/hypercall.S
+++ b/arch/arm64/xen/hypercall.S
@@ -82,6 +82,7 @@ HYPERCALL3(vcpu_op);
 HYPERCALL1(tmem_op);
 HYPERCALL1(platform_op_raw);
 HYPERCALL2(multicall);
+HYPERCALL2(vm_assist);
 
 ENTRY(privcmd_call)
mov x16, x0
-- 
2.6.6


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

[Xen-devel] [PATCH v2 1/3] xen: update xen headers

[Juergen Gross]

Update some Xen headers to be able to use new functionality.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Stefano Stabellini 
---
 include/xen/interface/vcpu.h | 24 +++-
 include/xen/interface/xen.h  | 17 -
 2 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/include/xen/interface/vcpu.h b/include/xen/interface/vcpu.h
index b05288c..98188c8 100644
--- a/include/xen/interface/vcpu.h
+++ b/include/xen/interface/vcpu.h
@@ -75,15 +75,21 @@
  */
 #define VCPUOP_get_runstate_info4
 struct vcpu_runstate_info {
-   /* VCPU's current state (RUNSTATE_*). */
-   int  state;
-   /* When was current state entered (system time, ns)? */
-   uint64_t state_entry_time;
-   /*
-* Time spent in each RUNSTATE_* (ns). The sum of these times is
-* guaranteed not to drift from system time.
-*/
-   uint64_t time[4];
+   /* VCPU's current state (RUNSTATE_*). */
+   int  state;
+   /* When was current state entered (system time, ns)? */
+   uint64_t state_entry_time;
+   /*
+* Update indicator set in state_entry_time:
+* When activated via VMASST_TYPE_runstate_update_flag, set during
+* updates in guest memory mapped copy of vcpu_runstate_info.
+*/
+#define XEN_RUNSTATE_UPDATE(1ULL << 63)
+   /*
+* Time spent in each RUNSTATE_* (ns). The sum of these times is
+* guaranteed not to drift from system time.
+*/
+   uint64_t time[4];
 };
 DEFINE_GUEST_HANDLE_STRUCT(vcpu_runstate_info);
 
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index d133112..1b0d189 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -413,7 +413,22 @@ DEFINE_GUEST_HANDLE_STRUCT(mmuext_op);
 /* x86/PAE guests: support PDPTs above 4GB. */
 #define VMASST_TYPE_pae_extended_cr3 3
 
-#define MAX_VMASST_TYPE 3
+/*
+ * x86 guests: Sane behaviour for virtual iopl
+ *  - virtual iopl updated from do_iret() hypercalls.
+ *  - virtual iopl reported in bounce frames.
+ *  - guest kernels assumed to be level 0 for the purpose of iopl checks.
+ */
+#define VMASST_TYPE_architectural_iopl   4
+
+/*
+ * All guests: activate update indicator in vcpu_runstate_info
+ * Enable setting the XEN_RUNSTATE_UPDATE flag in guest memory mapped
+ * vcpu_runstate_info during updates of the runstate information.
+ */
+#define VMASST_TYPE_runstate_update_flag 5
+
+#define MAX_VMASST_TYPE 5
 
 #ifndef __ASSEMBLY__
 
-- 
2.6.6


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

[Xen-devel] [PATCH v2 3/3] xen: support runqueue steal time on xen

[Juergen Gross]

Up to now reading the stolen time of a remote cpu was not possible in a
performant way under Xen. This made support of runqueue steal time via
paravirt_steal_rq_enabled impossible.

With the addition of an appropriate hypervisor interface this is now
possible, so add the support.

Signed-off-by: Juergen Gross 
---
V2: removed static variable as requested by Stefano Stabellini
---
 drivers/xen/time.c | 40 +++-
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 2257b66..a7fe35b 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -47,27 +47,31 @@ static u64 get64(const u64 *p)
return ret;
 }
 
-/*
- * Runstate accounting
- */
-void xen_get_runstate_snapshot(struct vcpu_runstate_info *res)
+static void xen_get_runstate_snapshot_cpu(struct vcpu_runstate_info *res,
+ unsigned int cpu)
 {
u64 state_time;
struct vcpu_runstate_info *state;
 
BUG_ON(preemptible());
 
-   state = this_cpu_ptr(_runstate);
+   state = per_cpu_ptr(_runstate, cpu);
 
-   /*
-* The runstate info is always updated by the hypervisor on
-* the current CPU, so there's no need to use anything
-* stronger than a compiler barrier when fetching it.
-*/
do {
state_time = get64(>state_entry_time);
+   rmb();  /* Hypervisor might update data. */
*res = READ_ONCE(*state);
-   } while (get64(>state_entry_time) != state_time);
+   rmb();  /* Hypervisor might update data. */
+   } while (get64(>state_entry_time) != state_time ||
+(state_time & XEN_RUNSTATE_UPDATE));
+}
+
+/*
+ * Runstate accounting
+ */
+void xen_get_runstate_snapshot(struct vcpu_runstate_info *res)
+{
+   xen_get_runstate_snapshot_cpu(res, smp_processor_id());
 }
 
 /* return true when a vcpu could run but has no real cpu to run on */
@@ -80,8 +84,7 @@ static u64 xen_steal_clock(int cpu)
 {
struct vcpu_runstate_info state;
 
-   BUG_ON(cpu != smp_processor_id());
-   xen_get_runstate_snapshot();
+   xen_get_runstate_snapshot_cpu(, cpu);
return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
 }
 
@@ -98,11 +101,14 @@ void xen_setup_runstate_info(int cpu)
 
 void __init xen_time_setup_guest(void)
 {
+   bool xen_runstate_remote;
+
+   xen_runstate_remote = !HYPERVISOR_vm_assist(VMASST_CMD_enable,
+   VMASST_TYPE_runstate_update_flag);
+
pv_time_ops.steal_clock = xen_steal_clock;
 
static_key_slow_inc(_steal_enabled);
-   /*
-* We can't set paravirt_steal_rq_enabled as this would require the
-* capability to read another cpu's runstate info.
-*/
+   if (xen_runstate_remote)
+   static_key_slow_inc(_steal_rq_enabled);
 }
-- 
2.6.6


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

[Xen-devel] [PATCH v2 0/3] xen: add full support for CONFIG_PARAVIRT_TIME_ACCOUNTING

[Juergen Gross]

With most recent Xen hypervisor (4.8) it is now possible to add full
support of CONFIG_PARAVIRT_TIME_ACCOUNTING.

To be applied on top of commit ed2f61fdd2356c2a1d1239aa1507ce4e2e059306
"xen: add steal_clock support on x86" of kernel/git/xen/tip.git

Runtime tested on x86_64, compile tested on arm64.

Changes in V2:
- patch 3: removed static variable as requested by Stefano Stabellini

Juergen Gross (3):
  xen: update xen headers
  arm/xen: add support for vm_assist hypercall
  xen: support runqueue steal time on xen

 arch/arm/include/asm/xen/hypercall.h |  1 +
 arch/arm/xen/enlighten.c |  1 +
 arch/arm/xen/hypercall.S |  1 +
 arch/arm64/xen/hypercall.S   |  1 +
 drivers/xen/time.c   | 40 +---
 include/xen/interface/vcpu.h | 24 ++
 include/xen/interface/xen.h  | 17 ++-
 7 files changed, 58 insertions(+), 27 deletions(-)

-- 
2.6.6


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

Re: [Xen-devel] [PATCH 3/3] xen: support runqueue steal time on xen

[Juergen Gross]

On 05/07/16 17:23, Stefano Stabellini wrote:
> On Wed, 22 Jun 2016, Juergen Gross wrote:
>> Up to now reading the stolen time of a remote cpu was not possible in a
>> performant way under Xen. This made support of runqueue steal time via
>> paravirt_steal_rq_enabled impossible.
>>
>> With the addition of an appropriate hypervisor interface this is now
>> possible, so add the support.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  drivers/xen/time.c | 42 +-
>>  1 file changed, 25 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
>> index 2257b66..65afbe9 100644
>> --- a/drivers/xen/time.c
>> +++ b/drivers/xen/time.c
>> @@ -19,6 +19,9 @@
>>  /* runstate info updated by Xen */
>>  static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
>>  
>> +/* runstate info of remote cpu accessible */
>> +static bool xen_runstate_remote;
> 
> Honestly I would rather have one global variable less if it means only
> dropping one BUG_ON.

Okay, I'll remove it.


Juergen

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

[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm
testid debian-hvm-install

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  8156d480861e937768d7d9ac0b73c1e74c368f1d
  Bug not present: 46e7b70699d8bf4db08c8bb5111974318dd5416d
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/96696/


  commit 8156d480861e937768d7d9ac0b73c1e74c368f1d
  Author: Gerd Hoffmann 
  Date:   Thu Jun 2 10:48:25 2016 +0200
  
  pc: allow raising low memory via max-ram-below-4g option
  
  This patch extends the functionality of the max-ram-below-4g option
  to also allow increasing lowmem.  Use case: Give as much memory as
  possible to legacy non-PAE guests.
  
  While being at it also rework the lowmem calculation logic and add a
  longish comment describing how it works and what the compatibility
  constrains are.
  
  Note:  This is a incompatible change.  When setting max-ram-below-4g to
  a value larger than 3.5G (or 3G with gigabyte alignment) it has no
  effect on older qemu versions: qemu silently ignores it.  With the patch
  applied it actually has an effect and changes the ram layout.  Highly
  unlikely to hit in practive though as there is no reason start old qemu
  versions that way.
  
  Signed-off-by: Gerd Hoffmann 
  Reviewed-by: Eduardo Habkost 
  Message-Id: <1464857305-26675-1-git-send-email-kra...@redhat.com>
  Signed-off-by: Paolo Bonzini 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm.debian-hvm-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm.debian-hvm-install
 --summary-out=tmp/96696.bisection-summary --basis-template=94856 
--blessings=real,real-bisect qemu-mainline 
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 96652 fail [host=nocera1] / 95888 [host=godello1] 95868 [host=fiano0] 95838 
[host=pinot1] 95649 [host=elbling1] 95573 [host=godello0] 95502 
[host=huxelrebe1] 95451 [host=italia0] 95397 [host=huxelrebe0] 95352 
[host=chardonnay1] 95299 [host=merlot1] 95276 [host=chardonnay0] 95258 
[host=elbling0] 95237 [host=baroque1] 95213 [host=pinot1] 95183 [host=pinot0] 
95144 [host=fiano0] 95121 [host=italia1] 95089 [host=baroque0] 94994 ok.
Failure / basis pass flights: 96652 / 94994
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest fe8567f6ad0055f38141f473071b30f3fe8df728 
246b3b28808ee5f4664be674dce573af9497fc7a 
44dd5e6b1cf505485d839bd62d47e29a36232d67 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
6e20809727261599e8527c456eb078c0e89139a1 
11659423113d2fbcf055085b5e8285d590addfaa 
bb4f41b3dff831faaf5a3248e0ecd123024d7f8f
Basis pass 2bd61c84489918c0648aee317c18b5a03f5949a4 
246b3b28808ee5f4664be674dce573af9497fc7a 
c977650a67e6ca6c3cff9548b031d072d00db80a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
500acc9c410bcea17148a1072e323c08d12e6a6b 
8b3d6858ecbe5f958f45ac5d8e5da6fa5a18266d
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#2bd61c84489918c0648aee317c18b5a03f5949a4-fe8567f6ad0055f38141f473071b30f3fe8df728
 
git://git.sv.gnu.org/gnulib.git#246b3b28808ee5f4664be674dce573af9497fc7a-246b3b28808ee5f4664be674dce573af9497fc7a
 
git://xenbits.xen.org/linux-pvops.git#c977650a67e6ca6c3cff9548b031d072d00db80a-44dd5e6b1cf505485d839bd62d47e29a36232d67
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#df553c056104e3dd8a2bd2e72539a57c4c085bae-6e20809727261599e8527c456eb078c0e89139a1
 

Re: [Xen-devel] Lenovo X200 IOMMU support through Xen 4.6 iommu=no-igfx switch

[Thierry Laurion]

I Konrad, first, thanks for your input and your time, it is much
appreciated.

I understand that those changes are torward the linux kernel, which is used
by xen compilation. I applied the changes and i'm rebuilding Qubes with xen
4.6.1 based on a kernel-4.1.24. Will test the build in the next days and
post back the results.

output of sudo lspci -v from dom0:
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
Controller Hub (rev 07)
Subsystem: Lenovo Device 20e0
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information: Len=0a 
Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Lenovo Device 20e4
Flags: bus master, fast devsel, latency 0, IRQ 47
Memory at e100 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 3400 [size=8]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)
Subsystem: Lenovo Device 20e4
Flags: fast devsel
Memory at e140 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3

00:19.0 Ethernet controller: Intel Corporation 82567LF Gigabit Network
Connection (rev 03)
Subsystem: Lenovo Device 20ee
Flags: bus master, fast devsel, latency 0, IRQ 60
Memory at e160 (32-bit, non-prefetchable) [size=128K]
Memory at e1624000 (32-bit, non-prefetchable) [size=4K]
I/O ports at 3000 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] PCI Advanced Features
Kernel driver in use: pciback
Kernel modules: e1000e

00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #4 (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device 20f0
Flags: bus master, medium devsel, latency 0, IRQ 16
I/O ports at 3020 [size=32]
Capabilities: [50] PCI Advanced Features
Kernel driver in use: pciback
Kernel modules: uhci_hcd

00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #5 (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device 20f0
Flags: bus master, medium devsel, latency 0, IRQ 17
I/O ports at 3040 [size=32]
Capabilities: [50] PCI Advanced Features
Kernel driver in use: pciback
Kernel modules: uhci_hcd

00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #6 (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device 20f0
Flags: bus master, medium devsel, latency 0, IRQ 18
I/O ports at 3060 [size=32]
Capabilities: [50] PCI Advanced Features
Kernel driver in use: pciback
Kernel modules: uhci_hcd

00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #2 (rev 03) (prog-if 20 [EHCI])
Subsystem: Lenovo Device 20f1
Flags: bus master, medium devsel, latency 0, IRQ 18
Memory at e1626000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: pciback
Kernel modules: ehci_pci

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
Controller (rev 03)
Subsystem: Lenovo Device 20f2
Flags: bus master, fast devsel, latency 0, IRQ 48
Memory at e162 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [130] Root Complex Link
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port
1 (rev 03) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 40
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Capabilities: [40] Express Root Port (Slot-), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Lenovo Device 20f3
Capabilities: [a0] Power Management version 2
Capabilities: [100] Virtual Channel
Capabilities: [180] Root Complex Link
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port
2 (rev 03) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 41
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0

Re: [Xen-devel] [PATCH 14/18] arm/altp2m: Add HVMOP_altp2m_set_mem_access.

[Sergej Proskurin]

Hello Julien,

On 07/05/2016 02:49 PM, Julien Grall wrote:
> Hello Sergej,
> 
> On 04/07/16 12:45, Sergej Proskurin wrote:
>> +static inline
>> +int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
>> +  struct p2m_domain *ap2m, p2m_access_t a,
>> +  gfn_t gfn)
>> +{
> 
> [...]
> 
>> +/* Set mem access attributes - currently supporting only one (4K)
>> page. */
>> +mask = level_masks[3];
>> +return apply_p2m_changes(d, ap2m, INSERT,
>> + gpa & mask,
>> + (gpa + level_sizes[level]) & mask,
>> + maddr & mask, mattr, 0, p2mt, a);
> 
> The operation INSERT will remove the previous mapping and decrease page
> reference for foreign mapping (see p2m_put_l3_page). So if you set the
> memory access for this kind of page, the reference count will be wrong
> afterward.
> 

I see your point. As far as I understand, the purpose of the function
p2m_put_l3_page to simply decrement the ref count of the particular pte
and free the page if its' ref count reaches zero. Since p2m_put_l3_page
is called only twice in p2m.c, we could insert a check
(p2m_is_hostp2m/altp2m) making sure that the ref count is decremented
only if the p2m in question is the hostp2m. This will make sure that the
ref count is maintained correctly.

Thank you for pointing that out.

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH 13/18] arm/altp2m: Make get_page_from_gva ready for altp2m.

[Sergej Proskurin]

Hi Julien,

On 07/04/2016 10:34 PM, Julien Grall wrote:
> Hello Sergej,
> 
> On 04/07/2016 12:45, Sergej Proskurin wrote:
>> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
>> index ce1c3c3..413125f 100644
>> --- a/xen/arch/arm/guestcopy.c
>> +++ b/xen/arch/arm/guestcopy.c
>> @@ -17,7 +17,7 @@ static unsigned long raw_copy_to_guest_helper(void
>> *to, const void *from,
>>  unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
>>  struct page_info *page;
>>
>> -page = get_page_from_gva(current->domain, (vaddr_t) to,
>> GV2M_WRITE);
>> +page = get_page_from_gva(current, (vaddr_t) to, GV2M_WRITE);
>>  if ( page == NULL )
>>  return len;
>>
>> @@ -64,7 +64,7 @@ unsigned long raw_clear_guest(void *to, unsigned len)
>>  unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
>>  struct page_info *page;
>>
>> -page = get_page_from_gva(current->domain, (vaddr_t) to,
>> GV2M_WRITE);
>> +page = get_page_from_gva(current, (vaddr_t) to, GV2M_WRITE);
>>  if ( page == NULL )
>>  return len;
>>
>> @@ -96,7 +96,7 @@ unsigned long raw_copy_from_guest(void *to, const
>> void __user *from, unsigned le
>>  unsigned size = min(len, (unsigned)(PAGE_SIZE - offset));
>>  struct page_info *page;
>>
>> -page = get_page_from_gva(current->domain, (vaddr_t) from,
>> GV2M_READ);
>> +page = get_page_from_gva(current, (vaddr_t) from, GV2M_READ);
>>  if ( page == NULL )
>>  return len;
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 9c8fefd..23b482f 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -1829,10 +1829,11 @@ err:
>>  return page;
>>  }
>>
>> -struct page_info *get_page_from_gva(struct domain *d, vaddr_t va,
>> +struct page_info *get_page_from_gva(struct vcpu *v, vaddr_t va,
>>  unsigned long flags)
>>  {
>> -struct p2m_domain *p2m = >arch.p2m;
>> +struct domain *d = v->domain;
>> +struct p2m_domain *p2m = altp2m_active(d) ? p2m_get_altp2m(v) :
>> p2m_get_hostp2m(d);
>>  struct page_info *page = NULL;
>>  paddr_t maddr = 0;
>>  int rc;
>> @@ -1844,17 +1845,23 @@ struct page_info *get_page_from_gva(struct
>> domain *d, vaddr_t va,
>>  unsigned long irq_flags;
>>
>>  local_irq_save(irq_flags);
>> -p2m_load_VTTBR(d);
>> +
>> +if ( altp2m_active(d) )
>> +p2m_load_altp2m_VTTBR(v);
>> +else
>> +p2m_load_VTTBR(d);
>>
>>  rc = gvirt_to_maddr(va, , flags);
>>
>> -p2m_load_VTTBR(current->domain);
>> +if ( altp2m_active(current->domain) )
>> +p2m_load_altp2m_VTTBR(current);
>> +else
>> +p2m_load_VTTBR(current->domain);
>> +
> 
> This could be abstracted with a new helper to load the VTTBR for a given
> vCPU.
> 

For my next patch series, I will think about an abstraction of the
function p2m_load[_altp2m]_VTTBR or a merge of both functions into one,
as discussed in path #11. Thank you.

>>  local_irq_restore(irq_flags);
>>  }
>>  else
>> -{
>>  rc = gvirt_to_maddr(va, , flags);
>> -}
>>
>>  if ( rc )
>>  goto err;
> 
> Regards,
> 

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH 11/18] arm/altp2m: Make flush_tlb_domain ready for altp2m.

[Sergej Proskurin]

Hi Julien,

On 07/05/2016 05:37 PM, Julien Grall wrote:
> 
> 
> On 05/07/16 15:48, Sergej Proskurin wrote:
>> On 07/04/2016 10:32 PM, Julien Grall wrote:
>>> On 04/07/2016 12:45, Sergej Proskurin wrote:
 +p2m_load_altp2m_VTTBR(n);
 +else
 +p2m_load_VTTBR(n->domain);
 +
   isb();

   if ( is_32bit_domain(n->domain) )
 @@ -119,22 +154,42 @@ void p2m_restore_state(struct vcpu *n)
   void flush_tlb_domain(struct domain *d)
   {
   unsigned long flags = 0;
 +struct vcpu *v = NULL;

 -/* Update the VTTBR if necessary with the domain d. In this case,
 - * it's only necessary to flush TLBs on every CPUs with the
 current VMID
 - * (our domain).
 +/*
 + * Update the VTTBR if necessary with the domain d. In this
 case, it is only
 + * necessary to flush TLBs on every CPUs with the current VMID
 (our
 + * domain).
*/
   if ( d != current->domain )
   {
   local_irq_save(flags);
 -p2m_load_VTTBR(d);
 -}

 -flush_tlb();
 +/* If altp2m is active, update VTTBR and flush TLBs of every
 VCPU */
 +if ( altp2m_active(d) )
 +{
 +for_each_vcpu( d, v )
 +{
 +p2m_load_altp2m_VTTBR(v);
 +flush_tlb();
 +}
 +}
 +else
 +{
 +p2m_load_VTTBR(d);
 +flush_tlb();
 +}
>>>
>>> Why do you need to do a such things? If the VMID is the same, a single
>>> call to flush_tlb() will nuke all the entries for the given TLBs.
>>>
>>> If the VMID is not shared, then I am not even sure why you would need
>>> to flush the TLBs for all the altp2ms.
>>>
>>
>> If the VMID is shared between multiple views and we would change one
>> entry in one specific view, we might reuse an entry that is not part of
>> the currently active altp2m view of the domain. And even if we assign
>> unique VMIDs to the individual altp2m views (as discussed in patch #04),
>> as far as I understand, we will still need to flush the mappings of all
>> altp2ms at this point because (AFAIK) changes in individual altp2m views
>> will still need to be propagated to the TLBs. Please correct me, if I am
>> wrong at this point.
> 
> You seem to be really confused how TLB flush instructions work on ARM.
> The function flush_tlb() will flush TLBs on all the processor for the
> current VMID. If the VMID is shared, then calling N-times the flush with
> the same VMID will just be a waste of processor cycle.
> 

True, you are right. I was confusing things, sorry. Thank you for
putting that straight.

> Now, if the VMID is not shared (and based on your current series):
> flush_tlb_domain is called in two places:
>- p2m_alloc_table
>- apply_p2m_changes
> 
> For the former, it allocates root table for a specific p2m. For the
> latter, the changes is only done for a specific p2m, and those changes
> are currently not replicated in all the p2ms. So flushing the TLBs for
> each altp2m view do not seem useful here too.
> 

I agree on this point as well. However, we should maybe think of another
name for flush_tlb_domain. Especially, if we do not flush the entire
domain (including all currently active altp2m views). What do you think?

Also, we would need another flushing routine that takes a specific p2m
as argument so that its VTTBR can be considered while flushing the TLBs.

>>
>>> I have looked to Xen with this series applied and noticed that when
>>> you remove a page from the hostp2m, the mapping in the altp2m is not
>>> removed. So the guest may use a page that would have been freed
>>> previously. Did I miss something?
>>>
>>
>> When altp2m is active, the hostp2m is not used. All changes are applied
>> directly to the individual altp2m views. As far as I know, the only
>> situations, where a mapping is removed from a specific p2m view is in
>> the functions unmap_regions_rw_cache, unmap_mmio_regions, and
>> guest_physmap_remove_page. Each one of these functions provide, however
>> the hostp2m to the function apply_p2m_changes, where the mapping is
>> eventually removed. So, we definitely remove mappings from the hostp2m.
>> However, these would not be removed from the associated altp2m views.
>>
>> Can you state a scenario, when and why pages might need to be removed at
>> run time from the hostp2m? In that case, maybe it would make sense to
>> extend the three functions (unmap_regions_rw_cache, unmap_mmio_regions,
>> and guest_physmap_remove_page) to additionally remove the mappings from
>> all available altp2m views?
> 
> All the functions, you mentioned can be called after the domain has been
> created. If you grep guest_physmap_remove_page in the code source, you
> will find that it is used to unmap grant entry from the memory (see
> 

Re: [Xen-devel] [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps

[Razvan Cojocaru]

On 07/05/16 21:37, Tamas K Lengyel wrote:
> The function vm_event_monitor_traps actually belongs in the monitor subsystem.
> As part of this patch we fix the sync input's type to bool_t to match how
> the callers use it.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Razvan Cojocaru 
> ---
>  xen/arch/x86/hvm/monitor.c |  7 ---
>  xen/common/monitor.c   | 44 +++-
>  xen/common/vm_event.c  | 45 -
>  xen/include/xen/monitor.h  |  6 +-
>  xen/include/xen/vm_event.h |  6 --
>  5 files changed, 52 insertions(+), 56 deletions(-)

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

[Xen-devel] [PATCH v1 18/20] libxl/acpi: Add ACPI e820 entry

[Boris Ostrovsky]

Add entry for ACPI tables created for PVHv2 guests to e820 map.

Signed-off-by: Boris Ostrovsky 
---

New patch

 tools/libxc/include/xc_dom.h |4 
 tools/libxl/libxl_dom.c  |8 
 tools/libxl/libxl_x86.c  |   11 +++
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6cb10c4..ec2da14 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -102,6 +102,10 @@ struct xc_dom_image {
 xen_vaddr_t virt_alloc_end;
 xen_vaddr_t bsd_symtab_start;
 
+/* ACPI tables (PVHv2 only) */
+xen_pfn_t acpi_pfn;
+xen_pfn_t acpi_pages;
+
 /*
  * initrd parameters as specified in start_info page
  * Depending on capabilities of the booted kernel this may be a virtual
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ec29060..ccc41b4 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1063,16 +1063,16 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
 }
 
+rc = libxl__build_dom(gc, domid, info, state, dom);
+if (rc != 0)
+goto out;
+
 rc = libxl__arch_domain_construct_memmap(gc, d_config, domid, dom);
 if (rc != 0) {
 LOG(ERROR, "setting domain memory map failed");
 goto out;
 }
 
-rc = libxl__build_dom(gc, domid, info, state, dom);
-if (rc != 0)
-goto out;
-
 rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
>store_mfn, state->console_port,
>console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 46cfafb..32ce1d2 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -503,6 +503,10 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 if (highmem_size)
 e820_entries++;
 
+/* PVHv2's ACPI tables */
+if (dom->acpi_pages)
+e820_entries++;
+
 if (e820_entries >= E820MAX) {
 LOG(ERROR, "Ooops! Too many entries in the memory map!");
 rc = ERROR_INVAL;
@@ -528,6 +532,13 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 nr++;
 }
 
+if (dom->acpi_pages) {
+e820[nr].addr = dom->acpi_pfn << XC_DOM_PAGE_SHIFT(dom);
+e820[nr].size = dom->acpi_pages << XC_DOM_PAGE_SHIFT(dom);
+e820[nr].type = E820_ACPI;
+nr++;
+}
+
 /* High memory */
 if (highmem_size) {
 e820[nr].addr = ((uint64_t)1 << 32);
-- 
1.7.1


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748

version targeted for testing:
 ovmf e58f1ae5c9689200865cf4fdd7d6e8a9d28e3cf3
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   41 days
Failing since 94750  2016-05-25 03:43:08 Z   41 days   92 attempts
Testing same since96675  2016-07-05 13:25:43 Z0 days1 attempts


People who touched revisions under test:
  Anandakrishnan Loganathan 
  Ard Biesheuvel 
  Bret Barkelew 
  Bruce Cran 
  Bruce Cran 
  Chao Zhang 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  david wei 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Evgeny Yakovlev 
  Feng Tian 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Li 
  Gary Lin 
  Giri P Mudusuru 
  Hao Wu 
  Hegde Nagaraj P 
  hegdenag 
  Heyi Guo 
  Jan D?bro? 
  Jan Dabros 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Joe Zhou 
  Jordan Justen 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Lu, ShifeiX A 
  lushifex 
  Marcin Wojtas 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Qiu Shumin 
  Ruiyu Ni 
  Ryan Harkin 
  Sami Mujawar 
  Satya Yarlagadda 
  Shannon Zhao 
  Sriram Subramanian 
  Star Zeng 
  Sunny Wang 
  Tapan Shah 
  Thomas Palmer 
  Yarlagadda, Satya P 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

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



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.

(No revision log; it would be 8275 lines long.)

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

[Xen-devel] [PATCH v1 00/20] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

This is V1 of the series posted earlier as an RFC

The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing 
existing
hvmloader's ACPI builder code. The builder is provided as a library in 
tools/libacpi.

Main changes from RFC are:
* Move toolstack code that loads the tables into PVHv2 guest from libxc to libxl
* Don't provide the builder to hypervisor as we didn't find a user for that (at 
least so far)
* Update e820 map for PVHv2 guests when ACPI tables are loaded
* Don't set HW_REDUCED_ACPI flags: this flag is only available starting with 
ACPI v5
* Separate ACPI-specific definition from libacpi definitions (i.e. acpi2_0.h vs 
libacpi.h)
* Add Processor objects to PVHv2's AML
* Separate out ACPI INFO description into a separate ASL file
* Specify ACPI INFO and tables' addresses in callers' code (not in acpi2_0.h)
* Build ASL/C files in targets' directories (Jan suggested making symlinks, 
this is slightly
  different but serves similar goal of preventing paralell make from making a 
mess of targets)
* Rework include files (x86.h), make callers specify include file that defines 
standard tools
  (see for example patch 13)
* Reorder some patches to decrease code churn

Other changes are described in patches (given number of changes I may have 
missed
mentioning some).

Boris Ostrovsky (20):
  hvmloader: Provide hvmloader_acpi_build_tables()
  acpi/hvmloader: Move acpi_info initialization out of ACPI code
  acpi/hvmloader: Initialize vm_gid data outside ACPI code
  acpi/hvmloader: Decide which SSDTs to install in hvmloader
  acpi/hvmloader: Move passthrough initialization from ACPI code
  acpi/hvmloader: Collect processor and NUMA info in hvmloader
  acpi/hvmloader: Set TIS header address in hvmloader
  acpi/hvmloader: Make providing IOAPIC in MADT optional
  acpi/hvmloader: Build WAET optionally
  acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory
ops
  acpi/hvmloader: Translate all addresses when assigning addresses in
ACPI tables
  acpi/hvmloader: Link ACPI object files directly
  acpi/hvmloader: Include file/paths adjustments
  acpi: Move ACPI code to tools/libacpi
  x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated
  x86: Allow LAPIC-only emulation_flags for HVM guests
  libacpi: Build DSDT for PVH guests
  libxl/acpi: Add ACPI e820 entry
  libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests
  libxl/acpi: Build ACPI tables for HVMlite guests

 .gitignore|   12 +-
 tools/firmware/hvmloader/Makefile |   20 +-
 tools/firmware/hvmloader/acpi/Makefile|   72 ---
 tools/firmware/hvmloader/acpi/README  |   24 -
 tools/firmware/hvmloader/acpi/acpi2_0.h   |  473 --
 tools/firmware/hvmloader/acpi/build.c |  648 -
 tools/firmware/hvmloader/acpi/dsdt.asl|  480 --
 tools/firmware/hvmloader/acpi/mk_dsdt.c   |  489 ---
 tools/firmware/hvmloader/acpi/ssdt_pm.asl |  421 
 tools/firmware/hvmloader/acpi/ssdt_s3.asl |   31 --
 tools/firmware/hvmloader/acpi/ssdt_s4.asl |   31 --
 tools/firmware/hvmloader/acpi/ssdt_tpm.asl|   30 --
 tools/firmware/hvmloader/acpi/static_tables.c |  170 ---
 tools/firmware/hvmloader/config.h |8 +-
 tools/firmware/hvmloader/hvmloader.c  |3 +-
 tools/firmware/hvmloader/mp_tables.c  |1 +
 tools/firmware/hvmloader/ovmf.c   |4 +-
 tools/firmware/hvmloader/pci.c|1 +
 tools/firmware/hvmloader/pir.c|1 +
 tools/firmware/hvmloader/rombios.c|4 +-
 tools/firmware/hvmloader/seabios.c|5 +-
 tools/firmware/hvmloader/smp.c|1 +
 tools/firmware/hvmloader/util.c   |   94 
 tools/firmware/hvmloader/util.h   |4 +
 tools/libacpi/Makefile|   87 
 tools/libacpi/README  |   33 ++
 tools/libacpi/acpi2_0.h   |  462 ++
 tools/libacpi/build.c |  613 +++
 tools/libacpi/dsdt.asl|  460 ++
 tools/libacpi/dsdt_acpi_info.asl  |   23 +
 tools/libacpi/libacpi.h   |  128 +
 tools/libacpi/mk_dsdt.c   |  499 +++
 tools/libacpi/ssdt_pm.asl |  421 
 tools/libacpi/ssdt_s3.asl |   31 ++
 tools/libacpi/ssdt_s4.asl |   31 ++
 tools/libacpi/ssdt_tpm.asl|   30 ++
 tools/libacpi/static_tables.c |  170 +++
 tools/libacpi/x86.h   |   38 ++
 tools/libxc/include/xc_dom.h  |4 +
 tools/libxl/Makefile  |   19 +-
 tools/libxl/libxl_arch.h  |3 +
 tools/libxl/libxl_dom.c 

[Xen-devel] [PATCH v1 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
 tools/firmware/hvmloader/acpi/build.c   |   68 +--
 tools/firmware/hvmloader/acpi/libacpi.h |1 +
 tools/firmware/hvmloader/util.c |2 +-
 3 files changed, 39 insertions(+), 32 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 94b46c1..8780984 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -81,43 +81,49 @@ static struct acpi_20_madt *construct_madt(struct 
acpi_config *config)
 madt->lapic_addr = LAPIC_BASE_ADDRESS;
 madt->flags  = ACPI_PCAT_COMPAT;
 
-intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
-for ( i = 0; i < 16; i++ )
+if ( config->table_flags & ACPI_BUILD_IOAPIC )
 {
-memset(intsrcovr, 0, sizeof(*intsrcovr));
-intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
-intsrcovr->length = sizeof(*intsrcovr);
-intsrcovr->source = i;
-
-if ( i == 0 )
-{
-/* ISA IRQ0 routed to IOAPIC GSI 2. */
-intsrcovr->gsi= 2;
-intsrcovr->flags  = 0x0;
-}
-else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
+for ( i = 0; i < 16; i++ )
 {
-/* PCI: active-low level-triggered. */
-intsrcovr->gsi= i;
-intsrcovr->flags  = 0xf;
-}
-else
-{
-/* No need for a INT source override structure. */
-continue;
+memset(intsrcovr, 0, sizeof(*intsrcovr));
+intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
+intsrcovr->length = sizeof(*intsrcovr);
+intsrcovr->source = i;
+
+if ( i == 0 )
+{
+/* ISA IRQ0 routed to IOAPIC GSI 2. */
+intsrcovr->gsi= 2;
+intsrcovr->flags  = 0x0;
+}
+else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+{
+/* PCI: active-low level-triggered. */
+intsrcovr->gsi= i;
+intsrcovr->flags  = 0xf;
+}
+else
+{
+/* No need for a INT source override structure. */
+continue;
+}
+
+intsrcovr++;
 }
 
-intsrcovr++;
-}
+io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
+memset(io_apic, 0, sizeof(*io_apic));
+io_apic->type= ACPI_IO_APIC;
+io_apic->length  = sizeof(*io_apic);
+io_apic->ioapic_id   = IOAPIC_ID;
+io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
 
-io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
-memset(io_apic, 0, sizeof(*io_apic));
-io_apic->type= ACPI_IO_APIC;
-io_apic->length  = sizeof(*io_apic);
-io_apic->ioapic_id   = IOAPIC_ID;
-io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
+lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
+}
+else
+lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
-lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
 config->ainfo.nr_cpus =config-> hvminfo->nr_vcpus;
 config->ainfo.madt_lapic0_addr = (uint32_t)lapic;
 for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 75874ec..86f19b9 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -35,6 +35,7 @@
 #define ACPI_BUILD_SSDT_S3(1<<1)
 #define ACPI_BUILD_SSDT_S4(1<<2)
 #define ACPI_BUILD_TCPA   (1<<3)
+#define ACPI_BUILD_IOAPIC (1<<4)
 
 #pragma pack ()
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 9f9c93b..5aecf7b 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -914,7 +914,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_BUILD_SSDT_S4;
 
-config->table_flags |= ACPI_BUILD_TCPA;
+config->table_flags |= (ACPI_BUILD_TCPA | ACPI_BUILD_IOAPIC);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.7.1


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

[Xen-devel] [PATCH v1 13/20] acpi/hvmloader: Include file/paths adjustments

[Boris Ostrovsky]

In prepearation to moving acpi sources into generally available
libacpi:

1. Move certain x86-specific definitions into acpi's x86.h
2. Modify include files serach paths to point to acpi
3. Macro-ise include file for build.c that defines various
   utilities used by that file. Users of libacpi will be expected
   to define this macro when compiling build.c

Signed-off-by: Boris Ostrovsky 
---

Changes in v1:
* Pass build.c include file that declates all standard utilities (printf. 
strcmp etc)
  as DSTDUTILS macro

x86-specific definitions are kept locally in x86.h. I wonder, however, whether 
this
should go somewhere in xen/include/public/. See, for example, patch 19
that demonstrates that having x86.h live in libacpi.h may not be such a great 
idea.

 tools/firmware/hvmloader/Makefile |3 +-
 tools/firmware/hvmloader/acpi/README  |   17 +++---
 tools/firmware/hvmloader/acpi/build.c |5 +--
 tools/firmware/hvmloader/acpi/x86.h   |   38 +
 tools/firmware/hvmloader/config.h |6 -
 tools/firmware/hvmloader/hvmloader.c  |3 +-
 tools/firmware/hvmloader/mp_tables.c  |1 +
 tools/firmware/hvmloader/ovmf.c   |2 +-
 tools/firmware/hvmloader/pci.c|1 +
 tools/firmware/hvmloader/pir.c|1 +
 tools/firmware/hvmloader/rombios.c|2 +-
 tools/firmware/hvmloader/seabios.c|4 +-
 tools/firmware/hvmloader/smp.c|1 +
 tools/firmware/hvmloader/util.c   |5 ++-
 14 files changed, 68 insertions(+), 21 deletions(-)
 create mode 100644 tools/firmware/hvmloader/acpi/x86.h

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 043da50..920b0d0 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -99,7 +99,8 @@ smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c build.c 
static_tables.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES))
-$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"../util.h\"
+CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)/
 vpath static_tables.c $(ACPI_PATH)/
 OBJS += $(ACPI_OBJS)
diff --git a/tools/firmware/hvmloader/acpi/README 
b/tools/firmware/hvmloader/acpi/README
index 210d5ba..1d603ea 100644
--- a/tools/firmware/hvmloader/acpi/README
+++ b/tools/firmware/hvmloader/acpi/README
@@ -1,11 +1,19 @@
-ACPI Table for domain firmware
+ACPI builder for domain firmware
 
 
-INSTALL
+BUILDING ACPI
 -
-Simply make is OK.
-# make 
+Users of ACPI builder are expected to provide an include file that defines
+the following:
+* strncpy
+* printf
+* NULL
+* test_bit
+* offsetof
 
+When compiling build.c, the name of this include file should be given to
+compiler as -DSTDUTILS=\"\". See tools/firmware/hvmloader/Makefile
+for an example.
 
 Note on DSDT Table
 --
@@ -22,3 +30,4 @@ DSDT compiler "iasl" is needed. By default, it will be 
downloaded
 using wget in Makefile. if it failed, please download manually from 
 http://developer.intel.com/technology/iapc/acpi/downloads.htm. 
 then compile and install iasl
+
diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 4b0302c..290f005 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -15,15 +15,14 @@
  * this program; If not, see .
  */
 
+#include STDUTILS
 #include "acpi2_0.h"
 #include "libacpi.h"
 #include "ssdt_s3.h"
 #include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
-#include "../config.h"
-#include "../util.h"
-#include "../vnuma.h"
+#include "x86.h"
 #include 
 #include 
 
diff --git a/tools/firmware/hvmloader/acpi/x86.h 
b/tools/firmware/hvmloader/acpi/x86.h
new file mode 100644
index 000..21cad0d
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/x86.h
@@ -0,0 +1,38 @@
+/**
+ * x86.h
+ *
+ * x86-specific interfaces used by ACPI builder and its callers
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR 

[Xen-devel] [PATCH v1 03/20] acpi/hvmloader: Initialize vm_gid data outside ACPI code

[Boris Ostrovsky]

This way ACPI code won't use xenstore-read() and hvm_param_set()
which are private to hvmloader.

Signed-off-by: Boris Ostrovsky 
---

This is one patch that modifies config->ainfo.vm_gid_addr in build.c, with that 
change
consumed by the caller (when it sets VM_PARAM_VM_GENERATION_ID_ADDR). We could
make the caller fill out config->ainfo.vm_gid_addr to avoid this as suggested 
by Jan but
I think logically this belongs in the ACPI builder.

 tools/firmware/hvmloader/acpi/build.c   |   30 +++---
 tools/firmware/hvmloader/acpi/libacpi.h |2 ++
 tools/firmware/hvmloader/util.c |   16 
 3 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 1092b4e..ca9727f 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -446,32 +446,24 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
  *
  * Return 0 if memory failure, != 0 if success
  */
-static int new_vm_gid(struct acpi_info *acpi_info)
+static int new_vm_gid(struct acpi_config *config)
 {
-uint64_t vm_gid[2], *buf;
-const char * s;
-char *end;
-
-acpi_info->vm_gid_addr = 0;
-
-/* read ID and check for 0 */
-s = xenstore_read("platform/generation-id", "0:0");
-vm_gid[0] = strtoll(s, , 0);
-vm_gid[1] = 0;
-if ( end && end[0] == ':' )
-vm_gid[1] = strtoll(end+1, NULL, 0);
-if ( !vm_gid[0] && !vm_gid[1] )
+uint64_t *buf;
+
+config->ainfo.vm_gid_addr = 0;
+
+/* check for 0 ID*/
+if ( !config->vm_gid[0] && !config->vm_gid[1] )
 return 1;
 
 /* copy to allocate BIOS memory */
-buf = (uint64_t *) mem_alloc(sizeof(vm_gid), 8);
+buf = (uint64_t *) mem_alloc(sizeof(config->vm_gid), 8);
 if ( !buf )
 return 0;
-memcpy(buf, vm_gid, sizeof(vm_gid));
+memcpy(buf, config->vm_gid, sizeof(config->vm_gid));
 
 /* set into ACPI table and HVM param the address */
-acpi_info->vm_gid_addr = virt_to_phys(buf);
-hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, acpi_info->vm_gid_addr);
+config->ainfo.vm_gid_addr = virt_to_phys(buf);
 
 return 1;
 }
@@ -593,7 +585,7 @@ void acpi_build_tables(struct acpi_config *config)
  offsetof(struct acpi_20_rsdp, extended_checksum),
  sizeof(struct acpi_20_rsdp));
 
-if ( !new_vm_gid(>ainfo) )
+if ( !new_vm_gid(config) )
 goto oom;
 
 *(struct acpi_info *)config->ainfop = config->ainfo;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 098eee1..aa19972 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -52,6 +52,8 @@ struct acpi_config {
 const unsigned char *dsdt_15cpu;
 unsigned int dsdt_15cpu_len;
 
+uint64_t vm_gid[2];
+
 /* May have some fields updated by acpi_build_table() */
 struct acpi_info ainfo;
 /*
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 4293efa..e62052b 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Check whether there exists overlap in the specified memory range.
@@ -861,6 +862,8 @@ int hpet_exists(unsigned long hpet_base)
 void hvmloader_acpi_build_tables(struct acpi_config *config,
  unsigned int physical)
 {
+const char *s;
+
 /* Allocate and initialise the acpi info area. */
 mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
 
@@ -876,10 +879,23 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 config->ainfo.pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
 }
 
+s = xenstore_read("platform/generation-id", "0:0");
+if ( s )
+{
+char *end;
+
+config->vm_gid[0] = strtoll(s, , 0);
+config->vm_gid[1] = 0;
+if ( end && end[0] == ':' )
+config->vm_gid[1] = strtoll(end+1, NULL, 0);
+}
+
 config->rsdp = physical;
 config->ainfop = ACPI_INFO_PHYSICAL_ADDRESS;
 
 acpi_build_tables(config);
+
+hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->ainfo.vm_gid_addr);
 }
 
 /*
-- 
1.7.1


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

[Xen-devel] [PATCH v1 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code

[Boris Ostrovsky]

Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read()

Signed-off-by: Boris Ostrovsky 
---

Changes in v1:
* Rename acpi_pt_length/addr to pt_length/addr

 tools/firmware/hvmloader/acpi/build.c   |   22 +++---
 tools/firmware/hvmloader/acpi/libacpi.h |5 +
 tools/firmware/hvmloader/util.c |   11 +++
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 0bcb185..95f6cf8 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -269,10 +269,10 @@ static struct acpi_20_slit *construct_slit(void)
 }
 
 static int construct_passthrough_tables(unsigned long *table_ptrs,
-int nr_tables)
+int nr_tables,
+struct acpi_config *config)
 {
-const char *s;
-uint8_t *acpi_pt_addr;
+unsigned long acpi_pt_addr;
 uint32_t acpi_pt_length;
 struct acpi_header *header;
 int nr_added;
@@ -280,19 +280,11 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 uint32_t total = 0;
 uint8_t *buffer;
 
-s = xenstore_read(HVM_XS_ACPI_PT_ADDRESS, NULL);
-if ( s == NULL )
-return 0;
-
-acpi_pt_addr = (uint8_t*)(uint32_t)strtoll(s, NULL, 0);
-if ( acpi_pt_addr == NULL )
-return 0;
-
-s = xenstore_read(HVM_XS_ACPI_PT_LENGTH, NULL);
-if ( s == NULL )
+if ( config->pt.pt_addr == 0 )
 return 0;
 
-acpi_pt_length = (uint32_t)strtoll(s, NULL, 0);
+acpi_pt_addr = config->pt.pt_addr;
+acpi_pt_length = config->pt.pt_length;
 
 for ( nr_added = 0; nr_added < nr_max; nr_added++ )
 {
@@ -428,7 +420,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* Load any additional tables passed through. */
-nr_tables += construct_passthrough_tables(table_ptrs, nr_tables);
+nr_tables += construct_passthrough_tables(table_ptrs, nr_tables, config);
 
 table_ptrs[nr_tables] = 0;
 return nr_tables;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 5454bc2..05e6c69 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -61,6 +61,11 @@ struct acpi_config {
 
 uint32_t table_flags;
 
+struct {
+uint32_t pt_addr;
+uint32_t pt_length;
+} pt;
+
 /* May have some fields updated by acpi_build_table() */
 struct acpi_info ainfo;
 /*
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 1ccb38c..1864d7a 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -895,6 +896,16 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 config->vm_gid[1] = strtoll(end+1, NULL, 0);
 }
 
+s = xenstore_read(HVM_XS_ACPI_PT_ADDRESS, NULL);
+if ( s )
+{
+config->pt.pt_addr = strtoll(s, NULL, 0);
+
+s = xenstore_read(HVM_XS_ACPI_PT_LENGTH, NULL);
+if ( s  )
+config->pt.pt_length = strtoll(s, NULL, 0);
+}
+
 if ( battery_port_exists() )
 config->table_flags |= ACPI_BUILD_SSDT_PM;
 if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1)  )
-- 
1.7.1


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

[Xen-devel] [PATCH v1 10/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops

[Boris Ostrovsky]

Components that wish to use ACPI builder will need to provide their own
mem_alloc() and virt_to_phys() routines. Pointers to these routines will
be passed to the builder as memory ops.

Signed-off-by: Boris Ostrovsky 
---

Changes in v1:
* Keep memory ops seprate from acpi_config, in struct acpi_context.

Jan requested adding a free() op to struct acpi_mem_ops. I couldn't see who 
might want to
use those. The builder uses (should use) mem_alloc() to allocate memory for 
tables, not as a
general-purpose allocator.

 tools/firmware/hvmloader/acpi/build.c   |   87 +--
 tools/firmware/hvmloader/acpi/libacpi.h |9 +++-
 tools/firmware/hvmloader/util.c |   16 +-
 3 files changed, 71 insertions(+), 41 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 570d26f..0adb3d6 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -54,7 +54,8 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(struct acpi_config *config)
+static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
+   struct acpi_config *config)
 {
 struct acpi_20_madt   *madt;
 struct acpi_20_madt_intsrcovr *intsrcovr;
@@ -67,7 +68,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_config 
*config)
 sz += sizeof(struct acpi_20_madt_ioapic);
 sz += sizeof(struct acpi_20_madt_lapic) * config->hvminfo->nr_vcpus;
 
-madt = mem_alloc(sz, 16);
+madt = ctxt->mem_ops.alloc(ctxt, sz, 16);
 if (!madt) return NULL;
 
 memset(madt, 0, sizeof(*madt));
@@ -147,11 +148,12 @@ static struct acpi_20_madt *construct_madt(struct 
acpi_config *config)
 return madt;
 }
 
-static struct acpi_20_hpet *construct_hpet(void)
+static struct acpi_20_hpet *construct_hpet(struct acpi_ctxt *ctxt,
+   struct acpi_config *config)
 {
 struct acpi_20_hpet *hpet;
 
-hpet = mem_alloc(sizeof(*hpet), 16);
+hpet = ctxt->mem_ops.alloc(ctxt, sizeof(*hpet), 16);
 if (!hpet) return NULL;
 
 memset(hpet, 0, sizeof(*hpet));
@@ -170,11 +172,12 @@ static struct acpi_20_hpet *construct_hpet(void)
 return hpet;
 }
 
-static struct acpi_20_waet *construct_waet(void)
+static struct acpi_20_waet *construct_waet(struct acpi_ctxt *ctxt,
+   struct acpi_config *config)
 {
 struct acpi_20_waet *waet;
 
-waet = mem_alloc(sizeof(*waet), 16);
+waet = ctxt->mem_ops.alloc(ctxt, sizeof(*waet), 16);
 if (!waet) return NULL;
 
 memcpy(waet, , sizeof(*waet));
@@ -185,7 +188,8 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(struct acpi_config *config)
+static struct acpi_20_srat *construct_srat(struct acpi_ctxt *ctxt,
+   struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -197,7 +201,7 @@ static struct acpi_20_srat *construct_srat(struct 
acpi_config *config)
 size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
sizeof(*memory) * config->numa.nr_vmemranges;
 
-p = mem_alloc(size, 16);
+p = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !p )
 return NULL;
 
@@ -243,7 +247,8 @@ static struct acpi_20_srat *construct_srat(struct 
acpi_config *config)
 return srat;
 }
 
-static struct acpi_20_slit *construct_slit(struct acpi_config *config)
+static struct acpi_20_slit *construct_slit(struct acpi_ctxt *ctxt,
+   struct acpi_config *config)
 {
 struct acpi_20_slit *slit;
 unsigned int i, num, size;
@@ -251,7 +256,7 @@ static struct acpi_20_slit *construct_slit(struct 
acpi_config *config)
 num = config->numa.nr_vnodes * config->numa.nr_vnodes;
 size = sizeof(*slit) + num * sizeof(uint8_t);
 
-slit = mem_alloc(size, 16);
+slit = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !slit )
 return NULL;
 
@@ -275,7 +280,8 @@ static struct acpi_20_slit *construct_slit(struct 
acpi_config *config)
 return slit;
 }
 
-static int construct_passthrough_tables(unsigned long *table_ptrs,
+static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
+unsigned long *table_ptrs,
 int nr_tables,
 struct acpi_config *config)
 {
@@ -300,7 +306,7 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 
 header = (struct acpi_header*)acpi_pt_addr;
 
-buffer = mem_alloc(header->length, 16);
+buffer = ctxt->mem_ops.alloc(ctxt, header->length, 16);
 if ( buffer == NULL )
 break;
 memcpy(buffer, header, header->length);

[Xen-devel] [PATCH v1 09/20] acpi/hvmloader: Build WAET optionally

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
 tools/firmware/hvmloader/acpi/build.c   |9 ++---
 tools/firmware/hvmloader/acpi/libacpi.h |1 +
 tools/firmware/hvmloader/util.c |3 ++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 8780984..570d26f 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -342,9 +342,12 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* WAET. */
-waet = construct_waet();
-if (!waet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+if ( config->table_flags & ACPI_BUILD_WAET )
+{
+waet = construct_waet();
+if ( !waet ) return -1;
+table_ptrs[nr_tables++] = (unsigned long)waet;
+}
 
 if ( config->table_flags & ACPI_BUILD_SSDT_PM )
 {
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 86f19b9..b052eab 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -36,6 +36,7 @@
 #define ACPI_BUILD_SSDT_S4(1<<2)
 #define ACPI_BUILD_TCPA   (1<<3)
 #define ACPI_BUILD_IOAPIC (1<<4)
+#define ACPI_BUILD_WAET   (1<<5)
 
 #pragma pack ()
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 5aecf7b..08328f8 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -914,7 +914,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_BUILD_SSDT_S4;
 
-config->table_flags |= (ACPI_BUILD_TCPA | ACPI_BUILD_IOAPIC);
+config->table_flags |= (ACPI_BUILD_TCPA | ACPI_BUILD_IOAPIC |
+ACPI_BUILD_WAET);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.7.1


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

[Xen-devel] [PATCH v1 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code

[Boris Ostrovsky]

acpi_info can be initialized by hvmloader itself. Now ACPI code
doesn't need to use hvmloader-private variables/routines such as
uart_exists(), lpt_exists() etc.

Signed-off-by: Boris Ostrovsky 
---
Changes in v1:
* Create libacpi.h for libacpi interface definitions
* Move RSDP struct acpi_info pointers into struct acpi_config 

 tools/firmware/hvmloader/acpi/acpi2_0.h |   11 
 tools/firmware/hvmloader/acpi/build.c   |   48 +++---
 tools/firmware/hvmloader/acpi/libacpi.h |   80 +++
 tools/firmware/hvmloader/seabios.c  |1 +
 tools/firmware/hvmloader/util.c |   21 -
 5 files changed, 109 insertions(+), 52 deletions(-)
 create mode 100644 tools/firmware/hvmloader/acpi/libacpi.h

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h 
b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 78eb43d..ddcee74 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -449,17 +449,6 @@ struct acpi_20_slit {
 #define ACPI_2_0_SRAT_REVISION 0x01
 #define ACPI_2_0_SLIT_REVISION 0x01
 
-#pragma pack ()
-
-struct acpi_config {
-unsigned char *dsdt_anycpu;
-int dsdt_anycpu_len;
-unsigned char *dsdt_15cpu;
-int dsdt_15cpu_len;
-};
-
-void acpi_build_tables(struct acpi_config *config, unsigned int physical);
-
 #endif /* _ACPI_2_0_H_ */
 
 /*
diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 1f7103e..1092b4e 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -16,6 +16,7 @@
  */
 
 #include "acpi2_0.h"
+#include "libacpi.h"
 #include "ssdt_s3.h"
 #include "ssdt_s4.h"
 #include "ssdt_tpm.h"
@@ -38,24 +39,6 @@ extern struct acpi_20_fadt Fadt;
 extern struct acpi_20_facs Facs;
 extern struct acpi_20_waet Waet;
 
-/*
- * Located at ACPI_INFO_PHYSICAL_ADDRESS.
- *
- * This must match the Field("BIOS") definition in the DSDT.
- */
-struct acpi_info {
-uint8_t  com1_present:1;/* 0[0] - System has COM1? */
-uint8_t  com2_present:1;/* 0[1] - System has COM2? */
-uint8_t  lpt1_present:1;/* 0[2] - System has LPT1? */
-uint8_t  hpet_present:1;/* 0[3] - System has HPET? */
-uint16_t nr_cpus;   /* 2- Number of CPUs */
-uint32_t pci_min, pci_len;  /* 4, 8 - PCI I/O hole boundaries */
-uint32_t madt_csum_addr;/* 12   - Address of MADT checksum */
-uint32_t madt_lapic0_addr;  /* 16   - Address of first MADT LAPIC struct */
-uint32_t vm_gid_addr;   /* 20   - Address of VM generation id buffer */
-uint64_t pci_hi_min, pci_hi_len; /* 24, 32 - PCI I/O hole boundaries */
-};
-
 static void set_checksum(
 void *table, uint32_t checksum_offset, uint32_t length)
 {
@@ -358,7 +341,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* HPET. */
-if ( hpet_exists(ACPI_HPET_ADDRESS) )
+if ( info->hpet_present )
 {
 hpet = construct_hpet();
 if (!hpet) return -1;
@@ -493,9 +476,8 @@ static int new_vm_gid(struct acpi_info *acpi_info)
 return 1;
 }
 
-void acpi_build_tables(struct acpi_config *config, unsigned int physical)
+void acpi_build_tables(struct acpi_config *config)
 {
-struct acpi_info *acpi_info;
 struct acpi_20_rsdp *rsdp;
 struct acpi_20_rsdt *rsdt;
 struct acpi_20_xsdt *xsdt;
@@ -506,11 +488,6 @@ void acpi_build_tables(struct acpi_config *config, 
unsigned int physical)
 unsigned longsecondary_tables[ACPI_MAX_SECONDARY_TABLES];
 int  nr_secondaries, i;
 
-/* Allocate and initialise the acpi info area. */
-mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
-acpi_info = (struct acpi_info *)ACPI_INFO_PHYSICAL_ADDRESS;
-memset(acpi_info, 0, sizeof(*acpi_info));
-
 /*
  * Fill in high-memory data structures, starting at @buf.
  */
@@ -570,7 +547,8 @@ void acpi_build_tables(struct acpi_config *config, unsigned 
int physical)
  offsetof(struct acpi_header, checksum),
  sizeof(struct acpi_20_fadt));
 
-nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info);
+nr_secondaries = construct_secondary_tables(secondary_tables,
+>ainfo);
 if ( nr_secondaries < 0 )
 goto oom;
 
@@ -603,7 +581,7 @@ void acpi_build_tables(struct acpi_config *config, unsigned 
int physical)
 /*
  * Fill in low-memory data structures: acpi_info and RSDP.
  */
-rsdp = (struct acpi_20_rsdp *)physical;
+rsdp = (struct acpi_20_rsdp *)config->rsdp;
 
 memcpy(rsdp, , sizeof(struct acpi_20_rsdp));
 rsdp->rsdt_address = (unsigned long)rsdt;
@@ -615,20 +593,10 @@ void acpi_build_tables(struct acpi_config *config, 
unsigned int physical)
  offsetof(struct acpi_20_rsdp, extended_checksum),
  sizeof(struct acpi_20_rsdp));
 
-if ( 

[Xen-devel] [PATCH v1 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader

[Boris Ostrovsky]

No need for ACPI code to rely on hvm_info.

Signed-off-by: Boris Ostrovsky 
---

Changes in v1:
* Pass hvm_info_table pointer in acpi_config

 tools/firmware/hvmloader/acpi/build.c   |   53 ---
 tools/firmware/hvmloader/acpi/libacpi.h |   13 +++
 tools/firmware/hvmloader/util.c |9 +
 3 files changed, 49 insertions(+), 26 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 95f6cf8..d6e7798 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -54,7 +54,7 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(struct acpi_info *info)
+static struct acpi_20_madt *construct_madt(struct acpi_config *config)
 {
 struct acpi_20_madt   *madt;
 struct acpi_20_madt_intsrcovr *intsrcovr;
@@ -65,7 +65,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 sz  = sizeof(struct acpi_20_madt);
 sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
 sz += sizeof(struct acpi_20_madt_ioapic);
-sz += sizeof(struct acpi_20_madt_lapic) * hvm_info->nr_vcpus;
+sz += sizeof(struct acpi_20_madt_lapic) * config->hvminfo->nr_vcpus;
 
 madt = mem_alloc(sz, 16);
 if (!madt) return NULL;
@@ -118,9 +118,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
 
 lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
-info->nr_cpus = hvm_info->nr_vcpus;
-info->madt_lapic0_addr = (uint32_t)lapic;
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+config->ainfo.nr_cpus =config-> hvminfo->nr_vcpus;
+config->ainfo.madt_lapic0_addr = (uint32_t)lapic;
+for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
 lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
@@ -128,7 +128,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 /* Processor ID must match processor-object IDs in the DSDT. */
 lapic->acpi_processor_id = i;
 lapic->apic_id = LAPIC_ID(i);
-lapic->flags = (test_bit(i, hvm_info->vcpu_online)
+lapic->flags = (test_bit(i, config->hvminfo->vcpu_online)
 ? ACPI_LOCAL_APIC_ENABLED : 0);
 lapic++;
 }
@@ -136,7 +136,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
 set_checksum(madt, offsetof(struct acpi_header, checksum),
  madt->header.length);
-info->madt_csum_addr = (uint32_t)>header.checksum;
+config->ainfo.madt_csum_addr = (uint32_t)>header.checksum;
 
 return madt;
 }
@@ -179,7 +179,7 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(void)
+static struct acpi_20_srat *construct_srat(struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -188,8 +188,8 @@ static struct acpi_20_srat *construct_srat(void)
 void *p;
 unsigned int i;
 
-size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
-   sizeof(*memory) * nr_vmemranges;
+size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
+   sizeof(*memory) * config->numa.nr_vmemranges;
 
 p = mem_alloc(size, 16);
 if ( !p )
@@ -206,25 +206,26 @@ static struct acpi_20_srat *construct_srat(void)
 srat->table_revision  = ACPI_SRAT_TABLE_REVISION;
 
 processor = (struct acpi_20_srat_processor *)(srat + 1);
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
 {
 processor->type = ACPI_PROCESSOR_AFFINITY;
 processor->length   = sizeof(*processor);
-processor->domain   = vcpu_to_vnode[i];
+processor->domain   = config->numa.vcpu_to_vnode[i];
 processor->apic_id  = LAPIC_ID(i);
 processor->flags= ACPI_LOCAL_APIC_AFFIN_ENABLED;
 processor++;
 }
 
 memory = (struct acpi_20_srat_memory *)processor;
-for ( i = 0; i < nr_vmemranges; i++ )
+for ( i = 0; i < config->numa.nr_vmemranges; i++ )
 {
 memory->type  = ACPI_MEMORY_AFFINITY;
 memory->length= sizeof(*memory);
-memory->domain= vmemrange[i].nid;
+memory->domain= config->numa.vmemrange[i].nid;
 memory->flags = ACPI_MEM_AFFIN_ENABLED;
-memory->base_address  = vmemrange[i].start;
-memory->mem_length= vmemrange[i].end - vmemrange[i].start;
+memory->base_address  = config->numa.vmemrange[i].start;
+memory->mem_length= config->numa.vmemrange[i].end -
+config->numa.vmemrange[i].start;
 memory++;
 }
 
@@ -236,12 +237,12 @@ static struct 

[Xen-devel] [PATCH v1 07/20] acpi/hvmloader: Set TIS header address in hvmloader

[Boris Ostrovsky]

Users other than hvmloader may provide TIS address as virtual.

Signed-off-by: Boris Ostrovsky 
---

Changes in v1:
* Merged 'if' conditions to make the diff smaller

 tools/firmware/hvmloader/acpi/build.c   |9 -
 tools/firmware/hvmloader/acpi/libacpi.h |3 +++
 tools/firmware/hvmloader/config.h   |2 ++
 tools/firmware/hvmloader/util.c |4 
 4 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index d6e7798..94b46c1 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -317,7 +317,6 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 struct acpi_20_tcpa *tcpa;
 unsigned char *ssdt;
 static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
-uint16_t *tis_hdr;
 void *lasa;
 
 /* MADT. */
@@ -370,10 +369,10 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* TPM TCPA and SSDT. */
-tis_hdr = (uint16_t *)0xFED40F00;
-if ( (tis_hdr[0] == tis_signature[0]) &&
- (tis_hdr[1] == tis_signature[1]) &&
- (tis_hdr[2] == tis_signature[2]) )
+if ( (config->table_flags & ACPI_BUILD_TCPA) &&
+ (config->tis_hdr[0] == tis_signature[0]) &&
+ (config->tis_hdr[1] == tis_signature[1]) &&
+ (config->tis_hdr[2] == tis_signature[2]) )
 {
 ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 9d28ba7..75874ec 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -34,6 +34,7 @@
 #define ACPI_BUILD_SSDT_PM(1<<0)
 #define ACPI_BUILD_SSDT_S3(1<<1)
 #define ACPI_BUILD_SSDT_S4(1<<2)
+#define ACPI_BUILD_TCPA   (1<<3)
 
 #pragma pack ()
 
@@ -79,6 +80,8 @@ struct acpi_config {
 struct acpi_numa numa;
 struct hvm_info_table *hvminfo;
 
+uint16_t *tis_hdr;
+
 /* May have some fields updated by acpi_build_table() */
 struct acpi_info ainfo;
 /*
diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index b838cf9..c7460fb 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -55,6 +55,8 @@ extern struct bios_config ovmf_config;
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_END 0xfc00
 
+#define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
+
 extern unsigned long pci_mem_start, pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 020cf1d..9f9c93b 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -914,6 +914,10 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_BUILD_SSDT_S4;
 
+config->table_flags |= ACPI_BUILD_TCPA;
+
+config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
+
 config->numa.nr_vmemranges = nr_vmemranges;
 config->numa.nr_vnodes = nr_vnodes;
 config->numa.vcpu_to_vnode = vcpu_to_vnode;
-- 
1.7.1


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

[Xen-devel] [PATCH v1 04/20] acpi/hvmloader: Decide which SSDTs to install in hvmloader

[Boris Ostrovsky]

With that, xenstore_read() won't need to be done in ACPI code

Signed-off-by: Boris Ostrovsky 
---
 tools/firmware/hvmloader/acpi/build.c   |   20 +++-
 tools/firmware/hvmloader/acpi/libacpi.h |7 +++
 tools/firmware/hvmloader/util.c |   12 
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index ca9727f..0bcb185 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -54,11 +54,6 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static uint8_t battery_port_exists(void)
-{
-return (inb(0x88) == 0x1F);
-}
-
 static struct acpi_20_madt *construct_madt(struct acpi_info *info)
 {
 struct acpi_20_madt   *madt;
@@ -320,7 +315,7 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 }
 
 static int construct_secondary_tables(unsigned long *table_ptrs,
-  struct acpi_info *info)
+  struct acpi_config *config)
 {
 int nr_tables = 0;
 struct acpi_20_madt *madt;
@@ -335,13 +330,13 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 /* MADT. */
 if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
 {
-madt = construct_madt(info);
+madt = construct_madt(>ainfo);
 if (!madt) return -1;
 table_ptrs[nr_tables++] = (unsigned long)madt;
 }
 
 /* HPET. */
-if ( info->hpet_present )
+if ( config->ainfo.hpet_present )
 {
 hpet = construct_hpet();
 if (!hpet) return -1;
@@ -353,7 +348,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 if (!waet) return -1;
 table_ptrs[nr_tables++] = (unsigned long)waet;
 
-if ( battery_port_exists() )
+if ( config->table_flags & ACPI_BUILD_SSDT_PM )
 {
 ssdt = mem_alloc(sizeof(ssdt_pm), 16);
 if (!ssdt) return -1;
@@ -361,7 +356,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 table_ptrs[nr_tables++] = (unsigned long)ssdt;
 }
 
-if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1) )
+if ( config->table_flags & ACPI_BUILD_SSDT_S3 )
 {
 ssdt = mem_alloc(sizeof(ssdt_s3), 16);
 if (!ssdt) return -1;
@@ -371,7 +366,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 printf("S3 disabled\n");
 }
 
-if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
+if ( config->table_flags & ACPI_BUILD_SSDT_S4 )
 {
 ssdt = mem_alloc(sizeof(ssdt_s4), 16);
 if (!ssdt) return -1;
@@ -539,8 +534,7 @@ void acpi_build_tables(struct acpi_config *config)
  offsetof(struct acpi_header, checksum),
  sizeof(struct acpi_20_fadt));
 
-nr_secondaries = construct_secondary_tables(secondary_tables,
->ainfo);
+nr_secondaries = construct_secondary_tables(secondary_tables, config);
 if ( nr_secondaries < 0 )
 goto oom;
 
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index aa19972..5454bc2 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -28,6 +28,11 @@
 #ifndef __LIBACPI_H__
 #define __LIBACPI_H__
 
+/* Flags indicating which tables to build */
+#define ACPI_BUILD_SSDT_PM(1<<0)
+#define ACPI_BUILD_SSDT_S3(1<<1)
+#define ACPI_BUILD_SSDT_S4(1<<2)
+
 #pragma pack ()
 
 /*
@@ -54,6 +59,8 @@ struct acpi_config {
 
 uint64_t vm_gid[2];
 
+uint32_t table_flags;
+
 /* May have some fields updated by acpi_build_table() */
 struct acpi_info ainfo;
 /*
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index e62052b..1ccb38c 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -859,6 +859,11 @@ int hpet_exists(unsigned long hpet_base)
 return ((hpet_id >> 16) == 0x8086);
 }
 
+static uint8_t battery_port_exists(void)
+{
+return (inb(0x88) == 0x1F);
+}
+
 void hvmloader_acpi_build_tables(struct acpi_config *config,
  unsigned int physical)
 {
@@ -890,6 +895,13 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 config->vm_gid[1] = strtoll(end+1, NULL, 0);
 }
 
+if ( battery_port_exists() )
+config->table_flags |= ACPI_BUILD_SSDT_PM;
+if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1)  )
+config->table_flags |= ACPI_BUILD_SSDT_S3;
+if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
+config->table_flags |= ACPI_BUILD_SSDT_S4;
+
 config->rsdp = physical;
 config->ainfop = ACPI_INFO_PHYSICAL_ADDRESS;
 
-- 
1.7.1


___
Xen-devel mailing list

[Xen-devel] [PATCH v1 17/20] libacpi: Build DSDT for PVH guests

[Boris Ostrovsky]

PVH guests require DSDT with only ACPI INFO (Xen-specific) and Processor
objects. We separate ASL's ACPI INFO definition into dsdt_acpi_info.asl so
that it can be included in ASLs for both HVM and PVH2.

Signed-off-by: Boris Ostrovsky 
---

New patch

 tools/libacpi/Makefile   |   24 
 tools/libacpi/dsdt.asl   |   20 
 tools/libacpi/dsdt_acpi_info.asl |   23 +++
 tools/libacpi/mk_dsdt.c  |   10 ++
 4 files changed, 53 insertions(+), 24 deletions(-)
 create mode 100644 tools/libacpi/dsdt_acpi_info.asl

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index cc0dc31..4068d9a 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -20,7 +20,8 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
 # Sources to be generated
-C_SRC = $(ACPI_BUILD_DIR)/dsdt_anycpu.c $(ACPI_BUILD_DIR)/dsdt_15cpu.c  
$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.c
+C_SRC = $(ACPI_BUILD_DIR)/dsdt_anycpu.c $(ACPI_BUILD_DIR)/dsdt_15cpu.c 
+C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.c $(ACPI_BUILD_DIR)/dsdt_pvh.c
 H_SRC = $(ACPI_BUILD_DIR)/ssdt_s3.h $(ACPI_BUILD_DIR)/ssdt_s4.h 
$(ACPI_BUILD_DIR)/ssdt_pm.h $(ACPI_BUILD_DIR)/ssdt_tpm.h
 
 vpath iasl $(PATH)
@@ -36,13 +37,15 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
 $(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
$(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+   cat dsdt_acpi_info.asl >> $@
$(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+   cat dsdt_acpi_info.asl >> $@
$(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
 
 $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
@@ -53,6 +56,19 @@ $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
rm -f $*.aml $*.hex
cd $(CURDIR)
 
+$(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
+   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 2, \"Xen\", \"HVM\", 
0)\n{" > $@
+   cat dsdt_acpi_info.asl >> $@
+   $(MK_DSDT) --debug=$(debug) --maxcpu any --no-dm >> $@
+
+$(ACPI_BUILD_DIR)/dsdt_pvh.c: iasl $(ACPI_BUILD_DIR)/dsdt_pvh.asl
+   cd $(ACPI_BUILD_DIR)
+   iasl -vs -p $* -tc $(ACPI_BUILD_DIR)/dsdt_pvh.asl
+   sed -e 's/AmlCode/dsdt_pvh/g' $*.hex >$@
+   echo "int dsdt_pvh_len=sizeof(dsdt_pvh);" >>$@
+   rm -f $*.aml $*.hex
+   cd $(CURDIR)
+
 iasl:
@echo
@echo "ACPI ASL compiler (iasl) is needed"
@@ -62,7 +78,7 @@ iasl:
@exit 1
 
 clean:
-   rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
+   rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC)) 
$(ACPI_BUILD_DIR)/dsdt_pvh.c
 
 distclean: clean
 
diff --git a/tools/libacpi/dsdt.asl b/tools/libacpi/dsdt.asl
index bd65823..b14f5d0 100644
--- a/tools/libacpi/dsdt.asl
+++ b/tools/libacpi/dsdt.asl
@@ -43,26 +43,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
 
 Scope (\_SB)
 {
-   /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC00 */
-   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
-   Field(BIOS, ByteAcc, NoLock, Preserve) {
-   UAR1, 1,
-   UAR2, 1,
-   LTP1, 1,
-   HPET, 1,
-   Offset(2),
-   NCPU, 16,
-   PMIN, 32,
-   PLEN, 32,
-   MSUA, 32, /* MADT checksum address */
-   MAPA, 32, /* MADT LAPIC0 address */
-   VGIA, 32, /* VM generation id address */
-   LMIN, 32,
-   HMIN, 32,
-   LLEN, 32,
-   HLEN, 32
-   }
-
 /* Fix HCT test for 0x400 pci memory:
  * - need to report low 640 MB mem as motherboard resource
  */
diff --git a/tools/libacpi/dsdt_acpi_info.asl b/tools/libacpi/dsdt_acpi_info.asl
new file mode 100644
index 000..eeecd49
--- /dev/null
+++ b/tools/libacpi/dsdt_acpi_info.asl
@@ -0,0 +1,23 @@
+
+Scope (\_SB)
+{
+   /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC00 */
+   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
+   Field(BIOS, ByteAcc, NoLock, Preserve) {
+   UAR1, 1,
+   UAR2, 1,
+   LTP1, 1,
+   HPET, 1,
+   Offset(2),
+   NCPU, 16,
+   PMIN, 32,
+   PLEN, 32,
+   MSUA, 32, /* MADT checksum address */
+   MAPA, 32, /* MADT LAPIC0 address */
+   VGIA, 32, /* VM generation id address */
+   LMIN, 32,
+   HMIN, 32,
+   LLEN, 32,
+   HLEN, 32
+   }
+}
diff --git 

[Xen-devel] [PATCH v1 01/20] hvmloader: Provide hvmloader_acpi_build_tables()

[Boris Ostrovsky]

In preparation for moving out ACPI builder make all
BIOSes call hvmloader_acpi_build_tables() instead of
calling ACPI code directly.

No functional changes.

Signed-off-by: Boris Ostrovsky 
---

Changes in v1:
* Added last sentence to commit message

 tools/firmware/hvmloader/ovmf.c|2 +-
 tools/firmware/hvmloader/rombios.c |2 +-
 tools/firmware/hvmloader/seabios.c |2 +-
 tools/firmware/hvmloader/util.c|7 +++
 tools/firmware/hvmloader/util.h|4 
 5 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index db9fa7a..74fec56 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -125,7 +125,7 @@ static void ovmf_acpi_build_tables(void)
 .dsdt_15cpu_len = 0
 };
 
-acpi_build_tables(, ACPI_PHYSICAL_ADDRESS);
+hvmloader_acpi_build_tables(, ACPI_PHYSICAL_ADDRESS);
 }
 
 static void ovmf_create_smbios_tables(void)
diff --git a/tools/firmware/hvmloader/rombios.c 
b/tools/firmware/hvmloader/rombios.c
index 1f15b94..1f8fc2d 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -180,7 +180,7 @@ static void rombios_acpi_build_tables(void)
 .dsdt_15cpu_len = dsdt_15cpu_len,
 };
 
-acpi_build_tables(, ACPI_PHYSICAL_ADDRESS);
+hvmloader_acpi_build_tables(, ACPI_PHYSICAL_ADDRESS);
 }
 
 static void rombios_create_mp_tables(void)
diff --git a/tools/firmware/hvmloader/seabios.c 
b/tools/firmware/hvmloader/seabios.c
index c6b3d9f..9f66a79 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -100,7 +100,7 @@ static void seabios_acpi_build_tables(void)
 .dsdt_15cpu_len = 0,
 };
 
-acpi_build_tables(, rsdp);
+hvmloader_acpi_build_tables(, rsdp);
 add_table(rsdp);
 }
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 9382709..9af29b1 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -21,6 +21,7 @@
 #include "config.h"
 #include "hypercall.h"
 #include "ctype.h"
+#include "acpi/acpi2_0.h"
 #include 
 #include 
 #include 
@@ -856,6 +857,12 @@ int hpet_exists(unsigned long hpet_base)
 return ((hpet_id >> 16) == 0x8086);
 }
 
+void hvmloader_acpi_build_tables(struct acpi_config *config,
+ unsigned int physical)
+{
+acpi_build_tables(config, physical);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 3126817..b226df4 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -273,6 +273,10 @@ extern struct e820map memory_map;
 bool check_overlap(uint64_t start, uint64_t size,
uint64_t reserved_start, uint64_t reserved_size);
 
+struct acpi_config;
+void hvmloader_acpi_build_tables(struct acpi_config *config,
+ unsigned int physical);
+
 #endif /* __HVMLOADER_UTIL_H__ */
 
 /*
-- 
1.7.1


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

[Xen-devel] [PATCH v1 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables

[Boris Ostrovsky]

Non-hvmloader users may be building tables in virtual address space
and therefore we need to make sure that values that end up in tables
are physical addresses.

Signed-off-by: Boris Ostrovsky 
---
 tools/firmware/hvmloader/acpi/build.c |   47 +
 1 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 0adb3d6..4b0302c 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -126,7 +126,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
 config->ainfo.nr_cpus =config-> hvminfo->nr_vcpus;
-config->ainfo.madt_lapic0_addr = (uint32_t)lapic;
+config->ainfo.madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
 for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
@@ -143,7 +143,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
 set_checksum(madt, offsetof(struct acpi_header, checksum),
  madt->header.length);
-config->ainfo.madt_csum_addr = (uint32_t)>header.checksum;
+config->ainfo.madt_csum_addr =
+ctxt->mem_ops.v2p(ctxt, >header.checksum);
 
 return madt;
 }
@@ -311,7 +312,7 @@ static int construct_passthrough_tables(struct acpi_ctxt 
*ctxt,
 break;
 memcpy(buffer, header, header->length);
 
-table_ptrs[nr_tables++] = (unsigned long)buffer;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, buffer);
 total += header->length;
 acpi_pt_addr += header->length;
 }
@@ -337,7 +338,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 madt = construct_madt(ctxt, config);
 if (!madt) return -1;
-table_ptrs[nr_tables++] = (unsigned long)madt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, madt);
 }
 
 /* HPET. */
@@ -345,7 +346,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 hpet = construct_hpet(ctxt, config);
 if (!hpet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)hpet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, hpet);
 }
 
 /* WAET. */
@@ -353,7 +354,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 waet = construct_waet(ctxt, config);
 if ( !waet ) return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, waet);
 }
 
 if ( config->table_flags & ACPI_BUILD_SSDT_PM )
@@ -361,7 +362,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_pm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_pm, sizeof(ssdt_pm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 }
 
 if ( config->table_flags & ACPI_BUILD_SSDT_S3 )
@@ -369,7 +370,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s3), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S3 disabled\n");
 }
@@ -379,7 +380,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s4), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S4 disabled\n");
 }
@@ -393,12 +394,12 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_tpm, sizeof(ssdt_tpm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 
 tcpa = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_tcpa), 16);
 if (!tcpa) return -1;
 memset(tcpa, 0, sizeof(*tcpa));
-table_ptrs[nr_tables++] = (unsigned long)tcpa;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, tcpa);
 
 tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
 tcpa->header.length= sizeof(*tcpa);
@@ -426,11 +427,11 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 struct acpi_20_slit *slit = construct_slit(ctxt, config);
 
 if ( srat )
-table_ptrs[nr_tables++] = (unsigned long)srat;
+

[Xen-devel] [PATCH v1 12/20] acpi/hvmloader: Link ACPI object files directly

[Boris Ostrovsky]

ACPI sources will be available to various component which will build
them according to their own rules. ACPI's Makefile will only generate
necessary source files.

Signed-off-by: Boris Ostrovsky 
---

Changes in v1:
* Build ASL and C files in target's (hvmloader) directory

 .gitignore |8 +++---
 tools/firmware/hvmloader/Makefile  |   11 -
 tools/firmware/hvmloader/acpi/Makefile |   37 +++
 3 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/.gitignore b/.gitignore
index e019f2e..9dd2086 100644
--- a/.gitignore
+++ b/.gitignore
@@ -126,10 +126,10 @@ tools/firmware/*bios/*bios*.txt
 tools/firmware/etherboot/gpxe/*
 tools/firmware/extboot/extboot.img
 tools/firmware/extboot/signrom
-tools/firmware/hvmloader/acpi/mk_dsdt
-tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt_*.asl
-tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/mk_dsdt
+tools/firmware/hvmloader/dsdt*.c
+tools/firmware/hvmloader/dsdt_*.asl
+tools/firmware/hvmloader/ssdt_*.h
 tools/firmware/hvmloader/hvmloader
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index f2f4791..043da50 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,6 +20,7 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
+export ACPI_BUILD_DIR=$(shell pwd)
 SUBDIRS := acpi
 
 # The HVM loader is started in 32-bit mode at the address below:
@@ -95,7 +96,15 @@ all: subdirs-all
 ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-hvmloader: $(OBJS) acpi/acpi.a
+ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
+ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c build.c 
static_tables.c
+ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES))
+$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+vpath build.c $(ACPI_PATH)/
+vpath static_tables.c $(ACPI_PATH)/
+OBJS += $(ACPI_OBJS)
+
+hvmloader: $(OBJS)
$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(LOADADDR) -o hvmloader.tmp $^
$(OBJCOPY) hvmloader.tmp hvmloader
rm -f hvmloader.tmp
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index d3e882a..4866912 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -17,36 +17,41 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c 
dsdt_anycpu_qemu_xen.c
-OBJS  = $(patsubst %.c,%.o,$(C_SRC))
+MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
-CFLAGS += $(CFLAGS_xeninclude)
+# Sources to be generated
+C_SRC = $(ACPI_BUILD_DIR)/dsdt_anycpu.c $(ACPI_BUILD_DIR)/dsdt_15cpu.c  
$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.c
+H_SRC = $(ACPI_BUILD_DIR)/ssdt_s3.h $(ACPI_BUILD_DIR)/ssdt_s4.h 
$(ACPI_BUILD_DIR)/ssdt_pm.h $(ACPI_BUILD_DIR)/ssdt_tpm.h
 
 vpath iasl $(PATH)
-all: acpi.a
+all: $(C_SRC) $(H_SRC)
 
-ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
+$(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
+   cd $(ACPI_BUILD_DIR)
iasl -vs -p $* -tc $<
sed -e 's/AmlCode/$*/g' $*.hex >$@
rm -f $*.hex $*.aml
+   cd $(CURDIR)
 
-mk_dsdt: mk_dsdt.c
+$(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@
+   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@
+   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
 
-$(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
-   iasl -vs -p $* -tc $*.asl
+$(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
+   cd $(ACPI_BUILD_DIR)
+   iasl -vs -p $* -tc $(ACPI_BUILD_DIR)/$*.asl
sed -e 's/AmlCode/$*/g' $*.hex >$@
echo "int $*_len=sizeof($*);" >>$@
rm -f $*.aml $*.hex
+   cd $(CURDIR)
 
 iasl:
@echo
@@ -56,14 +61,8 @@ iasl:
@echo 
@exit 1
 
-build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
-
-acpi.a: $(OBJS)
-   $(AR) rc $@ $(OBJS)
-
 clean:
-   rm -rf *.a *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
-   rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
+   rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
 
 distclean: clean
 
-- 
1.7.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [PATCH v1 15/20] x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
Changes in v1:
* More checks, in more approriate places

 xen/arch/x86/hvm/vlapic.c |   12 ++--
 xen/arch/x86/hvm/vpt.c|2 +-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index e2f4450..a3855c8 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1115,7 +1115,12 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
 struct domain *d = v->domain;
 struct vlapic *vlapic = vcpu_vlapic(v);
 uint32_t lvt0 = vlapic_get_reg(vlapic, APIC_LVT0);
-union vioapic_redir_entry redir0 = domain_vioapic(d)->redirtbl[0];
+union vioapic_redir_entry redir0;
+
+if ( !has_vioapic(d) || !has_vpic(d) )
+return 0;
+
+redir0 = domain_vioapic(d)->redirtbl[0];
 
 /* We deliver 8259 interrupts to the appropriate CPU as follows. */
 return ((/* IOAPIC pin0 is unmasked and routing to this LAPIC? */
@@ -1131,7 +1136,7 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
 
 int vlapic_accept_pic_intr(struct vcpu *v)
 {
-if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
+if ( vlapic_hw_disabled(vcpu_vlapic(v)) || !has_vpic(v->domain) )
 return 0;
 
 TRACE_2D(TRC_HVM_EMUL_LAPIC_PIC_INTR,
@@ -1146,6 +1151,9 @@ void vlapic_adjust_i8259_target(struct domain *d)
 {
 struct vcpu *v;
 
+if ( !has_vpic(d) )
+return;
+
 for_each_vcpu ( d, v )
 if ( __vlapic_accept_pic_intr(v) )
 goto found;
diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
index 358ec57..c90aa95 100644
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -496,7 +496,7 @@ void pt_adjust_global_vcpu_target(struct vcpu *v)
 struct pl_time *pl_time;
 int i;
 
-if ( v == NULL )
+if ( v == NULL || !has_vpit(v->domain) )
 return;
 
 vpit = >domain->arch.vpit;
-- 
1.7.1


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

[Xen-devel] [PATCH v1 14/20] acpi: Move ACPI code to tools/libacpi

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
 tools/firmware/hvmloader/Makefile  |   14 --
 .../{firmware/hvmloader/acpi => libacpi}/Makefile  |2 +-
 tools/{firmware/hvmloader/acpi => libacpi}/README  |0
 .../{firmware/hvmloader/acpi => libacpi}/acpi2_0.h |0
 tools/{firmware/hvmloader/acpi => libacpi}/build.c |0
 .../{firmware/hvmloader/acpi => libacpi}/dsdt.asl  |0
 .../{firmware/hvmloader/acpi => libacpi}/libacpi.h |0
 .../{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c |0
 .../hvmloader/acpi => libacpi}/ssdt_pm.asl |0
 .../hvmloader/acpi => libacpi}/ssdt_s3.asl |0
 .../hvmloader/acpi => libacpi}/ssdt_s4.asl |0
 .../hvmloader/acpi => libacpi}/ssdt_tpm.asl|0
 .../hvmloader/acpi => libacpi}/static_tables.c |0
 tools/{firmware/hvmloader/acpi => libacpi}/x86.h   |0
 14 files changed, 9 insertions(+), 7 deletions(-)
 rename tools/{firmware/hvmloader/acpi => libacpi}/Makefile (98%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/README (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/build.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/x86.h (100%)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 920b0d0..39a0156 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,9 +20,6 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-export ACPI_BUILD_DIR=$(shell pwd)
-SUBDIRS := acpi
-
 # The HVM loader is started in 32-bit mode at the address below:
 LOADADDR = 0x10
 
@@ -90,16 +87,20 @@ ROMS += $(SEABIOS_ROM)
 endif
 
 .PHONY: all
-all: subdirs-all
+all: acpi subdirs-all
$(MAKE) hvmloader
 
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(shell pwd)
+
 ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
+ACPI_PATH = $(XEN_ROOT)/tools/libacpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c build.c 
static_tables.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES))
-$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"../util.h\"
+$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"$(CURDIR)/util.h\"
 CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)/
 vpath static_tables.c $(ACPI_PATH)/
@@ -153,6 +154,7 @@ endif
 clean: subdirs-clean
rm -f roms.inc roms.inc.new acpi.h
rm -f hvmloader hvmloader.tmp *.o $(DEPS)
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(shell pwd) clean
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/acpi/Makefile b/tools/libacpi/Makefile
similarity index 98%
rename from tools/firmware/hvmloader/acpi/Makefile
rename to tools/libacpi/Makefile
index 4866912..cc0dc31 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -14,7 +14,7 @@
 # this program; If not, see .
 #
 
-XEN_ROOT = $(CURDIR)/../../../..
+XEN_ROOT = $(CURDIR)/../../
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
diff --git a/tools/firmware/hvmloader/acpi/README b/tools/libacpi/README
similarity index 100%
rename from tools/firmware/hvmloader/acpi/README
rename to tools/libacpi/README
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
similarity index 100%
rename from tools/firmware/hvmloader/acpi/acpi2_0.h
rename to tools/libacpi/acpi2_0.h
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/libacpi/build.c
similarity index 100%
rename from tools/firmware/hvmloader/acpi/build.c
rename to tools/libacpi/build.c
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl b/tools/libacpi/dsdt.asl
similarity index 100%
rename from tools/firmware/hvmloader/acpi/dsdt.asl
rename to tools/libacpi/dsdt.asl
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h b/tools/libacpi/libacpi.h
similarity index 100%
rename from tools/firmware/hvmloader/acpi/libacpi.h
rename to tools/libacpi/libacpi.h
diff --git a/tools/firmware/hvmloader/acpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
similarity index 100%
rename from tools/firmware/hvmloader/acpi/mk_dsdt.c
rename to tools/libacpi/mk_dsdt.c
diff --git a/tools/firmware/hvmloader/acpi/ssdt_pm.asl 
b/tools/libacpi/ssdt_pm.asl

[Xen-devel] [PATCH v1 19/20] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---

New patch

 tools/libxl/Makefile|2 ++
 tools/libxl/libxl_dom.c |   22 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 9fee752..3a2d64a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -165,6 +165,8 @@ $(XL_OBJS) $(TEST_PROG_OBJS) _libxl.api-for-check: \
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
+libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ccc41b4..ba3472e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -24,6 +24,9 @@
 #include 
 #include 
 #include 
+#if defined(__i386__) || defined(__x86_64__)
+#include 
+#endif
 
 #include "_paths.h"
 
@@ -1006,10 +1009,21 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->target_pages = mem_size >> XC_PAGE_SHIFT;
 if (dom->mmio_size == 0 && device_model)
 dom->mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
-else if (dom->mmio_size == 0 && !device_model)
-dom->mmio_size = GB(4) -
-((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
-<< XC_PAGE_SHIFT);
+else if (dom->mmio_size == 0 && !device_model) {
+#if defined(__i386__) || defined(__x86_64__)
+if (libxl_defbool_val(info->u.hvm.apic)) {
+/* Make sure LAPIC_BASE_ADDRESS is below special pages */
+assert(X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+  << XC_PAGE_SHIFT) - LAPIC_BASE_ADDRESS)) >= 
XC_PAGE_SIZE);
+dom->mmio_size = GB(4) - LAPIC_BASE_ADDRESS;
+} else
+dom->mmio_size = GB(4) -
+((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+ << XC_PAGE_SHIFT);
+#else
+assert(1);
+#endif
+}
 lowmem_end = mem_size;
 highmem_end = 0;
 mmio_start = (1ull << 32) - dom->mmio_size;
-- 
1.7.1


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

[Xen-devel] [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---

Changes in v1:
* Move to libxl
* Added populate_acpi_pages()
* Stash location/size of tables in xc_dom_image (to be used in constructing 
e820 map)
* Use libxl allocator
* Only set XEN_X86_EMU_LAPIC flag if 'apic' option is set.
* Make acpi_build_tables() return error code

 .gitignore   |4 +
 tools/libacpi/build.c|7 +-
 tools/libacpi/libacpi.h  |   15 ++-
 tools/libxl/Makefile |   17 +++-
 tools/libxl/libxl_arch.h |3 +
 tools/libxl/libxl_dom.c  |1 +
 tools/libxl/libxl_x86.c  |   29 +++--
 tools/libxl/libxl_x86_acpi.c |  292 ++
 tools/libxl/libxl_x86_acpi.h |   21 +++
 9 files changed, 373 insertions(+), 16 deletions(-)
 create mode 100644 tools/libxl/libxl_x86_acpi.c
 create mode 100644 tools/libxl/libxl_x86_acpi.h

diff --git a/.gitignore b/.gitignore
index 9dd2086..d4da37f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -179,6 +179,10 @@ tools/libxl/testenum.c
 tools/libxl/tmp.*
 tools/libxl/_libxl.api-for-check
 tools/libxl/*.api-ok
+tools/libxl/mk_dsdt
+tools/libxl/dsdt*.c
+tools/libxl/dsdt_*.asl
+tools/libxl/ssdt_*.h
 tools/misc/cpuperf/cpuperf-perfcntr
 tools/misc/cpuperf/cpuperf-xen
 tools/misc/xc_shadow
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 290f005..a6ddf53 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -23,6 +23,7 @@
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
 #include "x86.h"
+#include 
 #include 
 #include 
 
@@ -473,7 +474,7 @@ static int new_vm_gid(struct acpi_ctxt *ctxt,
 return 1;
 }
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
 {
 struct acpi_20_rsdp *rsdp;
 struct acpi_20_rsdt *rsdt;
@@ -594,11 +595,11 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 
 *(struct acpi_info *)config->ainfop = config->ainfo;
 
-return;
+return 0;
 
 oom:
 printf("unable to build ACPI tables: out of memory\n");
-
+return -1;
 }
 
 /*
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 87a2937..791ebac 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -69,6 +69,15 @@ struct acpi_ctxt {
 void *(*alloc)(struct acpi_ctxt *ctxt, uint32_t size, uint32_t align);
 unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
 } mem_ops;
+
+unsigned int page_size;
+unsigned int page_shift;
+
+/* Memory allocator */
+unsigned long alloc_base_paddr;
+unsigned long alloc_base_vaddr;
+unsigned long alloc_currp;
+unsigned long alloc_end;
 };
 
 struct acpi_config {
@@ -98,13 +107,13 @@ struct acpi_config {
  * This must match the OperationRegion(BIOS, SystemMemory, )
  * definition in the DSDT
  */
-unsigned int ainfop;
+unsigned long ainfop;
 
 /* RSDP address */
-unsigned int rsdp;
+unsigned long rsdp;
 };
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
 
 #endif /* __LIBACPI_H__ */
 
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3a2d64a..18be2e7 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -75,7 +75,20 @@ else
 LIBXL_OBJS-y += libxl_no_colo.o
 endif
 
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
+ACPI_PATH  = $(XEN_ROOT)/tools/libacpi
+ACPI_FILES = dsdt_pvh.c build.c static_tables.c
+ACPI_OBJS  = $(patsubst %.c,%.o,$(ACPI_FILES))
+$(ACPI_FILES): acpi
+$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"$(CURDIR)/libxl_x86_acpi.h\"
+vpath build.c $(ACPI_PATH)/
+vpath static_tables.c $(ACPI_PATH)/
+LIBXL_OBJS-$(CONFIG_X86) += $(ACPI_OBJS)
+
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd)
+
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
 
 ifeq ($(CONFIG_NetBSD),y)
@@ -166,6 +179,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
 libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+libxl_x86_acpi.o: CFLAGS += -I$(XEN_ROOT)/tools
 
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
@@ -308,6 +322,7 @@ clean:
$(RM) -f testidl.c.new testidl.c *.api-ok
$(RM) -f xenlight.pc
$(RM) -f xlutil.pc
+   $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd) clean
 
 distclean: clean
$(RM) -f xenlight.pc.in xlutil.pc.in
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 34a853c..7c6536b 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -62,4 +62,7 @@ int 

[Xen-devel] [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests

[Boris Ostrovsky]

PVHv2 guests may request LAPIC emulation (and nothing else)

Signed-off-by: Boris Ostrovsky 
---
Changes in v1:
* Refer to PVHv2 (not hvmlite)

 xen/arch/x86/domain.c |   26 --
 1 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 989bc74..c495a29 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 }
 else
 {
-if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
+uint32_t emflags;
+
+if ( is_hardware_domain(d) )
+config->emulation_flags |= XEN_X86_EMU_PIT;
+
+emflags = config->emulation_flags;
+if ( (emflags & ~XEN_X86_EMU_ALL) != 0 )
 {
 printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
-   d->domain_id, config->emulation_flags);
+   d->domain_id, emflags);
 return -EINVAL;
 }
-if ( is_hardware_domain(d) )
-config->emulation_flags |= XEN_X86_EMU_PIT;
-if ( config->emulation_flags != 0 &&
- (config->emulation_flags !=
-  (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
+
+/* PVHv2 guests can request emulated APIC */
+if ( emflags &&
+(is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
+ (emflags != XEN_X86_EMU_LAPIC)) :
+(emflags != XEN_X86_EMU_PIT)) )
 {
 printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
-   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV",
-   config->emulation_flags);
+   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
 return -EOPNOTSUPP;
 }
-d->arch.emulation_flags = config->emulation_flags;
+d->arch.emulation_flags = emflags;
 }
 
 if ( has_hvm_container_domain(d) )
-- 
1.7.1


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

[Xen-devel] [xen-unstable test] 96662: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat fail REGR. vs. 96611
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail REGR. vs. 96611
 test-armhf-armhf-xl-vhd   6 xen-boot  fail REGR. vs. 96611

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 96483
 build-amd64-rumpuserxen   6 xen-buildfail   like 96611
 build-i386-rumpuserxen6 xen-buildfail   like 96611
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 96611
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 96611
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 96611
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 96611

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  4481335590f9b585b8dd168f0269e064e7ecbf43
baseline version:
 xen  bb4f41b3dff831faaf5a3248e0ecd123024d7f8f

Last test of basis96611  2016-07-04 01:58:03 Z1 days
Failing since 96634  2016-07-04 12:50:54 Z1 days2 attempts
Testing same since96662  2016-07-05 01:45:09 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Corneliu ZUZU 
  Jan Beulich 
  Kevin Tian 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass

[Xen-devel] [PATCH v8 6/6] tools/xen-access: add test-case for ARM SMC

[Tamas K Lengyel]

Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/tests/xen-access/xen-access.c | 45 -
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 02655d5..a04dbff 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -338,6 +338,8 @@ void usage(char* progname)
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
 fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec|debug");
+#elif defined(__arm__) || defined(__aarch64__)
+fprintf(stderr, "|privcall");
 #endif
 fprintf(stderr,
 "\n"
@@ -426,6 +428,11 @@ int main(int argc, char *argv[])
 {
 debug = 1;
 }
+#elif defined(__arm__) || defined(__aarch64__)
+else if ( !strcmp(argv[0], "privcall") )
+{
+privcall = 1;
+}
 #endif
 else
 {
@@ -548,6 +555,16 @@ int main(int argc, char *argv[])
 }
 }
 
+if ( privcall )
+{
+rc = xc_monitor_privileged_call(xch, domain_id, 1);
+if ( rc < 0 )
+{
+ERROR("Error %d setting privileged call trapping with vm_event\n", 
rc);
+goto exit;
+}
+}
+
 /* Wait for access */
 for (;;)
 {
@@ -560,7 +577,8 @@ int main(int argc, char *argv[])
 rc = xc_monitor_software_breakpoint(xch, domain_id, 0);
 if ( debug )
 rc = xc_monitor_debug_exceptions(xch, domain_id, 0, 0);
-
+if ( privcall )
+rc = xc_monitor_privileged_call(xch, domain_id, 0);
 if ( altp2m )
 {
 rc = xc_altp2m_switch_to_view( xch, domain_id, 0 );
@@ -716,6 +734,31 @@ int main(int argc, char *argv[])
 }
 
 break;
+#if defined(__arm__) || defined(__aarch64__)
+case VM_EVENT_REASON_PRIVILEGED_CALL:
+{
+const struct vm_event_regs_arm *in_regs = 

+struct vm_event_regs_arm *out_regs = 
+bool is32bit = !!(in_regs->cpsr & PSR_MODE_BIT);
+uint64_t pc;
+
+*out_regs = *in_regs;
+
+if ( is32bit ) {
+pc = in_regs->arch.arm32.pc;
+out_regs->arch.arm32.pc += 4;
+} else {
+pc = in_regs->arch.arm64.pc;
+out_regs->arch.arm64.pc += 8;
+}
+
+printf("Privileged call: pc=%016"PRIx64" (vcpu %d)\n",
+   pc, req.vcpu_id);
+
+rsp.flags |= VM_EVENT_FLAG_SET_REGISTERS;
+}
+break;
+#endif
 default:
 fprintf(stderr, "UNKNOWN REASON CODE %d\n", req.reason);
 }
-- 
2.8.1


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

[Xen-devel] [PATCH v8 1/6] monitor: rename and relocate vm_event_monitor_traps

[Tamas K Lengyel]

The function vm_event_monitor_traps actually belongs in the monitor subsystem.
As part of this patch we fix the sync input's type to bool_t to match how
the callers use it.

Signed-off-by: Tamas K Lengyel 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Razvan Cojocaru 
---
 xen/arch/x86/hvm/monitor.c |  7 ---
 xen/common/monitor.c   | 44 +++-
 xen/common/vm_event.c  | 45 -
 xen/include/xen/monitor.h  |  6 +-
 xen/include/xen/vm_event.h |  6 --
 5 files changed, 52 insertions(+), 56 deletions(-)

diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index bbe5952..fb493bb 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -23,6 +23,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -48,7 +49,7 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 .u.write_ctrlreg.old_value = old
 };
 
-if ( vm_event_monitor_traps(curr, sync, ) >= 0 )
+if ( monitor_traps(curr, sync, ) >= 0 )
 return 1;
 }
 
@@ -68,7 +69,7 @@ void hvm_monitor_msr(unsigned int msr, uint64_t value)
 .u.mov_to_msr.value = value,
 };
 
-vm_event_monitor_traps(curr, 1, );
+monitor_traps(curr, 1, );
 }
 }
 
@@ -131,7 +132,7 @@ int hvm_monitor_debug(unsigned long rip, enum 
hvm_monitor_debug_type type,
 
 req.vcpu_id = curr->vcpu_id;
 
-return vm_event_monitor_traps(curr, sync, );
+return monitor_traps(curr, sync, );
 }
 
 /*
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 436214a..5fce61e 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -19,12 +19,15 @@
  * License along with this program; If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
 {
@@ -85,6 +88,45 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 return 0;
 }
 
+int monitor_traps(struct vcpu *v, bool_t sync, vm_event_request_t *req)
+{
+int rc;
+struct domain *d = v->domain;
+
+rc = vm_event_claim_slot(d, >vm_event->monitor);
+switch ( rc )
+{
+case 0:
+break;
+case -ENOSYS:
+/*
+ * If there was no ring to handle the event, then
+ * simply continue executing normally.
+ */
+return 0;
+default:
+return rc;
+};
+
+if ( sync )
+{
+req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
+vm_event_vcpu_pause(v);
+rc = 1;
+}
+
+if ( altp2m_active(d) )
+{
+req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
+req->altp2m_idx = altp2m_vcpu_idx(v);
+}
+
+vm_event_fill_regs(req);
+vm_event_put_request(d, >vm_event->monitor, req);
+
+return rc;
+}
+
 void monitor_guest_request(void)
 {
 struct vcpu *curr = current;
@@ -97,7 +139,7 @@ void monitor_guest_request(void)
 .vcpu_id = curr->vcpu_id,
 };
 
-vm_event_monitor_traps(curr, d->monitor.guest_request_sync, );
+monitor_traps(curr, d->monitor.guest_request_sync, );
 }
 }
 
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 17d2716..22bbfc1 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -789,50 +788,6 @@ void vm_event_vcpu_unpause(struct vcpu *v)
 }
 
 /*
- * Monitor vm-events
- */
-
-int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
-   vm_event_request_t *req)
-{
-int rc;
-struct domain *d = v->domain;
-
-rc = vm_event_claim_slot(d, >vm_event->monitor);
-switch ( rc )
-{
-case 0:
-break;
-case -ENOSYS:
-/*
- * If there was no ring to handle the event, then
- * simply continue executing normally.
- */
-return 0;
-default:
-return rc;
-};
-
-if ( sync )
-{
-req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
-vm_event_vcpu_pause(v);
-rc = 1;
-}
-
-if ( altp2m_active(d) )
-{
-req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
-req->altp2m_idx = altp2m_vcpu_idx(v);
-}
-
-vm_event_fill_regs(req);
-vm_event_put_request(d, >vm_event->monitor, req);
-
-return rc;
-}
-
-/*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index 204d5cc..2171d04 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -3,7 +3,7 @@
  *
  * Common monitor_op domctl handler.
  *
- * Copyright (c) 2015 Tamas K Lengyel (ta...@tklengyel.com)
+ * Copyright (c) 2015-2016 Tamas K Lengyel 

[Xen-devel] [PATCH v8 3/6] monitor: ARM SMC events

[Tamas K Lengyel]

Add support for monitoring ARM SMC events. This patch only adds the required
bits to enable/disable monitoring and forwarding the event through vm_event.

Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/Makefile |  1 +
 xen/arch/arm/monitor.c| 82 +++
 xen/arch/arm/traps.c  |  9 -
 xen/include/asm-arm/domain.h  |  5 +++
 xen/include/asm-arm/monitor.h | 22 +++-
 xen/include/public/domctl.h   |  1 +
 xen/include/public/vm_event.h | 10 ++
 7 files changed, 112 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/arm/monitor.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9e38da3..ffb0e96 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -41,6 +41,7 @@ obj-y += decode.o
 obj-y += processor.o
 obj-y += smc.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
+obj-y += monitor.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c
new file mode 100644
index 000..d609f4f
--- /dev/null
+++ b/xen/arch/arm/monitor.c
@@ -0,0 +1,82 @@
+/*
+ * arch/arm/monitor.c
+ *
+ * Arch-specific monitor_op domctl handler.
+ *
+ * Copyright (c) 2016 Tamas K Lengyel (tamas.leng...@zentific.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+
+int arch_monitor_domctl_event(struct domain *d,
+  struct xen_domctl_monitor_op *mop)
+{
+struct arch_domain *ad = >arch;
+bool_t requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op);
+
+switch ( mop->event )
+{
+case XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL:
+{
+bool_t old_status = ad->monitor.privileged_call_enabled;
+
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.privileged_call_enabled = requested_status;
+domain_unpause(d);
+break;
+}
+
+default:
+/*
+ * Should not be reached unless arch_monitor_get_capabilities() is
+ * not properly implemented.
+ */
+ASSERT_UNREACHABLE();
+return -EOPNOTSUPP;
+}
+
+return 0;
+}
+
+int monitor_smc()
+{
+struct vcpu *curr = current;
+
+if ( curr->domain->arch.monitor.privileged_call_enabled )
+{
+vm_event_request_t req = { 0 };
+
+req.reason = VM_EVENT_REASON_PRIVILEGED_CALL;
+req.vcpu_id = curr->vcpu_id;
+req.u.privcall.type = PRIVCALL_SMC;
+
+return monitor_traps(curr, 1, );
+}
+
+return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 627e8c9..846ba26 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "decode.h"
 #include "vtimer.h"
@@ -2509,13 +2510,19 @@ bad_data_abort:
 
 static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
 {
+int rc;
+
 if ( !check_conditional_instr(regs, hsr) )
 {
 advance_pc(regs, hsr);
 return;
 }
 
-inject_undef_exception(regs, hsr);
+rc = monitor_smc();
+if ( rc < 0 )
+domain_crash_synchronous();
+if ( !rc )
+inject_undef_exception(regs, hsr);
 }
 
 static void enter_hypervisor_head(struct cpu_user_regs *regs)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 979f7de..a97bee7 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -127,6 +127,11 @@ struct arch_domain
 paddr_t efi_acpi_gpa;
 paddr_t efi_acpi_len;
 #endif
+
+/* Monitor options */
+struct {
+uint8_t privileged_call_enabled : 1;
+} monitor;
 }  __cacheline_aligned;
 
 struct arch_vcpu
diff --git a/xen/include/asm-arm/monitor.h b/xen/include/asm-arm/monitor.h
index 4af707a..dcb0c5d 100644
--- a/xen/include/asm-arm/monitor.h
+++ b/xen/include/asm-arm/monitor.h
@@ -32,19 +32,8 @@ int arch_monitor_domctl_op(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 return -EOPNOTSUPP;
 }
 
-static inline
 int arch_monitor_domctl_event(struct domain *d,
-  struct xen_domctl_monitor_op 

[Xen-devel] [PATCH v8 2/6] arm: filter SMC exceptions with failed condition checks

[Tamas K Lengyel]

In AArch32 state, the ARMv8-A architecture permits, but does not require,
this trap to apply to conditional SMC instructions that fail their condition
code check, in the same way as with traps on other conditional instructions.

Signed-off-by: Tamas K Lengyel 
Suggested-by: Julien Grall 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/traps.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 44926ca..627e8c9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2507,6 +2507,17 @@ bad_data_abort:
 inject_dabt_exception(regs, info.gva, hsr.len);
 }
 
+static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
+{
+if ( !check_conditional_instr(regs, hsr) )
+{
+advance_pc(regs, hsr);
+return;
+}
+
+inject_undef_exception(regs, hsr);
+}
+
 static void enter_hypervisor_head(struct cpu_user_regs *regs)
 {
 if ( guest_mode(regs) )
@@ -2582,7 +2593,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs 
*regs)
  */
 GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
 perfc_incr(trap_smc32);
-inject_undef32_exception(regs);
+do_trap_smc(regs, hsr);
 break;
 case HSR_EC_HVC32:
 GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
@@ -2615,7 +2626,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs 
*regs)
  */
 GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
 perfc_incr(trap_smc64);
-inject_undef64_exception(regs, hsr.len);
+do_trap_smc(regs, hsr);
 break;
 case HSR_EC_SYSREG:
 GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr));
-- 
2.8.1


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

[Xen-devel] [PATCH v8 4/6] arm/vm_event: get/set registers

[Tamas K Lengyel]

Add support for getting/setting registers through vm_event on ARM.
The set of registers can be expanded in the future to include other registers
as well if required. The set is limited to the GPRs, PC, CPSR and TTBR0/1 in
this patch.

Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/Makefile  |   1 +
 xen/arch/arm/vm_event.c| 163 +
 xen/include/asm-arm/vm_event.h |  11 ---
 xen/include/asm-x86/vm_event.h |   4 -
 xen/include/public/vm_event.h  |  76 ++-
 xen/include/xen/vm_event.h |   3 +
 6 files changed, 240 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/arm/vm_event.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ffb0e96..82ac34c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -42,6 +42,7 @@ obj-y += processor.o
 obj-y += smc.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-y += monitor.o
+obj-y += vm_event.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/vm_event.c b/xen/arch/arm/vm_event.c
new file mode 100644
index 000..0e59fae
--- /dev/null
+++ b/xen/arch/arm/vm_event.c
@@ -0,0 +1,163 @@
+/*
+ * arch/arm/vm_event.c
+ *
+ * Architecture-specific vm_event handling routines
+ *
+ * Copyright (c) 2016 Tamas K Lengyel (ta...@tklengyel.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+
+void vm_event_fill_regs(vm_event_request_t *req)
+{
+const struct cpu_user_regs *regs = guest_cpu_user_regs();
+
+req->data.regs.arm.cpsr = regs->cpsr;
+req->data.regs.arm.ttbr0 = READ_SYSREG64(TTBR0_EL1);
+req->data.regs.arm.ttbr1 = READ_SYSREG64(TTBR1_EL1);
+
+if ( psr_mode_is_32bit(regs->cpsr) )
+{
+req->data.regs.arm.arch.arm32.r0 = regs->r0;
+req->data.regs.arm.arch.arm32.r1 = regs->r1;
+req->data.regs.arm.arch.arm32.r2 = regs->r2;
+req->data.regs.arm.arch.arm32.r3 = regs->r3;
+req->data.regs.arm.arch.arm32.r4 = regs->r4;
+req->data.regs.arm.arch.arm32.r5 = regs->r5;
+req->data.regs.arm.arch.arm32.r6 = regs->r6;
+req->data.regs.arm.arch.arm32.r7 = regs->r7;
+req->data.regs.arm.arch.arm32.r8 = regs->r8;
+req->data.regs.arm.arch.arm32.r9 = regs->r9;
+req->data.regs.arm.arch.arm32.r10 = regs->r10;
+req->data.regs.arm.arch.arm32.r11 = regs->fp;
+req->data.regs.arm.arch.arm32.r12 = regs->r12;
+req->data.regs.arm.arch.arm32.r13 = regs->sp;
+req->data.regs.arm.arch.arm32.r14 = regs->lr;
+req->data.regs.arm.arch.arm32.pc = regs->pc32;
+}
+#ifdef CONFIG_ARM_64
+else
+{
+req->data.regs.arm.arch.arm64.x0 = regs->x0;
+req->data.regs.arm.arch.arm64.x1 = regs->x1;
+req->data.regs.arm.arch.arm64.x2 = regs->x2;
+req->data.regs.arm.arch.arm64.x3 = regs->x3;
+req->data.regs.arm.arch.arm64.x4 = regs->x4;
+req->data.regs.arm.arch.arm64.x5 = regs->x5;
+req->data.regs.arm.arch.arm64.x6 = regs->x6;
+req->data.regs.arm.arch.arm64.x7 = regs->x7;
+req->data.regs.arm.arch.arm64.x8 = regs->x8;
+req->data.regs.arm.arch.arm64.x9 = regs->x9;
+req->data.regs.arm.arch.arm64.x10 = regs->x10;
+req->data.regs.arm.arch.arm64.x11 = regs->x11;
+req->data.regs.arm.arch.arm64.x12 = regs->x12;
+req->data.regs.arm.arch.arm64.x13 = regs->x13;
+req->data.regs.arm.arch.arm64.x14 = regs->x14;
+req->data.regs.arm.arch.arm64.x15 = regs->x15;
+req->data.regs.arm.arch.arm64.x16 = regs->x16;
+req->data.regs.arm.arch.arm64.x17 = regs->x17;
+req->data.regs.arm.arch.arm64.x18 = regs->x18;
+req->data.regs.arm.arch.arm64.x19 = regs->x19;
+req->data.regs.arm.arch.arm64.x20 = regs->x20;
+req->data.regs.arm.arch.arm64.x21 = regs->x21;
+req->data.regs.arm.arch.arm64.x22 = regs->x22;
+req->data.regs.arm.arch.arm64.x23 = regs->x23;
+req->data.regs.arm.arch.arm64.x24 = regs->x24;
+req->data.regs.arm.arch.arm64.x25 = regs->x25;
+req->data.regs.arm.arch.arm64.x26 = regs->x26;
+req->data.regs.arm.arch.arm64.x27 = regs->x27;
+req->data.regs.arm.arch.arm64.x28 = regs->x28;
+req->data.regs.arm.arch.arm64.x29 = regs->fp;
+ 

[Xen-devel] [PATCH v8 5/6] tools/libxc: add xc_monitor_privileged_call

[Tamas K Lengyel]

These are the user-space components for the new ARM SMC events.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/libxc/include/xenctrl.h |  3 +++
 tools/libxc/xc_monitor.c  | 14 ++
 2 files changed, 17 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 4a85b4a..5249d06 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2167,6 +2167,9 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id,
  bool enable, bool sync);
 int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
 bool enable, bool sync);
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable);
+
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 264992c..61da88d 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -172,6 +172,20 @@ int xc_monitor_debug_exceptions(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, );
 }
 
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.8.1


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

Re: [Xen-devel] [PATCH v3 09/16] efi: explicitly define efi struct in xen/arch/x86/efi/stub.c

[Daniel Kiper]

On Fri, May 27, 2016 at 02:16:09AM -0600, Jan Beulich wrote:
> >>> On 25.05.16 at 18:45,  wrote:
> > On Wed, May 25, 2016 at 01:03:42AM -0600, Jan Beulich wrote:
> >> >>> On 15.04.16 at 14:33,  wrote:
> >> > Existing solution does not allocate space for this symbol and any
> >> > references to acpi20, etc. does not make sense. As I saw any efi.*
> >> > references are protected by relevant ifs but we should not do that
> >> > because it makes code very fragile. If somebody does not know how
> >> > efi symbol is created he/she may assume that it always represent
> >> > valid structure and do invalid references somewhere.
> >>
> >> I do not view this as a valid reason for the change.
> >
> > Why?
>
> Because there are no accesses to the structure in non-EFI builds?
> Even if it's just a small table, I'm generally opposed to adding dead
> code or data. I simply do not like the attitude of "memory is cheap"
> these days. Following that model leads to quite a bit of useless
> bloat. Plus no matter whether memory is cheap, cache and TLB
> bandwidth are precious, and both may get pressure added by such
> dead elements.
>
> >> > --- a/xen/arch/x86/efi/stub.c
> >> > +++ b/xen/arch/x86/efi/stub.c
> >> > @@ -8,6 +8,14 @@
> >> >  const bool_t efi_enabled = 0;
> >> >  #endif
> >> >
> >> > +struct efi __read_mostly efi = {
> >> > +.acpi= EFI_INVALID_TABLE_ADDR,
> >> > +.acpi20  = EFI_INVALID_TABLE_ADDR,
> >> > +.mps = EFI_INVALID_TABLE_ADDR,
> >> > +.smbios  = EFI_INVALID_TABLE_ADDR,
> >> > +.smbios3 = EFI_INVALID_TABLE_ADDR
> >> > +};
> >>
> >> I don't view duplicating this here as a good approach - you'd better
> >> move the existing instance elsewhere. If this was a temporary thing
> >> (until a later patch), it might be acceptable, but since building without
> >> EFI support will need to remain an option (for people using older tool
> >> chains), I don't expect a later patch to remove this.
> >
> > Do you think about separate C file which should contain efi struct
> > and should be included in stub.c and runtime.c? Or anything else?
>
> A separate file seems to be overkill. Just move it to some other
> existing file; I'm sure some sensible place can be found.

This solution is not perfect, however, I cannot find better place for
efi struct. If you have one then drop me a line.

Daniel

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

Re: [Xen-devel] [PATCH v3 12/16 - RFC] x86/efi: create new early memory allocator

[Daniel Kiper]

On Fri, Apr 15, 2016 at 02:33:12PM +0200, Daniel Kiper wrote:
> There is a problem with place_string() which is used as early memory
> allocator. It gets memory chunks starting from start symbol and
> going down. Sadly this does not work when Xen is loaded using multiboot2
> protocol because start lives on 1 MiB address. So, I tried to use
> mem_lower address calculated by GRUB2. However, it works only on some
> machines. There are machines in the wild (e.g. Dell PowerEdge R820)
> which uses first ~640 KiB for boot services code or data... :-(((
>
> In case of multiboot2 protocol we need that place_string() only allocate
> memory chunk for EFI memory map. However, I think that it should be fixed
> instead of making another function used just in one case. I thought about
> two solutions.

I have done more experiments, read more code, etc. You can find results below.

> 1) We could use native EFI allocation functions (e.g. AllocatePool()
>or AllocatePages()) to get memory chunk. However, later (somewhere
>in __start_xen()) we must copy its contents to safe place or reserve
>this in e820 memory map and map it in Xen virtual address space.

I have checked Linux kernel code. It allocates buffer for memory map using
EFI API and later reserve it in e820 memory map. Simple. This should work
for us too but...

>In later case we must also care about conflicts with e.g. crash
>kernel regions which could be quite difficult.

This is not a problem since Xen can choose dynamically placement of kdump
region during boot phase and there is no requirement to specify it in boot
command line. This means that it will avoid all allocated/reserved regions
including EFI memory map. However, there is one potential problem which
cannot be avoided simply with current EFI spec. I think about conflicts
with trampoline. It must live below 1 MiB. However, there is not something
similar to "AllocateMaxAddress" option for AllocatePages() which would
ask EFI to allocate memory above a given address (Hmmm... Why UEFI designers
did not added such option, e.g. "AllocateMinAddress"? For me it is obvious
thing if we have "AllocateMaxAddress"). So, it means that we cannot simply
say "give me a memory chunk above 1 MiB". AIUI, Linux guys do not care,
hope that all EFI platforms are smart and AllocatePages() tries hard to
avoid everything below 1 MiB. We can go this way too. However, I am almost
sure that sooner or later we will find crazy platforms which allocate memory
from 0-1 MiB region. We can avoid this by getting EFI memory map, looking for
free regions above 1 MiB and then trying to allocate memory chunk using
AllocatePages() with "AllocateAddress". Does it make sense?

> 2) We may allocate memory area statically somewhere in Xen code which
>could be used as memory pool for early dynamic allocations. Looks
>quite simple. Additionally, it would not depend on EFI at all and
>could be used on legacy BIOS platforms if we need it. However, we
>must carefully choose size of this pool. We do not want increase
>Xen binary size too much and waste too much memory but also we must fit
>at least memory map on x86 EFI platforms. As I saw on small machine,
>e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
>than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
>So, it means that we need more than 8 KiB for EFI memory map only.
>Additionally, if we want to use this memory pool for Xen and modules
>command line storage (it would be used when xen.efi is executed as EFI
>application) then we should add, I think, about 1 KiB. In this case,
>to be on safe side, we should assume at least 64 KiB pool for early
>memory allocations, which is about 4 times of our earlier calculations.
>However, during discussion on Xen-devel Jan Beulich suggested that
>just in case we should use 1 MiB memory pool like it was in original
>place_string() implementation. So, let's use 1 MiB as it was proposed.
>If we think that we should not waste unallocated memory in the pool
>on running system then we can mark this region as __initdata and move
>all required data to dynamically allocated places somewhere in 
> __start_xen().

2a) We can create something like .init.bss and put this thing at the end of
regular .bss section. Then allocate memory chunks starting from lowest
address. After init phase we can free unused memory as in case of .init.text
or .init.data sections. This way we do not need allocate any space in
image file and freeing of unused memory should be simple. What do you
think about that one?

Daniel

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

Re: [Xen-devel] [PATCH v4] xsm: add a default policy to .init.data

[Konrad Rzeszutek Wilk]

On Tue, Jul 05, 2016 at 01:44:43PM -0400, Daniel De Graaf wrote:
> This adds a Kconfig option and support for including the XSM policy from
> tools/flask/policy in the hypervisor so that the bootloader does not
> need to provide a policy to get sane behavior from an XSM-enabled
> hypervisor.  The policy provided by the bootloader, if present, will
> override the built-in policy.
> 
> The XSM policy is not moved out of tools because that remains the
> primary location for installing and configuring the policy.
> 
> Signed-off-by: Daniel De Graaf 

Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [PATCH v2 10/11] hvmctl: convert HVMOP_*ioreq_server*

[Daniel De Graaf]

On 06/24/2016 06:34 AM, Jan Beulich wrote:

Note that we can't adjust HVM_IOREQSRV_BUFIOREQ_* to properly obey
name space rules, as these constants as in use by callers of the libxc
interface.

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: Paul Durrant 
Reviewed-by: Andrew Cooper 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 09/11] hvmctl: convert HVMOP_inject_msi

[Daniel De Graaf]

On 06/24/2016 06:33 AM, Jan Beulich wrote:

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: Andrew Cooper 

Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 08/11] hvmctl: convert HVMOP_inject_trap

[Daniel De Graaf]

On 06/24/2016 06:32 AM, Jan Beulich wrote:

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: Andrew Cooper 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 07/11] hvmctl: convert HVMOP_set_mem_type

[Daniel De Graaf]

On 06/24/2016 06:32 AM, Jan Beulich wrote:

This allows elimination of the (ab)use of the high operation number
bits for encoding continuations.

Also limiting "nr" at the libxc level to 32 bits (the high 32 bits of
the previous 64-bit parameter got ignore so far).

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: Andrew Cooper 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 06/11] hvmctl: convert HVMOP_modified_memory

[Daniel De Graaf]

On 06/24/2016 06:31 AM, Jan Beulich wrote:

Also limiting "nr" at the libxc level to 32 bits (the high 32 bits of
the previous 64-bit parameter got ignore so far).

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: Andrew Cooper 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 05/11] hvmctl: convert HVMOP_track_dirty_vram

[Daniel De Graaf]

On 06/24/2016 06:31 AM, Jan Beulich wrote:

Also limiting "nr" at the libxc level to 32 bits (the high 32 bits of
the previous 64-bit parameter got ignore so far).

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: Andrew Cooper 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 04/11] hvmctl: convert HVMOP_set_pci_link_route

[Daniel De Graaf]

On 06/24/2016 06:30 AM, Jan Beulich wrote:

Note that this retains the hvmop interface definitions as those had
(wrongly) been exposed to non-tool stack consumers (albeit the
operation wouldn't have succeeded when requested by a domain for
itself).

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: Andrew Cooper 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 03/11] hvmctl: convert HVMOP_set_isa_irq_level

[Daniel De Graaf]

On 06/24/2016 06:29 AM, Jan Beulich wrote:

Note that this retains the hvmop interface definitions as those had
(wrongly) been exposed to non-tool stack consumers (albeit the
operation wouldn't have succeeded when requested by a domain for
itself).

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 
Reviewed-by: Andrew Cooper 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 01/11] public / x86: introduce hvmctl hypercall

[Daniel De Graaf]

On 06/24/2016 06:28 AM, Jan Beulich wrote:

... as a means to replace all HVMOP_* which a domain can't issue on
itself (i.e. intended for use by only the control domain or device
model).

Signed-off-by: Jan Beulich 
Reviewed-by: Wei Liu 


Acked-by: Daniel De Graaf 


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

Re: [Xen-devel] [PATCH v2 2/5] xen/console: allow log level threshold adjustments

[Daniel De Graaf]

On 07/04/2016 11:13 AM, Wei Liu wrote:

... from serial console and via sysctl so that one doesn't always need
to reboot to see more / less messages.

Note that upper thresholds driven from the serial console are sticky,
i.e. while they get adjusted upwards when the lower threshold would
otherwise end up above the upper one, they don't get adjusted when
reducing the lower one. Full flexibility is available only via the
sysctl interface.

Signed-off-by: Jan Beulich 

Rework the sysctl interface to pass in / out strings directly. Provide
some helper functions to transform from log level numbers to strings and
vice verse. Lower and upper bounds are checked. Add XSM hook.

Signed-off-by: Wei Liu 


Acked-by: Daniel De Graaf 

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

[Xen-devel] [PATCH v4] xsm: add a default policy to .init.data

[Daniel De Graaf]

This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane behavior from an XSM-enabled
hypervisor.  The policy provided by the bootloader, if present, will
override the built-in policy.

The XSM policy is not moved out of tools because that remains the
primary location for installing and configuring the policy.

Signed-off-by: Daniel De Graaf 
---

Changes from v3:
 - Make default Kconfig value depend on the presence of checkpolicy
 - Use proper __initconst label on generated data
 - Place generated symbols in xsm.h to enforce type matching

 Config.mk   |  6 ++
 INSTALL | 10 --
 docs/misc/xen-command-line.markdown | 16 +---
 docs/misc/xsm-flask.txt | 30 +++---
 xen/common/Kconfig  | 20 
 xen/include/xsm/xsm.h   |  7 +++
 xen/xsm/flask/.gitignore|  1 +
 xen/xsm/flask/Makefile  | 11 +++
 xen/xsm/flask/gen-policy.py | 23 +++
 xen/xsm/xsm_core.c  | 15 ++-
 10 files changed, 114 insertions(+), 25 deletions(-)
 create mode 100644 xen/xsm/flask/.gitignore
 create mode 100644 xen/xsm/flask/gen-policy.py

diff --git a/Config.mk b/Config.mk
index 723e129..01316ae 100644
--- a/Config.mk
+++ b/Config.mk
@@ -147,6 +147,12 @@ export XEN_HAS_BUILD_ID=y
 build_id_linker := --build-id=sha1
 endif
 
+ifndef XEN_HAS_CHECKPOLICY
+CHECKPOLICY ?= checkpolicy
+XEN_HAS_CHECKPOLICY := $(shell $(CHECKPOLICY) -h 2>&1 | grep -q xen && 
echo y || echo n)
+export XEN_HAS_CHECKPOLICY
+endif
+
 # as-insn: Check whether assembler supports an instruction.
 # Usage: cflags-y += $(call as-insn "insn",option-yes,option-no)
 as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
diff --git a/INSTALL b/INSTALL
index 616a67a..9759354 100644
--- a/INSTALL
+++ b/INSTALL
@@ -269,10 +269,16 @@ Building the python tools may fail unless certain options 
are passed to
 setup.py. Config.mk contains additional info how to use this variable.
 PYTHON_PREFIX_ARG=
 
-The hypervisor may be build with XSM/Flask support, which can be changed
+The hypervisor may be built with XSM/Flask support, which can be changed
 by running:
 make -C xen menuconfig
-and enabling XSM/Flask in the 'Common Features' menu.
+and enabling XSM/Flask in the 'Common Features' menu.  A security policy
+is required to use XSM/Flask; if the SELinux policy compiler is
+available, the policy from tools can be included in the hypervisor.
+This option is enabled by default if XSM is enabled and the compiler
+(checkpolicy) is found.  The location of this executable can be set
+using the environment variable.
+CHECKPOLICY=
 
 Do a build for coverage.
 coverage=y
diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 2a088ca..5500242 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -712,13 +712,15 @@ enabled by running either:
   with untrusted guests.  If a policy is provided by the bootloader, it will be
   loaded; errors will be reported to the ring buffer but will not prevent
   booting.  The policy can be changed to enforcing mode using "xl setenforce".
-* `enforcing`: This requires a security policy to be provided by the bootloader
-  and will enter enforcing mode prior to the creation of domain 0.  If a valid
-  policy is not provided, the hypervisor will not continue booting.
-* `late`: This disables loading of the security policy from the bootloader.
-  FLASK will be enabled but will not enforce access controls until a policy is
-  loaded by a domain using "xl loadpolicy".  Once a policy is loaded, FLASK 
will
-  run in enforcing mode unless "xl setenforce" has changed that setting.
+* `enforcing`: This will cause the security server to enter enforcing mode 
prior
+  to the creation of domain 0.  If an valid policy is not provided by the
+  bootloader and no built-in policy is present, the hypervisor will not 
continue
+  booting.
+* `late`: This disables loading of the built-in security policy or the policy
+  provided by the bootloader.  FLASK will be enabled but will not enforce 
access
+  controls until a policy is loaded by a domain using "xl loadpolicy".  Once a
+  policy is loaded, FLASK will run in enforcing mode unless "xl setenforce" has
+  changed that setting.
 * `disabled`: This causes the XSM framework to revert to the dummy module.  The
   dummy module provides the same security policy as is used when compiling the
   hypervisor without support for XSM.  The xsm\_op hypercall can also be used 
to
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 2f42585..62f15dd 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -141,21 +141,21 @@ 

Re: [Xen-devel] [RFC] Hypervisor, x86 emulation deprivileged

[Andrew Cooper]

On 05/07/16 12:22, Anthony PERARD wrote:
> Hi,
>
> I've taken over the work from Ben to have a deprivileged mode in the
> hypervisor, but I'm unsure about which direction to take.

You should begin with an evaluation of available options, identifying
which issues are mitigated, those which are not, and which which new
risks are introduced.

E.g.

1) De-privileging the x86 instruction emulator into hypervisor ring3
Issues mitigated:
* Out of bounds pointer accesses.
Issues not mitigated:
* On-stack state corruption.
Risks:
* Introduces what is basically 3rd type of vcpu, including all the
subtly that comes user processes.


Performance is strictly a secondary consideration;  Make something which
works first, then make it fast.  Never the opposite way around.

Another exercise which might be useful is to look at the recent XSAs and
identified which of them could have been mitigated by one of the
suggestions.

~Andrew

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

Re: [Xen-devel] [RFC] Hypervisor, x86 emulation deprivileged

[Anthony PERARD]

On Tue, Jul 05, 2016 at 01:58:16PM +0100, George Dunlap wrote:
> On Tue, Jul 5, 2016 at 12:22 PM, Anthony PERARD
>  wrote:
> > Hi,
> >
> > I've taken over the work from Ben to have a deprivileged mode in the
> > hypervisor, but I'm unsure about which direction to take.
> >
> > First, after understanding what have been done, and fixing a few things,
> > I did some benchmark to compare a simple "device" running in ring0 to
> > the same one running in ring3 and also in QEMU. This "device" would call
> > 'rdtsc' on 'outl' and return the value in 'inl' (I actually do not use
> > the value). The measurement is done from a kernel module in the guest
> > (simply rdtsc;inl;rdtsc multiple time). This is the result I've found:
> >
> > ring3 ~3.5x slower than ring0
> > qemu   ~22x slower than ring0
> >   ~6.5x slower than ring3
> >
> > So that would be the worst-case scenario, where an emulator barely do
> > anything.
> >
> >
> > There have been different methods proposed to do the depriv mode, in
> > <55a8d477.2060...@citrix.com>, one of which was to implement a per-vcpu
> > stack which could be more elegant.
> >
> > So, would you suggest that I start working on a per-vcpu stack? Or
> > should I continue with the current direction?
> >
> >
> > Some of the code I have, including the code for the benchmark, can be
> > found here:
> > git://xenbits.xen.org/people/aperard/xen-unstable.git
> > branch: hvm-x86-deprivileged-mode-wip
> 
> I think we need to take a step back for a minute.
> 
> Correct me if I'm wrong here: this work doesn't move the *x86
> emulation* code into ring3, but instead moves the *device emulation*
> code into ring3, is that right?

Actually, I think it would be for both. If the impact on performance is
small enough. I haven't try to move the x86 emulation into ring3.

> So the use case would be a device which we think is too complicated to
> emulate in ring0, but is too slow to emulate in qemu.
> 
> So the question is:
> 
> 1. Are there any devices currently in ring0 that we would like to be
> able to move into ring3?
> 2. Are there any devices currently in qemu that we would like to move
> into ring3?

Maybe having the pci root move from qemu to xen would help some use
cases. It has been suggested here:
https://lists.xen.org/archives/html/xen-devel/2016-06/msg00553.html



-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 3/7] x86/vm-event/monitor: don't compromise monitor_write_data on domain cleanup

[Razvan Cojocaru]

On 07/05/16 17:28, Corneliu ZUZU wrote:
> The arch_vm_event structure is dynamically allocated and freed @
> vm_event_cleanup_domain. This cleanup is triggered e.g. when the toolstack 
> user
> disables domain monitoring (xc_monitor_disable), which in turn effectively
> discards any information that was in arch_vm_event.write_data.
> 
> But this can yield unexpected behavior since if a CR-write was awaiting to be
> committed on the scheduling tail (hvm_do_resume->arch_monitor_write_data)
> before xc_monitor_disable is called, then the domain CR write is wrongfully
> ignored, which of course, in these cases, can easily render a domain crash.
> 
> To fix the issue, this patch makes arch_vm_event.emul_read_data dynamically
> allocated and only frees that in vm_event_cleanup_domain, instead of the whole
> arch_vcpu.vm_event structure, which with this patch will only be freed on
> vcpu/domain destroyal.
> 
> Signed-off-by: Corneliu ZUZU 
> Acked-by: Razvan Cojocaru 
> ---
> Changed since v1:
>   * arch_vcpu.vm_event made pointer again to avoid eating memory from 
> arch_vcpu
> structure

I believe that all acks should be presumed lost on non-trivial changes
in a new version (which I believe this qualifies as being, with all the
new logic of allocating / deallocating only part of vm_event).

Unfortunately I'm out of office until early next week so I can't
properly test / thoroughly parse this until then, but we should be extra
careful that there are several places in the code where it is assumed
that v->arch.vm_event != NULL is the same thing as monitoring being
enabled. I'm not saying that they're not treated in this patch (the
proper change has certainly been made in emulate.c), I'm just saying
that we should be careful that they are.

Having said that, I propose a special macro to make this all clearer,
something like:

#define is_monitor_enabled_for_vcpu(v) \
( v->arch.vm_event && v->arch.vm_event->emul_read_data )

or equivalent inline functions returning a bool_t. Just a thought.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Stefano Stabellini]

On Thu, 23 Jun 2016, Julien Grall wrote:
> Hi Shannon,
> 
> On 23/06/2016 04:17, Shannon Zhao wrote:
> > From: Shannon Zhao 
> > 
> > Copy all the ACPI tables to guest space so that UEFI or guest could
> > access them.
> > 
> > Signed-off-by: Shannon Zhao 
> > ---
> >  tools/libxc/xc_dom_arm.c | 51
> > 
> >  1 file changed, 51 insertions(+)
> > 
> > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > index 64a8b67..6a0a5b7 100644
> > --- a/tools/libxc/xc_dom_arm.c
> > +++ b/tools/libxc/xc_dom_arm.c
> > @@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)
> > 
> >  /* 
> > */
> > 
> > +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
> > +{
> > +int rc, i;
> > +uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
> > + XC_PAGE_SHIFT;
> > +const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
> > +xen_pfn_t *p2m;
> > +void *acpi_pages;
> > +
> > +p2m = malloc(pages_num * sizeof(*p2m));
> > +for (i = 0; i < pages_num; i++)
> > +p2m[i] = base + i;
> > +
> > +rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
> > +  pages_num, 0, 0, p2m);
> 
> H... it looks like this is working because libxl is setting the maximum
> size of the domain with some slack (1MB). However, I guess the slack was for
> something else. Wei, Stefano, Ian, can you confirm?

If I recall correctly, the slack is a magic value coming from the
ancient history of toolstacks.

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

Re: [Xen-devel] [RFC] Hypervisor, x86 emulation deprivileged

[Anthony PERARD]

On Tue, Jul 05, 2016 at 07:02:39AM -0600, Jan Beulich wrote:
> >>> On 05.07.16 at 13:22,  wrote:
> > Hi,
> > 
> > I've taken over the work from Ben to have a deprivileged mode in the
> > hypervisor, but I'm unsure about which direction to take.
> > 
> > First, after understanding what have been done, and fixing a few things,
> > I did some benchmark to compare a simple "device" running in ring0 to
> > the same one running in ring3 and also in QEMU. This "device" would call
> > 'rdtsc' on 'outl' and return the value in 'inl' (I actually do not use
> > the value). The measurement is done from a kernel module in the guest
> > (simply rdtsc;inl;rdtsc multiple time). This is the result I've found:
> > 
> > ring3 ~3.5x slower than ring0
> > qemu   ~22x slower than ring0
> >   ~6.5x slower than ring3
> > 
> > So that would be the worst-case scenario, where an emulator barely do
> > anything.
> > 
> > 
> > There have been different methods proposed to do the depriv mode, in
> > <55a8d477.2060...@citrix.com>, one of which was to implement a per-vcpu
> > stack which could be more elegant.
> 
> Sadly my mail frontend doesn't let me search for message IDs (and
> this old a mail would have been purged anyway meanwhile), so I
> think (also considering how much time has passed) it would be better
> if you actually summarized where things stopped back then.

https://lists.xen.org/archives/html/xen-devel/2015-07/msg03507.html

It has been said that a per-vcpu stack would be too much work for a
short term project.

> > So, would you suggest that I start working on a per-vcpu stack? Or
> > should I continue with the current direction?
> 
> Was there any reason why using per-vCPU stacks would be assumed
> to meaningfully improve above numbers?

Probably not. I guess the context switch alone takes most time, and it
does not matter where the stack is and if there is a copy of it.

> I'm not sure pursuing this
> idea is really useful if more than a marginal performance degradation
> results.

Maybe the instruction emulator would be big enough that the impact of a
context swith would not matter as much? I don't know much about it so I
can not make a guess of how much code is running.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Stefano Stabellini]

On Mon, 27 Jun 2016, Julien Grall wrote:
> Hi Shannon,
> 
> On 27/06/16 02:44, Shannon Zhao wrote:
> > On 2016/6/24 0:26, Julien Grall wrote:
> > > On 23/06/16 04:16, Shannon Zhao wrote:
> > > > From: Shannon Zhao 
> > > > 
> > > > Construct GTDT table with the interrupt information of timers.
> > > > 
> > > > Signed-off-by: Shannon Zhao 
> > > > ---
> > > >tools/libxl/libxl_arm_acpi.c | 28 
> > > >1 file changed, 28 insertions(+)
> > > > 
> > > > diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> > > > index d5ffedf..de863f4 100644
> > > > --- a/tools/libxl/libxl_arm_acpi.c
> > > > +++ b/tools/libxl/libxl_arm_acpi.c
> > > > @@ -39,6 +39,9 @@ typedef uint64_t u64;
> > > >#define ACPI_BUILD_APPNAME6 "XenARM"
> > > >#define ACPI_BUILD_APPNAME4 "Xen "
> > > > 
> > > > +#define ACPI_LEVEL_SENSITIVE(u8) 0x00
> > > > +#define ACPI_ACTIVE_LOW (u8) 0x01
> > > > +
> > > 
> > > Why did not you include actypes.h rather than define these two defines?
> > If we include actypes.h, there will be some compiling errors.
> > 
> > ../../xen/include/acpi/actypes.h:55:2: error: #error ACPI_MACHINE_WIDTH
> > not defined
> >   #error ACPI_MACHINE_WIDTH not defined
> >^
> > ../../xen/include/acpi/actypes.h:130:9: error: unknown type name
> > 'COMPILER_DEPENDENT_UINT64'
> >   typedef COMPILER_DEPENDENT_UINT64 UINT64;
> >   ^
> > ../../xen/include/acpi/actypes.h:131:9: error: unknown type name
> > 'COMPILER_DEPENDENT_INT64'
> >   typedef COMPILER_DEPENDENT_INT64 INT64;
> >   ^
> > ../../xen/include/acpi/actypes.h:202:2: error: #error unknown
> > ACPI_MACHINE_WIDTH
> >   #error unknown ACPI_MACHINE_WIDTH
> >^
> > ../../xen/include/acpi/actypes.h:207:9: error: unknown type name
> > 'acpi_native_uint'
> >   typedef acpi_native_uint acpi_size;
> >   ^
> > ../../xen/include/acpi/actypes.h:617:3: error: unknown type name
> > 'acpi_io_address'
> > acpi_io_address pblk_address;
> > 
> > Yeah, it maybe can be solved by defining ACPI_MACHINE_WIDTH and
> > COMPILER_DEPENDENT_INT64 here, but since we only needs
> > ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW, I think it's ok to define them
> > here.
> 
> We should avoid to redefine value as much as possible. The 2 missing values
> are easy to define (see below) so there is no point to redefine in a less
> obvious way: no comment to explain what the values are for, and only a part of
> the set defined.
> 
> #define ACPI_MACHINE_WIDTH BITS_PER_LONG
> #define COMPILER_DEPENDENT_INT64 int64_t
> 
> Wei, Ian, Stefano, do you have any opinions?

I think you are right that we should avoid redefining
ACPI_LEVEL_SENSITIVE and ACPI_ACTIVE_LOW. But I think if possible we
should also avoid redefining ACPI_MACHINE_WIDTH and
COMPILER_DEPENDENT_INT64. If possible, we should include the header file
with those definitions too (acpi/platform/acenv.h ?).

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

[Xen-devel] [qemu-mainline test] 96652: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 94856
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
94856
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 94856
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
94856
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 94856
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 94856
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 94856
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 94856
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 94856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94856
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94856
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94856

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu11659423113d2fbcf055085b5e8285d590addfaa
baseline version:
 qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe

Last test of basis94856  2016-05-27 20:14:49 Z   38 days
Failing since 94983  2016-05-31 09:40:12 Z   35 days   50 attempts
Testing same since96652  2016-07-04 21:14:18 Z0 days1 attempts


People who touched revisions under test:
  Aaron Larson 
  Alberto Garcia 
  Aleksandar Markovic 
  Alex Bennée 
  Alex Bligh 
  Alex Williamson 
  Alexander Graf 
  Alexander Shopov 
  Alexey Kardashevskiy 
  Alistair Francis 
  Amit Shah 
  Andrea Arcangeli 
  Andrew Jeffery 
  Andrew Jones 
  Andrey Smirnov 
  Aneesh Kumar K.V 

Re: [Xen-devel] [PATCH v3 1/2] Interface for grant copy operation in libs.

[George Dunlap]

On Wed, Jun 22, 2016 at 3:52 PM, Wei Liu  wrote:
>> I think the best solution is to allow the osdep code to provide the
>> implementation of xengnttab_grant_copy_segment_t, allowing the Linux
>> code to do:
>>
>> typedef ioctl_gntdev_grant_copy_segment xengnttab_grant_copy_segment_t
>>
>> You should still provide the generic structure as well, for those
>> platforms that don't provide their own optimized version.
>>
>
> We can't do that (yet). This means we open the door for divergence on
> different platforms.
>
> Basically this approach requires each platform to do the same thing
> (typedef) This implies any application that uses libxengnttab will need
> to test what platform it runs on. It is just pushing the issue somewhere
> else.
>
> Still, I think I would wait a bit for other people to weight in because
> I'm not sure if my concern is wrong headed.

I tend to be sympathetic to David's argument here.  The library has to
provide some ABI to callers; and it has to know the appropriate Linux
ABI in order to translate from the library ABI to the Linux ABI.  If
it happens to know these are the same, I don't see a reason not to
"translate" it by just by casting the pointer.

If we want to declare the library ABI in a stand-alone fashion (i.e.,
instead of just doing a typedef, so that the library definition is the
same on all platforms), then having some compile-time checking to make
sure that the layouts of the two structures are identical makes sense.
Beyond that, I'm not sure what the extra copying really buys us.

 -George

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

Re: [Xen-devel] [PATCH v2 6/7] minor fixes (formatting, comments, unused includes etc.)

[Razvan Cojocaru]

On 07/05/16 17:30, Corneliu ZUZU wrote:
> Minor fixes:
>  - remove some empty lines
>  - remove some unused includes
>  - multi-line comment fixes
>  - 80-columns formatting fixes
> 
> Signed-off-by: Corneliu ZUZU 
> ---
> Changed since v1: 
> ---
>  xen/arch/arm/domain.c |  1 -
>  xen/arch/arm/traps.c  |  1 -
>  xen/arch/x86/hvm/hvm.c|  3 ---
>  xen/arch/x86/hvm/vmx/vmx.c|  1 -
>  xen/arch/x86/monitor.c|  1 -
>  xen/arch/x86/vm_event.c   |  3 ---
>  xen/common/monitor.c  |  1 -
>  xen/common/vm_event.c |  6 --
>  xen/include/asm-arm/vm_event.h|  9 +++--
>  xen/include/asm-x86/hvm/monitor.h |  1 -
>  xen/include/asm-x86/monitor.h |  3 ---
>  xen/include/asm-x86/vm_event.h|  1 -
>  xen/include/public/vm_event.h | 38 +++---
>  xen/include/xen/vm_event.h|  1 -
>  14 files changed, 26 insertions(+), 44 deletions(-)

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

[Xen-devel] [PULL v2 01/30] xen: fix ram init regression

[Michael S. Tsirkin]

From: Gerd Hoffmann 

Commit "8156d48 pc: allow raising low memory via max-ram-below-4g
option" causes a regression on xen, because it uses a different
memory split.

This patch initializes max-ram-below-4g to zero and leaves the
initialization to the memory initialization functions.  That way
they can pick different default values (max-ram-below-4g is zero
still) or use the user supplied value (max-ram-below-4g is non-zero).

Also skip the whole ram split calculation on Xen.  xen_ram_init()
does its own split calculation anyway so it is superfluous, also
this way xen_ram_init can actually see whenever max-ram-below-4g
is zero or not.

Reported-by: Anthony PERARD 
Tested-by: Anthony PERARD 
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/i386/pc.c  |  2 +-
 hw/i386/pc_piix.c | 50 --
 hw/i386/pc_q35.c  |  3 +++
 xen-hvm.c |  3 +++
 4 files changed, 35 insertions(+), 23 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 44a8f3b..cd1745e 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1919,7 +1919,7 @@ static void pc_machine_initfn(Object *obj)
 pc_machine_get_hotplug_memory_region_size,
 NULL, NULL, NULL, _abort);
 
-pcms->max_ram_below_4g = 0xe000; /* 3.5G */
+pcms->max_ram_below_4g = 0; /* use default */
 object_property_add(obj, PC_MACHINE_MAX_RAM_BELOW_4G, "size",
 pc_machine_get_max_ram_below_4g,
 pc_machine_set_max_ram_below_4g,
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index c7d70af..a07dc81 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -108,37 +108,43 @@ static void pc_init1(MachineState *machine,
  *so legacy non-PAE guests can get as much memory as possible in
  *the 32bit address space below 4G.
  *
+ *  - Note that Xen has its own ram setp code in xen_ram_init(),
+ *called via xen_hvm_init().
+ *
  * Examples:
  *qemu -M pc-1.7 -m 4G(old default)-> 3584M low,  512M high
  *qemu -M pc -m 4G(new default)-> 3072M low, 1024M high
  *qemu -M pc,max-ram-below-4g=2G -m 4G -> 2048M low, 2048M high
  *qemu -M pc,max-ram-below-4g=4G -m 3968M  -> 3968M low (=4G-128M)
  */
-lowmem = pcms->max_ram_below_4g;
-if (machine->ram_size >= pcms->max_ram_below_4g) {
-if (pcmc->gigabyte_align) {
-if (lowmem > 0xc000) {
-lowmem = 0xc000;
-}
-if (lowmem & ((1ULL << 30) - 1)) {
-error_report("Warning: Large machine and max_ram_below_4g "
- "(%" PRIu64 ") not a multiple of 1G; "
- "possible bad performance.",
- pcms->max_ram_below_4g);
+if (xen_enabled()) {
+xen_hvm_init(pcms, _memory);
+} else {
+if (!pcms->max_ram_below_4g) {
+pcms->max_ram_below_4g = 0xe000; /* default: 3.5G */
+}
+lowmem = pcms->max_ram_below_4g;
+if (machine->ram_size >= pcms->max_ram_below_4g) {
+if (pcmc->gigabyte_align) {
+if (lowmem > 0xc000) {
+lowmem = 0xc000;
+}
+if (lowmem & ((1ULL << 30) - 1)) {
+error_report("Warning: Large machine and max_ram_below_4g "
+ "(%" PRIu64 ") not a multiple of 1G; "
+ "possible bad performance.",
+ pcms->max_ram_below_4g);
+}
 }
 }
-}
 
-if (machine->ram_size >= lowmem) {
-pcms->above_4g_mem_size = machine->ram_size - lowmem;
-pcms->below_4g_mem_size = lowmem;
-} else {
-pcms->above_4g_mem_size = 0;
-pcms->below_4g_mem_size = machine->ram_size;
-}
-
-if (xen_enabled()) {
-xen_hvm_init(pcms, _memory);
+if (machine->ram_size >= lowmem) {
+pcms->above_4g_mem_size = machine->ram_size - lowmem;
+pcms->below_4g_mem_size = lowmem;
+} else {
+pcms->above_4g_mem_size = 0;
+pcms->below_4g_mem_size = machine->ram_size;
+}
 }
 
 pc_cpus_init(pcms);
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 04b2684..cd57bce 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -94,6 +94,9 @@ static void pc_q35_init(MachineState *machine)
 /* Handle the machine opt max-ram-below-4g.  It is basically doing
  * min(qemu limit, user limit).
  */
+if (!pcms->max_ram_below_4g) {
+pcms->max_ram_below_4g = 1ULL << 32; /* default: 4G */;
+}
 if (lowmem > pcms->max_ram_below_4g) {
 lowmem = 

Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

[Jan Beulich]

>>> On 05.07.16 at 17:34,  wrote:
> On Thu, Jun 30, 2016 at 03:10:11AM -0600, Jan Beulich wrote:
>> >>> On 29.06.16 at 18:27,  wrote:
>> > On 29/06/16 17:19, Vitaly Kuznetsov wrote:
>> >> To explain better what I'm trying to suggest here please take a look at
>> >> the attached patch. If we can guarantee long term that ACPI id always
>> >> equals to Xen's idea of vCPU id this is probably the easiest way.
>> >>
>> >> -- Vitaly
>> > 
>> > The code in hvmloader which sets up the MADT does:
>> > 
>> > for ( i = 0; i < hvm_info->nr_vcpus; i++ )
>> > {
>> > memset(lapic, 0, sizeof(*lapic));
>> > lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
>> > lapic->length  = sizeof(*lapic);
>> > /* Processor ID must match processor-object IDs in the DSDT. */
>> > lapic->acpi_processor_id = i;
>> > lapic->apic_id = LAPIC_ID(i);
>> > lapic->flags = (test_bit(i, hvm_info->vcpu_online)
>> > ? ACPI_LOCAL_APIC_ENABLED : 0);
>> > lapic++;
>> > }
>> > 
>> > So relying on the acpi_processor_id does look to be reliable.  That code
>> > hasn't changed since 2007, and that was only a bugfix.  I would go so
>> > far as to say it is reasonable for us to guarantee this in the guest ABI.
>> 
>> In fact - is there any other way a guest could learn the vCPU IDs
>> of its CPUs in a reliable way? I don't think so, and hence this de
>> facto already is part of the ABI; we should of course spell it out
>> somewhere.
> 
> CCing Joao.
> 
> Joao worked (and I think he posted an RFC patchset?) where this is changed so
> that the true hardware topology (core, thread, etc) is exposed. This is 
> obviously
> for cases where you want pinning.
> 
> I would hesistate to spell this out as an ABI..

Are you perhaps mixing up ACPI and APIC IDs? Here talk is of the
former, while Joao's patch set was about the latter iirc.

Jan


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

Re: [Xen-devel] [PATCH 11/18] arm/altp2m: Make flush_tlb_domain ready for altp2m.

[Julien Grall]

On 05/07/16 15:48, Sergej Proskurin wrote:

On 07/04/2016 10:32 PM, Julien Grall wrote:

On 04/07/2016 12:45, Sergej Proskurin wrote:

+p2m_load_altp2m_VTTBR(n);
+else
+p2m_load_VTTBR(n->domain);
+
  isb();

  if ( is_32bit_domain(n->domain) )
@@ -119,22 +154,42 @@ void p2m_restore_state(struct vcpu *n)
  void flush_tlb_domain(struct domain *d)
  {
  unsigned long flags = 0;
+struct vcpu *v = NULL;

-/* Update the VTTBR if necessary with the domain d. In this case,
- * it's only necessary to flush TLBs on every CPUs with the
current VMID
- * (our domain).
+/*
+ * Update the VTTBR if necessary with the domain d. In this
case, it is only
+ * necessary to flush TLBs on every CPUs with the current VMID (our
+ * domain).
   */
  if ( d != current->domain )
  {
  local_irq_save(flags);
-p2m_load_VTTBR(d);
-}

-flush_tlb();
+/* If altp2m is active, update VTTBR and flush TLBs of every
VCPU */
+if ( altp2m_active(d) )
+{
+for_each_vcpu( d, v )
+{
+p2m_load_altp2m_VTTBR(v);
+flush_tlb();
+}
+}
+else
+{
+p2m_load_VTTBR(d);
+flush_tlb();
+}


Why do you need to do a such things? If the VMID is the same, a single
call to flush_tlb() will nuke all the entries for the given TLBs.

If the VMID is not shared, then I am not even sure why you would need
to flush the TLBs for all the altp2ms.



If the VMID is shared between multiple views and we would change one
entry in one specific view, we might reuse an entry that is not part of
the currently active altp2m view of the domain. And even if we assign
unique VMIDs to the individual altp2m views (as discussed in patch #04),
as far as I understand, we will still need to flush the mappings of all
altp2ms at this point because (AFAIK) changes in individual altp2m views
will still need to be propagated to the TLBs. Please correct me, if I am
wrong at this point.


You seem to be really confused how TLB flush instructions work on ARM.
The function flush_tlb() will flush TLBs on all the processor for the 
current VMID. If the VMID is shared, then calling N-times the flush with 
the same VMID will just be a waste of processor cycle.


Now, if the VMID is not shared (and based on your current series):
flush_tlb_domain is called in two places:
   - p2m_alloc_table
   - apply_p2m_changes

For the former, it allocates root table for a specific p2m. For the 
latter, the changes is only done for a specific p2m, and those changes 
are currently not replicated in all the p2ms. So flushing the TLBs for 
each altp2m view do not seem useful here too.





I have looked to Xen with this series applied and noticed that when
you remove a page from the hostp2m, the mapping in the altp2m is not
removed. So the guest may use a page that would have been freed
previously. Did I miss something?



When altp2m is active, the hostp2m is not used. All changes are applied
directly to the individual altp2m views. As far as I know, the only
situations, where a mapping is removed from a specific p2m view is in
the functions unmap_regions_rw_cache, unmap_mmio_regions, and
guest_physmap_remove_page. Each one of these functions provide, however
the hostp2m to the function apply_p2m_changes, where the mapping is
eventually removed. So, we definitely remove mappings from the hostp2m.
However, these would not be removed from the associated altp2m views.

Can you state a scenario, when and why pages might need to be removed at
run time from the hostp2m? In that case, maybe it would make sense to
extend the three functions (unmap_regions_rw_cache, unmap_mmio_regions,
and guest_physmap_remove_page) to additionally remove the mappings from
all available altp2m views?


All the functions, you mentioned can be called after the domain has been 
created. If you grep guest_physmap_remove_page in the code source, you 
will find that it is used to unmap grant entry from the memory (see 
replace_grant_host_mapping) or when decreasing the memory reservation 
(see do_memory_op).


Note that, from my understanding, x86 has the same problem.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] xsm: add a default policy to .init.data

[Konrad Rzeszutek Wilk]

On Fri, Jul 01, 2016 at 01:19:51AM -0600, Jan Beulich wrote:
> >>> On 30.06.16 at 17:13,  wrote:
> > On Thu, Jun 30, 2016 at 10:01:18AM -0400, Daniel De Graaf wrote:
> >> On 06/30/2016 09:45 AM, Konrad Rzeszutek Wilk wrote:
> >> > On Wed, Jun 29, 2016 at 11:09:01AM -0400, Daniel De Graaf wrote:
> >> > > --- a/xen/xsm/xsm_core.c
> >> > > +++ b/xen/xsm/xsm_core.c
> >> > > @@ -36,6 +36,24 @@ static inline int verify(struct xsm_operations *ops)
> >> > >  return 0;
> >> > >  }
> >> > > 
> >> > > +#ifdef CONFIG_XSM_POLICY
> >> > > +extern char xsm_init_policy[];
> >> > 
> >> > > +extern int xsm_init_policy_size;
> >> > > +#else
> >> > > +#define xsm_init_policy 0
> >> > > +#endif
> >> > > +
> >> > > +static void __init xsm_policy_init(void)
> >> > > +{
> >> > > +#ifdef CONFIG_XSM_POLICY
> >> > > +if ( policy_size == 0 )
> >> > > +{
> >> > > +policy_buffer = xsm_init_policy;
> >> > > +policy_size = xsm_init_policy_size;
> >> > > +}
> >> > > +#endif
> >> > > +}
> >> > > +
> >> > 
> >> > This all looks like it could go in a header file?
> >> 
> >> Sure, I could move it to xsm.h.  I thought it might be clearer to have the
> >> assignment and the xfree() check in the same file.
> > 
> > You are the maintainer of that code, so it is your call.
> > 
> > Having externs in C code is not that great (from my perspective),
> > so if you move all of this to a header file that should get easier?
> 
> I agree, fwiw, for the extern-s to be moved to a header. That
> header should then also be included by the generated source
> file producing the symbols. I don't, however, see why the
> function should go to a header.

I was thinking that since the function is a nop under #CONFIG_XSM_POLICY
you could just make it an inline static function, like:

#ifdef CONFIG_XSM_POLICY
static inline void  xsm_policy_init(void)
{...
}
#else
#define xsm_policy_init(void) ;
#endif

Or such.


But this is really minor, and pls ignore it if means doing more work than
neccessary.

> 
> Jan
> 

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

Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

[Konrad Rzeszutek Wilk]

On Thu, Jun 30, 2016 at 03:10:11AM -0600, Jan Beulich wrote:
> >>> On 29.06.16 at 18:27,  wrote:
> > On 29/06/16 17:19, Vitaly Kuznetsov wrote:
> >> To explain better what I'm trying to suggest here please take a look at
> >> the attached patch. If we can guarantee long term that ACPI id always
> >> equals to Xen's idea of vCPU id this is probably the easiest way.
> >>
> >> -- Vitaly
> > 
> > The code in hvmloader which sets up the MADT does:
> > 
> > for ( i = 0; i < hvm_info->nr_vcpus; i++ )
> > {
> > memset(lapic, 0, sizeof(*lapic));
> > lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
> > lapic->length  = sizeof(*lapic);
> > /* Processor ID must match processor-object IDs in the DSDT. */
> > lapic->acpi_processor_id = i;
> > lapic->apic_id = LAPIC_ID(i);
> > lapic->flags = (test_bit(i, hvm_info->vcpu_online)
> > ? ACPI_LOCAL_APIC_ENABLED : 0);
> > lapic++;
> > }
> > 
> > So relying on the acpi_processor_id does look to be reliable.  That code
> > hasn't changed since 2007, and that was only a bugfix.  I would go so
> > far as to say it is reasonable for us to guarantee this in the guest ABI.
> 
> In fact - is there any other way a guest could learn the vCPU IDs
> of its CPUs in a reliable way? I don't think so, and hence this de
> facto already is part of the ABI; we should of course spell it out
> somewhere.

CCing Joao.

Joao worked (and I think he posted an RFC patchset?) where this is changed so
that the true hardware topology (core, thread, etc) is exposed. This is 
obviously
for cases where you want pinning.

I would hesistate to spell this out as an ABI..

P.S.
Which reminds me, Joao, you OK posting the patchset?
> 
> Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v2 7/7] minor #include change

[Razvan Cojocaru]

On 07/05/16 17:31, Corneliu ZUZU wrote:
> Move xen/paging.h #include from hvm/monitor.h to hvm/monitor.c (include 
> strictly
> where needed) and also change to asm/paging.h (include strictly what's 
> needed).
> 
> Signed-off-by: Corneliu ZUZU 
> ---
> Changed since v1:
>   * preserve alphabetical ordering
> ---
>  xen/arch/x86/hvm/monitor.c| 1 +
>  xen/include/asm-x86/hvm/monitor.h | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)


Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 3/3] xen: support runqueue steal time on xen

[Stefano Stabellini]

On Wed, 22 Jun 2016, Juergen Gross wrote:
> Up to now reading the stolen time of a remote cpu was not possible in a
> performant way under Xen. This made support of runqueue steal time via
> paravirt_steal_rq_enabled impossible.
> 
> With the addition of an appropriate hypervisor interface this is now
> possible, so add the support.
> 
> Signed-off-by: Juergen Gross 
> ---
>  drivers/xen/time.c | 42 +-
>  1 file changed, 25 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index 2257b66..65afbe9 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -19,6 +19,9 @@
>  /* runstate info updated by Xen */
>  static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
>  
> +/* runstate info of remote cpu accessible */
> +static bool xen_runstate_remote;

Honestly I would rather have one global variable less if it means only
dropping one BUG_ON.


>  /* return an consistent snapshot of 64-bit time/counter value */
>  static u64 get64(const u64 *p)
>  {
> @@ -47,27 +50,31 @@ static u64 get64(const u64 *p)
>   return ret;
>  }
>  
> -/*
> - * Runstate accounting
> - */
> -void xen_get_runstate_snapshot(struct vcpu_runstate_info *res)
> +static void xen_get_runstate_snapshot_cpu(struct vcpu_runstate_info *res,
> +   unsigned int cpu)
>  {
>   u64 state_time;
>   struct vcpu_runstate_info *state;
>  
>   BUG_ON(preemptible());
>  
> - state = this_cpu_ptr(_runstate);
> + state = per_cpu_ptr(_runstate, cpu);
>  
> - /*
> -  * The runstate info is always updated by the hypervisor on
> -  * the current CPU, so there's no need to use anything
> -  * stronger than a compiler barrier when fetching it.
> -  */
>   do {
>   state_time = get64(>state_entry_time);
> + rmb();  /* Hypervisor might update data. */
>   *res = READ_ONCE(*state);
> - } while (get64(>state_entry_time) != state_time);
> + rmb();  /* Hypervisor might update data. */
> + } while (get64(>state_entry_time) != state_time ||
> +  (state_time & XEN_RUNSTATE_UPDATE));
> +}
> +
> +/*
> + * Runstate accounting
> + */
> +void xen_get_runstate_snapshot(struct vcpu_runstate_info *res)
> +{
> + xen_get_runstate_snapshot_cpu(res, smp_processor_id());
>  }
>  
>  /* return true when a vcpu could run but has no real cpu to run on */
> @@ -80,8 +87,8 @@ static u64 xen_steal_clock(int cpu)
>  {
>   struct vcpu_runstate_info state;
>  
> - BUG_ON(cpu != smp_processor_id());
> - xen_get_runstate_snapshot();
> + BUG_ON(!xen_runstate_remote && cpu != smp_processor_id());
> + xen_get_runstate_snapshot_cpu(, cpu);
>   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
>  }
>  
> @@ -98,11 +105,12 @@ void xen_setup_runstate_info(int cpu)
>  
>  void __init xen_time_setup_guest(void)
>  {
> + xen_runstate_remote = !HYPERVISOR_vm_assist(VMASST_CMD_enable,
> + VMASST_TYPE_runstate_update_flag);
> +
>   pv_time_ops.steal_clock = xen_steal_clock;
>  
>   static_key_slow_inc(_steal_enabled);
> - /*
> -  * We can't set paravirt_steal_rq_enabled as this would require the
> -  * capability to read another cpu's runstate info.
> -  */
> + if (xen_runstate_remote)
> + static_key_slow_inc(_steal_rq_enabled);
>  }

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

Re: [Xen-devel] [PATCH 1/3] xen: update xen headers

[Stefano Stabellini]

On Wed, 22 Jun 2016, Juergen Gross wrote:
> Update some Xen headers to be able to use new functionality.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Stefano Stabellini 


>  include/xen/interface/vcpu.h | 24 +++-
>  include/xen/interface/xen.h  | 17 -
>  2 files changed, 31 insertions(+), 10 deletions(-)
> 
> diff --git a/include/xen/interface/vcpu.h b/include/xen/interface/vcpu.h
> index b05288c..98188c8 100644
> --- a/include/xen/interface/vcpu.h
> +++ b/include/xen/interface/vcpu.h
> @@ -75,15 +75,21 @@
>   */
>  #define VCPUOP_get_runstate_info  4
>  struct vcpu_runstate_info {
> - /* VCPU's current state (RUNSTATE_*). */
> - int  state;
> - /* When was current state entered (system time, ns)? */
> - uint64_t state_entry_time;
> - /*
> -  * Time spent in each RUNSTATE_* (ns). The sum of these times is
> -  * guaranteed not to drift from system time.
> -  */
> - uint64_t time[4];
> + /* VCPU's current state (RUNSTATE_*). */
> + int  state;
> + /* When was current state entered (system time, ns)? */
> + uint64_t state_entry_time;
> + /*
> +  * Update indicator set in state_entry_time:
> +  * When activated via VMASST_TYPE_runstate_update_flag, set during
> +  * updates in guest memory mapped copy of vcpu_runstate_info.
> +  */
> +#define XEN_RUNSTATE_UPDATE  (1ULL << 63)
> + /*
> +  * Time spent in each RUNSTATE_* (ns). The sum of these times is
> +  * guaranteed not to drift from system time.
> +  */
> + uint64_t time[4];
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(vcpu_runstate_info);
>  
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index d133112..1b0d189 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -413,7 +413,22 @@ DEFINE_GUEST_HANDLE_STRUCT(mmuext_op);
>  /* x86/PAE guests: support PDPTs above 4GB. */
>  #define VMASST_TYPE_pae_extended_cr3 3
>  
> -#define MAX_VMASST_TYPE 3
> +/*
> + * x86 guests: Sane behaviour for virtual iopl
> + *  - virtual iopl updated from do_iret() hypercalls.
> + *  - virtual iopl reported in bounce frames.
> + *  - guest kernels assumed to be level 0 for the purpose of iopl checks.
> + */
> +#define VMASST_TYPE_architectural_iopl   4
> +
> +/*
> + * All guests: activate update indicator in vcpu_runstate_info
> + * Enable setting the XEN_RUNSTATE_UPDATE flag in guest memory mapped
> + * vcpu_runstate_info during updates of the runstate information.
> + */
> +#define VMASST_TYPE_runstate_update_flag 5
> +
> +#define MAX_VMASST_TYPE 5
>  
>  #ifndef __ASSEMBLY__
>  
> -- 
> 2.6.6
> 

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

Re: [Xen-devel] [PATCH 2/3] arm/xen: add support for vm_assist hypercall

[Stefano Stabellini]

On Wed, 22 Jun 2016, Juergen Gross wrote:
> Add support for the Xen HYPERVISOR_vm_assist hypercall.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Stefano Stabellini 


>  arch/arm/include/asm/xen/hypercall.h | 1 +
>  arch/arm/xen/enlighten.c | 1 +
>  arch/arm/xen/hypercall.S | 1 +
>  arch/arm64/xen/hypercall.S   | 1 +
>  4 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h 
> b/arch/arm/include/asm/xen/hypercall.h
> index b6b962d..9d874db 100644
> --- a/arch/arm/include/asm/xen/hypercall.h
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -52,6 +52,7 @@ int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
>  int HYPERVISOR_physdev_op(int cmd, void *arg);
>  int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
>  int HYPERVISOR_tmem_op(void *arg);
> +int HYPERVISOR_vm_assist(unsigned int cmd, unsigned int type);
>  int HYPERVISOR_platform_op_raw(void *arg);
>  static inline int HYPERVISOR_platform_op(struct xen_platform_op *op)
>  {
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 71db30c..0f3aa12 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -389,4 +389,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
>  EXPORT_SYMBOL_GPL(privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index 9a36f4f..a648dfc 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -91,6 +91,7 @@ HYPERCALL3(vcpu_op);
>  HYPERCALL1(tmem_op);
>  HYPERCALL1(platform_op_raw);
>  HYPERCALL2(multicall);
> +HYPERCALL2(vm_assist);
>  
>  ENTRY(privcmd_call)
>   stmdb sp!, {r4}
> diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> index 70df80e..329c802 100644
> --- a/arch/arm64/xen/hypercall.S
> +++ b/arch/arm64/xen/hypercall.S
> @@ -82,6 +82,7 @@ HYPERCALL3(vcpu_op);
>  HYPERCALL1(tmem_op);
>  HYPERCALL1(platform_op_raw);
>  HYPERCALL2(multicall);
> +HYPERCALL2(vm_assist);
>  
>  ENTRY(privcmd_call)
>   mov x16, x0
> -- 
> 2.6.6
> 

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

Re: [Xen-devel] [PATCH v5 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Jan Beulich]

>>> On 05.07.16 at 16:35,  wrote:
> On Thu, Jun 23, 2016 at 4:42 PM, Tamas K Lengyel  wrote:
 +if ( !atomic_read(>pause_count) ||
 + !atomic_read(>pause_count) )
 +{
 +rcu_unlock_domain(cd);
 +rc = -EINVAL;
 +goto out;
 +}
>>>
>>> I realize that Jan asked for this, but I'm really not sure what good
>>> this is supposed to do, since the guest can be un-paused at any point
>>> halfway through the transaction.
>>>
>>> Wouldn't it make more sense to have this function pause and unpause
>>> the domains itself?
>>
>> The domains are paused by the user when this op is called, so this is
>> just a sanity check ensuring you are not issuing the op on some other
>> domain. So if this function would pause the domain as well all it
>> would do is increase the pause count. This is the only intended
>> use-case for this function at this time. It would make no sense to try
>> to issue this op on domains that are running, as that pretty much
>> guarantee that some of their memory has already diverged, and thus
>> bulk-sharing their memory would have some unintended side-effects.
> 
> Yes, I understand all that.  But what I'm saying (and mostly this is
> actually to Jan that I'm saying it) is that this check, as written,
> seems pointless to me.  We're effectively *not* trusting the toolstack
> to pause the domain, but we *are* trust the toolstack not to unpause
> the domain before the operation is completed.  It seems to me we
> should either trust the toolstack to pause the domain and leave it
> paused -- letting it suffer the consequences if it fails to do so --
> or we should pause and unpause the domain ourselves.
> 
> Adding an extra pause count is simple and harmless.  If we're going to
> make an effort to think about buggy toolstacks, we might as well just
> make it 100% safe.
> 
>>> To start with, it seems like having a "bulk share" option which could
>>> do just a specific range would be useful as well as a "bulk share"
>>> which automatically deduped the entire set of memory.
>>
>> I have no need for such options.
> 
> Yes, but it's not unlikely that somebody else may need them at some
> point in the future; and it's only a tiny bit of adjustment to make
> them more generally useful than just your current specific use case,
> so that we can avoid changing the interface, or adding yet another
> hypercall in the future.

Well, I don't view it as a guarantee, but simply a sanity check. Iirc
I did ask for it simply because similar checks exist elsewhere.

Jan


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

Re: [Xen-devel] [PATCH v5 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Tamas K Lengyel]

On Tue, Jul 5, 2016 at 8:35 AM, George Dunlap  wrote:
> On Thu, Jun 23, 2016 at 4:42 PM, Tamas K Lengyel  wrote:
 +if ( !atomic_read(>pause_count) ||
 + !atomic_read(>pause_count) )
 +{
 +rcu_unlock_domain(cd);
 +rc = -EINVAL;
 +goto out;
 +}
>>>
>>> I realize that Jan asked for this, but I'm really not sure what good
>>> this is supposed to do, since the guest can be un-paused at any point
>>> halfway through the transaction.
>>>
>>> Wouldn't it make more sense to have this function pause and unpause
>>> the domains itself?
>>
>> The domains are paused by the user when this op is called, so this is
>> just a sanity check ensuring you are not issuing the op on some other
>> domain. So if this function would pause the domain as well all it
>> would do is increase the pause count. This is the only intended
>> use-case for this function at this time. It would make no sense to try
>> to issue this op on domains that are running, as that pretty much
>> guarantee that some of their memory has already diverged, and thus
>> bulk-sharing their memory would have some unintended side-effects.
>
> Yes, I understand all that.  But what I'm saying (and mostly this is
> actually to Jan that I'm saying it) is that this check, as written,
> seems pointless to me.  We're effectively *not* trusting the toolstack
> to pause the domain, but we *are* trust the toolstack not to unpause
> the domain before the operation is completed.  It seems to me we
> should either trust the toolstack to pause the domain and leave it
> paused -- letting it suffer the consequences if it fails to do so --
> or we should pause and unpause the domain ourselves.
>
> Adding an extra pause count is simple and harmless.  If we're going to
> make an effort to think about buggy toolstacks, we might as well just
> make it 100% safe.

Well, there are many many more ways the toolstack could cause issues
for this op so I would say let's just trust the toolstack to behave as
intended so I'll remove the pause check and point out in a comment
that the intended usecase assumes both domains are paused and remain
paused for the duration of the op.

>
>>> To start with, it seems like having a "bulk share" option which could
>>> do just a specific range would be useful as well as a "bulk share"
>>> which automatically deduped the entire set of memory.
>>
>> I have no need for such options.
>
> Yes, but it's not unlikely that somebody else may need them at some
> point in the future; and it's only a tiny bit of adjustment to make
> them more generally useful than just your current specific use case,
> so that we can avoid changing the interface, or adding yet another
> hypercall in the future.
>
>>> Secondly, structuring the information like the other memory operations
>>> -- for example, "nr_extents" and "nr_done" -- would make it more
>>> consistent, and would allow you to also to avoid overwriting one of
>>> the "in" values and having to restore it when you were done.
>>
>> I don't see any harm in clearing this value to 0 when the op finishes
>> so I don't think it would really make much difference if we have
>> another field just for scratch-space use. I'm fine with adding that
>> but it just seems a bit odd to me.
>
> Well clearing the value to zero seems a bit odd to me. :-)  But more
> to the point, it's valuable to have the interface 1) be flexible
> enough to bulk-share a range but not the entire address space 2) be
> similar enough to existing interfaces that nobody needs to figure out
> how it works.

I really doubt there will be any users for this feature but it's
simple enough of an adjustment that I'm fine with the change.

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH v2] xen: use native disk xenbus protocol if possible

[Stefano Stabellini]

On Wed, 29 Jun 2016, Anthony PERARD wrote:
> On Wed, Jun 29, 2016 at 05:50:48PM +0200, Juergen Gross wrote:
> > The qdisk implementation is using the native xenbus protocol only in
> > case of no protocol specified at all. As using the explicit 32- or
> > 64-bit protocol is slower than the native one due to copying requests
> > not by memcpy but element for element, this is not optimal.
> > 
> > Correct this by using the native protocol in case word sizes of
> > frontend and backend match.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Anthony PERARD 

Added to my queue


> > ---
> > V2: use native protocol in case of unknown protocol specified as
> > requested by Anthony Perard
> > ---
> >  hw/block/xen_disk.c | 18 ++
> >  1 file changed, 10 insertions(+), 8 deletions(-)
> > 
> > diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> > index 90aca73..d0aae67 100644
> > --- a/hw/block/xen_disk.c
> > +++ b/hw/block/xen_disk.c
> > @@ -975,14 +975,16 @@ static int blk_connect(struct XenDevice *xendev)
> >  blkdev->feature_persistent = !!pers;
> >  }
> >  
> > -blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> > -if (blkdev->xendev.protocol) {
> > -if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) 
> > {
> > -blkdev->protocol = BLKIF_PROTOCOL_X86_32;
> > -}
> > -if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) 
> > {
> > -blkdev->protocol = BLKIF_PROTOCOL_X86_64;
> > -}
> > +if (!blkdev->xendev.protocol) {
> > +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> > +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_NATIVE) == 
> > 0) {
> > +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> > +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 
> > 0) {
> > +blkdev->protocol = BLKIF_PROTOCOL_X86_32;
> > +} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 
> > 0) {
> > +blkdev->protocol = BLKIF_PROTOCOL_X86_64;
> > +} else {
> > +blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
> >  }
> >  
> >  blkdev->sring = xengnttab_map_grant_ref(blkdev->xendev.gnttabdev,
> > -- 
> > 2.6.6
> > 
> 
> -- 
> Anthony PERARD
> 

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

Re: [Xen-devel] [PATCH 11/18] arm/altp2m: Make flush_tlb_domain ready for altp2m.

[Sergej Proskurin]

Hi Julien,


On 07/04/2016 10:32 PM, Julien Grall wrote:
> Hello Sergej,
>
> On 04/07/2016 12:45, Sergej Proskurin wrote:
>> This commit makes sure that the TLB of a domain considers flushing all
>> of the associated altp2m views. Therefore, in case a different domain
>> (not the currently active domain) shall flush its TLBs, the current
>> implementation loops over all VTTBRs of the different altp2m mappings
>> per vCPU and flushes the TLBs. This way, a change of one of the altp2m
>> mapping is considered.  At this point, it must be considered that the
>> domain --whose TLBs are to be flushed-- is not locked.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>>  xen/arch/arm/p2m.c | 71
>> --
>>  1 file changed, 63 insertions(+), 8 deletions(-)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 7e721f9..019f10e 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -15,6 +15,8 @@
>>  #include 
>>  #include 
>>
>> +#include 
>> +
>>  #ifdef CONFIG_ARM_64
>>  static unsigned int __read_mostly p2m_root_order;
>>  static unsigned int __read_mostly p2m_root_level;
>> @@ -79,12 +81,41 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
>>   P2M_ROOT_LEVEL, P2M_ROOT_PAGES);
>>  }
>>
>> +static uint64_t p2m_get_altp2m_vttbr(struct vcpu *v)
>> +{
>> +struct domain *d = v->domain;
>> +uint16_t index = vcpu_altp2m(v).p2midx;
>> +
>> +if ( index == INVALID_ALTP2M )
>> +return INVALID_MFN;
>> +
>> +BUG_ON(index >= MAX_ALTP2M);
>> +
>> +return d->arch.altp2m_vttbr[index];
>> +}
>> +
>> +static void p2m_load_altp2m_VTTBR(struct vcpu *v)
>
> Please try to share code when it is possible. For instance, a big part
> of this helper is similar to p2m_load_VTTBR. Assuming you get the p2m
> rather than the VTTBR directly.
>

I will combine these two functions, thank you.

>> +{
>> +struct domain *d = v->domain;
>> +uint64_t vttbr = p2m_get_altp2m_vttbr(v);
>> +
>> +if ( is_idle_domain(d) )
>> +return;
>> +
>> +BUG_ON(vttbr == INVALID_MFN);
>> +WRITE_SYSREG64(vttbr, VTTBR_EL2);
>> +
>> +isb(); /* Ensure update is visible */
>> +}
>> +
>>  static void p2m_load_VTTBR(struct domain *d)
>>  {
>>  if ( is_idle_domain(d) )
>>  return;
>> +
>>  BUG_ON(!d->arch.vttbr);
>>  WRITE_SYSREG64(d->arch.vttbr, VTTBR_EL2);
>> +
>
> Spurious changes.
>

I will revert these, thank you.

>>  isb(); /* Ensure update is visible */
>>  }
>>
>> @@ -101,7 +132,11 @@ void p2m_restore_state(struct vcpu *n)
>>  WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
>>  isb();
>>
>> -p2m_load_VTTBR(n->domain);
>> +if ( altp2m_active(n->domain) )
>
> This would benefit of an unlikely (maybe within altp2m_active).
>

Fair enough. I will insert an unlikely macro into altp2m_active.

>> +p2m_load_altp2m_VTTBR(n);
>> +else
>> +p2m_load_VTTBR(n->domain);
>> +
>>  isb();
>>
>>  if ( is_32bit_domain(n->domain) )
>> @@ -119,22 +154,42 @@ void p2m_restore_state(struct vcpu *n)
>>  void flush_tlb_domain(struct domain *d)
>>  {
>>  unsigned long flags = 0;
>> +struct vcpu *v = NULL;
>>
>> -/* Update the VTTBR if necessary with the domain d. In this case,
>> - * it's only necessary to flush TLBs on every CPUs with the
>> current VMID
>> - * (our domain).
>> +/*
>> + * Update the VTTBR if necessary with the domain d. In this
>> case, it is only
>> + * necessary to flush TLBs on every CPUs with the current VMID (our
>> + * domain).
>>   */
>>  if ( d != current->domain )
>>  {
>>  local_irq_save(flags);
>> -p2m_load_VTTBR(d);
>> -}
>>
>> -flush_tlb();
>> +/* If altp2m is active, update VTTBR and flush TLBs of every
>> VCPU */
>> +if ( altp2m_active(d) )
>> +{
>> +for_each_vcpu( d, v )
>> +{
>> +p2m_load_altp2m_VTTBR(v);
>> +flush_tlb();
>> +}
>> +}
>> +else
>> +{
>> +p2m_load_VTTBR(d);
>> +flush_tlb();
>> +}
>
> Why do you need to do a such things? If the VMID is the same, a single
> call to flush_tlb() will nuke all the entries for the given TLBs.
>
> If the VMID is not shared, then I am not even sure why you would need
> to flush the TLBs for all the altp2ms.
>

If the VMID is shared between multiple views and we would change one
entry in one specific view, we might reuse an entry that is not part of
the currently active altp2m view of the domain. And even if we assign
unique VMIDs to the individual altp2m views (as discussed in patch #04),
as far as I understand, we will still need to flush the mappings of all
altp2ms at this point because (AFAIK) changes in individual altp2m views
will still need to be propagated to the 

Re: [Xen-devel] [PATCH v2 3/7] x86/vm-event/monitor: don't compromise monitor_write_data on domain cleanup

[George Dunlap]

On 05/07/16 15:28, Corneliu ZUZU wrote:
> The arch_vm_event structure is dynamically allocated and freed @
> vm_event_cleanup_domain. This cleanup is triggered e.g. when the toolstack 
> user
> disables domain monitoring (xc_monitor_disable), which in turn effectively
> discards any information that was in arch_vm_event.write_data.
> 
> But this can yield unexpected behavior since if a CR-write was awaiting to be
> committed on the scheduling tail (hvm_do_resume->arch_monitor_write_data)
> before xc_monitor_disable is called, then the domain CR write is wrongfully
> ignored, which of course, in these cases, can easily render a domain crash.
> 
> To fix the issue, this patch makes arch_vm_event.emul_read_data dynamically
> allocated and only frees that in vm_event_cleanup_domain, instead of the whole
> arch_vcpu.vm_event structure, which with this patch will only be freed on
> vcpu/domain destroyal.
> 
> Signed-off-by: Corneliu ZUZU 
> Acked-by: Razvan Cojocaru 

On the basis of one of the vm_event maintainer's acks...

> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 16733a4..6616626 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1642,7 +1642,7 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
>  v->arch.vm_event->emulate_flags = violation ? rsp->flags : 0;
>  
>  if ( (rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA) )
> -v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
> +*v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
>  }
>  }
>  

p2m bits:

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH v2 7/7] minor #include change

[Tamas K Lengyel]

On Tue, Jul 5, 2016 at 8:31 AM, Corneliu ZUZU  wrote:
> Move xen/paging.h #include from hvm/monitor.h to hvm/monitor.c (include 
> strictly
> where needed) and also change to asm/paging.h (include strictly what's 
> needed).
>
> Signed-off-by: Corneliu ZUZU 

Acked-by: Tamas K Lengyel 

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

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

[Stefano Stabellini]

On Tue, 5 Jul 2016, Julien Grall wrote:
> On 05/07/16 15:04, Stefano Stabellini wrote:
> > On Tue, 5 Jul 2016, Julien Grall wrote:
> > > On 05/07/16 14:53, Stefano Stabellini wrote:
> > > > On Thu, 30 Jun 2016, Dirk Behme wrote:
> > > > > +- clocks: one or more clocks to be registered.
> > > > > +  Xen hypervisor drivers might replace native drivers, resulting in
> > > > > +  clocks not registered by these native drivers. To avoid that these
> > > > > +  unregistered clocks are disabled, then, e.g. by
> > > > > clk_disable_unused(),
> > > > > +  register them in the hypervisor node.
> > > > > +  An example for this are the clocks of the serial driver. If the
> > > > > clocks
> > > > > +  used by the serial hardware interface are not registered by the
> > > > > serial
> > > > > +  driver the serial output might stop once clk_disable_unused() is
> > > > > called.
> > > > 
> > > > What if we use the "status" property of the clocks? Could we set it to
> > > > "disabled" in Xen? Would that be enough for Linux to leave them alone?
> > > 
> > > clocks could be shared between multiple devices. So it is not possible to
> > > disable the clock.
> > 
> > To clarify my suggestion: I am not saying we should disable the clock, I
> > am saying we should set the "status" property to "disabled" in Xen for
> > the clock used by the serial or passthrough devices (for which the
> > "status" property is already set to "disabled"). That should work for
> > cases where the clock is not shared among multiple devices.
> 
> How would you be able to differentiate in Xen between a clock shared and a
> non-shared one? The only way I can think it going through all the device tree
> which sounds really expensive.

Yes, but it is only done once and we only need to do the search for
clocks of "disabled" devices.


> > If the clock is shared, then I don't think we would run into the issue
> > described by Dirk because I wouldn't imagine clk_disable_unused would
> > try to disable the clock anymore, because it would actually be in use
> > from Linux POV.
> 
> We also want to prevent Linux changing the rate of the clock (see Mark's mail
> [1]).

I am not sure what's the best way to achieve that for clocks shared
across multiple devices. Let's see what the clock maintainers suggest.

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

Re: [Xen-devel] [PATCH v5 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[George Dunlap]

On Thu, Jun 23, 2016 at 4:42 PM, Tamas K Lengyel  wrote:
>>> +if ( !atomic_read(>pause_count) ||
>>> + !atomic_read(>pause_count) )
>>> +{
>>> +rcu_unlock_domain(cd);
>>> +rc = -EINVAL;
>>> +goto out;
>>> +}
>>
>> I realize that Jan asked for this, but I'm really not sure what good
>> this is supposed to do, since the guest can be un-paused at any point
>> halfway through the transaction.
>>
>> Wouldn't it make more sense to have this function pause and unpause
>> the domains itself?
>
> The domains are paused by the user when this op is called, so this is
> just a sanity check ensuring you are not issuing the op on some other
> domain. So if this function would pause the domain as well all it
> would do is increase the pause count. This is the only intended
> use-case for this function at this time. It would make no sense to try
> to issue this op on domains that are running, as that pretty much
> guarantee that some of their memory has already diverged, and thus
> bulk-sharing their memory would have some unintended side-effects.

Yes, I understand all that.  But what I'm saying (and mostly this is
actually to Jan that I'm saying it) is that this check, as written,
seems pointless to me.  We're effectively *not* trusting the toolstack
to pause the domain, but we *are* trust the toolstack not to unpause
the domain before the operation is completed.  It seems to me we
should either trust the toolstack to pause the domain and leave it
paused -- letting it suffer the consequences if it fails to do so --
or we should pause and unpause the domain ourselves.

Adding an extra pause count is simple and harmless.  If we're going to
make an effort to think about buggy toolstacks, we might as well just
make it 100% safe.

>> To start with, it seems like having a "bulk share" option which could
>> do just a specific range would be useful as well as a "bulk share"
>> which automatically deduped the entire set of memory.
>
> I have no need for such options.

Yes, but it's not unlikely that somebody else may need them at some
point in the future; and it's only a tiny bit of adjustment to make
them more generally useful than just your current specific use case,
so that we can avoid changing the interface, or adding yet another
hypercall in the future.

>> Secondly, structuring the information like the other memory operations
>> -- for example, "nr_extents" and "nr_done" -- would make it more
>> consistent, and would allow you to also to avoid overwriting one of
>> the "in" values and having to restore it when you were done.
>
> I don't see any harm in clearing this value to 0 when the op finishes
> so I don't think it would really make much difference if we have
> another field just for scratch-space use. I'm fine with adding that
> but it just seems a bit odd to me.

Well clearing the value to zero seems a bit odd to me. :-)  But more
to the point, it's valuable to have the interface 1) be flexible
enough to bulk-share a range but not the entire address space 2) be
similar enough to existing interfaces that nobody needs to figure out
how it works.

 -George

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

[Xen-devel] [PATCH v2 7/7] minor #include change

[Corneliu ZUZU]

Move xen/paging.h #include from hvm/monitor.h to hvm/monitor.c (include strictly
where needed) and also change to asm/paging.h (include strictly what's needed).

Signed-off-by: Corneliu ZUZU 
---
Changed since v1:
  * preserve alphabetical ordering
---
 xen/arch/x86/hvm/monitor.c| 1 +
 xen/include/asm-x86/hvm/monitor.h | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index bbe5952..db6db6f 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/xen/include/asm-x86/hvm/monitor.h 
b/xen/include/asm-x86/hvm/monitor.h
index 8d4ef19..1c8ec6c 100644
--- a/xen/include/asm-x86/hvm/monitor.h
+++ b/xen/include/asm-x86/hvm/monitor.h
@@ -19,7 +19,6 @@
 #ifndef __ASM_X86_HVM_MONITOR_H__
 #define __ASM_X86_HVM_MONITOR_H__
 
-#include 
 #include 
 
 enum hvm_monitor_debug_type
-- 
2.5.0


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

[Xen-devel] [PATCH v2 6/7] minor fixes (formatting, comments, unused includes etc.)

[Corneliu ZUZU]

Minor fixes:
 - remove some empty lines
 - remove some unused includes
 - multi-line comment fixes
 - 80-columns formatting fixes

Signed-off-by: Corneliu ZUZU 
---
Changed since v1: 
---
 xen/arch/arm/domain.c |  1 -
 xen/arch/arm/traps.c  |  1 -
 xen/arch/x86/hvm/hvm.c|  3 ---
 xen/arch/x86/hvm/vmx/vmx.c|  1 -
 xen/arch/x86/monitor.c|  1 -
 xen/arch/x86/vm_event.c   |  3 ---
 xen/common/monitor.c  |  1 -
 xen/common/vm_event.c |  6 --
 xen/include/asm-arm/vm_event.h|  9 +++--
 xen/include/asm-x86/hvm/monitor.h |  1 -
 xen/include/asm-x86/monitor.h |  3 ---
 xen/include/asm-x86/vm_event.h|  1 -
 xen/include/public/vm_event.h | 38 +++---
 xen/include/xen/vm_event.h|  1 -
 14 files changed, 26 insertions(+), 44 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 6ce4645..61fc08e 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -294,7 +294,6 @@ static void continue_new_vcpu(struct vcpu *prev)
 else
 /* check_wakeup_from_wait(); */
 reset_stack_and_jump(return_to_new_vcpu64);
-
 }
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 44926ca..fb01703 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -439,7 +439,6 @@ static void inject_abt32_exception(struct cpu_user_regs 
*regs,
 far |= addr << 32;
 WRITE_SYSREG(far, FAR_EL1);
 WRITE_SYSREG(fsr, IFSR32_EL2);
-
 #endif
 }
 else
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 091cabe..32d2d5e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -63,11 +62,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 0fa3fea..ee108b5 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 2bb7d86..e3f57eb 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -21,7 +21,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 int arch_monitor_init_domain(struct domain *d)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 2fe7808..eed82e5 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -18,9 +18,6 @@
  * License along with this program; If not, see .
  */
 
-#include 
-#include 
-#include 
 #include 
 
 /* Implicitly serialized by the domctl lock. */
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 436214a..08d1d98 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 78126cf..8c80901 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -781,8 +781,10 @@ void vm_event_vcpu_unpause(struct vcpu *v)
 {
 int old, new, prev = v->vm_event_pause_count.counter;
 
-/* All unpause requests as a result of toolstack responses.  Prevent
- * underflow of the vcpu pause count. */
+/*
+ * All unpause requests as a result of toolstack responses.
+ * Prevent underflow of the vcpu pause count.
+ */
 do
 {
 old = prev;
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index a3fc4ce..ccc4b60 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -23,21 +23,18 @@
 #include 
 #include 
 
-static inline
-int vm_event_init_domain(struct domain *d)
+static inline int vm_event_init_domain(struct domain *d)
 {
 /* Nothing to do. */
 return 0;
 }
 
-static inline
-void vm_event_cleanup_domain(struct domain *d)
+static inline void vm_event_cleanup_domain(struct domain *d)
 {
 memset(>monitor, 0, sizeof(d->monitor));
 }
 
-static inline
-void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
+static inline void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
 {
 /* Not supported on ARM. */
 }
diff --git a/xen/include/asm-x86/hvm/monitor.h 
b/xen/include/asm-x86/hvm/monitor.h
index 8b0f119..8d4ef19 100644
--- a/xen/include/asm-x86/hvm/monitor.h
+++ b/xen/include/asm-x86/hvm/monitor.h
@@ -19,7 +19,6 @@
 #ifndef __ASM_X86_HVM_MONITOR_H__
 #define __ASM_X86_HVM_MONITOR_H__
 
-#include 
 #include 
 #include 
 
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index a094c0d..aa17be1 100644
--- a/xen/include/asm-x86/monitor.h
+++ 

[Xen-devel] [PATCH v2 5/7] x86/vm-event: minor ASSERT fix, add 'unlikely'

[Corneliu ZUZU]

Minor fixes:

* vm_event_register_write_resume: ASSERT on non-NULL v->arch.vm_event instead of
  >arch.vm_event->write_data.
* add 'unlikely' in if

Signed-off-by: Corneliu ZUZU 
---
 xen/arch/x86/hvm/hvm.c  | 2 +-
 xen/arch/x86/vm_event.c | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ac6d9eb..091cabe 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -475,7 +475,7 @@ void hvm_do_resume(struct vcpu *v)
 
 if ( unlikely(v->arch.vm_event) )
 {
-if ( v->arch.vm_event->emulate_flags )
+if ( unlikely(v->arch.vm_event->emulate_flags) )
 {
 enum emul_kind kind = EMUL_KIND_NORMAL;
 
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 0e25e4d..2fe7808 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -83,14 +83,16 @@ void vm_event_register_write_resume(struct vcpu *v, 
vm_event_response_t *rsp)
 {
 if ( rsp->flags & VM_EVENT_FLAG_DENY )
 {
-struct monitor_write_data *w = >arch.vm_event->write_data;
+struct monitor_write_data *w;
 
-ASSERT(w);
+ASSERT(v->arch.vm_event);
 
 /* deny flag requires the vCPU to be paused */
 if ( !atomic_read(>vm_event_pause_count) )
 return;
 
+w = >arch.vm_event->write_data;
+
 switch ( rsp->reason )
 {
 case VM_EVENT_REASON_MOV_TO_MSR:
-- 
2.5.0


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

[Xen-devel] [PATCH v2 4/7] x86/vm_event_resume: surround VM_EVENT_REASON_MOV_TO_MSR w/ CONFIG_X86

[Corneliu ZUZU]

VM_EVENT_REASON_MOV_TO_MSR is X86-specific, surround w/ #ifdef accordingly.

Signed-off-by: Corneliu ZUZU 
Acked-by: Razvan Cojocaru 
---
Changed since v1: 
---
 xen/common/vm_event.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 75bbbab..78126cf 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -394,7 +394,9 @@ void vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
  */
 switch ( rsp.reason )
 {
+#ifdef CONFIG_X86
 case VM_EVENT_REASON_MOV_TO_MSR:
+#endif
 case VM_EVENT_REASON_WRITE_CTRLREG:
 vm_event_register_write_resume(v, );
 break;
-- 
2.5.0


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

Re: [Xen-devel] [PATCH v2] xen: arm64: Add support for Renesas RCar Gen3 H3 Salvator-X platform

[Andre Przywara]

Hi,

On 05/07/16 15:22, Dirk Behme wrote:
> On 05.07.2016 15:45, Andre Przywara wrote:
>> Hi,
>>
>> On 05/07/16 14:34, Julien Grall wrote:
>>> (CC Andre)
>>>
>>> On 05/07/16 14:04, Dirk Behme wrote:
 On 05.07.2016 14:45, Julien Grall wrote:
>
>
> On 05/07/16 13:09, Dirk Behme wrote:
>> Hi Julien,
>>
>> On 05.07.2016 13:39, Julien Grall wrote:
>>> Hi Dirk,
>>>
>>> On 05/07/16 07:37, Dirk Behme wrote:
 Signed-off-by: Dirk Behme 
>>>
>>> This patch looks good to me, however I would like to see the
>>> documentation on the wiki page (see [1]) before giving any formal
>>> ack.
>>
>>
>> Ok, many thanks for your review!
>>
>> Yes, I understood that something more is needed.
>>
>>
>> I just wonder if we keep the patch on the mailing list for a moment.
>> With this it's publically available and we can see how's the public
>> interest for this board.
>>
>> Additionally, getting Xen running on this board and describe all
>> this in
>> the wiki isn't that easy. You either need to modify the flashed
>> firmware. Or, like me, load everything via a JTAG debugger ...
>
> Can you details why you think it is not easy? Why do you have to
> modify
> the firmware? Is it because it does not boot the hypervisor in EL2?


 The board boots via ATF, which starts U-Boot in EL1, then. You have to
 find a way to load Xen into memory (e.g. U-Boot TFTP) and then
 switch to
 EL2 to start Xen.
>>>
>>> But ATF is running in EL3, right? If so, can ATF just starts U-boot
>>> in EL2?
>>>
>>> I have a board at home (pine64) which also uses ATF and U-Boot and is
>>> able to boot Xen without any SMC call because the U-Boot is entered
>>> in EL2.
>>
>>  From having a very quick look into the rcar ATF port on github[1] I see:
>>
>> +#elif (RCAR_BL33_EXECUTION_EL == BL33_EL2)
>> +return (uint32_t)SPSR_64(MODE_EL2, MODE_SP_ELX,
>> DISABLE_ALL_EXCEPTIONS);
>>
>> So if you rebuild ATF with RCAR_BL33_EXECUTION_EL set to BL33_EL2 that
>> should enter U-Boot in EL2.
>>
>> The fix for the Pine64 was equally simple and works fine since then.
> 
> 
> This is an other solution most probably I meant when talking about
> "modifying the firmware" ;)
> 
> I'm somehow unsure about the pros and cons running U-Boot at EL1 versus
> EL2, though.

It shouldn't matter, really. U-Boot on AArch64 (called armv8 here) is
able to run in any exception level (in contrast to ARMv7).
Actually running in EL2 is the architecturally recommended way, even
with ATF (by default it drops into EL2 when returning to non-secure
world). On Juno (and the Pine64) is works fine this way.

As U-Boot only uses an identity mapping, many differences between EL2
and EL1 don't matter.

Cheers,
Andre.

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

[Xen-devel] [PATCH v2 3/7] x86/vm-event/monitor: don't compromise monitor_write_data on domain cleanup

[Corneliu ZUZU]

The arch_vm_event structure is dynamically allocated and freed @
vm_event_cleanup_domain. This cleanup is triggered e.g. when the toolstack user
disables domain monitoring (xc_monitor_disable), which in turn effectively
discards any information that was in arch_vm_event.write_data.

But this can yield unexpected behavior since if a CR-write was awaiting to be
committed on the scheduling tail (hvm_do_resume->arch_monitor_write_data)
before xc_monitor_disable is called, then the domain CR write is wrongfully
ignored, which of course, in these cases, can easily render a domain crash.

To fix the issue, this patch makes arch_vm_event.emul_read_data dynamically
allocated and only frees that in vm_event_cleanup_domain, instead of the whole
arch_vcpu.vm_event structure, which with this patch will only be freed on
vcpu/domain destroyal.

Signed-off-by: Corneliu ZUZU 
Acked-by: Razvan Cojocaru 
---
Changed since v1:
  * arch_vcpu.vm_event made pointer again to avoid eating memory from arch_vcpu
structure
---
 xen/arch/x86/domain.c  |  9 +++--
 xen/arch/x86/hvm/emulate.c |  6 +++---
 xen/arch/x86/hvm/hvm.c |  2 ++
 xen/arch/x86/mm/p2m.c  |  2 +-
 xen/arch/x86/vm_event.c| 22 --
 xen/common/vm_event.c  | 11 +++
 xen/include/asm-x86/monitor.h  |  4 +++-
 xen/include/asm-x86/vm_event.h |  2 +-
 8 files changed, 44 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index bb59247..0313208 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -492,8 +493,12 @@ int vcpu_initialise(struct vcpu *v)
 
 void vcpu_destroy(struct vcpu *v)
 {
-xfree(v->arch.vm_event);
-v->arch.vm_event = NULL;
+if ( unlikely(v->arch.vm_event) )
+{
+xfree(v->arch.vm_event->emul_read_data);
+xfree(v->arch.vm_event);
+v->arch.vm_event = NULL;
+}
 
 if ( is_pv_32bit_vcpu(v) )
 {
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 855af4d..3880df1 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -73,12 +73,12 @@ static int set_context_data(void *buffer, unsigned int size)
 {
 struct vcpu *curr = current;
 
-if ( curr->arch.vm_event )
+if ( curr->arch.vm_event && curr->arch.vm_event->emul_read_data )
 {
 unsigned int safe_size =
-min(size, curr->arch.vm_event->emul_read_data.size);
+min(size, curr->arch.vm_event->emul_read_data->size);
 
-memcpy(buffer, curr->arch.vm_event->emul_read_data.data, safe_size);
+memcpy(buffer, curr->arch.vm_event->emul_read_data->data, safe_size);
 memset(buffer + safe_size, 0, size - safe_size);
 return X86EMUL_OKAY;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e3829d2..ac6d9eb 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -479,6 +479,8 @@ void hvm_do_resume(struct vcpu *v)
 {
 enum emul_kind kind = EMUL_KIND_NORMAL;
 
+ASSERT(v->arch.vm_event->emul_read_data);
+
 if ( v->arch.vm_event->emulate_flags &
  VM_EVENT_FLAG_SET_EMUL_READ_DATA )
 kind = EMUL_KIND_SET_CONTEXT;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 16733a4..6616626 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1642,7 +1642,7 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
 v->arch.vm_event->emulate_flags = violation ? rsp->flags : 0;
 
 if ( (rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA) )
-v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
+*v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
 }
 }
 
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index 80f84d6..0e25e4d 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -30,12 +30,18 @@ int vm_event_init_domain(struct domain *d)
 
 for_each_vcpu ( d, v )
 {
-if ( v->arch.vm_event )
+if ( likely(!v->arch.vm_event) )
+{
+v->arch.vm_event = xzalloc(struct arch_vm_event);
+if ( !v->arch.vm_event )
+return -ENOMEM;
+}
+else if ( unlikely(v->arch.vm_event->emul_read_data) )
 continue;
 
-v->arch.vm_event = xzalloc(struct arch_vm_event);
-
-if ( !v->arch.vm_event )
+v->arch.vm_event->emul_read_data =
+xzalloc(struct vm_event_emul_read_data);
+if ( !v->arch.vm_event->emul_read_data )
 return -ENOMEM;
 }
 
@@ -52,8 +58,12 @@ void vm_event_cleanup_domain(struct domain *d)
 
 for_each_vcpu ( d, v )
 {
-xfree(v->arch.vm_event);
-v->arch.vm_event = NULL;
+if ( likely(!v->arch.vm_event) )
+continue;
+

[Xen-devel] [PATCH v2 2/7] x86/vm-event/monitor: relocate code-motion more appropriately

[Corneliu ZUZU]

For readability:

* Add function arch_monitor_write_data (in x86/monitor.c) and separate handling
of monitor_write_data there (previously done directly in hvm_do_resume).

* Separate enabling/disabling of CPU_BASED_CR3_LOAD_EXITING for CR3 monitor
vm-events from CR0 node @ vmx_update_guest_cr(v, 0) into newly added function
vmx_vm_event_update_cr3_traps(d); also, for a better interface, create generic
function write_ctrlreg_adjust_traps (in x86/monitor.c) which deals with setting
up any traps for cr-write monitor vm-events.

Signed-off-by: Corneliu ZUZU 
Acked-by: Razvan Cojocaru 
---
Changed since v1:
  * separated vmx-specific code motion in vmx_vm_event_update_cr3_traps
  * minor: reorder added include alphabetically
  * minor: move arch_monitor_write_data call in if @ hvm_do_resume
---
 xen/arch/x86/hvm/hvm.c| 46 ---
 xen/arch/x86/hvm/vmx/vmx.c| 58 +++
 xen/arch/x86/monitor.c| 48 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h |  1 +
 xen/include/asm-x86/monitor.h |  2 ++
 5 files changed, 114 insertions(+), 41 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c89ab6e..e3829d2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -475,8 +475,6 @@ void hvm_do_resume(struct vcpu *v)
 
 if ( unlikely(v->arch.vm_event) )
 {
-struct monitor_write_data *w = >arch.vm_event->write_data;
-
 if ( v->arch.vm_event->emulate_flags )
 {
 enum emul_kind kind = EMUL_KIND_NORMAL;
@@ -494,29 +492,7 @@ void hvm_do_resume(struct vcpu *v)
 v->arch.vm_event->emulate_flags = 0;
 }
 
-if ( w->do_write.msr )
-{
-hvm_msr_write_intercept(w->msr, w->value, 0);
-w->do_write.msr = 0;
-}
-
-if ( w->do_write.cr0 )
-{
-hvm_set_cr0(w->cr0, 0);
-w->do_write.cr0 = 0;
-}
-
-if ( w->do_write.cr4 )
-{
-hvm_set_cr4(w->cr4, 0);
-w->do_write.cr4 = 0;
-}
-
-if ( w->do_write.cr3 )
-{
-hvm_set_cr3(w->cr3, 0);
-w->do_write.cr3 = 0;
-}
+arch_monitor_write_data(v);
 }
 
 /* Inject pending hw/sw trap */
@@ -2206,7 +2182,10 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
 
 if ( hvm_monitor_crX(CR0, value, old_value) )
 {
-/* The actual write will occur in hvm_do_resume(), if permitted. */
+/*
+ * The actual write will occur in arch_monitor_write_data(), if
+ * permitted.
+ */
 v->arch.vm_event->write_data.do_write.cr0 = 1;
 v->arch.vm_event->write_data.cr0 = value;
 
@@ -2308,7 +2287,10 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 
 if ( hvm_monitor_crX(CR3, value, old) )
 {
-/* The actual write will occur in hvm_do_resume(), if permitted. */
+/*
+ * The actual write will occur in arch_monitor_write_data(), if
+ * permitted.
+ */
 v->arch.vm_event->write_data.do_write.cr3 = 1;
 v->arch.vm_event->write_data.cr3 = value;
 
@@ -2388,7 +2370,10 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
 
 if ( hvm_monitor_crX(CR4, value, old_cr) )
 {
-/* The actual write will occur in hvm_do_resume(), if permitted. */
+/*
+ * The actual write will occur in arch_monitor_write_data(), if
+ * permitted.
+ */
 v->arch.vm_event->write_data.do_write.cr4 = 1;
 v->arch.vm_event->write_data.cr4 = value;
 
@@ -3767,7 +3752,10 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 {
 ASSERT(v->arch.vm_event);
 
-/* The actual write will occur in hvm_do_resume() (if permitted). */
+/*
+ * The actual write will occur in arch_monitor_write_data(), if
+ * permitted.
+ */
 v->arch.vm_event->write_data.do_write.msr = 1;
 v->arch.vm_event->write_data.msr = msr;
 v->arch.vm_event->write_data.value = msr_content;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 8ab074f..0fa3fea 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1442,11 +1442,6 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
 if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
 v->arch.hvm_vmx.exec_control |= cr3_ctls;
 
-/* Trap CR3 updates if CR3 memory events are enabled. */
-if ( v->domain->arch.monitor.write_ctrlreg_enabled &
- monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
-v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
-
 if ( 

[Xen-devel] [PATCH v2 1/7] x86/vmx_update_guest_cr: minor optimization

[Corneliu ZUZU]

Minor optimization @ vmx_update_guest_cr: checks if v->arch.hvm_vmx.exec_control
was modified before actually calling vmx_update_cpu_exec_control(v).

Signed-off-by: Corneliu ZUZU 
---
Changed since v1: 
---
 xen/arch/x86/hvm/vmx/vmx.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index df19579..8ab074f 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1434,8 +1434,10 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
 if ( paging_mode_hap(v->domain) )
 {
 /* Manage GUEST_CR3 when CR0.PE=0. */
+uint32_t old_ctls = v->arch.hvm_vmx.exec_control;
 uint32_t cr3_ctls = (CPU_BASED_CR3_LOAD_EXITING |
  CPU_BASED_CR3_STORE_EXITING);
+
 v->arch.hvm_vmx.exec_control &= ~cr3_ctls;
 if ( !hvm_paging_enabled(v) && !vmx_unrestricted_guest(v) )
 v->arch.hvm_vmx.exec_control |= cr3_ctls;
@@ -1445,7 +1447,8 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
 v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;
 
-vmx_update_cpu_exec_control(v);
+if ( old_ctls != v->arch.hvm_vmx.exec_control )
+vmx_update_cpu_exec_control(v);
 }
 
 if ( !nestedhvm_vcpu_in_guestmode(v) )
-- 
2.5.0


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

[Xen-devel] [PATCH v2 0/7] x86/vm-event: Adjustments & fixes

[Corneliu ZUZU]

This patch-series makes some adjustments and fixes to the X86 vm-events code.
Summary:
1. minor optimization
2. relocate some code into added vm-event functions
Acked-by: Razvan Cojocaru 
3. fix monitor_write_data behavior on domain cleanup
Acked-by: Razvan Cojocaru 
4. surround VM_EVENT_REASON_MOV_TO_MSR w/ #ifdef CONFIG_X86
Acked-by: Razvan Cojocaru 
5+6+7. minor fixes (cleanup stuff)

Significant changes since v1:
  0/7: removed patch 4/8 of v1 series (restored monitor_write_data.do_write)
  2/7: separated vmx-specific code motion in vmx_vm_event_update_cr3_traps
  3/7: arch_vcpu.vm_event made pointer again to avoid eating memory from
   arch_vcpu structure

Corneliu ZUZU (7):
  x86/vmx_update_guest_cr: minor optimization
  x86/vm-event/monitor: relocate code-motion more appropriately
  x86/vm-event/monitor: don't compromise monitor_write_data on domain
cleanup
  x86/vm_event_resume: surround VM_EVENT_REASON_MOV_TO_MSR w/ CONFIG_X86
  x86/vm-event: minor ASSERT fix, add 'unlikely'
  minor fixes (formatting, comments, unused includes etc.)
  minor #include change

 xen/arch/arm/domain.c |  1 -
 xen/arch/arm/traps.c  |  1 -
 xen/arch/x86/domain.c |  9 --
 xen/arch/x86/hvm/emulate.c|  6 ++--
 xen/arch/x86/hvm/hvm.c| 53 
 xen/arch/x86/hvm/monitor.c|  1 +
 xen/arch/x86/hvm/vmx/vmx.c| 64 ++-
 xen/arch/x86/mm/p2m.c |  2 +-
 xen/arch/x86/monitor.c| 47 +++-
 xen/arch/x86/vm_event.c   | 31 ---
 xen/common/monitor.c  |  1 -
 xen/common/vm_event.c | 19 ++--
 xen/include/asm-arm/vm_event.h|  9 ++
 xen/include/asm-x86/hvm/monitor.h |  2 --
 xen/include/asm-x86/hvm/vmx/vmx.h |  1 +
 xen/include/asm-x86/monitor.h |  9 +++---
 xen/include/asm-x86/vm_event.h|  3 +-
 xen/include/public/vm_event.h | 38 +++
 xen/include/xen/vm_event.h|  1 -
 19 files changed, 195 insertions(+), 103 deletions(-)

-- 
2.5.0


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

Re: [Xen-devel] [PATCH v2] xen: arm64: Add support for Renesas RCar Gen3 H3 Salvator-X platform

[Dirk Behme]

On 05.07.2016 15:45, Andre Przywara wrote:

Hi,

On 05/07/16 14:34, Julien Grall wrote:

(CC Andre)

On 05/07/16 14:04, Dirk Behme wrote:

On 05.07.2016 14:45, Julien Grall wrote:



On 05/07/16 13:09, Dirk Behme wrote:

Hi Julien,

On 05.07.2016 13:39, Julien Grall wrote:

Hi Dirk,

On 05/07/16 07:37, Dirk Behme wrote:

Signed-off-by: Dirk Behme 


This patch looks good to me, however I would like to see the
documentation on the wiki page (see [1]) before giving any formal ack.



Ok, many thanks for your review!

Yes, I understood that something more is needed.


I just wonder if we keep the patch on the mailing list for a moment.
With this it's publically available and we can see how's the public
interest for this board.

Additionally, getting Xen running on this board and describe all
this in
the wiki isn't that easy. You either need to modify the flashed
firmware. Or, like me, load everything via a JTAG debugger ...


Can you details why you think it is not easy? Why do you have to modify
the firmware? Is it because it does not boot the hypervisor in EL2?



The board boots via ATF, which starts U-Boot in EL1, then. You have to
find a way to load Xen into memory (e.g. U-Boot TFTP) and then switch to
EL2 to start Xen.


But ATF is running in EL3, right? If so, can ATF just starts U-boot in EL2?

I have a board at home (pine64) which also uses ATF and U-Boot and is
able to boot Xen without any SMC call because the U-Boot is entered in EL2.


 From having a very quick look into the rcar ATF port on github[1] I see:

+#elif (RCAR_BL33_EXECUTION_EL == BL33_EL2)
+   return (uint32_t)SPSR_64(MODE_EL2, MODE_SP_ELX, DISABLE_ALL_EXCEPTIONS);

So if you rebuild ATF with RCAR_BL33_EXECUTION_EL set to BL33_EL2 that
should enter U-Boot in EL2.

The fix for the Pine64 was equally simple and works fine since then.



This is an other solution most probably I meant when talking about 
"modifying the firmware" ;)


I'm somehow unsure about the pros and cons running U-Boot at EL1 
versus EL2, though.


Best regards

Dirk


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

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

[Lan, Tianyu]

On 7/5/2016 9:57 PM, Jan Beulich wrote:

On 05.07.16 at 15:37,  wrote:

Hi Stefano, Andrew and Jan:
Could you give us more guides here to move forward virtual iommu
development? Thanks.


Due to ...


On 6/29/2016 11:04 AM, Tian, Kevin wrote:

Please let us know your thoughts. If no one has explicit objection based
on above rough idea, we'll go to write the high level design doc for more
detail discussion.


... this I actually expected we'd get to see something, rather than
our input being waited for.


OK. I get it. Because no response, double confirm we are on the
right way.


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

Re: [Xen-devel] [PATCH v3 00/17] Xen ARM DomU ACPI support

[Shannon Zhao]

On 2016年07月05日 18:32, Julien Grall wrote:
> On 05/07/16 04:12, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> Note: while there are still two points (user configuration name and
>> where to load the ACPI blob) which we don't reach an agreement and need
>> other maintainer's opinions, but I'd like to send the updated series out
>> since we could move forward and once we reach an agreement I can make
>> changes.
>
> It would have been nice to summarize the problems in the concerned
> patches to avoid having looking through all the patches in the
> previous version understanding what are the disagreements. Note that
> as the contributor of this series, I would expect you to drive the
> discussion (e.g gentle ping...).
>
Actually I notice Stefano and Wei are not active recently, so I thought
they are on holidays(or doing other things). So currently ping is
useless. Once they come back and if they don't reply I'll ping them.

> You also did not address my concern related to require iasl even on
> platform when ACPI will not be used (such as arm32). 
Oh, sorry, will address at next version.

Thanks,

-- 
Shannon


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

Re: [Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch

[PGNet Dev]

Reading @

 How to know if the balloon driver is running
  http://www.gossamer-threads.com/lists/xen/users/315064#315064

"...
IIRC the core balloon driver is always present when Xen is enabled and
so the kernel will respond to requests from the host/toolstack to change
the amount of RAM (e.g "xm/xl mem-set foo" in dom0, which would result
in changes to /proc/meminfo).

In order to get in-guest access to control ballooning you need to
CONFIG_XEN_BALLOON enable and load the xen-balloon.ko module. I'm not
sure but I think with modern kernels this will appear in /sys and
not /proc.
...
AFAIK the balloon driver is started if you just have CONFIG_XEN.

	LIke I said before CONFIG_XEN_BALLOON enables additional support for 
controlling the balloon driver from within the guest (as opposed to from 
the host toolstack).

..."

in the Guest,

grep -i config_xen= /boot/*config*
/boot/config-4.4.0-28-generic:CONFIG_XEN=y
grep -i xen /boot/*config* | grep -i balloon

/boot/config-4.4.0-28-generic:CONFIG_XEN_BALLOON=y

/boot/config-4.4.0-28-generic:CONFIG_XEN_SELFBALLOONING=y

/boot/config-4.4.0-28-generic:CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y

/boot/config-4.4.0-28-generic:CONFIG_XEN_BALLOON_MEMORY_HOTPLUG_LIMIT=512

find /sys /proc -type d | grep -i balloon | grep xen
/sys/devices/system/xen_memory/xen_memory0/selfballoon
/proc/sys/xen/balloon

ls -al /proc/sys/xen/balloon
hotplug_unpopulated

How do you blacklist the Guest ballooning?

Perhaps related?  Not clear 2 me that it's the same issue,

 xen/balloon: cancel ballooning if adding new memory failed

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3dcf63677d4eb7fdfc13290c8558c301d2588fe8

There's also balloon-related comments at

 http://wiki.xenproject.org/wiki/XenParavirtOps

although they now look somewhat out of date w.r.t. current 4x kernel

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

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

[Julien Grall]

On 05/07/16 15:04, Stefano Stabellini wrote:

On Tue, 5 Jul 2016, Julien Grall wrote:

On 05/07/16 14:53, Stefano Stabellini wrote:

On Thu, 30 Jun 2016, Dirk Behme wrote:

+- clocks: one or more clocks to be registered.
+  Xen hypervisor drivers might replace native drivers, resulting in
+  clocks not registered by these native drivers. To avoid that these
+  unregistered clocks are disabled, then, e.g. by clk_disable_unused(),
+  register them in the hypervisor node.
+  An example for this are the clocks of the serial driver. If the clocks
+  used by the serial hardware interface are not registered by the serial
+  driver the serial output might stop once clk_disable_unused() is
called.


What if we use the "status" property of the clocks? Could we set it to
"disabled" in Xen? Would that be enough for Linux to leave them alone?


clocks could be shared between multiple devices. So it is not possible to
disable the clock.


To clarify my suggestion: I am not saying we should disable the clock, I
am saying we should set the "status" property to "disabled" in Xen for
the clock used by the serial or passthrough devices (for which the
"status" property is already set to "disabled"). That should work for
cases where the clock is not shared among multiple devices.


How would you be able to differentiate in Xen between a clock shared and 
a non-shared one? The only way I can think it going through all the 
device tree which sounds really expensive.



If the clock is shared, then I don't think we would run into the issue
described by Dirk because I wouldn't imagine clk_disable_unused would
try to disable the clock anymore, because it would actually be in use
from Linux POV.


We also want to prevent Linux changing the rate of the clock (see Mark's 
mail [1]).


Regards,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00335.html


--
Julien Grall

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

Re: [Xen-devel] [PATCH v14 3/3] IOMMU: fix vt-d Device-TLB flush timeout issue

[Jan Beulich]

>>> On 05.07.16 at 15:56,  wrote:
> Just check it, do you agree to pick up this series?

Depends on Kevin's view; I wanted to send out review feedback
publicly regardless of who'd be picking it up.

Jan


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

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

[Stefano Stabellini]

On Tue, 5 Jul 2016, Julien Grall wrote:
> On 05/07/16 14:53, Stefano Stabellini wrote:
> > On Thu, 30 Jun 2016, Dirk Behme wrote:
> > > +- clocks: one or more clocks to be registered.
> > > +  Xen hypervisor drivers might replace native drivers, resulting in
> > > +  clocks not registered by these native drivers. To avoid that these
> > > +  unregistered clocks are disabled, then, e.g. by clk_disable_unused(),
> > > +  register them in the hypervisor node.
> > > +  An example for this are the clocks of the serial driver. If the clocks
> > > +  used by the serial hardware interface are not registered by the serial
> > > +  driver the serial output might stop once clk_disable_unused() is
> > > called.
> > 
> > What if we use the "status" property of the clocks? Could we set it to
> > "disabled" in Xen? Would that be enough for Linux to leave them alone?
> 
> clocks could be shared between multiple devices. So it is not possible to
> disable the clock.

To clarify my suggestion: I am not saying we should disable the clock, I
am saying we should set the "status" property to "disabled" in Xen for
the clock used by the serial or passthrough devices (for which the
"status" property is already set to "disabled"). That should work for
cases where the clock is not shared among multiple devices.

If the clock is shared, then I don't think we would run into the issue
described by Dirk because I wouldn't imagine clk_disable_unused would
try to disable the clock anymore, because it would actually be in use
from Linux POV.

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

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

[Julien Grall]

On 05/07/16 14:54, Julien Grall wrote:



On 05/07/16 14:53, Stefano Stabellini wrote:

On Thu, 30 Jun 2016, Dirk Behme wrote:

+- clocks: one or more clocks to be registered.
+  Xen hypervisor drivers might replace native drivers, resulting in
+  clocks not registered by these native drivers. To avoid that these
+  unregistered clocks are disabled, then, e.g. by clk_disable_unused(),
+  register them in the hypervisor node.
+  An example for this are the clocks of the serial driver. If the
clocks
+  used by the serial hardware interface are not registered by the
serial
+  driver the serial output might stop once clk_disable_unused() is
called.


What if we use the "status" property of the clocks? Could we set it to
"disabled" in Xen? Would that be enough for Linux to leave them alone?


clocks could be shared between multiple devices. So it is not possible
to disable the clock.


To give an example, below the UART node for juno 
(arch/arm64/boot/dts/arm/juno-base.dtsi):


soc_uart0: uart@7ff8 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x0 0x7ff8 0x0 0x1000>;
interrupts = ;
clocks = <_uartclk>, <_refclk100mhz>;
clock-names = "uartclk", "apb_pclk";
};

The clock soc_refclk100mhz is shared with the mailbox.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 10/18] arm/altp2m: Renamed and extended p2m_alloc_table.

[Sergej Proskurin]

Hello Julien,


On 07/04/2016 08:43 PM, Julien Grall wrote:
> Hello Sergej,
>
> On 04/07/16 12:45, Sergej Proskurin wrote:
>> +int p2m_table_init(struct domain *d)
>> +{
>> +int i = 0;
>> +int rc = -ENOMEM;
>> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +
>> +spin_lock(>lock);
>> +
>> +rc = p2m_alloc_table(p2m);
>> +if ( rc != 0 )
>> +goto out;
>> +
>> +d->arch.vttbr = d->arch.p2m.vttbr.vttbr;
>> +
>> +/*
>> + * Make sure that all TLBs corresponding to the new VMID are
>> flushed
>> + * before using it.
>>*/
>>   flush_tlb_domain(d);
>>
>>   spin_unlock(>lock);
>>
>> -return 0;
>> +if ( hvm_altp2m_supported() )
>> +{
>> +/* Init alternate p2m data */
>> +for ( i = 0; i < MAX_ALTP2M; i++ )
>> +{
>> +d->arch.altp2m_vttbr[i] = INVALID_MFN;
>> +rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
>
> Why do we need to allocate all the altp2m root page tables at the
> creation of the domain? This is wasting up to 80KB (2-root page for 10
> altp2m) per domain even if it may not be used at all by the domain.
>

As previously discussed in patch #05, I will change this behavior in a
way that altp2m views will be allocated at run time only when they are
needed. Thank you.

>> +if ( rc != 0 )
>> +goto out;
>> +}
>> +
>> +d->arch.altp2m_active = 0;
>> +}
>> +
>> +out:
>> +return rc;
>>   }
>>
>>   #define MAX_VMID 256
>> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
>> index 783db5c..451b097 100644
>> --- a/xen/include/asm-arm/p2m.h
>> +++ b/xen/include/asm-arm/p2m.h
>> @@ -171,7 +171,7 @@ int relinquish_p2m_mapping(struct domain *d);
>>*
>>* Returns 0 for success or -errno.
>>*/
>> -int p2m_alloc_table(struct domain *d);
>> +int p2m_table_init(struct domain *d);
>>
>>   /* Context switch */
>>   void p2m_save_state(struct vcpu *p);
>>
>
> Regards,
>

Best,
~Sergej

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

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

[Jan Beulich]

>>> On 05.07.16 at 15:37,  wrote:
> Hi Stefano, Andrew and Jan:
> Could you give us more guides here to move forward virtual iommu 
> development? Thanks.

Due to ...

> On 6/29/2016 11:04 AM, Tian, Kevin wrote:
>> Please let us know your thoughts. If no one has explicit objection based
>> on above rough idea, we'll go to write the high level design doc for more
>> detail discussion.

... this I actually expected we'd get to see something, rather than
our input being waited for.

Jan


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

Re: [Xen-devel] [PATCH RFC v1 09/14] Makefile: delete STUBDOMPATH target

[Wei Liu]

On Tue, Jul 05, 2016 at 01:53:22PM +, Xu, Quan wrote:
> Wei,
> I have spent a lot of days to clean up the code of vtpm / vtpmmgr. but there 
> are tricky issue to boot domu on TPM2.0..
> So I am afraid I can't finish it as today is my last working day at intel.
> 
> Now, these patch are on https://github.com/virt2x/vtpm2vtpmmgr 
> Sorry for that.

No need to be sorry. Thanks for letting us know.

Last but not least, thanks for your contribution to Xen and all the best
with your new journey!

Wei.

> Quan
> 
> On April 01, 2016 6:03 PM, Wei Liu  wrote:
> > On Fri, Apr 01, 2016 at 01:41:40AM +, Xu, Quan wrote:
> > > On March 31, 2016 9:50pm, Wei Liu  wrote:
> > > > On Thu, Mar 31, 2016 at 10:21:22AM +, Xu, Quan wrote:
> > > > > On March 11, 2016 12:53am, Wei Liu  wrote:
> > > > > > -build: $(STUBDOMPATH)
> > > > > > +build: $(STUBDOM_BUILD)
> > > > >
> > > > > Wei,
> > > > > in original code, in stubdom/vtpm and stubdom/vtpmmgr, the code
> > > > > style is inconsistent and ugly.
> > > > I personally prefer small patches in a series, but I don't object to
> > > > having large
> > > > patch(es) either.
> > >
> > > ok. I think so too. It may be one file per patch.
> > >
> > >
> > > > At the end of the day, I think Daniel's opinion matters most.
> > > > After a plan is agreed upon, you can then provide a branch for us to 
> > > > pull in.
> > >
> > > I think I am not authorized to branch, could you provide a branch and 
> > > tell me
> > how to commit to that branch?
> > > Sorry, I am unfamiliar with the upstream process.
> > >
> > 
> > Oh, you don't need to branch on the main tree (xen.git or future 
> > stubdom.git).
> > You can just do the following:
> > 
> >   $ git clone xen.git # or stubdom.git
> >   $ cd xen.git # or stubdom.git
> >   $ git branch wip.vtpm-coding-style-fix-v1
> >   ... do work, commit as you go alone ...
> >   $ git push $some_public_remote wip.vtpm-coding-style-fix-v1
> >   ... post your patch series on xen-devel, along with the git repository
> >   and branch
> > 
> > When your patches are all acked by Daniel, you can then fold all the tags 
> > into
> > your own branch (wip.vtpm-coding-style-fix-v$X-acked)
> > and prod committers to pull from that branch.
> > 
> > > > Note
> > > > that upstream don't test vtpm in any fashion so you do need to run your
> > tests.
> > > >
> > > I will test it. I think I hope Daniel could help my patches.
> > > btw, I have made a quick patch to fix the seal/unseal issue. I will send 
> > > out
> > later.
> > >
> > > > The only thing that matters to me is that when you will do it -- you
> > > > will need to patch a different tree after I split off stubdom. In
> > > > order to minimise the fuss one of us will need to wait for the other.
> > > >
> > > Once you have done, please let me know.
> > 
> > OK, I will try to sort it out within April.  Feel free to ping me if I drop 
> > the ball.
> > 
> > Wei.
> > 
> > > Quan
> > 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

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