From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [RFC PATCH 3/16]: PVH xen: Add PHYSDEVOP_map_iomem Date: Thu, 24 Jan 2013 17:53:27 -0800 Message-ID: <20130124175327.1266b156@mantra.us.oracle.com> References: <20130111173243.2438c22a@mantra.us.oracle.com> <50F3F8CE02000078000B53E6@nat28.tlf.novell.com> <20130115153538.7b82b284@mantra.us.oracle.com> <50F684B302000078000B612B@nat28.tlf.novell.com> <20130123181223.186f5c28@mantra.us.oracle.com> <51010BA502000078000B9031@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51010BA502000078000B9031@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, 24 Jan 2013 09:23:33 +0000 "Jan Beulich" wrote: > >>> On 24.01.13 at 03:12, Mukesh Rathor > >>> wrote: > > On Wed, 16 Jan 2013 09:45:07 +0000 > > "Jan Beulich" wrote: > > > >> >>> On 16.01.13 at 00:35, Mukesh Rathor > >> >>> 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