xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Jan Beulich <jan.beulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH RFC v12 07/21] pvh: Disable unneeded features of HVM containers
Date: Fri, 13 Sep 2013 17:36:06 +0100	[thread overview]
Message-ID: <52333EF6.3000404@eu.citrix.com> (raw)
In-Reply-To: <1379089521-25720-8-git-send-email-george.dunlap@eu.citrix.com>

On 13/09/13 17:25, George Dunlap wrote:
> Things kept:
> * cacheattr_region lists
> * irq-related structures
> * paging
> * tm_list
>
> Things disabled for now:
> * compat xlation
>
> Things disabled:
> * Emulated timers and clock sources
> * IO/MMIO emulation
> * msix tables
> * hvm params
> * hvm_funcs
> * nested HVM
> * Fast-path for emulated lapic accesses
>
> Getting rid of the hvm_params struct required a couple other places to
> check for its existence before attempting to read the params.
>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
> CC: Jan Beulich <jan.beulich@suse.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Keir Fraser <keir@xen.org>
> ---
>   xen/arch/x86/hvm/hvm.c      |   37 ++++++++++++++++++++++++++++++++++---
>   xen/arch/x86/hvm/io.c       |    4 ++++
>   xen/arch/x86/hvm/irq.c      |    3 +++
>   xen/arch/x86/hvm/mtrr.c     |    3 ++-
>   xen/arch/x86/hvm/vmx/intr.c |    3 ++-
>   xen/arch/x86/hvm/vmx/vmcs.c |    5 +++--
>   xen/arch/x86/hvm/vmx/vmx.c  |   10 ++++++++--
>   7 files changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 1764b78..6a7a006 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -301,6 +301,10 @@ u64 hvm_get_guest_tsc_adjust(struct vcpu *v)
>   
>   void hvm_migrate_timers(struct vcpu *v)
>   {
> +    /* PVH doesn't use rtc and emulated timers, it uses pvclock mechanism. */
> +    if ( is_pvh_vcpu(v) )
> +        return;
> +
>       rtc_migrate_timers(v);
>       pt_migrate(v);
>   }
> @@ -342,10 +346,13 @@ void hvm_do_resume(struct vcpu *v)
>   {
>       ioreq_t *p;
>   
> -    pt_restore_timer(v);
> -
>       check_wakeup_from_wait();
>   
> +    if ( is_pvh_vcpu(v) )
> +        goto check_inject_trap;
> +
> +    pt_restore_timer(v);
> +
>       /* NB. Optimised for common case (p->state == STATE_IOREQ_NONE). */
>       p = get_ioreq(v);
>       while ( p->state != STATE_IOREQ_NONE )
> @@ -368,6 +375,7 @@ void hvm_do_resume(struct vcpu *v)
>           }
>       }
>   
> +  check_inject_trap:
>       /* Inject pending hw/sw trap */
>       if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>       {
> @@ -521,6 +529,7 @@ int hvm_domain_initialise(struct domain *d)
>           return -EINVAL;
>       }
>   
> +    /* PVH: pbut_lock and uc_lock unused, but won't hurt */
>       spin_lock_init(&d->arch.hvm_domain.pbuf_lock);
>       spin_lock_init(&d->arch.hvm_domain.irq_lock);
>       spin_lock_init(&d->arch.hvm_domain.uc_lock);
> @@ -531,6 +540,9 @@ int hvm_domain_initialise(struct domain *d)
>       if ( rc != 0 )
>           goto fail0;
>   
> +    if ( is_pvh_domain(d) )
> +        return 0;
> +
>       INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
>       spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
>   
> @@ -584,6 +596,9 @@ int hvm_domain_initialise(struct domain *d)
>   
>   void hvm_domain_relinquish_resources(struct domain *d)
>   {
> +    if ( is_pvh_domain(d) )
> +        return;
> +
>       if ( hvm_funcs.nhvm_domain_relinquish_resources )
>           hvm_funcs.nhvm_domain_relinquish_resources(d);
>   
> @@ -609,6 +624,10 @@ void hvm_domain_relinquish_resources(struct domain *d)
>   void hvm_domain_destroy(struct domain *d)
>   {
>       hvm_destroy_cacheattr_region_list(d);
> +
> +    if ( is_pvh_domain(d) )
> +        return;
> +
>       hvm_funcs.domain_destroy(d);
>       rtc_deinit(d);
>       stdvga_deinit(d);
> @@ -1093,6 +1112,14 @@ int hvm_vcpu_initialise(struct vcpu *v)
>   
>       v->arch.hvm_vcpu.inject_trap.vector = -1;
>   
> +    if ( is_pvh_vcpu(v) )
> +    {
> +        v->arch.hvm_vcpu.hcall_64bit = 1;    /* PVH 32bitfixme. */
> +        /* This for hvm_long_mode_enabled(v). */
> +        v->arch.hvm_vcpu.guest_efer = EFER_SCE | EFER_LMA | EFER_LME;
> +        return 0;
> +    }
> +
>       rc = setup_compat_arg_xlat(v); /* teardown: free_compat_arg_xlat() */
>       if ( rc != 0 )
>           goto fail3;
> @@ -1168,7 +1195,10 @@ void hvm_vcpu_destroy(struct vcpu *v)
>   
>       tasklet_kill(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet);
>       hvm_vcpu_cacheattr_destroy(v);
> -    vlapic_destroy(v);
> +
> +    if ( is_hvm_vcpu(v) )
> +        vlapic_destroy(v);
> +
>       hvm_funcs.vcpu_destroy(v);
>   
>       /* Event channel is already freed by evtchn_destroy(). */
> @@ -1369,6 +1399,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
>       /* For the benefit of 32-bit WinXP (& older Windows) on AMD CPUs,
>        * a fast path for LAPIC accesses, skipping the p2m lookup. */
>       if ( !nestedhvm_vcpu_in_guestmode(v)
> +         && is_hvm_vcpu(v)
>            && gfn == PFN_DOWN(vlapic_base_address(vcpu_vlapic(v))) )
>       {
>           if ( !handle_mmio() )
> diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> index 4ae2c0c..3af4b34 100644
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -175,6 +175,10 @@ int handle_mmio(void)
>       struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
>       int rc;
>   
> +    /* No MMIO for PVH vcpus */
> +    if ( is_pvh_vcpu(curr) )
> +        return 0;
> +
>       hvm_emulate_prepare(&ctxt, guest_cpu_user_regs());
>   
>       rc = hvm_emulate_one(&ctxt);
> diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
> index 9eae5de..92fb245 100644
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -405,6 +405,9 @@ struct hvm_intack hvm_vcpu_has_pending_irq(struct vcpu *v)
>            && vcpu_info(v, evtchn_upcall_pending) )
>           return hvm_intack_vector(plat->irq.callback_via.vector);
>   
> +    if ( is_pvh_vcpu(v) )
> +        return hvm_intack_none;
> +
>       if ( vlapic_accept_pic_intr(v) && plat->vpic[0].int_output )
>           return hvm_intack_pic(0);
>   
> diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
> index ef51a8d..df888a6 100644
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -693,7 +693,8 @@ uint8_t epte_get_entry_emt(struct domain *d, unsigned long gfn, mfn_t mfn,
>            ((d->vcpu == NULL) || ((v = d->vcpu[0]) == NULL)) )
>           return MTRR_TYPE_WRBACK;
>   
> -    if ( !v->domain->arch.hvm_domain.params[HVM_PARAM_IDENT_PT] )
> +    if ( v->domain->arch.hvm_domain.params
> +         && !v->domain->arch.hvm_domain.params[HVM_PARAM_IDENT_PT] )

This is one thing I want to discuss: I can see why initially it was 
decided to disable hvm_params, as at the moment PVH only uses one of 
them, and this saves allocating the array for PVH domains.  But the 
result is a lot of fairly ugly things like this.  There's also (in 
another patch) a hack that allows a guest to *set* the IRQ callback via 
hvmop hvm_param_set, but not *read* it.

Additionally, as far as I can tell, the only reason we can't support mem 
events is because we don't have hvm_params.

Since I think at some point we well want to use the mem events on PVH 
guests, we should probably just allocate it now and avoid having things 
like this in the first place.

  -George

  reply	other threads:[~2013-09-13 16:36 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-13 16:25 Introduce PVH domU support George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 01/21] Fix failure path in hvm_vcpu_initialise George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 02/21] Fix failure path in construct_vmcs George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 03/21] Remove an unnecessary assert from vmx_update_debug_state George Dunlap
