All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 00/23] Make CONFIG_HVM work
@ 2018-08-26 12:19 Wei Liu
  2018-08-26 12:19 ` [PATCH v2 01/23] x86: change name of parameter for various invlpg functions Wei Liu
                   ` (22 more replies)
  0 siblings, 23 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Wei Liu

This series goes through x86 code to make CONFIG_HVM work.

With this series, it is possible to build Xen with PV support only.

Running `xl info` on a host with PV only Xen:

root@lcy2-dt108:~# xl info
host                   : lcy2-dt108
release                : 4.17.0-0.bpo.1-amd64
version                : #1 SMP Debian 4.17.8-1~bpo9+1 (2018-07-23)
machine                : x86_64
nr_cpus                : 8
max_cpu_id             : 7
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 2
cpu_mhz                : 3504.241
hw_caps                : bfebfbff:77faf3ff:2c100800:00000121:0000000f:009c6fbf:00000000:00000100
virt_caps              : directio
total_memory           : 32589
free_memory            : 1033
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 12
xen_extra              : -unstable
xen_version            : 4.12-unstable
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : Sun Aug 26 12:36:59 2018 +0100 git:7668e6dcc6
xen_commandline        : placeholder loglvl=all guest_loglvl=all com2=115200,8n1 ucode=scan console=com2,vga console_to_ring sync_console hvm_fep
cc_compiler            : gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
cc_compile_by          : wei
cc_compile_domain      : uk.xensource.com
cc_compile_date        : Sun Aug 26 12:37:04 BST 2018
build_id               : 1a2fb4652d8c26e5590bba6652049696a97ad2ab
xend_config_format     : 4

The major goal at the moment is to get something that works first,
then refine code structure later.  Currently CONFIG_HVM is littered in
individual files. In the future some of the code could / should be
moved to files under hvm/ for cleaner split.

I ran some basic PV / PVSHIM VM life cycle tests and XTF PV tests, all
worked.

Baseline:
$ ls -l xen # default build, non-debug
-rwxrwxr-x 1 wei wei 2379388 Aug 17 15:39 xen

$ ls -l xen # PV only, non-debug
-rwxrwxr-x 1 wei wei 1920572 Aug 26 12:37 xen

The PV only Xen is ~19.3% smaller in size.

Wei.

Wei Liu (23):
  x86: change name of parameter for various invlpg functions
  xen: is_hvm_{domain,vcpu} should evaluate to false when !CONFIG_HVM
  x86: enclose hvm_op and dm_op in CONFIG_HVM in relevant tables
  x86/hvm: provide hvm_hap_supported
  x86: provide stub for memory_type_changed
  x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI
  x86/vpmu: put HVM only code under CONFIG_HVM
  xen/pt: io.c contains HVM only code
  x86/pt: make it build with !CONFIG_HVM
  x86/pt: split out HVM functions from vtd.c
  x86: XENMEM_resource_ioreq_server is HVM only
  x86: monitor.o is currently HVM only
  x86: provide stubs, declarations and macros in hvm.h
  x86/mm: put nested p2m code under CONFIG_HVM
  x86/mm: put HVM only code under CONFIG_HVM
  x86/p2m/pod: make it build with !CONFIG_HVM
  x86/mm: put paging_update_nestedmode under CONFIG_HVM
  x86/domctl: XEN_DOMCTL_debug_op is HVM only
  x86: PIT emulation is common to both PV and HVM
  xen: connect guest creation with CONFIG_{HVM,PV}
  x86: expose CONFIG_HVM
  x86/pvshim: disable HVM for PV shim
  xen: decouple HVM and IOMMU capabilities

 tools/firmware/xen-dir/shim.config       |   2 +-
 tools/libxl/libxl.c                      |   5 +-
 tools/libxl/libxl.h                      |   6 +-
 tools/libxl/libxl_types.idl              |   1 +-
 tools/xl/xl_info.c                       |   5 +-
 xen/arch/arm/Kconfig                     |   3 +-
 xen/arch/x86/Kconfig                     |   6 +-
 xen/arch/x86/Makefile                    |   3 +-
 xen/arch/x86/cpu/vpmu.c                  |   6 +-
 xen/arch/x86/cpuid.c                     |   2 +-
 xen/arch/x86/domain.c                    |   8 +-
 xen/arch/x86/domctl.c                    |   2 +-
 xen/arch/x86/emul-i8254.c                | 609 ++++++++++++++++++++++++-
 xen/arch/x86/hvm/Makefile                |   1 +-
 xen/arch/x86/hvm/i8254.c                 | 597 +------------------------
 xen/arch/x86/hvm/svm/svm.c               |  14 +-
 xen/arch/x86/hvm/vmx/vmx.c               |  12 +-
 xen/arch/x86/hypercall.c                 |   4 +-
 xen/arch/x86/mm.c                        |  16 +-
 xen/arch/x86/mm/Makefile                 |   7 +-
 xen/arch/x86/mm/hap/hap.c                |   2 +-
 xen/arch/x86/mm/p2m.c                    |  23 +-
 xen/arch/x86/mm/paging.c                 |   2 +-
 xen/arch/x86/mm/shadow/multi.c           |  14 +-
 xen/arch/x86/mm/shadow/none.c            |   2 +-
 xen/arch/x86/physdev.c                   |   2 +-
 xen/arch/x86/pv/hypercall.c              |   4 +-
 xen/arch/x86/setup.c                     |   2 +-
 xen/arch/x86/sysctl.c                    |   2 +-
 xen/arch/x86/traps.c                     |   4 +-
 xen/common/domain.c                      |  14 +-
 xen/common/memory.c                      |   3 +-
 xen/common/vm_event.c                    |   2 +-
 xen/drivers/passthrough/Makefile         |   4 +-
 xen/drivers/passthrough/vtd/x86/Makefile |   3 +-
 xen/drivers/passthrough/vtd/x86/hvm.c    |  67 +++-
 xen/drivers/passthrough/vtd/x86/vtd.c    |  45 +--
 xen/include/asm-x86/hvm/domain.h         |   4 +-
 xen/include/asm-x86/hvm/hvm.h            | 160 +++++-
 xen/include/asm-x86/hvm/io.h             |   5 +-
 xen/include/asm-x86/hvm/svm/asid.h       |   4 +-
 xen/include/asm-x86/hvm/svm/svm.h        |   4 +-
 xen/include/asm-x86/hvm/vmx/vmx.h        |   5 +-
 xen/include/asm-x86/monitor.h            |  14 +-
 xen/include/asm-x86/mtrr.h               |   5 +-
 xen/include/asm-x86/p2m.h                |  40 +-
 xen/include/asm-x86/paging.h             |   3 +-
 xen/include/public/sysctl.h              |   8 +-
 xen/include/xen/sched.h                  |  13 +-
 49 files changed, 1048 insertions(+), 721 deletions(-)
 create mode 100644 xen/arch/x86/emul-i8254.c
 delete mode 100644 xen/arch/x86/hvm/i8254.c
 create mode 100644 xen/drivers/passthrough/vtd/x86/hvm.c

base-commit: e5d6ddcd31a6113e4a3db7a235ca78770fe8f401
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* [PATCH v2 01/23] x86: change name of parameter for various invlpg functions
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 13:49   ` Boris Ostrovsky
                     ` (3 more replies)
  2018-08-26 12:19 ` [PATCH v2 02/23] xen: is_hvm_{domain, vcpu} should evaluate to false when !CONFIG_HVM Wei Liu
                   ` (21 subsequent siblings)
  22 siblings, 4 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel
  Cc: Kevin Tian, Wei Liu, Suravee Suthikulpanit, Jun Nakajima,
	Andrew Cooper, Tim Deegan, George Dunlap, Jan Beulich,
	Boris Ostrovsky, Brian Woods

They all incorrectly named a parameter virtual address while it should
have been linear address.

Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/hvm/svm/svm.c         | 14 +++++++-------
 xen/arch/x86/hvm/vmx/vmx.c         | 12 ++++++------
 xen/arch/x86/mm.c                  | 10 +++++-----
 xen/arch/x86/mm/hap/hap.c          |  2 +-
 xen/arch/x86/mm/shadow/multi.c     | 14 +++++++-------
 xen/arch/x86/mm/shadow/none.c      |  2 +-
 xen/include/asm-x86/hvm/hvm.h      |  6 +++---
 xen/include/asm-x86/hvm/svm/asid.h |  4 ++--
 xen/include/asm-x86/hvm/svm/svm.h  |  4 ++--
 xen/include/asm-x86/paging.h       |  3 ++-
 10 files changed, 36 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 37f782b..cecd4f0 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2500,18 +2500,18 @@ static void svm_vmexit_do_invalidate_cache(struct cpu_user_regs *regs)
 }
 
 static void svm_invlpga_intercept(
-    struct vcpu *v, unsigned long vaddr, uint32_t asid)
+    struct vcpu *v, unsigned long linear, uint32_t asid)
 {
-    svm_invlpga(vaddr,
+    svm_invlpga(linear,
                 (asid == 0)
                 ? v->arch.hvm_vcpu.n1asid.asid
                 : vcpu_nestedhvm(v).nv_n2asid.asid);
 }
 
-static void svm_invlpg_intercept(unsigned long vaddr)
+static void svm_invlpg_intercept(unsigned long linear)
 {
-    HVMTRACE_LONG_2D(INVLPG, 0, TRC_PAR_LONG(vaddr));
-    paging_invlpg(current, vaddr);
+    HVMTRACE_LONG_2D(INVLPG, 0, TRC_PAR_LONG(linear));
+    paging_invlpg(current, linear);
 }
 
 static bool is_invlpg(const struct x86_emulate_state *state,
@@ -2524,9 +2524,9 @@ static bool is_invlpg(const struct x86_emulate_state *state,
            (ext & 7) == 7;
 }
 
-static void svm_invlpg(struct vcpu *v, unsigned long vaddr)
+static void svm_invlpg(struct vcpu *v, unsigned long linear)
 {
-    svm_asid_g_invlpg(v, vaddr);
+    svm_asid_g_invlpg(v, linear);
 }
 
 static bool svm_get_pending_event(struct vcpu *v, struct x86_event *info)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 73f0d52..2f4947a 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -75,7 +75,7 @@ static void vmx_wbinvd_intercept(void);
 static void vmx_fpu_dirty_intercept(void);
 static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content);
 static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content);
