linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	<xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>,
	<boris.ostrovsky@oracle.com>, <david.vrabel@citrix.com>,
	<hpa@zytor.com>, Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [PATCH v13 08/19] xen/pvh/mmu: Use PV TLB instead of native.
Date: Mon, 6 Jan 2014 11:33:00 +0000	[thread overview]
Message-ID: <alpine.DEB.2.02.1401061128130.8667@kaball.uk.xensource.com> (raw)
In-Reply-To: <20140105194155.GC12263@phenom.dumpdata.com>

On Sun, 5 Jan 2014, Konrad Rzeszutek Wilk wrote:
> On Sun, Jan 05, 2014 at 06:11:39PM +0000, Stefano Stabellini wrote:
> > On Fri, 3 Jan 2014, Konrad Rzeszutek Wilk wrote:
> > > From: Mukesh Rathor <mukesh.rathor@oracle.com>
> > > 
> > > We also optimize one - the TLB flush. The native operation would
> > > needlessly IPI offline VCPUs causing extra wakeups. Using the
> > > Xen one avoids that and lets the hypervisor determine which
> > > VCPU needs the TLB flush.
> > > 
> > > Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  arch/x86/xen/mmu.c | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > > 
> > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > > index 490ddb3..c1d406f 100644
> > > --- a/arch/x86/xen/mmu.c
> > > +++ b/arch/x86/xen/mmu.c
> > > @@ -2222,6 +2222,15 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
> > >  void __init xen_init_mmu_ops(void)
> > >  {
> > >  	x86_init.paging.pagetable_init = xen_pagetable_init;
> > > +
> > > +	/* Optimization - we can use the HVM one but it has no idea which
> > > +	 * VCPUs are descheduled - which means that it will needlessly IPI
> > > +	 * them. Xen knows so let it do the job.
> > > +	 */
> > > +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > > +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> > > +		return;
> > > +	}
> > >  	pv_mmu_ops = xen_mmu_ops;
> > >  
> > >  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> > 
> > Regarding this patch, the next one and the other changes to
> > xen_setup_shared_info, xen_setup_mfn_list_list,
> > xen_setup_vcpu_info_placement, etc: considering that the mmu related
> > stuff is very different between PV and PVH guests, I wonder if it makes
> > any sense to keep calling xen_init_mmu_ops on PVH.
> > 
> > I would introduce a new function, xen_init_pvh_mmu_ops, that sets
> > pv_mmu_ops.flush_tlb_others and only calls whatever is needed for PVH
> > under a new xen_pvh_pagetable_init.
> > Just to give you an idea, not even compiled tested:
> 
> There is something to be said about sharing the same code path
> that "old-style" PV is using with the new-style - code coverage.
> 
> That is the code gets tested under both platforms and if I (or
> anybody else) introduce a bug in the "common-PV-paths" it will
> be immediately obvious as hopefully the regression tests
> will pick it up.
> 
> It is not nice - as low-level code is sprinkled with the one-offs
> for the PVH - which mostly is doing _less_.

I thought you would say that. However in this specific case the costs
exceed the benefits. Think of all the times we'll have to debug
something, we'll be staring at the code, and several dozens of minutes
later we'll realize that the code we have been looking at all along is
not actually executed in PVH mode.


> What I was thinking is to flip this around. Make the PVH paths
> the default and then have something like 'if (!xen_pvh_domain())'
> ... the big code.
> 
> Would you be OK with this line of thinking going forward say
> after this patchset?
 
I am not opposed to it in principle but I don't expect that you'll be
able to improve things significantly.

  reply	other threads:[~2014-01-06 11:33 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-03 19:38 [PATCH v13] Linux Xen PVH support (v13) Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 01/19] xen/p2m: Check for auto-xlat when doing mfn_to_local_pfn Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 02/19] xen/pvh/x86: Define what an PVH guest is (v3) Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 03/19] xen/pvh: Early bootup changes in PV code (v4) Konrad Rzeszutek Wilk
2014-01-05 17:49   ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 04/19] xen/pvh: Don't setup P2M tree Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 05/19] xen/mmu/p2m: Refactor the xen_pagetable_init code (v2) Konrad Rzeszutek Wilk
2014-01-05 17:51   ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 06/19] xen/mmu: Cleanup xen_pagetable_p2m_copy a bit Konrad Rzeszutek Wilk
2014-01-05 17:56   ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 07/19] xen/pvh: MMU changes for PVH (v2) Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 08/19] xen/pvh/mmu: Use PV TLB instead of native Konrad Rzeszutek Wilk
2014-01-05 18:11   ` Stefano Stabellini
2014-01-05 19:41     ` Konrad Rzeszutek Wilk
2014-01-06 11:33       ` Stefano Stabellini [this message]
2014-01-06 14:59         ` Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 09/19] xen/pvh: Setup up shared_info Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 10/19] xen/pvh: Load GDT/GS in early PV bootup code for BSP Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 11/19] xen/pvh: Secondary VCPU bringup (non-bootup CPUs) Konrad Rzeszutek Wilk
2014-01-06 10:52   ` David Vrabel
2014-01-06 15:03     ` Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 12/19] xen/pvh: Update E820 to work with PVH (v2) Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 13/19] xen/pvh: Piggyback on PVHVM for event channels (v2) Konrad Rzeszutek Wilk
2014-01-05 18:15   ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 14/19] xen/grants: Remove gnttab_max_grant_frames dependency on gnttab_init Konrad Rzeszutek Wilk
2014-01-05 18:16   ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 15/19] xen/grant-table: Refactor gnttab_init Konrad Rzeszutek Wilk
2014-01-05 18:18   ` Stefano Stabellini
2014-01-05 19:33     ` Konrad Rzeszutek Wilk
2014-01-03 19:38 ` [PATCH v13 16/19] xen/grant: Implement an grant frame array struct (v2) Konrad Rzeszutek Wilk
2014-01-05 18:38   ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 17/19] xen/pvh: Piggyback on PVHVM for grant driver (v4) Konrad Rzeszutek Wilk
2014-01-05 18:20   ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 18/19] xen/pvh: Piggyback on PVHVM XenBus Konrad Rzeszutek Wilk
2014-01-05 17:54   ` Stefano Stabellini
2014-01-03 19:38 ` [PATCH v13 19/19] xen/pvh: Support ParaVirtualized Hardware extensions (v3) Konrad Rzeszutek Wilk
2014-01-06 10:55 ` [PATCH v13] Linux Xen PVH support (v13) David Vrabel
2014-01-06 14:53   ` Konrad Rzeszutek Wilk

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=alpine.DEB.2.02.1401061128130.8667@kaball.uk.xensource.com \
    --to=stefano.stabellini@eu.citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=hpa@zytor.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mukesh.rathor@oracle.com \
    --cc=xen-devel@lists.xenproject.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).