From: David Vrabel <david.vrabel@citrix.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
"Mukesh Rathor" <mukesh.rathor@oracle.com>,
boris.ostrovsky@oracle.com
Cc: <xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [V1 PATCH] dom0 pvh: map foreign pfns in our p2m for toolstack
Date: Tue, 27 May 2014 11:59:26 +0100 [thread overview]
Message-ID: <5384700E.1030501@citrix.com> (raw)
In-Reply-To: <53846C4C.1080701@citrix.com>
On 27/05/14 11:43, Roger Pau Monné wrote:
> On 24/05/14 03:33, Mukesh Rathor wrote:
>> When running as dom0 in pvh mode, foreign pfns that are accessed must be
>> added to our p2m which is managed by xen. This is done via
>> XENMEM_add_to_physmap_range hypercall. This is needed for toolstack
>> building guests and mapping guest memory, xentrace mapping xen pages,
>> etc..
Thanks.
Applied to devel/for-linus-3.16, but see comments below.
>> +static int xlate_add_to_p2m(unsigned long lpfn, unsigned long fgmfn,
>> + unsigned int domid)
The preferred abbreviation is GFN not GMFN. I fixed this up.
>> +{
>> + int rc, err = 0;
>> + xen_pfn_t gpfn = lpfn;
>> + xen_ulong_t idx = fgmfn;
>> +
>> + struct xen_add_to_physmap_range xatp = {
>> + .domid = DOMID_SELF,
>> + .foreign_domid = domid,
>> + .size = 1,
>> + .space = XENMAPSPACE_gmfn_foreign,
>> + };
>> + set_xen_guest_handle(xatp.idxs, &idx);
>> + set_xen_guest_handle(xatp.gpfns, &gpfn);
>> + set_xen_guest_handle(xatp.errs, &err);
>> +
>> + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
>> + return rc;
>
> Thanks for the patches, I see two problems with this approach, the first
> one is that you are completely ignoring the error in the variable "err",
> which means that you can end up with a pfn that Linux thinks it's valid,
> but it's not mapped to any mfn, so when you try to access it you will
> trigger the vioapic crash.
I spotted this and fixed this up by adding:
+ if (rc < 0)
+ return rc;
+ return err;
> The second one is that this seems extremely inefficient, you are issuing
> one hypercall for each memory page, when you could instead batch all the
> pages into a single hypercall and map them in one shot.
I agree, but the 3.16 merge window is nearly here so I've applied it
as-is. Note that the privcmd driver calls this function once per page,
so the lack of batching doesn't really hurt here.
David
next prev parent reply other threads:[~2014-05-27 10:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-24 2:33 [V1 PATCH] dom0 pvh linux support Mukesh Rathor
2014-05-24 2:33 ` [V1 PATCH] dom0 pvh: map foreign pfns in our p2m for toolstack Mukesh Rathor
2014-05-27 10:43 ` [Xen-devel] " Roger Pau Monné
2014-05-27 10:59 ` David Vrabel [this message]
2014-05-27 18:46 ` Mukesh Rathor
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=5384700E.1030501@citrix.com \
--to=david.vrabel@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mukesh.rathor@oracle.com \
--cc=roger.pau@citrix.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
Powered by JetHome