-static void vmx_invlpg(struct vcpu *v, unsigned long vaddr);
+static void vmx_invlpg(struct vcpu *v, unsigned long linear);
 
 struct vmx_pi_blocking_vcpu {
     struct list_head     list;
@@ -2594,16 +2594,16 @@ static void vmx_dr_access(unsigned long exit_qualification,
     vmx_update_cpu_exec_control(v);
 }
 
-static void vmx_invlpg_intercept(unsigned long vaddr)
+static void vmx_invlpg_intercept(unsigned long linear)
 {
-    HVMTRACE_LONG_2D(INVLPG, /*invlpga=*/ 0, TRC_PAR_LONG(vaddr));
-    paging_invlpg(current, vaddr);
+    HVMTRACE_LONG_2D(INVLPG, /*invlpga=*/ 0, TRC_PAR_LONG(linear));
+    paging_invlpg(current, linear);
 }
 
-static void vmx_invlpg(struct vcpu *v, unsigned long vaddr)
+static void vmx_invlpg(struct vcpu *v, unsigned long linear)
 {
     if ( cpu_has_vmx_vpid )
-        vpid_sync_vcpu_gva(v, vaddr);
+        vpid_sync_vcpu_gva(v, linear);
 }
 
 static int vmx_vmfunc_intercept(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 8ac4412..a774458 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5788,19 +5788,19 @@ const unsigned long *__init get_platform_badpages(unsigned int *array_size)
     return bad_pages;
 }
 
-void paging_invlpg(struct vcpu *v, unsigned long va)
+void paging_invlpg(struct vcpu *v, unsigned long linear)
 {
-    if ( !is_canonical_address(va) )
+    if ( !is_canonical_address(linear) )
         return;
 
     if ( paging_mode_enabled(v->domain) &&
-         !paging_get_hostmode(v)->invlpg(v, va) )
+         !paging_get_hostmode(v)->invlpg(v, linear) )
         return;
 
     if ( is_pv_vcpu(v) )
-        flush_tlb_one_local(va);
+        flush_tlb_one_local(linear);
     else
-        hvm_invlpg(v, va);
+        hvm_invlpg(v, linear);
 }
 
 /* Build a 32bit PSE page table using 4MB pages. */
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 812a840..c78da99 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -650,7 +650,7 @@ static int hap_page_fault(struct vcpu *v, unsigned long va,
  * should not be intercepting it.  However, we need to correctly handle
  * getting here from instruction emulation.
  */
-static bool_t hap_invlpg(struct vcpu *v, unsigned long va)
+static bool_t hap_invlpg(struct vcpu *v, unsigned long linear)
 {
     /*
      * Emulate INVLPGA:
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 9e43533..fe322ec 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3554,7 +3554,7 @@ propagate:
  * instruction should be issued on the hardware, or false if it's safe not
  * to do so.
  */
-static bool sh_invlpg(struct vcpu *v, unsigned long va)
+static bool sh_invlpg(struct vcpu *v, unsigned long linear)
 {
     mfn_t sl1mfn;
     shadow_l2e_t sl2e;
@@ -3577,14 +3577,14 @@ static bool sh_invlpg(struct vcpu *v, unsigned long va)
     {
         shadow_l3e_t sl3e;
         if ( !(shadow_l4e_get_flags(
-                   sh_linear_l4_table(v)[shadow_l4_linear_offset(va)])
+                   sh_linear_l4_table(v)[shadow_l4_linear_offset(linear)])
                & _PAGE_PRESENT) )
             return false;
         /* This must still be a copy-from-user because we don't have the
          * paging lock, and the higher-level shadows might disappear
          * under our feet. */
         if ( __copy_from_user(&sl3e, (sh_linear_l3_table(v)
-                                      + shadow_l3_linear_offset(va)),
+                                      + shadow_l3_linear_offset(linear)),
                               sizeof (sl3e)) != 0 )
         {
             perfc_incr(shadow_invlpg_fault);
@@ -3594,7 +3594,7 @@ static bool sh_invlpg(struct vcpu *v, unsigned long va)
             return false;
     }
 #else /* SHADOW_PAGING_LEVELS == 3 */
-    if ( !(l3e_get_flags(v->arch.paging.shadow.l3table[shadow_l3_linear_offset(va)])
+    if ( !(l3e_get_flags(v->arch.paging.shadow.l3table[shadow_l3_linear_offset(linear)])
            & _PAGE_PRESENT) )
         // no need to flush anything if there's no SL2...
         return false;
@@ -3603,7 +3603,7 @@ static bool sh_invlpg(struct vcpu *v, unsigned long va)
     /* This must still be a copy-from-user because we don't have the shadow
      * lock, and the higher-level shadows might disappear under our feet. */
     if ( __copy_from_user(&sl2e,
-                          sh_linear_l2_table(v) + shadow_l2_linear_offset(va),
+                          sh_linear_l2_table(v) + shadow_l2_linear_offset(linear),
                           sizeof (sl2e)) != 0 )
     {
         perfc_incr(shadow_invlpg_fault);
@@ -3647,7 +3647,7 @@ static bool sh_invlpg(struct vcpu *v, unsigned long va)
              * feet. */
             if ( __copy_from_user(&sl2e,
                                   sh_linear_l2_table(v)
-                                  + shadow_l2_linear_offset(va),
+                                  + shadow_l2_linear_offset(linear),
                                   sizeof (sl2e)) != 0 )
             {
                 perfc_incr(shadow_invlpg_fault);
@@ -3669,7 +3669,7 @@ static bool sh_invlpg(struct vcpu *v, unsigned long va)
                         && page_is_out_of_sync(pg) ) )
             {
                 shadow_l1e_t *sl1;
-                sl1 = sh_linear_l1_table(v) + shadow_l1_linear_offset(va);
+                sl1 = sh_linear_l1_table(v) + shadow_l1_linear_offset(linear);
                 /* Remove the shadow entry that maps this VA */
                 (void) shadow_set_l1e(d, sl1, shadow_l1e_empty(),
                                       p2m_invalid, sl1mfn);
diff --git a/xen/arch/x86/mm/shadow/none.c b/xen/arch/x86/mm/shadow/none.c
index a8c9604..4de645a 100644
--- a/xen/arch/x86/mm/shadow/none.c
+++ b/xen/arch/x86/mm/shadow/none.c
@@ -37,7 +37,7 @@ static int _page_fault(struct vcpu *v, unsigned long va,
     return 0;
 }
 
-static bool _invlpg(struct vcpu *v, unsigned long va)
+static bool _invlpg(struct vcpu *v, unsigned long linear)
 {
     ASSERT_UNREACHABLE();
     return true;
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 146720c..78e7900 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -160,7 +160,7 @@ struct hvm_function_table {
 
     int  (*event_pending)(struct vcpu *v);
     bool (*get_pending_event)(struct vcpu *v, struct x86_event *info);
-    void (*invlpg)(struct vcpu *v, unsigned long vaddr);
+    void (*invlpg)(struct vcpu *v, unsigned long linear);
 
     int  (*cpu_up_prepare)(unsigned int cpu);
     void (*cpu_dead)(unsigned int cpu);
@@ -454,9 +454,9 @@ static inline int hvm_event_pending(struct vcpu *v)
     return hvm_funcs.event_pending(v);
 }
 
-static inline void hvm_invlpg(struct vcpu *v, unsigned long va)
+static inline void hvm_invlpg(struct vcpu *v, unsigned long linear)
 {
-    hvm_funcs.invlpg(v, va);
+    hvm_funcs.invlpg(v, linear);
 }
 
 /* These bits in CR4 are owned by the host. */
diff --git a/xen/include/asm-x86/hvm/svm/asid.h b/xen/include/asm-x86/hvm/svm/asid.h
index d3a144c..b16bd04 100644
--- a/xen/include/asm-x86/hvm/svm/asid.h
+++ b/xen/include/asm-x86/hvm/svm/asid.h
@@ -25,11 +25,11 @@
 void svm_asid_init(const struct cpuinfo_x86 *c);
 void svm_asid_handle_vmrun(void);
 
-static inline void svm_asid_g_invlpg(struct vcpu *v, unsigned long g_vaddr)
+static inline void svm_asid_g_invlpg(struct vcpu *v, unsigned long g_linear)
 {
 #if 0
     /* Optimization? */
-    svm_invlpga(g_vaddr, v->arch.hvm_svm.vmcb->guest_asid);
+    svm_invlpga(g_linear, v->arch.hvm_svm.vmcb->guest_asid);
 #endif
 
     /* Safe fallback. Take a new ASID. */
diff --git a/xen/include/asm-x86/hvm/svm/svm.h b/xen/include/asm-x86/hvm/svm/svm.h
index 4e5e142..8166046 100644
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -40,13 +40,13 @@ static inline void svm_vmsave_pa(paddr_t vmcb)
         : : "a" (vmcb) : "memory" );
 }
 
-static inline void svm_invlpga(unsigned long vaddr, uint32_t asid)
+static inline void svm_invlpga(unsigned long linear, uint32_t asid)
 {
     asm volatile (
         ".byte 0x0f,0x01,0xdf"
         : /* output */
         : /* input */
-        "a" (vaddr), "c" (asid));
+        "a" (linear), "c" (asid));
 }
 
 unsigned long *svm_msrbit(unsigned long *msr_bitmap, uint32_t msr);
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index f440e3e..b51e170 100644
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -110,7 +110,8 @@ struct shadow_paging_mode {
 struct paging_mode {
     int           (*page_fault            )(struct vcpu *v, unsigned long va,
                                             struct cpu_user_regs *regs);
-    bool          (*invlpg                )(struct vcpu *v, unsigned long va);
+    bool          (*invlpg                )(struct vcpu *v,
+                                            unsigned long linear);
     unsigned long (*gva_to_gfn            )(struct vcpu *v,
                                             struct p2m_domain *p2m,
                                             unsigned long va,
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 02/23] xen: is_hvm_{domain, vcpu} should evaluate to false when !CONFIG_HVM
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
  2018-08-26 12:19 ` [PATCH v2 01/23] x86: change name of parameter for various invlpg functions Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 14:24   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 03/23] x86: enclose hvm_op and dm_op in CONFIG_HVM in relevant tables Wei Liu
                   ` (20 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Jan Beulich

Turn them into static inline functions which evaluate to false when
CONFIG_HVM is not set. ARM won't be broken because ARM guests are set
to PV type in the hypervisor.

But ARM has plan to switch to HVM guest type inside the hypervisor, so
preemptively introduce CONFIG_HVM for ARM here.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/arm/Kconfig    |  3 +++
 xen/include/xen/sched.h | 13 +++++++++++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 586bc62..c0e969e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -52,6 +52,9 @@ config HAS_ITS
         prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
         depends on GICV3 && !NEW_VGIC
 
+config HVM
+        def_bool y
+
 config NEW_VGIC
 	bool
 	prompt "Use new VGIC implementation"
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 51ceebe..fdd18a7 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -879,8 +879,17 @@ void watchdog_domain_destroy(struct domain *d);
 
 #define is_pv_domain(d) ((d)->guest_type == guest_type_pv)
 #define is_pv_vcpu(v)   (is_pv_domain((v)->domain))
-#define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm)
-#define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
+
+static inline bool is_hvm_domain(const struct domain *d)
+{
+    return IS_ENABLED(CONFIG_HVM) ? d->guest_type == guest_type_hvm : false;
+}
+
+static inline bool is_hvm_vcpu(const struct vcpu *v)
+{
+    return is_hvm_domain(v->domain);
+}
+
 #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
                            cpumask_weight((v)->cpu_hard_affinity) == 1)
 #ifdef CONFIG_HAS_PASSTHROUGH
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 03/23] x86: enclose hvm_op and dm_op in CONFIG_HVM in relevant tables
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
  2018-08-26 12:19 ` [PATCH v2 01/23] x86: change name of parameter for various invlpg functions Wei Liu
  2018-08-26 12:19 ` [PATCH v2 02/23] xen: is_hvm_{domain, vcpu} should evaluate to false when !CONFIG_HVM Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 14:24   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 04/23] x86/hvm: provide hvm_hap_supported Wei Liu
                   ` (19 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

PV guest (Dom0) needs to able to use these two hypercalls in order to
serve HVM guests. But if xen doesn't support HVM at all there is no
point in exposing them to PV guests.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
v2:
1. Merge two CONFIG_HVMs together
2. Also change args table
---
 xen/arch/x86/hypercall.c    | 4 +++-
 xen/arch/x86/pv/hypercall.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index 90e88c1..74bde5e 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -60,13 +60,15 @@ const hypercall_args_t hypercall_args_table[NR_hypercalls] =
     ARGS(xenoprof_op, 2),
     ARGS(event_channel_op, 2),
     ARGS(physdev_op, 2),
-    ARGS(hvm_op, 2),
     ARGS(sysctl, 1),
     ARGS(domctl, 1),
     ARGS(kexec_op, 2),
     ARGS(tmem_op, 1),
     ARGS(xenpmu_op, 2),
+#ifdef CONFIG_HVM
+    ARGS(hvm_op, 2),
     ARGS(dm_op, 3),
+#endif
     ARGS(mca, 1),
     ARGS(arch_1, 1),
 };
diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index bbc3011..7f42b40 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -68,7 +68,6 @@ const hypercall_table_t pv_hypercall_table[] = {
 #endif
     HYPERCALL(event_channel_op),
     COMPAT_CALL(physdev_op),
-    HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
     HYPERCALL(domctl),
 #ifdef CONFIG_KEXEC
@@ -78,7 +77,10 @@ const hypercall_table_t pv_hypercall_table[] = {
     HYPERCALL(tmem_op),
 #endif
     HYPERCALL(xenpmu_op),
+#ifdef CONFIG_HVM
+    HYPERCALL(hvm_op),
     COMPAT_CALL(dm_op),
+#endif
     HYPERCALL(mca),
     HYPERCALL(arch_1),
 };
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 04/23] x86/hvm: provide hvm_hap_supported
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (2 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 03/23] x86: enclose hvm_op and dm_op in CONFIG_HVM in relevant tables Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 14:25   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 05/23] x86: provide stub for memory_type_changed Wei Liu
                   ` (18 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

And replace direct accesses in non-HVM subsystems to
hvm_funcs.hap_supported with the new function, to avoid accessing an
internal data structure of another subsystem directly.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/cpuid.c          | 2 +-
 xen/arch/x86/domain.c         | 2 +-
 xen/arch/x86/setup.c          | 2 +-
 xen/include/asm-x86/hvm/hvm.h | 5 +++++
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 3d504b3..88694ed 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -475,7 +475,7 @@ static void __init calculate_hvm_max_policy(void)
     *p = host_cpuid_policy;
     cpuid_policy_to_featureset(p, hvm_featureset);
 
-    hvm_featuremask = hvm_funcs.hap_supported ?
+    hvm_featuremask = hvm_hap_supported() ?
         hvm_hap_featuremask : hvm_shadow_featuremask;
 
     for ( i = 0; i < ARRAY_SIZE(hvm_featureset); ++i )
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 5bb900e..eb1e93f 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -506,7 +506,7 @@ int arch_domain_create(struct domain *d,
     /* Need to determine if HAP is enabled before initialising paging */
     if ( is_hvm_domain(d) )
         d->arch.hvm_domain.hap_enabled =
-            hvm_funcs.hap_supported && (config->flags & XEN_DOMCTL_CDF_hap);
+            hvm_hap_supported() && (config->flags & XEN_DOMCTL_CDF_hap);
 
     if ( (rc = paging_domain_init(d, config->flags)) != 0 )
         goto fail;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index a22256f..261861e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1690,7 +1690,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     if ( dom0_pvh )
     {
         dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm_guest |
-                           ((hvm_funcs.hap_supported && !opt_dom0_shadow) ?
+                           ((hvm_hap_supported() && !opt_dom0_shadow) ?
                             XEN_DOMCTL_CDF_hap : 0));
 
         dom0_cfg.arch.emulation_flags |=
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 78e7900..9c73cbf 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -621,6 +621,11 @@ static inline bool_t hvm_is_singlestep_supported(void)
             hvm_funcs.is_singlestep_supported());
 }
 
+static inline bool hvm_hap_supported(void)
+{
+    return hvm_funcs.hap_supported;
+}
+
 /* returns true if hardware supports alternate p2m's */
 static inline bool hvm_altp2m_supported(void)
 {
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 05/23] x86: provide stub for memory_type_changed
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (3 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 04/23] x86/hvm: provide hvm_hap_supported Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 14:28   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI Wei Liu
                   ` (17 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

Jan indicated that for PV guests the memory type is not changed, for
HVM guests memory_type_changed is needed for EPT's effective memory
type calculation.  This means memory_type_changed is HVM only.

Provide a stub to minimise code churn.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/asm-x86/mtrr.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/include/asm-x86/mtrr.h b/xen/include/asm-x86/mtrr.h
index 7edcb94..4be704c 100644
--- a/xen/include/asm-x86/mtrr.h
+++ b/xen/include/asm-x86/mtrr.h
@@ -92,7 +92,12 @@ extern bool_t mtrr_fix_range_msr_set(struct domain *, struct mtrr_state *,
                                      uint32_t row, uint64_t msr_content);
 extern bool_t mtrr_def_type_msr_set(struct domain *, struct mtrr_state *,
                                     uint64_t msr_content);
+#ifdef CONFIG_HVM
 extern void memory_type_changed(struct domain *);
+#else
+static inline void memory_type_changed(struct domain *d) {}
+#endif
+
 extern bool_t pat_msr_set(uint64_t *pat, uint64_t msr);
 
 bool is_var_mtrr_overlapped(const struct mtrr_state *m);
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (4 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 05/23] x86: provide stub for memory_type_changed Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 14:29   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 07/23] x86/vpmu: put HVM only code under CONFIG_HVM Wei Liu
                   ` (16 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/physdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index b87ec90..af7fd84 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -557,6 +557,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
         ret = pci_mmcfg_reserved(info.address, info.segment,
                                  info.start_bus, info.end_bus, info.flags);
+#ifdef CONFIG_HAS_VPCI
         if ( !ret && has_vpci(currd) )
         {
             /*
@@ -567,6 +568,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
                                               info.start_bus, info.end_bus,
                                               info.segment);
         }
+#endif
 
         break;
     }
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 07/23] x86/vpmu: put HVM only code under CONFIG_HVM
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (5 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 15:03   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 08/23] xen/pt: io.c contains HVM only code Wei Liu
                   ` (15 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

Change u32 to uint32_t while at it.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/cpu/vpmu.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index b978e05..fa6762f 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -196,8 +196,10 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 {
     struct vcpu *sampled = current, *sampling;
     struct vpmu_struct *vpmu;
+#ifdef CONFIG_HVM
     struct vlapic *vlapic;
-    u32 vlapic_lvtpc;
+    uint32_t vlapic_lvtpc;
+#endif
 
     /*
      * dom0 will handle interrupt for special domains (e.g. idle domain) or,
@@ -324,6 +326,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         return;
     }
 
+#ifdef CONFIG_HVM
     /* HVM guests */
     vlapic = vcpu_vlapic(sampling);
 
@@ -345,6 +348,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
         sampling->nmi_pending = 1;
         break;
     }
+#endif
 }
 
 static void vpmu_save_force(void *arg)
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 08/23] xen/pt: io.c contains HVM only code
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (6 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 07/23] x86/vpmu: put HVM only code under CONFIG_HVM Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 15:04   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 09/23] x86/pt: make it build with !CONFIG_HVM Wei Liu
                   ` (14 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Wei Liu, Jan Beulich

We also need to make it x86 only because ARM also defines CONFIG_HVM.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
v2: use x86-y list
---
 xen/drivers/passthrough/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/Makefile b/xen/drivers/passthrough/Makefile
index 6087333..d50ab18 100644
--- a/xen/drivers/passthrough/Makefile
+++ b/xen/drivers/passthrough/Makefile
@@ -4,6 +4,8 @@ subdir-$(CONFIG_X86) += x86
 subdir-$(CONFIG_ARM) += arm
 
 obj-y += iommu.o
-obj-$(CONFIG_X86) += io.o
 obj-$(CONFIG_HAS_PCI) += pci.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
+
+x86-$(CONFIG_HVM) := io.o
+obj-$(CONFIG_X86) += $(x86-y)
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 09/23] x86/pt: make it build with !CONFIG_HVM
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (7 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 08/23] xen/pt: io.c contains HVM only code Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 15:07   ` Jan Beulich
  2018-08-30  1:29   ` Tian, Kevin
  2018-08-26 12:19 ` [PATCH v2 10/23] x86/pt: split out HVM functions from vtd.c Wei Liu
                   ` (13 subsequent siblings)
  22 siblings, 2 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel
  Cc: Kevin Tian, Wei Liu, Jan Beulich, Andrew Cooper, Paul Durrant,
	Jun Nakajima

This requires providing stubs for a few functions which are part of
HVM code.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/include/asm-x86/hvm/io.h      | 5 +++++
 xen/include/asm-x86/hvm/vmx/vmx.h | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/xen/include/asm-x86/hvm/io.h b/xen/include/asm-x86/hvm/io.h
index e6b6ed0..8c83fd0 100644
--- a/xen/include/asm-x86/hvm/io.h
+++ b/xen/include/asm-x86/hvm/io.h
@@ -125,7 +125,12 @@ void hvm_interrupt_post(struct vcpu *v, int vector, int type);
 void hvm_dpci_eoi(struct domain *d, unsigned int guest_irq,
                   const union vioapic_redir_entry *ent);
 void msix_write_completion(struct vcpu *);
+
+#ifdef CONFIG_HVM
 void msixtbl_init(struct domain *d);
+#else
+static inline void msixtbl_init(struct domain *d) {}
+#endif
 
 /* Arch-specific MSI data for vPCI. */
 struct vpci_arch_msi {
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
index 89619e4..4966f72 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -611,8 +611,13 @@ void p2m_init_hap_data(struct p2m_domain *p2m);
 void vmx_pi_per_cpu_init(unsigned int cpu);
 void vmx_pi_desc_fixup(unsigned int cpu);
 
+#ifdef CONFIG_HVM
 void vmx_pi_hooks_assign(struct domain *d);
 void vmx_pi_hooks_deassign(struct domain *d);
+#else
+static inline void vmx_pi_hooks_assign(struct domain *d) {}
+static inline void vmx_pi_hooks_deassign(struct domain *d) {}
+#endif
 
 #define APIC_INVALID_DEST           0xffffffff
 
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 10/23] x86/pt: split out HVM functions from vtd.c
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (8 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 09/23] x86/pt: make it build with !CONFIG_HVM Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-30  1:29   ` Tian, Kevin
  2018-08-26 12:19 ` [PATCH v2 11/23] x86: XENMEM_resource_ioreq_server is HVM only Wei Liu
                   ` (12 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Kevin Tian, Wei Liu

Functions are moved to hvm.c. Reorder makefile items while at it.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
v2: reduce and sort inlcudes
---
 xen/drivers/passthrough/vtd/x86/Makefile |  3 +-
 xen/drivers/passthrough/vtd/x86/hvm.c    | 67 +++++++++++++++++++++++++-
 xen/drivers/passthrough/vtd/x86/vtd.c    | 45 +-----------------
 3 files changed, 69 insertions(+), 46 deletions(-)
 create mode 100644 xen/drivers/passthrough/vtd/x86/hvm.c

diff --git a/xen/drivers/passthrough/vtd/x86/Makefile b/xen/drivers/passthrough/vtd/x86/Makefile
index df4509d..4ef00a4 100644
--- a/xen/drivers/passthrough/vtd/x86/Makefile
+++ b/xen/drivers/passthrough/vtd/x86/Makefile
@@ -1,2 +1,3 @@
-obj-y += vtd.o
 obj-y += ats.o
+obj-$(CONFIG_HVM) += hvm.o
+obj-y += vtd.o
diff --git a/xen/drivers/passthrough/vtd/x86/hvm.c b/xen/drivers/passthrough/vtd/x86/hvm.c
new file mode 100644
index 0000000..6675dca
--- /dev/null
+++ b/xen/drivers/passthrough/vtd/x86/hvm.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright (c) 2008, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 <http://www.gnu.org/licenses/>.
+ *
+ * Copyright (C) Allen Kay <allen.m.kay@intel.com>
+ * Copyright (C) Weidong Han <weidong.han@intel.com>
+ */
+
+#include <xen/iommu.h>
+#include <xen/irq.h>
+#include <xen/sched.h>
+
+static int _hvm_dpci_isairq_eoi(struct domain *d,
+                                struct hvm_pirq_dpci *pirq_dpci, void *arg)
+{
+    struct hvm_irq *hvm_irq = hvm_domain_irq(d);
+    unsigned int isairq = (long)arg;
+    const struct dev_intx_gsi_link *digl;
+
+    list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
+    {
+        unsigned int link = hvm_pci_intx_link(digl->device, digl->intx);
+
+        if ( hvm_irq->pci_link.route[link] == isairq )
+        {
+            hvm_pci_intx_deassert(d, digl->device, digl->intx);
+            if ( --pirq_dpci->pending == 0 )
+            {
+                stop_timer(&pirq_dpci->timer);
+                pirq_guest_eoi(dpci_pirq(pirq_dpci));
+            }
+        }
+    }
+
+    return 0;
+}
+
+void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq)
+{
+    struct hvm_irq_dpci *dpci = NULL;
+
+    ASSERT(isairq < NR_ISAIRQS);
+    if ( !iommu_enabled )
+        return;
+
+    spin_lock(&d->event_lock);
+
+    dpci = domain_get_irq_dpci(d);
+
+    if ( dpci && test_bit(isairq, dpci->isairq_map) )
+    {
+        /* Multiple mirq may be mapped to one isa irq */
+        pt_pirq_iterate(d, _hvm_dpci_isairq_eoi, (void *)(long)isairq);
+    }
+    spin_unlock(&d->event_lock);
+}
diff --git a/xen/drivers/passthrough/vtd/x86/vtd.c b/xen/drivers/passthrough/vtd/x86/vtd.c
index 00a9891..ac653ee 100644
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -63,51 +63,6 @@ void flush_all_cache()
     wbinvd();
 }
 
-static int _hvm_dpci_isairq_eoi(struct domain *d,
-                                struct hvm_pirq_dpci *pirq_dpci, void *arg)
-{
-    struct hvm_irq *hvm_irq = hvm_domain_irq(d);
-    unsigned int isairq = (long)arg;
-    const struct dev_intx_gsi_link *digl;
-
-    list_for_each_entry ( digl, &pirq_dpci->digl_list, list )
-    {
-        unsigned int link = hvm_pci_intx_link(digl->device, digl->intx);
-
-        if ( hvm_irq->pci_link.route[link] == isairq )
-        {
-            hvm_pci_intx_deassert(d, digl->device, digl->intx);
-            if ( --pirq_dpci->pending == 0 )
-            {
-                stop_timer(&pirq_dpci->timer);
-                pirq_guest_eoi(dpci_pirq(pirq_dpci));
-            }
-        }
-    }
-
-    return 0;
-}
-
-void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq)
-{
-    struct hvm_irq_dpci *dpci = NULL;
-
-    ASSERT(isairq < NR_ISAIRQS);
-    if ( !iommu_enabled)
-        return;
-
-    spin_lock(&d->event_lock);
-
-    dpci = domain_get_irq_dpci(d);
-
-    if ( dpci && test_bit(isairq, dpci->isairq_map) )
-    {
-        /* Multiple mirq may be mapped to one isa irq */
-        pt_pirq_iterate(d, _hvm_dpci_isairq_eoi, (void *)(long)isairq);
-    }
-    spin_unlock(&d->event_lock);
-}
-
 void __hwdom_init vtd_set_hwdom_mapping(struct domain *d)
 {
     unsigned long i, top, max_pfn;
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 11/23] x86: XENMEM_resource_ioreq_server is HVM only
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (9 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 10/23] x86/pt: split out HVM functions from vtd.c Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 15:13   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 12/23] x86: monitor.o is currently " Wei Liu
                   ` (11 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

Put the entire case branch under CONFIG_HVM.

Nonetheless check HVM before trying to get ioreq server.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
v2: put entire case branch under CONFIG_HVM
---
 xen/arch/x86/mm.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a774458..ec3caf4 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4376,12 +4376,17 @@ int arch_acquire_resource(struct domain *d, unsigned int type,
 
     switch ( type )
     {
+#ifdef CONFIG_HVM
     case XENMEM_resource_ioreq_server:
     {
         ioservid_t ioservid = id;
         unsigned int i;
 
         rc = -EINVAL;
+        if ( !is_hvm_domain(d) )
+            break;
+
+        rc = -EINVAL;
         if ( id != (unsigned int)ioservid )
             break;
 
@@ -4404,6 +4409,7 @@ int arch_acquire_resource(struct domain *d, unsigned int type,
         *flags |= XENMEM_rsrc_acq_caller_owned;
         break;
     }
+#endif
 
     default:
         rc = -EOPNOTSUPP;
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 12/23] x86: monitor.o is currently HVM only
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (10 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 11/23] x86: XENMEM_resource_ioreq_server is HVM only Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-26 16:33   ` Razvan Cojocaru
  2018-08-27 15:18   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 13/23] x86: provide stubs, declarations and macros in hvm.h Wei Liu
                   ` (10 subsequent siblings)
  22 siblings, 2 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel
  Cc: Andrew Cooper, Tamas K Lengyel, Wei Liu, Razvan Cojocaru, Jan Beulich

There has been plan to make PV work, but it is not yet there.  Provide
stubs to make it build with !CONFIG_HVM.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/Makefile         |  2 +-
 xen/include/asm-x86/monitor.h | 14 ++++++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 9b9b63a..43f9189 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -45,7 +45,7 @@ obj-y += microcode_amd.o
 obj-y += microcode_intel.o
 obj-y += microcode.o
 obj-y += mm.o x86_64/mm.o
-obj-y += monitor.o
+obj-$(CONFIG_HVM) += monitor.o
 obj-y += mpparse.o
 obj-y += nmi.o
 obj-y += numa.o
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 4988903..09f7f8a 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -99,10 +99,24 @@ static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
 int arch_monitor_domctl_event(struct domain *d,
                               struct xen_domctl_monitor_op *mop);
 
+#ifdef CONFIG_HVM
+
 int arch_monitor_init_domain(struct domain *d);
 
 void arch_monitor_cleanup_domain(struct domain *d);
 
+#else
+
+static inline int arch_monitor_init_domain(struct domain *d)
+{
+    return 0;
+}
+
+static inline void arch_monitor_cleanup_domain(struct domain *d)
+{}
+
+#endif
+
 bool monitored_msr(const struct domain *d, u32 msr);
 bool monitored_msr_onchangeonly(const struct domain *d, u32 msr);
 
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 13/23] x86: provide stubs, declarations and macros in hvm.h
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (11 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 12/23] x86: monitor.o is currently " Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 15:43   ` Jan Beulich
  2018-09-03  9:45   ` Paul Durrant
  2018-08-26 12:19 ` [PATCH v2 14/23] x86/mm: put nested p2m code under CONFIG_HVM Wei Liu
                   ` (9 subsequent siblings)
  22 siblings, 2 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

Make sure hvm_enabled evaluate to false then provide necessary stubs,
declarations and macros to make Xen build.

The is_viridian_domain macro can't be turned into an inline function
easily, so instead its caller is modified to avoid unused variable
warning.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/traps.c          |   4 +-
 xen/include/asm-x86/hvm/hvm.h | 149 ++++++++++++++++++++++++++++++++++-
 2 files changed, 148 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index ddff346..27b9651 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -771,9 +771,9 @@ static void do_trap(struct cpu_user_regs *regs)
 /* Returns 0 if not handled, and non-0 for success. */
 int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val)
 {
-    struct domain *d = current->domain;
     /* Optionally shift out of the way of Viridian architectural MSRs. */
-    uint32_t base = is_viridian_domain(d) ? 0x40000200 : 0x40000000;
+    uint32_t base = is_viridian_domain(current->domain)
+        ? 0x40000200 : 0x40000000;
 
     switch ( idx - base )
     {
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 9c73cbf..7820586 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -235,7 +235,10 @@ struct hvm_function_table {
 };
 
 extern struct hvm_function_table hvm_funcs;
-extern bool_t hvm_enabled;
+
+#ifdef CONFIG_HVM
+extern bool hvm_enabled;
+
 extern s8 hvm_port80_allowed;
 
 extern const struct hvm_function_table *start_svm(void);
@@ -268,8 +271,8 @@ u64 hvm_get_guest_tsc_fixed(struct vcpu *v, u64 at_tsc);
 #define hvm_tsc_scaling_ratio(d) \
     ((d)->arch.hvm_domain.tsc_scaling_ratio)
 
-u64 hvm_scale_tsc(const struct domain *d, u64 tsc);
-u64 hvm_get_tsc_scaling_ratio(u32 gtsc_khz);
+uint64_t hvm_scale_tsc(const struct domain *d, uint64_t tsc);
+uint64_t hvm_get_tsc_scaling_ratio(uint32_t gtsc_khz);
 
 void hvm_init_guest_time(struct domain *d);
 void hvm_set_guest_time(struct vcpu *v, u64 guest_time);
@@ -675,6 +678,146 @@ unsigned long hvm_cr4_guest_valid_bits(const struct domain *d, bool restore);
         d_->arch.hvm_domain.pi_ops.vcpu_block(v_);          \
 })
 
+#else /* CONFIG_HVM */
+
+#define hvm_enabled false
+
+static inline int hvm_guest_x86_mode(struct vcpu *v)
+{
+    ASSERT_UNREACHABLE();
+    return -1;
+}
+
+static inline bool hvm_is_singlestep_supported(void)
+{
+    ASSERT_UNREACHABLE();
+    return false;
+}
+
+static inline int vmsi_deliver(
+    struct domain *d, int vector,
+    uint8_t dest, uint8_t dest_mode,
+    uint8_t delivery_mode, uint8_t trig_mode)
+{
+    ASSERT_UNREACHABLE();
+    return -EINVAL;
+}
+
+static inline bool nhvm_vmcx_hap_enabled(struct vcpu *v)
+{
+    return false;
+}
+
+static inline bool hvm_hap_supported(void)
+{
+    return false;
+}
+
+static inline void hvm_set_info_guest(struct vcpu *v)
+{
+    ASSERT_UNREACHABLE();
+}
+
+static inline void hvm_cpuid_policy_changed(struct vcpu *v)
+{
+    ASSERT_UNREACHABLE();
+}
+
+static inline void hvm_flush_guest_tlbs(void)
+{
+    ASSERT_UNREACHABLE();
+}
+
+static inline void hvm_invlpg(struct vcpu *v, unsigned long linear)
+{
+    ASSERT_UNREACHABLE();
+}
+
+static inline int hvm_cpu_up(void)
+{
+    return 0;
+}
+
+static inline void hvm_cpu_down(void)
+{
+}
+
+static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
+{
+    ASSERT_UNREACHABLE();
+    return 0;
+}
+
+static inline void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset,
+                                      uint64_t at_tsc)
+{
+    ASSERT_UNREACHABLE();
+}
+
+static inline void hvm_update_host_cr3(struct vcpu *v)
+{
+    ASSERT_UNREACHABLE();
+}
+
+static inline unsigned int hvm_get_cpl(struct vcpu *v)
+{
+    ASSERT_UNREACHABLE();
+    return -1;
+}
+
+static inline int hvm_event_pending(struct vcpu *v)
+{
+    return 0;
+}
+
+static inline void hvm_inject_hw_exception(unsigned int vector, int errcode)
+{
+    ASSERT_UNREACHABLE();
+}
+
+static inline void hvm_update_guest_cr3(struct vcpu *v, bool noflush)
+{
+    ASSERT_UNREACHABLE();
+}
+
+#define hvm_long_mode_active(v) (false)
+#define hvm_pae_enabled(v) (false)
+#define hvm_get_guest_time(v) (0)
+#define is_viridian_domain(d) (false)
+#define has_viridian_time_ref_count(d) (false)
+#define hvm_tsc_scaling_supported (false)
+#define hap_has_1gb (false)
+#define hap_has_2mb (false)
+
+#define hvm_paging_enabled(v) (false)
+#define hvm_nx_enabled(v) (false)
+#define hvm_wp_enabled(v) (false)
+#define hvm_smap_enabled(v) (false)
+#define hvm_smep_enabled(v) (false)
+#define hvm_pku_enabled(v) (false)
+
+#define arch_vcpu_block(v) ((void)v)
+
+int hvm_vcpu_initialise(struct vcpu *v);
+void hvm_vcpu_destroy(struct vcpu *v);
+int hvm_domain_initialise(struct domain *d);
+void hvm_domain_destroy(struct domain *d);
+void hvm_domain_soft_reset(struct domain *d);
+void hvm_domain_relinquish_resources(struct domain *d);
+uint64_t hvm_scale_tsc(const struct domain *d, uint64_t tsc);
+uint64_t hvm_get_tsc_scaling_ratio(uint32_t gtsc_khz);
+
+void hvm_get_segment_register(struct vcpu *v, enum x86_segment seg,
+                              struct segment_register *reg);
+
+void hvm_set_rdtsc_exiting(struct domain *d, bool_t enable);
+void hvm_toggle_singlestep(struct vcpu *v);
+void hvm_mapped_guest_frames_mark_dirty(struct domain *);
+void hvm_hypercall_page_initialise(struct domain *d,
+                                   void *hypercall_page);
+
+#endif /* CONFIG_HVM */
+
 #endif /* __ASM_X86_HVM_HVM_H__ */
 
 /*
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 14/23] x86/mm: put nested p2m code under CONFIG_HVM
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (12 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 13/23] x86: provide stubs, declarations and macros in hvm.h Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-27 15:56   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 15/23] x86/mm: put HVM only " Wei Liu
                   ` (8 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: George Dunlap, Andrew Cooper, Wei Liu, Jan Beulich

These functions are only useful for nested hvm, which isn't enabled
when CONFIG_HVM is false.

Enclose relevant code in CONFIG_HVM. Guard np2m_schedule with
nestedhvm_enabled.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/domain.c | 6 ++++--
 xen/arch/x86/mm/p2m.c | 6 ++++++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index eb1e93f..a996741 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1689,7 +1689,8 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
     {
         _update_runstate_area(prev);
         vpmu_switch_from(prev);
-        np2m_schedule(NP2M_SCHEDLE_OUT);
+        if ( nestedhvm_enabled(prevd) )
+            np2m_schedule(NP2M_SCHEDLE_OUT);
     }
 
     if ( is_hvm_domain(prevd) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
@@ -1756,7 +1757,8 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
         /* Must be done with interrupts enabled */
         vpmu_switch_to(next);
-        np2m_schedule(NP2M_SCHEDLE_IN);
+        if ( nestedhvm_enabled(nextd) )
+            np2m_schedule(NP2M_SCHEDLE_IN);
     }
 
     /* Ensure that the vcpu has an up-to-date time base. */
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 1089b86..c82db32 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -144,6 +144,7 @@ static void p2m_teardown_hostp2m(struct domain *d)
 
 static void p2m_teardown_nestedp2m(struct domain *d)
 {
+#ifdef CONFIG_HVM
     unsigned int i;
     struct p2m_domain *p2m;
 
@@ -156,10 +157,12 @@ static void p2m_teardown_nestedp2m(struct domain *d)
         p2m_free_one(p2m);
         d->arch.nested_p2m[i] = NULL;
     }
+#endif
 }
 
 static int p2m_init_nestedp2m(struct domain *d)
 {
+#ifdef CONFIG_HVM
     unsigned int i;
     struct p2m_domain *p2m;
 
@@ -176,6 +179,7 @@ static int p2m_init_nestedp2m(struct domain *d)
         p2m->write_p2m_entry = nestedp2m_write_p2m_entry;
         list_add(&p2m->np2m_list, &p2m_get_hostp2m(d)->np2m_list);
     }
+#endif
 
     return 0;
 }
@@ -1714,6 +1718,7 @@ void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
         p2m_switch_vcpu_altp2m_by_id(v, idx);
 }
 
+#ifdef CONFIG_HVM
 static struct p2m_domain *
 p2m_getlru_nestedp2m(struct domain *d, struct p2m_domain *p2m)
 {
@@ -1969,6 +1974,7 @@ void np2m_schedule(int dir)
         p2m_unlock(p2m);
     }
 }
+#endif
 
 unsigned long paging_gva_to_gfn(struct vcpu *v,
                                 unsigned long va,
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 15/23] x86/mm: put HVM only code under CONFIG_HVM
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (13 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 14/23] x86/mm: put nested p2m code under CONFIG_HVM Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-26 16:39   ` Razvan Cojocaru
                     ` (2 more replies)
  2018-08-26 12:19 ` [PATCH v2 16/23] x86/p2m/pod: make it build with !CONFIG_HVM Wei Liu
                   ` (7 subsequent siblings)
  22 siblings, 3 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel
  Cc: Tamas K Lengyel, Wei Liu, Razvan Cojocaru, George Dunlap,
	Andrew Cooper, Jan Beulich

Going through the code, HAP, EPT, PoD and ALTP2M depend on HVM code.
Put these components under CONFIG_HVM. This further requires putting
one of the vm event under CONFIG_HVM.

Also make hap_enabled evaluate to false when !CONFIG_HVM. This in turn
requires marking a variable in p2m_set_entry as __maybe_unused.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/mm/Makefile         |  7 ++++---
 xen/arch/x86/mm/p2m.c            | 17 ++++++++++-------
 xen/common/vm_event.c            |  2 ++
 xen/include/asm-x86/hvm/domain.h |  4 ++++
 4 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index 3017119..e3b7be8 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -1,9 +1,10 @@
 subdir-y += shadow
-subdir-y += hap
+subdir-$(CONFIG_HVM) += hap
 
 obj-y += paging.o
-obj-y += p2m.o p2m-pt.o p2m-ept.o p2m-pod.o
-obj-y += altp2m.o
+obj-y += p2m.o p2m-pt.o
+obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
+obj-$(CONFIG_HVM) += altp2m.o
 obj-y += guest_walk_2.o
 obj-y += guest_walk_3.o
 obj-y += guest_walk_4.o
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c82db32..e41d6bf 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -535,7 +535,7 @@ struct page_info *p2m_get_page_from_gfn(
 int p2m_set_entry(struct p2m_domain *p2m, gfn_t gfn, mfn_t mfn,
                   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
-    struct domain *d = p2m->domain;
+    struct domain * __maybe_unused d = p2m->domain;
     unsigned long todo = 1ul << page_order;
     unsigned int order;
     int set_rc, rc = 0;
@@ -1712,12 +1712,6 @@ void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
     }
 }
 
-void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
-{
-    if ( altp2m_active(v->domain) )
-        p2m_switch_vcpu_altp2m_by_id(v, idx);
-}
-
 #ifdef CONFIG_HVM
 static struct p2m_domain *
 p2m_getlru_nestedp2m(struct domain *d, struct p2m_domain *p2m)
@@ -2165,6 +2159,14 @@ int unmap_mmio_regions(struct domain *d,
     return i == nr ? 0 : i ?: ret;
 }
 
+#ifdef CONFIG_HVM
+
+void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
+{
+    if ( altp2m_active(v->domain) )
+        p2m_switch_vcpu_altp2m_by_id(v, idx);
+}
+
 bool_t p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsigned int idx)
 {
     struct domain *d = v->domain;
@@ -2542,6 +2544,7 @@ int p2m_altp2m_propagate_change(struct domain *d, gfn_t gfn,
 
     return ret;
 }
+#endif /* CONFIG_HVM */
 
 /*** Audit ***/
 
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 144ab81..4d06c8f 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -429,9 +429,11 @@ void vm_event_resume(struct domain *d, struct vm_event_domain *ved)
              */
             vm_event_toggle_singlestep(d, v, &rsp);
 
+#ifdef CONFIG_HVM
             /* Check for altp2m switch */
             if ( rsp.flags & VM_EVENT_FLAG_ALTERNATE_P2M )
                 p2m_altp2m_check(v, rsp.altp2m_idx);
+#endif
 
             if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
                 vm_event_set_registers(v, &rsp);
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 5885950..4517f89 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -202,7 +202,11 @@ struct hvm_domain {
     };
 };
 
+#ifdef CONFIG_HVM
 #define hap_enabled(d)  ((d)->arch.hvm_domain.hap_enabled)
+#else
+#define hap_enabled(d)  false
+#endif
 
 #endif /* __ASM_X86_HVM_DOMAIN_H__ */
 
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 16/23] x86/p2m/pod: make it build with !CONFIG_HVM
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (14 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 15/23] x86/mm: put HVM only " Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-28 10:47   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM Wei Liu
                   ` (6 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Jan Beulich

Populate-on-demand is HVM only. Provide a bunch of stubs for common
p2m code and guard one invocation of guest_physmap_mark_populate_on_demand
with is_hvm_domain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/memory.c       |  3 ++-
 xen/include/asm-x86/p2m.h | 40 ++++++++++++++++++++++++++++++++++++----
 2 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 996f94b..5c71ce1 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -210,7 +210,8 @@ static void populate_physmap(struct memop_args *a)
             if ( d == curr_d )
                 goto out;
 
-            if ( guest_physmap_mark_populate_on_demand(d, gpfn,
+            if ( is_hvm_domain(d) &&
+                 guest_physmap_mark_populate_on_demand(d, gpfn,
                                                        a->extent_order) < 0 )
                 goto out;
         }
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index d4b3cfc..d0c25ea 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -646,6 +646,12 @@ int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
 /* Dump PoD information about the domain */
 void p2m_pod_dump_data(struct domain *d);
 
+#ifdef CONFIG_HVM
+
+/* Called by p2m code when demand-populating a PoD page */
+bool
+p2m_pod_demand_populate(struct p2m_domain *p2m, gfn_t gfn, unsigned int order);
+
 /* Move all pages from the populate-on-demand cache to the domain page_list
  * (usually in preparation for domain destruction) */
 int p2m_pod_empty_cache(struct domain *d);
@@ -662,6 +668,36 @@ p2m_pod_offline_or_broken_hit(struct page_info *p);
 void
 p2m_pod_offline_or_broken_replace(struct page_info *p);
 
+#else
+
+static inline bool
+p2m_pod_demand_populate(struct p2m_domain *p2m, gfn_t gfn, unsigned int order)
+{
+    return false;
+}
+
+static inline int p2m_pod_empty_cache(struct domain *d)
+{
+    return 0;
+}
+
+static inline int p2m_pod_set_mem_target(struct domain *d, unsigned long target)
+{
+    return 0;
+}
+
+static inline int p2m_pod_offline_or_broken_hit(struct page_info *p)
+{
+    return 0;
+}
+
+static inline void p2m_pod_offline_or_broken_replace(struct page_info *p)
+{
+    ASSERT_UNREACHABLE();
+}
+
+#endif
+
 
 /*
  * Paging to disk and page-sharing
@@ -730,10 +766,6 @@ extern void audit_p2m(struct domain *d,
 #define P2M_DEBUG(f, a...) do { (void)(f); } while(0)
 #endif
 
-/* Called by p2m code when demand-populating a PoD page */
-bool
-p2m_pod_demand_populate(struct p2m_domain *p2m, gfn_t gfn, unsigned int order);
-
 /*
  * Functions specific to the p2m-pt implementation
  */
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (15 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 16/23] x86/p2m/pod: make it build with !CONFIG_HVM Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-28 10:50   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 18/23] x86/domctl: XEN_DOMCTL_debug_op is HVM only Wei Liu
                   ` (5 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: George Dunlap, Andrew Cooper, Wei Liu, Jan Beulich

Nested HVM is not enabled when !CONFIG_HVM.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/mm/paging.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index dcee496..7f460bd 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct vcpu *v)
     return paging_get_nestedmode(v);
 }
 
+#ifdef CONFIG_HVM
 void paging_update_nestedmode(struct vcpu *v)
 {
     ASSERT(nestedhvm_enabled(v->domain));
@@ -930,6 +931,7 @@ void paging_update_nestedmode(struct vcpu *v)
         v->arch.paging.nestedmode = NULL;
     hvm_asid_flush_vcpu(v);
 }
