linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v2] xen: support priv-mapping in an HVM tools domain
Date: Wed, 1 Nov 2017 16:37:20 +0100	[thread overview]
Message-ID: <74fdb5e0-d418-1c3c-d9ac-27d7bb08a49c@suse.com> (raw)
In-Reply-To: <30616b0c528248d3bc23bcb53311c1e2@AMSPEX02CL03.citrite.net>

On 01/11/17 14:45, Paul Durrant wrote:
>> -----Original Message-----
>> From: Juergen Gross [mailto:jgross@suse.com]
>> Sent: 01 November 2017 13:40
>> To: Paul Durrant <Paul.Durrant@citrix.com>; x86@kernel.org; xen-
>> devel@lists.xenproject.org; linux-kernel@vger.kernel.org
>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>; Thomas Gleixner
>> <tglx@linutronix.de>; Ingo Molnar <mingo@redhat.com>; H. Peter Anvin
>> <hpa@zytor.com>
>> Subject: Re: [PATCH v2] xen: support priv-mapping in an HVM tools domain
>>
>> On 01/11/17 12:31, Paul Durrant wrote:
>>> If the domain has XENFEAT_auto_translated_physmap then use of the PV-
>>> specific HYPERVISOR_mmu_update hypercall is clearly incorrect.
>>>
>>> This patch adds checks in xen_remap_domain_gfn_array() and
>>> xen_unmap_domain_gfn_array() which call through to the approprate
>>> xlate_mmu function if the feature is present.
>>>
>>> This patch also moves xen_remap_domain_gfn_range() into the PV-only
>> MMU
>>> code and #ifdefs the (only) calling code in privcmd accordingly.
>>>
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>> ---
>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Cc: Juergen Gross <jgross@suse.com>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>> ---
>>>  arch/x86/xen/mmu.c    | 36 +++++++++++++++++-------------------
>>>  arch/x86/xen/mmu_pv.c | 11 +++++++++++
>>>  drivers/xen/privcmd.c | 17 +++++++++++++----
>>>  include/xen/xen-ops.h |  7 +++++++
>>>  4 files changed, 48 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>>> index 3e15345abfe7..01837c36e293 100644
>>> --- a/arch/x86/xen/mmu.c
>>> +++ b/arch/x86/xen/mmu.c
>>> @@ -91,12 +91,12 @@ static int remap_area_mfn_pte_fn(pte_t *ptep,
>> pgtable_t token,
>>>  	return 0;
>>>  }
>>>
>>> -static int do_remap_gfn(struct vm_area_struct *vma,
>>> -			unsigned long addr,
>>> -			xen_pfn_t *gfn, int nr,
>>> -			int *err_ptr, pgprot_t prot,
>>> -			unsigned domid,
>>> -			struct page **pages)
>>> +int xen_remap_gfn(struct vm_area_struct *vma,
>>> +		  unsigned long addr,
>>> +		  xen_pfn_t *gfn, int nr,
>>> +		  int *err_ptr, pgprot_t prot,
>>> +		  unsigned int domid,
>>> +		  struct page **pages)
>>>  {
>>>  	int err = 0;
>>>  	struct remap_data rmd;
>>> @@ -166,36 +166,34 @@ static int do_remap_gfn(struct vm_area_struct
>> *vma,
>>>  	return err < 0 ? err : mapped;
>>>  }
>>>
>>> -int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
>>> -			       unsigned long addr,
>>> -			       xen_pfn_t gfn, int nr,
>>> -			       pgprot_t prot, unsigned domid,
>>> -			       struct page **pages)
>>> -{
>>> -	return do_remap_gfn(vma, addr, &gfn, nr, NULL, prot, domid,
>> pages);
>>> -}
>>> -EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
>>> -
>>>  int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
>>>  			       unsigned long addr,
>>>  			       xen_pfn_t *gfn, int nr,
>>>  			       int *err_ptr, pgprot_t prot,
>>>  			       unsigned domid, struct page **pages)
>>>  {
>>> +	if (xen_feature(XENFEAT_auto_translated_physmap))
>>> +		return xen_xlate_remap_gfn_array(vma, addr, gfn, nr,
>> err_ptr,
>>> +						 prot, domid, pages);
>>> +
>>>  	/* We BUG_ON because it's a programmer error to pass a NULL
>> err_ptr,
>>>  	 * and the consequences later is quite hard to detect what the actual
>>>  	 * cause of "wrong memory was mapped in".
>>>  	 */
>>>  	BUG_ON(err_ptr == NULL);
>>> -	return do_remap_gfn(vma, addr, gfn, nr, err_ptr, prot, domid,
>> pages);
>>> +	return xen_remap_gfn(vma, addr, gfn, nr, err_ptr, prot, domid,
>>> +			     pages);
>>>  }
>>>  EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_array);
>>>
>>>  /* Returns: 0 success */
>>>  int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
>>> -			       int numpgs, struct page **pages)
>>> +			       int nr, struct page **pages)
>>>  {
>>> -	if (!pages || !xen_feature(XENFEAT_auto_translated_physmap))
>>> +	if (xen_feature(XENFEAT_auto_translated_physmap))
>>> +		return xen_xlate_unmap_gfn_range(vma, nr, pages);
>>> +
>>> +	if (!pages)
>>>  		return 0;
>>>
>>>  	return -EINVAL;
>>> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
>>> index 71495f1a86d7..4974d8a6c2b4 100644
>>> --- a/arch/x86/xen/mmu_pv.c
>>> +++ b/arch/x86/xen/mmu_pv.c
>>> @@ -2670,3 +2670,14 @@ phys_addr_t paddr_vmcoreinfo_note(void)
>>>  		return __pa(vmcoreinfo_note);
>>>  }
>>>  #endif /* CONFIG_KEXEC_CORE */
>>> +
>>> +int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
>>> +			       unsigned long addr,
>>> +			       xen_pfn_t gfn, int nr,
>>> +			       pgprot_t prot, unsigned int domid,
>>> +			       struct page **pages)
>>> +{
>>> +	return xen_remap_gfn(vma, addr, &gfn, nr, NULL, prot, domid,
>>> +			     pages);
>>> +}
>>> +EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>> index feca75b07fdd..b58a1719b606 100644
>>> --- a/drivers/xen/privcmd.c
>>> +++ b/drivers/xen/privcmd.c
>>> @@ -215,6 +215,8 @@ static int traverse_pages_block(unsigned nelem,
>> size_t size,
>>>  	return ret;
>>>  }
>>>
>>> +#ifdef CONFIG_XEN_PV
>>> +
>>>  struct mmap_gfn_state {
>>>  	unsigned long va;
>>>  	struct vm_area_struct *vma;
>>> @@ -261,10 +263,6 @@ static long privcmd_ioctl_mmap(struct file *file,
>> void __user *udata)
>>>  	LIST_HEAD(pagelist);
>>>  	struct mmap_gfn_state state;
>>>
>>> -	/* We only support privcmd_ioctl_mmap_batch for auto translated.
>> */
>>> -	if (xen_feature(XENFEAT_auto_translated_physmap))
>>> -		return -ENOSYS;
>>> -
>>
>> CONFIG_XEN_PV doesn't mean we don't support running as HVM guest.
>>
>> I don't think you can remove this test, nor do I think it makes sense
>> to put privcmd_ioctl_mmap() inside an #ifdef.
> 
> Ok, I can leave the test in, but I only put the function inside the ifdef at Boris's request (unless I misinterpreted what he meant).
> 
>>
>> You should rather add something like privcmd_ioctl_mmap_pv() with all
>> the PV-specific functionality and call this here. For !CONFIG_XEN_PV
>> it can e.g. just BUG().
>>
> 
> Personally, I prefer my original patch where all the changes were kept inside mmu.c. It was much neater.

Hmm, this was sent (and commented) during my vacation, so I didn't look
at it very thoroughly with Boris having done so.

TBH I like V1 better, too.

Boris, do you feel strong about the #ifdef part?


Juergen

  reply	other threads:[~2017-11-01 15:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 11:31 [PATCH v2] xen: support priv-mapping in an HVM tools domain Paul Durrant
2017-11-01 13:39 ` Juergen Gross
2017-11-01 13:45   ` Paul Durrant
2017-11-01 15:37     ` Juergen Gross [this message]
2017-11-01 18:18       ` Boris Ostrovsky
2017-11-02  9:30         ` Paul Durrant
2017-11-02 20:59           ` Boris Ostrovsky

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=74fdb5e0-d418-1c3c-d9ac-27d7bb08a49c@suse.com \
    --to=jgross@suse.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --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).