All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, tim@xen.org, keir@xen.org
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	wei.liu2@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: Limitation in HVM physmap
Date: Fri, 1 Nov 2013 12:21:42 +0000	[thread overview]
Message-ID: <20131101122142.GD4966@zion.uk.xensource.com> (raw)
In-Reply-To: <20131018142012.GB20185@zion.uk.xensource.com>

On Fri, Oct 18, 2013 at 03:20:12PM +0100, 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?
> 

FWIW I tested this on real hardware, a Dell R710 server.

dmesg:
[   39.394807] efifb: probing for efifb
[   39.437552] efifb: framebuffer at 0xd5800000, mapped to 0xffffc90013f00000, using 1216k, total 1216k
[   39.546549] efifb: mode is 640x480x32, linelength=2560, pages=1
[   39.617140] efifb: scrolling: redraw
[   39.659709] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

lspci -vvv:
0b:03.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 (rev 0a) (prog-if 00 [VGA controller])
        Subsystem: Dell PowerEdge R710 MGA G200eW WPCM450
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (4000ns min, 8000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at d5800000 (32-bit, prefetchable) [size=8M]
        Region 1: Memory at de7fc000 (32-bit, non-prefetchable) [size=16K]
        Region 2: Memory at de800000 (32-bit, non-prefetchable) [size=8M]
        [virtual] Expansion ROM at de000000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

So I think the behavior of OVMF is consistent with real hardware.

Wei.

> Thanks
> Wei

  parent reply	other threads:[~2013-11-01 12:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-18 14:20 Limitation in HVM physmap Wei Liu
2013-10-18 14:26 ` George Dunlap
2013-10-18 15:12   ` Paul Durrant
2013-10-18 14:28 ` Tim Deegan
2013-10-18 14:36   ` Wei Liu
2013-10-18 14:41     ` Tim Deegan
2013-10-18 14:56       ` Wei Liu
2013-10-18 14:59         ` Ian Campbell
2013-10-18 15:00           ` Ian Campbell
2013-10-18 15:04           ` Wei Liu
2013-10-18 15:06             ` George Dunlap
2013-10-18 15:07             ` Wei Liu
2013-10-18 15:09               ` Ian Campbell
2013-10-18 15:14           ` Stefano Stabellini
2013-10-18 14:47     ` Jan Beulich
2013-10-18 15:01       ` Wei Liu
2013-10-18 15:07         ` Ian Campbell
2013-10-18 15:30           ` Wei Liu
2013-10-18 15:09         ` Jan Beulich
2013-11-01 12:21 ` Wei Liu [this message]
2013-11-01 12:26   ` George Dunlap
2013-11-01 12:33   ` Ian Campbell
2013-11-01 12:45     ` Wei Liu
2013-11-01 12:49       ` Ian Campbell
2013-11-01 14:08         ` Wei Liu
2013-11-01 14:12           ` Ian Campbell
2013-11-01 14:19             ` Wei Liu
2013-11-01 14:31               ` Ian Campbell
2013-11-01 14:55                 ` Wei Liu
2013-11-01 15:04                   ` Ian Campbell
2013-11-04  9:28                     ` Fabio Fantoni
2013-11-04 11:42                       ` Wei Liu
2013-11-04 12:05                         ` Fabio Fantoni
2013-11-04 12:17                           ` Wei Liu
2013-11-04 14:08                             ` Fabio Fantoni
2013-11-04 14:14                               ` Wei Liu

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=20131101122142.GD4966@zion.uk.xensource.com \
    --to=wei.liu2@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.