+#endif
 
 void paging_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
                             l1_pgentry_t *p, l1_pgentry_t new,
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 18/23] x86/domctl: XEN_DOMCTL_debug_op is HVM only
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (16 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-28 10:50   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM Wei Liu
                   ` (4 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/domctl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index ab85489..6f1c43e 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -975,6 +975,7 @@ long arch_do_domctl(
         d->arch.suppress_spurious_page_faults = 1;
         break;
 
+#ifdef CONFIG_HVM
     case XEN_DOMCTL_debug_op:
     {
         struct vcpu *v;
@@ -992,6 +993,7 @@ long arch_do_domctl(
         ret = hvm_debug_op(v, domctl->u.debug_op.op);
         break;
     }
+#endif
 
     case XEN_DOMCTL_gdbsx_guestmemio:
         domctl->u.gdbsx_guest_memio.remain = domctl->u.gdbsx_guest_memio.len;
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (17 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 18/23] x86/domctl: XEN_DOMCTL_debug_op is HVM only Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-28 11:44   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV} Wei Liu
                   ` (3 subsequent siblings)
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

Move the file to x86 common code and change its name to emul-i8254.c.

Put HVM only code under CONFIG_HVM or is_hvm_domain.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
v2: move the whole file.
---
 xen/arch/x86/Makefile     |   1 +-
 xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
 xen/arch/x86/hvm/Makefile |   1 +-
 xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
 4 files changed, 610 insertions(+), 598 deletions(-)
 create mode 100644 xen/arch/x86/emul-i8254.c
 delete mode 100644 xen/arch/x86/hvm/i8254.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 43f9189..c03bca6 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -27,6 +27,7 @@ obj-y += domain.o
 obj-bin-y += dom0_build.init.o
 obj-y += domain_page.o
 obj-y += e820.o
+obj-y += emul-i8254.o
 obj-y += extable.o
 obj-y += flushtlb.o
 obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
diff --git a/xen/arch/x86/emul-i8254.c b/xen/arch/x86/emul-i8254.c
new file mode 100644
index 0000000..f4436f8
--- /dev/null
+++ b/xen/arch/x86/emul-i8254.c
@@ -0,0 +1,609 @@
+/*
+ * QEMU 8253/8254 interval timer emulation
+ * 
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyright (c) 2006 Intel Corperation
+ * Copyright (c) 2007 Keir Fraser, XenSource Inc.
+ * 
+ * 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 PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <xen/types.h>
+#include <xen/mm.h>
+#include <xen/xmalloc.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/sched.h>
+#include <xen/trace.h>
+#include <asm/time.h>
+#include <asm/hvm/hvm.h>
+#include <asm/hvm/io.h>
+#include <asm/hvm/support.h>
+#include <asm/hvm/vpt.h>
+#include <asm/current.h>
+
+#define domain_vpit(x) (&(x)->arch.vpit)
+#define vcpu_vpit(x)   (domain_vpit((x)->domain))
+#define vpit_domain(x) (container_of((x), struct domain, arch.vpit))
+#define vpit_vcpu(x)   (pt_global_vcpu_target(vpit_domain(x)))
+
+#define RW_STATE_LSB 1
+#define RW_STATE_MSB 2
+#define RW_STATE_WORD0 3
+#define RW_STATE_WORD1 4
+
+static int handle_pit_io(
+    int dir, unsigned int port, unsigned int bytes, uint32_t *val);
+static int handle_speaker_io(
+    int dir, unsigned int port, unsigned int bytes, uint32_t *val);
+
+#define get_guest_time(v) \
+   (is_hvm_vcpu(v) ? hvm_get_guest_time(v) : (u64)get_s_time())
+
+static int pit_get_count(PITState *pit, int channel)
+{
+    uint64_t d;
+    int  counter;
+    struct hvm_hw_pit_channel *c = &pit->hw.channels[channel];
+    struct vcpu *v = vpit_vcpu(pit);
+
+    ASSERT(spin_is_locked(&pit->lock));
+
+    d = muldiv64(get_guest_time(v) - pit->count_load_time[channel],
+                 PIT_FREQ, SYSTEM_TIME_HZ);
+
+    switch ( c->mode )
+    {
+    case 0:
+    case 1:
+    case 4:
+    case 5:
+        counter = (c->count - d) & 0xffff;
+        break;
+    case 3:
+        /* XXX: may be incorrect for odd counts */
+        counter = c->count - ((2 * d) % c->count);
+        break;
+    default:
+        counter = c->count - (d % c->count);
+        break;
+    }
+    return counter;
+}
+
+static int pit_get_out(PITState *pit, int channel)
+{
+    struct hvm_hw_pit_channel *s = &pit->hw.channels[channel];
+    uint64_t d;
+    int out;
+    struct vcpu *v = vpit_vcpu(pit);
+
+    ASSERT(spin_is_locked(&pit->lock));
+
+    d = muldiv64(get_guest_time(v) - pit->count_load_time[channel], 
+                 PIT_FREQ, SYSTEM_TIME_HZ);
+
+    switch ( s->mode )
+    {
+    default:
+    case 0:
+        out = (d >= s->count);
+        break;
+    case 1:
+        out = (d < s->count);
+        break;
+    case 2:
+        out = (((d % s->count) == 0) && (d != 0));
+        break;
+    case 3:
+        out = ((d % s->count) < ((s->count + 1) >> 1));
+        break;
+    case 4:
+    case 5:
+        out = (d == s->count);
+        break;
+    }
+
+    return out;
+}
+
+static void pit_set_gate(PITState *pit, int channel, int val)
+{
+    struct hvm_hw_pit_channel *s = &pit->hw.channels[channel];
+    struct vcpu *v = vpit_vcpu(pit);
+
+    ASSERT(spin_is_locked(&pit->lock));
+
+    switch ( s->mode )
+    {
+    default:
+    case 0:
+    case 4:
+        /* XXX: just disable/enable counting */
+        break;
+    case 1:
+    case 5:
+    case 2:
+    case 3:
+        /* Restart counting on rising edge. */
+        if ( s->gate < val )
+            pit->count_load_time[channel] = get_guest_time(v);
+        break;
+    }
+
+    s->gate = val;
+}
+
+static int pit_get_gate(PITState *pit, int channel)
+{
+    ASSERT(spin_is_locked(&pit->lock));
+    return pit->hw.channels[channel].gate;
+}
+
+#ifdef CONFIG_HVM
+static void pit_time_fired(struct vcpu *v, void *priv)
+{
+    uint64_t *count_load_time = priv;
+    TRACE_0D(TRC_HVM_EMUL_PIT_TIMER_CB);
+    *count_load_time = get_guest_time(v);
+}
+#endif
+
+static void pit_load_count(PITState *pit, int channel, int val)
+{
+    u32 period;
+    struct hvm_hw_pit_channel *s = &pit->hw.channels[channel];
+    struct vcpu *v = vpit_vcpu(pit);
+
+    ASSERT(spin_is_locked(&pit->lock));
+
+    if ( val == 0 )
+        val = 0x10000;
+
+    if ( v == NULL )
+        pit->count_load_time[channel] = 0;
+    else
+        pit->count_load_time[channel] = get_guest_time(v);
+    s->count = val;
+    period = DIV_ROUND(val * SYSTEM_TIME_HZ, PIT_FREQ);
+
+    if ( (v == NULL) || !is_hvm_vcpu(v) || (channel != 0) )
+        return;
+
+#ifdef CONFIG_HVM
+    switch ( s->mode )
+    {
+    case 2:
+    case 3:
+        /* Periodic timer. */
+        TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, period);
+        create_periodic_time(v, &pit->pt0, period, period, 0, pit_time_fired, 
+                             &pit->count_load_time[channel], false);
+        break;
+    case 1:
+    case 4:
+        /* One-shot timer. */
+        TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, 0);
+        create_periodic_time(v, &pit->pt0, period, 0, 0, pit_time_fired,
+                             &pit->count_load_time[channel], false);
+        break;
+    default:
+        TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
+        destroy_periodic_time(&pit->pt0);
+        break;
+    }
+#endif
+}
+
+static void pit_latch_count(PITState *pit, int channel)
+{
+    struct hvm_hw_pit_channel *c = &pit->hw.channels[channel];
+
+    ASSERT(spin_is_locked(&pit->lock));
+
+    if ( !c->count_latched )
+    {
+        c->latched_count = pit_get_count(pit, channel);
+        c->count_latched = c->rw_mode;
+    }
+}
+
+static void pit_latch_status(PITState *pit, int channel)
+{
+    struct hvm_hw_pit_channel *c = &pit->hw.channels[channel];
+
+    ASSERT(spin_is_locked(&pit->lock));
+
+    if ( !c->status_latched )
+    {
+        /* TODO: Return NULL COUNT (bit 6). */
+        c->status = ((pit_get_out(pit, channel) << 7) |
+                     (c->rw_mode << 4) |
+                     (c->mode << 1) |
+                     c->bcd);
+        c->status_latched = 1;
+    }
+}
+
+static void pit_ioport_write(struct PITState *pit, uint32_t addr, uint32_t val)
+{
+    int channel, access;
+    struct hvm_hw_pit_channel *s;
+
+    val  &= 0xff;
+    addr &= 3;
+
+    spin_lock(&pit->lock);
+
+    if ( addr == 3 )
+    {
+        channel = val >> 6;
+        if ( channel == 3 )
+        {
+            /* Read-Back Command. */
+            for ( channel = 0; channel < 3; channel++ )
+            {
+                s = &pit->hw.channels[channel];
+                if ( val & (2 << channel) )
+                {
+                    if ( !(val & 0x20) )
+                        pit_latch_count(pit, channel);
+                    if ( !(val & 0x10) )
+                        pit_latch_status(pit, channel);
+                }
+            }
+        }
+        else
+        {
+            /* Select Counter <channel>. */
+            s = &pit->hw.channels[channel];
+            access = (val >> 4) & 3;
+            if ( access == 0 )
+            {
+                pit_latch_count(pit, channel);
+            }
+            else
+            {
+                s->rw_mode = access;
+                s->read_state = access;
+                s->write_state = access;
+                s->mode = (val >> 1) & 7;
+                if ( s->mode > 5 )
+                    s->mode -= 4;
+                s->bcd = val & 1;
+                /* XXX: update irq timer ? */
+            }
+        }
+    }
+    else
+    {
+        /* Write Count. */
+        s = &pit->hw.channels[addr];
+        switch ( s->write_state )
+        {
+        default:
+        case RW_STATE_LSB:
+            pit_load_count(pit, addr, val);
+            break;
+        case RW_STATE_MSB:
+            pit_load_count(pit, addr, val << 8);
+            break;
+        case RW_STATE_WORD0:
+            s->write_latch = val;
+            s->write_state = RW_STATE_WORD1;
+            break;
+        case RW_STATE_WORD1:
+            pit_load_count(pit, addr, s->write_latch | (val << 8));
+            s->write_state = RW_STATE_WORD0;
+            break;
+        }
+    }
+
+    spin_unlock(&pit->lock);
+}
+
+static uint32_t pit_ioport_read(struct PITState *pit, uint32_t addr)
+{
+    int ret, count;
+    struct hvm_hw_pit_channel *s;
+    
+    addr &= 3;
+    s = &pit->hw.channels[addr];
+
+    spin_lock(&pit->lock);
+
+    if ( s->status_latched )
+    {
+        s->status_latched = 0;
+        ret = s->status;
+    }
+    else if ( s->count_latched )
+    {
+        switch ( s->count_latched )
+        {
+        default:
+        case RW_STATE_LSB:
+            ret = s->latched_count & 0xff;
+            s->count_latched = 0;
+            break;
+        case RW_STATE_MSB:
+            ret = s->latched_count >> 8;
+            s->count_latched = 0;
+            break;
+        case RW_STATE_WORD0:
+            ret = s->latched_count & 0xff;
+            s->count_latched = RW_STATE_MSB;
+            break;
+        }
+    }
+    else
+    {
+        switch ( s->read_state )
+        {
+        default:
+        case RW_STATE_LSB:
+            count = pit_get_count(pit, addr);
+            ret = count & 0xff;
+            break;
+        case RW_STATE_MSB:
+            count = pit_get_count(pit, addr);
+            ret = (count >> 8) & 0xff;
+            break;
+        case RW_STATE_WORD0:
+            count = pit_get_count(pit, addr);
+            ret = count & 0xff;
+            s->read_state = RW_STATE_WORD1;
+            break;
+        case RW_STATE_WORD1:
+            count = pit_get_count(pit, addr);
+            ret = (count >> 8) & 0xff;
+            s->read_state = RW_STATE_WORD0;
+            break;
+        }
+    }
+
+    spin_unlock(&pit->lock);
+
+    return ret;
+}
+
+#ifdef CONFIG_HVM
+void pit_stop_channel0_irq(PITState *pit)
+{
+    if ( !has_vpit(current->domain) )
+        return;
+
+    TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
+    spin_lock(&pit->lock);
+    destroy_periodic_time(&pit->pt0);
+    spin_unlock(&pit->lock);
+}
+
+static int pit_save(struct domain *d, hvm_domain_context_t *h)
+{
+    PITState *pit = domain_vpit(d);
+    int rc;
+
+    if ( !has_vpit(d) )
+        return 0;
+
+    spin_lock(&pit->lock);
+    
+    rc = hvm_save_entry(PIT, 0, h, &pit->hw);
+
+    spin_unlock(&pit->lock);
+
+    return rc;
+}
+
+static int pit_load(struct domain *d, hvm_domain_context_t *h)
+{
+    PITState *pit = domain_vpit(d);
+    int i;
+
+    if ( !has_vpit(d) )
+        return -ENODEV;
+
+    spin_lock(&pit->lock);
+
+    if ( hvm_load_entry(PIT, h, &pit->hw) )
+    {
+        spin_unlock(&pit->lock);
+        return 1;
+    }
+    
+    /*
+     * Recreate platform timers from hardware state.  There will be some 
+     * time jitter here, but the wall-clock will have jumped massively, so 
+     * we hope the guest can handle it.
+     */
+    pit->pt0.last_plt_gtime = get_guest_time(d->vcpu[0]);
+    for ( i = 0; i < 3; i++ )
+        pit_load_count(pit, i, pit->hw.channels[i].count);
+
+    spin_unlock(&pit->lock);
+
+    return 0;
+}
+
+HVM_REGISTER_SAVE_RESTORE(PIT, pit_save, pit_load, 1, HVMSR_PER_DOM);
+#endif
+
+void pit_reset(struct domain *d)
+{
+    PITState *pit = domain_vpit(d);
+    struct hvm_hw_pit_channel *s;
+    int i;
+
+    if ( !has_vpit(d) )
+        return;
+
+    if ( is_hvm_domain(d) )
+    {
+        TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
+        destroy_periodic_time(&pit->pt0);
+        pit->pt0.source = PTSRC_isa;
+    }
+
+    spin_lock(&pit->lock);
+
+    for ( i = 0; i < 3; i++ )
+    {
+        s = &pit->hw.channels[i];
+        s->mode = 0xff; /* the init mode */
+        s->gate = (i != 2);
+        pit_load_count(pit, i, 0);
+    }
+
+    spin_unlock(&pit->lock);
+}
+
+void pit_init(struct domain *d, unsigned long cpu_khz)
+{
+    PITState *pit = domain_vpit(d);
+
+    if ( !has_vpit(d) )
+        return;
+
+    spin_lock_init(&pit->lock);
+
+    if ( is_hvm_domain(d) )
+    {
+        register_portio_handler(d, PIT_BASE, 4, handle_pit_io);
+        register_portio_handler(d, 0x61, 1, handle_speaker_io);
+    }
+
+    pit_reset(d);
+}
+
+void pit_deinit(struct domain *d)
+{
+    PITState *pit = domain_vpit(d);
+
+    if ( !has_vpit(d) )
+        return;
+
+    if ( is_hvm_domain(d) )
+    {
+        TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
+        destroy_periodic_time(&pit->pt0);
+    }
+}
+
+/* the intercept action for PIT DM retval:0--not handled; 1--handled */  
+static int handle_pit_io(
+    int dir, unsigned int port, unsigned int bytes, uint32_t *val)
+{
+    struct PITState *vpit = vcpu_vpit(current);
+
+    if ( bytes != 1 )
+    {
+        gdprintk(XENLOG_WARNING, "PIT bad access\n");
+        *val = ~0;
+        return X86EMUL_OKAY;
+    }
+
+    if ( dir == IOREQ_WRITE )
+    {
+        pit_ioport_write(vpit, port, *val);
+    }
+    else
+    {
+        if ( (port & 3) != 3 )
+            *val = pit_ioport_read(vpit, port);
+        else
+            gdprintk(XENLOG_WARNING, "PIT: read A1:A0=3!\n");
+    }
+
+    return X86EMUL_OKAY;
+}
+
+static void speaker_ioport_write(
+    struct PITState *pit, uint32_t addr, uint32_t val)
+{
+    pit->hw.speaker_data_on = (val >> 1) & 1;
+    pit_set_gate(pit, 2, val & 1);
+}
+
+static uint32_t speaker_ioport_read(
+    struct PITState *pit, uint32_t addr)
+{
+    /* Refresh clock toggles at about 15us. We approximate as 2^14ns. */
+    unsigned int refresh_clock = ((unsigned int)NOW() >> 14) & 1;
+    return ((pit->hw.speaker_data_on << 1) | pit_get_gate(pit, 2) |
+            (pit_get_out(pit, 2) << 5) | (refresh_clock << 4));
+}
+
+static int handle_speaker_io(
+    int dir, unsigned int port, uint32_t bytes, uint32_t *val)
+{
+    struct PITState *vpit = vcpu_vpit(current);
+
+    BUG_ON(bytes != 1);
+
+    spin_lock(&vpit->lock);
+
+    if ( dir == IOREQ_WRITE )
+        speaker_ioport_write(vpit, port, *val);
+    else
+        *val = speaker_ioport_read(vpit, port);
+
+    spin_unlock(&vpit->lock);
+
+    return X86EMUL_OKAY;
+}
+
+int pv_pit_handler(int port, int data, int write)
+{
+    ioreq_t ioreq = {
+        .size = 1,
+        .type = IOREQ_TYPE_PIO,
+        .addr = port,
+        .dir  = write ? IOREQ_WRITE : IOREQ_READ,
+        .data = data
+    };
+
+    if ( !has_vpit(current->domain) )
+        return ~0;
+
+    if ( is_hardware_domain(current->domain) && hwdom_pit_access(&ioreq) )
+    {
+        /* nothing to do */;
+    }
+    else
+    {
+        uint32_t val = data;
+        if ( port == 0x61 )
+            handle_speaker_io(ioreq.dir, port, 1, &val);
+        else
+            handle_pit_io(ioreq.dir, port, 1, &val);
+        ioreq.data = val;
+    }
+
+    return !write ? ioreq.data : 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 5bd38f6..5e04bc1 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -10,7 +10,6 @@ obj-y += grant_table.o
 obj-y += hpet.o
 obj-y += hvm.o
 obj-y += hypercall.o
-obj-y += i8254.o
 obj-y += intercept.o
 obj-y += io.o
 obj-y += ioreq.o
diff --git a/xen/arch/x86/hvm/i8254.c b/xen/arch/x86/hvm/i8254.c
deleted file mode 100644
index b8ec56f..0000000
--- a/xen/arch/x86/hvm/i8254.c
+++ /dev/null
@@ -1,597 +0,0 @@
-/*
- * QEMU 8253/8254 interval timer emulation
- * 
- * Copyright (c) 2003-2004 Fabrice Bellard
- * Copyright (c) 2006 Intel Corperation
- * Copyright (c) 2007 Keir Fraser, XenSource Inc.
- * 
- * 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 PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- */
-
-#include <xen/types.h>
-#include <xen/mm.h>
-#include <xen/xmalloc.h>
-#include <xen/lib.h>
-#include <xen/errno.h>
-#include <xen/sched.h>
-#include <xen/trace.h>
-#include <asm/time.h>
-#include <asm/hvm/hvm.h>
-#include <asm/hvm/io.h>
-#include <asm/hvm/support.h>
-#include <asm/hvm/vpt.h>
-#include <asm/current.h>
-
-#define domain_vpit(x) (&(x)->arch.vpit)
-#define vcpu_vpit(x)   (domain_vpit((x)->domain))
-#define vpit_domain(x) (container_of((x), struct domain, arch.vpit))
-#define vpit_vcpu(x)   (pt_global_vcpu_target(vpit_domain(x)))
-
-#define RW_STATE_LSB 1
-#define RW_STATE_MSB 2
-#define RW_STATE_WORD0 3
-#define RW_STATE_WORD1 4
-
-static int handle_pit_io(
-    int dir, unsigned int port, unsigned int bytes, uint32_t *val);
-static int handle_speaker_io(
-    int dir, unsigned int port, unsigned int bytes, uint32_t *val);
-
-#define get_guest_time(v) \
-   (is_hvm_vcpu(v) ? hvm_get_guest_time(v) : (u64)get_s_time())
-
-static int pit_get_count(PITState *pit, int channel)
-{
-    uint64_t d;
-    int  counter;
-    struct hvm_hw_pit_channel *c = &pit->hw.channels[channel];
-    struct vcpu *v = vpit_vcpu(pit);
-
-    ASSERT(spin_is_locked(&pit->lock));
-
-    d = muldiv64(get_guest_time(v) - pit->count_load_time[channel],
-                 PIT_FREQ, SYSTEM_TIME_HZ);
-
-    switch ( c->mode )
-    {
-    case 0:
-    case 1:
-    case 4:
-    case 5:
-        counter = (c->count - d) & 0xffff;
-        break;
-    case 3:
-        /* XXX: may be incorrect for odd counts */
-        counter = c->count - ((2 * d) % c->count);
-        break;
-    default:
-        counter = c->count - (d % c->count);
-        break;
-    }
-    return counter;
-}
-
-static int pit_get_out(PITState *pit, int channel)
-{
-    struct hvm_hw_pit_channel *s = &pit->hw.channels[channel];
-    uint64_t d;
-    int out;
-    struct vcpu *v = vpit_vcpu(pit);
-
-    ASSERT(spin_is_locked(&pit->lock));
-
-    d = muldiv64(get_guest_time(v) - pit->count_load_time[channel], 
-                 PIT_FREQ, SYSTEM_TIME_HZ);
-
-    switch ( s->mode )
-    {
-    default:
-    case 0:
-        out = (d >= s->count);
-        break;
-    case 1:
-        out = (d < s->count);
-        break;
-    case 2:
-        out = (((d % s->count) == 0) && (d != 0));
-        break;
-    case 3:
-        out = ((d % s->count) < ((s->count + 1) >> 1));
-        break;
-    case 4:
-    case 5:
-        out = (d == s->count);
-        break;
-    }
-
-    return out;
-}
-
-static void pit_set_gate(PITState *pit, int channel, int val)
-{
-    struct hvm_hw_pit_channel *s = &pit->hw.channels[channel];
-    struct vcpu *v = vpit_vcpu(pit);
-
-    ASSERT(spin_is_locked(&pit->lock));
-
-    switch ( s->mode )
-    {
-    default:
-    case 0:
-    case 4:
-        /* XXX: just disable/enable counting */
-        break;
-    case 1:
-    case 5:
-    case 2:
-    case 3:
-        /* Restart counting on rising edge. */
-        if ( s->gate < val )
-            pit->count_load_time[channel] = get_guest_time(v);
-        break;
-    }
-
-    s->gate = val;
-}
-
-static int pit_get_gate(PITState *pit, int channel)
-{
-    ASSERT(spin_is_locked(&pit->lock));
-    return pit->hw.channels[channel].gate;
-}
-
-static void pit_time_fired(struct vcpu *v, void *priv)
-{
-    uint64_t *count_load_time = priv;
-    TRACE_0D(TRC_HVM_EMUL_PIT_TIMER_CB);
-    *count_load_time = get_guest_time(v);
-}
-
-static void pit_load_count(PITState *pit, int channel, int val)
-{
-    u32 period;
-    struct hvm_hw_pit_channel *s = &pit->hw.channels[channel];
-    struct vcpu *v = vpit_vcpu(pit);
-
-    ASSERT(spin_is_locked(&pit->lock));
-
-    if ( val == 0 )
-        val = 0x10000;
-
-    if ( v == NULL )
-        pit->count_load_time[channel] = 0;
-    else
-        pit->count_load_time[channel] = get_guest_time(v);
-    s->count = val;
-    period = DIV_ROUND(val * SYSTEM_TIME_HZ, PIT_FREQ);
-
-    if ( (v == NULL) || !is_hvm_vcpu(v) || (channel != 0) )
-        return;
-
-    switch ( s->mode )
-    {
-    case 2:
-    case 3:
-        /* Periodic timer. */
-        TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, period);
-        create_periodic_time(v, &pit->pt0, period, period, 0, pit_time_fired, 
-                             &pit->count_load_time[channel], false);
-        break;
-    case 1:
-    case 4:
-        /* One-shot timer. */
-        TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, 0);
-        create_periodic_time(v, &pit->pt0, period, 0, 0, pit_time_fired,
-                             &pit->count_load_time[channel], false);
-        break;
-    default:
-        TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
-        destroy_periodic_time(&pit->pt0);
-        break;
-    }
-}
-
-static void pit_latch_count(PITState *pit, int channel)
-{
-    struct hvm_hw_pit_channel *c = &pit->hw.channels[channel];
-
-    ASSERT(spin_is_locked(&pit->lock));
-
-    if ( !c->count_latched )
-    {
-        c->latched_count = pit_get_count(pit, channel);
-        c->count_latched = c->rw_mode;
-    }
-}
-
-static void pit_latch_status(PITState *pit, int channel)
-{
-    struct hvm_hw_pit_channel *c = &pit->hw.channels[channel];
-
-    ASSERT(spin_is_locked(&pit->lock));
-
-    if ( !c->status_latched )
-    {
-        /* TODO: Return NULL COUNT (bit 6). */
-        c->status = ((pit_get_out(pit, channel) << 7) |
-                     (c->rw_mode << 4) |
-                     (c->mode << 1) |
-                     c->bcd);
-        c->status_latched = 1;
-    }
-}
-
-static void pit_ioport_write(struct PITState *pit, uint32_t addr, uint32_t val)
-{
-    int channel, access;
-    struct hvm_hw_pit_channel *s;
-
-    val  &= 0xff;
-    addr &= 3;
-
-    spin_lock(&pit->lock);
-
-    if ( addr == 3 )
-    {
-        channel = val >> 6;
-        if ( channel == 3 )
-        {
-            /* Read-Back Command. */
-            for ( channel = 0; channel < 3; channel++ )
-            {
-                s = &pit->hw.channels[channel];
-                if ( val & (2 << channel) )
-                {
-                    if ( !(val & 0x20) )
-                        pit_latch_count(pit, channel);
-                    if ( !(val & 0x10) )
-                        pit_latch_status(pit, channel);
-                }
-            }
-        }
-        else
-        {
-            /* Select Counter <channel>. */
-            s = &pit->hw.channels[channel];
-            access = (val >> 4) & 3;
-            if ( access == 0 )
-            {
-                pit_latch_count(pit, channel);
-            }
-            else
-            {
-                s->rw_mode = access;
-                s->read_state = access;
-                s->write_state = access;
-                s->mode = (val >> 1) & 7;
-                if ( s->mode > 5 )
-                    s->mode -= 4;
-                s->bcd = val & 1;
-                /* XXX: update irq timer ? */
-            }
-        }
-    }
-    else
-    {
-        /* Write Count. */
-        s = &pit->hw.channels[addr];
-        switch ( s->write_state )
-        {
-        default:
-        case RW_STATE_LSB:
-            pit_load_count(pit, addr, val);
-            break;
-        case RW_STATE_MSB:
-            pit_load_count(pit, addr, val << 8);
-            break;
-        case RW_STATE_WORD0:
-            s->write_latch = val;
-            s->write_state = RW_STATE_WORD1;
-            break;
-        case RW_STATE_WORD1:
-            pit_load_count(pit, addr, s->write_latch | (val << 8));
-            s->write_state = RW_STATE_WORD0;
-            break;
-        }
-    }
-
-    spin_unlock(&pit->lock);
-}
-
-static uint32_t pit_ioport_read(struct PITState *pit, uint32_t addr)
-{
-    int ret, count;
-    struct hvm_hw_pit_channel *s;
-    
-    addr &= 3;
-    s = &pit->hw.channels[addr];
-
-    spin_lock(&pit->lock);
-
-    if ( s->status_latched )
-    {
-        s->status_latched = 0;
-        ret = s->status;
-    }
-    else if ( s->count_latched )
-    {
-        switch ( s->count_latched )
-        {
-        default:
-        case RW_STATE_LSB:
-            ret = s->latched_count & 0xff;
-            s->count_latched = 0;
-            break;
-        case RW_STATE_MSB:
-            ret = s->latched_count >> 8;
-            s->count_latched = 0;
-            break;
-        case RW_STATE_WORD0:
-            ret = s->latched_count & 0xff;
-            s->count_latched = RW_STATE_MSB;
-            break;
-        }
-    }
-    else
-    {
-        switch ( s->read_state )
-        {
-        default:
-        case RW_STATE_LSB:
-            count = pit_get_count(pit, addr);
-            ret = count & 0xff;
-            break;
-        case RW_STATE_MSB:
-            count = pit_get_count(pit, addr);
-            ret = (count >> 8) & 0xff;
-            break;
-        case RW_STATE_WORD0:
-            count = pit_get_count(pit, addr);
-            ret = count & 0xff;
-            s->read_state = RW_STATE_WORD1;
-            break;
-        case RW_STATE_WORD1:
-            count = pit_get_count(pit, addr);
-            ret = (count >> 8) & 0xff;
-            s->read_state = RW_STATE_WORD0;
-            break;
-        }
-    }
-
-    spin_unlock(&pit->lock);
-
-    return ret;
-}
-
-void pit_stop_channel0_irq(PITState *pit)
-{
-    if ( !has_vpit(current->domain) )
-        return;
-
-    TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
-    spin_lock(&pit->lock);
-    destroy_periodic_time(&pit->pt0);
-    spin_unlock(&pit->lock);
-}
-
-static int pit_save(struct domain *d, hvm_domain_context_t *h)
-{
-    PITState *pit = domain_vpit(d);
-    int rc;
-
-    if ( !has_vpit(d) )
-        return 0;
-
-    spin_lock(&pit->lock);
-    
-    rc = hvm_save_entry(PIT, 0, h, &pit->hw);
-
-    spin_unlock(&pit->lock);
-
-    return rc;
-}
-
-static int pit_load(struct domain *d, hvm_domain_context_t *h)
-{
-    PITState *pit = domain_vpit(d);
-    int i;
-
-    if ( !has_vpit(d) )
-        return -ENODEV;
-
-    spin_lock(&pit->lock);
-
-    if ( hvm_load_entry(PIT, h, &pit->hw) )
-    {
-        spin_unlock(&pit->lock);
-        return 1;
-    }
-    
-    /*
-     * Recreate platform timers from hardware state.  There will be some 
-     * time jitter here, but the wall-clock will have jumped massively, so 
-     * we hope the guest can handle it.
-     */
-    pit->pt0.last_plt_gtime = get_guest_time(d->vcpu[0]);
-    for ( i = 0; i < 3; i++ )
-        pit_load_count(pit, i, pit->hw.channels[i].count);
-
-    spin_unlock(&pit->lock);
-
-    return 0;
-}
-
-HVM_REGISTER_SAVE_RESTORE(PIT, pit_save, pit_load, 1, HVMSR_PER_DOM);
-
-void pit_reset(struct domain *d)
-{
-    PITState *pit = domain_vpit(d);
-    struct hvm_hw_pit_channel *s;
-    int i;
-
-    if ( !has_vpit(d) )
-        return;
-
-    TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
-    destroy_periodic_time(&pit->pt0);
-    pit->pt0.source = PTSRC_isa;
-
-    spin_lock(&pit->lock);
-
-    for ( i = 0; i < 3; i++ )
-    {
-        s = &pit->hw.channels[i];
-        s->mode = 0xff; /* the init mode */
-        s->gate = (i != 2);
-        pit_load_count(pit, i, 0);
-    }
-
-    spin_unlock(&pit->lock);
-}
-
-void pit_init(struct domain *d, unsigned long cpu_khz)
-{
-    PITState *pit = domain_vpit(d);
-
-    if ( !has_vpit(d) )
-        return;
-
-    spin_lock_init(&pit->lock);
-
-    if ( is_hvm_domain(d) )
-    {
-        register_portio_handler(d, PIT_BASE, 4, handle_pit_io);
-        register_portio_handler(d, 0x61, 1, handle_speaker_io);
-    }
-
-    pit_reset(d);
-}
-
-void pit_deinit(struct domain *d)
-{
-    PITState *pit = domain_vpit(d);
-
-    if ( !has_vpit(d) )
-        return;
-
-    TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
-    destroy_periodic_time(&pit->pt0);
-}
-
-/* the intercept action for PIT DM retval:0--not handled; 1--handled */  
-static int handle_pit_io(
-    int dir, unsigned int port, unsigned int bytes, uint32_t *val)
-{
-    struct PITState *vpit = vcpu_vpit(current);
-
-    if ( bytes != 1 )
-    {
-        gdprintk(XENLOG_WARNING, "PIT bad access\n");
-        *val = ~0;
-        return X86EMUL_OKAY;
-    }
-
-    if ( dir == IOREQ_WRITE )
-    {
-        pit_ioport_write(vpit, port, *val);
-    }
-    else
-    {
-        if ( (port & 3) != 3 )
-            *val = pit_ioport_read(vpit, port);
-        else
-            gdprintk(XENLOG_WARNING, "PIT: read A1:A0=3!\n");
-    }
-
-    return X86EMUL_OKAY;
-}
-
-static void speaker_ioport_write(
-    struct PITState *pit, uint32_t addr, uint32_t val)
-{
-    pit->hw.speaker_data_on = (val >> 1) & 1;
-    pit_set_gate(pit, 2, val & 1);
-}
-
-static uint32_t speaker_ioport_read(
-    struct PITState *pit, uint32_t addr)
-{
-    /* Refresh clock toggles at about 15us. We approximate as 2^14ns. */
-    unsigned int refresh_clock = ((unsigned int)NOW() >> 14) & 1;
-    return ((pit->hw.speaker_data_on << 1) | pit_get_gate(pit, 2) |
-            (pit_get_out(pit, 2) << 5) | (refresh_clock << 4));
-}
-
-static int handle_speaker_io(
-    int dir, unsigned int port, uint32_t bytes, uint32_t *val)
-{
-    struct PITState *vpit = vcpu_vpit(current);
-
-    BUG_ON(bytes != 1);
-
-    spin_lock(&vpit->lock);
-
-    if ( dir == IOREQ_WRITE )
-        speaker_ioport_write(vpit, port, *val);
-    else
-        *val = speaker_ioport_read(vpit, port);
-
-    spin_unlock(&vpit->lock);
-
-    return X86EMUL_OKAY;
-}
-
-int pv_pit_handler(int port, int data, int write)
-{
-    ioreq_t ioreq = {
-        .size = 1,
-        .type = IOREQ_TYPE_PIO,
-        .addr = port,
-        .dir  = write ? IOREQ_WRITE : IOREQ_READ,
-        .data = data
-    };
-
-    if ( !has_vpit(current->domain) )
-        return ~0;
-
-    if ( is_hardware_domain(current->domain) && hwdom_pit_access(&ioreq) )
-    {
-        /* nothing to do */;
-    }
-    else
-    {
-        uint32_t val = data;
-        if ( port == 0x61 )
-            handle_speaker_io(ioreq.dir, port, 1, &val);
-        else
-            handle_pit_io(ioreq.dir, port, 1, &val);
-        ioreq.data = val;
-    }
-
-    return !write ? ioreq.data : 0;
-}
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV}
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (18 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-28 11:07   ` Julien Grall
  2018-08-28 11:47   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 21/23] x86: expose CONFIG_HVM Wei Liu
                   ` (2 subsequent siblings)
  22 siblings, 2 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Jan Beulich

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/common/domain.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 171d25e..73b5485 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -318,9 +318,23 @@ struct domain *domain_create(domid_t domid,
     if ( !is_idle_domain(d) )
     {
         if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
+        {
+#ifdef CONFIG_HVM
             d->guest_type = guest_type_hvm;
+#else
+            err = -EINVAL;
+            goto fail;
+#endif
+        }
         else
+        {
+#ifdef CONFIG_PV
             d->guest_type = guest_type_pv;
+#else
+            err = -EINVAL;
+            goto fail;
+#endif
+        }
 
         watchdog_domain_init(d);
         init_status |= INIT_watchdog;
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 21/23] x86: expose CONFIG_HVM
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (19 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV} Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-28 11:50   ` Jan Beulich
  2018-08-26 12:19 ` [PATCH v2 22/23] x86/pvshim: disable HVM for PV shim Wei Liu
  2018-08-26 12:19 ` [PATCH v2 23/23] xen: decouple HVM and IOMMU capabilities Wei Liu
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
v2: use tab to indent

Haven't added a dependency on PV_SHIM_EXCLUSIVE because agreement is
not yet reached.
---
 xen/arch/x86/Kconfig | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 73ab8f8..11637e1 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -60,6 +60,12 @@ config PV_LINEAR_PT
 
 config HVM
 	def_bool y
+	prompt "HVM / PVH support"
+	---help---
+	  Interfaces to support HVM and PVH guests.
+
+	  If unsure, say Y.
+
 
 config SHADOW_PAGING
         bool "Shadow Paging"
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 22/23] x86/pvshim: disable HVM for PV shim
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (20 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 21/23] x86: expose CONFIG_HVM Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-26 12:19 ` [PATCH v2 23/23] xen: decouple HVM and IOMMU capabilities Wei Liu
  22 siblings, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel; +Cc: Ian Jackson, Wei Liu

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
---
 tools/firmware/xen-dir/shim.config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware/xen-dir/shim.config b/tools/firmware/xen-dir/shim.config
index 21d7075..de53dfe 100644
--- a/tools/firmware/xen-dir/shim.config
+++ b/tools/firmware/xen-dir/shim.config
@@ -12,7 +12,7 @@ CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
 CONFIG_NR_CPUS=32
 CONFIG_PV=y
 CONFIG_PV_LINEAR_PT=y
-CONFIG_HVM=y
+# CONFIG_HVM is not set
 # CONFIG_SHADOW_PAGING is not set
 # CONFIG_BIGMEM is not set
 # CONFIG_HVM_FEP is not set
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* [PATCH v2 23/23] xen: decouple HVM and IOMMU capabilities
  2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
                   ` (21 preceding siblings ...)
  2018-08-26 12:19 ` [PATCH v2 22/23] x86/pvshim: disable HVM for PV shim Wei Liu
@ 2018-08-26 12:19 ` Wei Liu
  2018-08-28 11:56   ` Jan Beulich
  22 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-26 12:19 UTC (permalink / raw)
  To: xen-devel
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, Jan Beulich

HVM and IOMMU are two distinct hardware features, yet they were
bundled together in sysctl and xl's output.

Decouple them on sysctl level. On toolstack level we still need to
maintain a sensible semantics for `xl info`. Massage the information
according to the following table:

pv      hvm     iommu           flags in xl info
0       0       0               n/a
0       0       1               n/a
0       1       0               hvm
0       1       1               hvm hvm_directio
1       0       0               NIL
1       0       1               directio
1       1       0               hvm
1       1       1               hvm hvm_directio directio

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxl/libxl.c         | 5 +++--
 tools/libxl/libxl.h         | 6 ++++++
 tools/libxl/libxl_types.idl | 1 +
 tools/xl/xl_info.c          | 5 +++--
 xen/arch/x86/sysctl.c       | 2 +-
 xen/include/public/sysctl.h | 8 ++++----
 6 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b41ade9..a0d9f2b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -396,8 +396,9 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
 
     physinfo->cap_hvm = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm);
-    physinfo->cap_hvm_directio =
-        !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hvm_directio);
+    physinfo->cap_directio =
+        !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_directio);
+    physinfo->cap_hvm_directio = physinfo->cap_hvm && physinfo->cap_directio;
 
     GC_FREE;
     return 0;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index ae2d63d..2cfc1b0 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -67,6 +67,12 @@
  * the same $(XEN_VERSION) (e.g. throughout a major release).
  */
 
