[Xen-devel] [PATCH v10 5/9] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from HVM
guests.
This patch introduces a new structure (vcpu_hvm_context) that should be used
in conjuction with the VCPUOP_initialise hypercall in order to initialize
vCPUs for HVM guests.
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Campbell
Cc: Stefano Stabellini
---
Changes since v9:
- s/arch_initialize_vcpu/arch_initialise_vcpu.
- s/default_initalize_vcpu/default_initialise_vcpu.
- Expanded the SEG macro in order to also de the sanity checking.
- Removed setting the .sel field in the 32bit macro.
- Removed setting the .sel and .base fields in the 64bit SEG macro.
- Fixed the calls to hvm_cr4_guest_reserved_bits and hvm_efer_valid in
order to perform the checking against the guest cpuid features.
- Moved the prototype of default_initialise_vcpu so it's after
arch_initialise_vcpu.
- Remove the HVM wrappers around vcpu_op, all vcpu ops are now available to
HVM guests.
Changes since v8:
- Create a generic default_initalize_vcpu function that can be shared with
x86 PV guests and ARM guests.
- Pass check_segment register by reference.
- Check that code/data segments always have the 'S' attribute bit set.
- Fix some of the checks done in check_segment.
- Fix indentation of gprintk calls.
- Remove failure messages in case the padding fields are not zero.
- Make hvm_efer_valid and hvm_cr4_guest_reserved_bits global and use them
to check the input values provided by the user.
- Only check the attribute field in order to figure out if a segment is
null.
- Make sure the TR segment is a system segment.
Changes since v7:
- Improved error messages.
- Set EFER.LMA if EFER.LME is set by the user.
- Fix calculation of CS limit.
- Add more checks to segment registers.
- Add checks to make sure padding fields are 0.
- Remove ugly arch ifdefs from common domain.c.
- Add the implicit padding of vcpu_hvm_x86_32 explicitly in the structure.
- Simplify the compat vcpu code since it's only used on x86.
Changes since v6:
- Add comments to clarify some initializations.
- Introduce a generic default_initialize_vcpu that's used to initialize a
ARM vCPU or a x86 PV vCPU.
- Move the undef of the SEG macro.
- Fix the size of the eflags register, it should be 32bits.
- Add a comment regarding the value of the 12-15 bits of the _ar fields.
- Remove the 16bit strucutre, the 32bit one can be used to start the cpu in
real mode.
- Add some sanity checks to the values passed in.
- Add paddings to vcpu_hvm_context so the layout on 32/64bits is the same.
- Add support for the compat version of VCPUOP_initialise.
Changes since v5:
- Fix a coding style issue.
- Merge the code from wip-dmlite-v5-refactor by Andrew in order to reduce
bloat.
- Print the offending %cr3 in case of error when using shadow.
- Reduce the scope of local variables in arch_initialize_vcpu.
- s/current->domain/v->domain/g in arch_initialize_vcpu.
- Expand the comment in public/vcpu.h to document the usage of
vcpu_hvm_context for HVM guests.
- Add myself as the copyright holder for the public hvm_vcpu.h header.
Changes since v4:
- Don't assume mode is 64B, add an explicit check.
- Don't set TF_kernel_mode, it is only needed for PV guests.
- Don't set CR0_ET unconditionally.
---
xen/arch/arm/domain.c | 5 +
xen/arch/x86/domain.c | 308 ++
xen/arch/x86/hvm/hvm.c| 61 +---
xen/common/compat/domain.c| 50 +--
xen/common/domain.c | 41 +++--
xen/include/Makefile | 1 +
xen/include/asm-x86/domain.h | 3 +
xen/include/asm-x86/hvm/hvm.h | 5 +
xen/include/public/hvm/hvm_vcpu.h | 144 ++
xen/include/public/vcpu.h | 6 +-
xen/include/xen/domain.h | 3 +
xen/include/xlat.lst | 3 +
12 files changed, 541 insertions(+), 89 deletions(-)
create mode 100644 xen/include/public/hvm/hvm_vcpu.h
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 860ac7d..3d274ae 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -756,6 +756,11 @@ int arch_set_info_guest(
return 0;
}
+int arch_initialise_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+return default_initialise_vcpu(v, arg);
+}
+
int arch_vcpu_reset(struct vcpu *v)
{
vcpu_end_shutdown_deferral(v);
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index df40dc6..ca5247d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1188,6 +1189,313 @@ int arch_set_info_guest(
#undef c
}
+static inline int check_segment(struct segment_register *reg,
+enum x86_segment seg)
+{
+
+if ( reg->att
Re: [Xen-devel] [PATCH v10 5/9] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
On Mon, 2015-12-07 at 17:48 +0100, Roger Pau Monne wrote: > Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down, > VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from HVM > guests. > > This patch introduces a new structure (vcpu_hvm_context) that should be > used > in conjuction with the VCPUOP_initialise hypercall in order to initialize "conjunction" > vCPUs for HVM guests. > > Signed-off-by: Roger Pau Monné > Signed-off-by: Andrew Cooper > Cc: Jan Beulich > Cc: Andrew Cooper For the (trivial) ARM bit: > Acked-by: Ian Campbell [...] > xen/arch/arm/domain.c | 5 + ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 5/9] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
>>> On 07.12.15 at 17:48, wrote:
> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
> VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from HVM
> guests.
>
> This patch introduces a new structure (vcpu_hvm_context) that should be used
> in conjuction with the VCPUOP_initialise hypercall in order to initialize
> vCPUs for HVM guests.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
albeit I may fiddle with some of the messages in check_segment()
upon committing, and pending clarification on ...
> +if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
> +{
> +/* Shadow-mode CR3 change. Check PDBR and update refcounts. */
> +struct page_info *page = get_page_from_gfn(v->domain,
> + v->arch.hvm_vcpu.guest_cr[3] >> PAGE_SHIFT,
> + NULL, P2M_ALLOC);
> +if ( !page )
> +{
> +gprintk(XENLOG_ERR, "Invalid CR3: %#lx\n",
> +v->arch.hvm_vcpu.guest_cr[3]);
> +domain_crash(v->domain);
> +return -EINVAL;
> +}
... why you crash the domain here when you don't on any on the
earlier error paths.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 5/9] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
El 10/12/15 a les 17.53, Jan Beulich ha escrit:
On 07.12.15 at 17:48, wrote:
>> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
>> VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from HVM
>> guests.
>>
>> This patch introduces a new structure (vcpu_hvm_context) that should be used
>> in conjuction with the VCPUOP_initialise hypercall in order to initialize
>> vCPUs for HVM guests.
>>
>> Signed-off-by: Roger Pau Monné
>> Signed-off-by: Andrew Cooper
>
> Reviewed-by: Jan Beulich
> albeit I may fiddle with some of the messages in check_segment()
> upon committing, and pending clarification on ...
>
>> +if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
>> +{
>> +/* Shadow-mode CR3 change. Check PDBR and update refcounts. */
>> +struct page_info *page = get_page_from_gfn(v->domain,
>> + v->arch.hvm_vcpu.guest_cr[3] >> PAGE_SHIFT,
>> + NULL, P2M_ALLOC);
>> +if ( !page )
>> +{
>> +gprintk(XENLOG_ERR, "Invalid CR3: %#lx\n",
>> +v->arch.hvm_vcpu.guest_cr[3]);
>> +domain_crash(v->domain);
>> +return -EINVAL;
>> +}
>
> ... why you crash the domain here when you don't on any on the
> earlier error paths.
I don't see any reason why we should crash the domain, I'm not sure
where the domain_crash call it's coming from, it's been here since the
first version of this patch.
If you want I can send a new version without the domain crash, or you
can amend it while committing. AFAICT removing the domain_crash call
doesn't have any side effects.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 5/9] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
>>> On 10.12.15 at 18:18, wrote:
> El 10/12/15 a les 17.53, Jan Beulich ha escrit:
> On 07.12.15 at 17:48, wrote:
>>> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down,
>>> VCPUOP_is_up, VCPUOP_get_physid and VCPUOP_send_nmi hypercalls from HVM
>>> guests.
>>>
>>> This patch introduces a new structure (vcpu_hvm_context) that should be used
>>> in conjuction with the VCPUOP_initialise hypercall in order to initialize
>>> vCPUs for HVM guests.
>>>
>>> Signed-off-by: Roger Pau Monné
>>> Signed-off-by: Andrew Cooper
>>
>> Reviewed-by: Jan Beulich
>> albeit I may fiddle with some of the messages in check_segment()
>> upon committing, and pending clarification on ...
>>
>>> +if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
>>> +{
>>> +/* Shadow-mode CR3 change. Check PDBR and update refcounts. */
>>> +struct page_info *page = get_page_from_gfn(v->domain,
>>> + v->arch.hvm_vcpu.guest_cr[3] >>
>>> PAGE_SHIFT,
>>> + NULL, P2M_ALLOC);
>>> +if ( !page )
>>> +{
>>> +gprintk(XENLOG_ERR, "Invalid CR3: %#lx\n",
>>> +v->arch.hvm_vcpu.guest_cr[3]);
>>> +domain_crash(v->domain);
>>> +return -EINVAL;
>>> +}
>>
>> ... why you crash the domain here when you don't on any on the
>> earlier error paths.
>
> I don't see any reason why we should crash the domain, I'm not sure
> where the domain_crash call it's coming from, it's been here since the
> first version of this patch.
>
> If you want I can send a new version without the domain crash, or you
> can amend it while committing. AFAICT removing the domain_crash call
> doesn't have any side effects.
I don't see a need for another version, unless other feedback you
might get would make that necessary.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
