* [PATCH 01/34] x86: fix building !CONFIG_LOCK_PROFILE
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-17 15:37 ` Wei Liu
2018-08-17 15:12 ` [PATCH 02/34] x86/vvmx: make get_shadow_eptp static function Wei Liu
` (34 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Julien Grall, Jan Beulich
The init function shouldn't be built or called at all when
!CONFIG_LOCK_PROFILE.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/common/spinlock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 8f2ba08..36e31c9 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -471,6 +471,7 @@ void _lock_profile_deregister_struct(
spin_unlock(&lock_profile_lock);
}
+#ifdef CONFIG_LOCK_PROFILE
static int __init lock_prof_init(void)
{
struct lock_profile **q;
@@ -489,5 +490,6 @@ static int __init lock_prof_init(void)
return 0;
}
__initcall(lock_prof_init);
+#endif
#endif /* LOCK_PROFILE */
--
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] 130+ messages in thread* [PATCH 02/34] x86/vvmx: make get_shadow_eptp static function
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
2018-08-17 15:12 ` [PATCH 01/34] x86: fix building !CONFIG_LOCK_PROFILE Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-22 2:48 ` Tian, Kevin
2018-08-17 15:12 ` [PATCH 03/34] x86: HVM_FEP should depend on HVM Wei Liu
` (33 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Kevin Tian, Wei Liu, Jan Beulich, Jun Nakajima
Its callers live within the same file.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
xen/include/asm-x86/hvm/vmx/vvmx.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 918d47d..b7d9a1a 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1107,7 +1107,7 @@ static void load_shadow_guest_state(struct vcpu *v)
/* TODO: CR3 target control */
}
-uint64_t get_shadow_eptp(struct vcpu *v)
+static uint64_t get_shadow_eptp(struct vcpu *v)
{
struct p2m_domain *p2m = p2m_get_nestedp2m(v);
struct ept_data *ept = &p2m->ept;
diff --git a/xen/include/asm-x86/hvm/vmx/vvmx.h b/xen/include/asm-x86/hvm/vmx/vvmx.h
index 9ea35eb..a20bd9e 100644
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
@@ -188,8 +188,6 @@ enum vmx_insn_errno set_vvmcs_real_safe(const struct vcpu *, u32 encoding,
set_vvmcs_real_safe(vcpu, encoding, val) : \
set_vvmcs_virtual_safe(vcpu_nestedhvm(vcpu).nv_vvmcx, encoding, val))
-uint64_t get_shadow_eptp(struct vcpu *v);
-
void nvmx_destroy_vmcs(struct vcpu *v);
int nvmx_handle_vmptrld(struct cpu_user_regs *regs);
int nvmx_handle_vmptrst(struct cpu_user_regs *regs);
--
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] 130+ messages in thread* [PATCH 03/34] x86: HVM_FEP should depend on HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
2018-08-17 15:12 ` [PATCH 01/34] x86: fix building !CONFIG_LOCK_PROFILE Wei Liu
2018-08-17 15:12 ` [PATCH 02/34] x86/vvmx: make get_shadow_eptp static function Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 8:06 ` Roger Pau Monné
2018-08-17 15:12 ` [PATCH 04/34] x86/mm: don't reference hvm_funcs directly Wei Liu
` (32 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 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/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 63b286a..ba5cb62 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -94,6 +94,7 @@ config BIGMEM
config HVM_FEP
bool "HVM Forced Emulation Prefix support" if EXPERT = "y"
default DEBUG
+ depends on HVM
---help---
Compiles in a feature that allows HVM guest to arbitrarily
--
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] 130+ messages in thread* [PATCH 04/34] x86/mm: don't reference hvm_funcs directly
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (2 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 03/34] x86: HVM_FEP should depend on HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 9:28 ` Andrew Cooper
2018-08-17 15:12 ` [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM Wei Liu
` (31 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
It is generally not a good idea to reference the internal data
structure of the another subsystem directly. Introduce a wrapper
function for the invlpg hook.
No functional change.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/mm.c | 2 +-
xen/include/asm-x86/hvm/hvm.h | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 85ccf48..8ac4412 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5800,7 +5800,7 @@ void paging_invlpg(struct vcpu *v, unsigned long va)
if ( is_pv_vcpu(v) )
flush_tlb_one_local(va);
else
- hvm_funcs.invlpg(v, va);
+ hvm_invlpg(v, va);
}
/* Build a 32bit PSE page table using 4MB pages. */
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 4f720ad..146720c 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -454,6 +454,11 @@ 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)
+{
+ hvm_funcs.invlpg(v, va);
+}
+
/* These bits in CR4 are owned by the host. */
#define HVM_CR4_HOST_MASK (mmu_cr4_features & \
(X86_CR4_VMXE | X86_CR4_PAE | X86_CR4_MCE))
--
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] 130+ messages in thread* Re: [PATCH 04/34] x86/mm: don't reference hvm_funcs directly
2018-08-17 15:12 ` [PATCH 04/34] x86/mm: don't reference hvm_funcs directly Wei Liu
@ 2018-08-20 9:28 ` Andrew Cooper
2018-08-20 10:21 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Andrew Cooper @ 2018-08-20 9:28 UTC (permalink / raw)
To: Wei Liu, xen-devel; +Cc: Jan Beulich
On 17/08/2018 16:12, Wei Liu wrote:
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index 4f720ad..146720c 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -454,6 +454,11 @@ 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)
Please s/va/linear/ while making this addition (or do a general va =>
linear cleanup for invlpg). Sadly, the terminology has been incorrect
since the codes introduction.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 04/34] x86/mm: don't reference hvm_funcs directly
2018-08-20 9:28 ` Andrew Cooper
@ 2018-08-20 10:21 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-20 10:21 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Wei Liu, Jan Beulich
On Mon, Aug 20, 2018 at 10:28:21AM +0100, Andrew Cooper wrote:
> On 17/08/2018 16:12, Wei Liu wrote:
> > diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> > index 4f720ad..146720c 100644
> > --- a/xen/include/asm-x86/hvm/hvm.h
> > +++ b/xen/include/asm-x86/hvm/hvm.h
> > @@ -454,6 +454,11 @@ 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)
>
> Please s/va/linear/ while making this addition (or do a general va =>
> linear cleanup for invlpg). Sadly, the terminology has been incorrect
I will make another patch to clean it up.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (3 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 04/34] x86/mm: don't reference hvm_funcs directly Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-19 16:48 ` Andrew Cooper
2018-08-20 11:51 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 06/34] x86: fix two unused variable errors " Wei Liu
` (30 subsequent siblings)
35 siblings, 2 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Julien Grall, Jan Beulich
Since it is defined in common header file, introduce CONFIG_HVM to
Arm to avoid breakage.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/arm/Kconfig | 3 +++
xen/include/xen/sched.h | 6 ++++++
2 files changed, 9 insertions(+)
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..8fc3423 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -879,8 +879,14 @@ 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))
+
+#if CONFIG_HVM
#define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm)
+#else
+#define is_hvm_domain(d) (0)
+#endif
#define is_hvm_vcpu(v) (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] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM Wei Liu
@ 2018-08-19 16:48 ` Andrew Cooper
2018-08-20 9:06 ` Wei Liu
2018-08-20 11:51 ` Jan Beulich
1 sibling, 1 reply; 130+ messages in thread
From: Andrew Cooper @ 2018-08-19 16:48 UTC (permalink / raw)
To: Wei Liu, xen-devel
Cc: Stefano Stabellini, George Dunlap, Tim Deegan, Ian Jackson,
Julien Grall, Jan Beulich
On 17/08/2018 16:12, Wei Liu wrote:
> Since it is defined in common header file, introduce CONFIG_HVM to
> Arm to avoid breakage.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> xen/arch/arm/Kconfig | 3 +++
> xen/include/xen/sched.h | 6 ++++++
> 2 files changed, 9 insertions(+)
>
> 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..8fc3423 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -879,8 +879,14 @@ 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))
> +
> +#if CONFIG_HVM
> #define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm)
> +#else
> +#define is_hvm_domain(d) (0)
> +#endif
> #define is_hvm_vcpu(v) (is_hvm_domain(v->domain))
The need for the following patch is caused by a bug here, in that you
don't evaluate d.
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
seems to compile, and should DTRT including all appropriate parameter
evaluation.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-19 16:48 ` Andrew Cooper
@ 2018-08-20 9:06 ` Wei Liu
2018-08-20 9:23 ` Andrew Cooper
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-20 9:06 UTC (permalink / raw)
To: Andrew Cooper
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Tim Deegan,
Ian Jackson, Julien Grall, Jan Beulich, xen-devel
On Sun, Aug 19, 2018 at 05:48:17PM +0100, Andrew Cooper wrote:
> On 17/08/2018 16:12, Wei Liu wrote:
> > Since it is defined in common header file, introduce CONFIG_HVM to
> > Arm to avoid breakage.
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > xen/arch/arm/Kconfig | 3 +++
> > xen/include/xen/sched.h | 6 ++++++
> > 2 files changed, 9 insertions(+)
> >
> > 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..8fc3423 100644
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -879,8 +879,14 @@ 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))
> > +
> > +#if CONFIG_HVM
> > #define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm)
> > +#else
> > +#define is_hvm_domain(d) (0)
> > +#endif
> > #define is_hvm_vcpu(v) (is_hvm_domain(v->domain))
>
> The need for the following patch is caused by a bug here, in that you
> don't evaluate d.
I know. I didn't classified that as a bug though.
>
> 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);
> +}
> +
This should work too. I'm not too fuss whether is_hvm_* are macros or
functions.
> #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
> cpumask_weight((v)->cpu_hard_affinity) == 1)
> #ifdef CONFIG_HAS_PASSTHROUGH
>
> seems to compile, and should DTRT including all appropriate parameter
> evaluation.
I will test if DCE works properly with static inline functions.
Wei.
>
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-20 9:06 ` Wei Liu
@ 2018-08-20 9:23 ` Andrew Cooper
2018-08-20 9:45 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Andrew Cooper @ 2018-08-20 9:23 UTC (permalink / raw)
To: Wei Liu
Cc: Stefano Stabellini, George Dunlap, Tim Deegan, Ian Jackson,
Julien Grall, Jan Beulich, xen-devel
On 20/08/2018 10:06, Wei Liu wrote:
> On Sun, Aug 19, 2018 at 05:48:17PM +0100, Andrew Cooper wrote:
>> On 17/08/2018 16:12, Wei Liu wrote:
>>> Since it is defined in common header file, introduce CONFIG_HVM to
>>> Arm to avoid breakage.
>>>
>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>> ---
>>> xen/arch/arm/Kconfig | 3 +++
>>> xen/include/xen/sched.h | 6 ++++++
>>> 2 files changed, 9 insertions(+)
>>>
>>> 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..8fc3423 100644
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -879,8 +879,14 @@ 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))
>>> +
>>> +#if CONFIG_HVM
>>> #define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm)
>>> +#else
>>> +#define is_hvm_domain(d) (0)
>>> +#endif
>>> #define is_hvm_vcpu(v) (is_hvm_domain(v->domain))
>> The need for the following patch is caused by a bug here, in that you
>> don't evaluate d.
> I know. I didn't classified that as a bug though.
I'm afraid that the x86 maintainership will disagree with you there.
>
>> 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);
>> +}
>> +
> This should work too. I'm not too fuss whether is_hvm_* are macros or
> functions.
static inlines are superior to macros in a lot of ways. If in doubt,
use a static inline (if you can. we've got some header file tangles
which occasionally make it very hard to use static inlines).
>
>> #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
>> cpumask_weight((v)->cpu_hard_affinity) == 1)
>> #ifdef CONFIG_HAS_PASSTHROUGH
>>
>> seems to compile, and should DTRT including all appropriate parameter
>> evaluation.
> I will test if DCE works properly with static inline functions.
It does (/should).
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-20 9:23 ` Andrew Cooper
@ 2018-08-20 9:45 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-20 9:45 UTC (permalink / raw)
To: Andrew Cooper
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Tim Deegan,
Ian Jackson, Julien Grall, Jan Beulich, xen-devel
On Mon, Aug 20, 2018 at 10:23:47AM +0100, Andrew Cooper wrote:
> >
> >> 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);
> >> +}
> >> +
> > This should work too. I'm not too fuss whether is_hvm_* are macros or
> > functions.
>
> static inlines are superior to macros in a lot of ways. If in doubt,
> use a static inline (if you can. we've got some header file tangles
> which occasionally make it very hard to use static inlines).
OK, sure.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM Wei Liu
2018-08-19 16:48 ` Andrew Cooper
@ 2018-08-20 11:51 ` Jan Beulich
2018-08-21 16:31 ` Wei Liu
1 sibling, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-20 11:51 UTC (permalink / raw)
To: Wei Liu
Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> Since it is defined in common header file, introduce CONFIG_HVM to
> Arm to avoid breakage.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> xen/arch/arm/Kconfig | 3 +++
> xen/include/xen/sched.h | 6 ++++++
> 2 files changed, 9 insertions(+)
>
> 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
I'm not convinced this is a good idea, but I'll let the ARM maintainers
judge.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-20 11:51 ` Jan Beulich
@ 2018-08-21 16:31 ` Wei Liu
2018-08-21 18:33 ` Julien Grall
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-21 16:31 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 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > Since it is defined in common header file, introduce CONFIG_HVM to
> > Arm to avoid breakage.
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > xen/arch/arm/Kconfig | 3 +++
> > xen/include/xen/sched.h | 6 ++++++
> > 2 files changed, 9 insertions(+)
> >
> > 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
>
> I'm not convinced this is a good idea, but I'll let the ARM maintainers
> judge.
Andrew discovered that hvm flag is not set by toolstack so ARM guests
are PV guests to Xen. I think the addition here can be omitted.
However I would still like to hear from ARM maintainers what guest type
should be set for ARM, because sooner or later I will need to change PV
code as well.
Grepping for is_{hvm,pv}_* in arch/arm yields no result, but then there
is common code that we need to take care of.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-21 16:31 ` Wei Liu
@ 2018-08-21 18:33 ` Julien Grall
2018-08-21 18:49 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Julien Grall @ 2018-08-21 18:33 UTC (permalink / raw)
To: Wei Liu, Jan Beulich
Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, xen-devel
Hi Wei,
On 08/21/2018 05:31 PM, Wei Liu wrote:
> On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
>>>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
>>> Since it is defined in common header file, introduce CONFIG_HVM to
>>> Arm to avoid breakage.
>>>
>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>> ---
>>> xen/arch/arm/Kconfig | 3 +++
>>> xen/include/xen/sched.h | 6 ++++++
>>> 2 files changed, 9 insertions(+)
>>>,
>>> 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
>>
>> I'm not convinced this is a good idea, but I'll let the ARM maintainers
>> judge.
>
> Andrew discovered that hvm flag is not set by toolstack so ARM guests
> are PV guests to Xen. I think the addition here can be omitted.
>
> However I would still like to hear from ARM maintainers what guest type
> should be set for ARM, because sooner or later I will need to change PV
> code as well.
>
> Grepping for is_{hvm,pv}_* in arch/arm yields no result, but then there
> is common code that we need to take care of.
Using PV was more a convenience at the time because was not there. The
plan is to switch to PVH (see RFC [1]).
I will try to find some times this week to rework the patch based on the
comments.
Cheers,
[1] https://lists.xen.org/archives/html/xen-devel/2018-06/msg01537.html
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-21 18:33 ` Julien Grall
@ 2018-08-21 18:49 ` Wei Liu
2018-08-21 18:50 ` Julien Grall
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-21 18:49 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 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 08/21/2018 05:31 PM, Wei Liu wrote:
> > On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
> > > > > > On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > > > Since it is defined in common header file, introduce CONFIG_HVM to
> > > > Arm to avoid breakage.
> > > >
> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > ---
> > > > xen/arch/arm/Kconfig | 3 +++
> > > > xen/include/xen/sched.h | 6 ++++++
> > > > 2 files changed, 9 insertions(+)
> > > > ,
> > > > 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
> > >
> > > I'm not convinced this is a good idea, but I'll let the ARM maintainers
> > > judge.
> >
> > Andrew discovered that hvm flag is not set by toolstack so ARM guests
> > are PV guests to Xen. I think the addition here can be omitted.
> >
> > However I would still like to hear from ARM maintainers what guest type
> > should be set for ARM, because sooner or later I will need to change PV
> > code as well.
> >
> > Grepping for is_{hvm,pv}_* in arch/arm yields no result, but then there
> > is common code that we need to take care of.
>
> Using PV was more a convenience at the time because was not there. The plan
> is to switch to PVH (see RFC [1]).
>
> I will try to find some times this week to rework the patch based on the
> comments.
>
> Cheers,
>
> [1] https://lists.xen.org/archives/html/xen-devel/2018-06/msg01537.html
Yes, switching to PVH in toolstack is ideal.
The problem we discuss here is in the hypervisor. Hypervisor only has
HVM and PV. What type should ARM guests be? I think with the move to use
PVH in toolstack, the type in hypervisor should be HVM (as oppose to PV
now)?
Wei.
>
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-21 18:49 ` Wei Liu
@ 2018-08-21 18:50 ` Julien Grall
2018-08-21 18:59 ` Stefano Stabellini
0 siblings, 1 reply; 130+ messages in thread
From: Julien Grall @ 2018-08-21 18:50 UTC (permalink / raw)
To: Wei Liu
Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Jan Beulich, xen-devel
On 08/21/2018 07:49 PM, Wei Liu wrote:
> On Tue, Aug 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
>> Hi Wei,
>>
>> On 08/21/2018 05:31 PM, Wei Liu wrote:
>>> On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
>>>>>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
>>>>> Since it is defined in common header file, introduce CONFIG_HVM to
>>>>> Arm to avoid breakage.
>>>>>
>>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>>>> ---
>>>>> xen/arch/arm/Kconfig | 3 +++
>>>>> xen/include/xen/sched.h | 6 ++++++
>>>>> 2 files changed, 9 insertions(+)
>>>>> ,
>>>>> 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
>>>>
>>>> I'm not convinced this is a good idea, but I'll let the ARM maintainers
>>>> judge.
>>>
>>> Andrew discovered that hvm flag is not set by toolstack so ARM guests
>>> are PV guests to Xen. I think the addition here can be omitted.
>>>
>>> However I would still like to hear from ARM maintainers what guest type
>>> should be set for ARM, because sooner or later I will need to change PV
>>> code as well.
>>>
>>> Grepping for is_{hvm,pv}_* in arch/arm yields no result, but then there
>>> is common code that we need to take care of.
>>
>> Using PV was more a convenience at the time because was not there. The plan
>> is to switch to PVH (see RFC [1]).
>>
>> I will try to find some times this week to rework the patch based on the
>> comments.
>>
>> Cheers,
>>
>> [1] https://lists.xen.org/archives/html/xen-devel/2018-06/msg01537.html
>
> Yes, switching to PVH in toolstack is ideal.
>
> The problem we discuss here is in the hypervisor. Hypervisor only has
> HVM and PV. What type should ARM guests be? I think with the move to use
> PVH in toolstack, the type in hypervisor should be HVM (as oppose to PV
> now)?
Arm guest are much closer to HVM than PV. So the hypervisor should use
HVM here.
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] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-21 18:50 ` Julien Grall
@ 2018-08-21 18:59 ` Stefano Stabellini
2018-08-21 20:08 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Stefano Stabellini @ 2018-08-21 18:59 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, 21 Aug 2018, Julien Grall wrote:
> On 08/21/2018 07:49 PM, Wei Liu wrote:
> > On Tue, Aug 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
> > > Hi Wei,
> > >
> > > On 08/21/2018 05:31 PM, Wei Liu wrote:
> > > > On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
> > > > > > > > On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > > > > > Since it is defined in common header file, introduce CONFIG_HVM to
> > > > > > Arm to avoid breakage.
> > > > > >
> > > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > > ---
> > > > > > xen/arch/arm/Kconfig | 3 +++
> > > > > > xen/include/xen/sched.h | 6 ++++++
> > > > > > 2 files changed, 9 insertions(+)
> > > > > > ,
> > > > > > 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
> > > > >
> > > > > I'm not convinced this is a good idea, but I'll let the ARM
> > > > > maintainers
> > > > > judge.
> > > >
> > > > Andrew discovered that hvm flag is not set by toolstack so ARM guests
> > > > are PV guests to Xen. I think the addition here can be omitted.
> > > >
> > > > However I would still like to hear from ARM maintainers what guest type
> > > > should be set for ARM, because sooner or later I will need to change PV
> > > > code as well.
> > > >
> > > > Grepping for is_{hvm,pv}_* in arch/arm yields no result, but then there
> > > > is common code that we need to take care of.
> > >
> > > Using PV was more a convenience at the time because was not there. The
> > > plan
> > > is to switch to PVH (see RFC [1]).
> > >
> > > I will try to find some times this week to rework the patch based on the
> > > comments.
> > >
> > > Cheers,
> > >
> > > [1] https://lists.xen.org/archives/html/xen-devel/2018-06/msg01537.html
> >
> > Yes, switching to PVH in toolstack is ideal.
> >
> > The problem we discuss here is in the hypervisor. Hypervisor only has
> > HVM and PV. What type should ARM guests be? I think with the move to use
> > PVH in toolstack, the type in hypervisor should be HVM (as oppose to PV
> > now)?
>
> Arm guest are much closer to HVM than PV. So the hypervisor should use HVM
> here.
+1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-21 18:59 ` Stefano Stabellini
@ 2018-08-21 20:08 ` Wei Liu
2018-08-22 15:11 ` Julien Grall
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-21 20:08 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Wei Liu, George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Julien Grall, Jan Beulich, xen-devel
On Tue, Aug 21, 2018 at 11:59:26AM -0700, Stefano Stabellini wrote:
> On Tue, 21 Aug 2018, Julien Grall wrote:
> > On 08/21/2018 07:49 PM, Wei Liu wrote:
> > > On Tue, Aug 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
> > > > Hi Wei,
> > > >
> > > > On 08/21/2018 05:31 PM, Wei Liu wrote:
> > > > > On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
> > > > > > > > > On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > > > > > > Since it is defined in common header file, introduce CONFIG_HVM to
> > > > > > > Arm to avoid breakage.
> > > > > > >
> > > > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > > > ---
> > > > > > > xen/arch/arm/Kconfig | 3 +++
> > > > > > > xen/include/xen/sched.h | 6 ++++++
> > > > > > > 2 files changed, 9 insertions(+)
> > > > > > > ,
> > > > > > > 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
> > > > > >
> > > > > > I'm not convinced this is a good idea, but I'll let the ARM
> > > > > > maintainers
> > > > > > judge.
> > > > >
> > > > > Andrew discovered that hvm flag is not set by toolstack so ARM guests
> > > > > are PV guests to Xen. I think the addition here can be omitted.
> > > > >
> > > > > However I would still like to hear from ARM maintainers what guest type
> > > > > should be set for ARM, because sooner or later I will need to change PV
> > > > > code as well.
> > > > >
> > > > > Grepping for is_{hvm,pv}_* in arch/arm yields no result, but then there
> > > > > is common code that we need to take care of.
> > > >
> > > > Using PV was more a convenience at the time because was not there. The
> > > > plan
> > > > is to switch to PVH (see RFC [1]).
> > > >
> > > > I will try to find some times this week to rework the patch based on the
> > > > comments.
> > > >
> > > > Cheers,
> > > >
> > > > [1] https://lists.xen.org/archives/html/xen-devel/2018-06/msg01537.html
> > >
> > > Yes, switching to PVH in toolstack is ideal.
> > >
> > > The problem we discuss here is in the hypervisor. Hypervisor only has
> > > HVM and PV. What type should ARM guests be? I think with the move to use
> > > PVH in toolstack, the type in hypervisor should be HVM (as oppose to PV
> > > now)?
> >
> > Arm guest are much closer to HVM than PV. So the hypervisor should use HVM
> > here.
>
> +1
OK. In that case, what do you guys think about introducing CONFIG_HVM to
ARM?
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-21 20:08 ` Wei Liu
@ 2018-08-22 15:11 ` Julien Grall
2018-08-22 15:20 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Julien Grall @ 2018-08-22 15:11 UTC (permalink / raw)
To: Wei Liu, Stefano Stabellini
Cc: George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan,
Jan Beulich, xen-devel
Hi Wei,
On 21/08/18 21:08, Wei Liu wrote:
> On Tue, Aug 21, 2018 at 11:59:26AM -0700, Stefano Stabellini wrote:
>> On Tue, 21 Aug 2018, Julien Grall wrote:
>>> On 08/21/2018 07:49 PM, Wei Liu wrote:
>>>> On Tue, Aug 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
>>>>> Hi Wei,
>>>>>
>>>>> On 08/21/2018 05:31 PM, Wei Liu wrote:
>>>>>> On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
>>>>>>>>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
>>>>>>>> Since it is defined in common header file, introduce CONFIG_HVM to
>>>>>>>> Arm to avoid breakage.
>>>>>>>>
>>>>>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>>>>>>> ---
>>>>>>>> xen/arch/arm/Kconfig | 3 +++
>>>>>>>> xen/include/xen/sched.h | 6 ++++++
>>>>>>>> 2 files changed, 9 insertions(+)
>>>>>>>> ,
>>>>>>>> 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
>>>>>>>
>>>>>>> I'm not convinced this is a good idea, but I'll let the ARM
>>>>>>> maintainers
>>>>>>> judge.
>>>>>>
>>>>>> Andrew discovered that hvm flag is not set by toolstack so ARM guests
>>>>>> are PV guests to Xen. I think the addition here can be omitted.
>>>>>>
>>>>>> However I would still like to hear from ARM maintainers what guest type
>>>>>> should be set for ARM, because sooner or later I will need to change PV
>>>>>> code as well.
>>>>>>
>>>>>> Grepping for is_{hvm,pv}_* in arch/arm yields no result, but then there
>>>>>> is common code that we need to take care of.
>>>>>
>>>>> Using PV was more a convenience at the time because was not there. The
>>>>> plan
>>>>> is to switch to PVH (see RFC [1]).
>>>>>
>>>>> I will try to find some times this week to rework the patch based on the
>>>>> comments.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> [1] https://lists.xen.org/archives/html/xen-devel/2018-06/msg01537.html
>>>>
>>>> Yes, switching to PVH in toolstack is ideal.
>>>>
>>>> The problem we discuss here is in the hypervisor. Hypervisor only has
>>>> HVM and PV. What type should ARM guests be? I think with the move to use
>>>> PVH in toolstack, the type in hypervisor should be HVM (as oppose to PV
>>>> now)?
>>>
>>> Arm guest are much closer to HVM than PV. So the hypervisor should use HVM
>>> here.
>>
>> +1
>
> OK. In that case, what do you guys think about introducing CONFIG_HVM to
> ARM?
I am ok with that. Note, you will need my patch series "tools/libxl:
Switch Arm guest type to PVH" [1] to make it work on Arm.
Cheers,
[1]
https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg01902.html
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
2018-08-22 15:11 ` Julien Grall
@ 2018-08-22 15:20 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-22 15:20 UTC (permalink / raw)
To: Julien Grall
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Jan Beulich, xen-devel
On Wed, Aug 22, 2018 at 04:11:45PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 21/08/18 21:08, Wei Liu wrote:
> > On Tue, Aug 21, 2018 at 11:59:26AM -0700, Stefano Stabellini wrote:
> > > On Tue, 21 Aug 2018, Julien Grall wrote:
> > > > On 08/21/2018 07:49 PM, Wei Liu wrote:
> > > > > On Tue, Aug 21, 2018 at 07:33:56PM +0100, Julien Grall wrote:
> > > > > > Hi Wei,
> > > > > >
> > > > > > On 08/21/2018 05:31 PM, Wei Liu wrote:
> > > > > > > On Mon, Aug 20, 2018 at 05:51:28AM -0600, Jan Beulich wrote:
> > > > > > > > > > > On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > > > > > > > > Since it is defined in common header file, introduce CONFIG_HVM to
> > > > > > > > > Arm to avoid breakage.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > > > > > > > ---
> > > > > > > > > xen/arch/arm/Kconfig | 3 +++
> > > > > > > > > xen/include/xen/sched.h | 6 ++++++
> > > > > > > > > 2 files changed, 9 insertions(+)
> > > > > > > > > ,
> > > > > > > > > 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
> > > > > > > >
> > > > > > > > I'm not convinced this is a good idea, but I'll let the ARM
> > > > > > > > maintainers
> > > > > > > > judge.
> > > > > > >
> > > > > > > Andrew discovered that hvm flag is not set by toolstack so ARM guests
> > > > > > > are PV guests to Xen. I think the addition here can be omitted.
> > > > > > >
> > > > > > > However I would still like to hear from ARM maintainers what guest type
> > > > > > > should be set for ARM, because sooner or later I will need to change PV
> > > > > > > code as well.
> > > > > > >
> > > > > > > Grepping for is_{hvm,pv}_* in arch/arm yields no result, but then there
> > > > > > > is common code that we need to take care of.
> > > > > >
> > > > > > Using PV was more a convenience at the time because was not there. The
> > > > > > plan
> > > > > > is to switch to PVH (see RFC [1]).
> > > > > >
> > > > > > I will try to find some times this week to rework the patch based on the
> > > > > > comments.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > [1] https://lists.xen.org/archives/html/xen-devel/2018-06/msg01537.html
> > > > >
> > > > > Yes, switching to PVH in toolstack is ideal.
> > > > >
> > > > > The problem we discuss here is in the hypervisor. Hypervisor only has
> > > > > HVM and PV. What type should ARM guests be? I think with the move to use
> > > > > PVH in toolstack, the type in hypervisor should be HVM (as oppose to PV
> > > > > now)?
> > > >
> > > > Arm guest are much closer to HVM than PV. So the hypervisor should use HVM
> > > > here.
> > > +1
> >
> > OK. In that case, what do you guys think about introducing CONFIG_HVM to
> > ARM?
>
> I am ok with that. Note, you will need my patch series "tools/libxl: Switch
> Arm guest type to PVH" [1] to make it work on Arm.
>
> Cheers,
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg01902.html
It is very subtle. This patch and your series can be applied
independently of each other.
My patch to introduce CONFIG_HVM for ARM doesn't actually switch the
guest type inside hypervisor to HVM. It is more about preserving
relevant code paths in arch agnostic code for ARM. As it turns out this
patch won't have any effect on ARM because up until now ARM guests have
all taken the PV paths.
With your series applied, ARM guests will start taking HVM paths, which
will always happen with or without this patch. But your patch is
probably prerequisite to make CONFIG_PV work in the future.
Wei.
>
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 06/34] x86: fix two unused variable errors when !CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (4 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 8:09 ` Roger Pau Monné
2018-08-17 15:12 ` [PATCH 07/34] x86: only call memory_type_changed for HVM guests Wei Liu
` (29 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: George Dunlap, Andrew Cooper, Wei Liu, Jan Beulich, Tim Deegan
The one in context_switch is fixed by annotating with __maybe_unused
because I want to keep prevd around.
The other is fixed by eliminating v.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/domain.c | 3 ++-
xen/arch/x86/mm/shadow/common.c | 3 +--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 5bb900e..574bdf0 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1671,7 +1671,8 @@ static void __context_switch(void)
void context_switch(struct vcpu *prev, struct vcpu *next)
{
unsigned int cpu = smp_processor_id();
- const struct domain *prevd = prev->domain, *nextd = next->domain;
+ const struct domain * __maybe_unused prevd = prev->domain,
+ *nextd = next->domain;
unsigned int dirty_cpu = next->dirty_cpu;
ASSERT(local_irq_is_enabled());
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index fd42d73..0856650 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -430,10 +430,9 @@ const struct x86_emulate_ops *shadow_init_emulation(
void shadow_continue_emulation(struct sh_emulate_ctxt *sh_ctxt,
struct cpu_user_regs *regs)
{
- struct vcpu *v = current;
unsigned long addr, diff;
- ASSERT(is_hvm_vcpu(v));
+ ASSERT(is_hvm_vcpu(current));
/*
* We don't refetch the segment bases, because we don't emulate
--
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] 130+ messages in thread* Re: [PATCH 06/34] x86: fix two unused variable errors when !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 06/34] x86: fix two unused variable errors " Wei Liu
@ 2018-08-21 8:09 ` Roger Pau Monné
2018-08-21 8:11 ` Andrew Cooper
0 siblings, 1 reply; 130+ messages in thread
From: Roger Pau Monné @ 2018-08-21 8:09 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, xen-devel, Tim Deegan, Jan Beulich, Andrew Cooper
On Fri, Aug 17, 2018 at 04:12:24PM +0100, Wei Liu wrote:
> The one in context_switch is fixed by annotating with __maybe_unused
> because I want to keep prevd around.
>
> The other is fixed by eliminating v.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> xen/arch/x86/domain.c | 3 ++-
> xen/arch/x86/mm/shadow/common.c | 3 +--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 5bb900e..574bdf0 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1671,7 +1671,8 @@ static void __context_switch(void)
> void context_switch(struct vcpu *prev, struct vcpu *next)
> {
> unsigned int cpu = smp_processor_id();
> - const struct domain *prevd = prev->domain, *nextd = next->domain;
> + const struct domain * __maybe_unused prevd = prev->domain,
> + *nextd = next->domain;
Could you align *nextd to prevd?
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 06/34] x86: fix two unused variable errors when !CONFIG_HVM
2018-08-21 8:09 ` Roger Pau Monné
@ 2018-08-21 8:11 ` Andrew Cooper
0 siblings, 0 replies; 130+ messages in thread
From: Andrew Cooper @ 2018-08-21 8:11 UTC (permalink / raw)
To: Roger Pau Monné, Wei Liu
Cc: George Dunlap, xen-devel, Tim Deegan, Jan Beulich
On 21/08/2018 09:09, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 04:12:24PM +0100, Wei Liu wrote:
>> The one in context_switch is fixed by annotating with __maybe_unused
>> because I want to keep prevd around.
>>
>> The other is fixed by eliminating v.
>>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
FAOD, this patch is wrong, and not necessary when the bug in the
previous patch has been fixed.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 07/34] x86: only call memory_type_changed for HVM guests
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (5 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 06/34] x86: fix two unused variable errors " Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 11:57 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 08/34] x86: enclose hvm_op and dm_op in CONFIG_HVM in PV hypercall table Wei Liu
` (28 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Julien Grall, 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. Call memory_type_changed for HVM guests only.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/domctl.c | 4 ++--
xen/common/domctl.c | 5 +++--
xen/drivers/passthrough/iommu.c | 3 ++-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1002659..a8325f5 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -416,7 +416,7 @@ long arch_do_domctl(
ret = ioports_permit_access(d, fp, fp + np - 1);
else
ret = ioports_deny_access(d, fp, fp + np - 1);
- if ( !ret )
+ if ( !ret && is_hvm_domain(d) )
memory_type_changed(d);
break;
}
@@ -824,7 +824,7 @@ long arch_do_domctl(
"ioport_map: error %ld denying dom%d access to [%x,%x]\n",
ret, d->domain_id, fmp, fmp + np - 1);
}
- if ( !ret )
+ if ( !ret && is_hvm_domain(d) )
memory_type_changed(d);
break;
}
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 0ef554a..ae99fed 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -977,7 +977,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
else
ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
- if ( !ret )
+ if ( !ret && is_hvm_domain(d) )
memory_type_changed(d);
break;
}
@@ -1037,7 +1037,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
ret, d->domain_id, mfn, mfn_end);
}
/* Do this unconditionally to cover errors on above failure paths. */
- memory_type_changed(d);
+ if ( is_hvm_domain(d) )
+ memory_type_changed(d);
break;
}
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 70d218f..cf5aa20 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -240,7 +240,8 @@ int iommu_construct(struct domain *d)
* memory_type_changed lose effect if memory type changes.
* Call memory_type_changed here to amend this.
*/
- memory_type_changed(d);
+ if ( is_hvm_domain(d) )
+ memory_type_changed(d);
return 0;
}
--
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] 130+ messages in thread* Re: [PATCH 07/34] x86: only call memory_type_changed for HVM guests
2018-08-17 15:12 ` [PATCH 07/34] x86: only call memory_type_changed for HVM guests Wei Liu
@ 2018-08-20 11:57 ` Jan Beulich
2018-08-22 16:12 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-20 11:57 UTC (permalink / raw)
To: Wei Liu
Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -416,7 +416,7 @@ long arch_do_domctl(
> ret = ioports_permit_access(d, fp, fp + np - 1);
> else
> ret = ioports_deny_access(d, fp, fp + np - 1);
> - if ( !ret )
> + if ( !ret && is_hvm_domain(d) )
> memory_type_changed(d);
I think whether to add is_hvm_...() conditionals or whether to introduce
stubs should be selected based on resulting code churn: In the case
here this would seem to suggest a static inline stub is on order. Or
perhaps more generically - if a function already sits solely on is_hvm_...()
guarded code paths, don't introduce a stub, but otherwise probably
introducing a stub is preferable over scattering around new is_hvm_...()
guards.
> @@ -1037,7 +1037,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> ret, d->domain_id, mfn, mfn_end);
> }
> /* Do this unconditionally to cover errors on above failure paths. */
> - memory_type_changed(d);
> + if ( is_hvm_domain(d) )
Hard tab (not that it matters much with the above).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 07/34] x86: only call memory_type_changed for HVM guests
2018-08-20 11:57 ` Jan Beulich
@ 2018-08-22 16:12 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-22 16:12 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 20, 2018 at 05:57:25AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -416,7 +416,7 @@ long arch_do_domctl(
> > ret = ioports_permit_access(d, fp, fp + np - 1);
> > else
> > ret = ioports_deny_access(d, fp, fp + np - 1);
> > - if ( !ret )
> > + if ( !ret && is_hvm_domain(d) )
> > memory_type_changed(d);
>
> I think whether to add is_hvm_...() conditionals or whether to introduce
> stubs should be selected based on resulting code churn: In the case
> here this would seem to suggest a static inline stub is on order. Or
> perhaps more generically - if a function already sits solely on is_hvm_...()
> guarded code paths, don't introduce a stub, but otherwise probably
> introducing a stub is preferable over scattering around new is_hvm_...()
> guards.
If there had been dozens of calls to memory_type_changed I would have
added a stub instead. I will switch to using stubs in the next version.
If a function already sits under is_hvm_* no stub will be needed in the
first place, assuming DCE works properly.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 08/34] x86: enclose hvm_op and dm_op in CONFIG_HVM in PV hypercall table
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (6 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 07/34] x86: only call memory_type_changed for HVM guests Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 11:59 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 09/34] x86: guard HAS_VPCI with CONFIG_HVM Wei Liu
` (27 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 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>
---
xen/arch/x86/pv/hypercall.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index bbc3011..75e6cdb 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -68,7 +68,9 @@ const hypercall_table_t pv_hypercall_table[] = {
#endif
HYPERCALL(event_channel_op),
COMPAT_CALL(physdev_op),
+#ifdef CONFIG_HVM
HYPERCALL(hvm_op),
+#endif
HYPERCALL(sysctl),
HYPERCALL(domctl),
#ifdef CONFIG_KEXEC
@@ -78,7 +80,9 @@ const hypercall_table_t pv_hypercall_table[] = {
HYPERCALL(tmem_op),
#endif
HYPERCALL(xenpmu_op),
+#ifdef CONFIG_HVM
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] 130+ messages in thread* Re: [PATCH 08/34] x86: enclose hvm_op and dm_op in CONFIG_HVM in PV hypercall table
2018-08-17 15:12 ` [PATCH 08/34] x86: enclose hvm_op and dm_op in CONFIG_HVM in PV hypercall table Wei Liu
@ 2018-08-20 11:59 ` Jan Beulich
2018-08-20 13:09 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-20 11:59 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/pv/hypercall.c
> +++ b/xen/arch/x86/pv/hypercall.c
> @@ -68,7 +68,9 @@ const hypercall_table_t pv_hypercall_table[] = {
> #endif
> HYPERCALL(event_channel_op),
> COMPAT_CALL(physdev_op),
> +#ifdef CONFIG_HVM
> HYPERCALL(hvm_op),
> +#endif
> HYPERCALL(sysctl),
> HYPERCALL(domctl),
> #ifdef CONFIG_KEXEC
> @@ -78,7 +80,9 @@ const hypercall_table_t pv_hypercall_table[] = {
> HYPERCALL(tmem_op),
> #endif
> HYPERCALL(xenpmu_op),
> +#ifdef CONFIG_HVM
> COMPAT_CALL(dm_op),
> +#endif
> HYPERCALL(mca),
> HYPERCALL(arch_1),
> };
Is there anything speaking against putting them both into the same
single #ifdef? Also, what about hypercall_args_table[]?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 08/34] x86: enclose hvm_op and dm_op in CONFIG_HVM in PV hypercall table
2018-08-20 11:59 ` Jan Beulich
@ 2018-08-20 13:09 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-20 13:09 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel
On Mon, Aug 20, 2018 at 05:59:38AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/pv/hypercall.c
> > +++ b/xen/arch/x86/pv/hypercall.c
> > @@ -68,7 +68,9 @@ const hypercall_table_t pv_hypercall_table[] = {
> > #endif
> > HYPERCALL(event_channel_op),
> > COMPAT_CALL(physdev_op),
> > +#ifdef CONFIG_HVM
> > HYPERCALL(hvm_op),
> > +#endif
> > HYPERCALL(sysctl),
> > HYPERCALL(domctl),
> > #ifdef CONFIG_KEXEC
> > @@ -78,7 +80,9 @@ const hypercall_table_t pv_hypercall_table[] = {
> > HYPERCALL(tmem_op),
> > #endif
> > HYPERCALL(xenpmu_op),
> > +#ifdef CONFIG_HVM
> > COMPAT_CALL(dm_op),
> > +#endif
> > HYPERCALL(mca),
> > HYPERCALL(arch_1),
> > };
>
> Is there anything speaking against putting them both into the same
> single #ifdef?
No.
> Also, what about hypercall_args_table[]?
Stray entries in hypercall_args_table shouldn't cause any harm, but I
agree we should put them under ifdef as well.
Wei.
>
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 09/34] x86: guard HAS_VPCI with CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (7 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 08/34] x86: enclose hvm_op and dm_op in CONFIG_HVM in PV hypercall table Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 12:03 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 10/34] x86: stub out has_* testing for emulation flags Wei Liu
` (26 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
VPCI is only useful for PVH / HVM guests. Ideally CONFIG_HVM should
imply !PV_SHIM_EXCLUSIVE, but we still want to build PV_SHIM_EXCLUSIVE
with CONFIG_HVM at this stage because a lot of things are still
entangled.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index ba5cb62..73ab8f8 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -23,7 +23,7 @@ config X86
select HAS_PCI
select HAS_PDX
select HAS_UBSAN
- select HAS_VPCI if !PV_SHIM_EXCLUSIVE
+ select HAS_VPCI if !PV_SHIM_EXCLUSIVE && HVM
select NEEDS_LIBELF
select NUMA
--
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] 130+ messages in thread* [PATCH 10/34] x86: stub out has_* testing for emulation flags
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (8 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 09/34] x86: guard HAS_VPCI with CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 12:37 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 11/34] xen/pt: io.c contains HVM only code Wei Liu
` (25 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
Most are all HVM only. Provide stubs for !CONFIG_HVM.
One exception is PIT emulation, which is available to both PV and HVM.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/include/asm-x86/domain.h | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 09f6b3d..4c18054 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -440,6 +440,8 @@ struct arch_domain
uint32_t emulation_flags;
} __cacheline_aligned;
+#ifdef CONFIG_HVM
+
#define has_vlapic(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_LAPIC))
#define has_vhpet(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_HPET))
#define has_vpm(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PM))
@@ -448,11 +450,31 @@ struct arch_domain
#define has_vpic(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIC))
#define has_vvga(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_VGA))
#define has_viommu(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_IOMMU))
-#define has_vpit(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
#define has_pirq(d) (!!((d)->arch.emulation_flags & \
XEN_X86_EMU_USE_PIRQ))
#define has_vpci(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_VPCI))
+#else
+
+#define has_vlapic(d) (0)
+#define has_vhpet(d) (0)
+#define has_vpm(d) (0)
+#define has_vrtc(d) (0)
+#define has_vioapic(d) (0)
+#define has_vpic(d) (0)
+#define has_vvga(d) (0)
+#define has_viommu(d) (0)
+#define has_pirq(d) (0)
+#define has_vpci(d) (0)
+
+#endif
+
+#if CONFIG_HVM || CONFIG_PV
+#define has_vpit(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
+#else
+#define has_vpit(d) (0)
+#endif
+
#define has_arch_pdevs(d) (!list_empty(&(d)->arch.pdev_list))
#define gdt_ldt_pt_idx(v) \
--
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] 130+ messages in thread* Re: [PATCH 10/34] x86: stub out has_* testing for emulation flags
2018-08-17 15:12 ` [PATCH 10/34] x86: stub out has_* testing for emulation flags Wei Liu
@ 2018-08-20 12:37 ` Jan Beulich
2018-08-22 16:43 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-20 12:37 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> Most are all HVM only. Provide stubs for !CONFIG_HVM.
>
> One exception is PIT emulation, which is available to both PV and HVM.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> xen/include/asm-x86/domain.h | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 09f6b3d..4c18054 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -440,6 +440,8 @@ struct arch_domain
> uint32_t emulation_flags;
> } __cacheline_aligned;
>
> +#ifdef CONFIG_HVM
> +
> #define has_vlapic(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_LAPIC))
> #define has_vhpet(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_HPET))
> #define has_vpm(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PM))
> @@ -448,11 +450,31 @@ struct arch_domain
> #define has_vpic(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIC))
> #define has_vvga(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_VGA))
> #define has_viommu(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_IOMMU))
> -#define has_vpit(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
> #define has_pirq(d) (!!((d)->arch.emulation_flags & \
> XEN_X86_EMU_USE_PIRQ))
> #define has_vpci(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_VPCI))
>
> +#else
> +
> +#define has_vlapic(d) (0)
> +#define has_vhpet(d) (0)
> +#define has_vpm(d) (0)
> +#define has_vrtc(d) (0)
> +#define has_vioapic(d) (0)
> +#define has_vpic(d) (0)
> +#define has_vvga(d) (0)
> +#define has_viommu(d) (0)
> +#define has_pirq(d) (0)
> +#define has_vpci(d) (0)
> +
> +#endif
I'm not convinced - this introduces disconnected duplicate logic
(between here and emulation_flags_ok()). If we were to go this
route, I think comments would need to be added on both sides,
each referring to the other one.
Furthermore, if we go this route, then "false" please instead of
"(0)".
> +#if CONFIG_HVM || CONFIG_PV
> +#define has_vpit(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
> +#else
> +#define has_vpit(d) (0)
> +#endif
What purpose would a Xen serve with both HVM and PV disabled?
IOW - I don't think any #if is warranted here.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 10/34] x86: stub out has_* testing for emulation flags
2018-08-20 12:37 ` Jan Beulich
@ 2018-08-22 16:43 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-22 16:43 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel
On Mon, Aug 20, 2018 at 06:37:28AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > Most are all HVM only. Provide stubs for !CONFIG_HVM.
> >
> > One exception is PIT emulation, which is available to both PV and HVM.
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > xen/include/asm-x86/domain.h | 24 +++++++++++++++++++++++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> > index 09f6b3d..4c18054 100644
> > --- a/xen/include/asm-x86/domain.h
> > +++ b/xen/include/asm-x86/domain.h
> > @@ -440,6 +440,8 @@ struct arch_domain
> > uint32_t emulation_flags;
> > } __cacheline_aligned;
> >
> > +#ifdef CONFIG_HVM
> > +
> > #define has_vlapic(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_LAPIC))
> > #define has_vhpet(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_HPET))
> > #define has_vpm(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PM))
> > @@ -448,11 +450,31 @@ struct arch_domain
> > #define has_vpic(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIC))
> > #define has_vvga(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_VGA))
> > #define has_viommu(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_IOMMU))
> > -#define has_vpit(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
> > #define has_pirq(d) (!!((d)->arch.emulation_flags & \
> > XEN_X86_EMU_USE_PIRQ))
> > #define has_vpci(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_VPCI))
> >
> > +#else
> > +
> > +#define has_vlapic(d) (0)
> > +#define has_vhpet(d) (0)
> > +#define has_vpm(d) (0)
> > +#define has_vrtc(d) (0)
> > +#define has_vioapic(d) (0)
> > +#define has_vpic(d) (0)
> > +#define has_vvga(d) (0)
> > +#define has_viommu(d) (0)
> > +#define has_pirq(d) (0)
> > +#define has_vpci(d) (0)
> > +
> > +#endif
>
> I'm not convinced - this introduces disconnected duplicate logic
> (between here and emulation_flags_ok()). If we were to go this
> route, I think comments would need to be added on both sides,
> each referring to the other one.
>
> Furthermore, if we go this route, then "false" please instead of
> "(0)".
This patch can be dropped with adjustment to other files.
>
> > +#if CONFIG_HVM || CONFIG_PV
> > +#define has_vpit(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
> > +#else
> > +#define has_vpit(d) (0)
> > +#endif
>
> What purpose would a Xen serve with both HVM and PV disabled?
> IOW - I don't think any #if is warranted here.
This is useful for developers.
I would certainly build with both PV and HVM disabled in the future to
catch any wrong assumptions that creep into x86 common code.
(Though in this instance the addition here is not needed)
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 11/34] xen/pt: io.c contains HVM only code
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (9 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 10/34] x86: stub out has_* testing for emulation flags Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 12:41 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 12/34] x86/pt: only call some functions for HVM guests Wei Liu
` (24 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Wei Liu, Jan Beulich
We still need to test CONFIG_X86 because Arm also defines CONFIG_HVM.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
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..6b2d2e0 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
+ifeq ($(CONFIG_X86),y)
+obj-$(CONFIG_HVM) += io.o
+endif
obj-$(CONFIG_HAS_PCI) += pci.o
obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
--
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] 130+ messages in thread* Re: [PATCH 11/34] xen/pt: io.c contains HVM only code
2018-08-17 15:12 ` [PATCH 11/34] xen/pt: io.c contains HVM only code Wei Liu
@ 2018-08-20 12:41 ` Jan Beulich
0 siblings, 0 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-20 12:41 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> --- 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
> +ifeq ($(CONFIG_X86),y)
> +obj-$(CONFIG_HVM) += io.o
> +endif
What to do here depends on whether HVM is to become visible
as a config option on ARM: If it doesn't, no ifeq() or alike is
needed here at all. If it does, I'd favor using consistently the
list approach, i.e.
x86-y := ...
x86-$(CONFIG_HVM) += io.o
obj-$(CONFIG_X86) += $(x86-y)
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 12/34] x86/pt: only call some functions for HVM guests
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (10 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 11/34] xen/pt: io.c contains HVM only code Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 12:48 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 13/34] x86/pt: split out HVM functions from vtd.c Wei Liu
` (23 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Kevin Tian, Wei Liu, Jun Nakajima, Jan Beulich
This patch effectively lifts the check out from these functions to its
caller. Asserts are added for safety.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/hvm/vmsi.c | 4 +++-
xen/arch/x86/hvm/vmx/vmx.c | 8 ++++++--
xen/drivers/passthrough/pci.c | 2 +-
xen/drivers/passthrough/vtd/iommu.c | 6 +++---
4 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 3001d5c..39c29d3 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -561,7 +561,9 @@ void msixtbl_init(struct domain *d)
{
struct hvm_io_handler *handler;
- if ( !is_hvm_domain(d) || !has_vlapic(d) || msixtbl_initialised(d) )
+ ASSERT(is_hvm_domain(d));
+
+ if ( !has_vlapic(d) || msixtbl_initialised(d) )
return;
INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 73f0d52..7a3fd62 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -315,7 +315,9 @@ void vmx_pi_hooks_assign(struct domain *d)
{
struct vcpu *v;
- if ( !iommu_intpost || !is_hvm_domain(d) )
+ ASSERT(is_hvm_domain(d));
+
+ if ( !iommu_intpost )
return;
ASSERT(!d->arch.hvm_domain.pi_ops.vcpu_block);
@@ -354,7 +356,9 @@ void vmx_pi_hooks_deassign(struct domain *d)
{
struct vcpu *v;
- if ( !iommu_intpost || !is_hvm_domain(d) )
+ ASSERT(is_hvm_domain(d));
+
+ if ( !iommu_intpost )
return;
ASSERT(d->arch.hvm_domain.pi_ops.vcpu_block);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index c4890a4..9f99fa2 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1439,7 +1439,7 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn, u32 flag)
goto done;
}
- if ( pdev->msix )
+ if ( pdev->msix && is_hvm_domain(d) )
msixtbl_init(d);
pdev->fault.count = 0;
diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
index 1710256..6dcbcf2 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2382,13 +2382,13 @@ static int reassign_device_ownership(
if ( ret )
return ret;
- if ( !has_arch_pdevs(target) )
+ if ( !has_arch_pdevs(target) && is_hvm_domain(target) )
vmx_pi_hooks_assign(target);
ret = domain_context_mapping(target, devfn, pdev);
if ( ret )
{
- if ( !has_arch_pdevs(target) )
+ if ( !has_arch_pdevs(target) && is_hvm_domain(target) )
vmx_pi_hooks_deassign(target);
return ret;
@@ -2400,7 +2400,7 @@ static int reassign_device_ownership(
pdev->domain = target;
}
- if ( !has_arch_pdevs(source) )
+ if ( !has_arch_pdevs(source) && is_hvm_domain(source) )
vmx_pi_hooks_deassign(source);
return ret;
--
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] 130+ messages in thread* Re: [PATCH 12/34] x86/pt: only call some functions for HVM guests
2018-08-17 15:12 ` [PATCH 12/34] x86/pt: only call some functions for HVM guests Wei Liu
@ 2018-08-20 12:48 ` Jan Beulich
2018-08-22 17:08 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-20 12:48 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, Kevin Tian, Jun Nakajima, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
For the subject, do you perhaps mean "call some functions for HVM guests
only"? Otherwise, putting emphasis on "some", the sense gets sort of
inverted from what I think you mean.
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -561,7 +561,9 @@ void msixtbl_init(struct domain *d)
> {
> struct hvm_io_handler *handler;
>
> - if ( !is_hvm_domain(d) || !has_vlapic(d) || msixtbl_initialised(d) )
> + ASSERT(is_hvm_domain(d));
> +
> + if ( !has_vlapic(d) || msixtbl_initialised(d) )
> return;
According to your earlier patch, has_vlapic() implies is_hvm_domain(),
so if anything is to be moved to the caller, then has_vlapic() (and
is_hvm_domain() would then to be dropped altogether). However,
this is again a case where I'm not sure whether adding / extending
if()-s around calls is indeed preferable over adding static inline stubs.
Perhaps for the specific one here either variant is about as much (or
as little) code churn, but for the PI hooks functions I think the stub
approach might be slightly better.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 12/34] x86/pt: only call some functions for HVM guests
2018-08-20 12:48 ` Jan Beulich
@ 2018-08-22 17:08 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-22 17:08 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Kevin Tian, Wei Liu, Jun Nakajima, xen-devel
On Mon, Aug 20, 2018 at 06:48:58AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
>
> According to your earlier patch, has_vlapic() implies is_hvm_domain(),
> so if anything is to be moved to the caller, then has_vlapic() (and
> is_hvm_domain() would then to be dropped altogether). However,
> this is again a case where I'm not sure whether adding / extending
> if()-s around calls is indeed preferable over adding static inline stubs.
> Perhaps for the specific one here either variant is about as much (or
> as little) code churn, but for the PI hooks functions I think the stub
> approach might be slightly better.
OK. I will put together some stubs.
Wei.
>
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 13/34] x86/pt: split out HVM functions from vtd.c
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (11 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 12/34] x86/pt: only call some functions for HVM guests Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 12:05 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 14/34] x86/pt: add HVM check to XEN_DOMCTL_unbind_pt_irq Wei Liu
` (22 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 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>
---
xen/drivers/passthrough/vtd/x86/Makefile | 3 +-
xen/drivers/passthrough/vtd/x86/hvm.c | 77 +++++++++++++++++++++++++-
xen/drivers/passthrough/vtd/x86/vtd.c | 45 +---------------
3 files changed, 79 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..b71b3a7
--- /dev/null
+++ b/xen/drivers/passthrough/vtd/x86/hvm.c
@@ -0,0 +1,77 @@
+/*
+ * 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/sched.h>
+#include <xen/softirq.h>
+#include <xen/domain_page.h>
+#include <asm/paging.h>
+#include <xen/iommu.h>
+#include <xen/irq.h>
+#include <xen/numa.h>
+#include <asm/fixmap.h>
+#include <asm/setup.h>
+#include "../iommu.h"
+#include "../dmar.h"
+#include "../vtd.h"
+#include "../extern.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] 130+ messages in thread* Re: [PATCH 13/34] x86/pt: split out HVM functions from vtd.c
2018-08-17 15:12 ` [PATCH 13/34] x86/pt: split out HVM functions from vtd.c Wei Liu
@ 2018-08-20 12:05 ` Jan Beulich
2018-08-21 10:30 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-20 12:05 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, Kevin Tian
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> --- /dev/null
> +++ b/xen/drivers/passthrough/vtd/x86/hvm.c
> @@ -0,0 +1,77 @@
> +/*
> + * 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/sched.h>
> +#include <xen/softirq.h>
> +#include <xen/domain_page.h>
> +#include <asm/paging.h>
> +#include <xen/iommu.h>
> +#include <xen/irq.h>
> +#include <xen/numa.h>
> +#include <asm/fixmap.h>
> +#include <asm/setup.h>
> +#include "../iommu.h"
> +#include "../dmar.h"
> +#include "../vtd.h"
> +#include "../extern.h"
This is a whole lot of includes for the poor two functions you move:
Are they really all needed? And in any event may I remind you of
our general attempt to sort includes at least in new sources?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 13/34] x86/pt: split out HVM functions from vtd.c
2018-08-20 12:05 ` Jan Beulich
@ 2018-08-21 10:30 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-21 10:30 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Kevin Tian, Wei Liu
On Mon, Aug 20, 2018 at 06:05:13AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > --- /dev/null
> > +++ b/xen/drivers/passthrough/vtd/x86/hvm.c
> > @@ -0,0 +1,77 @@
> > +/*
> > + * 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/sched.h>
> > +#include <xen/softirq.h>
> > +#include <xen/domain_page.h>
> > +#include <asm/paging.h>
> > +#include <xen/iommu.h>
> > +#include <xen/irq.h>
> > +#include <xen/numa.h>
> > +#include <asm/fixmap.h>
> > +#include <asm/setup.h>
> > +#include "../iommu.h"
> > +#include "../dmar.h"
> > +#include "../vtd.h"
> > +#include "../extern.h"
>
> This is a whole lot of includes for the poor two functions you move:
> Are they really all needed? And in any event may I remind you of
> our general attempt to sort includes at least in new sources?
OK. I will try to reduce the number of includes here. And also sort
them.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 14/34] x86/pt: add HVM check to XEN_DOMCTL_unbind_pt_irq
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (12 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 13/34] x86/pt: split out HVM functions from vtd.c Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 12:51 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 15/34] x86/nestedhvm: make it build with !CONFIG_HVM Wei Liu
` (21 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
Its counterpart is HVM only. Add the check to help dead code
elimination to figure out the call to pt_irq_destroy_bind is not
needed when HVM is not enabled.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/domctl.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index a8325f5..4869e88 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -715,6 +715,10 @@ long arch_do_domctl(
struct xen_domctl_bind_pt_irq *bind = &domctl->u.bind_pt_irq;
int irq = domain_pirq_to_irq(d, bind->machine_irq);
+ ret = -EINVAL;
+ if ( !is_hvm_domain(d) )
+ break;
+
ret = -EPERM;
if ( irq <= 0 || !irq_access_permitted(currd, irq) )
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] 130+ messages in thread* [PATCH 15/34] x86/nestedhvm: make it build with !CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (13 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 14/34] x86/pt: add HVM check to XEN_DOMCTL_unbind_pt_irq Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 12:57 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 16/34] x86/hvm: enclose hvm_enabled and hvm_funcs in CONFIG_HVM Wei Liu
` (20 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: George Dunlap, Andrew Cooper, Wei Liu, Jan Beulich
Make two functions static inline so that they can be referenced in p2m
code. Check nestedhvm is enabled before calling
nestedhvm_vmcx_flushtlb (which also has a side effect of not issuing
unnecessary IPIs for non-nested case).
While moving, reformat code and use proper boolean.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/hvm/nestedhvm.c | 21 ---------------------
xen/arch/x86/mm/p2m.c | 3 ++-
xen/include/asm-x86/hvm/nestedhvm.h | 19 +++++++++++++++++--
3 files changed, 19 insertions(+), 24 deletions(-)
diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index ab50b2a..bd11019 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -26,13 +26,6 @@
static unsigned long *shadow_io_bitmap[3];
-/* Nested HVM on/off per domain */
-bool nestedhvm_enabled(const struct domain *d)
-{
- return is_hvm_domain(d) && d->arch.hvm_domain.params &&
- d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM];
-}
-
/* Nested VCPU */
bool_t
nestedhvm_vcpu_in_guestmode(struct vcpu *v)
@@ -120,20 +113,6 @@ nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
cpumask_clear(p2m->dirty_cpumask);
}
-bool_t
-nestedhvm_is_n2(struct vcpu *v)
-{
- if (!nestedhvm_enabled(v->domain)
- || nestedhvm_vmswitch_in_progress(v)
- || !nestedhvm_paging_mode_hap(v))
- return 0;
-
- if (nestedhvm_vcpu_in_guestmode(v))
- return 1;
-
- return 0;
-}
-
/* Common shadow IO Permission bitmap */
/* There four global patterns of io bitmap each guest can
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 8e9fbb5..1089b86 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1756,7 +1756,8 @@ p2m_flush_table_locked(struct p2m_domain *p2m)
p2m->np2m_generation++;
/* Make sure nobody else is using this p2m table */
- nestedhvm_vmcx_flushtlb(p2m);
+ if ( nestedhvm_enabled(d) )
+ nestedhvm_vmcx_flushtlb(p2m);
/* Zap the top level of the trie */
mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
diff --git a/xen/include/asm-x86/hvm/nestedhvm.h b/xen/include/asm-x86/hvm/nestedhvm.h
index 47165fc..c7003dd 100644
--- a/xen/include/asm-x86/hvm/nestedhvm.h
+++ b/xen/include/asm-x86/hvm/nestedhvm.h
@@ -33,7 +33,11 @@ enum nestedhvm_vmexits {
};
/* Nested HVM on/off per domain */
-bool nestedhvm_enabled(const struct domain *d);
+static inline bool nestedhvm_enabled(const struct domain *d)
+{
+ return is_hvm_domain(d) && d->arch.hvm_domain.params &&
+ d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM];
+}
/* Nested VCPU */
int nestedhvm_vcpu_initialise(struct vcpu *v);
@@ -70,7 +74,18 @@ unsigned long *nestedhvm_vcpu_iomap_get(bool_t ioport_80, bool_t ioport_ed);
void nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m);
-bool_t nestedhvm_is_n2(struct vcpu *v);
+static inline bool nestedhvm_is_n2(struct vcpu *v)
+{
+ if ( !nestedhvm_enabled(v->domain) ||
+ nestedhvm_vmswitch_in_progress(v) ||
+ !nestedhvm_paging_mode_hap(v) )
+ return false;
+
+ if ( nestedhvm_vcpu_in_guestmode(v) )
+ return true;
+
+ return false;
+}
static inline void nestedhvm_set_cr(struct vcpu *v, unsigned int cr,
unsigned long value)
--
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] 130+ messages in thread* Re: [PATCH 15/34] x86/nestedhvm: make it build with !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 15/34] x86/nestedhvm: make it build with !CONFIG_HVM Wei Liu
@ 2018-08-20 12:57 ` Jan Beulich
0 siblings, 0 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-20 12:57 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
The title isn't very consistent within itself: Nested-HVM code is certainly
not to be built without CONFIG_HVM.
> @@ -70,7 +74,18 @@ unsigned long *nestedhvm_vcpu_iomap_get(bool_t ioport_80, bool_t ioport_ed);
>
> void nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m);
>
> -bool_t nestedhvm_is_n2(struct vcpu *v);
> +static inline bool nestedhvm_is_n2(struct vcpu *v)
I'm tempted to suggest the parameter could be constified, but it
looks like this would require some const additions elsewhere first.
> +{
> + if ( !nestedhvm_enabled(v->domain) ||
> + nestedhvm_vmswitch_in_progress(v) ||
> + !nestedhvm_paging_mode_hap(v) )
> + return false;
> +
> + if ( nestedhvm_vcpu_in_guestmode(v) )
> + return true;
> +
> + return false;
Can the last four lines be a single return statement please? With
that
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] 130+ messages in thread
* [PATCH 16/34] x86/hvm: enclose hvm_enabled and hvm_funcs in CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (14 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 15/34] x86/nestedhvm: make it build with !CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 13:04 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 17/34] x86/vmce: enclose HVM load / save code " Wei Liu
` (19 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
This helps to take advantage of dead code elimination. Turn
hvm_enabled into proper bool while at it.
Providing an empty hvm_funcs resolves a lot of undefined references to
it in the header. It is safe to do so because those functions / macros
are not expected to be used.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/include/asm-x86/hvm/hvm.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 146720c..b3bc8d2 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -234,8 +234,14 @@ struct hvm_function_table {
} tsc_scaling;
};
+#if CONFIG_HVM
+extern bool hvm_enabled;
extern struct hvm_function_table hvm_funcs;
-extern bool_t hvm_enabled;
+#else
+#define hvm_enabled false
+static struct hvm_function_table hvm_funcs = {};
+#endif
+
extern s8 hvm_port80_allowed;
extern const struct hvm_function_table *start_svm(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] 130+ messages in thread* Re: [PATCH 16/34] x86/hvm: enclose hvm_enabled and hvm_funcs in CONFIG_HVM
2018-08-17 15:12 ` [PATCH 16/34] x86/hvm: enclose hvm_enabled and hvm_funcs in CONFIG_HVM Wei Liu
@ 2018-08-20 13:04 ` Jan Beulich
2018-08-24 16:25 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-20 13:04 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> This helps to take advantage of dead code elimination. Turn
> hvm_enabled into proper bool while at it.
>
> Providing an empty hvm_funcs resolves a lot of undefined references to
> it in the header. It is safe to do so because those functions / macros
> are not expected to be used.
"not expected to be used" != "not used". This ...
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -234,8 +234,14 @@ struct hvm_function_table {
> } tsc_scaling;
> };
>
> +#if CONFIG_HVM
> +extern bool hvm_enabled;
> extern struct hvm_function_table hvm_funcs;
> -extern bool_t hvm_enabled;
> +#else
> +#define hvm_enabled false
> +static struct hvm_function_table hvm_funcs = {};
... is a no-go imo. Either keep the extern visible (but don't have a
definition anywhere, relying on DCE once again), or make sure the
structure has no members at all in the !HVM case (but that would
assume the references you talk about aren't field accesses, but
only accesses to the entire structure). Otherwise we'd end up
with a significant amount of NULL pointers.
But in the end it's not really clear to me what problem you're trying
to solve: The header here should not be included at all when HVM
is not enabled (or most of it be inside "#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] 130+ messages in thread* Re: [PATCH 16/34] x86/hvm: enclose hvm_enabled and hvm_funcs in CONFIG_HVM
2018-08-20 13:04 ` Jan Beulich
@ 2018-08-24 16:25 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-24 16:25 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel
On Mon, Aug 20, 2018 at 07:04:09AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > This helps to take advantage of dead code elimination. Turn
> > hvm_enabled into proper bool while at it.
> >
> > Providing an empty hvm_funcs resolves a lot of undefined references to
> > it in the header. It is safe to do so because those functions / macros
> > are not expected to be used.
>
> "not expected to be used" != "not used". This ...
>
> > --- a/xen/include/asm-x86/hvm/hvm.h
> > +++ b/xen/include/asm-x86/hvm/hvm.h
> > @@ -234,8 +234,14 @@ struct hvm_function_table {
> > } tsc_scaling;
> > };
> >
> > +#if CONFIG_HVM
> > +extern bool hvm_enabled;
> > extern struct hvm_function_table hvm_funcs;
> > -extern bool_t hvm_enabled;
> > +#else
> > +#define hvm_enabled false
> > +static struct hvm_function_table hvm_funcs = {};
>
> ... is a no-go imo. Either keep the extern visible (but don't have a
> definition anywhere, relying on DCE once again), or make sure the
> structure has no members at all in the !HVM case (but that would
> assume the references you talk about aren't field accesses, but
> only accesses to the entire structure). Otherwise we'd end up
> with a significant amount of NULL pointers.
>
> But in the end it's not really clear to me what problem you're trying
> to solve: The header here should not be included at all when HVM
> is not enabled (or most of it be inside "#ifdef CONFIG_HVM").
This patch has been rewritten to provide more stubs etc.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 17/34] x86/vmce: enclose HVM load / save code in CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (15 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 16/34] x86/hvm: enclose hvm_enabled and hvm_funcs in CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 13:04 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 18/34] x86/amd: skip OSVW function calls if !CONFIG_HVM Wei Liu
` (18 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 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/cpu/mcheck/vmce.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index e07cd2f..467125b 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -349,6 +349,7 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
return ret;
}
+#if CONFIG_HVM
static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
{
struct vcpu *v;
@@ -392,6 +393,7 @@ static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+#endif
/*
* for Intel MCE, broadcast vMCE to all vcpus
--
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] 130+ messages in thread* [PATCH 18/34] x86/amd: skip OSVW function calls if !CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (16 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 17/34] x86/vmce: enclose HVM load / save code " Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 13:06 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 19/34] x86: check HVM before trying to get ioreq server Wei Liu
` (17 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
The two functions are not needed when HVM is not supported in
hypervisor.
Note that using hvm_enabled won't work because early_microcode_init
gets to cpu_request_microcode before hvm_enabled is set in presmp init
call stage.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/microcode_amd.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
index 53f9f54..fba44cc 100644
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -550,7 +550,9 @@ static int cpu_request_microcode(unsigned int cpu, const void *buf,
xfree(mc_old);
out:
+#if CONFIG_HVM
svm_host_osvw_init();
+#endif
/*
* In some cases we may return an error even if processor's microcode has
@@ -609,6 +611,7 @@ err1:
static int start_update(void)
{
+#if CONFIG_HVM
/*
* We assume here that svm_host_osvw_init() will be called on each cpu (from
* cpu_request_microcode()).
@@ -619,6 +622,7 @@ static int start_update(void)
* supporting OSVW so we will not deal with this possibility.
*/
svm_host_osvw_reset();
+#endif
return 0;
}
--
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] 130+ messages in thread* [PATCH 19/34] x86: check HVM before trying to get ioreq server
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (17 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 18/34] x86/amd: skip OSVW function calls if !CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 13:08 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 20/34] x86/mtrr: move is_var_mtrr_overlapped Wei Liu
` (16 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
This helps with dead code elimination. No functional change.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/mm.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 8ac4412..f3fa6ce 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4382,6 +4382,10 @@ int arch_acquire_resource(struct domain *d, unsigned int type,
unsigned int i;
rc = -EINVAL;
+ if ( !is_hvm_domain(d) )
+ break;
+
+ rc = -EINVAL;
if ( id != (unsigned int)ioservid )
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] 130+ messages in thread* [PATCH 20/34] x86/mtrr: move is_var_mtrr_overlapped
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (18 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 19/34] x86: check HVM before trying to get ioreq server Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 7:58 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 21/34] x86/mm: p2m_flush and nvcpu_flush are HVM only Wei Liu
` (15 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
Move it to x86 generic code. While at it, use proper boolean type.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/cpu/mtrr/generic.c | 31 +++++++++++++++++++++++++++++++
xen/arch/x86/hvm/mtrr.c | 31 -------------------------------
xen/include/asm-x86/mtrr.h | 2 +-
3 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index 0976365..499d5f4 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -51,6 +51,37 @@ get_fixed_ranges(mtrr_type * frs)
}
}
+bool is_var_mtrr_overlapped(const struct mtrr_state *m)
+{
+ unsigned int seg, i;
+ unsigned int num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
+
+ for ( i = 0; i < num_var_ranges; i++ )
+ {
+ uint64_t base1 = m->var_ranges[i].base >> PAGE_SHIFT;
+ uint64_t mask1 = m->var_ranges[i].mask >> PAGE_SHIFT;
+
+ if ( !(m->var_ranges[i].mask & MTRR_PHYSMASK_VALID) )
+ continue;
+
+ for ( seg = i + 1; seg < num_var_ranges; seg ++ )
+ {
+ uint64_t base2 = m->var_ranges[seg].base >> PAGE_SHIFT;
+ uint64_t mask2 = m->var_ranges[seg].mask >> PAGE_SHIFT;
+
+ if ( !(m->var_ranges[seg].mask & MTRR_PHYSMASK_VALID) )
+ continue;
+
+ if ( (base1 & mask1 & mask2) == (base2 & mask2 & mask1) )
+ {
+ /* MTRR is overlapped. */
+ return true;
+ }
+ }
+ }
+ return false;
+}
+
void mtrr_save_fixed_ranges(void *info)
{
get_fixed_ranges(mtrr_state.fixed_ranges);
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index c502dda..edfe5cd 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -75,37 +75,6 @@ static uint8_t __read_mostly mtrr_epat_tbl[MTRR_NUM_TYPES][MEMORY_NUM_TYPES] =
static uint8_t __read_mostly pat_entry_tbl[PAT_TYPE_NUMS] =
{ [0 ... PAT_TYPE_NUMS-1] = INVALID_MEM_TYPE };
-bool_t is_var_mtrr_overlapped(const struct mtrr_state *m)
-{
- unsigned int seg, i;
- unsigned int num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
-
- for ( i = 0; i < num_var_ranges; i++ )
- {
- uint64_t base1 = m->var_ranges[i].base >> PAGE_SHIFT;
- uint64_t mask1 = m->var_ranges[i].mask >> PAGE_SHIFT;
-
- if ( !(m->var_ranges[i].mask & MTRR_PHYSMASK_VALID) )
- continue;
-
- for ( seg = i + 1; seg < num_var_ranges; seg ++ )
- {
- uint64_t base2 = m->var_ranges[seg].base >> PAGE_SHIFT;
- uint64_t mask2 = m->var_ranges[seg].mask >> PAGE_SHIFT;
-
- if ( !(m->var_ranges[seg].mask & MTRR_PHYSMASK_VALID) )
- continue;
-
- if ( (base1 & mask1 & mask2) == (base2 & mask2 & mask1) )
- {
- /* MTRR is overlapped. */
- return 1;
- }
- }
- }
- return 0;
-}
-
static int __init hvm_mtrr_pat_init(void)
{
unsigned int i, j;
diff --git a/xen/include/asm-x86/mtrr.h b/xen/include/asm-x86/mtrr.h
index 72d0690..7edcb94 100644
--- a/xen/include/asm-x86/mtrr.h
+++ b/xen/include/asm-x86/mtrr.h
@@ -95,7 +95,7 @@ extern bool_t mtrr_def_type_msr_set(struct domain *, struct mtrr_state *,
extern void memory_type_changed(struct domain *);
extern bool_t pat_msr_set(uint64_t *pat, uint64_t msr);
-bool_t is_var_mtrr_overlapped(const struct mtrr_state *m);
+bool is_var_mtrr_overlapped(const struct mtrr_state *m);
bool mtrr_pat_not_equal(const struct vcpu *vd, const struct vcpu *vs);
#endif /* __ASM_X86_MTRR_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] 130+ messages in thread* Re: [PATCH 20/34] x86/mtrr: move is_var_mtrr_overlapped
2018-08-17 15:12 ` [PATCH 20/34] x86/mtrr: move is_var_mtrr_overlapped Wei Liu
@ 2018-08-21 7:58 ` Jan Beulich
2018-08-21 14:12 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 7:58 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> Move it to x86 generic code. While at it, use proper boolean type.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
with a couple of cosmetic adjustments beyond the bool
conversion you've already done:
> +bool is_var_mtrr_overlapped(const struct mtrr_state *m)
> +{
> + unsigned int seg, i;
> + unsigned int num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
> +
> + for ( i = 0; i < num_var_ranges; i++ )
> + {
> + uint64_t base1 = m->var_ranges[i].base >> PAGE_SHIFT;
> + uint64_t mask1 = m->var_ranges[i].mask >> PAGE_SHIFT;
Here and below I wonder whether PFN_DOWN() wouldn't be
appropriate to use. I'll leave that up to you though.
> + if ( !(m->var_ranges[i].mask & MTRR_PHYSMASK_VALID) )
> + continue;
> +
> + for ( seg = i + 1; seg < num_var_ranges; seg ++ )
Stray blank before ++.
> + {
> + uint64_t base2 = m->var_ranges[seg].base >> PAGE_SHIFT;
> + uint64_t mask2 = m->var_ranges[seg].mask >> PAGE_SHIFT;
> +
> + if ( !(m->var_ranges[seg].mask & MTRR_PHYSMASK_VALID) )
> + continue;
> +
> + if ( (base1 & mask1 & mask2) == (base2 & mask2 & mask1) )
> + {
> + /* MTRR is overlapped. */
"MTRRs overlap" or some such.
> + return true;
> + }
> + }
> + }
> + return false;
> +}
Blank line ahead of main "return" please.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 20/34] x86/mtrr: move is_var_mtrr_overlapped
2018-08-21 7:58 ` Jan Beulich
@ 2018-08-21 14:12 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-21 14:12 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel
On Tue, Aug 21, 2018 at 01:58:51AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > Move it to x86 generic code. While at it, use proper boolean type.
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> with a couple of cosmetic adjustments beyond the bool
> conversion you've already done:
>
> > +bool is_var_mtrr_overlapped(const struct mtrr_state *m)
> > +{
> > + unsigned int seg, i;
> > + unsigned int num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
> > +
> > + for ( i = 0; i < num_var_ranges; i++ )
> > + {
> > + uint64_t base1 = m->var_ranges[i].base >> PAGE_SHIFT;
> > + uint64_t mask1 = m->var_ranges[i].mask >> PAGE_SHIFT;
>
> Here and below I wonder whether PFN_DOWN() wouldn't be
> appropriate to use. I'll leave that up to you though.
>
Since base and mask aren't really PFN so I think it would be more
appropriate to leave them as-is.
I have fixed up the other two issues you mentioned.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 21/34] x86/mm: p2m_flush and nvcpu_flush are HVM only
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (19 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 20/34] x86/mtrr: move is_var_mtrr_overlapped Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 8:01 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM Wei Liu
` (14 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: George Dunlap, Andrew Cooper, Wei Liu, Jan Beulich
p2m_flush is only called by HAP code, nvcpu_flush is only useful for
nestedhvm, both of which depend on HVM support.
Enclose their code in CONFIG_HVM. Add assertions.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/mm/p2m.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 1089b86..1a04b34 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1785,10 +1785,13 @@ p2m_flush_table(struct p2m_domain *p2m)
void
p2m_flush(struct vcpu *v, struct p2m_domain *p2m)
{
+#if CONFIG_HVM
+ ASSERT(is_hvm_vcpu(v));
ASSERT(v->domain == p2m->domain);
vcpu_nestedhvm(v).nv_p2m = NULL;
p2m_flush_table(p2m);
hvm_asid_flush_vcpu(v);
+#endif
}
void
@@ -1839,8 +1842,11 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m)
static void nvcpu_flush(struct vcpu *v)
{
+#if CONFIG_HVM
+ ASSERT(is_hvm_vcpu(v));
hvm_asid_flush_vcpu(v);
vcpu_nestedhvm(v).stale_np2m = true;
+#endif
}
struct p2m_domain *
--
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] 130+ messages in thread* Re: [PATCH 21/34] x86/mm: p2m_flush and nvcpu_flush are HVM only
2018-08-17 15:12 ` [PATCH 21/34] x86/mm: p2m_flush and nvcpu_flush are HVM only Wei Liu
@ 2018-08-21 8:01 ` Jan Beulich
2018-08-22 14:14 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 8:01 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> p2m_flush is only called by HAP code, nvcpu_flush is only useful for
> nestedhvm, both of which depend on HVM support.
>
> Enclose their code in CONFIG_HVM. Add assertions.
But why do you put the #ifdef-s inside the functions, rather than
around them? From what you say, without CONFIG_HVM no caller
should exist.
Jan
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> xen/arch/x86/mm/p2m.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 1089b86..1a04b34 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1785,10 +1785,13 @@ p2m_flush_table(struct p2m_domain *p2m)
> void
> p2m_flush(struct vcpu *v, struct p2m_domain *p2m)
> {
> +#if CONFIG_HVM
> + ASSERT(is_hvm_vcpu(v));
> ASSERT(v->domain == p2m->domain);
> vcpu_nestedhvm(v).nv_p2m = NULL;
> p2m_flush_table(p2m);
> hvm_asid_flush_vcpu(v);
> +#endif
> }
>
> void
> @@ -1839,8 +1842,11 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m)
>
> static void nvcpu_flush(struct vcpu *v)
> {
> +#if CONFIG_HVM
> + ASSERT(is_hvm_vcpu(v));
> hvm_asid_flush_vcpu(v);
> vcpu_nestedhvm(v).stale_np2m = true;
> +#endif
> }
>
> struct p2m_domain *
> --
> 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] 130+ messages in thread* Re: [PATCH 21/34] x86/mm: p2m_flush and nvcpu_flush are HVM only
2018-08-21 8:01 ` Jan Beulich
@ 2018-08-22 14:14 ` Wei Liu
2018-08-24 17:19 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-22 14:14 UTC (permalink / raw)
To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Wei Liu, xen-devel
On Tue, Aug 21, 2018 at 02:01:12AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > p2m_flush is only called by HAP code, nvcpu_flush is only useful for
> > nestedhvm, both of which depend on HVM support.
> >
> > Enclose their code in CONFIG_HVM. Add assertions.
>
> But why do you put the #ifdef-s inside the functions, rather than
> around them? From what you say, without CONFIG_HVM no caller
> should exist.
>
> Jan
>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > xen/arch/x86/mm/p2m.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > index 1089b86..1a04b34 100644
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -1785,10 +1785,13 @@ p2m_flush_table(struct p2m_domain *p2m)
> > void
> > p2m_flush(struct vcpu *v, struct p2m_domain *p2m)
This is called by HAP code which I didn't put under CONFIG_HVM yet.
I will see about reworking that part to put HAP under CONFIG_HVM.
> > {
> > +#if CONFIG_HVM
> > + ASSERT(is_hvm_vcpu(v));
> > ASSERT(v->domain == p2m->domain);
> > vcpu_nestedhvm(v).nv_p2m = NULL;
> > p2m_flush_table(p2m);
> > hvm_asid_flush_vcpu(v);
> > +#endif
> > }
> >
> > void
> > @@ -1839,8 +1842,11 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m)
> >
> > static void nvcpu_flush(struct vcpu *v)
This is referenced by another HVM function. Maybe I can reshuffle code a
bit more to make it work.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 21/34] x86/mm: p2m_flush and nvcpu_flush are HVM only
2018-08-22 14:14 ` Wei Liu
@ 2018-08-24 17:19 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-24 17:19 UTC (permalink / raw)
To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Wei Liu, xen-devel
On Wed, Aug 22, 2018 at 03:14:12PM +0100, Wei Liu wrote:
> On Tue, Aug 21, 2018 at 02:01:12AM -0600, Jan Beulich wrote:
> > >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > > p2m_flush is only called by HAP code, nvcpu_flush is only useful for
> > > nestedhvm, both of which depend on HVM support.
> > >
> > > Enclose their code in CONFIG_HVM. Add assertions.
> >
> > But why do you put the #ifdef-s inside the functions, rather than
> > around them? From what you say, without CONFIG_HVM no caller
> > should exist.
> >
> > Jan
> >
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > > xen/arch/x86/mm/p2m.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > > index 1089b86..1a04b34 100644
> > > --- a/xen/arch/x86/mm/p2m.c
> > > +++ b/xen/arch/x86/mm/p2m.c
> > > @@ -1785,10 +1785,13 @@ p2m_flush_table(struct p2m_domain *p2m)
> > > void
> > > p2m_flush(struct vcpu *v, struct p2m_domain *p2m)
>
> This is called by HAP code which I didn't put under CONFIG_HVM yet.
>
> I will see about reworking that part to put HAP under CONFIG_HVM.
>
> > > {
> > > +#if CONFIG_HVM
> > > + ASSERT(is_hvm_vcpu(v));
> > > ASSERT(v->domain == p2m->domain);
> > > vcpu_nestedhvm(v).nv_p2m = NULL;
> > > p2m_flush_table(p2m);
> > > hvm_asid_flush_vcpu(v);
> > > +#endif
> > > }
> > >
> > > void
> > > @@ -1839,8 +1842,11 @@ static void assign_np2m(struct vcpu *v, struct p2m_domain *p2m)
> > >
> > > static void nvcpu_flush(struct vcpu *v)
>
> This is referenced by another HVM function. Maybe I can reshuffle code a
> bit more to make it work.
It appears that more code can be put under CONFIG_HVM. I have done that.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (20 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 21/34] x86/mm: p2m_flush and nvcpu_flush are HVM only Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-19 16:27 ` Razvan Cojocaru
2018-08-21 8:07 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 23/34] x86/oprofile: put SVM " Wei Liu
` (13 subsequent siblings)
35 siblings, 2 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel
Cc: Tamas K Lengyel, Wei Liu, Razvan Cojocaru, George Dunlap,
Andrew Cooper, Jan Beulich
Going through the code, nested EPT, EPT, 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 | 5 +++--
xen/arch/x86/mm/hap/Makefile | 2 +-
xen/arch/x86/mm/p2m.c | 17 ++++++++++-------
xen/common/vm_event.c | 2 ++
xen/include/asm-x86/hvm/domain.h | 4 ++++
5 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index 3017119..156a321 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -2,8 +2,9 @@ subdir-y += shadow
subdir-y += 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 p2m-pod.o
+obj-$(CONFIG_HVM) += p2m-ept.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/hap/Makefile b/xen/arch/x86/mm/hap/Makefile
index b14a9af..a8e44de 100644
--- a/xen/arch/x86/mm/hap/Makefile
+++ b/xen/arch/x86/mm/hap/Makefile
@@ -3,7 +3,7 @@ obj-y += guest_walk_2level.o
obj-y += guest_walk_3level.o
obj-y += guest_walk_4level.o
obj-y += nested_hap.o
-obj-y += nested_ept.o
+obj-$(CONFIG_HVM) += nested_ept.o
guest_walk_%level.o: guest_walk.c Makefile
$(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 1a04b34..2111cb6 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -531,7 +531,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;
@@ -1708,12 +1708,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);
-}
-
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;
}
+#if 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..2824673 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);
+#if 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..8d28b54 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -202,7 +202,11 @@ struct hvm_domain {
};
};
+#if 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] 130+ messages in thread* Re: [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM
2018-08-17 15:12 ` [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM Wei Liu
@ 2018-08-19 16:27 ` Razvan Cojocaru
2018-08-24 16:25 ` Wei Liu
2018-08-21 8:07 ` Jan Beulich
1 sibling, 1 reply; 130+ messages in thread
From: Razvan Cojocaru @ 2018-08-19 16:27 UTC (permalink / raw)
To: Wei Liu, xen-devel
Cc: George Dunlap, Andrew Cooper, Tamas K Lengyel, Jan Beulich
On 8/17/18 6:12 PM, Wei Liu wrote:
> Going through the code, nested EPT, EPT, 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 | 5 +++--
> xen/arch/x86/mm/hap/Makefile | 2 +-
> xen/arch/x86/mm/p2m.c | 17 ++++++++++-------
> xen/common/vm_event.c | 2 ++
> xen/include/asm-x86/hvm/domain.h | 4 ++++
> 5 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
> index 3017119..156a321 100644
> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -2,8 +2,9 @@ subdir-y += shadow
> subdir-y += 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 p2m-pod.o
> +obj-$(CONFIG_HVM) += p2m-ept.o
> +obj-$(CONFIG_HVM) += altp2m.o
I am able to compile xen.gz by running make in xen/ with no issues with
the following patch applied:
diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index 930bdc2669..b2867fdaf7 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -15,8 +15,6 @@
* this program; If not, see <http://www.gnu.org/licenses/>.
*/
-#include <asm/hvm/support.h>
-#include <asm/hvm/hvm.h>
#include <asm/p2m.h>
#include <asm/altp2m.h>
So I wonder if those includes are simply leftovers that, once removed,
would simplify your patch.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 130+ messages in thread
* Re: [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM
2018-08-19 16:27 ` Razvan Cojocaru
@ 2018-08-24 16:25 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-24 16:25 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: Tamas K Lengyel, Wei Liu, George Dunlap, Andrew Cooper,
Jan Beulich, xen-devel
On Sun, Aug 19, 2018 at 07:27:22PM +0300, Razvan Cojocaru wrote:
> On 8/17/18 6:12 PM, Wei Liu wrote:
> > Going through the code, nested EPT, EPT, 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 | 5 +++--
> > xen/arch/x86/mm/hap/Makefile | 2 +-
> > xen/arch/x86/mm/p2m.c | 17 ++++++++++-------
> > xen/common/vm_event.c | 2 ++
> > xen/include/asm-x86/hvm/domain.h | 4 ++++
> > 5 files changed, 20 insertions(+), 10 deletions(-)
> >
> > diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
> > index 3017119..156a321 100644
> > --- a/xen/arch/x86/mm/Makefile
> > +++ b/xen/arch/x86/mm/Makefile
> > @@ -2,8 +2,9 @@ subdir-y += shadow
> > subdir-y += 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 p2m-pod.o
> > +obj-$(CONFIG_HVM) += p2m-ept.o
> > +obj-$(CONFIG_HVM) += altp2m.o
>
> I am able to compile xen.gz by running make in xen/ with no issues with
> the following patch applied:
>
> diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
> index 930bdc2669..b2867fdaf7 100644
> --- a/xen/arch/x86/mm/altp2m.c
> +++ b/xen/arch/x86/mm/altp2m.c
> @@ -15,8 +15,6 @@
> * this program; If not, see <http://www.gnu.org/licenses/>.
> */
>
> -#include <asm/hvm/support.h>
> -#include <asm/hvm/hvm.h>
> #include <asm/p2m.h>
> #include <asm/altp2m.h>
>
> So I wonder if those includes are simply leftovers that, once removed,
> would simplify your patch.
This is a good improvement in and of itself but I don't think it will
affect my work here.
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] 130+ messages in thread
* Re: [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM
2018-08-17 15:12 ` [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM Wei Liu
2018-08-19 16:27 ` Razvan Cojocaru
@ 2018-08-21 8:07 ` Jan Beulich
2018-08-22 14:14 ` Wei Liu
2018-08-24 17:05 ` Wei Liu
1 sibling, 2 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 8:07 UTC (permalink / raw)
To: Wei Liu
Cc: George Dunlap, Andrew Cooper, Tamas K Lengyel, Razvan Cojocaru,
xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -2,8 +2,9 @@ subdir-y += shadow
> subdir-y += 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 p2m-pod.o
> +obj-$(CONFIG_HVM) += p2m-ept.o
> +obj-$(CONFIG_HVM) += altp2m.o
PoD is HVM-only too.
> --- a/xen/arch/x86/mm/hap/Makefile
> +++ b/xen/arch/x86/mm/hap/Makefile
> @@ -3,7 +3,7 @@ obj-y += guest_walk_2level.o
> obj-y += guest_walk_3level.o
> obj-y += guest_walk_4level.o
> obj-y += nested_hap.o
> -obj-y += nested_ept.o
> +obj-$(CONFIG_HVM) += nested_ept.o
As follows from the reply to the previous patch, the entire hap/ should
be excluded when !HVM.
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -531,7 +531,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;
This presumably again is a result of using a macro somewhere which
doesn't evaluate its argument(s)?
> @@ -2165,6 +2159,14 @@ int unmap_mmio_regions(struct domain *d,
> return i == nr ? 0 : i ?: ret;
> }
>
> +#if CONFIG_HVM
#ifdef (also elsewhere; did I overlook similar issues in earlier patches?)
> --- 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);
>
> +#if CONFIG_HVM
> /* Check for altp2m switch */
> if ( rsp.flags & VM_EVENT_FLAG_ALTERNATE_P2M )
> p2m_altp2m_check(v, rsp.altp2m_idx);
> +#endif
Perhaps again better to have a static inline stub?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM
2018-08-21 8:07 ` Jan Beulich
@ 2018-08-22 14:14 ` Wei Liu
2018-08-24 17:05 ` Wei Liu
1 sibling, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-22 14:14 UTC (permalink / raw)
To: Jan Beulich
Cc: Tamas K Lengyel, Wei Liu, Razvan Cojocaru, George Dunlap,
Andrew Cooper, xen-devel
On Tue, Aug 21, 2018 at 02:07:22AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/mm/Makefile
> > +++ b/xen/arch/x86/mm/Makefile
> > @@ -2,8 +2,9 @@ subdir-y += shadow
> > subdir-y += 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 p2m-pod.o
> > +obj-$(CONFIG_HVM) += p2m-ept.o
> > +obj-$(CONFIG_HVM) += altp2m.o
>
> PoD is HVM-only too.
>
> > --- a/xen/arch/x86/mm/hap/Makefile
> > +++ b/xen/arch/x86/mm/hap/Makefile
> > @@ -3,7 +3,7 @@ obj-y += guest_walk_2level.o
> > obj-y += guest_walk_3level.o
> > obj-y += guest_walk_4level.o
> > obj-y += nested_hap.o
> > -obj-y += nested_ept.o
> > +obj-$(CONFIG_HVM) += nested_ept.o
>
> As follows from the reply to the previous patch, the entire hap/ should
> be excluded when !HVM.
OK. I will put pod and hap under CONFIG_HVM as well.
>
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -531,7 +531,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;
>
> This presumably again is a result of using a macro somewhere which
> doesn't evaluate its argument(s)?
No. In this case it is because the code which uses d is guarded by
CONFIG_HVM.
>
> > @@ -2165,6 +2159,14 @@ int unmap_mmio_regions(struct domain *d,
> > return i == nr ? 0 : i ?: ret;
> > }
> >
> > +#if CONFIG_HVM
>
> #ifdef (also elsewhere; did I overlook similar issues in earlier patches?)
>
OK.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM
2018-08-21 8:07 ` Jan Beulich
2018-08-22 14:14 ` Wei Liu
@ 2018-08-24 17:05 ` Wei Liu
1 sibling, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-24 17:05 UTC (permalink / raw)
To: Jan Beulich
Cc: Tamas K Lengyel, Wei Liu, Razvan Cojocaru, George Dunlap,
Andrew Cooper, xen-devel
On Tue, Aug 21, 2018 at 02:07:22AM -0600, Jan Beulich wrote:
> #ifdef (also elsewhere; did I overlook similar issues in earlier patches?)
>
> > --- 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);
> >
> > +#if CONFIG_HVM
> > /* Check for altp2m switch */
> > if ( rsp.flags & VM_EVENT_FLAG_ALTERNATE_P2M )
> > p2m_altp2m_check(v, rsp.altp2m_idx);
> > +#endif
>
> Perhaps again better to have a static inline stub?
I will leave this as-is. The code churn would be the same.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 23/34] x86/oprofile: put SVM only code under CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (21 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 8:12 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 24/34] x86/mem_access: put HVM only function " Wei Liu
` (12 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
The code snippet in question is to detect NMI held by SVM until STGI
is called. When Xen doesn't even support HVM guests there is no need
to check svm_stgi_label.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/oprofile/op_model_athlon.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/oprofile/op_model_athlon.c b/xen/arch/x86/oprofile/op_model_athlon.c
index 2d3763c..3d6e26f 100644
--- a/xen/arch/x86/oprofile/op_model_athlon.c
+++ b/xen/arch/x86/oprofile/op_model_athlon.c
@@ -319,9 +319,11 @@ static int athlon_check_ctrs(unsigned int const cpu,
unsigned long eip = regs->rip;
int mode = 0;
struct vcpu *v = current;
- struct cpu_user_regs *guest_regs = guest_cpu_user_regs();
unsigned int const nr_ctrs = model->num_counters;
+#if CONFIG_HVM
+ struct cpu_user_regs *guest_regs = guest_cpu_user_regs();
+
if (!guest_mode(regs) &&
(eip == (unsigned long)svm_stgi_label)) {
/* SVM guest was running when NMI occurred */
@@ -329,6 +331,7 @@ static int athlon_check_ctrs(unsigned int const cpu,
eip = guest_regs->rip;
mode = xenoprofile_get_mode(v, guest_regs);
} else
+#endif
mode = xenoprofile_get_mode(v, regs);
for (i = 0 ; i < nr_ctrs; ++i) {
--
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] 130+ messages in thread* [PATCH 24/34] x86/mem_access: put HVM only function under CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (22 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 23/34] x86/oprofile: put SVM " Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-19 16:36 ` Razvan Cojocaru
2018-08-17 15:12 ` [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM Wei Liu
` (11 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel
Cc: Tamas K Lengyel, Wei Liu, Razvan Cojocaru, George Dunlap,
Andrew Cooper, Jan Beulich
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/mm/mem_access.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 03a8641..e1525fd 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -138,6 +138,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
return violation;
}
+#if CONFIG_HVM
bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
struct npfec npfec,
vm_event_request_t **req_ptr)
@@ -244,6 +245,7 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
/* Return whether vCPU pause is required (aka. sync event) */
return (p2ma != p2m_access_n2rwx);
}
+#endif
int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
struct p2m_domain *ap2m, p2m_access_t a,
--
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] 130+ messages in thread* Re: [PATCH 24/34] x86/mem_access: put HVM only function under CONFIG_HVM
2018-08-17 15:12 ` [PATCH 24/34] x86/mem_access: put HVM only function " Wei Liu
@ 2018-08-19 16:36 ` Razvan Cojocaru
0 siblings, 0 replies; 130+ messages in thread
From: Razvan Cojocaru @ 2018-08-19 16:36 UTC (permalink / raw)
To: Wei Liu, xen-devel
Cc: George Dunlap, Andrew Cooper, Tamas K Lengyel, Jan Beulich
On 8/17/18 6:12 PM, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> xen/arch/x86/mm/mem_access.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index 03a8641..e1525fd 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -138,6 +138,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
> return violation;
> }
>
> +#if CONFIG_HVM
> bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
> struct npfec npfec,
> vm_event_request_t **req_ptr)
> @@ -244,6 +245,7 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
> /* Return whether vCPU pause is required (aka. sync event) */
> return (p2ma != p2m_access_n2rwx);
> }
> +#endif
>
> int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
> struct p2m_domain *ap2m, p2m_access_t a,
>
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] 130+ messages in thread
* [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (23 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 24/34] x86/mem_access: put HVM only function " Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 8:27 ` Jan Beulich
` (3 more replies)
2018-08-17 15:12 ` [PATCH 26/34] x86/mm/shadow: split out HVM only code Wei Liu
` (10 subsequent siblings)
35 siblings, 4 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: George Dunlap, Tim Deegan, Wei Liu, Jan Beulich, Andrew Cooper
Enclose HVM only emulation code under CONFIG_HVM. Add some BUG()s to
to catch any issue.
Note that although some code checks is_hvm_*, which hints it can be
called for PV as well, I can't find such paths.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/mm/shadow/common.c | 18 ++++++++++++++++--
xen/arch/x86/mm/shadow/multi.c | 27 +++++++++++++++++++++------
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 0856650..4381538 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -113,6 +113,7 @@ __initcall(shadow_audit_key_init);
#endif /* SHADOW_AUDIT */
+#if CONFIG_HVM
/**************************************************************************/
/* x86 emulator support for the shadow code
*/
@@ -380,11 +381,13 @@ static const struct x86_emulate_ops hvm_shadow_emulator_ops = {
.cmpxchg = hvm_emulate_cmpxchg,
.cpuid = hvmemul_cpuid,
};
+#endif
const struct x86_emulate_ops *shadow_init_emulation(
struct sh_emulate_ctxt *sh_ctxt, struct cpu_user_regs *regs,
unsigned int pte_size)
{
+#if CONFIG_HVM
struct segment_register *creg, *sreg;
struct vcpu *v = current;
unsigned long addr;
@@ -423,6 +426,10 @@ const struct x86_emulate_ops *shadow_init_emulation(
? sizeof(sh_ctxt->insn_buf) : 0;
return &hvm_shadow_emulator_ops;
+#else
+ BUG();
+ return NULL;
+#endif
}
/* Update an initialized emulation context to prepare for the next
@@ -430,6 +437,7 @@ const struct x86_emulate_ops *shadow_init_emulation(
void shadow_continue_emulation(struct sh_emulate_ctxt *sh_ctxt,
struct cpu_user_regs *regs)
{
+#if CONFIG_HVM
unsigned long addr, diff;
ASSERT(is_hvm_vcpu(current));
@@ -451,6 +459,9 @@ void shadow_continue_emulation(struct sh_emulate_ctxt *sh_ctxt,
? sizeof(sh_ctxt->insn_buf) : 0;
sh_ctxt->insn_buf_eip = regs->rip;
}
+#else
+ BUG();
+#endif
}
@@ -1685,6 +1696,7 @@ static unsigned int shadow_get_allocation(struct domain *d)
+ ((pg & ((1 << (20 - PAGE_SHIFT)) - 1)) ? 1 : 0));
}
+#if CONFIG_HVM
/**************************************************************************/
/* Handling guest writes to pagetables. */
@@ -1957,6 +1969,7 @@ static void sh_emulate_unmap_dest(struct vcpu *v, void *addr,
atomic_inc(&v->domain->arch.paging.shadow.gtable_dirty_version);
}
+#endif
/**************************************************************************/
/* Hash table for storing the guest->shadow mappings.
@@ -2723,12 +2736,13 @@ static int sh_remove_all_mappings(struct domain *d, mfn_t gmfn, gfn_t gfn)
&& (page->count_info & PGC_count_mask) <= 3
&& ((page->u.inuse.type_info & PGT_count_mask)
== (is_xen_heap_page(page) ||
- is_ioreq_server_page(d, page)))) )
+ (is_hvm_domain(d) && is_ioreq_server_page(d, page))))) )
{
SHADOW_ERROR("can't find all mappings of mfn %lx (gfn %lx): "
"c=%lx t=%lx x=%d i=%d\n", mfn_x(gmfn), gfn_x(gfn),
page->count_info, page->u.inuse.type_info,
- !!is_xen_heap_page(page), is_ioreq_server_page(d, page));
+ !!is_xen_heap_page(page),
+ is_hvm_domain(d) && is_ioreq_server_page(d, page));
}
}
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 021ae25..ff7a20c 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
}
else
{
+#if CONFIG_HVM
/* Magic MMIO marker: extract gfn for MMIO address */
ASSERT(sh_l1e_is_mmio(sl1e));
+ ASSERT(is_hvm_vcpu(v));
gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e))))
<< PAGE_SHIFT)
| (va & ~PAGE_MASK);
+ perfc_incr(shadow_fault_fast_mmio);
+ SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
+ sh_reset_early_unshadow(v);
+ trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
+ return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
+ access)
+ ? EXCRET_fault_fixed : 0;
+#else
+ /* When HVM is not enabled, there shouldn't be MMIO marker */
+ BUG();
+#endif
}
- perfc_incr(shadow_fault_fast_mmio);
- SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
- sh_reset_early_unshadow(v);
- trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
- return (handle_mmio_with_translation(va, gpa >> PAGE_SHIFT, access)
- ? EXCRET_fault_fixed : 0);
}
else
{
@@ -3381,8 +3388,10 @@ static int sh_page_fault(struct vcpu *v,
r = x86_emulate(&emul_ctxt.ctxt, emul_ops);
+#if CONFIG_HVM
if ( r == X86EMUL_EXCEPTION )
{
+ ASSERT(is_hvm_domain(d));
/*
* This emulation covers writes to shadow pagetables. We tolerate #PF
* (from accesses spanning pages, concurrent paging updated from
@@ -3404,6 +3413,7 @@ static int sh_page_fault(struct vcpu *v,
r = X86EMUL_UNHANDLEABLE;
}
}
+#endif
/*
* NB. We do not unshadow on X86EMUL_EXCEPTION. It's not clear that it
@@ -3513,6 +3523,8 @@ static int sh_page_fault(struct vcpu *v,
mmio:
if ( !guest_mode(regs) )
goto not_a_shadow_fault;
+#if CONFIG_HVM
+ ASSERT(is_hvm_vcpu(v));
perfc_incr(shadow_fault_mmio);
sh_audit_gw(v, &gw);
SHADOW_PRINTK("mmio %#"PRIpaddr"\n", gpa);
@@ -3523,6 +3535,9 @@ static int sh_page_fault(struct vcpu *v,
trace_shadow_gen(TRC_SHADOW_MMIO, va);
return (handle_mmio_with_translation(va, gpa >> PAGE_SHIFT, access)
? EXCRET_fault_fixed : 0);
+#else
+ BUG();
+#endif
not_a_shadow_fault:
sh_audit_gw(v, &gw);
--
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] 130+ messages in thread* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM Wei Liu
@ 2018-08-21 8:27 ` Jan Beulich
2018-08-24 20:40 ` Wei Liu
2018-08-26 11:04 ` Wei Liu
2018-08-21 8:29 ` Roger Pau Monné
` (2 subsequent siblings)
3 siblings, 2 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 8:27 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, Tim Deegan, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> @@ -423,6 +426,10 @@ const struct x86_emulate_ops *shadow_init_emulation(
> ? sizeof(sh_ctxt->insn_buf) : 0;
>
> return &hvm_shadow_emulator_ops;
> +#else
> + BUG();
> + return NULL;
> +#endif
> }
The sole invocation of the function sits right _after_ an is_hvm_...()
conditional (which is odd enough, but presumably a result of the
history of the code). Leaving aside a couple of labels (the goto-s to
which are, I think, provable to be HVM-only as well), that is
preceded by a shadow_mode_refcounts() check (right at the
"emulate" label). I think shadow_mode_refcounts() wants to
become constant false for !HVM, at which point the is_hvm_...()
could even go away (but there's no strict need for this to happen
right away).
Bottom line - once again the entire function (not just its body) should
be put inside the #ifdef, and then of course the same for
shadow_continue_emulation().
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> }
> else
> {
> +#if CONFIG_HVM
> /* Magic MMIO marker: extract gfn for MMIO address */
> ASSERT(sh_l1e_is_mmio(sl1e));
> + ASSERT(is_hvm_vcpu(v));
> gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e))))
> << PAGE_SHIFT)
> | (va & ~PAGE_MASK);
> + perfc_incr(shadow_fault_fast_mmio);
> + SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
> + sh_reset_early_unshadow(v);
> + trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
> + return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
> + access)
> + ? EXCRET_fault_fixed : 0;
> +#else
> + /* When HVM is not enabled, there shouldn't be MMIO marker */
> + BUG();
At the example of this, while I agree we shouldn't reach here for PV,
can this nevertheless be the less impactful domain_crash() please?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-21 8:27 ` Jan Beulich
@ 2018-08-24 20:40 ` Wei Liu
2018-08-26 11:04 ` Wei Liu
1 sibling, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-24 20:40 UTC (permalink / raw)
To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Tim Deegan, Wei Liu, xen-devel
On Tue, Aug 21, 2018 at 02:27:40AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > @@ -423,6 +426,10 @@ const struct x86_emulate_ops *shadow_init_emulation(
> > ? sizeof(sh_ctxt->insn_buf) : 0;
> >
> > return &hvm_shadow_emulator_ops;
> > +#else
> > + BUG();
> > + return NULL;
> > +#endif
> > }
>
> The sole invocation of the function sits right _after_ an is_hvm_...()
> conditional (which is odd enough, but presumably a result of the
> history of the code). Leaving aside a couple of labels (the goto-s to
> which are, I think, provable to be HVM-only as well), that is
> preceded by a shadow_mode_refcounts() check (right at the
> "emulate" label). I think shadow_mode_refcounts() wants to
> become constant false for !HVM, at which point the is_hvm_...()
> could even go away (but there's no strict need for this to happen
> right away).
>
> Bottom line - once again the entire function (not just its body) should
> be put inside the #ifdef, and then of course the same for
> shadow_continue_emulation().
>
> > --- a/xen/arch/x86/mm/shadow/multi.c
> > +++ b/xen/arch/x86/mm/shadow/multi.c
> > @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> > }
> > else
> > {
> > +#if CONFIG_HVM
> > /* Magic MMIO marker: extract gfn for MMIO address */
> > ASSERT(sh_l1e_is_mmio(sl1e));
> > + ASSERT(is_hvm_vcpu(v));
> > gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e))))
> > << PAGE_SHIFT)
> > | (va & ~PAGE_MASK);
> > + perfc_incr(shadow_fault_fast_mmio);
> > + SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
> > + sh_reset_early_unshadow(v);
> > + trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
> > + return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
> > + access)
> > + ? EXCRET_fault_fixed : 0;
> > +#else
> > + /* When HVM is not enabled, there shouldn't be MMIO marker */
> > + BUG();
>
> At the example of this, while I agree we shouldn't reach here for PV,
> can this nevertheless be the less impactful domain_crash() please?
Since Tim has reviewed this patch, I will submit a follow-up patch for
switching to domain_crash.
Wei.
>
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-21 8:27 ` Jan Beulich
2018-08-24 20:40 ` Wei Liu
@ 2018-08-26 11:04 ` Wei Liu
2018-08-27 7:46 ` Jan Beulich
1 sibling, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-26 11:04 UTC (permalink / raw)
To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Tim Deegan, Wei Liu, xen-devel
On Tue, Aug 21, 2018 at 02:27:40AM -0600, Jan Beulich wrote:
>
> > --- a/xen/arch/x86/mm/shadow/multi.c
> > +++ b/xen/arch/x86/mm/shadow/multi.c
> > @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> > }
> > else
> > {
> > +#if CONFIG_HVM
> > /* Magic MMIO marker: extract gfn for MMIO address */
> > ASSERT(sh_l1e_is_mmio(sl1e));
> > + ASSERT(is_hvm_vcpu(v));
> > gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e))))
> > << PAGE_SHIFT)
> > | (va & ~PAGE_MASK);
> > + perfc_incr(shadow_fault_fast_mmio);
> > + SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
> > + sh_reset_early_unshadow(v);
> > + trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
> > + return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
> > + access)
> > + ? EXCRET_fault_fixed : 0;
> > +#else
> > + /* When HVM is not enabled, there shouldn't be MMIO marker */
> > + BUG();
>
> At the example of this, while I agree we shouldn't reach here for PV,
> can this nevertheless be the less impactful domain_crash() please?
>
Do you only want this BUG() to be replaced?
I think the two in shadonw_*_emulation should stay because you will only
ever get NULL pointer deref if you allow the code to continue.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-26 11:04 ` Wei Liu
@ 2018-08-27 7:46 ` Jan Beulich
2018-08-27 9:12 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-27 7:46 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, Tim Deegan, xen-devel
>>> On 26.08.18 at 13:04, <wei.liu2@citrix.com> wrote:
> On Tue, Aug 21, 2018 at 02:27:40AM -0600, Jan Beulich wrote:
>>
>> > --- a/xen/arch/x86/mm/shadow/multi.c
>> > +++ b/xen/arch/x86/mm/shadow/multi.c
>> > @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
>> > }
>> > else
>> > {
>> > +#if CONFIG_HVM
>> > /* Magic MMIO marker: extract gfn for MMIO address */
>> > ASSERT(sh_l1e_is_mmio(sl1e));
>> > + ASSERT(is_hvm_vcpu(v));
>> > gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e))))
>> > << PAGE_SHIFT)
>> > | (va & ~PAGE_MASK);
>> > + perfc_incr(shadow_fault_fast_mmio);
>> > + SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
>> > + sh_reset_early_unshadow(v);
>> > + trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
>> > + return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
>> > + access)
>> > + ? EXCRET_fault_fixed : 0;
>> > +#else
>> > + /* When HVM is not enabled, there shouldn't be MMIO marker */
>> > + BUG();
>>
>> At the example of this, while I agree we shouldn't reach here for PV,
>> can this nevertheless be the less impactful domain_crash() please?
>>
>
> Do you only want this BUG() to be replaced?
>
> I think the two in shadonw_*_emulation should stay because you will only
> ever get NULL pointer deref if you allow the code to continue.
Did you perhaps remove too much context? From what's left I can't
judge which others you refer to, or what NULL deref you talk about.
Looking back at the full patch - I think I had already suggested that
the two shadow_*_emulation() should altogether go inside #ifdef
CONFIG_HVM, not just their bodies.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-27 7:46 ` Jan Beulich
@ 2018-08-27 9:12 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-27 9:12 UTC (permalink / raw)
To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Tim Deegan, Wei Liu, xen-devel
On Mon, Aug 27, 2018 at 01:46:10AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 13:04, <wei.liu2@citrix.com> wrote:
> > On Tue, Aug 21, 2018 at 02:27:40AM -0600, Jan Beulich wrote:
> >>
> >> > --- a/xen/arch/x86/mm/shadow/multi.c
> >> > +++ b/xen/arch/x86/mm/shadow/multi.c
> >> > @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> >> > }
> >> > else
> >> > {
> >> > +#if CONFIG_HVM
> >> > /* Magic MMIO marker: extract gfn for MMIO address */
> >> > ASSERT(sh_l1e_is_mmio(sl1e));
> >> > + ASSERT(is_hvm_vcpu(v));
> >> > gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e))))
> >> > << PAGE_SHIFT)
> >> > | (va & ~PAGE_MASK);
> >> > + perfc_incr(shadow_fault_fast_mmio);
> >> > + SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
> >> > + sh_reset_early_unshadow(v);
> >> > + trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
> >> > + return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
> >> > + access)
> >> > + ? EXCRET_fault_fixed : 0;
> >> > +#else
> >> > + /* When HVM is not enabled, there shouldn't be MMIO marker */
> >> > + BUG();
> >>
> >> At the example of this, while I agree we shouldn't reach here for PV,
> >> can this nevertheless be the less impactful domain_crash() please?
> >>
> >
> > Do you only want this BUG() to be replaced?
> >
> > I think the two in shadonw_*_emulation should stay because you will only
> > ever get NULL pointer deref if you allow the code to continue.
>
> Did you perhaps remove too much context? From what's left I can't
> judge which others you refer to, or what NULL deref you talk about.
The BUG()s in shadow_*_emulation, like I mentioned in my reply.
What I meant was if I make shadown_init_emulation like:
domain_crash(d);
return NULL;
Nothing good is going to happen.
> Looking back at the full patch - I think I had already suggested that
> the two shadow_*_emulation() should altogether go inside #ifdef
> CONFIG_HVM, not just their bodies.
I will see about doing that later this week.
(Today is public holiday in UK)
Wei.
>
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM Wei Liu
2018-08-21 8:27 ` Jan Beulich
@ 2018-08-21 8:29 ` Roger Pau Monné
2018-08-21 8:41 ` Jan Beulich
2018-08-24 20:39 ` Wei Liu
2018-08-21 8:41 ` Jan Beulich
2018-08-24 6:56 ` Tim Deegan
3 siblings, 2 replies; 130+ messages in thread
From: Roger Pau Monné @ 2018-08-21 8:29 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, xen-devel, Tim Deegan, Jan Beulich, Andrew Cooper
On Fri, Aug 17, 2018 at 04:12:43PM +0100, Wei Liu wrote:
> Enclose HVM only emulation code under CONFIG_HVM. Add some BUG()s to
> to catch any issue.
>
> Note that although some code checks is_hvm_*, which hints it can be
> called for PV as well, I can't find such paths.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> xen/arch/x86/mm/shadow/common.c | 18 ++++++++++++++++--
> xen/arch/x86/mm/shadow/multi.c | 27 +++++++++++++++++++++------
> 2 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
> index 0856650..4381538 100644
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -113,6 +113,7 @@ __initcall(shadow_audit_key_init);
> #endif /* SHADOW_AUDIT */
>
>
> +#if CONFIG_HVM
> /**************************************************************************/
> /* x86 emulator support for the shadow code
> */
> @@ -380,11 +381,13 @@ static const struct x86_emulate_ops hvm_shadow_emulator_ops = {
> .cmpxchg = hvm_emulate_cmpxchg,
> .cpuid = hvmemul_cpuid,
> };
> +#endif
>
> const struct x86_emulate_ops *shadow_init_emulation(
> struct sh_emulate_ctxt *sh_ctxt, struct cpu_user_regs *regs,
> unsigned int pte_size)
> {
> +#if CONFIG_HVM
> struct segment_register *creg, *sreg;
> struct vcpu *v = current;
> unsigned long addr;
> @@ -423,6 +426,10 @@ const struct x86_emulate_ops *shadow_init_emulation(
> ? sizeof(sh_ctxt->insn_buf) : 0;
>
> return &hvm_shadow_emulator_ops;
> +#else
> + BUG();
I would usually use ASSERT_UNREACHABLE in such situations.
And here I wonder whether this cannot be called from a PV path,
AFAICT:
do_page_fault -> fixup_page_fault -> paging_fault -> page_fault
(sh_page_fault) -> shadow_init_emulation
But maybe there are other conditions that make this path actually
unreachable (or maybe something in your series changed this path).
> + return NULL;
> +#endif
> }
>
> /* Update an initialized emulation context to prepare for the next
> @@ -430,6 +437,7 @@ const struct x86_emulate_ops *shadow_init_emulation(
> void shadow_continue_emulation(struct sh_emulate_ctxt *sh_ctxt,
> struct cpu_user_regs *regs)
> {
> +#if CONFIG_HVM
> unsigned long addr, diff;
>
> ASSERT(is_hvm_vcpu(current));
> @@ -451,6 +459,9 @@ void shadow_continue_emulation(struct sh_emulate_ctxt *sh_ctxt,
> ? sizeof(sh_ctxt->insn_buf) : 0;
> sh_ctxt->insn_buf_eip = regs->rip;
> }
> +#else
> + BUG();
> +#endif
> }
>
>
> @@ -1685,6 +1696,7 @@ static unsigned int shadow_get_allocation(struct domain *d)
> + ((pg & ((1 << (20 - PAGE_SHIFT)) - 1)) ? 1 : 0));
> }
>
> +#if CONFIG_HVM
> /**************************************************************************/
> /* Handling guest writes to pagetables. */
>
> @@ -1957,6 +1969,7 @@ static void sh_emulate_unmap_dest(struct vcpu *v, void *addr,
>
> atomic_inc(&v->domain->arch.paging.shadow.gtable_dirty_version);
> }
> +#endif
>
> /**************************************************************************/
> /* Hash table for storing the guest->shadow mappings.
> @@ -2723,12 +2736,13 @@ static int sh_remove_all_mappings(struct domain *d, mfn_t gmfn, gfn_t gfn)
> && (page->count_info & PGC_count_mask) <= 3
> && ((page->u.inuse.type_info & PGT_count_mask)
> == (is_xen_heap_page(page) ||
> - is_ioreq_server_page(d, page)))) )
> + (is_hvm_domain(d) && is_ioreq_server_page(d, page))))) )
Isn't this a separate bugfix? is_ioreq_server_page shouldn't be called
for PV domains at all (same below).
> {
> SHADOW_ERROR("can't find all mappings of mfn %lx (gfn %lx): "
> "c=%lx t=%lx x=%d i=%d\n", mfn_x(gmfn), gfn_x(gfn),
> page->count_info, page->u.inuse.type_info,
> - !!is_xen_heap_page(page), is_ioreq_server_page(d, page));
> + !!is_xen_heap_page(page),
> + is_hvm_domain(d) && is_ioreq_server_page(d, page));
> }
> }
>
> diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
> index 021ae25..ff7a20c 100644
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> }
> else
> {
> +#if CONFIG_HVM
> /* Magic MMIO marker: extract gfn for MMIO address */
> ASSERT(sh_l1e_is_mmio(sl1e));
> + ASSERT(is_hvm_vcpu(v));
> gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e))))
> << PAGE_SHIFT)
> | (va & ~PAGE_MASK);
> + perfc_incr(shadow_fault_fast_mmio);
> + SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
> + sh_reset_early_unshadow(v);
> + trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
> + return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
> + access)
> + ? EXCRET_fault_fixed : 0;
Could you align the '?' to 'handle'.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-21 8:29 ` Roger Pau Monné
@ 2018-08-21 8:41 ` Jan Beulich
2018-08-24 20:39 ` Wei Liu
1 sibling, 0 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 8:41 UTC (permalink / raw)
To: Roger Pau Monne, Wei Liu
Cc: George Dunlap, Andrew Cooper, Tim Deegan, xen-devel
>>> On 21.08.18 at 10:29, <roger.pau@citrix.com> wrote:
> On Fri, Aug 17, 2018 at 04:12:43PM +0100, Wei Liu wrote:
>> @@ -2723,12 +2736,13 @@ static int sh_remove_all_mappings(struct domain *d, mfn_t gmfn, gfn_t gfn)
>> && (page->count_info & PGC_count_mask) <= 3
>> && ((page->u.inuse.type_info & PGT_count_mask)
>> == (is_xen_heap_page(page) ||
>> - is_ioreq_server_page(d, page)))) )
>> + (is_hvm_domain(d) && is_ioreq_server_page(d, page))))) )
>
> Isn't this a separate bugfix? is_ioreq_server_page shouldn't be called
> for PV domains at all (same below).
There's a shadow_mode_external() just out of context here. Along the
lines of my previous reply, this one too should be forced to constant
false when !HVM.
Without this, i.e. if the code was somehow reachable for PV guests,
this would have been a security issue.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-21 8:29 ` Roger Pau Monné
2018-08-21 8:41 ` Jan Beulich
@ 2018-08-24 20:39 ` Wei Liu
1 sibling, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-24 20:39 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Wei Liu, George Dunlap, Andrew Cooper, Tim Deegan, Jan Beulich,
xen-devel
On Tue, Aug 21, 2018 at 10:29:21AM +0200, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 04:12:43PM +0100, Wei Liu wrote:
> > Enclose HVM only emulation code under CONFIG_HVM. Add some BUG()s to
> > to catch any issue.
> >
> > Note that although some code checks is_hvm_*, which hints it can be
> > called for PV as well, I can't find such paths.
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > xen/arch/x86/mm/shadow/common.c | 18 ++++++++++++++++--
> > xen/arch/x86/mm/shadow/multi.c | 27 +++++++++++++++++++++------
> > 2 files changed, 37 insertions(+), 8 deletions(-)
> >
> > diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
> > index 0856650..4381538 100644
> > --- a/xen/arch/x86/mm/shadow/common.c
> > +++ b/xen/arch/x86/mm/shadow/common.c
> > @@ -113,6 +113,7 @@ __initcall(shadow_audit_key_init);
> > #endif /* SHADOW_AUDIT */
> >
> >
> > +#if CONFIG_HVM
> > /**************************************************************************/
> > /* x86 emulator support for the shadow code
> > */
> > @@ -380,11 +381,13 @@ static const struct x86_emulate_ops hvm_shadow_emulator_ops = {
> > .cmpxchg = hvm_emulate_cmpxchg,
> > .cpuid = hvmemul_cpuid,
> > };
> > +#endif
> >
> > const struct x86_emulate_ops *shadow_init_emulation(
> > struct sh_emulate_ctxt *sh_ctxt, struct cpu_user_regs *regs,
> > unsigned int pte_size)
> > {
> > +#if CONFIG_HVM
> > struct segment_register *creg, *sreg;
> > struct vcpu *v = current;
> > unsigned long addr;
> > @@ -423,6 +426,10 @@ const struct x86_emulate_ops *shadow_init_emulation(
> > ? sizeof(sh_ctxt->insn_buf) : 0;
> >
> > return &hvm_shadow_emulator_ops;
> > +#else
> > + BUG();
>
> I would usually use ASSERT_UNREACHABLE in such situations.
>
> And here I wonder whether this cannot be called from a PV path,
> AFAICT:
>
> do_page_fault -> fixup_page_fault -> paging_fault -> page_fault
> (sh_page_fault) -> shadow_init_emulation
>
> But maybe there are other conditions that make this path actually
> unreachable (or maybe something in your series changed this path).
It can't / shouldn't be reached from PV. See Jan's replies.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM Wei Liu
2018-08-21 8:27 ` Jan Beulich
2018-08-21 8:29 ` Roger Pau Monné
@ 2018-08-21 8:41 ` Jan Beulich
2018-08-24 20:26 ` Wei Liu
2018-08-24 6:56 ` Tim Deegan
3 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 8:41 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, Tim Deegan, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> }
> else
> {
> +#if CONFIG_HVM
> /* Magic MMIO marker: extract gfn for MMIO address */
> ASSERT(sh_l1e_is_mmio(sl1e));
> + ASSERT(is_hvm_vcpu(v));
> gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e))))
> << PAGE_SHIFT)
> | (va & ~PAGE_MASK);
> + perfc_incr(shadow_fault_fast_mmio);
> + SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
> + sh_reset_early_unshadow(v);
> + trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
> + return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
> + access)
> + ? EXCRET_fault_fixed : 0;
> +#else
> + /* When HVM is not enabled, there shouldn't be MMIO marker */
> + BUG();
> +#endif
> }
> - perfc_incr(shadow_fault_fast_mmio);
> - SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
> - sh_reset_early_unshadow(v);
> - trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
> - return (handle_mmio_with_translation(va, gpa >> PAGE_SHIFT, access)
> - ? EXCRET_fault_fixed : 0);
> }
Actually, while I'm not the maintainer of this code, instead of moving
the code up and increasing indentation, would you mind dropping the
pointless "else" (and decrease indentation of the code in its body)?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-21 8:41 ` Jan Beulich
@ 2018-08-24 20:26 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-24 20:26 UTC (permalink / raw)
To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Tim Deegan, Wei Liu, xen-devel
On Tue, Aug 21, 2018 at 02:41:06AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/mm/shadow/multi.c
> > +++ b/xen/arch/x86/mm/shadow/multi.c
> > @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> > }
> > else
> > {
> > +#if CONFIG_HVM
> > /* Magic MMIO marker: extract gfn for MMIO address */
> > ASSERT(sh_l1e_is_mmio(sl1e));
> > + ASSERT(is_hvm_vcpu(v));
> > gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e))))
> > << PAGE_SHIFT)
> > | (va & ~PAGE_MASK);
> > + perfc_incr(shadow_fault_fast_mmio);
> > + SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
> > + sh_reset_early_unshadow(v);
> > + trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
> > + return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
> > + access)
> > + ? EXCRET_fault_fixed : 0;
> > +#else
> > + /* When HVM is not enabled, there shouldn't be MMIO marker */
> > + BUG();
> > +#endif
> > }
> > - perfc_incr(shadow_fault_fast_mmio);
> > - SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
> > - sh_reset_early_unshadow(v);
> > - trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
> > - return (handle_mmio_with_translation(va, gpa >> PAGE_SHIFT, access)
> > - ? EXCRET_fault_fixed : 0);
> > }
>
> Actually, while I'm not the maintainer of this code, instead of moving
> the code up and increasing indentation, would you mind dropping the
> pointless "else" (and decrease indentation of the code in its body)?
Done.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM Wei Liu
` (2 preceding siblings ...)
2018-08-21 8:41 ` Jan Beulich
@ 2018-08-24 6:56 ` Tim Deegan
3 siblings, 0 replies; 130+ messages in thread
From: Tim Deegan @ 2018-08-24 6:56 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, xen-devel, Jan Beulich, Andrew Cooper
At 16:12 +0100 on 17 Aug (1534522363), Wei Liu wrote:
> Enclose HVM only emulation code under CONFIG_HVM. Add some BUG()s to
> to catch any issue.
>
> Note that although some code checks is_hvm_*, which hints it can be
> called for PV as well, I can't find such paths.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 26/34] x86/mm/shadow: split out HVM only code
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (24 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 11:36 ` Jan Beulich
2018-08-24 6:57 ` Tim Deegan
2018-08-17 15:12 ` [PATCH 27/34] x86: make hvm_inject_* functions build when !CONFIG_HVM Wei Liu
` (9 subsequent siblings)
35 siblings, 2 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: George Dunlap, Tim Deegan, Wei Liu, Jan Beulich, Andrew Cooper
Move the code previously enclosed in CONFIG_HVM into its own file.
Note that although some code explicitly check is_hvm_*, which hints it
can be used for PV too, I can't find a code path that would be the
case.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Can be squashed into previous patch if that's preferable.
---
xen/arch/x86/mm/shadow/Makefile | 1 +-
xen/arch/x86/mm/shadow/common.c | 542 +------------------------------
xen/arch/x86/mm/shadow/hvm.c | 590 +++++++++++++++++++++++++++++++++-
3 files changed, 596 insertions(+), 537 deletions(-)
create mode 100644 xen/arch/x86/mm/shadow/hvm.c
diff --git a/xen/arch/x86/mm/shadow/Makefile b/xen/arch/x86/mm/shadow/Makefile
index bcb23d2..72658f3 100644
--- a/xen/arch/x86/mm/shadow/Makefile
+++ b/xen/arch/x86/mm/shadow/Makefile
@@ -1,5 +1,6 @@
ifeq ($(CONFIG_SHADOW_PAGING),y)
obj-y += common.o guest_2.o guest_3.o guest_4.o
+obj-$(CONFIG_HVM) += hvm.o
else
obj-y += none.o
endif
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 4381538..aa94416 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -114,273 +114,16 @@ __initcall(shadow_audit_key_init);
#if CONFIG_HVM
-/**************************************************************************/
-/* x86 emulator support for the shadow code
- */
-
-/*
- * Returns a mapped pointer to write to, or one of the following error
- * indicators.
- */
-#define MAPPING_UNHANDLEABLE ERR_PTR(~(long)X86EMUL_UNHANDLEABLE)
-#define MAPPING_EXCEPTION ERR_PTR(~(long)X86EMUL_EXCEPTION)
-#define MAPPING_SILENT_FAIL ERR_PTR(~(long)X86EMUL_OKAY)
-static void *sh_emulate_map_dest(struct vcpu *v, unsigned long vaddr,
- unsigned int bytes,
- struct sh_emulate_ctxt *sh_ctxt);
-static void sh_emulate_unmap_dest(struct vcpu *v, void *addr,
- unsigned int bytes,
- struct sh_emulate_ctxt *sh_ctxt);
-
-/*
- * Callers which pass a known in-range x86_segment can rely on the return
- * pointer being valid. Other callers must explicitly check for errors.
- */
-static struct segment_register *hvm_get_seg_reg(
- enum x86_segment seg, struct sh_emulate_ctxt *sh_ctxt)
-{
- unsigned int idx = seg;
- struct segment_register *seg_reg;
-
- if ( idx >= ARRAY_SIZE(sh_ctxt->seg_reg) )
- return ERR_PTR(-X86EMUL_UNHANDLEABLE);
-
- seg_reg = &sh_ctxt->seg_reg[idx];
- if ( !__test_and_set_bit(idx, &sh_ctxt->valid_seg_regs) )
- hvm_get_segment_register(current, idx, seg_reg);
- return seg_reg;
-}
-
-static int hvm_translate_virtual_addr(
+extern const struct x86_emulate_ops hvm_shadow_emulator_ops;
+extern struct segment_register *hvm_get_seg_reg(
+ enum x86_segment seg, struct sh_emulate_ctxt *sh_ctxt);
+extern int hvm_translate_virtual_addr(
enum x86_segment seg,
unsigned long offset,
unsigned int bytes,
enum hvm_access_type access_type,
struct sh_emulate_ctxt *sh_ctxt,
- unsigned long *linear)
-{
- const struct segment_register *reg;
- int okay;
-
- reg = hvm_get_seg_reg(seg, sh_ctxt);
- if ( IS_ERR(reg) )
- return -PTR_ERR(reg);
-
- okay = hvm_virtual_to_linear_addr(
- seg, reg, offset, bytes, access_type,
- hvm_get_seg_reg(x86_seg_cs, sh_ctxt), linear);
-
- if ( !okay )
- {
- /*
- * Leave exception injection to the caller for non-user segments: We
- * neither know the exact error code to be used, nor can we easily
- * determine the kind of exception (#GP or #TS) in that case.
- */
- if ( is_x86_user_segment(seg) )
- x86_emul_hw_exception(
- (seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault,
- 0, &sh_ctxt->ctxt);
- return X86EMUL_EXCEPTION;
- }
-
- return 0;
-}
-
-static int
-hvm_read(enum x86_segment seg,
- unsigned long offset,
- void *p_data,
- unsigned int bytes,
- enum hvm_access_type access_type,
- struct sh_emulate_ctxt *sh_ctxt)
-{
- pagefault_info_t pfinfo;
- unsigned long addr;
- int rc;
-
- rc = hvm_translate_virtual_addr(
- seg, offset, bytes, access_type, sh_ctxt, &addr);
- if ( rc || !bytes )
- return rc;
-
- if ( access_type == hvm_access_insn_fetch )
- rc = hvm_fetch_from_guest_linear(p_data, addr, bytes, 0, &pfinfo);
- else
- rc = hvm_copy_from_guest_linear(p_data, addr, bytes, 0, &pfinfo);
-
- switch ( rc )
- {
- case HVMTRANS_okay:
- return X86EMUL_OKAY;
- case HVMTRANS_bad_linear_to_gfn:
- x86_emul_pagefault(pfinfo.ec, pfinfo.linear, &sh_ctxt->ctxt);
- return X86EMUL_EXCEPTION;
- case HVMTRANS_bad_gfn_to_mfn:
- case HVMTRANS_unhandleable:
- return X86EMUL_UNHANDLEABLE;
- case HVMTRANS_gfn_paged_out:
- case HVMTRANS_gfn_shared:
- return X86EMUL_RETRY;
- }
-
- BUG();
- return X86EMUL_UNHANDLEABLE;
-}
-
-static int
-hvm_emulate_read(enum x86_segment seg,
- unsigned long offset,
- void *p_data,
- unsigned int bytes,
- struct x86_emulate_ctxt *ctxt)
-{
- if ( !is_x86_user_segment(seg) )
- return X86EMUL_UNHANDLEABLE;
- return hvm_read(seg, offset, p_data, bytes, hvm_access_read,
- container_of(ctxt, struct sh_emulate_ctxt, ctxt));
-}
-
-static int
-hvm_emulate_insn_fetch(enum x86_segment seg,
- unsigned long offset,
- void *p_data,
- unsigned int bytes,
- struct x86_emulate_ctxt *ctxt)
-{
- struct sh_emulate_ctxt *sh_ctxt =
- container_of(ctxt, struct sh_emulate_ctxt, ctxt);
- unsigned int insn_off = offset - sh_ctxt->insn_buf_eip;
-
- ASSERT(seg == x86_seg_cs);
-
- /* Fall back if requested bytes are not in the prefetch cache. */
- if ( unlikely((insn_off + bytes) > sh_ctxt->insn_buf_bytes) )
- return hvm_read(seg, offset, p_data, bytes,
- hvm_access_insn_fetch, sh_ctxt);
-
- /* Hit the cache. Simple memcpy. */
- memcpy(p_data, &sh_ctxt->insn_buf[insn_off], bytes);
- return X86EMUL_OKAY;
-}
-
-static int
-hvm_emulate_write(enum x86_segment seg,
- unsigned long offset,
- void *p_data,
- unsigned int bytes,
- struct x86_emulate_ctxt *ctxt)
-{
- struct sh_emulate_ctxt *sh_ctxt =
- container_of(ctxt, struct sh_emulate_ctxt, ctxt);
- struct vcpu *v = current;
- unsigned long addr;
- void *ptr;
- int rc;
-
- /* How many emulations could we save if we unshadowed on stack writes? */
- if ( seg == x86_seg_ss )
- perfc_incr(shadow_fault_emulate_stack);
-
- rc = hvm_translate_virtual_addr(
- seg, offset, bytes, hvm_access_write, sh_ctxt, &addr);
- if ( rc || !bytes )
- return rc;
-
- /* Unaligned writes are only acceptable on HVM */
- if ( (addr & (bytes - 1)) && !is_hvm_vcpu(v) )
- return X86EMUL_UNHANDLEABLE;
-
- ptr = sh_emulate_map_dest(v, addr, bytes, sh_ctxt);
- if ( IS_ERR(ptr) )
- return ~PTR_ERR(ptr);
-
- paging_lock(v->domain);
- memcpy(ptr, p_data, bytes);
-
- if ( tb_init_done )
- v->arch.paging.mode->shadow.trace_emul_write_val(ptr, addr,
- p_data, bytes);
-
- sh_emulate_unmap_dest(v, ptr, bytes, sh_ctxt);
- shadow_audit_tables(v);
- paging_unlock(v->domain);
-
- return X86EMUL_OKAY;
-}
-
-static int
-hvm_emulate_cmpxchg(enum x86_segment seg,
- unsigned long offset,
- void *p_old,
- void *p_new,
- unsigned int bytes,
- bool lock,
- struct x86_emulate_ctxt *ctxt)
-{
- struct sh_emulate_ctxt *sh_ctxt =
- container_of(ctxt, struct sh_emulate_ctxt, ctxt);
- struct vcpu *v = current;
- unsigned long addr, old, new, prev;
- void *ptr;
- int rc;
-
- if ( bytes > sizeof(long) )
- return X86EMUL_UNHANDLEABLE;
-
- rc = hvm_translate_virtual_addr(
- seg, offset, bytes, hvm_access_write, sh_ctxt, &addr);
- if ( rc )
- return rc;
-
- /* Unaligned writes are only acceptable on HVM */
- if ( (addr & (bytes - 1)) && !is_hvm_vcpu(v) )
- return X86EMUL_UNHANDLEABLE;
-
- ptr = sh_emulate_map_dest(v, addr, bytes, sh_ctxt);
- if ( IS_ERR(ptr) )
- return ~PTR_ERR(ptr);
-
- old = new = 0;
- memcpy(&old, p_old, bytes);
- memcpy(&new, p_new, bytes);
-
- paging_lock(v->domain);
- switch ( bytes )
- {
- case 1: prev = cmpxchg((uint8_t *)ptr, old, new); break;
- case 2: prev = cmpxchg((uint16_t *)ptr, old, new); break;
- case 4: prev = cmpxchg((uint32_t *)ptr, old, new); break;
- case 8: prev = cmpxchg((uint64_t *)ptr, old, new); break;
- default:
- SHADOW_PRINTK("cmpxchg size %u is not supported\n", bytes);
- prev = ~old;
- }
-
- if ( prev != old )
- {
- memcpy(p_old, &prev, bytes);
- rc = X86EMUL_CMPXCHG_FAILED;
- }
-
- SHADOW_DEBUG(EMULATE,
- "va %#lx was %#lx expected %#lx wanted %#lx now %#lx bytes %u\n",
- addr, prev, old, new, *(unsigned long *)ptr, bytes);
-
- sh_emulate_unmap_dest(v, ptr, bytes, sh_ctxt);
- shadow_audit_tables(v);
- paging_unlock(v->domain);
-
- return rc;
-}
-
-static const struct x86_emulate_ops hvm_shadow_emulator_ops = {
- .read = hvm_emulate_read,
- .insn_fetch = hvm_emulate_insn_fetch,
- .write = hvm_emulate_write,
- .cmpxchg = hvm_emulate_cmpxchg,
- .cpuid = hvmemul_cpuid,
-};
+ unsigned long *linear);
#endif
const struct x86_emulate_ops *shadow_init_emulation(
@@ -1696,281 +1439,6 @@ static unsigned int shadow_get_allocation(struct domain *d)
+ ((pg & ((1 << (20 - PAGE_SHIFT)) - 1)) ? 1 : 0));
}
-#if CONFIG_HVM
-/**************************************************************************/
-/* Handling guest writes to pagetables. */
-
-/*
- * Translate a VA to an MFN, injecting a page-fault if we fail. If the
- * mapping succeeds, a reference will be held on the underlying page.
- */
-#define BAD_GVA_TO_GFN (~0UL)
-#define BAD_GFN_TO_MFN (~1UL)
-#define READONLY_GFN (~2UL)
-static mfn_t emulate_gva_to_mfn(struct vcpu *v, unsigned long vaddr,
- struct sh_emulate_ctxt *sh_ctxt)
-{
- unsigned long gfn;
- struct page_info *page;
- mfn_t mfn;
- p2m_type_t p2mt;
- uint32_t pfec = PFEC_page_present | PFEC_write_access;
-
- /* Translate the VA to a GFN. */
- gfn = paging_get_hostmode(v)->gva_to_gfn(v, NULL, vaddr, &pfec);
- if ( gfn == gfn_x(INVALID_GFN) )
- {
- x86_emul_pagefault(pfec, vaddr, &sh_ctxt->ctxt);
-
- return _mfn(BAD_GVA_TO_GFN);
- }
-
- /* Translate the GFN to an MFN. */
- ASSERT(!paging_locked_by_me(v->domain));
-
- page = get_page_from_gfn(v->domain, gfn, &p2mt, P2M_ALLOC);
-
- /* Sanity checking. */
- if ( page == NULL )
- {
- return _mfn(BAD_GFN_TO_MFN);
- }
- if ( p2m_is_discard_write(p2mt) )
- {
- put_page(page);
- return _mfn(READONLY_GFN);
- }
- if ( !p2m_is_ram(p2mt) )
- {
- put_page(page);
- return _mfn(BAD_GFN_TO_MFN);
- }
- mfn = page_to_mfn(page);
- ASSERT(mfn_valid(mfn));
-
- v->arch.paging.last_write_was_pt = !!sh_mfn_is_a_page_table(mfn);
-
- return mfn;
-}
-
-/*
- * Check that the user is allowed to perform this write. If a mapping is
- * returned, page references will be held on sh_ctxt->mfn[0] and
- * sh_ctxt->mfn[1] iff !INVALID_MFN.
- */
-static void *sh_emulate_map_dest(struct vcpu *v, unsigned long vaddr,
- unsigned int bytes,
- struct sh_emulate_ctxt *sh_ctxt)
-{
- struct domain *d = v->domain;
- void *map;
-
-#ifndef NDEBUG
- /* We don't emulate user-mode writes to page tables. */
- if ( is_hvm_domain(d) ? hvm_get_cpl(v) == 3
- : !guest_kernel_mode(v, guest_cpu_user_regs()) )
- {
- gdprintk(XENLOG_DEBUG, "User-mode write to pagetable reached "
- "emulate_map_dest(). This should never happen!\n");
- return MAPPING_UNHANDLEABLE;
- }
-#endif
-
- sh_ctxt->mfn[0] = emulate_gva_to_mfn(v, vaddr, sh_ctxt);
- if ( !mfn_valid(sh_ctxt->mfn[0]) )
- {
- switch ( mfn_x(sh_ctxt->mfn[0]) )
- {
- case BAD_GVA_TO_GFN: return MAPPING_EXCEPTION;
- case READONLY_GFN: return MAPPING_SILENT_FAIL;
- default: return MAPPING_UNHANDLEABLE;
- }
- }
-
- /* Unaligned writes mean probably this isn't a pagetable. */
- if ( vaddr & (bytes - 1) )
- sh_remove_shadows(d, sh_ctxt->mfn[0], 0, 0 /* Slow, can fail. */ );
-
- if ( likely(((vaddr + bytes - 1) & PAGE_MASK) == (vaddr & PAGE_MASK)) )
- {
- /* Whole write fits on a single page. */
- sh_ctxt->mfn[1] = INVALID_MFN;
- map = map_domain_page(sh_ctxt->mfn[0]) + (vaddr & ~PAGE_MASK);
- }
- else if ( !is_hvm_domain(d) )
- {
- /*
- * Cross-page emulated writes are only supported for HVM guests;
- * PV guests ought to know better.
- */
- put_page(mfn_to_page(sh_ctxt->mfn[0]));
- return MAPPING_UNHANDLEABLE;
- }
- else
- {
- /* This write crosses a page boundary. Translate the second page. */
- sh_ctxt->mfn[1] = emulate_gva_to_mfn(
- v, (vaddr + bytes - 1) & PAGE_MASK, sh_ctxt);
- if ( !mfn_valid(sh_ctxt->mfn[1]) )
- {
- put_page(mfn_to_page(sh_ctxt->mfn[0]));
- switch ( mfn_x(sh_ctxt->mfn[1]) )
- {
- case BAD_GVA_TO_GFN: return MAPPING_EXCEPTION;
- case READONLY_GFN: return MAPPING_SILENT_FAIL;
- default: return MAPPING_UNHANDLEABLE;
- }
- }
-
- /* Cross-page writes mean probably not a pagetable. */
- sh_remove_shadows(d, sh_ctxt->mfn[1], 0, 0 /* Slow, can fail. */ );
-
- map = vmap(sh_ctxt->mfn, 2);
- if ( !map )
- {
- put_page(mfn_to_page(sh_ctxt->mfn[0]));
- put_page(mfn_to_page(sh_ctxt->mfn[1]));
- return MAPPING_UNHANDLEABLE;
- }
- map += (vaddr & ~PAGE_MASK);
- }
-
-#if (SHADOW_OPTIMIZATIONS & SHOPT_SKIP_VERIFY)
- /*
- * Remember if the bottom bit was clear, so we can choose not to run
- * the change through the verify code if it's still clear afterwards.
- */
- sh_ctxt->low_bit_was_clear = map != NULL && !(*(u8 *)map & _PAGE_PRESENT);
-#endif
-
- return map;
-}
-
-/*
- * Optimization: If we see two emulated writes of zeros to the same
- * page-table without another kind of page fault in between, we guess
- * that this is a batch of changes (for process destruction) and
- * unshadow the page so we don't take a pagefault on every entry. This
- * should also make finding writeable mappings of pagetables much
- * easier.
- *
- * Look to see if this is the second emulated write in a row to this
- * page, and unshadow if it is.
- */
-static inline void check_for_early_unshadow(struct vcpu *v, mfn_t gmfn)
-{
-#if SHADOW_OPTIMIZATIONS & SHOPT_EARLY_UNSHADOW
- struct domain *d = v->domain;
-
- /*
- * If the domain has never made a "dying" op, use the two-writes
- * heuristic; otherwise, unshadow as soon as we write a zero for a dying
- * process.
- *
- * Don't bother trying to unshadow if it's not a PT, or if it's > l1.
- */
- if ( ( v->arch.paging.shadow.pagetable_dying
- || ( !d->arch.paging.shadow.pagetable_dying_op
- && v->arch.paging.shadow.last_emulated_mfn_for_unshadow == mfn_x(gmfn) ) )
- && sh_mfn_is_a_page_table(gmfn)
- && (!d->arch.paging.shadow.pagetable_dying_op ||
- !(mfn_to_page(gmfn)->shadow_flags
- & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_64))) )
- {
- perfc_incr(shadow_early_unshadow);
- sh_remove_shadows(d, gmfn, 1, 0 /* Fast, can fail to unshadow */ );
- TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_EARLY_UNSHADOW);
- }
- v->arch.paging.shadow.last_emulated_mfn_for_unshadow = mfn_x(gmfn);
-#endif
-}
-
-/*
- * Tidy up after the emulated write: mark pages dirty, verify the new
- * contents, and undo the mapping.
- */
-static void sh_emulate_unmap_dest(struct vcpu *v, void *addr,
- unsigned int bytes,
- struct sh_emulate_ctxt *sh_ctxt)
-{
- u32 b1 = bytes, b2 = 0, shflags;
-
- ASSERT(mfn_valid(sh_ctxt->mfn[0]));
-
- /* If we are writing lots of PTE-aligned zeros, might want to unshadow */
- if ( likely(bytes >= 4) && (*(u32 *)addr == 0) )
- {
- if ( !((unsigned long)addr & (sh_ctxt->pte_size - 1)) )
- check_for_early_unshadow(v, sh_ctxt->mfn[0]);
- /*
- * Don't reset the heuristic if we're writing zeros at non-aligned
- * addresses, otherwise it doesn't catch REP MOVSD on PAE guests.
- */
- }
- else
- sh_reset_early_unshadow(v);
-
- /*
- * We can avoid re-verifying the page contents after the write if:
- * - it was no larger than the PTE type of this pagetable;
- * - it was aligned to the PTE boundaries; and
- * - _PAGE_PRESENT was clear before and after the write.
- */
- shflags = mfn_to_page(sh_ctxt->mfn[0])->shadow_flags;
-#if (SHADOW_OPTIMIZATIONS & SHOPT_SKIP_VERIFY)
- if ( sh_ctxt->low_bit_was_clear
- && !(*(u8 *)addr & _PAGE_PRESENT)
- && ((!(shflags & SHF_32)
- /*
- * Not shadowed 32-bit: aligned 64-bit writes that leave
- * the present bit unset are safe to ignore.
- */
- && ((unsigned long)addr & 7) == 0
- && bytes <= 8)
- ||
- (!(shflags & (SHF_PAE|SHF_64))
- /*
- * Not shadowed PAE/64-bit: aligned 32-bit writes that
- * leave the present bit unset are safe to ignore.
- */
- && ((unsigned long)addr & 3) == 0
- && bytes <= 4)) )
- {
- /* Writes with this alignment constraint can't possibly cross pages. */
- ASSERT(!mfn_valid(sh_ctxt->mfn[1]));
- }
- else
-#endif /* SHADOW_OPTIMIZATIONS & SHOPT_SKIP_VERIFY */
- {
- if ( unlikely(mfn_valid(sh_ctxt->mfn[1])) )
- {
- /* Validate as two writes, one to each page. */
- b1 = PAGE_SIZE - (((unsigned long)addr) & ~PAGE_MASK);
- b2 = bytes - b1;
- ASSERT(b2 < bytes);
- }
- if ( likely(b1 > 0) )
- sh_validate_guest_pt_write(v, sh_ctxt->mfn[0], addr, b1);
- if ( unlikely(b2 > 0) )
- sh_validate_guest_pt_write(v, sh_ctxt->mfn[1], addr + b1, b2);
- }
-
- paging_mark_dirty(v->domain, sh_ctxt->mfn[0]);
- put_page(mfn_to_page(sh_ctxt->mfn[0]));
-
- if ( unlikely(mfn_valid(sh_ctxt->mfn[1])) )
- {
- paging_mark_dirty(v->domain, sh_ctxt->mfn[1]);
- put_page(mfn_to_page(sh_ctxt->mfn[1]));
- vunmap((void *)((unsigned long)addr & PAGE_MASK));
- }
- else
- unmap_domain_page(addr);
-
- atomic_inc(&v->domain->arch.paging.shadow.gtable_dirty_version);
-}
-#endif
-
/**************************************************************************/
/* Hash table for storing the guest->shadow mappings.
* The table itself is an array of pointers to shadows; the shadows are then
diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c
new file mode 100644
index 0000000..863f644
--- /dev/null
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -0,0 +1,590 @@
+
+/******************************************************************************
+ * arch/x86/mm/shadow/hvm.c
+ *
+ * Shadow code that does not need to be multiply compiled and is HVM only.
+ * Parts of this code are Copyright (c) 2006 by XenSource Inc.
+ * Parts of this code are Copyright (c) 2006 by Michael A Fetterman
+ * Parts based on earlier work by Michael A Fetterman, Ian Pratt et al.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <xen/types.h>
+#include <xen/mm.h>
+#include <xen/trace.h>
+#include <xen/sched.h>
+#include <xen/perfc.h>
+#include <xen/irq.h>
+#include <xen/domain_page.h>
+#include <xen/guest_access.h>
+#include <xen/keyhandler.h>
+#include <asm/event.h>
+#include <asm/page.h>
+#include <asm/current.h>
+#include <asm/flushtlb.h>
+#include <asm/shadow.h>
+#include <asm/hvm/ioreq.h>
+#include <xen/numa.h>
+#include "private.h"
+
+/**************************************************************************/
+/* x86 emulator support for the shadow code
+ */
+
+/*
+ * Returns a mapped pointer to write to, or one of the following error
+ * indicators.
+ */
+#define MAPPING_UNHANDLEABLE ERR_PTR(~(long)X86EMUL_UNHANDLEABLE)
+#define MAPPING_EXCEPTION ERR_PTR(~(long)X86EMUL_EXCEPTION)
+#define MAPPING_SILENT_FAIL ERR_PTR(~(long)X86EMUL_OKAY)
+static void *sh_emulate_map_dest(struct vcpu *v, unsigned long vaddr,
+ unsigned int bytes,
+ struct sh_emulate_ctxt *sh_ctxt);
+static void sh_emulate_unmap_dest(struct vcpu *v, void *addr,
+ unsigned int bytes,
+ struct sh_emulate_ctxt *sh_ctxt);
+
+/*
+ * Callers which pass a known in-range x86_segment can rely on the return
+ * pointer being valid. Other callers must explicitly check for errors.
+ */
+struct segment_register *hvm_get_seg_reg(
+ enum x86_segment seg, struct sh_emulate_ctxt *sh_ctxt)
+{
+ unsigned int idx = seg;
+ struct segment_register *seg_reg;
+
+ if ( idx >= ARRAY_SIZE(sh_ctxt->seg_reg) )
+ return ERR_PTR(-X86EMUL_UNHANDLEABLE);
+
+ seg_reg = &sh_ctxt->seg_reg[idx];
+ if ( !__test_and_set_bit(idx, &sh_ctxt->valid_seg_regs) )
+ hvm_get_segment_register(current, idx, seg_reg);
+ return seg_reg;
+}
+
+int hvm_translate_virtual_addr(
+ enum x86_segment seg,
+ unsigned long offset,
+ unsigned int bytes,
+ enum hvm_access_type access_type,
+ struct sh_emulate_ctxt *sh_ctxt,
+ unsigned long *linear)
+{
+ const struct segment_register *reg;
+ int okay;
+
+ reg = hvm_get_seg_reg(seg, sh_ctxt);
+ if ( IS_ERR(reg) )
+ return -PTR_ERR(reg);
+
+ okay = hvm_virtual_to_linear_addr(
+ seg, reg, offset, bytes, access_type,
+ hvm_get_seg_reg(x86_seg_cs, sh_ctxt), linear);
+
+ if ( !okay )
+ {
+ /*
+ * Leave exception injection to the caller for non-user segments: We
+ * neither know the exact error code to be used, nor can we easily
+ * determine the kind of exception (#GP or #TS) in that case.
+ */
+ if ( is_x86_user_segment(seg) )
+ x86_emul_hw_exception(
+ (seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault,
+ 0, &sh_ctxt->ctxt);
+ return X86EMUL_EXCEPTION;
+ }
+
+ return 0;
+}
+
+static int
+hvm_read(enum x86_segment seg,
+ unsigned long offset,
+ void *p_data,
+ unsigned int bytes,
+ enum hvm_access_type access_type,
+ struct sh_emulate_ctxt *sh_ctxt)
+{
+ pagefault_info_t pfinfo;
+ unsigned long addr;
+ int rc;
+
+ rc = hvm_translate_virtual_addr(
+ seg, offset, bytes, access_type, sh_ctxt, &addr);
+ if ( rc || !bytes )
+ return rc;
+
+ if ( access_type == hvm_access_insn_fetch )
+ rc = hvm_fetch_from_guest_linear(p_data, addr, bytes, 0, &pfinfo);
+ else
+ rc = hvm_copy_from_guest_linear(p_data, addr, bytes, 0, &pfinfo);
+
+ switch ( rc )
+ {
+ case HVMTRANS_okay:
+ return X86EMUL_OKAY;
+ case HVMTRANS_bad_linear_to_gfn:
+ x86_emul_pagefault(pfinfo.ec, pfinfo.linear, &sh_ctxt->ctxt);
+ return X86EMUL_EXCEPTION;
+ case HVMTRANS_bad_gfn_to_mfn:
+ case HVMTRANS_unhandleable:
+ return X86EMUL_UNHANDLEABLE;
+ case HVMTRANS_gfn_paged_out:
+ case HVMTRANS_gfn_shared:
+ return X86EMUL_RETRY;
+ }
+
+ BUG();
+ return X86EMUL_UNHANDLEABLE;
+}
+
+static int
+hvm_emulate_read(enum x86_segment seg,
+ unsigned long offset,
+ void *p_data,
+ unsigned int bytes,
+ struct x86_emulate_ctxt *ctxt)
+{
+ if ( !is_x86_user_segment(seg) )
+ return X86EMUL_UNHANDLEABLE;
+ return hvm_read(seg, offset, p_data, bytes, hvm_access_read,
+ container_of(ctxt, struct sh_emulate_ctxt, ctxt));
+}
+
+static int
+hvm_emulate_insn_fetch(enum x86_segment seg,
+ unsigned long offset,
+ void *p_data,
+ unsigned int bytes,
+ struct x86_emulate_ctxt *ctxt)
+{
+ struct sh_emulate_ctxt *sh_ctxt =
+ container_of(ctxt, struct sh_emulate_ctxt, ctxt);
+ unsigned int insn_off = offset - sh_ctxt->insn_buf_eip;
+
+ ASSERT(seg == x86_seg_cs);
+
+ /* Fall back if requested bytes are not in the prefetch cache. */
+ if ( unlikely((insn_off + bytes) > sh_ctxt->insn_buf_bytes) )
+ return hvm_read(seg, offset, p_data, bytes,
+ hvm_access_insn_fetch, sh_ctxt);
+
+ /* Hit the cache. Simple memcpy. */
+ memcpy(p_data, &sh_ctxt->insn_buf[insn_off], bytes);
+ return X86EMUL_OKAY;
+}
+
+static int
+hvm_emulate_write(enum x86_segment seg,
+ unsigned long offset,
+ void *p_data,
+ unsigned int bytes,
+ struct x86_emulate_ctxt *ctxt)
+{
+ struct sh_emulate_ctxt *sh_ctxt =
+ container_of(ctxt, struct sh_emulate_ctxt, ctxt);
+ struct vcpu *v = current;
+ unsigned long addr;
+ void *ptr;
+ int rc;
+
+ /* How many emulations could we save if we unshadowed on stack writes? */
+ if ( seg == x86_seg_ss )
+ perfc_incr(shadow_fault_emulate_stack);
+
+ rc = hvm_translate_virtual_addr(
+ seg, offset, bytes, hvm_access_write, sh_ctxt, &addr);
+ if ( rc || !bytes )
+ return rc;
+
+ /* Unaligned writes are only acceptable on HVM */
+ if ( (addr & (bytes - 1)) && !is_hvm_vcpu(v) )
+ return X86EMUL_UNHANDLEABLE;
+
+ ptr = sh_emulate_map_dest(v, addr, bytes, sh_ctxt);
+ if ( IS_ERR(ptr) )
+ return ~PTR_ERR(ptr);
+
+ paging_lock(v->domain);
+ memcpy(ptr, p_data, bytes);
+
+ if ( tb_init_done )
+ v->arch.paging.mode->shadow.trace_emul_write_val(ptr, addr,
+ p_data, bytes);
+
+ sh_emulate_unmap_dest(v, ptr, bytes, sh_ctxt);
+ shadow_audit_tables(v);
+ paging_unlock(v->domain);
+
+ return X86EMUL_OKAY;
+}
+
+static int
+hvm_emulate_cmpxchg(enum x86_segment seg,
+ unsigned long offset,
+ void *p_old,
+ void *p_new,
+ unsigned int bytes,
+ bool lock,
+ struct x86_emulate_ctxt *ctxt)
+{
+ struct sh_emulate_ctxt *sh_ctxt =
+ container_of(ctxt, struct sh_emulate_ctxt, ctxt);
+ struct vcpu *v = current;
+ unsigned long addr, old, new, prev;
+ void *ptr;
+ int rc;
+
+ if ( bytes > sizeof(long) )
+ return X86EMUL_UNHANDLEABLE;
+
+ rc = hvm_translate_virtual_addr(
+ seg, offset, bytes, hvm_access_write, sh_ctxt, &addr);
+ if ( rc )
+ return rc;
+
+ /* Unaligned writes are only acceptable on HVM */
+ if ( (addr & (bytes - 1)) && !is_hvm_vcpu(v) )
+ return X86EMUL_UNHANDLEABLE;
+
+ ptr = sh_emulate_map_dest(v, addr, bytes, sh_ctxt);
+ if ( IS_ERR(ptr) )
+ return ~PTR_ERR(ptr);
+
+ old = new = 0;
+ memcpy(&old, p_old, bytes);
+ memcpy(&new, p_new, bytes);
+
+ paging_lock(v->domain);
+ switch ( bytes )
+ {
+ case 1: prev = cmpxchg((uint8_t *)ptr, old, new); break;
+ case 2: prev = cmpxchg((uint16_t *)ptr, old, new); break;
+ case 4: prev = cmpxchg((uint32_t *)ptr, old, new); break;
+ case 8: prev = cmpxchg((uint64_t *)ptr, old, new); break;
+ default:
+ SHADOW_PRINTK("cmpxchg size %u is not supported\n", bytes);
+ prev = ~old;
+ }
+
+ if ( prev != old )
+ {
+ memcpy(p_old, &prev, bytes);
+ rc = X86EMUL_CMPXCHG_FAILED;
+ }
+
+ SHADOW_DEBUG(EMULATE,
+ "va %#lx was %#lx expected %#lx wanted %#lx now %#lx bytes %u\n",
+ addr, prev, old, new, *(unsigned long *)ptr, bytes);
+
+ sh_emulate_unmap_dest(v, ptr, bytes, sh_ctxt);
+ shadow_audit_tables(v);
+ paging_unlock(v->domain);
+
+ return rc;
+}
+
+const struct x86_emulate_ops hvm_shadow_emulator_ops = {
+ .read = hvm_emulate_read,
+ .insn_fetch = hvm_emulate_insn_fetch,
+ .write = hvm_emulate_write,
+ .cmpxchg = hvm_emulate_cmpxchg,
+ .cpuid = hvmemul_cpuid,
+};
+
+/**************************************************************************/
+/* Handling guest writes to pagetables. */
+
+/*
+ * Translate a VA to an MFN, injecting a page-fault if we fail. If the
+ * mapping succeeds, a reference will be held on the underlying page.
+ */
+#define BAD_GVA_TO_GFN (~0UL)
+#define BAD_GFN_TO_MFN (~1UL)
+#define READONLY_GFN (~2UL)
+static mfn_t emulate_gva_to_mfn(struct vcpu *v, unsigned long vaddr,
+ struct sh_emulate_ctxt *sh_ctxt)
+{
+ unsigned long gfn;
+ struct page_info *page;
+ mfn_t mfn;
+ p2m_type_t p2mt;
+ uint32_t pfec = PFEC_page_present | PFEC_write_access;
+
+ /* Translate the VA to a GFN. */
+ gfn = paging_get_hostmode(v)->gva_to_gfn(v, NULL, vaddr, &pfec);
+ if ( gfn == gfn_x(INVALID_GFN) )
+ {
+ x86_emul_pagefault(pfec, vaddr, &sh_ctxt->ctxt);
+
+ return _mfn(BAD_GVA_TO_GFN);
+ }
+
+ /* Translate the GFN to an MFN. */
+ ASSERT(!paging_locked_by_me(v->domain));
+
+ page = get_page_from_gfn(v->domain, gfn, &p2mt, P2M_ALLOC);
+
+ /* Sanity checking. */
+ if ( page == NULL )
+ {
+ return _mfn(BAD_GFN_TO_MFN);
+ }
+ if ( p2m_is_discard_write(p2mt) )
+ {
+ put_page(page);
+ return _mfn(READONLY_GFN);
+ }
+ if ( !p2m_is_ram(p2mt) )
+ {
+ put_page(page);
+ return _mfn(BAD_GFN_TO_MFN);
+ }
+ mfn = page_to_mfn(page);
+ ASSERT(mfn_valid(mfn));
+
+ v->arch.paging.last_write_was_pt = !!sh_mfn_is_a_page_table(mfn);
+
+ return mfn;
+}
+
+/*
+ * Check that the user is allowed to perform this write. If a mapping is
+ * returned, page references will be held on sh_ctxt->mfn[0] and
+ * sh_ctxt->mfn[1] iff !INVALID_MFN.
+ */
+static void *sh_emulate_map_dest(struct vcpu *v, unsigned long vaddr,
+ unsigned int bytes,
+ struct sh_emulate_ctxt *sh_ctxt)
+{
+ struct domain *d = v->domain;
+ void *map;
+
+#ifndef NDEBUG
+ /* We don't emulate user-mode writes to page tables. */
+ if ( is_hvm_domain(d) ? hvm_get_cpl(v) == 3
+ : !guest_kernel_mode(v, guest_cpu_user_regs()) )
+ {
+ gdprintk(XENLOG_DEBUG, "User-mode write to pagetable reached "
+ "emulate_map_dest(). This should never happen!\n");
+ return MAPPING_UNHANDLEABLE;
+ }
+#endif
+
+ sh_ctxt->mfn[0] = emulate_gva_to_mfn(v, vaddr, sh_ctxt);
+ if ( !mfn_valid(sh_ctxt->mfn[0]) )
+ {
+ switch ( mfn_x(sh_ctxt->mfn[0]) )
+ {
+ case BAD_GVA_TO_GFN: return MAPPING_EXCEPTION;
+ case READONLY_GFN: return MAPPING_SILENT_FAIL;
+ default: return MAPPING_UNHANDLEABLE;
+ }
+ }
+
+ /* Unaligned writes mean probably this isn't a pagetable. */
+ if ( vaddr & (bytes - 1) )
+ sh_remove_shadows(d, sh_ctxt->mfn[0], 0, 0 /* Slow, can fail. */ );
+
+ if ( likely(((vaddr + bytes - 1) & PAGE_MASK) == (vaddr & PAGE_MASK)) )
+ {
+ /* Whole write fits on a single page. */
+ sh_ctxt->mfn[1] = INVALID_MFN;
+ map = map_domain_page(sh_ctxt->mfn[0]) + (vaddr & ~PAGE_MASK);
+ }
+ else if ( !is_hvm_domain(d) )
+ {
+ /*
+ * Cross-page emulated writes are only supported for HVM guests;
+ * PV guests ought to know better.
+ */
+ put_page(mfn_to_page(sh_ctxt->mfn[0]));
+ return MAPPING_UNHANDLEABLE;
+ }
+ else
+ {
+ /* This write crosses a page boundary. Translate the second page. */
+ sh_ctxt->mfn[1] = emulate_gva_to_mfn(
+ v, (vaddr + bytes - 1) & PAGE_MASK, sh_ctxt);
+ if ( !mfn_valid(sh_ctxt->mfn[1]) )
+ {
+ put_page(mfn_to_page(sh_ctxt->mfn[0]));
+ switch ( mfn_x(sh_ctxt->mfn[1]) )
+ {
+ case BAD_GVA_TO_GFN: return MAPPING_EXCEPTION;
+ case READONLY_GFN: return MAPPING_SILENT_FAIL;
+ default: return MAPPING_UNHANDLEABLE;
+ }
+ }
+
+ /* Cross-page writes mean probably not a pagetable. */
+ sh_remove_shadows(d, sh_ctxt->mfn[1], 0, 0 /* Slow, can fail. */ );
+
+ map = vmap(sh_ctxt->mfn, 2);
+ if ( !map )
+ {
+ put_page(mfn_to_page(sh_ctxt->mfn[0]));
+ put_page(mfn_to_page(sh_ctxt->mfn[1]));
+ return MAPPING_UNHANDLEABLE;
+ }
+ map += (vaddr & ~PAGE_MASK);
+ }
+
+#if (SHADOW_OPTIMIZATIONS & SHOPT_SKIP_VERIFY)
+ /*
+ * Remember if the bottom bit was clear, so we can choose not to run
+ * the change through the verify code if it's still clear afterwards.
+ */
+ sh_ctxt->low_bit_was_clear = map != NULL && !(*(u8 *)map & _PAGE_PRESENT);
+#endif
+
+ return map;
+}
+
+/*
+ * Optimization: If we see two emulated writes of zeros to the same
+ * page-table without another kind of page fault in between, we guess
+ * that this is a batch of changes (for process destruction) and
+ * unshadow the page so we don't take a pagefault on every entry. This
+ * should also make finding writeable mappings of pagetables much
+ * easier.
+ *
+ * Look to see if this is the second emulated write in a row to this
+ * page, and unshadow if it is.
+ */
+static inline void check_for_early_unshadow(struct vcpu *v, mfn_t gmfn)
+{
+#if SHADOW_OPTIMIZATIONS & SHOPT_EARLY_UNSHADOW
+ struct domain *d = v->domain;
+
+ /*
+ * If the domain has never made a "dying" op, use the two-writes
+ * heuristic; otherwise, unshadow as soon as we write a zero for a dying
+ * process.
+ *
+ * Don't bother trying to unshadow if it's not a PT, or if it's > l1.
+ */
+ if ( ( v->arch.paging.shadow.pagetable_dying
+ || ( !d->arch.paging.shadow.pagetable_dying_op
+ && v->arch.paging.shadow.last_emulated_mfn_for_unshadow == mfn_x(gmfn) ) )
+ && sh_mfn_is_a_page_table(gmfn)
+ && (!d->arch.paging.shadow.pagetable_dying_op ||
+ !(mfn_to_page(gmfn)->shadow_flags
+ & (SHF_L2_32|SHF_L2_PAE|SHF_L2H_PAE|SHF_L4_64))) )
+ {
+ perfc_incr(shadow_early_unshadow);
+ sh_remove_shadows(d, gmfn, 1, 0 /* Fast, can fail to unshadow */ );
+ TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_EARLY_UNSHADOW);
+ }
+ v->arch.paging.shadow.last_emulated_mfn_for_unshadow = mfn_x(gmfn);
+#endif
+}
+
+/*
+ * Tidy up after the emulated write: mark pages dirty, verify the new
+ * contents, and undo the mapping.
+ */
+static void sh_emulate_unmap_dest(struct vcpu *v, void *addr,
+ unsigned int bytes,
+ struct sh_emulate_ctxt *sh_ctxt)
+{
+ u32 b1 = bytes, b2 = 0, shflags;
+
+ ASSERT(mfn_valid(sh_ctxt->mfn[0]));
+
+ /* If we are writing lots of PTE-aligned zeros, might want to unshadow */
+ if ( likely(bytes >= 4) && (*(u32 *)addr == 0) )
+ {
+ if ( !((unsigned long)addr & (sh_ctxt->pte_size - 1)) )
+ check_for_early_unshadow(v, sh_ctxt->mfn[0]);
+ /*
+ * Don't reset the heuristic if we're writing zeros at non-aligned
+ * addresses, otherwise it doesn't catch REP MOVSD on PAE guests.
+ */
+ }
+ else
+ sh_reset_early_unshadow(v);
+
+ /*
+ * We can avoid re-verifying the page contents after the write if:
+ * - it was no larger than the PTE type of this pagetable;
+ * - it was aligned to the PTE boundaries; and
+ * - _PAGE_PRESENT was clear before and after the write.
+ */
+ shflags = mfn_to_page(sh_ctxt->mfn[0])->shadow_flags;
+#if (SHADOW_OPTIMIZATIONS & SHOPT_SKIP_VERIFY)
+ if ( sh_ctxt->low_bit_was_clear
+ && !(*(u8 *)addr & _PAGE_PRESENT)
+ && ((!(shflags & SHF_32)
+ /*
+ * Not shadowed 32-bit: aligned 64-bit writes that leave
+ * the present bit unset are safe to ignore.
+ */
+ && ((unsigned long)addr & 7) == 0
+ && bytes <= 8)
+ ||
+ (!(shflags & (SHF_PAE|SHF_64))
+ /*
+ * Not shadowed PAE/64-bit: aligned 32-bit writes that
+ * leave the present bit unset are safe to ignore.
+ */
+ && ((unsigned long)addr & 3) == 0
+ && bytes <= 4)) )
+ {
+ /* Writes with this alignment constraint can't possibly cross pages. */
+ ASSERT(!mfn_valid(sh_ctxt->mfn[1]));
+ }
+ else
+#endif /* SHADOW_OPTIMIZATIONS & SHOPT_SKIP_VERIFY */
+ {
+ if ( unlikely(mfn_valid(sh_ctxt->mfn[1])) )
+ {
+ /* Validate as two writes, one to each page. */
+ b1 = PAGE_SIZE - (((unsigned long)addr) & ~PAGE_MASK);
+ b2 = bytes - b1;
+ ASSERT(b2 < bytes);
+ }
+ if ( likely(b1 > 0) )
+ sh_validate_guest_pt_write(v, sh_ctxt->mfn[0], addr, b1);
+ if ( unlikely(b2 > 0) )
+ sh_validate_guest_pt_write(v, sh_ctxt->mfn[1], addr + b1, b2);
+ }
+
+ paging_mark_dirty(v->domain, sh_ctxt->mfn[0]);
+ put_page(mfn_to_page(sh_ctxt->mfn[0]));
+
+ if ( unlikely(mfn_valid(sh_ctxt->mfn[1])) )
+ {
+ paging_mark_dirty(v->domain, sh_ctxt->mfn[1]);
+ put_page(mfn_to_page(sh_ctxt->mfn[1]));
+ vunmap((void *)((unsigned long)addr & PAGE_MASK));
+ }
+ else
+ unmap_domain_page(addr);
+
+ atomic_inc(&v->domain->arch.paging.shadow.gtable_dirty_version);
+}
+
+/*
+ * 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] 130+ messages in thread* Re: [PATCH 26/34] x86/mm/shadow: split out HVM only code
2018-08-17 15:12 ` [PATCH 26/34] x86/mm/shadow: split out HVM only code Wei Liu
@ 2018-08-21 11:36 ` Jan Beulich
2018-08-24 6:57 ` Tim Deegan
1 sibling, 0 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 11:36 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, Tim Deegan, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> --- /dev/null
> +++ b/xen/arch/x86/mm/shadow/hvm.c
> @@ -0,0 +1,590 @@
> +
> +/******************************************************************************
> + * arch/x86/mm/shadow/hvm.c
> + *
> + * Shadow code that does not need to be multiply compiled and is HVM only.
> + * Parts of this code are Copyright (c) 2006 by XenSource Inc.
> + * Parts of this code are Copyright (c) 2006 by Michael A Fetterman
> + * Parts based on earlier work by Michael A Fetterman, Ian Pratt et al.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <xen/types.h>
> +#include <xen/mm.h>
> +#include <xen/trace.h>
> +#include <xen/sched.h>
> +#include <xen/perfc.h>
> +#include <xen/irq.h>
> +#include <xen/domain_page.h>
> +#include <xen/guest_access.h>
> +#include <xen/keyhandler.h>
At the example of this specific include I once again wonder whether
you've simply copied the list of includes from the original file.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 26/34] x86/mm/shadow: split out HVM only code
2018-08-17 15:12 ` [PATCH 26/34] x86/mm/shadow: split out HVM only code Wei Liu
2018-08-21 11:36 ` Jan Beulich
@ 2018-08-24 6:57 ` Tim Deegan
1 sibling, 0 replies; 130+ messages in thread
From: Tim Deegan @ 2018-08-24 6:57 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, xen-devel, Jan Beulich, Andrew Cooper
At 16:12 +0100 on 17 Aug (1534522364), Wei Liu wrote:
> Move the code previously enclosed in CONFIG_HVM into its own file.
>
> Note that although some code explicitly check is_hvm_*, which hints it
> can be used for PV too, I can't find a code path that would be the
> case.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 27/34] x86: make hvm_inject_* functions build when !CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (25 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 26/34] x86/mm/shadow: split out HVM only code Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 8:37 ` Roger Pau Monné
2018-08-21 11:39 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 28/34] x86/vm_event: put vm_event_fill_regs under CONFIG_HVM Wei Liu
` (8 subsequent siblings)
35 siblings, 2 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
They reference hvm_inject_event which is HVM code (not compiled). They
aren't used by code outside HVM code anyway.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/include/asm-x86/hvm/hvm.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index b3bc8d2..0444f3b 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -422,6 +422,7 @@ static inline void hvm_inject_exception(
unsigned int vector, unsigned int type,
unsigned int insn_len, int error_code)
{
+#if CONFIG_HVM
struct x86_event event = {
.vector = vector,
.type = type,
@@ -430,10 +431,12 @@ static inline void hvm_inject_exception(
};
hvm_inject_event(&event);
+#endif
}
static inline void hvm_inject_hw_exception(unsigned int vector, int errcode)
{
+#if CONFIG_HVM
struct x86_event event = {
.vector = vector,
.type = X86_EVENTTYPE_HW_EXCEPTION,
@@ -441,10 +444,12 @@ static inline void hvm_inject_hw_exception(unsigned int vector, int errcode)
};
hvm_inject_event(&event);
+#endif
}
static inline void hvm_inject_page_fault(int errcode, unsigned long cr2)
{
+#if CONFIG_HVM
struct x86_event event = {
.vector = TRAP_page_fault,
.type = X86_EVENTTYPE_HW_EXCEPTION,
@@ -453,6 +458,7 @@ static inline void hvm_inject_page_fault(int errcode, unsigned long cr2)
};
hvm_inject_event(&event);
+#endif
}
static inline int hvm_event_pending(struct vcpu *v)
--
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] 130+ messages in thread* Re: [PATCH 27/34] x86: make hvm_inject_* functions build when !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 27/34] x86: make hvm_inject_* functions build when !CONFIG_HVM Wei Liu
@ 2018-08-21 8:37 ` Roger Pau Monné
2018-08-24 16:27 ` Wei Liu
2018-08-21 11:39 ` Jan Beulich
1 sibling, 1 reply; 130+ messages in thread
From: Roger Pau Monné @ 2018-08-21 8:37 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, Jan Beulich, Andrew Cooper
On Fri, Aug 17, 2018 at 04:12:45PM +0100, Wei Liu wrote:
> They reference hvm_inject_event which is HVM code (not compiled). They
> aren't used by code outside HVM code anyway.
Can you put all the functions inside of an #ifdef CONFIG_HVM instead
of making them no-ops?
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 27/34] x86: make hvm_inject_* functions build when !CONFIG_HVM
2018-08-21 8:37 ` Roger Pau Monné
@ 2018-08-24 16:27 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-24 16:27 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel, Wei Liu, Jan Beulich, Andrew Cooper
On Tue, Aug 21, 2018 at 10:37:24AM +0200, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 04:12:45PM +0100, Wei Liu wrote:
> > They reference hvm_inject_event which is HVM code (not compiled). They
> > aren't used by code outside HVM code anyway.
>
> Can you put all the functions inside of an #ifdef CONFIG_HVM instead
> of making them no-ops?
>
> Thanks, Roger.
This patch has been dropped in new version of the series.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 27/34] x86: make hvm_inject_* functions build when !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 27/34] x86: make hvm_inject_* functions build when !CONFIG_HVM Wei Liu
2018-08-21 8:37 ` Roger Pau Monné
@ 2018-08-21 11:39 ` Jan Beulich
1 sibling, 0 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 11:39 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> They reference hvm_inject_event which is HVM code (not compiled). They
> aren't used by code outside HVM code anyway.
Again looks to be a case of DCE doing its job (if arranged for properly)
instead of adding #ifdef-s to functions which ought to be entirely
unavailable when !HVM. So if anything, I could once again see the
functions as a whole disappear in that case, not just their bodies.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 28/34] x86/vm_event: put vm_event_fill_regs under CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (26 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 27/34] x86: make hvm_inject_* functions build when !CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-19 16:41 ` Razvan Cojocaru
2018-08-17 15:12 ` [PATCH 29/34] x86/mm: put paging_update_nestedmode " Wei Liu
` (7 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel
Cc: Andrew Cooper, Tamas K Lengyel, Wei Liu, Jan Beulich, Razvan Cojocaru
Ideally the HVM specific part of VM event should be moved into hvm/ at
some point, but this will do for now.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/vm_event.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index f91aade..b4f6afb 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -124,6 +124,7 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
void vm_event_fill_regs(vm_event_request_t *req)
{
+#if CONFIG_HVM
const struct cpu_user_regs *regs = guest_cpu_user_regs();
struct segment_register seg;
struct hvm_hw_cpu ctxt;
@@ -177,6 +178,7 @@ void vm_event_fill_regs(vm_event_request_t *req)
hvm_get_segment_register(curr, x86_seg_cs, &seg);
req->data.regs.x86.cs_arbytes = seg.attr;
+#endif
}
void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
--
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] 130+ messages in thread* Re: [PATCH 28/34] x86/vm_event: put vm_event_fill_regs under CONFIG_HVM
2018-08-17 15:12 ` [PATCH 28/34] x86/vm_event: put vm_event_fill_regs under CONFIG_HVM Wei Liu
@ 2018-08-19 16:41 ` Razvan Cojocaru
2018-08-21 10:45 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Razvan Cojocaru @ 2018-08-19 16:41 UTC (permalink / raw)
To: Wei Liu, xen-devel; +Cc: Andrew Cooper, Tamas K Lengyel, Jan Beulich
On 8/17/18 6:12 PM, Wei Liu wrote:
> Ideally the HVM specific part of VM event should be moved into hvm/ at
> some point, but this will do for now.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> xen/arch/x86/vm_event.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> index f91aade..b4f6afb 100644
> --- a/xen/arch/x86/vm_event.c
> +++ b/xen/arch/x86/vm_event.c
> @@ -124,6 +124,7 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
>
> void vm_event_fill_regs(vm_event_request_t *req)
> {
> +#if CONFIG_HVM
> const struct cpu_user_regs *regs = guest_cpu_user_regs();
> struct segment_register seg;
> struct hvm_hw_cpu ctxt;
> @@ -177,6 +178,7 @@ void vm_event_fill_regs(vm_event_request_t *req)
>
> hvm_get_segment_register(curr, x86_seg_cs, &seg);
> req->data.regs.x86.cs_arbytes = seg.attr;
> +#endif
> }
Some registers can be obtained here without using HVM-specific code,
unless I'm misunderstanding how it works. So I wonder if it wouldn't be
better to put only the "struct hvm_hw_cpu ctxt;"-related code under
CONFIG_HVM - that way what can be queried via guest_cpu_user_regs()
alone won't be lost.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 28/34] x86/vm_event: put vm_event_fill_regs under CONFIG_HVM
2018-08-19 16:41 ` Razvan Cojocaru
@ 2018-08-21 10:45 ` Wei Liu
2018-08-21 11:00 ` Razvan Cojocaru
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-21 10:45 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: xen-devel, Tamas K Lengyel, Wei Liu, Jan Beulich, Andrew Cooper
On Sun, Aug 19, 2018 at 07:41:11PM +0300, Razvan Cojocaru wrote:
> On 8/17/18 6:12 PM, Wei Liu wrote:
> > Ideally the HVM specific part of VM event should be moved into hvm/ at
> > some point, but this will do for now.
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > xen/arch/x86/vm_event.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> > index f91aade..b4f6afb 100644
> > --- a/xen/arch/x86/vm_event.c
> > +++ b/xen/arch/x86/vm_event.c
> > @@ -124,6 +124,7 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
> >
> > void vm_event_fill_regs(vm_event_request_t *req)
> > {
> > +#if CONFIG_HVM
> > const struct cpu_user_regs *regs = guest_cpu_user_regs();
> > struct segment_register seg;
> > struct hvm_hw_cpu ctxt;
> > @@ -177,6 +178,7 @@ void vm_event_fill_regs(vm_event_request_t *req)
> >
> > hvm_get_segment_register(curr, x86_seg_cs, &seg);
> > req->data.regs.x86.cs_arbytes = seg.attr;
> > +#endif
> > }
>
> Some registers can be obtained here without using HVM-specific code,
> unless I'm misunderstanding how it works. So I wonder if it wouldn't be
> better to put only the "struct hvm_hw_cpu ctxt;"-related code under
> CONFIG_HVM - that way what can be queried via guest_cpu_user_regs()
> alone won't be lost.
>
But there is an assertion for is_hvm_vcpu at the beginning of the
function, that's how I got the impression that function is supposed to
be HVM only. Do you want me to remove that ASSERT too?
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] 130+ messages in thread* Re: [PATCH 28/34] x86/vm_event: put vm_event_fill_regs under CONFIG_HVM
2018-08-21 10:45 ` Wei Liu
@ 2018-08-21 11:00 ` Razvan Cojocaru
0 siblings, 0 replies; 130+ messages in thread
From: Razvan Cojocaru @ 2018-08-21 11:00 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, Tamas K Lengyel, Jan Beulich, Andrew Cooper
On 8/21/18 1:45 PM, Wei Liu wrote:
> On Sun, Aug 19, 2018 at 07:41:11PM +0300, Razvan Cojocaru wrote:
>> On 8/17/18 6:12 PM, Wei Liu wrote:
>>> Ideally the HVM specific part of VM event should be moved into hvm/ at
>>> some point, but this will do for now.
>>>
>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>> ---
>>> xen/arch/x86/vm_event.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
>>> index f91aade..b4f6afb 100644
>>> --- a/xen/arch/x86/vm_event.c
>>> +++ b/xen/arch/x86/vm_event.c
>>> @@ -124,6 +124,7 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
>>>
>>> void vm_event_fill_regs(vm_event_request_t *req)
>>> {
>>> +#if CONFIG_HVM
>>> const struct cpu_user_regs *regs = guest_cpu_user_regs();
>>> struct segment_register seg;
>>> struct hvm_hw_cpu ctxt;
>>> @@ -177,6 +178,7 @@ void vm_event_fill_regs(vm_event_request_t *req)
>>>
>>> hvm_get_segment_register(curr, x86_seg_cs, &seg);
>>> req->data.regs.x86.cs_arbytes = seg.attr;
>>> +#endif
>>> }
>>
>> Some registers can be obtained here without using HVM-specific code,
>> unless I'm misunderstanding how it works. So I wonder if it wouldn't be
>> better to put only the "struct hvm_hw_cpu ctxt;"-related code under
>> CONFIG_HVM - that way what can be queried via guest_cpu_user_regs()
>> alone won't be lost.
>>
>
> But there is an assertion for is_hvm_vcpu at the beginning of the
> function, that's how I got the impression that function is supposed to
> be HVM only. Do you want me to remove that ASSERT too?
At the moment it only make sense for HVM, but since that assert this
comment appeared in include/asm-x86/monitor.h:
73 /*
74 * At the moment only Intel and AMD HVM domains are supported.
However,
75 * event delivery could be extended to PV domains.
76 */
and there has been an (unsuccessful) series to add vm_events to PV domains:
https://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01010.html
That's what I had in mind when I said that not everything there is tied
to HVM. However, we have no current plans to extend mem_access to PV and
the function does indeed only makes sense for HVM domains at the moment,
so unless Tamas or other maintainers have something against your changes
I suppose we don't need to anticipate PV support yet.
So,
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] 130+ messages in thread
* [PATCH 29/34] x86/mm: put paging_update_nestedmode under CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (27 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 28/34] x86/vm_event: put vm_event_fill_regs under CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 11:41 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 30/34] x86: PIT emulation is common to PV and HVM Wei Liu
` (6 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 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..2aec1d4 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -921,6 +921,7 @@ const struct paging_mode *paging_get_mode(struct vcpu *v)
void paging_update_nestedmode(struct vcpu *v)
{
+#if CONFIG_HVM
ASSERT(nestedhvm_enabled(v->domain));
if (nestedhvm_paging_mode_hap(v))
/* nested-on-nested */
@@ -929,6 +930,7 @@ void paging_update_nestedmode(struct vcpu *v)
/* TODO: shadow-on-shadow */
v->arch.paging.nestedmode = NULL;
hvm_asid_flush_vcpu(v);
+#endif
}
void paging_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
--
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] 130+ messages in thread* Re: [PATCH 29/34] x86/mm: put paging_update_nestedmode under CONFIG_HVM
2018-08-17 15:12 ` [PATCH 29/34] x86/mm: put paging_update_nestedmode " Wei Liu
@ 2018-08-21 11:41 ` Jan Beulich
2018-08-24 16:28 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 11:41 UTC (permalink / raw)
To: Wei Liu; +Cc: George Dunlap, Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> Nested HVM is not enabled when !CONFIG_HVM.
All callers of the function sit under hvm/, so once again I don't see
why the function needs to remain available with an empty body.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 29/34] x86/mm: put paging_update_nestedmode under CONFIG_HVM
2018-08-21 11:41 ` Jan Beulich
@ 2018-08-24 16:28 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-24 16:28 UTC (permalink / raw)
To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Wei Liu, xen-devel
On Tue, Aug 21, 2018 at 05:41:49AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > Nested HVM is not enabled when !CONFIG_HVM.
>
> All callers of the function sit under hvm/, so once again I don't see
> why the function needs to remain available with an empty body.
Yes the whole function can be put 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] 130+ messages in thread
* [PATCH 30/34] x86: PIT emulation is common to PV and HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (28 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 29/34] x86/mm: put paging_update_nestedmode " Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 8:03 ` Roger Pau Monné
2018-08-21 11:43 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM Wei Liu
` (5 subsequent siblings)
35 siblings, 2 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
Move the common parts to emul-i8254.c. This requires moving some of
the macros to vpt.h. Some of the code in common code is put under
is_hvm_* checks so that DCE can kick in. Factor out HVM only
pit_load_count_channel0 to reduce amount of code in x86 common code.
Leave HVM specific code where it was before.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/Makefile | 1 +-
xen/arch/x86/emul-i8254.c | 506 +++++++++++++++++++++++++++++++++++-
xen/arch/x86/hvm/i8254.c | 462 +--------------------------------
xen/include/asm-x86/hvm/vpt.h | 9 +-
4 files changed, 521 insertions(+), 457 deletions(-)
create mode 100644 xen/arch/x86/emul-i8254.c
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 9b9b63a..5a42ff7 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..605098c
--- /dev/null
+++ b/xen/arch/x86/emul-i8254.c
@@ -0,0 +1,506 @@
+/*
+ * 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 RW_STATE_LSB 1
+#define RW_STATE_MSB 2
+#define RW_STATE_WORD0 3
+#define RW_STATE_WORD1 4
+
+#define vcpu_vpit(x) (domain_vpit((x)->domain))
+
+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;
+}
+
+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) || (channel != 0) )
+ return;
+
+ if ( is_hvm_vcpu(v) )
+ pit_load_count_channel0(pit, period);
+}
+
+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;
+}
+
+/* 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;
+}
+
+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);
+ }
+}
+
+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);
+}
+
+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/i8254.c b/xen/arch/x86/hvm/i8254.c
index b8ec56f..5115022 100644
--- a/xen/arch/x86/hvm/i8254.c
+++ b/xen/arch/x86/hvm/i8254.c
@@ -38,124 +38,6 @@
#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;
@@ -163,26 +45,12 @@ static void pit_time_fired(struct vcpu *v, void *priv)
*count_load_time = get_guest_time(v);
}
-static void pit_load_count(PITState *pit, int channel, int val)
+void pit_load_count_channel0(PITState *pit, uint32_t period)
{
- u32 period;
- struct hvm_hw_pit_channel *s = &pit->hw.channels[channel];
+ struct hvm_hw_pit_channel *s = &pit->hw.channels[0];
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;
+ ASSERT(is_hvm_vcpu(v));
switch ( s->mode )
{
@@ -191,14 +59,14 @@ static void pit_load_count(PITState *pit, int channel, int val)
/* 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);
+ &pit->count_load_time[0], 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);
+ &pit->count_load_time[0], false);
break;
default:
TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER);
@@ -207,178 +75,6 @@ static void pit_load_count(PITState *pit, int channel, int val)
}
}
-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) )
@@ -439,154 +135,6 @@ static int pit_load(struct domain *d, hvm_domain_context_t *h)
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
diff --git a/xen/include/asm-x86/hvm/vpt.h b/xen/include/asm-x86/hvm/vpt.h
index 61c26ed..0064ad8 100644
--- a/xen/include/asm-x86/hvm/vpt.h
+++ b/xen/include/asm-x86/hvm/vpt.h
@@ -178,6 +178,8 @@ void pit_reset(struct domain *d);
void pit_init(struct domain *d, unsigned long cpu_khz);
void pit_stop_channel0_irq(PITState * pit);
+void pit_load_count(PITState *pit, int channel, int val);
+void pit_load_count_channel0(PITState *pit, uint32_t period);
void pit_deinit(struct domain *d);
void rtc_init(struct domain *d);
void rtc_migrate_timers(struct vcpu *v);
@@ -194,4 +196,11 @@ void hpet_init(struct domain *d);
void hpet_deinit(struct domain *d);
void hpet_reset(struct domain *d);
+#define domain_vpit(x) (&(x)->arch.vpit)
+#define vpit_domain(x) (container_of((x), struct domain, arch.vpit))
+#define vpit_vcpu(x) (pt_global_vcpu_target(vpit_domain(x)))
+
+#define get_guest_time(v) \
+ (is_hvm_vcpu(v) ? hvm_get_guest_time(v) : (u64)get_s_time())
+
#endif /* __ASM_X86_HVM_VPT_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] 130+ messages in thread* Re: [PATCH 30/34] x86: PIT emulation is common to PV and HVM
2018-08-17 15:12 ` [PATCH 30/34] x86: PIT emulation is common to PV and HVM Wei Liu
@ 2018-08-21 8:03 ` Roger Pau Monné
2018-08-21 11:43 ` Jan Beulich
1 sibling, 0 replies; 130+ messages in thread
From: Roger Pau Monné @ 2018-08-21 8:03 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, Jan Beulich, Andrew Cooper
On Fri, Aug 17, 2018 at 04:12:48PM +0100, Wei Liu wrote:
> Move the common parts to emul-i8254.c. This requires moving some of
> the macros to vpt.h. Some of the code in common code is put under
> is_hvm_* checks so that DCE can kick in. Factor out HVM only
> pit_load_count_channel0 to reduce amount of code in x86 common code.
>
> Leave HVM specific code where it was before.
IMO I would rather have the whole emulation code in a single file and
the HVM only functions guarded by CONFIG_HVM. I think it's easier to
find and understand the code if it's all placed in a single file.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 30/34] x86: PIT emulation is common to PV and HVM
2018-08-17 15:12 ` [PATCH 30/34] x86: PIT emulation is common to PV and HVM Wei Liu
2018-08-21 8:03 ` Roger Pau Monné
@ 2018-08-21 11:43 ` Jan Beulich
1 sibling, 0 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 11:43 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> Move the common parts to emul-i8254.c. This requires moving some of
> the macros to vpt.h. Some of the code in common code is put under
> is_hvm_* checks so that DCE can kick in. Factor out HVM only
> pit_load_count_channel0 to reduce amount of code in x86 common code.
>
> Leave HVM specific code where it was before.
>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> xen/arch/x86/Makefile | 1 +-
> xen/arch/x86/emul-i8254.c | 506 +++++++++++++++++++++++++++++++++++-
> xen/arch/x86/hvm/i8254.c | 462 +--------------------------------
When the file as a whole is 600 lines, I think I agree with Roger
that moving the entire file (and adding some #ifdef-ary) is
probably better, and avoids exposing internals through vpt.h.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (29 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 30/34] x86: PIT emulation is common to PV and HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-20 12:59 ` Andrew Cooper
2018-08-21 11:46 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 32/34] x86: expose CONFIG_HVM Wei Liu
` (4 subsequent siblings)
35 siblings, 2 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 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 | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 171d25e..a22df12 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -318,8 +318,14 @@ struct domain *domain_create(domid_t domid,
if ( !is_idle_domain(d) )
{
if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
+ {
+#if CONFIG_HVM
d->guest_type = guest_type_hvm;
- else
+#else
+ err = -EINVAL;
+ goto fail;
+#endif
+ } else
d->guest_type = guest_type_pv;
watchdog_domain_init(d);
--
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] 130+ messages in thread* Re: [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM Wei Liu
@ 2018-08-20 12:59 ` Andrew Cooper
2018-08-21 10:41 ` Wei Liu
2018-08-21 11:46 ` Jan Beulich
1 sibling, 1 reply; 130+ messages in thread
From: Andrew Cooper @ 2018-08-20 12:59 UTC (permalink / raw)
To: Wei Liu, xen-devel
Cc: Stefano Stabellini, George Dunlap, Tim Deegan, Ian Jackson,
Julien Grall, Jan Beulich
On 17/08/2018 16:12, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> xen/common/domain.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 171d25e..a22df12 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -318,8 +318,14 @@ struct domain *domain_create(domid_t domid,
> if ( !is_idle_domain(d) )
> {
> if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
As discovered during my domain creation rewrite work, libxl on ARM
doesn't set hvm/hap.
IMO, they should, and libxl should be fixed.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM
2018-08-20 12:59 ` Andrew Cooper
@ 2018-08-21 10:41 ` Wei Liu
2018-08-21 18:35 ` Julien Grall
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-21 10:41 UTC (permalink / raw)
To: Andrew Cooper
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Tim Deegan,
Ian Jackson, Julien Grall, Jan Beulich, xen-devel
On Mon, Aug 20, 2018 at 01:59:57PM +0100, Andrew Cooper wrote:
> On 17/08/2018 16:12, Wei Liu wrote:
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > xen/common/domain.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 171d25e..a22df12 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -318,8 +318,14 @@ struct domain *domain_create(domid_t domid,
> > if ( !is_idle_domain(d) )
> > {
> > if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
>
> As discovered during my domain creation rewrite work, libxl on ARM
> doesn't set hvm/hap.
>
> IMO, they should, and libxl should be fixed.
>
ISTR they wanted guest type to be PV in libxl.
Wei.
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM
2018-08-21 10:41 ` Wei Liu
@ 2018-08-21 18:35 ` Julien Grall
0 siblings, 0 replies; 130+ messages in thread
From: Julien Grall @ 2018-08-21 18:35 UTC (permalink / raw)
To: Wei Liu, Andrew Cooper
Cc: Stefano Stabellini, George Dunlap, Tim Deegan, Ian Jackson,
Jan Beulich, xen-devel
Hi Wei,
On 08/21/2018 11:41 AM, Wei Liu wrote:
> On Mon, Aug 20, 2018 at 01:59:57PM +0100, Andrew Cooper wrote:
>> On 17/08/2018 16:12, Wei Liu wrote:
>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>> ---
>>> xen/common/domain.c | 8 +++++++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>> index 171d25e..a22df12 100644
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -318,8 +318,14 @@ struct domain *domain_create(domid_t domid,
>>> if ( !is_idle_domain(d) )
>>> {
>>> if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
>>
>> As discovered during my domain creation rewrite work, libxl on ARM
>> doesn't set hvm/hap.
>>
>> IMO, they should, and libxl should be fixed.
>>
>
> ISTR they wanted guest type to be PV in libxl.
I think that was because PV was allowing us to not start QEMU. Now that
PVH exists in lixbl, libxl should be switched to use PVH for Arm guest.
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] 130+ messages in thread
* Re: [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM
2018-08-17 15:12 ` [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM Wei Liu
2018-08-20 12:59 ` Andrew Cooper
@ 2018-08-21 11:46 ` Jan Beulich
1 sibling, 0 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 11:46 UTC (permalink / raw)
To: Wei Liu
Cc: Stefano Stabellini, George Dunlap, Andrew Cooper, Ian Jackson,
Tim Deegan, Julien Grall, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -318,8 +318,14 @@ struct domain *domain_create(domid_t domid,
> if ( !is_idle_domain(d) )
> {
> if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
> + {
> +#if CONFIG_HVM
> d->guest_type = guest_type_hvm;
> - else
> +#else
> + err = -EINVAL;
> + goto fail;
> +#endif
> + } else
> d->guest_type = guest_type_pv;
Would you mind doing the CONFIG_PV case of this as well, which
would then probably also make more apparent that the "else"
above belongs on its own line? Of course once again part of the
final look of this section depends on what ARM folks want to do
with regard to 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] 130+ messages in thread
* [PATCH 32/34] x86: expose CONFIG_HVM
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (30 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 11:48 ` Jan Beulich
2018-08-17 15:12 ` [PATCH 33/34] x86/pvshim: disable HVM for PV shim Wei Liu
` (3 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 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/Kconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 73ab8f8..75aa2f2 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] 130+ messages in thread* Re: [PATCH 32/34] x86: expose CONFIG_HVM
2018-08-17 15:12 ` [PATCH 32/34] x86: expose CONFIG_HVM Wei Liu
@ 2018-08-21 11:48 ` Jan Beulich
2018-08-21 12:49 ` Andrew Cooper
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 11:48 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <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.
As said before, this wants to gain a dependency on !PV_SHIM_EXCLUSIVE.
Also, please use proper (tab) indentation also for the help portion.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 32/34] x86: expose CONFIG_HVM
2018-08-21 11:48 ` Jan Beulich
@ 2018-08-21 12:49 ` Andrew Cooper
2018-08-21 12:57 ` Jan Beulich
0 siblings, 1 reply; 130+ messages in thread
From: Andrew Cooper @ 2018-08-21 12:49 UTC (permalink / raw)
To: Jan Beulich, Wei Liu; +Cc: xen-devel
On 21/08/2018 12:48, Jan Beulich wrote:
>>>> On 17.08.18 at 17:12, <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.
> As said before, this wants to gain a dependency on !PV_SHIM_EXCLUSIVE.
No - it should not.
Dependencies force options to be hidden in Kconfig, which lead to very
poor use experience for people trying to find an option they expect to
be available.
There no functional dependency between HVM and PV_SHIM_EXCLUSIVE, so
there should be no dependency in Kconfig. PV_SHIM_EXCLUSIVE should
probably recommend in its help text to disable HVM, but that is the most
which Kconfig should influence.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 32/34] x86: expose CONFIG_HVM
2018-08-21 12:49 ` Andrew Cooper
@ 2018-08-21 12:57 ` Jan Beulich
0 siblings, 0 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 12:57 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Wei Liu
>>> On 21.08.18 at 14:49, <andrew.cooper3@citrix.com> wrote:
> On 21/08/2018 12:48, Jan Beulich wrote:
>>>>> On 17.08.18 at 17:12, <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.
>> As said before, this wants to gain a dependency on !PV_SHIM_EXCLUSIVE.
>
> No - it should not.
>
> Dependencies force options to be hidden in Kconfig, which lead to very
> poor use experience for people trying to find an option they expect to
> be available.
>
> There no functional dependency between HVM and PV_SHIM_EXCLUSIVE, so
> there should be no dependency in Kconfig. PV_SHIM_EXCLUSIVE should
> probably recommend in its help text to disable HVM, but that is the most
> which Kconfig should influence.
I disagree; at the very least the default of the option here should
not be Yes when PV_SHIM_EXCLUSIVE is enabled. But I think a
depends is The Right Thing To Do (tm) here; user experience when
using the various frontends is only one aspect, users getting their
selections wrong because they've been given too much control is
another. What business would a user wanting to configure the shim
have finding the HVM option?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* [PATCH 33/34] x86/pvshim: disable HVM for PV shim
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (31 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 32/34] x86: expose CONFIG_HVM Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 8:40 ` Roger Pau Monné
2018-08-17 15:12 ` [PATCH 34/34] RFC x86: introduce directio virt cap Wei Liu
` (2 subsequent siblings)
35 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson, Wei Liu
Signed-off-by: Wei Liu <wei.liu2@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] 130+ messages in thread* [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (32 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 33/34] x86/pvshim: disable HVM for PV shim Wei Liu
@ 2018-08-17 15:12 ` Wei Liu
2018-08-21 8:32 ` Roger Pau Monné
2018-08-21 11:52 ` Jan Beulich
2018-08-17 15:55 ` [PATCH 00/34] Make CONFIG_HVM work Konrad Rzeszutek Wilk
2018-08-20 9:13 ` Andrew Cooper
35 siblings, 2 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-17 15:12 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich
hvm_directio is set when iommu is enabled, but in fact iommu is not
tied to HVM. In order to not break existing tools, expose a new flag
directio for (iommu_enabled && !hvm_enabled).
RFC This doesn't build at the moment. Do we care about that flag being
inaccurate?
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
xen/arch/x86/sysctl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index e704ed7..a8d64c5 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
if ( hvm_enabled )
pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
- if ( iommu_enabled )
+ if ( hvm_enabled && iommu_enabled )
pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
+ else if ( iommu_enabled )
+ pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
}
long arch_do_sysctl(
--
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] 130+ messages in thread* Re: [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-17 15:12 ` [PATCH 34/34] RFC x86: introduce directio virt cap Wei Liu
@ 2018-08-21 8:32 ` Roger Pau Monné
2018-08-21 10:25 ` Wei Liu
2018-08-21 11:52 ` Jan Beulich
1 sibling, 1 reply; 130+ messages in thread
From: Roger Pau Monné @ 2018-08-21 8:32 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, Jan Beulich, Andrew Cooper
On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> hvm_directio is set when iommu is enabled, but in fact iommu is not
> tied to HVM. In order to not break existing tools, expose a new flag
> directio for (iommu_enabled && !hvm_enabled).
>
> RFC This doesn't build at the moment. Do we care about that flag being
> inaccurate?
I think there is no hardware out there with an IOMMU that don't have
virtualization extensions (ie: having VTd but not VTx for example),
but maybe I'm wrong.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-21 8:32 ` Roger Pau Monné
@ 2018-08-21 10:25 ` Wei Liu
2018-08-21 10:40 ` Roger Pau Monné
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-21 10:25 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel, Wei Liu, Jan Beulich, Andrew Cooper
On Tue, Aug 21, 2018 at 10:32:18AM +0200, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> > hvm_directio is set when iommu is enabled, but in fact iommu is not
> > tied to HVM. In order to not break existing tools, expose a new flag
> > directio for (iommu_enabled && !hvm_enabled).
> >
> > RFC This doesn't build at the moment. Do we care about that flag being
> > inaccurate?
>
> I think there is no hardware out there with an IOMMU that don't have
> virtualization extensions (ie: having VTd but not VTx for example),
> but maybe I'm wrong.
The question is whether it makes sense to expose the name "hvm_directio"
at all when you can't run an HVM guest in the first place.
Also iommu isn't an HVM only feature, PV guests can also make use of it
if I understand correctly, hence the suggestion of "directio".
Wei.
>
> Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-21 10:25 ` Wei Liu
@ 2018-08-21 10:40 ` Roger Pau Monné
2018-08-21 10:43 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Roger Pau Monné @ 2018-08-21 10:40 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, Jan Beulich, Andrew Cooper
On Tue, Aug 21, 2018 at 11:25:58AM +0100, Wei Liu wrote:
> On Tue, Aug 21, 2018 at 10:32:18AM +0200, Roger Pau Monné wrote:
> > On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> > > hvm_directio is set when iommu is enabled, but in fact iommu is not
> > > tied to HVM. In order to not break existing tools, expose a new flag
> > > directio for (iommu_enabled && !hvm_enabled).
> > >
> > > RFC This doesn't build at the moment. Do we care about that flag being
> > > inaccurate?
> >
> > I think there is no hardware out there with an IOMMU that don't have
> > virtualization extensions (ie: having VTd but not VTx for example),
> > but maybe I'm wrong.
>
> The question is whether it makes sense to expose the name "hvm_directio"
> at all when you can't run an HVM guest in the first place.
>
> Also iommu isn't an HVM only feature, PV guests can also make use of it
> if I understand correctly, hence the suggestion of "directio".
Right, I see your point.
Could we remove this hvm_directio artifact and just expose an iommu
capability?
Since this is a sysctl I think we can change the interface without
issues, so I would just
s/XEN_SYSCTL_PHYSCAP_hvm_directio/XEN_SYSCTL_PHYSCAP_iommu/.
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-21 10:40 ` Roger Pau Monné
@ 2018-08-21 10:43 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-21 10:43 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel, Wei Liu, Jan Beulich, Andrew Cooper
On Tue, Aug 21, 2018 at 12:40:22PM +0200, Roger Pau Monné wrote:
> On Tue, Aug 21, 2018 at 11:25:58AM +0100, Wei Liu wrote:
> > On Tue, Aug 21, 2018 at 10:32:18AM +0200, Roger Pau Monné wrote:
> > > On Fri, Aug 17, 2018 at 04:12:52PM +0100, Wei Liu wrote:
> > > > hvm_directio is set when iommu is enabled, but in fact iommu is not
> > > > tied to HVM. In order to not break existing tools, expose a new flag
> > > > directio for (iommu_enabled && !hvm_enabled).
> > > >
> > > > RFC This doesn't build at the moment. Do we care about that flag being
> > > > inaccurate?
> > >
> > > I think there is no hardware out there with an IOMMU that don't have
> > > virtualization extensions (ie: having VTd but not VTx for example),
> > > but maybe I'm wrong.
> >
> > The question is whether it makes sense to expose the name "hvm_directio"
> > at all when you can't run an HVM guest in the first place.
> >
> > Also iommu isn't an HVM only feature, PV guests can also make use of it
> > if I understand correctly, hence the suggestion of "directio".
>
> Right, I see your point.
>
> Could we remove this hvm_directio artifact and just expose an iommu
> capability?
>
> Since this is a sysctl I think we can change the interface without
> issues, so I would just
> s/XEN_SYSCTL_PHYSCAP_hvm_directio/XEN_SYSCTL_PHYSCAP_iommu/.
>
I agree and am very tempted at the moment. But let's wait to see if
there is objection.
Wei.
> Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-17 15:12 ` [PATCH 34/34] RFC x86: introduce directio virt cap Wei Liu
2018-08-21 8:32 ` Roger Pau Monné
@ 2018-08-21 11:52 ` Jan Beulich
2018-08-21 13:43 ` Wei Liu
1 sibling, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 11:52 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
> if ( hvm_enabled )
> pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
> - if ( iommu_enabled )
> + if ( hvm_enabled && iommu_enabled )
> pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
> + else if ( iommu_enabled )
> + pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
> }
At the sysctl layer I think you can, as suggested iirc by Roger,
simply replace hvm_directio with directio (or iommu). For the
"xl info" output, otoh, I'm afraid this doesn't hold, as people
may parse for the string. Depending on how this would best
be addressed in the tool stack, replacing the sysctl names may
then no longer be the most suitable solution.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-21 11:52 ` Jan Beulich
@ 2018-08-21 13:43 ` Wei Liu
2018-08-21 15:40 ` Jan Beulich
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-21 13:43 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel
On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> > --- a/xen/arch/x86/sysctl.c
> > +++ b/xen/arch/x86/sysctl.c
> > @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> > min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
> > if ( hvm_enabled )
> > pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
> > - if ( iommu_enabled )
> > + if ( hvm_enabled && iommu_enabled )
> > pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
> > + else if ( iommu_enabled )
> > + pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
> > }
>
> At the sysctl layer I think you can, as suggested iirc by Roger,
> simply replace hvm_directio with directio (or iommu). For the
> "xl info" output, otoh, I'm afraid this doesn't hold, as people
> may parse for the string. Depending on how this would best
> be addressed in the tool stack, replacing the sysctl names may
> then no longer be the most suitable solution.
In that case what do you think about the two flags this patch provides
on the toolstack level?
Essentially we change slightly hvm_directio's meaning to mean "hvm &&
iommu_enabled" while it previously mean "iommu_enabled", and then in the
absence of hvm_directio, add "directio" as an indication for
"iommu_enabled".
Wei.
>
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-21 13:43 ` Wei Liu
@ 2018-08-21 15:40 ` Jan Beulich
2018-08-21 16:02 ` Wei Liu
0 siblings, 1 reply; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 15:40 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 21.08.18 at 15:43, <wei.liu2@citrix.com> wrote:
> On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
>> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
>> > --- a/xen/arch/x86/sysctl.c
>> > +++ b/xen/arch/x86/sysctl.c
>> > @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>> > min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
>> > if ( hvm_enabled )
>> > pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
>> > - if ( iommu_enabled )
>> > + if ( hvm_enabled && iommu_enabled )
>> > pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
>> > + else if ( iommu_enabled )
>> > + pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
>> > }
>>
>> At the sysctl layer I think you can, as suggested iirc by Roger,
>> simply replace hvm_directio with directio (or iommu). For the
>> "xl info" output, otoh, I'm afraid this doesn't hold, as people
>> may parse for the string. Depending on how this would best
>> be addressed in the tool stack, replacing the sysctl names may
>> then no longer be the most suitable solution.
>
> In that case what do you think about the two flags this patch provides
> on the toolstack level?
>
> Essentially we change slightly hvm_directio's meaning to mean "hvm &&
> iommu_enabled" while it previously mean "iommu_enabled", and then in the
> absence of hvm_directio, add "directio" as an indication for
> "iommu_enabled".
I think when you mean to provide two flags, retaining the meaning
of the pre-existing one might be desirable. But as said before -
much depends on what the tool stack means to present to the user.
The expectations on the current meaning on "xl info" output should
not be broken.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-21 15:40 ` Jan Beulich
@ 2018-08-21 16:02 ` Wei Liu
2018-08-21 16:11 ` Jan Beulich
0 siblings, 1 reply; 130+ messages in thread
From: Wei Liu @ 2018-08-21 16:02 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Wei Liu, xen-devel
On Tue, Aug 21, 2018 at 09:40:07AM -0600, Jan Beulich wrote:
> >>> On 21.08.18 at 15:43, <wei.liu2@citrix.com> wrote:
> > On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
> >> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
> >> > --- a/xen/arch/x86/sysctl.c
> >> > +++ b/xen/arch/x86/sysctl.c
> >> > @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> >> > min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
> >> > if ( hvm_enabled )
> >> > pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
> >> > - if ( iommu_enabled )
> >> > + if ( hvm_enabled && iommu_enabled )
> >> > pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
> >> > + else if ( iommu_enabled )
> >> > + pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
> >> > }
> >>
> >> At the sysctl layer I think you can, as suggested iirc by Roger,
> >> simply replace hvm_directio with directio (or iommu). For the
> >> "xl info" output, otoh, I'm afraid this doesn't hold, as people
> >> may parse for the string. Depending on how this would best
> >> be addressed in the tool stack, replacing the sysctl names may
> >> then no longer be the most suitable solution.
> >
> > In that case what do you think about the two flags this patch provides
> > on the toolstack level?
> >
> > Essentially we change slightly hvm_directio's meaning to mean "hvm &&
> > iommu_enabled" while it previously mean "iommu_enabled", and then in the
> > absence of hvm_directio, add "directio" as an indication for
> > "iommu_enabled".
>
> I think when you mean to provide two flags, retaining the meaning
> of the pre-existing one might be desirable. But as said before -
> much depends on what the tool stack means to present to the user.
> The expectations on the current meaning on "xl info" output should
> not be broken.
Previously "hvm" and "hvm_directio" always show up together. The
hvm_directio only case never showed up in practice -- I don't think
there had been systems with vt-d but not vt-x.
My plan for xl info:
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
This retains sensible (though not completely identical) semantics for
hvm_directio.
The term "directio" can also be "iommu" if that's preferable.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 34/34] RFC x86: introduce directio virt cap
2018-08-21 16:02 ` Wei Liu
@ 2018-08-21 16:11 ` Jan Beulich
0 siblings, 0 replies; 130+ messages in thread
From: Jan Beulich @ 2018-08-21 16:11 UTC (permalink / raw)
To: Wei Liu; +Cc: Andrew Cooper, xen-devel
>>> On 21.08.18 at 18:02, <wei.liu2@citrix.com> wrote:
> On Tue, Aug 21, 2018 at 09:40:07AM -0600, Jan Beulich wrote:
>> >>> On 21.08.18 at 15:43, <wei.liu2@citrix.com> wrote:
>> > On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
>> >> >>> On 17.08.18 at 17:12, <wei.liu2@citrix.com> wrote:
>> >> > --- a/xen/arch/x86/sysctl.c
>> >> > +++ b/xen/arch/x86/sysctl.c
>> >> > @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>> >> > min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
>> >> > if ( hvm_enabled )
>> >> > pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
>> >> > - if ( iommu_enabled )
>> >> > + if ( hvm_enabled && iommu_enabled )
>> >> > pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
>> >> > + else if ( iommu_enabled )
>> >> > + pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
>> >> > }
>> >>
>> >> At the sysctl layer I think you can, as suggested iirc by Roger,
>> >> simply replace hvm_directio with directio (or iommu). For the
>> >> "xl info" output, otoh, I'm afraid this doesn't hold, as people
>> >> may parse for the string. Depending on how this would best
>> >> be addressed in the tool stack, replacing the sysctl names may
>> >> then no longer be the most suitable solution.
>> >
>> > In that case what do you think about the two flags this patch provides
>> > on the toolstack level?
>> >
>> > Essentially we change slightly hvm_directio's meaning to mean "hvm &&
>> > iommu_enabled" while it previously mean "iommu_enabled", and then in the
>> > absence of hvm_directio, add "directio" as an indication for
>> > "iommu_enabled".
>>
>> I think when you mean to provide two flags, retaining the meaning
>> of the pre-existing one might be desirable. But as said before -
>> much depends on what the tool stack means to present to the user.
>> The expectations on the current meaning on "xl info" output should
>> not be broken.
>
> Previously "hvm" and "hvm_directio" always show up together. The
> hvm_directio only case never showed up in practice -- I don't think
> there had been systems with vt-d but not vt-x.
>
> My plan for xl info:
>
> 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
>
> This retains sensible (though not completely identical) semantics for
> hvm_directio.
I think that ought to be fine.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 00/34] Make CONFIG_HVM work
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (33 preceding siblings ...)
2018-08-17 15:12 ` [PATCH 34/34] RFC x86: introduce directio virt cap Wei Liu
@ 2018-08-17 15:55 ` Konrad Rzeszutek Wilk
2018-08-17 16:00 ` Wei Liu
2018-08-20 9:13 ` Andrew Cooper
35 siblings, 1 reply; 130+ messages in thread
From: Konrad Rzeszutek Wilk @ 2018-08-17 15:55 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel
On Fri, Aug 17, 2018 at 04:12:18PM +0100, Wei Liu wrote:
> 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:
'PV only'? You mean HVM only surely?
>
> 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.057
> hw_caps :
> bfebfbff:77faf3ff:2c100800:00000121:0000000f:009c6fbf:00000000:00000100
> virt_caps : hvm_directio
> total_memory : 32589
> free_memory : 4158
> 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 : Fri Aug 17 12:53:34 2018 +0100 git:382ad34e4e
> 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 : Fri Aug 17 14:41:56 BST 2018
> build_id : 3989ecb7693aa02f6ecc748a951ed444cc70ba94
> xend_config_format : 4
>
> The hvm_directio flag is not accurate. See the last patch for
> discussion.
>
> 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
PV or HVM?
> worked.
>
> $ ls -l xen # PV only, non-debug
> -rwxrwxr-x 1 wei wei 1957436 Aug 17 15:32 xen
> $ ls -l xen # default build, non-debug
> -rwxrwxr-x 1 wei wei 2379388 Aug 17 15:39 xen
>
> The PV only Xen is ~17.8% smaller in size.
Well, this is the third time you said it, so maybe you did mean PV only.?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 00/34] Make CONFIG_HVM work
2018-08-17 15:55 ` [PATCH 00/34] Make CONFIG_HVM work Konrad Rzeszutek Wilk
@ 2018-08-17 16:00 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-17 16:00 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: xen-devel, Wei Liu
On Fri, Aug 17, 2018 at 11:55:10AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 17, 2018 at 04:12:18PM +0100, Wei Liu wrote:
> > 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:
>
> 'PV only'? You mean HVM only surely?
Yes, PV only -- by setting CONFIG_HVM to n.
Making CONFIG_PV work is next, then you can have HVM only Xen.
> > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p
Look here. :-)
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread
* Re: [PATCH 00/34] Make CONFIG_HVM work
2018-08-17 15:12 [PATCH 00/34] Make CONFIG_HVM work Wei Liu
` (34 preceding siblings ...)
2018-08-17 15:55 ` [PATCH 00/34] Make CONFIG_HVM work Konrad Rzeszutek Wilk
@ 2018-08-20 9:13 ` Andrew Cooper
2018-08-20 9:16 ` Wei Liu
35 siblings, 1 reply; 130+ messages in thread
From: Andrew Cooper @ 2018-08-20 9:13 UTC (permalink / raw)
To: Wei Liu, xen-devel
On 17/08/2018 16:12, Wei Liu wrote:
> 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.057
> hw_caps :
> bfebfbff:77faf3ff:2c100800:00000121:0000000f:009c6fbf:00000000:00000100
> virt_caps : hvm_directio
> total_memory : 32589
> free_memory : 4158
> 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 : Fri Aug 17 12:53:34 2018 +0100 git:382ad34e4e
> 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 : Fri Aug 17 14:41:56 BST 2018
> build_id : 3989ecb7693aa02f6ecc748a951ed444cc70ba94
> xend_config_format : 4
>
> The hvm_directio flag is not accurate. See the last patch for
> discussion.
>
> 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.
>
> $ ls -l xen # PV only, non-debug
> -rwxrwxr-x 1 wei wei 1957436 Aug 17 15:32 xen
> $ ls -l xen # default build, non-debug
> -rwxrwxr-x 1 wei wei 2379388 Aug 17 15:39 xen
>
> The PV only Xen is ~17.8% smaller in size.
Hmm - only that little? I'm somewhat surprised. I guess it will be
equally telling to see the delta for an HVM-only Xen.
Either way, to get this going in the right direction, Patches 1-4 are
trivial. Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 130+ messages in thread* Re: [PATCH 00/34] Make CONFIG_HVM work
2018-08-20 9:13 ` Andrew Cooper
@ 2018-08-20 9:16 ` Wei Liu
0 siblings, 0 replies; 130+ messages in thread
From: Wei Liu @ 2018-08-20 9:16 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Wei Liu
On Mon, Aug 20, 2018 at 10:13:07AM +0100, Andrew Cooper wrote:
> On 17/08/2018 16:12, Wei Liu wrote:
> > 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.057
> > hw_caps :
> > bfebfbff:77faf3ff:2c100800:00000121:0000000f:009c6fbf:00000000:00000100
> > virt_caps : hvm_directio
> > total_memory : 32589
> > free_memory : 4158
> > 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 : Fri Aug 17 12:53:34 2018 +0100 git:382ad34e4e
> > 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 : Fri Aug 17 14:41:56 BST 2018
> > build_id : 3989ecb7693aa02f6ecc748a951ed444cc70ba94
> > xend_config_format : 4
> >
> > The hvm_directio flag is not accurate. See the last patch for
> > discussion.
> >
> > 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.
> >
> > $ ls -l xen # PV only, non-debug
> > -rwxrwxr-x 1 wei wei 1957436 Aug 17 15:32 xen
> > $ ls -l xen # default build, non-debug
> > -rwxrwxr-x 1 wei wei 2379388 Aug 17 15:39 xen
> >
> > The PV only Xen is ~17.8% smaller in size.
>
> Hmm - only that little? I'm somewhat surprised. I guess it will be
> equally telling to see the delta for an HVM-only Xen.
There is in fact more code that should be put under CONFIG_HVM, but
that's something for later patches.
>
> Either way, to get this going in the right direction, Patches 1-4 are
> trivial. Acked-by: Andrew Cooper <andrew.cooper3@citrix.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] 130+ messages in thread