+/* LIBXL_HAVE_PHYSINFO_CAP_DIRECTIO
+ *
+ * If this is defined, libxl_physinfo has a "cap_directio" field.
+ */
+#define LIBXL_HAVE_PHYSINFO_CAP_DIRECTIO 1
+
 /* LIBXL_HAVE_CONSOLE_NOTIFY_FD
  *
  * If this is defined, libxl_console_exec and
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 4a38580..2cceb8c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -1014,6 +1014,7 @@ libxl_physinfo = Struct("physinfo", [
 
     ("cap_hvm", bool),
     ("cap_hvm_directio", bool),
+    ("cap_directio", bool),
     ], dir=DIR_OUT)
 
 libxl_connectorinfo = Struct("connectorinfo", [
diff --git a/tools/xl/xl_info.c b/tools/xl/xl_info.c
index 6c8be26..93e2c5f 100644
--- a/tools/xl/xl_info.c
+++ b/tools/xl/xl_info.c
@@ -210,9 +210,10 @@ static void output_physinfo(void)
          info.hw_cap[4], info.hw_cap[5], info.hw_cap[6], info.hw_cap[7]
         );
 
-    maybe_printf("virt_caps              :%s%s\n",
+    maybe_printf("virt_caps              :%s%s%s\n",
          info.cap_hvm ? " hvm" : "",
-         info.cap_hvm_directio ? " hvm_directio" : ""
+         info.cap_hvm_directio ? " hvm_directio" : "",
+         info.cap_directio ? " directio" : ""
         );
 
     vinfo = libxl_get_version_info(ctx);
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index e704ed7..456dc58 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -93,7 +93,7 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
     if ( hvm_enabled )
         pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
     if ( iommu_enabled )
-        pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
+        pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
 }
 
 long arch_do_sysctl(
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 839c1b9..8cd0a9c 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -36,7 +36,7 @@
 #include "physdev.h"
 #include "tmem.h"
 
-#define XEN_SYSCTL_INTERFACE_VERSION 0x00000011
+#define XEN_SYSCTL_INTERFACE_VERSION 0x00000012
 
 /*
  * Read console content from Xen buffer ring.
@@ -85,9 +85,9 @@ struct xen_sysctl_tbuf_op {
  /* (x86) The platform supports HVM guests. */
 #define _XEN_SYSCTL_PHYSCAP_hvm          0
 #define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
- /* (x86) The platform supports HVM-guest direct access to I/O devices. */
-#define _XEN_SYSCTL_PHYSCAP_hvm_directio 1
-#define XEN_SYSCTL_PHYSCAP_hvm_directio  (1u<<_XEN_SYSCTL_PHYSCAP_hvm_directio)
+ /* (x86) The platform supports direct access to I/O devices with IOMMU. */
+#define _XEN_SYSCTL_PHYSCAP_directio 1
+#define XEN_SYSCTL_PHYSCAP_directio  (1u<<_XEN_SYSCTL_PHYSCAP_directio)
 struct xen_sysctl_physinfo {
     uint32_t threads_per_core;
     uint32_t cores_per_socket;
-- 
git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 12/23] x86: monitor.o is currently HVM only
  2018-08-26 12:19 ` [PATCH v2 12/23] x86: monitor.o is currently " Wei Liu
@ 2018-08-26 16:33   ` Razvan Cojocaru
  2018-08-27 15:18   ` Jan Beulich
  1 sibling, 0 replies; 97+ messages in thread
From: Razvan Cojocaru @ 2018-08-26 16:33 UTC (permalink / raw)
  To: Wei Liu, xen-devel; +Cc: Andrew Cooper, Tamas K Lengyel, Jan Beulich

On 8/26/18 3:19 PM, Wei Liu wrote:
> There has been plan to make PV work, but it is not yet there.  Provide
> stubs to make it build with !CONFIG_HVM.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/arch/x86/Makefile         |  2 +-
>  xen/include/asm-x86/monitor.h | 14 ++++++++++++++
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 9b9b63a..43f9189 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -45,7 +45,7 @@ obj-y += microcode_amd.o
>  obj-y += microcode_intel.o
>  obj-y += microcode.o
>  obj-y += mm.o x86_64/mm.o
> -obj-y += monitor.o
> +obj-$(CONFIG_HVM) += monitor.o
>  obj-y += mpparse.o
>  obj-y += nmi.o
>  obj-y += numa.o
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index 4988903..09f7f8a 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -99,10 +99,24 @@ static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
>  int arch_monitor_domctl_event(struct domain *d,
>                                struct xen_domctl_monitor_op *mop);
>  
> +#ifdef CONFIG_HVM
> +
>  int arch_monitor_init_domain(struct domain *d);
>  
>  void arch_monitor_cleanup_domain(struct domain *d);
>  
> +#else
> +
> +static inline int arch_monitor_init_domain(struct domain *d)
> +{
> +    return 0;

Right, if vm_event is not supported for anything other than HVM then we
should return -ENOENT or a similar error here. That way, at least the
user knows things will not work upfront (when trying to enable vm_event).

> +}
> +
> +static inline void arch_monitor_cleanup_domain(struct domain *d)
> +{}

I'm not sure if this is valid coding style (as opposed to having a
newline before '}'.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 15/23] x86/mm: put HVM only code under CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 15/23] x86/mm: put HVM only " Wei Liu
@ 2018-08-26 16:39   ` Razvan Cojocaru
  2018-08-27  9:03   ` Wei Liu
  2018-08-27 16:01   ` Jan Beulich
  2 siblings, 0 replies; 97+ messages in thread
From: Razvan Cojocaru @ 2018-08-26 16:39 UTC (permalink / raw)
  To: Wei Liu, xen-devel
  Cc: George Dunlap, Andrew Cooper, Tamas K Lengyel, Jan Beulich

On 8/26/18 3:19 PM, Wei Liu wrote:
> Going through the code, HAP, EPT, PoD and ALTP2M depend on HVM code.
> Put these components under CONFIG_HVM. This further requires putting
> one of the vm event under CONFIG_HVM.
> 
> Also make hap_enabled evaluate to false when !CONFIG_HVM. This in turn
> requires marking a variable in p2m_set_entry as __maybe_unused.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 15/23] x86/mm: put HVM only code under CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 15/23] x86/mm: put HVM only " Wei Liu
  2018-08-26 16:39   ` Razvan Cojocaru
@ 2018-08-27  9:03   ` Wei Liu
  2018-08-28 10:41     ` Wei Liu
  2018-08-27 16:01   ` Jan Beulich
  2 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-27  9:03 UTC (permalink / raw)
  To: xen-devel
  Cc: Tamas K Lengyel, Wei Liu, Razvan Cojocaru, George Dunlap,
	Andrew Cooper, Jan Beulich

On Sun, Aug 26, 2018 at 01:19:48PM +0100, Wei Liu wrote:
> Going through the code, HAP, EPT, PoD and ALTP2M depend on HVM code.
> Put these components under CONFIG_HVM. This further requires putting
> one of the vm event under CONFIG_HVM.
> 
> Also make hap_enabled evaluate to false when !CONFIG_HVM. This in turn
> requires marking a variable in p2m_set_entry as __maybe_unused.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/arch/x86/mm/Makefile         |  7 ++++---
>  xen/arch/x86/mm/p2m.c            | 17 ++++++++++-------
>  xen/common/vm_event.c            |  2 ++
>  xen/include/asm-x86/hvm/domain.h |  4 ++++
>  4 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
> index 3017119..e3b7be8 100644
> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -1,9 +1,10 @@
>  subdir-y += shadow
> -subdir-y += hap
> +subdir-$(CONFIG_HVM) += hap
>  
>  obj-y += paging.o
> -obj-y += p2m.o p2m-pt.o p2m-ept.o p2m-pod.o
> -obj-y += altp2m.o
> +obj-y += p2m.o p2m-pt.o
> +obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
> +obj-$(CONFIG_HVM) += altp2m.o
>  obj-y += guest_walk_2.o
>  obj-y += guest_walk_3.o
>  obj-y += guest_walk_4.o
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index c82db32..e41d6bf 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -535,7 +535,7 @@ struct page_info *p2m_get_page_from_gfn(
>  int p2m_set_entry(struct p2m_domain *p2m, gfn_t gfn, mfn_t mfn,
>                    unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
>  {
> -    struct domain *d = p2m->domain;
> +    struct domain * __maybe_unused d = p2m->domain;
>      unsigned long todo = 1ul << page_order;
>      unsigned int order;
>      int set_rc, rc = 0;
> @@ -1712,12 +1712,6 @@ void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
>      }
>  }
>  
> -void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
> -{
> -    if ( altp2m_active(v->domain) )
> -        p2m_switch_vcpu_altp2m_by_id(v, idx);
> -}
> -
>  #ifdef CONFIG_HVM
>  static struct p2m_domain *
>  p2m_getlru_nestedp2m(struct domain *d, struct p2m_domain *p2m)
> @@ -2165,6 +2159,14 @@ int unmap_mmio_regions(struct domain *d,
>      return i == nr ? 0 : i ?: ret;
>  }
>  
> +#ifdef CONFIG_HVM
> +
> +void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
> +{
> +    if ( altp2m_active(v->domain) )
> +        p2m_switch_vcpu_altp2m_by_id(v, idx);
> +}
> +
>  bool_t p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsigned int idx)
>  {
>      struct domain *d = v->domain;
> @@ -2542,6 +2544,7 @@ int p2m_altp2m_propagate_change(struct domain *d, gfn_t gfn,
>  
>      return ret;
>  }
> +#endif /* CONFIG_HVM */
>  
>  /*** Audit ***/
>  
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 144ab81..4d06c8f 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -429,9 +429,11 @@ void vm_event_resume(struct domain *d, struct vm_event_domain *ved)
>               */
>              vm_event_toggle_singlestep(d, v, &rsp);
>  
> +#ifdef CONFIG_HVM
>              /* Check for altp2m switch */
>              if ( rsp.flags & VM_EVENT_FLAG_ALTERNATE_P2M )
>                  p2m_altp2m_check(v, rsp.altp2m_idx);
> +#endif
>  
>              if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
>                  vm_event_set_registers(v, &rsp);
> diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
> index 5885950..4517f89 100644
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -202,7 +202,11 @@ struct hvm_domain {
>      };
>  };
>  
> +#ifdef CONFIG_HVM
>  #define hap_enabled(d)  ((d)->arch.hvm_domain.hap_enabled)
> +#else
> +#define hap_enabled(d)  false
> +#endif

Hmm... I thought I had rewritten this to be a static inline function.

I will try to make it a static inline function.

Wei.

>  
>  #endif /* __ASM_X86_HVM_DOMAIN_H__ */
>  
> -- 
> git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 01/23] x86: change name of parameter for various invlpg functions
  2018-08-26 12:19 ` [PATCH v2 01/23] x86: change name of parameter for various invlpg functions Wei Liu
@ 2018-08-27 13:49   ` Boris Ostrovsky
  2018-08-27 13:54     ` Jan Beulich
  2018-08-27 14:20   ` Jan Beulich
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 97+ messages in thread
From: Boris Ostrovsky @ 2018-08-27 13:49 UTC (permalink / raw)
  To: Wei Liu, xen-devel
  Cc: Kevin Tian, Jan Beulich, George Dunlap, Andrew Cooper,
	Tim Deegan, Jun Nakajima, Brian Woods, Suravee Suthikulpanit

On 08/26/2018 08:19 AM, Wei Liu wrote:
> They all incorrectly named a parameter virtual address while it should
> have been linear address.
>
> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>

AMD SDM doesn't make distinction between linear and virtual addresses so
I wonder why this was requested.


-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 01/23] x86: change name of parameter for various invlpg functions
  2018-08-27 13:49   ` Boris Ostrovsky
@ 2018-08-27 13:54     ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 13:54 UTC (permalink / raw)
  To: Boris Ostrovsky
  Cc: Kevin Tian, Wei Liu, Jun Nakajima, George Dunlap, Andrew Cooper,
	Tim Deegan, Suravee Suthikulpanit, xen-devel, Brian Woods

>>> On 27.08.18 at 15:49, <boris.ostrovsky@oracle.com> wrote:
> On 08/26/2018 08:19 AM, Wei Liu wrote:
>> They all incorrectly named a parameter virtual address while it should
>> have been linear address.
>>
>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> AMD SDM doesn't make distinction between linear and virtual addresses so
> I wonder why this was requested.

Because it is incorrect to consider them the same: A virtual address is
a segment:offset pair, while a linear address is a plain number (typically
but not always resulting from adding segment base and offset).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 01/23] x86: change name of parameter for various invlpg functions
  2018-08-26 12:19 ` [PATCH v2 01/23] x86: change name of parameter for various invlpg functions Wei Liu
  2018-08-27 13:49   ` Boris Ostrovsky
@ 2018-08-27 14:20   ` Jan Beulich
  2018-08-30  1:26   ` Tian, Kevin
  2018-09-03 13:46   ` Wei Liu
  3 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 14:20 UTC (permalink / raw)
  To: Wei Liu
  Cc: Kevin Tian, Suravee Suthikulpanit, George Dunlap, Andrew Cooper,
	Tim Deegan, Jun Nakajima, xen-devel, Boris Ostrovsky,
	Brian Woods

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> They all incorrectly named a parameter virtual address while it should
> have been linear address.
> 
> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 02/23] xen: is_hvm_{domain, vcpu} should evaluate to false when !CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 02/23] xen: is_hvm_{domain, vcpu} should evaluate to false when !CONFIG_HVM Wei Liu
@ 2018-08-27 14:24   ` Jan Beulich
  2018-08-28  8:41     ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 14:24 UTC (permalink / raw)
  To: Wei Liu
  Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
	Tim Deegan, Julien Grall, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> Turn them into static inline functions which evaluate to false when
> CONFIG_HVM is not set. ARM won't be broken because ARM guests are set
> to PV type in the hypervisor.
> 
> But ARM has plan to switch to HVM guest type inside the hypervisor, so
> preemptively introduce CONFIG_HVM for ARM here.

But is setting this to Y then correct at this point?

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -879,8 +879,17 @@ void watchdog_domain_destroy(struct domain *d);
>  
>  #define is_pv_domain(d) ((d)->guest_type == guest_type_pv)
>  #define is_pv_vcpu(v)   (is_pv_domain((v)->domain))
> -#define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm)
> -#define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
> +
> +static inline bool is_hvm_domain(const struct domain *d)
> +{
> +    return IS_ENABLED(CONFIG_HVM) ? d->guest_type == guest_type_hvm : false;

Ultimately I think the guest_type_{hvm,pv} enumerators should only
be enabled when CONFIG_{HVM,PV}, so I think #ifdef CONFIG_HVM
would be the better choice here. But of course we can do this further
conversion at a later point, so
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 03/23] x86: enclose hvm_op and dm_op in CONFIG_HVM in relevant tables
  2018-08-26 12:19 ` [PATCH v2 03/23] x86: enclose hvm_op and dm_op in CONFIG_HVM in relevant tables Wei Liu
@ 2018-08-27 14:24   ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 14:24 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> PV guest (Dom0) needs to able to use these two hypercalls in order to
> serve HVM guests. But if xen doesn't support HVM at all there is no
> point in exposing them to PV guests.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 04/23] x86/hvm: provide hvm_hap_supported
  2018-08-26 12:19 ` [PATCH v2 04/23] x86/hvm: provide hvm_hap_supported Wei Liu
@ 2018-08-27 14:25   ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 14:25 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> And replace direct accesses in non-HVM subsystems to
> hvm_funcs.hap_supported with the new function, to avoid accessing an
> internal data structure of another subsystem directly.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 05/23] x86: provide stub for memory_type_changed
  2018-08-26 12:19 ` [PATCH v2 05/23] x86: provide stub for memory_type_changed Wei Liu
@ 2018-08-27 14:28   ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 14:28 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> Jan indicated that for PV guests the memory type is not changed, for
> HVM guests memory_type_changed is needed for EPT's effective memory
> type calculation.  This means memory_type_changed is HVM only.
> 
> Provide a stub to minimise code churn.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI
  2018-08-26 12:19 ` [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI Wei Liu
@ 2018-08-27 14:29   ` Jan Beulich
  2018-08-28  8:45     ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 14:29 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -557,6 +557,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  
