From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Limitation in HVM physmap Date: Fri, 18 Oct 2013 15:26:01 +0100 Message-ID: <526144F9.5010108@eu.citrix.com> References: <20131018142012.GB20185@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131018142012.GB20185@zion.uk.xensource.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: Wei Liu , Jan Beulich , tim@xen.org, keir@xen.org Cc: Stefano Stabellini , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 18/10/13 15:20, Wei Liu wrote: > Hi Jan, Tim and Keir > > I currently run into the limitation of HVM's physmap: one MFN can only > be mapped into one guest physical frame. Why is it designed like that? > > The scenario is that: when QEMU boots with OVMF (UEFI firmware), OVMF > will first map the framebuffer to 0x80000000, resulting the framebuffer > MFNs added to corresponding slots in physmap. A few moments later when > Linux kernel loads, it tries to map framebuffer MFNs to 0xf00000000, > which fails because those MFNs have already been mapped in other > locations. Is there a way to fix this? If I understood our f2f conversation correctly, not only this, but after Linux has remapped it to 0xf, it makes calls into EFI which then access it again at 0x8. So there is a period of time when it is accessed from both places. (Correct me if I misunderstood something...) -George