2013-09-16 21:09   ` Mukesh Rathor
2013-09-18 10:39     ` George Dunlap
2013-09-18 12:38       ` Jan Beulich
2013-09-18 12:53         ` George Dunlap
2013-09-18 13:51           ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 04/21] pvh prep: code motion George Dunlap
2013-09-18 12:59   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 05/21] Introduce pv guest type and has_hvm_container macros George Dunlap
2013-09-18 13:46   ` Jan Beulich
2013-09-19 16:27     ` George Dunlap
2013-09-20  8:11       ` Jan Beulich
2013-09-20  9:23         ` George Dunlap
2013-09-20  9:44           ` Jan Beulich
2013-09-19 16:58   ` George Dunlap
2013-09-20  8:38     ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 06/21] pvh: Introduce PVH guest type George Dunlap
2013-09-18 14:10   ` Jan Beulich
2013-09-20 10:01     ` George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 07/21] pvh: Disable unneeded features of HVM containers George Dunlap
2013-09-13 16:36   ` George Dunlap [this message]
     [not found]     ` <CAGU+aus16muryVYd-aOzv-CAXPk_xxVh_e-R7Ug1RxGRJ_MAfQ@mail.gmail.com>
2013-09-13 21:33       ` Aravindh Puthiyaparambil (aravindp)
2013-09-16 23:17     ` Mukesh Rathor
2013-09-18 10:50       ` George Dunlap
2013-09-18 14:18   ` Jan Beulich
2013-09-18 14:43     ` George Dunlap
2013-09-18 14:47       ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 08/21] pvh: vmx-specific changes George Dunlap
2013-09-13 16:38   ` George Dunlap
2013-09-16  7:37     ` Jan Beulich
2013-09-16  9:15       ` George Dunlap
2013-09-16 23:12     ` Mukesh Rathor
2013-09-17  8:48       ` George Dunlap
2013-09-18  0:13         ` Mukesh Rathor
2013-09-18 14:25   ` Jan Beulich
2013-09-20 13:07     ` George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 09/21] pvh: Do not allow PVH guests to change paging modes George Dunlap
2013-09-18 14:32   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 10/21] pvh: PVH access to hypercalls George Dunlap
2013-09-18 14:45   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 11/21] pvh: Use PV e820 George Dunlap
2013-09-18 14:48   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 12/21] pvh: Support guest_kernel_mode for PVH George Dunlap
2013-09-18 14:52   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 13/21] pvh: Support read_segment_register " George Dunlap
2013-09-18 14:56   ` Jan Beulich
2013-09-20 14:18     ` George Dunlap
2013-09-20 14:56       ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 14/21] pvh: read_descriptor for PVH guests George Dunlap
2013-09-13 16:40   ` George Dunlap
2013-09-18 15:00   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 15/21] pvh: Set up more PV stuff in set_info_guest George Dunlap
2013-09-18 15:17   ` Jan Beulich
2013-09-20 14:50     ` George Dunlap
2013-09-20 14:58       ` Jan Beulich
2013-09-20 15:12         ` George Dunlap
2013-09-20 15:26           ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 16/21] pvh: Use PV handlers for emulated forced invalid ops, cpuid, and IO George Dunlap
2013-09-18 15:31   ` Jan Beulich
2013-09-19  1:02     ` Mukesh Rathor
2013-09-19 10:09       ` Jan Beulich
2013-09-20 17:03         ` George Dunlap
2013-09-20 17:06           ` George Dunlap
2013-09-23  6:49           ` Jan Beulich
2013-09-23 13:48     ` George Dunlap
2013-09-23 14:09       ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 17/21] pvh: Disable 32-bit guest support for now George Dunlap
2013-09-18 15:36   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 18/21] pvh: Restrict tsc_mode to NEVER_EMULATE " George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 19/21] pvh: Disable debug traps when doing pv emulation for PVH domains George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 20/21] pvh: Disable memevents for PVH guests for now George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 21/21] pvh: Documentation George Dunlap
2013-09-13 16:41 ` Introduce PVH domU support George Dunlap

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=52333EF6.3000404@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=jan.beulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /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).