>          ret = pci_mmcfg_reserved(info.address, info.segment,
>                                   info.start_bus, info.end_bus, info.flags);
> +#ifdef CONFIG_HAS_VPCI
>          if ( !ret && has_vpci(currd) )
>          {
>              /*
> @@ -567,6 +568,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>                                                info.start_bus, info.end_bus,
>                                                info.segment);
>          }
> +#endif

Perhaps better to make has_vpci() evaluate to false in that case,
and once again rely on DCE?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 07/23] x86/vpmu: put HVM only code under CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 07/23] x86/vpmu: put HVM only code under CONFIG_HVM Wei Liu
@ 2018-08-27 15:03   ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 15:03 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> Change u32 to uint32_t while at it.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 08/23] xen/pt: io.c contains HVM only code
  2018-08-26 12:19 ` [PATCH v2 08/23] xen/pt: io.c contains HVM only code Wei Liu
@ 2018-08-27 15:04   ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 15:04 UTC (permalink / raw)
  To: Wei Liu; +Cc: xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> We also need to make it x86 only because ARM also defines CONFIG_HVM.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 09/23] x86/pt: make it build with !CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 09/23] x86/pt: make it build with !CONFIG_HVM Wei Liu
@ 2018-08-27 15:07   ` Jan Beulich
  2018-08-30  1:29   ` Tian, Kevin
  1 sibling, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 15:07 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, Kevin Tian, Paul Durrant, Jun Nakajima, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> This requires providing stubs for a few functions which are part of
> HVM code.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 11/23] x86: XENMEM_resource_ioreq_server is HVM only
  2018-08-26 12:19 ` [PATCH v2 11/23] x86: XENMEM_resource_ioreq_server is HVM only Wei Liu
@ 2018-08-27 15:13   ` Jan Beulich
  2018-08-29 16:28     ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 15:13 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4376,12 +4376,17 @@ int arch_acquire_resource(struct domain *d, unsigned int type,
>  
>      switch ( type )
>      {
> +#ifdef CONFIG_HVM
>      case XENMEM_resource_ioreq_server:
>      {
>          ioservid_t ioservid = id;
>          unsigned int i;
>  
>          rc = -EINVAL;
> +        if ( !is_hvm_domain(d) )
> +            break;
> +
> +        rc = -EINVAL;
>          if ( id != (unsigned int)ioservid )
>              break;

Since this is the only caller of hvm_get_ioreq_server_frame(),
adding an is_hvm_domain() check here means the one inside
the function becomes redundant - it should be dropped or
converted to an ASSERT() imo. Furthermore if the check is to
remain here, please drop the redundant assignment of rc.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 12/23] x86: monitor.o is currently HVM only
  2018-08-26 12:19 ` [PATCH v2 12/23] x86: monitor.o is currently " Wei Liu
  2018-08-26 16:33   ` Razvan Cojocaru
@ 2018-08-27 15:18   ` Jan Beulich
  2018-08-27 15:23     ` Razvan Cojocaru
  2018-08-29 16:42     ` Wei Liu
  1 sibling, 2 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 15:18 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> There has been plan to make PV work, but it is not yet there.  Provide
> stubs to make it build with !CONFIG_HVM.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/arch/x86/Makefile         |  2 +-
>  xen/include/asm-x86/monitor.h | 14 ++++++++++++++
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 9b9b63a..43f9189 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -45,7 +45,7 @@ obj-y += microcode_amd.o
>  obj-y += microcode_intel.o
>  obj-y += microcode.o
>  obj-y += mm.o x86_64/mm.o
> -obj-y += monitor.o
> +obj-$(CONFIG_HVM) += monitor.o
>  obj-y += mpparse.o
>  obj-y += nmi.o
>  obj-y += numa.o
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index 4988903..09f7f8a 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -99,10 +99,24 @@ static inline uint32_t 
> arch_monitor_get_capabilities(struct domain *d)
>  int arch_monitor_domctl_event(struct domain *d,
>                                struct xen_domctl_monitor_op *mop);
>  
> +#ifdef CONFIG_HVM
> +
>  int arch_monitor_init_domain(struct domain *d);
>  
>  void arch_monitor_cleanup_domain(struct domain *d);
>  
> +#else
> +
> +static inline int arch_monitor_init_domain(struct domain *d)
> +{
> +    return 0;
> +}
> +
> +static inline void arch_monitor_cleanup_domain(struct domain *d)
> +{}
> +
> +#endif

Wouldn't the entire XEN_DOMCTL_VM_EVENT_OP_MONITOR case
in vm_event_domctl() then better be put in an #ifdef instead?

Otherwise, style wise I think I sort of agree with Razvan: We don't
seem to have any examples of {} together on their own line. We
do have example though with them together at the end of the
preceding line, which I think is better than having { and } separately
on their own lines.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 12/23] x86: monitor.o is currently HVM only
  2018-08-27 15:18   ` Jan Beulich
@ 2018-08-27 15:23     ` Razvan Cojocaru
  2018-08-29 16:42     ` Wei Liu
  1 sibling, 0 replies; 97+ messages in thread
From: Razvan Cojocaru @ 2018-08-27 15:23 UTC (permalink / raw)
  To: Jan Beulich, Wei Liu; +Cc: Andrew Cooper, Tamas K Lengyel, xen-devel

On 8/27/18 6:18 PM, Jan Beulich wrote:
>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>> There has been plan to make PV work, but it is not yet there.  Provide
>> stubs to make it build with !CONFIG_HVM.
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> ---
>>  xen/arch/x86/Makefile         |  2 +-
>>  xen/include/asm-x86/monitor.h | 14 ++++++++++++++
>>  2 files changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
>> index 9b9b63a..43f9189 100644
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -45,7 +45,7 @@ obj-y += microcode_amd.o
>>  obj-y += microcode_intel.o
>>  obj-y += microcode.o
>>  obj-y += mm.o x86_64/mm.o
>> -obj-y += monitor.o
>> +obj-$(CONFIG_HVM) += monitor.o
>>  obj-y += mpparse.o
>>  obj-y += nmi.o
>>  obj-y += numa.o
>> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
>> index 4988903..09f7f8a 100644
>> --- a/xen/include/asm-x86/monitor.h
>> +++ b/xen/include/asm-x86/monitor.h
>> @@ -99,10 +99,24 @@ static inline uint32_t 
>> arch_monitor_get_capabilities(struct domain *d)
>>  int arch_monitor_domctl_event(struct domain *d,
>>                                struct xen_domctl_monitor_op *mop);
>>  
>> +#ifdef CONFIG_HVM
>> +
>>  int arch_monitor_init_domain(struct domain *d);
>>  
>>  void arch_monitor_cleanup_domain(struct domain *d);
>>  
>> +#else
>> +
>> +static inline int arch_monitor_init_domain(struct domain *d)
>> +{
>> +    return 0;
>> +}
>> +
>> +static inline void arch_monitor_cleanup_domain(struct domain *d)
>> +{}
>> +
>> +#endif
> 
> Wouldn't the entire XEN_DOMCTL_VM_EVENT_OP_MONITOR case
> in vm_event_domctl() then better be put in an #ifdef instead?

That should be fine as well (perhaps even better than returning an error
here, since the switch would then just default with an error without the
duplicate function).


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 13/23] x86: provide stubs, declarations and macros in hvm.h
  2018-08-26 12:19 ` [PATCH v2 13/23] x86: provide stubs, declarations and macros in hvm.h Wei Liu
@ 2018-08-27 15:43   ` Jan Beulich
  2018-09-03  9:45   ` Paul Durrant
  1 sibling, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 15:43 UTC (permalink / raw)
  To: Paul Durrant, Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> Make sure hvm_enabled evaluate to false then provide necessary stubs,
> declarations and macros to make Xen build.
> 
> The is_viridian_domain macro can't be turned into an inline function
> easily, so instead its caller is modified to avoid unused variable
> warning.

I assume that's because struct domain hasn't been fully declared
yet at that point. Some preliminary looking around suggests that
it may be possible to address this by moving it plus a few more
nearby items into hvm/viridian.h, and avoiding other headers in
hvm/ to include hvm/viridian.h. This last item would in turn seem
to require to convert struct viridian_domain the instance in
struct hvm_domain to a pointer, which I personally think would
be desirable anyway. Paul?

Otoh I'm not really sure all of this is worth the effort.

> @@ -268,8 +271,8 @@ u64 hvm_get_guest_tsc_fixed(struct vcpu *v, u64 at_tsc);
>  #define hvm_tsc_scaling_ratio(d) \
>      ((d)->arch.hvm_domain.tsc_scaling_ratio)
>  
> -u64 hvm_scale_tsc(const struct domain *d, u64 tsc);
> -u64 hvm_get_tsc_scaling_ratio(u32 gtsc_khz);
> +uint64_t hvm_scale_tsc(const struct domain *d, uint64_t tsc);
> +uint64_t hvm_get_tsc_scaling_ratio(uint32_t gtsc_khz);

I think this change doesn't really belong here. I don't mind if you
want to keep it, but then I question the need for uint32_t (rather
than unsigned int) for the second prototype's parameter.

> @@ -675,6 +678,146 @@ unsigned long hvm_cr4_guest_valid_bits(const struct domain *d, bool restore);
>          d_->arch.hvm_domain.pi_ops.vcpu_block(v_);          \
>  })
>  
> +#else /* CONFIG_HVM */
> +
> +#define hvm_enabled false
> +
> +static inline int hvm_guest_x86_mode(struct vcpu *v)
> +{
> +    ASSERT_UNREACHABLE();
> +    return -1;
> +}

Hmm, there's a whole lot of things down from here. I'd really like to
see this minimized quite a bit. A first thought: On top of my indirect
call patching series, instead of directly using the macros provided
by the alternatives.h additions, an extra layer of abstraction could
introduce a macro which evaluates to ASSERT_UNREACHABLE()
without HVM, and to alternative_{,v}call() otherwise. I think this
would eliminate quite a few of the newly added inline functions.
I'll therefore skip some of the additions here.

> +#define hvm_long_mode_active(v) (false)
> +#define hvm_pae_enabled(v) (false)
> +#define hvm_get_guest_time(v) (0)
> +#define is_viridian_domain(d) (false)
> +#define has_viridian_time_ref_count(d) (false)
> +#define hvm_tsc_scaling_supported (false)
> +#define hap_has_1gb (false)
> +#define hap_has_2mb (false)
> +
> +#define hvm_paging_enabled(v) (false)
> +#define hvm_nx_enabled(v) (false)
> +#define hvm_wp_enabled(v) (false)
> +#define hvm_smap_enabled(v) (false)
> +#define hvm_smep_enabled(v) (false)
> +#define hvm_pku_enabled(v) (false)
> +
> +#define arch_vcpu_block(v) ((void)v)

Parenthesization is odd here: Just like for hvm_enabled, false
and 0 don't need parentheses, yet arguments should (a) be
properly parenthesized when used and (b) be consistently
evaluated (or not).

> +int hvm_vcpu_initialise(struct vcpu *v);
> +void hvm_vcpu_destroy(struct vcpu *v);
> +int hvm_domain_initialise(struct domain *d);
> +void hvm_domain_destroy(struct domain *d);
> +void hvm_domain_soft_reset(struct domain *d);
> +void hvm_domain_relinquish_resources(struct domain *d);
> +uint64_t hvm_scale_tsc(const struct domain *d, uint64_t tsc);
> +uint64_t hvm_get_tsc_scaling_ratio(uint32_t gtsc_khz);
> +
> +void hvm_get_segment_register(struct vcpu *v, enum x86_segment seg,
> +                              struct segment_register *reg);
> +
> +void hvm_set_rdtsc_exiting(struct domain *d, bool_t enable);
> +void hvm_toggle_singlestep(struct vcpu *v);
> +void hvm_mapped_guest_frames_mark_dirty(struct domain *);
> +void hvm_hypercall_page_initialise(struct domain *d,
> +                                   void *hypercall_page);

Many if not all of these already have declarations. They shouldn't
be repeated (and risk to go out of sync) in the #if and #else
sections of this conditional. All external declarations are fine to
remain visible regardless of CONFIG_HVM - the linker will complain
if any are referenced without there being a definition anywhere.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 14/23] x86/mm: put nested p2m code under CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 14/23] x86/mm: put nested p2m code under CONFIG_HVM Wei Liu
@ 2018-08-27 15:56   ` Jan Beulich
  2018-08-28  8:40     ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 15:56 UTC (permalink / raw)
  To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1689,7 +1689,8 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>      {
>          _update_runstate_area(prev);
>          vpmu_switch_from(prev);
> -        np2m_schedule(NP2M_SCHEDLE_OUT);
> +        if ( nestedhvm_enabled(prevd) )
> +            np2m_schedule(NP2M_SCHEDLE_OUT);
>      }
>  
>      if ( is_hvm_domain(prevd) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
> @@ -1756,7 +1757,8 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>  
>          /* Must be done with interrupts enabled */
>          vpmu_switch_to(next);
> -        np2m_schedule(NP2M_SCHEDLE_IN);
> +        if ( nestedhvm_enabled(nextd) )
> +            np2m_schedule(NP2M_SCHEDLE_IN);
>      }

How do these additions help? nestedhvm_enabled() is not an inline
function, and the entire series doesn't seem to touch hvm/nestedhvm.h
(i.e. there's no inline stub being added).

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -144,6 +144,7 @@ static void p2m_teardown_hostp2m(struct domain *d)
>  
>  static void p2m_teardown_nestedp2m(struct domain *d)
>  {
> +#ifdef CONFIG_HVM
>      unsigned int i;
>      struct p2m_domain *p2m;
>  
> @@ -156,10 +157,12 @@ static void p2m_teardown_nestedp2m(struct domain *d)
>          p2m_free_one(p2m);
>          d->arch.nested_p2m[i] = NULL;
>      }
> +#endif
>  }
>  
>  static int p2m_init_nestedp2m(struct domain *d)
>  {
> +#ifdef CONFIG_HVM
>      unsigned int i;
>      struct p2m_domain *p2m;
>  
> @@ -176,6 +179,7 @@ static int p2m_init_nestedp2m(struct domain *d)
>          p2m->write_p2m_entry = nestedp2m_write_p2m_entry;
>          list_add(&p2m->np2m_list, &p2m_get_hostp2m(d)->np2m_list);
>      }
> +#endif
>  
>      return 0;
>  }

Hmm, I think this is too ad hoc for my taste: For one I'm puzzled
by the lack of any (existing) is_hvm_domain() here. And then the
fields initialization of which you skip should also disappear, to
eliminate the risk of some code somewhere using the fields
uninitialized. This might simply mean to move the fields from
struct arch_domain to struct hvm_domain. I understand this may
end up being a more involved task, but it looks pretty much
unavoidable to me.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 15/23] x86/mm: put HVM only code under CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 15/23] x86/mm: put HVM only " Wei Liu
  2018-08-26 16:39   ` Razvan Cojocaru
  2018-08-27  9:03   ` Wei Liu
@ 2018-08-27 16:01   ` Jan Beulich
  2018-08-28 10:41     ` Wei Liu
  2 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-27 16:01 UTC (permalink / raw)
  To: Wei Liu
  Cc: George Dunlap, Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru,
	xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -1,9 +1,10 @@
>  subdir-y += shadow
> -subdir-y += hap
> +subdir-$(CONFIG_HVM) += hap
>  
>  obj-y += paging.o
> -obj-y += p2m.o p2m-pt.o p2m-ept.o p2m-pod.o
> -obj-y += altp2m.o
> +obj-y += p2m.o p2m-pt.o
> +obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
> +obj-$(CONFIG_HVM) += altp2m.o
>  obj-y += guest_walk_2.o
>  obj-y += guest_walk_3.o
>  obj-y += guest_walk_4.o

Would you mind once again sorting things at the same time?

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -535,7 +535,7 @@ struct page_info *p2m_get_page_from_gfn(
>  int p2m_set_entry(struct p2m_domain *p2m, gfn_t gfn, mfn_t mfn,
>                    unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
>  {
> -    struct domain *d = p2m->domain;
> +    struct domain * __maybe_unused d = p2m->domain;

Instead of this, why don't you simply latch hap_enabled()'s return
value into a local bool variable? (Otherwise I would ask for const
to be added here as you touch this anyway.) Adding
__maybe_unused should really be a last resort only.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 14/23] x86/mm: put nested p2m code under CONFIG_HVM
  2018-08-27 15:56   ` Jan Beulich
@ 2018-08-28  8:40     ` Wei Liu
  2018-08-28  9:10       ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-28  8:40 UTC (permalink / raw)
  To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Wei Liu, xen-devel

On Mon, Aug 27, 2018 at 09:56:24AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -1689,7 +1689,8 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
> >      {
> >          _update_runstate_area(prev);
> >          vpmu_switch_from(prev);
> > -        np2m_schedule(NP2M_SCHEDLE_OUT);
> > +        if ( nestedhvm_enabled(prevd) )
> > +            np2m_schedule(NP2M_SCHEDLE_OUT);
> >      }
> >  
> >      if ( is_hvm_domain(prevd) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
> > @@ -1756,7 +1757,8 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
> >  
> >          /* Must be done with interrupts enabled */
> >          vpmu_switch_to(next);
> > -        np2m_schedule(NP2M_SCHEDLE_IN);
> > +        if ( nestedhvm_enabled(nextd) )
> > +            np2m_schedule(NP2M_SCHEDLE_IN);
> >      }
> 
> How do these additions help? nestedhvm_enabled() is not an inline
> function, and the entire series doesn't seem to touch hvm/nestedhvm.h
> (i.e. there's no inline stub being added).

The patch that changed nestedhvm_enabled was committed before I sent out
this series -- please pull the latest changes.

> 
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -144,6 +144,7 @@ static void p2m_teardown_hostp2m(struct domain *d)
> >  
> >  static void p2m_teardown_nestedp2m(struct domain *d)
> >  {
> > +#ifdef CONFIG_HVM
> >      unsigned int i;
> >      struct p2m_domain *p2m;
> >  
> > @@ -156,10 +157,12 @@ static void p2m_teardown_nestedp2m(struct domain *d)
> >          p2m_free_one(p2m);
> >          d->arch.nested_p2m[i] = NULL;
> >      }
> > +#endif
> >  }
> >  
> >  static int p2m_init_nestedp2m(struct domain *d)
> >  {
> > +#ifdef CONFIG_HVM
> >      unsigned int i;
> >      struct p2m_domain *p2m;
> >  
> > @@ -176,6 +179,7 @@ static int p2m_init_nestedp2m(struct domain *d)
> >          p2m->write_p2m_entry = nestedp2m_write_p2m_entry;
> >          list_add(&p2m->np2m_list, &p2m_get_hostp2m(d)->np2m_list);
> >      }
> > +#endif
> >  
> >      return 0;
> >  }
> 
> Hmm, I think this is too ad hoc for my taste: For one I'm puzzled
> by the lack of any (existing) is_hvm_domain() here. And then the
> fields initialization of which you skip should also disappear, to
> eliminate the risk of some code somewhere using the fields
> uninitialized. This might simply mean to move the fields from
> struct arch_domain to struct hvm_domain. I understand this may
> end up being a more involved task, but it looks pretty much
> unavoidable to me.

p2m_init is called unconditionally for both PV and HVM. At the time I
read the code it appeared that it required nestedp2m to be initialised
and tear down unconditionally.

Do you want me to rewrite p2m_init and p2m_teardown_final to put things
under is_hvm_domain?

Regarding fields in data structure, I think moving them would be a good
idea.

Wei.

> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 02/23] xen: is_hvm_{domain, vcpu} should evaluate to false when !CONFIG_HVM
  2018-08-27 14:24   ` Jan Beulich
@ 2018-08-28  8:41     ` Wei Liu
  2018-08-28 11:09       ` Julien Grall
  0 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-28  8:41 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, xen-devel

On Mon, Aug 27, 2018 at 08:24:03AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > Turn them into static inline functions which evaluate to false when
> > CONFIG_HVM is not set. ARM won't be broken because ARM guests are set
> > to PV type in the hypervisor.
> > 
> > But ARM has plan to switch to HVM guest type inside the hypervisor, so
> > preemptively introduce CONFIG_HVM for ARM here.
> 
> But is setting this to Y then correct at this point?

I think it would be less surprising when the switching eventually
happens. I will let ARM maintainers decide whether it should be Y or N.

> 
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -879,8 +879,17 @@ void watchdog_domain_destroy(struct domain *d);
> >  
> >  #define is_pv_domain(d) ((d)->guest_type == guest_type_pv)
> >  #define is_pv_vcpu(v)   (is_pv_domain((v)->domain))
> > -#define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm)
> > -#define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
> > +
> > +static inline bool is_hvm_domain(const struct domain *d)
> > +{
> > +    return IS_ENABLED(CONFIG_HVM) ? d->guest_type == guest_type_hvm : false;
> 
> Ultimately I think the guest_type_{hvm,pv} enumerators should only
> be enabled when CONFIG_{HVM,PV}, so I think #ifdef CONFIG_HVM
> would be the better choice here. But of course we can do this further
> conversion at a later point, so
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI
  2018-08-27 14:29   ` Jan Beulich
@ 2018-08-28  8:45     ` Wei Liu
  2018-08-28  9:08       ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-28  8:45 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel

On Mon, Aug 27, 2018 at 08:29:20AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -557,6 +557,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> >  
> >          ret = pci_mmcfg_reserved(info.address, info.segment,
> >                                   info.start_bus, info.end_bus, info.flags);
> > +#ifdef CONFIG_HAS_VPCI
> >          if ( !ret && has_vpci(currd) )
> >          {
> >              /*
> > @@ -567,6 +568,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> >                                                info.start_bus, info.end_bus,
> >                                                info.segment);
> >          }
> > +#endif
> 
> Perhaps better to make has_vpci() evaluate to false in that case,
> and once again rely on DCE?

But then that goes back to your previous argument that it creates
disconnection between emulation_flags_ok and has_*. If we want to change
has_vpci I would also need to change emulation_flags_ok. Is that what
you prefer?

Wei.

> 
> Jan
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI
  2018-08-28  8:45     ` Wei Liu
@ 2018-08-28  9:08       ` Jan Beulich
  2018-08-29 16:23         ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-28  9:08 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 28.08.18 at 10:45, <wei.liu2@citrix.com> wrote:
> On Mon, Aug 27, 2018 at 08:29:20AM -0600, Jan Beulich wrote:
>> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>> > --- a/xen/arch/x86/physdev.c
>> > +++ b/xen/arch/x86/physdev.c
>> > @@ -557,6 +557,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>> >  
>> >          ret = pci_mmcfg_reserved(info.address, info.segment,
>> >                                   info.start_bus, info.end_bus, info.flags);
>> > +#ifdef CONFIG_HAS_VPCI
>> >          if ( !ret && has_vpci(currd) )
>> >          {
>> >              /*
>> > @@ -567,6 +568,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>> >                                                info.start_bus, info.end_bus,
>> >                                                info.segment);
>> >          }
>> > +#endif
>> 
>> Perhaps better to make has_vpci() evaluate to false in that case,
>> and once again rely on DCE?
> 
> But then that goes back to your previous argument that it creates
> disconnection between emulation_flags_ok and has_*. If we want to change
> has_vpci I would also need to change emulation_flags_ok. Is that what
> you prefer?

Hmm, I see. Utilizing DCE here seems pretty desirable. Perhaps
emulation_flags_ok() should be switched to use derived constants
rather than the raw public interface ones. The HVM-only ones
then would simply become constant zero when !HVM, allowing
emulation_flags_ok() as well as the has_*() macros to be left alone
and DCE still be utilized.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 14/23] x86/mm: put nested p2m code under CONFIG_HVM
  2018-08-28  8:40     ` Wei Liu
@ 2018-08-28  9:10       ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-28  9:10 UTC (permalink / raw)
  To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, xen-devel

>>> On 28.08.18 at 10:40, <wei.liu2@citrix.com> wrote:
> On Mon, Aug 27, 2018 at 09:56:24AM -0600, Jan Beulich wrote:
>> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>> > --- a/xen/arch/x86/domain.c
>> > +++ b/xen/arch/x86/domain.c
>> > @@ -1689,7 +1689,8 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>> >      {
>> >          _update_runstate_area(prev);
>> >          vpmu_switch_from(prev);
>> > -        np2m_schedule(NP2M_SCHEDLE_OUT);
>> > +        if ( nestedhvm_enabled(prevd) )
>> > +            np2m_schedule(NP2M_SCHEDLE_OUT);
>> >      }
>> >  
>> >      if ( is_hvm_domain(prevd) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
>> > @@ -1756,7 +1757,8 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>> >  
>> >          /* Must be done with interrupts enabled */
>> >          vpmu_switch_to(next);
>> > -        np2m_schedule(NP2M_SCHEDLE_IN);
>> > +        if ( nestedhvm_enabled(nextd) )
>> > +            np2m_schedule(NP2M_SCHEDLE_IN);
>> >      }
>> 
>> How do these additions help? nestedhvm_enabled() is not an inline
>> function, and the entire series doesn't seem to touch hvm/nestedhvm.h
>> (i.e. there's no inline stub being added).
> 
> The patch that changed nestedhvm_enabled was committed before I sent out
> this series -- please pull the latest changes.

Oh, I see - I'm sorry.

>> > --- a/xen/arch/x86/mm/p2m.c
>> > +++ b/xen/arch/x86/mm/p2m.c
>> > @@ -144,6 +144,7 @@ static void p2m_teardown_hostp2m(struct domain *d)
>> >  
>> >  static void p2m_teardown_nestedp2m(struct domain *d)
>> >  {
>> > +#ifdef CONFIG_HVM
>> >      unsigned int i;
>> >      struct p2m_domain *p2m;
>> >  
>> > @@ -156,10 +157,12 @@ static void p2m_teardown_nestedp2m(struct domain *d)
>> >          p2m_free_one(p2m);
>> >          d->arch.nested_p2m[i] = NULL;
>> >      }
>> > +#endif
>> >  }
>> >  
>> >  static int p2m_init_nestedp2m(struct domain *d)
>> >  {
>> > +#ifdef CONFIG_HVM
>> >      unsigned int i;
>> >      struct p2m_domain *p2m;
>> >  
>> > @@ -176,6 +179,7 @@ static int p2m_init_nestedp2m(struct domain *d)
>> >          p2m->write_p2m_entry = nestedp2m_write_p2m_entry;
>> >          list_add(&p2m->np2m_list, &p2m_get_hostp2m(d)->np2m_list);
>> >      }
>> > +#endif
>> >  
>> >      return 0;
>> >  }
>> 
>> Hmm, I think this is too ad hoc for my taste: For one I'm puzzled
>> by the lack of any (existing) is_hvm_domain() here. And then the
>> fields initialization of which you skip should also disappear, to
>> eliminate the risk of some code somewhere using the fields
>> uninitialized. This might simply mean to move the fields from
>> struct arch_domain to struct hvm_domain. I understand this may
>> end up being a more involved task, but it looks pretty much
>> unavoidable to me.
> 
> p2m_init is called unconditionally for both PV and HVM. At the time I
> read the code it appeared that it required nestedp2m to be initialised
> and tear down unconditionally.
> 
> Do you want me to rewrite p2m_init and p2m_teardown_final to put things
> under is_hvm_domain?

I think that's what is needed, yes.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 15/23] x86/mm: put HVM only code under CONFIG_HVM
  2018-08-27  9:03   ` Wei Liu
@ 2018-08-28 10:41     ` Wei Liu
  2018-08-28 10:53       ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-28 10:41 UTC (permalink / raw)
  To: xen-devel
  Cc: Tamas K Lengyel, Wei Liu, Razvan Cojocaru, George Dunlap,
	Andrew Cooper, Jan Beulich

On Mon, Aug 27, 2018 at 10:03:11AM +0100, Wei Liu wrote:
> > +#ifdef CONFIG_HVM
> >  #define hap_enabled(d)  ((d)->arch.hvm_domain.hap_enabled)
> > +#else
> > +#define hap_enabled(d)  false
> > +#endif
> 
> Hmm... I thought I had rewritten this to be a static inline function.
> 
> I will try to make it a static inline function.
> 

It all came back: The reason I didn't turn it into a static inline
function was because asm/hvm/domain.h didn't have struct domain
available. To fix that it would seem to require more code churn to me.

I will keep hap_enabled a macro.

Wei.

> Wei.
> 
> >  
> >  #endif /* __ASM_X86_HVM_DOMAIN_H__ */
> >  
> > -- 
> > git-series 0.9.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 15/23] x86/mm: put HVM only code under CONFIG_HVM
  2018-08-27 16:01   ` Jan Beulich
@ 2018-08-28 10:41     ` Wei Liu
  0 siblings, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-28 10:41 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Tamas K Lengyel, Wei Liu, Razvan Cojocaru, George Dunlap,
	Andrew Cooper, xen-devel

On Mon, Aug 27, 2018 at 10:01:31AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/mm/Makefile
> > +++ b/xen/arch/x86/mm/Makefile
> > @@ -1,9 +1,10 @@
> >  subdir-y += shadow
> > -subdir-y += hap
> > +subdir-$(CONFIG_HVM) += hap
> >  
> >  obj-y += paging.o
> > -obj-y += p2m.o p2m-pt.o p2m-ept.o p2m-pod.o
> > -obj-y += altp2m.o
> > +obj-y += p2m.o p2m-pt.o
> > +obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
> > +obj-$(CONFIG_HVM) += altp2m.o
> >  obj-y += guest_walk_2.o
> >  obj-y += guest_walk_3.o
> >  obj-y += guest_walk_4.o
> 
> Would you mind once again sorting things at the same time?

Sure.

> 
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -535,7 +535,7 @@ struct page_info *p2m_get_page_from_gfn(
> >  int p2m_set_entry(struct p2m_domain *p2m, gfn_t gfn, mfn_t mfn,
> >                    unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
> >  {
> > -    struct domain *d = p2m->domain;
> > +    struct domain * __maybe_unused d = p2m->domain;
> 
> Instead of this, why don't you simply latch hap_enabled()'s return
> value into a local bool variable? (Otherwise I would ask for const
> to be added here as you touch this anyway.) Adding
> __maybe_unused should really be a last resort only.

OK. I will latch its value.

Wei.

> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 16/23] x86/p2m/pod: make it build with !CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 16/23] x86/p2m/pod: make it build with !CONFIG_HVM Wei Liu
@ 2018-08-28 10:47   ` Jan Beulich
  2018-08-28 10:54     ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 10:47 UTC (permalink / raw)
  To: Wei Liu
  Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
	Tim Deegan, Julien Grall, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> +static inline int p2m_pod_set_mem_target(struct domain *d, unsigned long target)
> +{
> +    return 0;
> +}

This one, at the very least, should not be needed: The case block
in arch_memory_op() containing the only call should altogether be
framed by #ifdef CONFIG_HVM.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM Wei Liu
@ 2018-08-28 10:50   ` Jan Beulich
  2018-08-30  7:42     ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 10:50 UTC (permalink / raw)
  To: Andrew Cooper, Wei Liu, George Dunlap; +Cc: xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct vcpu *v)
>      return paging_get_nestedmode(v);
>  }
>  
> +#ifdef CONFIG_HVM
>  void paging_update_nestedmode(struct vcpu *v)
>  {
>      ASSERT(nestedhvm_enabled(v->domain));
> @@ -930,6 +931,7 @@ void paging_update_nestedmode(struct vcpu *v)
>          v->arch.paging.nestedmode = NULL;
>      hvm_asid_flush_vcpu(v);
>  }
> +#endif

Just a consideration (no objection): Would it be worthwhile to
introduce CONFIG_NESTED_HVM at the same time (for now hard
coded to Y, and of course depending on HVM) to avoid having to
touch all such places a second time later on?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 18/23] x86/domctl: XEN_DOMCTL_debug_op is HVM only
  2018-08-26 12:19 ` [PATCH v2 18/23] x86/domctl: XEN_DOMCTL_debug_op is HVM only Wei Liu
@ 2018-08-28 10:50   ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 10:50 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 15/23] x86/mm: put HVM only code under CONFIG_HVM
  2018-08-28 10:41     ` Wei Liu
@ 2018-08-28 10:53       ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 10:53 UTC (permalink / raw)
  To: Wei Liu
  Cc: George Dunlap, Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru,
	xen-devel

>>> On 28.08.18 at 12:41, <wei.liu2@citrix.com> wrote:
> On Mon, Aug 27, 2018 at 10:03:11AM +0100, Wei Liu wrote:
>> > +#ifdef CONFIG_HVM
>> >  #define hap_enabled(d)  ((d)->arch.hvm_domain.hap_enabled)
>> > +#else
>> > +#define hap_enabled(d)  false
>> > +#endif
>> 
>> Hmm... I thought I had rewritten this to be a static inline function.
>> 
>> I will try to make it a static inline function.
>> 
> 
> It all came back: The reason I didn't turn it into a static inline
> function was because asm/hvm/domain.h didn't have struct domain
> available. To fix that it would seem to require more code churn to me.
> 
> I will keep hap_enabled a macro.

But then please at least evaluate its argument, to avoid any
need to add __maybe_unused to local variables.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 16/23] x86/p2m/pod: make it build with !CONFIG_HVM
  2018-08-28 10:47   ` Jan Beulich
@ 2018-08-28 10:54     ` Wei Liu
  2018-08-28 11:32       ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-28 10:54 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, xen-devel

On Tue, Aug 28, 2018 at 04:47:53AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > +static inline int p2m_pod_set_mem_target(struct domain *d, unsigned long target)
> > +{
> > +    return 0;
> > +}
> 
> This one, at the very least, should not be needed: The case block
> in arch_memory_op() containing the only call should altogether be
> framed by #ifdef CONFIG_HVM.

The toolstack unconditionally sets pod target when setting a domain's
memory target. I will need to change libxl to not issue pod call for PV
guests in that case.

Wei.

> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV}
  2018-08-26 12:19 ` [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV} Wei Liu
@ 2018-08-28 11:07   ` Julien Grall
  2018-08-28 13:13     ` Wei Liu
  2018-08-28 11:47   ` Jan Beulich
  1 sibling, 1 reply; 97+ messages in thread
From: Julien Grall @ 2018-08-28 11:07 UTC (permalink / raw)
  To: Wei Liu, xen-devel
  Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
	Tim Deegan, Jan Beulich

Hi Wei,

On 26/08/18 13:19, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

This patch is going to break Arm until we switched to PVH in the toolstack.

Cheers,

