From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [RFC PATCH 3/16]: PVH xen: Add PHYSDEVOP_map_iomem
Date: Thu, 24 Jan 2013 17:53:27 -0800 [thread overview]
Message-ID: <20130124175327.1266b156@mantra.us.oracle.com> (raw)
In-Reply-To: <51010BA502000078000B9031@nat28.tlf.novell.com>
On Thu, 24 Jan 2013 09:23:33 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:
> >>> On 24.01.13 at 03:12, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On Wed, 16 Jan 2013 09:45:07 +0000
> > "Jan Beulich" <JBeulich@suse.com> wrote:
> >
> >> >>> On 16.01.13 at 00:35, Mukesh Rathor <mukesh.rathor@oracle.com>
> >> >>> wrote:
> >> > On Mon, 14 Jan 2013 11:23:42 +0000 "Jan Beulich"
> >> that to say that a PVH guest will need to issue this for each
> >> >> and every MMIO range? Irrespective of being DomU or Dom0? I
> >> >> would have expected that this could be transparent...
> >> >
> >> > Hmm.. we discussed this at xen hackathon last year. The
> >> > guest maps the entire range in one shot. Doing it this way keeps
> >> > things flexible for future if EPT size gets to be a problem.
> >>
> >> But is this the only way to do this? I.e. is there no transparent
> >> alternative?
> >
> > Like what? If you can explain a bit more, I can try to prototype it.
> > Are you suggesting you don't want the guest be involved at all in
> > the mmio mappings? BTW, we map the entire range at present walking
> > the e820.
>
> If you map the entire range anyway, I see even less reason for
> Dom0 to do that - the hypervisor could launch Dom0 with all the
> ranges mapped then.
True. A brief background: initially I was only mapping selective
ranges by hooking into pte updates by drivers, etc.. in linux. At
that point ACPI table was giving a bit of problem (I later got that
working), so after discussing with Ian and Stefano we decided to
map the entire range initially, but later if EPT size gets to be an
issue (specially on large NUMA) boxes, we could go back to selective
mapping of ranges.
Since this happens once during boot, I am ok either way. Staying with
what I've keeps linux code clean and also provides flexibily for future
in case. But if you feel strongly, I can special case dom0 in linux
to assume xen has it all mapped, and generate a patch there. Please lmk.
thanks,
Mukesh
next prev parent reply other threads:[~2013-01-25 1:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-12 1:32 [RFC PATCH 3/16]: PVH xen: Add PHYSDEVOP_map_iomem Mukesh Rathor
2013-01-14 11:23 ` Jan Beulich
2013-01-15 23:35 ` Mukesh Rathor
2013-01-16 9:45 ` Jan Beulich
2013-01-24 2:12 ` Mukesh Rathor
2013-01-24 9:23 ` Jan Beulich
2013-01-25 1:53 ` Mukesh Rathor [this message]
2013-01-25 8:05 ` Jan Beulich
2013-01-26 2:23 ` Mukesh Rathor
2013-01-26 3:04 ` Mukesh Rathor
2013-01-28 15:13 ` Stefano Stabellini
2013-01-28 16:43 ` Konrad Rzeszutek Wilk
2013-01-28 16:47 ` Jan Beulich
2013-01-28 16:50 ` Ian Campbell
2013-01-28 10:55 ` Ian Campbell
2013-01-24 15:06 ` Tim Deegan
2013-01-25 1:03 ` Mukesh Rathor
2013-01-28 16:39 ` Konrad Rzeszutek Wilk
2013-01-28 16:47 ` Jan Beulich
2013-01-30 21:24 ` 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=20130124175327.1266b156@mantra.us.oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=JBeulich@suse.com \
--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).