[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