> ---
>   xen/common/domain.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
> 
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 171d25e..73b5485 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -318,9 +318,23 @@ struct domain *domain_create(domid_t domid,
>       if ( !is_idle_domain(d) )
>       {
>           if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
> +        {
> +#ifdef CONFIG_HVM
>               d->guest_type = guest_type_hvm;
> +#else
> +            err = -EINVAL;
> +            goto fail;
> +#endif
> +        }
>           else
> +        {
> +#ifdef CONFIG_PV
>               d->guest_type = guest_type_pv;
> +#else
> +            err = -EINVAL;
> +            goto fail;
> +#endif
> +        }
>   
>           watchdog_domain_init(d);
>           init_status |= INIT_watchdog;
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 02/23] xen: is_hvm_{domain, vcpu} should evaluate to false when !CONFIG_HVM
  2018-08-28  8:41     ` Wei Liu
@ 2018-08-28 11:09       ` Julien Grall
  0 siblings, 0 replies; 97+ messages in thread
From: Julien Grall @ 2018-08-28 11:09 UTC (permalink / raw)
  To: Wei Liu, Jan Beulich
  Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
	Tim Deegan, xen-devel

Hi,

On 28/08/18 09:41, Wei Liu wrote:
> On Mon, Aug 27, 2018 at 08:24:03AM -0600, Jan Beulich wrote:
>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>>> Turn them into static inline functions which evaluate to false when
>>> CONFIG_HVM is not set. ARM won't be broken because ARM guests are set
>>> to PV type in the hypervisor.
>>>
>>> But ARM has plan to switch to HVM guest type inside the hypervisor, so
>>> preemptively introduce CONFIG_HVM for ARM here.
>>
>> But is setting this to Y then correct at this point?
> 
> I think it would be less surprising when the switching eventually
> happens. I will let ARM maintainers decide whether it should be Y or N.

I am fine with this changes to be committed now.

Acked-by: Julien Grall <julien.grall@arm.com>


Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 16/23] x86/p2m/pod: make it build with !CONFIG_HVM
  2018-08-28 10:54     ` Wei Liu
@ 2018-08-28 11:32       ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 11:32 UTC (permalink / raw)
  To: Wei Liu
  Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
	Tim Deegan, Julien Grall, xen-devel

>>> On 28.08.18 at 12:54, <wei.liu2@citrix.com> wrote:
> On Tue, Aug 28, 2018 at 04:47:53AM -0600, Jan Beulich wrote:
>> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>> > +static inline int p2m_pod_set_mem_target(struct domain *d, unsigned long target)
>> > +{
>> > +    return 0;
>> > +}
>> 
>> This one, at the very least, should not be needed: The case block
>> in arch_memory_op() containing the only call should altogether be
>> framed by #ifdef CONFIG_HVM.
> 
> The toolstack unconditionally sets pod target when setting a domain's
> memory target. I will need to change libxl to not issue pod call for PV
> guests in that case.

Ah, I see. I also forgot to say that the entire pod sub-structure
of struct p2m_domain should also be enclosed in #ifdef CONFIG_HVM.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-26 12:19 ` [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM Wei Liu
@ 2018-08-28 11:44   ` Jan Beulich
  2018-08-28 13:19     ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 11:44 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> Move the file to x86 common code and change its name to emul-i8254.c.
> 
> Put HVM only code under CONFIG_HVM or is_hvm_domain.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> v2: move the whole file.
> ---
>  xen/arch/x86/Makefile     |   1 +-
>  xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
>  xen/arch/x86/hvm/Makefile |   1 +-
>  xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
>  4 files changed, 610 insertions(+), 598 deletions(-)
>  create mode 100644 xen/arch/x86/emul-i8254.c
>  delete mode 100644 xen/arch/x86/hvm/i8254.c

On the assumption that the changes to the file are only CONFIG_HVM
additions
Acked-by: Jan Beulich <jbeulich@suse.com>
Generating the diff with rename detection would have eased review
though.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV}
  2018-08-26 12:19 ` [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV} Wei Liu
  2018-08-28 11:07   ` Julien Grall
@ 2018-08-28 11:47   ` Jan Beulich
  2018-08-28 13:15     ` Wei Liu
  1 sibling, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 11:47 UTC (permalink / raw)
  To: Wei Liu
  Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
	Tim Deegan, Julien Grall, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
provided the ARM side issue pointed out by Julien is going to
be taken care of (presumably by a patch inserted earlier in the
series).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 21/23] x86: expose CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 21/23] x86: expose CONFIG_HVM Wei Liu
@ 2018-08-28 11:50   ` Jan Beulich
  2018-08-28 12:14     ` Andrew Cooper
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 11:50 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>  
>  config HVM
>  	def_bool y
> +	prompt "HVM / PVH support"
> +	---help---
> +	  Interfaces to support HVM and PVH guests.
> +
> +	  If unsure, say Y.
> +
>  
>  config SHADOW_PAGING

No double blank lines please.

My previously voiced reservations wrt the shim remain. I continue
to disagree with Andrew that the symbol needs to be visible in a
shim-only config, and I continue to demand as a minimum that the
default here be N in that case if the symbol really is to remain visible.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 23/23] xen: decouple HVM and IOMMU capabilities
  2018-08-26 12:19 ` [PATCH v2 23/23] xen: decouple HVM and IOMMU capabilities Wei Liu
@ 2018-08-28 11:56   ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 11:56 UTC (permalink / raw)
  To: Wei Liu
  Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
	Tim Deegan, Julien Grall, xen-devel

>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> HVM and IOMMU are two distinct hardware features, yet they were
> bundled together in sysctl and xl's output.
> 
> Decouple them on sysctl level. On toolstack level we still need to
> maintain a sensible semantics for `xl info`. Massage the information
> according to the following table:
> 
> pv      hvm     iommu           flags in xl info
> 0       0       0               n/a
> 0       0       1               n/a
> 0       1       0               hvm
> 0       1       1               hvm hvm_directio
> 1       0       0               NIL
> 1       0       1               directio
> 1       1       0               hvm
> 1       1       1               hvm hvm_directio directio
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Hypervisor side
Acked-by: Jan Beulich <jbeulich@suse.com>

Tools side looks sensible to me too, but I'm not going to claim I've
properly reviewed it.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 21/23] x86: expose CONFIG_HVM
  2018-08-28 11:50   ` Jan Beulich
@ 2018-08-28 12:14     ` Andrew Cooper
  2018-08-28 13:33       ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Andrew Cooper @ 2018-08-28 12:14 UTC (permalink / raw)
  To: Jan Beulich, Wei Liu; +Cc: xen-devel

On 28/08/18 12:50, Jan Beulich wrote:
>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>  
>>  config HVM
>>  	def_bool y
>> +	prompt "HVM / PVH support"
>> +	---help---
>> +	  Interfaces to support HVM and PVH guests.

This definitely needs more than a single line...

>> +
>> +	  If unsure, say Y.
>> +
>>  
>>  config SHADOW_PAGING
> No double blank lines please.
>
> My previously voiced reservations wrt the shim remain. I continue
> to disagree with Andrew that the symbol needs to be visible in a
> shim-only config, and I continue to demand as a minimum that the
> default here be N in that case if the symbol really is to remain visible.

Conditionally influencing the default is fine.  Hiding the symbol is not.

To be very very clear, I will nack/revert any patch which tries to
insert a dependency here.  I find your reasoning to be wrong, and
sufficiently short sighted and detrimental to users, that I'm not going
to let the patch in.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV}
  2018-08-28 11:07   ` Julien Grall
@ 2018-08-28 13:13     ` Wei Liu
  0 siblings, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-28 13:13 UTC (permalink / raw)
  To: Julien Grall
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Jan Beulich, xen-devel

