From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [PATCH 8/18 V2]: PVH xen: domain creation code changes
Date: Mon, 18 Mar 2013 11:54:07 -0400 [thread overview]
Message-ID: <20130318155407.GL24560@phenom.dumpdata.com> (raw)
In-Reply-To: <20130315173658.53f402b3@mantra.us.oracle.com>
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index 2fa2ea5..31aa04f 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -190,6 +190,11 @@ struct hvm_function_table {
> paddr_t *L1_gpa, unsigned int *page_order,
> uint8_t *p2m_acc, bool_t access_r,
> bool_t access_w, bool_t access_x);
> + /* PVH functions */
> + int (*pvh_set_vcpu_info)(struct vcpu *v, struct vcpu_guest_context *ctxtp);
> + int (*pvh_read_descriptor)(unsigned int sel, const struct vcpu *v,
> + const struct cpu_user_regs *regs, unsigned long *base,
> + unsigned long *limit, unsigned int *ar);
Ewww.. Please remove the 'pvh_' part and have a comment saying:
/* These two functions are used only in PVH mode. */
> };
>
> extern struct hvm_function_table hvm_funcs;
> @@ -323,6 +328,19 @@ static inline unsigned long hvm_get_shadow_gs_base(struct vcpu *v)
> return hvm_funcs.get_shadow_gs_base(v);
> }
>
> +static inline int hvm_pvh_set_vcpu_info(struct vcpu *v,
> + struct vcpu_guest_context *ctxtp)
> +{
> + return hvm_funcs.pvh_set_vcpu_info(v, ctxtp);
> +}
> +
> +static inline int hvm_pvh_read_descriptor(unsigned int sel,
> + const struct vcpu *v, const struct cpu_user_regs *regs,
> + unsigned long *base, unsigned long *limit, unsigned int *ar)
> +{
> + return hvm_funcs.pvh_read_descriptor(sel, v, regs, base, limit, ar);
> +}
> +
> #define is_viridian_domain(_d) \
> (is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))
>
> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
> index e8b8cd7..2725a62 100644
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -104,6 +104,13 @@ struct nestedvcpu {
>
> #define vcpu_nestedhvm(v) ((v)->arch.hvm_vcpu.nvcpu)
>
> +/* add any PVH specific fields here */
> +struct pvh_hvm_vcpu_ext
> +{
> + /* Guest-specified relocation of vcpu_info. */
> + unsigned long vcpu_info_mfn;
> +};
> +
> struct hvm_vcpu {
> /* Guest control-register and EFER values, just as the guest sees them. */
> unsigned long guest_cr[5];
> @@ -170,6 +177,8 @@ struct hvm_vcpu {
> struct hvm_trap inject_trap;
>
> struct viridian_vcpu viridian;
> +
> + struct pvh_hvm_vcpu_ext hvm_pvh;
Can you remove the two 'hvm' parts? So it is
struct pvh_vcpu_ext pvh;
?
> };
>
> #endif /* __ASM_X86_HVM_VCPU_H__ */
> diff --git a/xen/include/asm-x86/system.h b/xen/include/asm-x86/system.h
> index d8dc6f2..5681806 100644
> --- a/xen/include/asm-x86/system.h
> +++ b/xen/include/asm-x86/system.h
> @@ -4,9 +4,15 @@
> #include <xen/lib.h>
> #include <asm/bitops.h>
>
> +/* We need vcpu because during context switch, going from pure PV to PVH,
> + * in save_segments(), current has been updated to next, and no longer pointing
> + * to the pure PV. Note: for PVH, we update regs->selectors on each vmexit */
> #define read_segment_register(vcpu, regs, name) \
> ({ u16 __sel; \
> - asm volatile ( "movw %%" STR(name) ",%0" : "=r" (__sel) ); \
> + if (is_pvh_vcpu(vcpu)) \
> + __sel = regs->name; \
> + else \
> + asm volatile ( "movw %%" STR(name) ",%0" : "=r" (__sel) ); \
> __sel; \
> })
>
> --
> 1.7.2.3
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
prev parent reply other threads:[~2013-03-18 15:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-16 0:36 [PATCH 8/18 V2]: PVH xen: domain creation code changes Mukesh Rathor
2013-03-18 11:57 ` Jan Beulich
2013-03-21 16:16 ` Tim Deegan
2013-03-26 1:29 ` Mukesh Rathor
2013-03-26 7:39 ` Jan Beulich
2013-03-26 21:04 ` Mukesh Rathor
2013-03-27 7:30 ` Jan Beulich
2013-03-18 15:54 ` Konrad Rzeszutek Wilk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130318155407.GL24560@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Xen-devel@lists.xensource.com \
--cc=mukesh.rathor@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).