On Tue, Aug 28, 2018 at 12:07:24PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> On 26/08/18 13:19, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> This patch is going to break Arm until we switched to PVH in the toolstack.
> 
> Cheers,
> 
> > ---
> >   xen/common/domain.c | 14 ++++++++++++++
> >   1 file changed, 14 insertions(+)
> > 
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 171d25e..73b5485 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -318,9 +318,23 @@ struct domain *domain_create(domid_t domid,
> >       if ( !is_idle_domain(d) )
> >       {
> >           if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
> > +        {
> > +#ifdef CONFIG_HVM
> >               d->guest_type = guest_type_hvm;
> > +#else
> > +            err = -EINVAL;
> > +            goto fail;
> > +#endif
> > +        }
> >           else
> > +        {
> > +#ifdef CONFIG_PV

Oh, yes, this should have been

/* Currently toolstack treats ARM guests as PV, bodge it for now until
 * ARM switches to PVH.
 */

#if defined(CONFIG_PV) || defined(CONFIG_ARM)

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV}
  2018-08-28 11:47   ` Jan Beulich
@ 2018-08-28 13:15     ` Wei Liu
  0 siblings, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-28 13:15 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
	Ian Jackson, Tim Deegan, Julien Grall, xen-devel

On Tue, Aug 28, 2018 at 05:47:13AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> provided the ARM side issue pointed out by Julien is going to
> be taken care of (presumably by a patch inserted earlier in the
> series).

The issue is going to be taken care of by either updating the CONFIG_PV
ifdef (as I proposed in the reply to Julien), shrink the scope of this
patch to only handle CONFIG_HVM or wait until Julien's series is
committed.

In any case, I have taken note to sort this out.

Wei.

> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-28 11:44   ` Jan Beulich
@ 2018-08-28 13:19     ` Wei Liu
  2018-08-28 14:36       ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-28 13:19 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel

On Tue, Aug 28, 2018 at 05:44:51AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > Move the file to x86 common code and change its name to emul-i8254.c.
> > 
> > Put HVM only code under CONFIG_HVM or is_hvm_domain.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > v2: move the whole file.
> > ---
> >  xen/arch/x86/Makefile     |   1 +-
> >  xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
> >  xen/arch/x86/hvm/Makefile |   1 +-
> >  xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
> >  4 files changed, 610 insertions(+), 598 deletions(-)
> >  create mode 100644 xen/arch/x86/emul-i8254.c
> >  delete mode 100644 xen/arch/x86/hvm/i8254.c
> 
> On the assumption that the changes to the file are only CONFIG_HVM
> additions

No only that. There are a few is_hvm_domain calls as well.

> Acked-by: Jan Beulich <jbeulich@suse.com>

Does this still stand?

> Generating the diff with rename detection would have eased review
> though.

I already had diff.renames=true in my config. Unfortunately it didn't
seem to work. Not sure why.

Wei.

> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 21/23] x86: expose CONFIG_HVM
  2018-08-28 12:14     ` Andrew Cooper
@ 2018-08-28 13:33       ` Jan Beulich
  2018-08-29 16:56         ` Andrew Cooper
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 13:33 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: xen-devel, Wei Liu

>>> On 28.08.18 at 14:14, <andrew.cooper3@citrix.com> wrote:
> On 28/08/18 12:50, Jan Beulich wrote:
>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>>  
>>>  config HVM
>>>  	def_bool y
>>> +	prompt "HVM / PVH support"
>>> +	---help---
>>> +	  Interfaces to support HVM and PVH guests.
> 
> This definitely needs more than a single line...
> 
>>> +
>>> +	  If unsure, say Y.
>>> +
>>>  
>>>  config SHADOW_PAGING
>> No double blank lines please.
>>
>> My previously voiced reservations wrt the shim remain. I continue
>> to disagree with Andrew that the symbol needs to be visible in a
>> shim-only config, and I continue to demand as a minimum that the
>> default here be N in that case if the symbol really is to remain visible.
> 
> Conditionally influencing the default is fine.  Hiding the symbol is not.
> 
> To be very very clear, I will nack/revert any patch which tries to
> insert a dependency here.  I find your reasoning to be wrong, and
> sufficiently short sighted and detrimental to users, that I'm not going
> to let the patch in.

Since iirc you didn't respond to my most recent comment on v1 here,
I would have very much hoped you'd explain your position a little
better than just claiming that the symbol becoming invisible with a
dependency added is a bad thing. I'm certainly open to (good)
arguments, but I'm not accepting a plain statement without proper
explanation.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-28 13:19     ` Wei Liu
@ 2018-08-28 14:36       ` Jan Beulich
  2018-08-28 14:48         ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 14:36 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 28.08.18 at 15:19, <wei.liu2@citrix.com> wrote:
> On Tue, Aug 28, 2018 at 05:44:51AM -0600, Jan Beulich wrote:
>> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>> > Move the file to x86 common code and change its name to emul-i8254.c.
>> > 
>> > Put HVM only code under CONFIG_HVM or is_hvm_domain.
>> > 
>> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> > ---
>> > v2: move the whole file.
>> > ---
>> >  xen/arch/x86/Makefile     |   1 +-
>> >  xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
>> >  xen/arch/x86/hvm/Makefile |   1 +-
>> >  xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
>> >  4 files changed, 610 insertions(+), 598 deletions(-)
>> >  create mode 100644 xen/arch/x86/emul-i8254.c
>> >  delete mode 100644 xen/arch/x86/hvm/i8254.c
>> 
>> On the assumption that the changes to the file are only CONFIG_HVM
>> additions
> 
> No only that. There are a few is_hvm_domain calls as well.
> 
>> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> Does this still stand?

Yes, albeit looking at the full diff of the files I'm then a little
puzzled about is_hvm_domain() uses: Why does pit_load_count()
need an #ifdef added at all, with the is_hvm_vcpu() check
right before it?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-28 14:36       ` Jan Beulich
@ 2018-08-28 14:48         ` Wei Liu
  2018-08-28 14:51           ` Andrew Cooper
  2018-08-28 14:56           ` Wei Liu
  0 siblings, 2 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-28 14:48 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel

On Tue, Aug 28, 2018 at 08:36:37AM -0600, Jan Beulich wrote:
> >>> On 28.08.18 at 15:19, <wei.liu2@citrix.com> wrote:
> > On Tue, Aug 28, 2018 at 05:44:51AM -0600, Jan Beulich wrote:
> >> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> >> > Move the file to x86 common code and change its name to emul-i8254.c.
> >> > 
> >> > Put HVM only code under CONFIG_HVM or is_hvm_domain.
> >> > 
> >> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >> > ---
> >> > v2: move the whole file.
> >> > ---
> >> >  xen/arch/x86/Makefile     |   1 +-
> >> >  xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
> >> >  xen/arch/x86/hvm/Makefile |   1 +-
> >> >  xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
> >> >  4 files changed, 610 insertions(+), 598 deletions(-)
> >> >  create mode 100644 xen/arch/x86/emul-i8254.c
> >> >  delete mode 100644 xen/arch/x86/hvm/i8254.c
> >> 
> >> On the assumption that the changes to the file are only CONFIG_HVM
> >> additions
> > 
> > No only that. There are a few is_hvm_domain calls as well.
> > 
> >> Acked-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Does this still stand?
> 
> Yes, albeit looking at the full diff of the files I'm then a little
> puzzled about is_hvm_domain() uses: Why does pit_load_count()
> need an #ifdef added at all, with the is_hvm_vcpu() check
> right before it?

Because if I don't do that we get "defined but not used" warnings.

Wei.

> 
> Jan
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-28 14:48         ` Wei Liu
@ 2018-08-28 14:51           ` Andrew Cooper
  2018-08-28 14:58             ` Wei Liu
  2018-08-28 14:56           ` Wei Liu
  1 sibling, 1 reply; 97+ messages in thread
From: Andrew Cooper @ 2018-08-28 14:51 UTC (permalink / raw)
  To: Wei Liu, Jan Beulich; +Cc: xen-devel

On 28/08/18 15:48, Wei Liu wrote:
> On Tue, Aug 28, 2018 at 08:36:37AM -0600, Jan Beulich wrote:
>>>>> On 28.08.18 at 15:19, <wei.liu2@citrix.com> wrote:
>>> On Tue, Aug 28, 2018 at 05:44:51AM -0600, Jan Beulich wrote:
>>>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>>>>> Move the file to x86 common code and change its name to emul-i8254.c.
>>>>>
>>>>> Put HVM only code under CONFIG_HVM or is_hvm_domain.
>>>>>
>>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>>>> ---
>>>>> v2: move the whole file.
>>>>> ---
>>>>>  xen/arch/x86/Makefile     |   1 +-
>>>>>  xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
>>>>>  xen/arch/x86/hvm/Makefile |   1 +-
>>>>>  xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
>>>>>  4 files changed, 610 insertions(+), 598 deletions(-)
>>>>>  create mode 100644 xen/arch/x86/emul-i8254.c
>>>>>  delete mode 100644 xen/arch/x86/hvm/i8254.c
>>>> On the assumption that the changes to the file are only CONFIG_HVM
>>>> additions
>>> No only that. There are a few is_hvm_domain calls as well.
>>>
>>>> Acked-by: Jan Beulich <jbeulich@suse.com>
>>> Does this still stand?
>> Yes, albeit looking at the full diff of the files I'm then a little
>> puzzled about is_hvm_domain() uses: Why does pit_load_count()
>> need an #ifdef added at all, with the is_hvm_vcpu() check
>> right before it?
> Because if I don't do that we get "defined but not used" warnings.

(hopefully) not with the newer is_hvm_vcpu() which evaluates its
arguments properly.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-28 14:48         ` Wei Liu
  2018-08-28 14:51           ` Andrew Cooper
@ 2018-08-28 14:56           ` Wei Liu
  1 sibling, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-28 14:56 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel

On Tue, Aug 28, 2018 at 03:48:07PM +0100, Wei Liu wrote:
> On Tue, Aug 28, 2018 at 08:36:37AM -0600, Jan Beulich wrote:
> > >>> On 28.08.18 at 15:19, <wei.liu2@citrix.com> wrote:
> > > On Tue, Aug 28, 2018 at 05:44:51AM -0600, Jan Beulich wrote:
> > >> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > >> > Move the file to x86 common code and change its name to emul-i8254.c.
> > >> > 
> > >> > Put HVM only code under CONFIG_HVM or is_hvm_domain.
> > >> > 
> > >> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > >> > ---
> > >> > v2: move the whole file.
> > >> > ---
> > >> >  xen/arch/x86/Makefile     |   1 +-
> > >> >  xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
> > >> >  xen/arch/x86/hvm/Makefile |   1 +-
> > >> >  xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
> > >> >  4 files changed, 610 insertions(+), 598 deletions(-)
> > >> >  create mode 100644 xen/arch/x86/emul-i8254.c
> > >> >  delete mode 100644 xen/arch/x86/hvm/i8254.c
> > >> 
> > >> On the assumption that the changes to the file are only CONFIG_HVM
> > >> additions
> > > 
> > > No only that. There are a few is_hvm_domain calls as well.
> > > 
> > >> Acked-by: Jan Beulich <jbeulich@suse.com>
> > > 
> > > Does this still stand?
> > 
> > Yes, albeit looking at the full diff of the files I'm then a little
> > puzzled about is_hvm_domain() uses: Why does pit_load_count()
> > need an #ifdef added at all, with the is_hvm_vcpu() check
> > right before it?
> 
> Because if I don't do that we get "defined but not used" warnings.

This is nonsense. I misread the function name.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-28 14:51           ` Andrew Cooper
@ 2018-08-28 14:58             ` Wei Liu
  2018-08-28 15:04               ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-28 14:58 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: xen-devel, Wei Liu, Jan Beulich

On Tue, Aug 28, 2018 at 03:51:51PM +0100, Andrew Cooper wrote:
> On 28/08/18 15:48, Wei Liu wrote:
> > On Tue, Aug 28, 2018 at 08:36:37AM -0600, Jan Beulich wrote:
> >>>>> On 28.08.18 at 15:19, <wei.liu2@citrix.com> wrote:
> >>> On Tue, Aug 28, 2018 at 05:44:51AM -0600, Jan Beulich wrote:
> >>>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> >>>>> Move the file to x86 common code and change its name to emul-i8254.c.
> >>>>>
> >>>>> Put HVM only code under CONFIG_HVM or is_hvm_domain.
> >>>>>
> >>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >>>>> ---
> >>>>> v2: move the whole file.
> >>>>> ---
> >>>>>  xen/arch/x86/Makefile     |   1 +-
> >>>>>  xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
> >>>>>  xen/arch/x86/hvm/Makefile |   1 +-
> >>>>>  xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
> >>>>>  4 files changed, 610 insertions(+), 598 deletions(-)
> >>>>>  create mode 100644 xen/arch/x86/emul-i8254.c
> >>>>>  delete mode 100644 xen/arch/x86/hvm/i8254.c
> >>>> On the assumption that the changes to the file are only CONFIG_HVM
> >>>> additions
> >>> No only that. There are a few is_hvm_domain calls as well.
> >>>
> >>>> Acked-by: Jan Beulich <jbeulich@suse.com>
> >>> Does this still stand?
> >> Yes, albeit looking at the full diff of the files I'm then a little
> >> puzzled about is_hvm_domain() uses: Why does pit_load_count()
> >> need an #ifdef added at all, with the is_hvm_vcpu() check
> >> right before it?
> > Because if I don't do that we get "defined but not used" warnings.
> 
> (hopefully) not with the newer is_hvm_vcpu() which evaluates its
> arguments properly.

The real reason is I put pit_time_fired under CONFIG_HVM because it is
only used as a HVM only callback -- passed as a parameter to
create_periodic_time.

If I remove CONFIG_HVM around pit_time_fired, I can remove CONFIG_HVM in
pit_load_count.  Let me know if you prefer this.

Wei.


> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-28 14:58             ` Wei Liu
@ 2018-08-28 15:04               ` Jan Beulich
  2018-08-28 15:17                 ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-28 15:04 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, xen-devel

>>> On 28.08.18 at 16:58, <wei.liu2@citrix.com> wrote:
> On Tue, Aug 28, 2018 at 03:51:51PM +0100, Andrew Cooper wrote:
>> On 28/08/18 15:48, Wei Liu wrote:
>> > On Tue, Aug 28, 2018 at 08:36:37AM -0600, Jan Beulich wrote:
>> >>>>> On 28.08.18 at 15:19, <wei.liu2@citrix.com> wrote:
>> >>> On Tue, Aug 28, 2018 at 05:44:51AM -0600, Jan Beulich wrote:
>> >>>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>> >>>>> Move the file to x86 common code and change its name to emul-i8254.c.
>> >>>>>
>> >>>>> Put HVM only code under CONFIG_HVM or is_hvm_domain.
>> >>>>>
>> >>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> >>>>> ---
>> >>>>> v2: move the whole file.
>> >>>>> ---
>> >>>>>  xen/arch/x86/Makefile     |   1 +-
>> >>>>>  xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
>> >>>>>  xen/arch/x86/hvm/Makefile |   1 +-
>> >>>>>  xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
>> >>>>>  4 files changed, 610 insertions(+), 598 deletions(-)
>> >>>>>  create mode 100644 xen/arch/x86/emul-i8254.c
>> >>>>>  delete mode 100644 xen/arch/x86/hvm/i8254.c
>> >>>> On the assumption that the changes to the file are only CONFIG_HVM
>> >>>> additions
>> >>> No only that. There are a few is_hvm_domain calls as well.
>> >>>
>> >>>> Acked-by: Jan Beulich <jbeulich@suse.com>
>> >>> Does this still stand?
>> >> Yes, albeit looking at the full diff of the files I'm then a little
>> >> puzzled about is_hvm_domain() uses: Why does pit_load_count()
>> >> need an #ifdef added at all, with the is_hvm_vcpu() check
>> >> right before it?
>> > Because if I don't do that we get "defined but not used" warnings.
>> 
>> (hopefully) not with the newer is_hvm_vcpu() which evaluates its
>> arguments properly.
> 
> The real reason is I put pit_time_fired under CONFIG_HVM because it is
> only used as a HVM only callback -- passed as a parameter to
> create_periodic_time.
> 
> If I remove CONFIG_HVM around pit_time_fired, I can remove CONFIG_HVM in
> pit_load_count.  Let me know if you prefer this.

Oh, I see. I'd prefer this, yes, but I'm unconvinced DCE would
eliminate pit_time_fired() in that case. If you find it does, I think
that would be better indeed (less #ifdef clutter).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM
  2018-08-28 15:04               ` Jan Beulich
@ 2018-08-28 15:17                 ` Wei Liu
  0 siblings, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-28 15:17 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel

On Tue, Aug 28, 2018 at 09:04:24AM -0600, Jan Beulich wrote:
> >>> On 28.08.18 at 16:58, <wei.liu2@citrix.com> wrote:
> > On Tue, Aug 28, 2018 at 03:51:51PM +0100, Andrew Cooper wrote:
> >> On 28/08/18 15:48, Wei Liu wrote:
> >> > On Tue, Aug 28, 2018 at 08:36:37AM -0600, Jan Beulich wrote:
> >> >>>>> On 28.08.18 at 15:19, <wei.liu2@citrix.com> wrote:
> >> >>> On Tue, Aug 28, 2018 at 05:44:51AM -0600, Jan Beulich wrote:
> >> >>>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> >> >>>>> Move the file to x86 common code and change its name to emul-i8254.c.
> >> >>>>>
> >> >>>>> Put HVM only code under CONFIG_HVM or is_hvm_domain.
> >> >>>>>
> >> >>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >> >>>>> ---
> >> >>>>> v2: move the whole file.
> >> >>>>> ---
> >> >>>>>  xen/arch/x86/Makefile     |   1 +-
> >> >>>>>  xen/arch/x86/emul-i8254.c | 609 +++++++++++++++++++++++++++++++++++++++-
> >> >>>>>  xen/arch/x86/hvm/Makefile |   1 +-
> >> >>>>>  xen/arch/x86/hvm/i8254.c  | 597 +--------------------------------------
> >> >>>>>  4 files changed, 610 insertions(+), 598 deletions(-)
> >> >>>>>  create mode 100644 xen/arch/x86/emul-i8254.c
> >> >>>>>  delete mode 100644 xen/arch/x86/hvm/i8254.c
> >> >>>> On the assumption that the changes to the file are only CONFIG_HVM
> >> >>>> additions
> >> >>> No only that. There are a few is_hvm_domain calls as well.
> >> >>>
> >> >>>> Acked-by: Jan Beulich <jbeulich@suse.com>
> >> >>> Does this still stand?
> >> >> Yes, albeit looking at the full diff of the files I'm then a little
> >> >> puzzled about is_hvm_domain() uses: Why does pit_load_count()
> >> >> need an #ifdef added at all, with the is_hvm_vcpu() check
> >> >> right before it?
> >> > Because if I don't do that we get "defined but not used" warnings.
> >> 
> >> (hopefully) not with the newer is_hvm_vcpu() which evaluates its
> >> arguments properly.
> > 
> > The real reason is I put pit_time_fired under CONFIG_HVM because it is
> > only used as a HVM only callback -- passed as a parameter to
> > create_periodic_time.
> > 
> > If I remove CONFIG_HVM around pit_time_fired, I can remove CONFIG_HVM in
> > pit_load_count.  Let me know if you prefer this.
> 
> Oh, I see. I'd prefer this, yes, but I'm unconvinced DCE would
> eliminate pit_time_fired() in that case. If you find it does, I think
> that would be better indeed (less #ifdef clutter).

At least for gcc 6.3 DCE does eliminate pit_time_fired. I will remove
the two CONFIG_HVMs in the next iteration.

Wei.

> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI
  2018-08-28  9:08       ` Jan Beulich
@ 2018-08-29 16:23         ` Wei Liu
  0 siblings, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-29 16:23 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel

On Tue, Aug 28, 2018 at 03:08:24AM -0600, Jan Beulich wrote:
> >>> On 28.08.18 at 10:45, <wei.liu2@citrix.com> wrote:
> > On Mon, Aug 27, 2018 at 08:29:20AM -0600, Jan Beulich wrote:
> >> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> >> > --- a/xen/arch/x86/physdev.c
> >> > +++ b/xen/arch/x86/physdev.c
> >> > @@ -557,6 +557,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> >> >  
> >> >          ret = pci_mmcfg_reserved(info.address, info.segment,
> >> >                                   info.start_bus, info.end_bus, info.flags);
> >> > +#ifdef CONFIG_HAS_VPCI
> >> >          if ( !ret && has_vpci(currd) )
> >> >          {
> >> >              /*
> >> > @@ -567,6 +568,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> >> >                                                info.start_bus, info.end_bus,
> >> >                                                info.segment);
> >> >          }
> >> > +#endif
> >> 
> >> Perhaps better to make has_vpci() evaluate to false in that case,
> >> and once again rely on DCE?
> > 
> > But then that goes back to your previous argument that it creates
> > disconnection between emulation_flags_ok and has_*. If we want to change
> > has_vpci I would also need to change emulation_flags_ok. Is that what
> > you prefer?
> 
> Hmm, I see. Utilizing DCE here seems pretty desirable. Perhaps
> emulation_flags_ok() should be switched to use derived constants
> rather than the raw public interface ones. The HVM-only ones
> then would simply become constant zero when !HVM, allowing
> emulation_flags_ok() as well as the has_*() macros to be left alone
> and DCE still be utilized.

I have written a new patch to introduce a set of internal flags. It did
work as expected.

Also dropped this patch from the queue.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 11/23] x86: XENMEM_resource_ioreq_server is HVM only
  2018-08-27 15:13   ` Jan Beulich
@ 2018-08-29 16:28     ` Wei Liu
  0 siblings, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-29 16:28 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel

On Mon, Aug 27, 2018 at 09:13:04AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -4376,12 +4376,17 @@ int arch_acquire_resource(struct domain *d, unsigned int type,
> >  
> >      switch ( type )
> >      {
> > +#ifdef CONFIG_HVM
> >      case XENMEM_resource_ioreq_server:
> >      {
> >          ioservid_t ioservid = id;
> >          unsigned int i;
> >  
> >          rc = -EINVAL;
> > +        if ( !is_hvm_domain(d) )
> > +            break;
> > +
> > +        rc = -EINVAL;
> >          if ( id != (unsigned int)ioservid )
> >              break;
> 
> Since this is the only caller of hvm_get_ioreq_server_frame(),
> adding an is_hvm_domain() check here means the one inside
> the function becomes redundant - it should be dropped or
> converted to an ASSERT() imo. Furthermore if the check is to
> remain here, please drop the redundant assignment of rc.

A general principle I have been sticking to is the common code should
make sure guest type specific function should only be called when
necessary by using is_hvm/pv_*. Restructuring the code like that makes
DCE work effectively.

That means a lot of the checks in hvm_/pv_ functions should lifted out
and turned into ASSERT.

For this patch, is_hvm_domain in the case branch will remain and the one
in hvm_get_ioreq_server_frame will be turned into ASSERT.

Wei.

> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 12/23] x86: monitor.o is currently HVM only
  2018-08-27 15:18   ` Jan Beulich
  2018-08-27 15:23     ` Razvan Cojocaru
@ 2018-08-29 16:42     ` Wei Liu
  2018-08-29 17:43       ` Tamas K Lengyel
  1 sibling, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-29 16:42 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Andrew Cooper, Tamas K Lengyel, Wei Liu, Razvan Cojocaru, xen-devel

On Mon, Aug 27, 2018 at 09:18:29AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > There has been plan to make PV work, but it is not yet there.  Provide
> > stubs to make it build with !CONFIG_HVM.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  xen/arch/x86/Makefile         |  2 +-
> >  xen/include/asm-x86/monitor.h | 14 ++++++++++++++
> >  2 files changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > index 9b9b63a..43f9189 100644
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -45,7 +45,7 @@ obj-y += microcode_amd.o
> >  obj-y += microcode_intel.o
> >  obj-y += microcode.o
> >  obj-y += mm.o x86_64/mm.o
> > -obj-y += monitor.o
> > +obj-$(CONFIG_HVM) += monitor.o
> >  obj-y += mpparse.o
> >  obj-y += nmi.o
> >  obj-y += numa.o
> > diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> > index 4988903..09f7f8a 100644
> > --- a/xen/include/asm-x86/monitor.h
> > +++ b/xen/include/asm-x86/monitor.h
> > @@ -99,10 +99,24 @@ static inline uint32_t 
> > arch_monitor_get_capabilities(struct domain *d)
> >  int arch_monitor_domctl_event(struct domain *d,
> >                                struct xen_domctl_monitor_op *mop);
> >  
> > +#ifdef CONFIG_HVM
> > +
> >  int arch_monitor_init_domain(struct domain *d);
> >  
> >  void arch_monitor_cleanup_domain(struct domain *d);
> >  
> > +#else
> > +
> > +static inline int arch_monitor_init_domain(struct domain *d)
> > +{
> > +    return 0;
> > +}
> > +
> > +static inline void arch_monitor_cleanup_domain(struct domain *d)
> > +{}
> > +
> > +#endif
> 
> Wouldn't the entire XEN_DOMCTL_VM_EVENT_OP_MONITOR case
> in vm_event_domctl() then better be put in an #ifdef instead?

I didn't do that because that was common to both ARM and x86.

But now looking at the ARM counterpart, it is not supported either. When
it is eventually supported on ARM, it will be likely to be dependent on
CONFIG_HVM anyway. So I think I can put XEN_DOMCTL_VM_EVENT_OP_MONITOR
under CONFIG_HVM.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 21/23] x86: expose CONFIG_HVM
  2018-08-28 13:33       ` Jan Beulich
@ 2018-08-29 16:56         ` Andrew Cooper
  2018-08-30  6:21           ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Andrew Cooper @ 2018-08-29 16:56 UTC (permalink / raw)
  To: Jan Beulich; +Cc: xen-devel, Wei Liu

On 28/08/18 14:33, Jan Beulich wrote:
>>>> On 28.08.18 at 14:14, <andrew.cooper3@citrix.com> wrote:
>> On 28/08/18 12:50, Jan Beulich wrote:
>>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>>>> --- a/xen/arch/x86/Kconfig
>>>> +++ b/xen/arch/x86/Kconfig
>>>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>>>  
>>>>  config HVM
>>>>  	def_bool y
>>>> +	prompt "HVM / PVH support"
>>>> +	---help---
>>>> +	  Interfaces to support HVM and PVH guests.
>> This definitely needs more than a single line...
>>
>>>> +
>>>> +	  If unsure, say Y.
>>>> +
>>>>  
>>>>  config SHADOW_PAGING
>>> No double blank lines please.
>>>
>>> My previously voiced reservations wrt the shim remain. I continue
>>> to disagree with Andrew that the symbol needs to be visible in a
>>> shim-only config, and I continue to demand as a minimum that the
>>> default here be N in that case if the symbol really is to remain visible.
>> Conditionally influencing the default is fine.  Hiding the symbol is not.
>>
>> To be very very clear, I will nack/revert any patch which tries to
>> insert a dependency here.  I find your reasoning to be wrong, and
>> sufficiently short sighted and detrimental to users, that I'm not going
>> to let the patch in.
> Since iirc you didn't respond to my most recent comment on v1 here,
> I would have very much hoped you'd explain your position a little
> better than just claiming that the symbol becoming invisible with a
> dependency added is a bad thing. I'm certainly open to (good)
> arguments, but I'm not accepting a plain statement without proper
> explanation.

I'm not sure how to put this any more clearly.

Our users cannot read *your* mind when they are trying to use `make
menuconfig`.

Since our users are not experts in Xen, the lack of an HVM option is
going to cause confusion and questions to mailing lists/IRC, rather than
the realisation that (obviously?) they needed to disable
PV_SHIM_EXCLUSIVE first.

It does not matter if people accidentally select both options, because
they'll end up with the same build as exists today, and a fractionally
larger than necessary hypervisor.  It does matter that people can
sensibly navigate the menu without unnecessary confusion.

Finally (and minor in comparison), from the point of view of keeping our
interfaces clean, we'll want Randconfig to occasionally test with both
of them enabled.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 12/23] x86: monitor.o is currently HVM only
  2018-08-29 16:42     ` Wei Liu
@ 2018-08-29 17:43       ` Tamas K Lengyel
  2018-08-29 18:09         ` Razvan Cojocaru
  0 siblings, 1 reply; 97+ messages in thread
From: Tamas K Lengyel @ 2018-08-29 17:43 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, Razvan Cojocaru, Jan Beulich, Xen-devel

On Wed, Aug 29, 2018 at 10:42 AM Wei Liu <wei.liu2@citrix.com> wrote:
>
> On Mon, Aug 27, 2018 at 09:18:29AM -0600, Jan Beulich wrote:
> > >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > > There has been plan to make PV work, but it is not yet there.  Provide
> > > stubs to make it build with !CONFIG_HVM.
> > >
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > >  xen/arch/x86/Makefile         |  2 +-
> > >  xen/include/asm-x86/monitor.h | 14 ++++++++++++++
> > >  2 files changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > > index 9b9b63a..43f9189 100644
> > > --- a/xen/arch/x86/Makefile
> > > +++ b/xen/arch/x86/Makefile
> > > @@ -45,7 +45,7 @@ obj-y += microcode_amd.o
> > >  obj-y += microcode_intel.o
> > >  obj-y += microcode.o
> > >  obj-y += mm.o x86_64/mm.o
> > > -obj-y += monitor.o
> > > +obj-$(CONFIG_HVM) += monitor.o
> > >  obj-y += mpparse.o
> > >  obj-y += nmi.o
> > >  obj-y += numa.o
> > > diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> > > index 4988903..09f7f8a 100644
> > > --- a/xen/include/asm-x86/monitor.h
> > > +++ b/xen/include/asm-x86/monitor.h
> > > @@ -99,10 +99,24 @@ static inline uint32_t
> > > arch_monitor_get_capabilities(struct domain *d)
> > >  int arch_monitor_domctl_event(struct domain *d,
> > >                                struct xen_domctl_monitor_op *mop);
> > >
> > > +#ifdef CONFIG_HVM
> > > +
> > >  int arch_monitor_init_domain(struct domain *d);
> > >
> > >  void arch_monitor_cleanup_domain(struct domain *d);
> > >
> > > +#else
> > > +
> > > +static inline int arch_monitor_init_domain(struct domain *d)
> > > +{
> > > +    return 0;
> > > +}
> > > +
> > > +static inline void arch_monitor_cleanup_domain(struct domain *d)
> > > +{}
> > > +
> > > +#endif
> >
> > Wouldn't the entire XEN_DOMCTL_VM_EVENT_OP_MONITOR case
> > in vm_event_domctl() then better be put in an #ifdef instead?
>
> I didn't do that because that was common to both ARM and x86.
>
> But now looking at the ARM counterpart, it is not supported either. When
> it is eventually supported on ARM, it will be likely to be dependent on
> CONFIG_HVM anyway. So I think I can put XEN_DOMCTL_VM_EVENT_OP_MONITOR
> under CONFIG_HVM.
>

It is not that it is not supported, it is that it's not (yet) needed.
I think it would be better to have ifdef CONFIG_HVM only in code
that's reached on x86 and not common ones.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 12/23] x86: monitor.o is currently HVM only
  2018-08-29 17:43       ` Tamas K Lengyel
@ 2018-08-29 18:09         ` Razvan Cojocaru
  2018-08-30  7:14           ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Razvan Cojocaru @ 2018-08-29 18:09 UTC (permalink / raw)
  To: Tamas K Lengyel, Wei Liu; +Cc: Andrew Cooper, Jan Beulich, Xen-devel

On 8/29/18 8:43 PM, Tamas K Lengyel wrote:
> On Wed, Aug 29, 2018 at 10:42 AM Wei Liu <wei.liu2@citrix.com> wrote:
>>
>> On Mon, Aug 27, 2018 at 09:18:29AM -0600, Jan Beulich wrote:
>>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>>>> There has been plan to make PV work, but it is not yet there.  Provide
>>>> stubs to make it build with !CONFIG_HVM.
>>>>
>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>>> ---
>>>>  xen/arch/x86/Makefile         |  2 +-
>>>>  xen/include/asm-x86/monitor.h | 14 ++++++++++++++
>>>>  2 files changed, 15 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
>>>> index 9b9b63a..43f9189 100644
>>>> --- a/xen/arch/x86/Makefile
>>>> +++ b/xen/arch/x86/Makefile
>>>> @@ -45,7 +45,7 @@ obj-y += microcode_amd.o
>>>>  obj-y += microcode_intel.o
>>>>  obj-y += microcode.o
>>>>  obj-y += mm.o x86_64/mm.o
>>>> -obj-y += monitor.o
>>>> +obj-$(CONFIG_HVM) += monitor.o
>>>>  obj-y += mpparse.o
>>>>  obj-y += nmi.o
>>>>  obj-y += numa.o
>>>> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
>>>> index 4988903..09f7f8a 100644
>>>> --- a/xen/include/asm-x86/monitor.h
>>>> +++ b/xen/include/asm-x86/monitor.h
>>>> @@ -99,10 +99,24 @@ static inline uint32_t
>>>> arch_monitor_get_capabilities(struct domain *d)
>>>>  int arch_monitor_domctl_event(struct domain *d,
>>>>                                struct xen_domctl_monitor_op *mop);
>>>>
>>>> +#ifdef CONFIG_HVM
>>>> +
>>>>  int arch_monitor_init_domain(struct domain *d);
>>>>
>>>>  void arch_monitor_cleanup_domain(struct domain *d);
>>>>
>>>> +#else
>>>> +
>>>> +static inline int arch_monitor_init_domain(struct domain *d)
>>>> +{
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static inline void arch_monitor_cleanup_domain(struct domain *d)
>>>> +{}
>>>> +
>>>> +#endif
>>>
>>> Wouldn't the entire XEN_DOMCTL_VM_EVENT_OP_MONITOR case
>>> in vm_event_domctl() then better be put in an #ifdef instead?
>>
>> I didn't do that because that was common to both ARM and x86.
>>
>> But now looking at the ARM counterpart, it is not supported either. When
>> it is eventually supported on ARM, it will be likely to be dependent on
>> CONFIG_HVM anyway. So I think I can put XEN_DOMCTL_VM_EVENT_OP_MONITOR
>> under CONFIG_HVM.
>>
> 
> It is not that it is not supported, it is that it's not (yet) needed.
> I think it would be better to have ifdef CONFIG_HVM only in code
> that's reached on x86 and not common ones.

FWIW, I agree with Tamas here.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 01/23] x86: change name of parameter for various invlpg functions
  2018-08-26 12:19 ` [PATCH v2 01/23] x86: change name of parameter for various invlpg functions Wei Liu
  2018-08-27 13:49   ` Boris Ostrovsky
  2018-08-27 14:20   ` Jan Beulich
@ 2018-08-30  1:26   ` Tian, Kevin
  2018-09-03 13:46   ` Wei Liu
  3 siblings, 0 replies; 97+ messages in thread
From: Tian, Kevin @ 2018-08-30  1:26 UTC (permalink / raw)
  To: Wei Liu, xen-devel
  Cc: Nakajima, Jun, George Dunlap, Andrew Cooper, Tim Deegan,
	Jan Beulich, Boris Ostrovsky, Brian Woods, Suravee Suthikulpanit

> From: Wei Liu
> Sent: Sunday, August 26, 2018 8:20 PM
> 
> They all incorrectly named a parameter virtual address while it should
> have been linear address.
> 
> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 10/23] x86/pt: split out HVM functions from vtd.c
  2018-08-26 12:19 ` [PATCH v2 10/23] x86/pt: split out HVM functions from vtd.c Wei Liu
@ 2018-08-30  1:29   ` Tian, Kevin
  0 siblings, 0 replies; 97+ messages in thread
From: Tian, Kevin @ 2018-08-30  1:29 UTC (permalink / raw)
  To: Wei Liu, xen-devel

> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Sunday, August 26, 2018 8:20 PM
> 
> Functions are moved to hvm.c. Reorder makefile items while at it.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Kevin Tian <kevin.tian@intel.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 09/23] x86/pt: make it build with !CONFIG_HVM
  2018-08-26 12:19 ` [PATCH v2 09/23] x86/pt: make it build with !CONFIG_HVM Wei Liu
  2018-08-27 15:07   ` Jan Beulich
@ 2018-08-30  1:29   ` Tian, Kevin
  1 sibling, 0 replies; 97+ messages in thread
From: Tian, Kevin @ 2018-08-30  1:29 UTC (permalink / raw)
  To: Wei Liu, xen-devel
  Cc: Andrew Cooper, Paul Durrant, Nakajima, Jun, Jan Beulich

> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Sunday, August 26, 2018 8:20 PM
> 
> This requires providing stubs for a few functions which are part of
> HVM code.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 21/23] x86: expose CONFIG_HVM
  2018-08-29 16:56         ` Andrew Cooper
@ 2018-08-30  6:21           ` Jan Beulich
  2018-08-30  6:57             ` Juergen Gross
  2018-08-31 20:09             ` Andrew Cooper
  0 siblings, 2 replies; 97+ messages in thread
From: Jan Beulich @ 2018-08-30  6:21 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Ian Jackson,
	Doug Goldstein, Tim Deegan, Julien Grall, xen-devel

>>> On 29.08.18 at 18:56, <andrew.cooper3@citrix.com> wrote:
> On 28/08/18 14:33, Jan Beulich wrote:
>>>>> On 28.08.18 at 14:14, <andrew.cooper3@citrix.com> wrote:
>>> On 28/08/18 12:50, Jan Beulich wrote:
>>>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>>>>> --- a/xen/arch/x86/Kconfig
>>>>> +++ b/xen/arch/x86/Kconfig
>>>>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>>>>  
>>>>>  config HVM
>>>>>  	def_bool y
>>>>> +	prompt "HVM / PVH support"
>>>>> +	---help---
>>>>> +	  Interfaces to support HVM and PVH guests.
>>> This definitely needs more than a single line...
>>>
>>>>> +
>>>>> +	  If unsure, say Y.
>>>>> +
>>>>>  
>>>>>  config SHADOW_PAGING
>>>> No double blank lines please.
>>>>
>>>> My previously voiced reservations wrt the shim remain. I continue
>>>> to disagree with Andrew that the symbol needs to be visible in a
>>>> shim-only config, and I continue to demand as a minimum that the
>>>> default here be N in that case if the symbol really is to remain visible.
>>> Conditionally influencing the default is fine.  Hiding the symbol is not.
>>>
>>> To be very very clear, I will nack/revert any patch which tries to
>>> insert a dependency here.  I find your reasoning to be wrong, and
>>> sufficiently short sighted and detrimental to users, that I'm not going
>>> to let the patch in.
>> Since iirc you didn't respond to my most recent comment on v1 here,
>> I would have very much hoped you'd explain your position a little
>> better than just claiming that the symbol becoming invisible with a
>> dependency added is a bad thing. I'm certainly open to (good)
>> arguments, but I'm not accepting a plain statement without proper
>> explanation.
> 
> I'm not sure how to put this any more clearly.
> 
> Our users cannot read *your* mind when they are trying to use `make
> menuconfig`.
> 
> Since our users are not experts in Xen, the lack of an HVM option is
> going to cause confusion and questions to mailing lists/IRC, rather than
> the realisation that (obviously?) they needed to disable
> PV_SHIM_EXCLUSIVE first.

But that's an argument to remove support for "depends on" altogether
from the kconfig sources. I'm not buying this as an argument. Option
combinations that make no sense should not be permitted, _in the very
interest of users who are no experts in Xen_.

Furthermore I can only express my personal feelings for "make
menuconfig" and alike - just don't use it.

> Finally (and minor in comparison), from the point of view of keeping our
> interfaces clean, we'll want Randconfig to occasionally test with both
> of them enabled.

Why, when the combination doesn't make sense?

Anyway - I'm extending the Cc list to get the more general underlying
question resolved. To those who haven't followed the discussion from
the beginning: The question is whether senseless combinations of
Kconfig options should be permitted, or whether instead "depends on"
is a reasonable thing to use in such cases to prevent their (combined)
selection.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 21/23] x86: expose CONFIG_HVM
  2018-08-30  6:21           ` Jan Beulich
@ 2018-08-30  6:57             ` Juergen Gross
  2018-08-31 20:09             ` Andrew Cooper
  1 sibling, 0 replies; 97+ messages in thread
From: Juergen Gross @ 2018-08-30  6:57 UTC (permalink / raw)
  To: Jan Beulich, Andrew Cooper
  Cc: Stefano Stabellini, Wei Liu, George Dunlap, Doug Goldstein,
	Ian Jackson, Tim Deegan, Julien Grall, xen-devel

On 30/08/18 08:21, Jan Beulich wrote:
>>>> On 29.08.18 at 18:56, <andrew.cooper3@citrix.com> wrote:
>> On 28/08/18 14:33, Jan Beulich wrote:
>>>>>> On 28.08.18 at 14:14, <andrew.cooper3@citrix.com> wrote:
>>>> On 28/08/18 12:50, Jan Beulich wrote:
>>>>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>>>>>> --- a/xen/arch/x86/Kconfig
>>>>>> +++ b/xen/arch/x86/Kconfig
>>>>>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>>>>>  
>>>>>>  config HVM
>>>>>>  	def_bool y
>>>>>> +	prompt "HVM / PVH support"
>>>>>> +	---help---
>>>>>> +	  Interfaces to support HVM and PVH guests.
>>>> This definitely needs more than a single line...
>>>>
>>>>>> +
>>>>>> +	  If unsure, say Y.
>>>>>> +
>>>>>>  
>>>>>>  config SHADOW_PAGING
>>>>> No double blank lines please.
>>>>>
>>>>> My previously voiced reservations wrt the shim remain. I continue
>>>>> to disagree with Andrew that the symbol needs to be visible in a
>>>>> shim-only config, and I continue to demand as a minimum that the
>>>>> default here be N in that case if the symbol really is to remain visible.
>>>> Conditionally influencing the default is fine.  Hiding the symbol is not.
>>>>
>>>> To be very very clear, I will nack/revert any patch which tries to
>>>> insert a dependency here.  I find your reasoning to be wrong, and
>>>> sufficiently short sighted and detrimental to users, that I'm not going
>>>> to let the patch in.
>>> Since iirc you didn't respond to my most recent comment on v1 here,
>>> I would have very much hoped you'd explain your position a little
>>> better than just claiming that the symbol becoming invisible with a
>>> dependency added is a bad thing. I'm certainly open to (good)
>>> arguments, but I'm not accepting a plain statement without proper
>>> explanation.
>>
>> I'm not sure how to put this any more clearly.
>>
>> Our users cannot read *your* mind when they are trying to use `make
>> menuconfig`.
>>
>> Since our users are not experts in Xen, the lack of an HVM option is
>> going to cause confusion and questions to mailing lists/IRC, rather than
>> the realisation that (obviously?) they needed to disable
>> PV_SHIM_EXCLUSIVE first.
> 
> But that's an argument to remove support for "depends on" altogether
> from the kconfig sources. I'm not buying this as an argument. Option
> combinations that make no sense should not be permitted, _in the very
> interest of users who are no experts in Xen_.
> 
> Furthermore I can only express my personal feelings for "make
> menuconfig" and alike - just don't use it.
> 
>> Finally (and minor in comparison), from the point of view of keeping our
>> interfaces clean, we'll want Randconfig to occasionally test with both
>> of them enabled.
> 
> Why, when the combination doesn't make sense?
> 
> Anyway - I'm extending the Cc list to get the more general underlying
> question resolved. To those who haven't followed the discussion from
> the beginning: The question is whether senseless combinations of
> Kconfig options should be permitted, or whether instead "depends on"
> is a reasonable thing to use in such cases to prevent their (combined)
> selection.

I'm on Jan's side.

Someone familiar with Kconfig for the Linux kernel will expect exactly
this behavior: a symbol is only visible when it makes sense to select
it.

In case you are missing the symbol you can still search for it in
menuconfig and the dependencies will be displayed.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 12/23] x86: monitor.o is currently HVM only
  2018-08-29 18:09         ` Razvan Cojocaru
@ 2018-08-30  7:14           ` Wei Liu
  0 siblings, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-08-30  7:14 UTC (permalink / raw)
  To: Razvan Cojocaru
  Cc: Andrew Cooper, Tamas K Lengyel, Wei Liu, Jan Beulich, Xen-devel

On Wed, Aug 29, 2018 at 09:09:03PM +0300, Razvan Cojocaru wrote:
> On 8/29/18 8:43 PM, Tamas K Lengyel wrote:
> > On Wed, Aug 29, 2018 at 10:42 AM Wei Liu <wei.liu2@citrix.com> wrote:
> >>
> >> On Mon, Aug 27, 2018 at 09:18:29AM -0600, Jan Beulich wrote:
> >>>>>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> >>>> There has been plan to make PV work, but it is not yet there.  Provide
> >>>> stubs to make it build with !CONFIG_HVM.
> >>>>
> >>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >>>> ---
> >>>>  xen/arch/x86/Makefile         |  2 +-
> >>>>  xen/include/asm-x86/monitor.h | 14 ++++++++++++++
> >>>>  2 files changed, 15 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> >>>> index 9b9b63a..43f9189 100644
> >>>> --- a/xen/arch/x86/Makefile
> >>>> +++ b/xen/arch/x86/Makefile
> >>>> @@ -45,7 +45,7 @@ obj-y += microcode_amd.o
> >>>>  obj-y += microcode_intel.o
> >>>>  obj-y += microcode.o
> >>>>  obj-y += mm.o x86_64/mm.o
> >>>> -obj-y += monitor.o
> >>>> +obj-$(CONFIG_HVM) += monitor.o
> >>>>  obj-y += mpparse.o
> >>>>  obj-y += nmi.o
> >>>>  obj-y += numa.o
> >>>> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> >>>> index 4988903..09f7f8a 100644
> >>>> --- a/xen/include/asm-x86/monitor.h
> >>>> +++ b/xen/include/asm-x86/monitor.h
> >>>> @@ -99,10 +99,24 @@ static inline uint32_t
> >>>> arch_monitor_get_capabilities(struct domain *d)
> >>>>  int arch_monitor_domctl_event(struct domain *d,
> >>>>                                struct xen_domctl_monitor_op *mop);
> >>>>
> >>>> +#ifdef CONFIG_HVM
> >>>> +
> >>>>  int arch_monitor_init_domain(struct domain *d);
> >>>>
> >>>>  void arch_monitor_cleanup_domain(struct domain *d);
> >>>>
> >>>> +#else
> >>>> +
> >>>> +static inline int arch_monitor_init_domain(struct domain *d)
> >>>> +{
> >>>> +    return 0;
> >>>> +}
> >>>> +
> >>>> +static inline void arch_monitor_cleanup_domain(struct domain *d)
> >>>> +{}
> >>>> +
> >>>> +#endif
> >>>
> >>> Wouldn't the entire XEN_DOMCTL_VM_EVENT_OP_MONITOR case
> >>> in vm_event_domctl() then better be put in an #ifdef instead?
> >>
> >> I didn't do that because that was common to both ARM and x86.
> >>
> >> But now looking at the ARM counterpart, it is not supported either. When
> >> it is eventually supported on ARM, it will be likely to be dependent on
> >> CONFIG_HVM anyway. So I think I can put XEN_DOMCTL_VM_EVENT_OP_MONITOR
> >> under CONFIG_HVM.
> >>
> > 
> > It is not that it is not supported, it is that it's not (yet) needed.
> > I think it would be better to have ifdef CONFIG_HVM only in code
> > that's reached on x86 and not common ones.
> 
> FWIW, I agree with Tamas here.

Alright, in that case I will keep this patch, with the style issues
addressed.

Wei.

> 
> 
> Thanks,
> Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM
  2018-08-28 10:50   ` Jan Beulich
@ 2018-08-30  7:42     ` Wei Liu
  2018-08-30  8:35       ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-08-30  7:42 UTC (permalink / raw)
  To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Wei Liu, xen-devel

On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/mm/paging.c
> > +++ b/xen/arch/x86/mm/paging.c
> > @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct vcpu *v)
> >      return paging_get_nestedmode(v);
> >  }
> >  
> > +#ifdef CONFIG_HVM
> >  void paging_update_nestedmode(struct vcpu *v)
> >  {
> >      ASSERT(nestedhvm_enabled(v->domain));
> > @@ -930,6 +931,7 @@ void paging_update_nestedmode(struct vcpu *v)
> >          v->arch.paging.nestedmode = NULL;
> >      hvm_asid_flush_vcpu(v);
> >  }
> > +#endif
> 
> Just a consideration (no objection): Would it be worthwhile to
> introduce CONFIG_NESTED_HVM at the same time (for now hard
> coded to Y, and of course depending on HVM) to avoid having to
> touch all such places a second time later on?

If we plan to make nested hvm configurable in the future, that would be
a worthwhile thing to do; otherwise it is just another concept that
users need to care about, which creates some mental burden.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM
  2018-08-30  7:42     ` Wei Liu
@ 2018-08-30  8:35       ` Jan Beulich
  2018-09-03 14:27         ` Wei Liu
  0 siblings, 1 reply; 97+ messages in thread
From: Jan Beulich @ 2018-08-30  8:35 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: George Dunlap, xen-devel, Wei Liu

>>> On 30.08.18 at 09:42, <wei.liu2@citrix.com> wrote:
> On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
>> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>> > --- a/xen/arch/x86/mm/paging.c
>> > +++ b/xen/arch/x86/mm/paging.c
>> > @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct vcpu 
> *v)
>> >      return paging_get_nestedmode(v);
>> >  }
>> >  
>> > +#ifdef CONFIG_HVM
>> >  void paging_update_nestedmode(struct vcpu *v)
>> >  {
>> >      ASSERT(nestedhvm_enabled(v->domain));
>> > @@ -930,6 +931,7 @@ void paging_update_nestedmode(struct vcpu *v)
>> >          v->arch.paging.nestedmode = NULL;
>> >      hvm_asid_flush_vcpu(v);
>> >  }
>> > +#endif
>> 
>> Just a consideration (no objection): Would it be worthwhile to
>> introduce CONFIG_NESTED_HVM at the same time (for now hard
>> coded to Y, and of course depending on HVM) to avoid having to
>> touch all such places a second time later on?
> 
> If we plan to make nested hvm configurable in the future, that would be
> a worthwhile thing to do; otherwise it is just another concept that
> users need to care about, which creates some mental burden.

Andrew, do you have any opinion / preference either way?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 21/23] x86: expose CONFIG_HVM
  2018-08-30  6:21           ` Jan Beulich
  2018-08-30  6:57             ` Juergen Gross
@ 2018-08-31 20:09             ` Andrew Cooper
  2018-09-03 11:35               ` Jan Beulich
  1 sibling, 1 reply; 97+ messages in thread
From: Andrew Cooper @ 2018-08-31 20:09 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Lars Kurth, Stefano Stabellini, Wei Liu, George Dunlap,
	Ian Jackson, Doug Goldstein, Tim Deegan, Julien Grall, xen-devel

On 30/08/18 07:21, Jan Beulich wrote:
>>>>>> +
>>>>>> +	  If unsure, say Y.
>>>>>> +
>>>>>>  
>>>>>>  config SHADOW_PAGING
>>>>> No double blank lines please.
>>>>>
>>>>> My previously voiced reservations wrt the shim remain. I continue
>>>>> to disagree with Andrew that the symbol needs to be visible in a
>>>>> shim-only config, and I continue to demand as a minimum that the
>>>>> default here be N in that case if the symbol really is to remain visible.
>>>> Conditionally influencing the default is fine.  Hiding the symbol is not.
>>>>
>>>> To be very very clear, I will nack/revert any patch which tries to
>>>> insert a dependency here.  I find your reasoning to be wrong, and
>>>> sufficiently short sighted and detrimental to users, that I'm not going
>>>> to let the patch in.
>>> Since iirc you didn't respond to my most recent comment on v1 here,
>>> I would have very much hoped you'd explain your position a little
>>> better than just claiming that the symbol becoming invisible with a
>>> dependency added is a bad thing. I'm certainly open to (good)
>>> arguments, but I'm not accepting a plain statement without proper
>>> explanation.
>> I'm not sure how to put this any more clearly.
>>
>> Our users cannot read *your* mind when they are trying to use `make
>> menuconfig`.
>>
>> Since our users are not experts in Xen, the lack of an HVM option is
>> going to cause confusion and questions to mailing lists/IRC, rather than
>> the realisation that (obviously?) they needed to disable
>> PV_SHIM_EXCLUSIVE first.
> But that's an argument to remove support for "depends on" altogether
> from the kconfig sources.

Nonsense.  That is not a remotely plausible interpretation of what I said.

Dependences are normal and expected for functionality built on top of
each other.  What makes this easy and logical for people to navigate is
that dependencies are normally a self-contained directed acyclic tree.

In this case, you're adding a link between a leaf at the bottom of the
PV tree which chops off the entire HVM tree, and it is dependences like
this which are confusing for users (who are not experts) to navigate.

If something is going to malfunction (fail to compile/crash on boot/etc)
then a dependency is the correct tool to use.  Having a slightly fat
binary with some unused code is not the same class of problem, and
should not be treated as if they are the same.

>  I'm not buying this as an argument. Option
> combinations that make no sense should not be permitted, _in the very
> interest of users who are no experts in Xen_.

I'll address "makes no sense" below, but as to permitted...

It is impossible to offer people flexibility, and prevent them from
getting into every conceivable problematic scenario.  At some point you
have to trust that they have accepted some responsibility for the
outcome by modifying .config, and they are capable of the elementary
reasoning such as "oh. that didn't work.  perhaps I should undo it".

>
> Furthermore I can only express my personal feelings for "make
> menuconfig" and alike - just don't use it.

You might enjoy/prefer manually editing .config.  You are free and
welcome to do so.

It is naive to presume that everyone else will agree with your choices
and opinions, and especially in this case as menuconfig is by far the
most common way users edit their configuration.  (So much so that I
can't find a tutorial online which uses anything other than menuconfig,
whether for linux or for other projects which have borrowed Kconfig like
we have.)

>
>> Finally (and minor in comparison), from the point of view of keeping our
>> interfaces clean, we'll want Randconfig to occasionally test with both
>> of them enabled.
> Why, when the combination doesn't make sense?

Case in point, "x86: use VMLOAD for PV context switch".

A user wanting to run PVShim most efficiently on an AMD Fam17h (which
has virtual vmload/save support) would enable nested virt and want to
use vmload support.  Such a user would want both
CONFIG_PV_SHIM_EXCLUSIVE and CONFIG_HVM enabled.

> Anyway - I'm extending the Cc list to get the more general underlying
> question resolved. To those who haven't followed the discussion from
> the beginning: The question is whether senseless combinations of
> Kconfig options should be permitted, or whether instead "depends on"
> is a reasonable thing to use in such cases to prevent their (combined)
> selection.

The people whose opinions matter most here are those who build/package
Xen, who are not developers and therefore not experts in how the
hypervisor fits together.

If it turns out that the majority of users disagree with me, then I'll
withdraw my nack, but the reason I'm being such a pain in this regard is
that this thread re-enforces my opinion that your judgement here is
wrong, is actively detrimental to usability (which is far wider than
just developer usability), and that the users will agree with me in this
matter.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 13/23] x86: provide stubs, declarations and macros in hvm.h
  2018-08-26 12:19 ` [PATCH v2 13/23] x86: provide stubs, declarations and macros in hvm.h Wei Liu
  2018-08-27 15:43   ` Jan Beulich
@ 2018-09-03  9:45   ` Paul Durrant
  2018-09-03  9:50     ` Wei Liu
  1 sibling, 1 reply; 97+ messages in thread
From: Paul Durrant @ 2018-09-03  9:45 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf
> Of Wei Liu
> Sent: 26 August 2018 13:20
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Wei Liu
> <wei.liu2@citrix.com>; Jan Beulich <jbeulich@suse.com>
> Subject: [Xen-devel] [PATCH v2 13/23] x86: provide stubs, declarations and
> macros in hvm.h
> 
> Make sure hvm_enabled evaluate to false then provide necessary stubs,
> declarations and macros to make Xen build.
> 
> The is_viridian_domain macro can't be turned into an inline function
> easily,

Why? It's just an is_hvm_domain() and a feature check.

> so instead its caller is modified to avoid unused variable
> warning.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/arch/x86/traps.c          |   4 +-
>  xen/include/asm-x86/hvm/hvm.h | 149
> ++++++++++++++++++++++++++++++++++-
>  2 files changed, 148 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index ddff346..27b9651 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -771,9 +771,9 @@ static void do_trap(struct cpu_user_regs *regs)
>  /* Returns 0 if not handled, and non-0 for success. */
>  int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val)
>  {
> -    struct domain *d = current->domain;
>      /* Optionally shift out of the way of Viridian architectural MSRs. */
> -    uint32_t base = is_viridian_domain(d) ? 0x40000200 : 0x40000000;
> +    uint32_t base = is_viridian_domain(current->domain)
> +        ? 0x40000200 : 0x40000000;
> 

This is a bit ugly so it would be nice to keep it on a single line.

  Paul

>      switch ( idx - base )
>      {
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-
> x86/hvm/hvm.h
> index 9c73cbf..7820586 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -235,7 +235,10 @@ struct hvm_function_table {
>  };
> 
>  extern struct hvm_function_table hvm_funcs;
> -extern bool_t hvm_enabled;
> +
> +#ifdef CONFIG_HVM
> +extern bool hvm_enabled;
> +
>  extern s8 hvm_port80_allowed;
> 
>  extern const struct hvm_function_table *start_svm(void);
> @@ -268,8 +271,8 @@ u64 hvm_get_guest_tsc_fixed(struct vcpu *v, u64
> at_tsc);
>  #define hvm_tsc_scaling_ratio(d) \
>      ((d)->arch.hvm_domain.tsc_scaling_ratio)
> 
> -u64 hvm_scale_tsc(const struct domain *d, u64 tsc);
> -u64 hvm_get_tsc_scaling_ratio(u32 gtsc_khz);
> +uint64_t hvm_scale_tsc(const struct domain *d, uint64_t tsc);
> +uint64_t hvm_get_tsc_scaling_ratio(uint32_t gtsc_khz);
> 
>  void hvm_init_guest_time(struct domain *d);
>  void hvm_set_guest_time(struct vcpu *v, u64 guest_time);
> @@ -675,6 +678,146 @@ unsigned long hvm_cr4_guest_valid_bits(const
> struct domain *d, bool restore);
>          d_->arch.hvm_domain.pi_ops.vcpu_block(v_);          \
>  })
> 
> +#else /* CONFIG_HVM */
> +
> +#define hvm_enabled false
> +
> +static inline int hvm_guest_x86_mode(struct vcpu *v)
> +{
> +    ASSERT_UNREACHABLE();
> +    return -1;
> +}
> +
> +static inline bool hvm_is_singlestep_supported(void)
> +{
> +    ASSERT_UNREACHABLE();
> +    return false;
> +}
> +
> +static inline int vmsi_deliver(
> +    struct domain *d, int vector,
> +    uint8_t dest, uint8_t dest_mode,
> +    uint8_t delivery_mode, uint8_t trig_mode)
> +{
> +    ASSERT_UNREACHABLE();
> +    return -EINVAL;
> +}
> +
> +static inline bool nhvm_vmcx_hap_enabled(struct vcpu *v)
> +{
> +    return false;
> +}
> +
> +static inline bool hvm_hap_supported(void)
> +{
> +    return false;
> +}
> +
> +static inline void hvm_set_info_guest(struct vcpu *v)
> +{
> +    ASSERT_UNREACHABLE();
> +}
> +
> +static inline void hvm_cpuid_policy_changed(struct vcpu *v)
> +{
> +    ASSERT_UNREACHABLE();
> +}
> +
> +static inline void hvm_flush_guest_tlbs(void)
> +{
> +    ASSERT_UNREACHABLE();
> +}
> +
> +static inline void hvm_invlpg(struct vcpu *v, unsigned long linear)
> +{
> +    ASSERT_UNREACHABLE();
> +}
> +
> +static inline int hvm_cpu_up(void)
> +{
> +    return 0;
> +}
> +
> +static inline void hvm_cpu_down(void)
> +{
> +}
> +
> +static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
> +{
> +    ASSERT_UNREACHABLE();
> +    return 0;
> +}
> +
> +static inline void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset,
> +                                      uint64_t at_tsc)
> +{
> +    ASSERT_UNREACHABLE();
> +}
> +
> +static inline void hvm_update_host_cr3(struct vcpu *v)
> +{
> +    ASSERT_UNREACHABLE();
> +}
> +
> +static inline unsigned int hvm_get_cpl(struct vcpu *v)
> +{
> +    ASSERT_UNREACHABLE();
> +    return -1;
> +}
> +
> +static inline int hvm_event_pending(struct vcpu *v)
> +{
> +    return 0;
> +}
> +
> +static inline void hvm_inject_hw_exception(unsigned int vector, int
> errcode)
> +{
> +    ASSERT_UNREACHABLE();
> +}
> +
> +static inline void hvm_update_guest_cr3(struct vcpu *v, bool noflush)
> +{
> +    ASSERT_UNREACHABLE();
> +}
> +
> +#define hvm_long_mode_active(v) (false)
> +#define hvm_pae_enabled(v) (false)
> +#define hvm_get_guest_time(v) (0)
> +#define is_viridian_domain(d) (false)
> +#define has_viridian_time_ref_count(d) (false)
> +#define hvm_tsc_scaling_supported (false)
> +#define hap_has_1gb (false)
> +#define hap_has_2mb (false)
> +
> +#define hvm_paging_enabled(v) (false)
> +#define hvm_nx_enabled(v) (false)
> +#define hvm_wp_enabled(v) (false)
> +#define hvm_smap_enabled(v) (false)
> +#define hvm_smep_enabled(v) (false)
> +#define hvm_pku_enabled(v) (false)
> +
> +#define arch_vcpu_block(v) ((void)v)
> +
> +int hvm_vcpu_initialise(struct vcpu *v);
> +void hvm_vcpu_destroy(struct vcpu *v);
> +int hvm_domain_initialise(struct domain *d);
> +void hvm_domain_destroy(struct domain *d);
> +void hvm_domain_soft_reset(struct domain *d);
> +void hvm_domain_relinquish_resources(struct domain *d);
> +uint64_t hvm_scale_tsc(const struct domain *d, uint64_t tsc);
> +uint64_t hvm_get_tsc_scaling_ratio(uint32_t gtsc_khz);
> +
> +void hvm_get_segment_register(struct vcpu *v, enum x86_segment seg,
> +                              struct segment_register *reg);
> +
> +void hvm_set_rdtsc_exiting(struct domain *d, bool_t enable);
> +void hvm_toggle_singlestep(struct vcpu *v);
> +void hvm_mapped_guest_frames_mark_dirty(struct domain *);
> +void hvm_hypercall_page_initialise(struct domain *d,
> +                                   void *hypercall_page);
> +
> +#endif /* CONFIG_HVM */
> +
>  #endif /* __ASM_X86_HVM_HVM_H__ */
> 
>  /*
> --
> git-series 0.9.1
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 13/23] x86: provide stubs, declarations and macros in hvm.h
  2018-09-03  9:45   ` Paul Durrant
@ 2018-09-03  9:50     ` Wei Liu
  0 siblings, 0 replies; 97+ messages in thread
From: Wei Liu @ 2018-09-03  9:50 UTC (permalink / raw)
  To: Paul Durrant; +Cc: xen-devel, Wei Liu, Jan Beulich, Andrew Cooper

On Mon, Sep 03, 2018 at 10:45:01AM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf
> > Of Wei Liu
> > Sent: 26 August 2018 13:20
> > To: xen-devel@lists.xenproject.org
> > Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Wei Liu
> > <wei.liu2@citrix.com>; Jan Beulich <jbeulich@suse.com>
> > Subject: [Xen-devel] [PATCH v2 13/23] x86: provide stubs, declarations and
> > macros in hvm.h
> > 
> > Make sure hvm_enabled evaluate to false then provide necessary stubs,
> > declarations and macros to make Xen build.
> > 
> > The is_viridian_domain macro can't be turned into an inline function
> > easily,
> 
> Why? It's just an is_hvm_domain() and a feature check.

It is domain.h which includes hvm/domain.h, not the other way around.
When is_viridian_domain is defined, struct domain is not available. If
is_viridian_domain is a function, it will need to know the definition of
struct domain.

Another way to fix this is to move is_viridian_domain to another header
file. I don't know which one would be preferred.

> 
> > so instead its caller is modified to avoid unused variable
> > warning.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  xen/arch/x86/traps.c          |   4 +-
> >  xen/include/asm-x86/hvm/hvm.h | 149
> > ++++++++++++++++++++++++++++++++++-
> >  2 files changed, 148 insertions(+), 5 deletions(-)
> > 
> > diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> > index ddff346..27b9651 100644
> > --- a/xen/arch/x86/traps.c
> > +++ b/xen/arch/x86/traps.c
> > @@ -771,9 +771,9 @@ static void do_trap(struct cpu_user_regs *regs)
> >  /* Returns 0 if not handled, and non-0 for success. */
> >  int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val)
> >  {
> > -    struct domain *d = current->domain;
> >      /* Optionally shift out of the way of Viridian architectural MSRs. */
> > -    uint32_t base = is_viridian_domain(d) ? 0x40000200 : 0x40000000;
> > +    uint32_t base = is_viridian_domain(current->domain)
> > +        ? 0x40000200 : 0x40000000;
> > 
> 
> This is a bit ugly so it would be nice to keep it on a single line.

OK.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 21/23] x86: expose CONFIG_HVM
  2018-08-31 20:09             ` Andrew Cooper
@ 2018-09-03 11:35               ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-09-03 11:35 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Lars Kurth, Stefano Stabellini, Wei Liu, George Dunlap,
	Doug Goldstein, Ian Jackson, Tim Deegan, Julien Grall, xen-devel

>>> On 31.08.18 at 22:09, <andrew.cooper3@citrix.com> wrote:
> On 30/08/18 07:21, Jan Beulich wrote:
>>>>>>> +
>>>>>>> +	  If unsure, say Y.
>>>>>>> +
>>>>>>>  
>>>>>>>  config SHADOW_PAGING
>>>>>> No double blank lines please.
>>>>>>
>>>>>> My previously voiced reservations wrt the shim remain. I continue
>>>>>> to disagree with Andrew that the symbol needs to be visible in a
>>>>>> shim-only config, and I continue to demand as a minimum that the
>>>>>> default here be N in that case if the symbol really is to remain visible.
>>>>> Conditionally influencing the default is fine.  Hiding the symbol is not.
>>>>>
>>>>> To be very very clear, I will nack/revert any patch which tries to
>>>>> insert a dependency here.  I find your reasoning to be wrong, and
>>>>> sufficiently short sighted and detrimental to users, that I'm not going
>>>>> to let the patch in.
>>>> Since iirc you didn't respond to my most recent comment on v1 here,
>>>> I would have very much hoped you'd explain your position a little
>>>> better than just claiming that the symbol becoming invisible with a
>>>> dependency added is a bad thing. I'm certainly open to (good)
>>>> arguments, but I'm not accepting a plain statement without proper
>>>> explanation.
>>> I'm not sure how to put this any more clearly.
>>>
>>> Our users cannot read *your* mind when they are trying to use `make
>>> menuconfig`.
>>>
>>> Since our users are not experts in Xen, the lack of an HVM option is
>>> going to cause confusion and questions to mailing lists/IRC, rather than
>>> the realisation that (obviously?) they needed to disable
>>> PV_SHIM_EXCLUSIVE first.
>> But that's an argument to remove support for "depends on" altogether
>> from the kconfig sources.
> 
> Nonsense.  That is not a remotely plausible interpretation of what I said.
> 
> Dependences are normal and expected for functionality built on top of
> each other.  What makes this easy and logical for people to navigate is
> that dependencies are normally a self-contained directed acyclic tree.
> 
> In this case, you're adding a link between a leaf at the bottom of the
> PV tree which chops off the entire HVM tree, and it is dependences like
> this which are confusing for users (who are not experts) to navigate.
> 
> If something is going to malfunction (fail to compile/crash on boot/etc)
> then a dependency is the correct tool to use.  Having a slightly fat
> binary with some unused code is not the same class of problem, and
> should not be treated as if they are the same.

And you are willing to exclude that no issues will slip in over time,
where shim-exclusive is taken to imply absence of HVM support?
A pretty obvious example could be the simple omission of an
is_{pv,hvm}_...() check somewhere.

>>> Finally (and minor in comparison), from the point of view of keeping our
>>> interfaces clean, we'll want Randconfig to occasionally test with both
>>> of them enabled.
>> Why, when the combination doesn't make sense?
> 
> Case in point, "x86: use VMLOAD for PV context switch".
> 
> A user wanting to run PVShim most efficiently on an AMD Fam17h (which
> has virtual vmload/save support) would enable nested virt and want to
> use vmload support.  Such a user would want both
> CONFIG_PV_SHIM_EXCLUSIVE and CONFIG_HVM enabled.

I doubt this is a suitable example. I have a hard time seeing anyone
wanting to pull in the whole HVM baggage just for this one piece of
optimization.

>> Anyway - I'm extending the Cc list to get the more general underlying
>> question resolved. To those who haven't followed the discussion from
>> the beginning: The question is whether senseless combinations of
>> Kconfig options should be permitted, or whether instead "depends on"
>> is a reasonable thing to use in such cases to prevent their (combined)
>> selection.
> 
> The people whose opinions matter most here are those who build/package
> Xen, who are not developers and therefore not experts in how the
> hypervisor fits together.
> 
> If it turns out that the majority of users disagree with me, then I'll
> withdraw my nack, but the reason I'm being such a pain in this regard is
> that this thread re-enforces my opinion that your judgement here is
> wrong, is actively detrimental to usability (which is far wider than
> just developer usability), and that the users will agree with me in this
> matter.

That's as much your anticipation of what they might want, as it is
mine to think that helping them to avoid bogus configurations is the
best we can do here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 01/23] x86: change name of parameter for various invlpg functions
  2018-08-26 12:19 ` [PATCH v2 01/23] x86: change name of parameter for various invlpg functions Wei Liu
                     ` (2 preceding siblings ...)
  2018-08-30  1:26   ` Tian, Kevin
@ 2018-09-03 13:46   ` Wei Liu
  2018-09-04 13:42     ` Boris Ostrovsky
  3 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-09-03 13:46 UTC (permalink / raw)
  To: xen-devel
  Cc: Kevin Tian, Wei Liu, Suravee Suthikulpanit, Jun Nakajima,
	Andrew Cooper, Tim Deegan, George Dunlap, Jan Beulich,
	Boris Ostrovsky, Brian Woods

On Sun, Aug 26, 2018 at 01:19:34PM +0100, Wei Liu wrote:
> They all incorrectly named a parameter virtual address while it should
> have been linear address.
> 
> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Is there more comment on this?

These being rather mechanical changes makes me wonder if I should wait
to collect all necessary ack/review or just go ahead with Jan and
Kevin's.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM
  2018-08-30  8:35       ` Jan Beulich
@ 2018-09-03 14:27         ` Wei Liu
  2018-09-03 14:48           ` Jan Beulich
  0 siblings, 1 reply; 97+ messages in thread
From: Wei Liu @ 2018-09-03 14:27 UTC (permalink / raw)
  To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Wei Liu, xen-devel

On Thu, Aug 30, 2018 at 02:35:37AM -0600, Jan Beulich wrote:
> >>> On 30.08.18 at 09:42, <wei.liu2@citrix.com> wrote:
> > On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
> >> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> >> > --- a/xen/arch/x86/mm/paging.c
> >> > +++ b/xen/arch/x86/mm/paging.c
> >> > @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct vcpu 
> > *v)
> >> >      return paging_get_nestedmode(v);
> >> >  }
> >> >  
> >> > +#ifdef CONFIG_HVM
> >> >  void paging_update_nestedmode(struct vcpu *v)
> >> >  {
> >> >      ASSERT(nestedhvm_enabled(v->domain));
> >> > @@ -930,6 +931,7 @@ void paging_update_nestedmode(struct vcpu *v)
> >> >          v->arch.paging.nestedmode = NULL;
> >> >      hvm_asid_flush_vcpu(v);
> >> >  }
> >> > +#endif
> >> 
> >> Just a consideration (no objection): Would it be worthwhile to
> >> introduce CONFIG_NESTED_HVM at the same time (for now hard
> >> coded to Y, and of course depending on HVM) to avoid having to
> >> touch all such places a second time later on?
> > 
> > If we plan to make nested hvm configurable in the future, that would be
> > a worthwhile thing to do; otherwise it is just another concept that
> > users need to care about, which creates some mental burden.
> 
> Andrew, do you have any opinion / preference either way?

I discussed this with Andrew on IRC and came to the conclusion it is not
worth it to introduce CONFIG_NESTED_HVM, because:

1. Nested virt will become commonplace for Xen.
2. Trying to split nested parts from non-nested parts will be massively
   complicated.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM
  2018-09-03 14:27         ` Wei Liu
@ 2018-09-03 14:48           ` Jan Beulich
  0 siblings, 0 replies; 97+ messages in thread
From: Jan Beulich @ 2018-09-03 14:48 UTC (permalink / raw)
  To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, xen-devel

>>> On 03.09.18 at 16:27, <wei.liu2@citrix.com> wrote:
> On Thu, Aug 30, 2018 at 02:35:37AM -0600, Jan Beulich wrote:
>> >>> On 30.08.18 at 09:42, <wei.liu2@citrix.com> wrote:
>> > On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
>> >> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
>> >> > --- a/xen/arch/x86/mm/paging.c
>> >> > +++ b/xen/arch/x86/mm/paging.c
>> >> > @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct vcpu 
>> > *v)
>> >> >      return paging_get_nestedmode(v);
>> >> >  }
>> >> >  
>> >> > +#ifdef CONFIG_HVM
>> >> >  void paging_update_nestedmode(struct vcpu *v)
>> >> >  {
>> >> >      ASSERT(nestedhvm_enabled(v->domain));
>> >> > @@ -930,6 +931,7 @@ void paging_update_nestedmode(struct vcpu *v)
>> >> >          v->arch.paging.nestedmode = NULL;
>> >> >      hvm_asid_flush_vcpu(v);
>> >> >  }
>> >> > +#endif
>> >> 
>> >> Just a consideration (no objection): Would it be worthwhile to
>> >> introduce CONFIG_NESTED_HVM at the same time (for now hard
>> >> coded to Y, and of course depending on HVM) to avoid having to
>> >> touch all such places a second time later on?
>> > 
>> > If we plan to make nested hvm configurable in the future, that would be
>> > a worthwhile thing to do; otherwise it is just another concept that
>> > users need to care about, which creates some mental burden.
>> 
>> Andrew, do you have any opinion / preference either way?
> 
> I discussed this with Andrew on IRC and came to the conclusion it is not
> worth it to introduce CONFIG_NESTED_HVM, because:
> 
> 1. Nested virt will become commonplace for Xen.
> 2. Trying to split nested parts from non-nested parts will be massively
>    complicated.

Okay then.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

* Re: [PATCH v2 01/23] x86: change name of parameter for various invlpg functions
  2018-09-03 13:46   ` Wei Liu
@ 2018-09-04 13:42     ` Boris Ostrovsky
  0 siblings, 0 replies; 97+ messages in thread
From: Boris Ostrovsky @ 2018-09-04 13:42 UTC (permalink / raw)
  To: Wei Liu, xen-devel
  Cc: Kevin Tian, Jan Beulich, George Dunlap, Andrew Cooper,
	Tim Deegan, Jun Nakajima, Brian Woods, Suravee Suthikulpanit



On 09/03/2018 09:46 AM, Wei Liu wrote:
> On Sun, Aug 26, 2018 at 01:19:34PM +0100, Wei Liu wrote:
>> They all incorrectly named a parameter virtual address while it should
>> have been linear address.
>>
>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Is there more comment on this?
>
> These being rather mechanical changes makes me wonder if I should wait
> to collect all necessary ack/review or just go ahead with Jan and
> Kevin's.


As I said earlier, I am not convinced this change is necessary since AMD 
defines virtual and linear addresses as synonyms (see, for example, 
section 1.1.1. in volume 2).

However, if others think linear is a better term to use, that's fine too.

Acked-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 97+ messages in thread

end of thread, other threads:[~2018-09-04 13:43 UTC | newest]

Thread overview: 97+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-26 12:19 [PATCH v2 00/23] Make CONFIG_HVM work Wei Liu
2018-08-26 12:19 ` [PATCH v2 01/23] x86: change name of parameter for various invlpg functions Wei Liu
2018-08-27 13:49   ` Boris Ostrovsky
2018-08-27 13:54     ` Jan Beulich
2018-08-27 14:20   ` Jan Beulich
2018-08-30  1:26   ` Tian, Kevin
2018-09-03 13:46   ` Wei Liu
2018-09-04 13:42     ` Boris Ostrovsky
2018-08-26 12:19 ` [PATCH v2 02/23] xen: is_hvm_{domain, vcpu} should evaluate to false when !CONFIG_HVM Wei Liu
2018-08-27 14:24   ` Jan Beulich
2018-08-28  8:41     ` Wei Liu
2018-08-28 11:09       ` Julien Grall
2018-08-26 12:19 ` [PATCH v2 03/23] x86: enclose hvm_op and dm_op in CONFIG_HVM in relevant tables Wei Liu
2018-08-27 14:24   ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 04/23] x86/hvm: provide hvm_hap_supported Wei Liu
2018-08-27 14:25   ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 05/23] x86: provide stub for memory_type_changed Wei Liu
2018-08-27 14:28   ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI Wei Liu
2018-08-27 14:29   ` Jan Beulich
2018-08-28  8:45     ` Wei Liu
2018-08-28  9:08       ` Jan Beulich
2018-08-29 16:23         ` Wei Liu
2018-08-26 12:19 ` [PATCH v2 07/23] x86/vpmu: put HVM only code under CONFIG_HVM Wei Liu
2018-08-27 15:03   ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 08/23] xen/pt: io.c contains HVM only code Wei Liu
2018-08-27 15:04   ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 09/23] x86/pt: make it build with !CONFIG_HVM Wei Liu
2018-08-27 15:07   ` Jan Beulich
2018-08-30  1:29   ` Tian, Kevin
2018-08-26 12:19 ` [PATCH v2 10/23] x86/pt: split out HVM functions from vtd.c Wei Liu
2018-08-30  1:29   ` Tian, Kevin
2018-08-26 12:19 ` [PATCH v2 11/23] x86: XENMEM_resource_ioreq_server is HVM only Wei Liu
2018-08-27 15:13   ` Jan Beulich
2018-08-29 16:28     ` Wei Liu
2018-08-26 12:19 ` [PATCH v2 12/23] x86: monitor.o is currently " Wei Liu
2018-08-26 16:33   ` Razvan Cojocaru
2018-08-27 15:18   ` Jan Beulich
2018-08-27 15:23     ` Razvan Cojocaru
2018-08-29 16:42     ` Wei Liu
2018-08-29 17:43       ` Tamas K Lengyel
2018-08-29 18:09         ` Razvan Cojocaru
2018-08-30  7:14           ` Wei Liu
2018-08-26 12:19 ` [PATCH v2 13/23] x86: provide stubs, declarations and macros in hvm.h Wei Liu
2018-08-27 15:43   ` Jan Beulich
2018-09-03  9:45   ` Paul Durrant
2018-09-03  9:50     ` Wei Liu
2018-08-26 12:19 ` [PATCH v2 14/23] x86/mm: put nested p2m code under CONFIG_HVM Wei Liu
2018-08-27 15:56   ` Jan Beulich
2018-08-28  8:40     ` Wei Liu
2018-08-28  9:10       ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 15/23] x86/mm: put HVM only " Wei Liu
2018-08-26 16:39   ` Razvan Cojocaru
2018-08-27  9:03   ` Wei Liu
2018-08-28 10:41     ` Wei Liu
2018-08-28 10:53       ` Jan Beulich
2018-08-27 16:01   ` Jan Beulich
2018-08-28 10:41     ` Wei Liu
2018-08-26 12:19 ` [PATCH v2 16/23] x86/p2m/pod: make it build with !CONFIG_HVM Wei Liu
2018-08-28 10:47   ` Jan Beulich
2018-08-28 10:54     ` Wei Liu
2018-08-28 11:32       ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM Wei Liu
2018-08-28 10:50   ` Jan Beulich
2018-08-30  7:42     ` Wei Liu
2018-08-30  8:35       ` Jan Beulich
2018-09-03 14:27         ` Wei Liu
2018-09-03 14:48           ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 18/23] x86/domctl: XEN_DOMCTL_debug_op is HVM only Wei Liu
2018-08-28 10:50   ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 19/23] x86: PIT emulation is common to both PV and HVM Wei Liu
2018-08-28 11:44   ` Jan Beulich
2018-08-28 13:19     ` Wei Liu
2018-08-28 14:36       ` Jan Beulich
2018-08-28 14:48         ` Wei Liu
2018-08-28 14:51           ` Andrew Cooper
2018-08-28 14:58             ` Wei Liu
2018-08-28 15:04               ` Jan Beulich
2018-08-28 15:17                 ` Wei Liu
2018-08-28 14:56           ` Wei Liu
2018-08-26 12:19 ` [PATCH v2 20/23] xen: connect guest creation with CONFIG_{HVM, PV} Wei Liu
2018-08-28 11:07   ` Julien Grall
2018-08-28 13:13     ` Wei Liu
2018-08-28 11:47   ` Jan Beulich
2018-08-28 13:15     ` Wei Liu
2018-08-26 12:19 ` [PATCH v2 21/23] x86: expose CONFIG_HVM Wei Liu
2018-08-28 11:50   ` Jan Beulich
2018-08-28 12:14     ` Andrew Cooper
2018-08-28 13:33       ` Jan Beulich
2018-08-29 16:56         ` Andrew Cooper
2018-08-30  6:21           ` Jan Beulich
2018-08-30  6:57             ` Juergen Gross
2018-08-31 20:09             ` Andrew Cooper
2018-09-03 11:35               ` Jan Beulich
2018-08-26 12:19 ` [PATCH v2 22/23] x86/pvshim: disable HVM for PV shim Wei Liu
2018-08-26 12:19 ` [PATCH v2 23/23] xen: decouple HVM and IOMMU capabilities Wei Liu
2018-08-28 11:56   ` Jan Beulich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.