thr3ads.net - Xen devel - Limitation in HVM physmap [Oct 2013]

If this information is useful, please help other people find it:
Share via:

Wei Liu

2013-Oct-18 14:20 UTC

Limitation in HVM physmap

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?

Thanks
Wei

George Dunlap

2013-Oct-18 14:26 UTC

head link

Re: Limitation in HVM physmap

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

Tim Deegan

2013-Oct-18 14:28 UTC

head link

Re: Limitation in HVM physmap

Hi,

At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:> 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?
1. For simplicity.  That code is hard wnough to work with already. :)

2. It helps avoid worrying about inconsistent cache settings if the
   HAP tables only have one entry for each MFN. 

3. Xen maintains a single mapping from MFN back to PFN, and any code
   that uses it would have to be able to deal with getting multiple
   answers.  That''s already been partly changed by the mem_sharing
   code (which obviously _can_ have multiple P2M entries pointing to
   the same MFN but is a bit complex as a result).
> 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?
Qemu could remember where it put the framebuffer last time and unmap
it.  AIUI that''s how real hardware would behave if you changed the
framebuffer base address -- the framebuffer wouldn''t still be mapped at
the old location as well.

Cheers,

Tim.

Wei Liu

2013-Oct-18 14:36 UTC

head link

Re: Limitation in HVM physmap

On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan
wrote:> Hi,
> 
> At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> > 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?
> 
> 1. For simplicity.  That code is hard wnough to work with already. :)
> 
> 2. It helps avoid worrying about inconsistent cache settings if the
>    HAP tables only have one entry for each MFN. 
> 
> 3. Xen maintains a single mapping from MFN back to PFN, and any code
>    that uses it would have to be able to deal with getting multiple
>    answers.  That''s already been partly changed by the mem_sharing
>    code (which obviously _can_ have multiple P2M entries pointing to
>    the same MFN but is a bit complex as a result).
> 
I see.
> > 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?
> 
> Qemu could remember where it put the framebuffer last time and unmap
> it.  AIUI that''s how real hardware would behave if you changed the
> framebuffer base address -- the framebuffer wouldn''t still be
mapped at
> the old location as well.
> 
In fact, this is not the case in OVMF. EFIFB driver in Linux will always
use the EFIFB region (0x80000000) provided by OVMF. 

Unmapping the first region (0x80000000) 1) makes the guest not able to
refresh its framebuffer, 2) causes lots of traps in QEMU (because guest
is still accessing first region) which makes QEMU busy-looping all the
time.

I do have a workaround in QEMU but it''s very fragile and ugly...

Wei.
> Cheers,
> 
> Tim.

Tim Deegan

2013-Oct-18 14:41 UTC

head link

Re: Limitation in HVM physmap

At 15:36 +0100 on 18 Oct (1382107000), Wei Liu wrote:> On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
> > Hi,
> > 
> > At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> > > 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?
> > 
> > 1. For simplicity.  That code is hard wnough to work with already. :)
> > 
> > 2. It helps avoid worrying about inconsistent cache settings if the
> >    HAP tables only have one entry for each MFN. 
> > 
> > 3. Xen maintains a single mapping from MFN back to PFN, and any code
> >    that uses it would have to be able to deal with getting multiple
> >    answers.  That''s already been partly changed by the
mem_sharing
> >    code (which obviously _can_ have multiple P2M entries pointing to
> >    the same MFN but is a bit complex as a result).
> > 
> 
> I see.
> 
> > > 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?
> > 
> > Qemu could remember where it put the framebuffer last time and unmap
> > it.  AIUI that''s how real hardware would behave if you
changed the
> > framebuffer base address -- the framebuffer wouldn''t still be
mapped at
> > the old location as well.
> > 
> 
> In fact, this is not the case in OVMF. EFIFB driver in Linux will always
> use the EFIFB region (0x80000000) provided by OVMF. 
So what''s mapping it at 0xf00000000?  Is linux running two drivers
against the same graphics card at the same time?  That sounds like
trouble!

And how would this work with a real graphics card?  Isn''t there only
one BAR that controls where the framebuffer presents itself?

Tim.

Jan Beulich

2013-Oct-18 14:47 UTC

head link

Re: Limitation in HVM physmap

>>> On 18.10.13 at 16:36, Wei Liu <wei.liu2@citrix.com> wrote:
> On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
>> At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
>> > 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?
Since when does the Linux kernel have control over the physical
address where the frame buffer sits (other than by writing PCI
devices'' BARs, which implies the address range to change rather
than a second instance to be created)?
>> Qemu could remember where it put the framebuffer last time and unmap
>> it.  AIUI that''s how real hardware would behave if you changed
the
>> framebuffer base address -- the framebuffer wouldn''t still be
mapped at
>> the old location as well.
>> 
> 
> In fact, this is not the case in OVMF. EFIFB driver in Linux will always
> use the EFIFB region (0x80000000) provided by OVMF. 
> 
> Unmapping the first region (0x80000000) 1) makes the guest not able to
> refresh its framebuffer, 2) causes lots of traps in QEMU (because guest
> is still accessing first region) which makes QEMU busy-looping all the
> time.
How does that behavior map to real hardware behavior?

Jan

Wei Liu

2013-Oct-18 14:56 UTC

head link

Re: Limitation in HVM physmap

On Fri, Oct 18, 2013 at 04:41:49PM +0200, Tim Deegan
wrote:> At 15:36 +0100 on 18 Oct (1382107000), Wei Liu wrote:
> > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
> > > Hi,
> > > 
> > > At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> > > > 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?
> > > 
> > > 1. For simplicity.  That code is hard wnough to work with
already. :)
> > > 
> > > 2. It helps avoid worrying about inconsistent cache settings if
the
> > >    HAP tables only have one entry for each MFN. 
> > > 
> > > 3. Xen maintains a single mapping from MFN back to PFN, and any
code
> > >    that uses it would have to be able to deal with getting
multiple
> > >    answers.  That''s already been partly changed by the
mem_sharing
> > >    code (which obviously _can_ have multiple P2M entries pointing
to
> > >    the same MFN but is a bit complex as a result).
> > > 
> > 
> > I see.
> > 
> > > > 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?
> > > 
> > > Qemu could remember where it put the framebuffer last time and
unmap
> > > it.  AIUI that''s how real hardware would behave if you
changed the
> > > framebuffer base address -- the framebuffer wouldn''t
still be mapped at
> > > the old location as well.
> > > 
> > 
> > In fact, this is not the case in OVMF. EFIFB driver in Linux will
always
> > use the EFIFB region (0x80000000) provided by OVMF. 
> 
> So what''s mapping it at 0xf00000000?  Is linux running two drivers
> against the same graphics card at the same time?  That sounds like
> trouble!
> 
During OVMF initialization:

(d28) PciBus: Resource Map for Root Bridge PciRoot(0x0)                         
(d28) Type =   Io16; Base = 0xC000;     Length = 0x1000;        Alignment =
0xFFF
(d28)  Base = 0xC000;   Length = 0x100; Alignment = 0xFF;       Owner = PCI 
[00|04|
(d28)  Base = 0xC100;   Length = 0x100; Alignment = 0xFF;       Owner = PCI 
[00|03|
(d28)  Base = 0xC200;   Length = 0x10;  Alignment = 0xF;        Owner = PCI 
[00|01|
(d28) Type =  Mem32; Base = 0x80000000; Length = 0x3100000;     Alignment =
0x1FFFFF
(d28)  Base = 0x80000000;       Length = 0x2000000;     Alignment = 0x1FFFFFF; 
Owne
(d28) |02|00:10] 

Later when Linux loads EFIFB driver:
[    2.628264] efifb: framebuffer at 0x80000000, mapped to
0xffffc90000100000, using 1876k, total 1875k
[    2.646827] efifb: mode is 800x600x32, linelength=3200, pages=1
[    2.658833] efifb: scrolling: redraw
[    2.666342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

0xf0000000 is mapped by:

00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA
controller])
	Subsystem: Red Hat, Inc Device 1100
	Physical Slot: 2
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
	Region 1: Memory at f3010000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at f3000000 [disabled] [size=64K]
> And how would this work with a real graphics card?  Isn''t there
only
> one BAR that controls where the framebuffer presents itself?
> 
No idea. Maybe I''m missing something? TBH I''ve never had any
EFI-capable
hardware. 

Wei.
> Tim.

Ian Campbell

2013-Oct-18 14:59 UTC

head link

Re: Limitation in HVM physmap

On Fri, 2013-10-18 at 15:56 +0100, Wei Liu wrote:> On Fri, Oct 18, 2013 at 04:41:49PM +0200, Tim Deegan wrote:
> > At 15:36 +0100 on 18 Oct (1382107000), Wei Liu wrote:
> > > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
> > > > Hi,
> > > > 
> > > > At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> > > > > 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?
> > > > 
> > > > 1. For simplicity.  That code is hard wnough to work with
already. :)
> > > > 
> > > > 2. It helps avoid worrying about inconsistent cache settings
if the
> > > >    HAP tables only have one entry for each MFN. 
> > > > 
> > > > 3. Xen maintains a single mapping from MFN back to PFN, and
any code
> > > >    that uses it would have to be able to deal with getting
multiple
> > > >    answers.  That''s already been partly changed by
the mem_sharing
> > > >    code (which obviously _can_ have multiple P2M entries
pointing to
> > > >    the same MFN but is a bit complex as a result).
> > > > 
> > > 
> > > I see.
> > > 
> > > > > 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?
> > > > 
> > > > Qemu could remember where it put the framebuffer last time
and unmap
> > > > it.  AIUI that''s how real hardware would behave if
you changed the
> > > > framebuffer base address -- the framebuffer
wouldn''t still be mapped at
> > > > the old location as well.
> > > > 
> > > 
> > > In fact, this is not the case in OVMF. EFIFB driver in Linux will
always
> > > use the EFIFB region (0x80000000) provided by OVMF. 
> > 
> > So what''s mapping it at 0xf00000000?  Is linux running two
drivers
> > against the same graphics card at the same time?  That sounds like
> > trouble!
> > 
> 
> During OVMF initialization:
> 
> (d28) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> (d28) Type =   Io16; Base = 0xC000;     Length = 0x1000;        Alignment =
0xFFF
> (d28)  Base = 0xC000;   Length = 0x100; Alignment = 0xFF;       Owner = PCI
[00|04|
> (d28)  Base = 0xC100;   Length = 0x100; Alignment = 0xFF;       Owner = PCI
[00|03|
> (d28)  Base = 0xC200;   Length = 0x10;  Alignment = 0xF;        Owner = PCI
[00|01|
> (d28) Type =  Mem32; Base = 0x80000000; Length = 0x3100000;     Alignment =
0x1FFFFF
> (d28)  Base = 0x80000000;       Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owne
> (d28) |02|00:10] 
> 
> Later when Linux loads EFIFB driver:
> [    2.628264] efifb: framebuffer at 0x80000000, mapped to
> 0xffffc90000100000, using 1876k, total 1875k
> [    2.646827] efifb: mode is 800x600x32, linelength=3200, pages=1
> [    2.658833] efifb: scrolling: redraw
> [    2.666342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> 0xf0000000 is mapped by:
What hardware is backing the framebuffer at 0x80000000? It doesn''t
appear to be this cirrus device.

Does this VM have two graphics cards and therefore two drivers (efifb
and cirrusfb/vesafb/etc)?

If there are two gfx cards then there should be two framebuffers and
therefore no mfn sharing in the p2m, although you would probably be
better off arranging for their to only one gfx card...
> 
> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA
controller])
> 	Subsystem: Red Hat, Inc Device 1100
> 	Physical Slot: 2
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
> 	Region 1: Memory at f3010000 (32-bit, non-prefetchable) [size=4K]
> 	Expansion ROM at f3000000 [disabled] [size=64K]
> 
> > And how would this work with a real graphics card?  Isn''t
there only
> > one BAR that controls where the framebuffer presents itself?
> > 
> 
> No idea. Maybe I''m missing something? TBH I''ve never had
any EFI-capable
> hardware. 
> 
> Wei.
> 
> > Tim.

Ian Campbell

2013-Oct-18 15:00 UTC

head link

Re: Limitation in HVM physmap

On Fri, 2013-10-18 at 15:59 +0100, Ian Campbell wrote:> On Fri, 2013-10-18 at 15:56 +0100, Wei Liu wrote:
> > On Fri, Oct 18, 2013 at 04:41:49PM +0200, Tim Deegan wrote:
> > > At 15:36 +0100 on 18 Oct (1382107000), Wei Liu wrote:
> > > > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
> > > > > Hi,
> > > > > 
> > > > > At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> > > > > > 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?
> > > > > 
> > > > > 1. For simplicity.  That code is hard wnough to work
with already. :)
> > > > > 
> > > > > 2. It helps avoid worrying about inconsistent cache
settings if the
> > > > >    HAP tables only have one entry for each MFN. 
> > > > > 
> > > > > 3. Xen maintains a single mapping from MFN back to PFN,
and any code
> > > > >    that uses it would have to be able to deal with
getting multiple
> > > > >    answers.  That''s already been partly
changed by the mem_sharing
> > > > >    code (which obviously _can_ have multiple P2M
entries pointing to
> > > > >    the same MFN but is a bit complex as a result).
> > > > > 
> > > > 
> > > > I see.
> > > > 
> > > > > > 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?
> > > > > 
> > > > > Qemu could remember where it put the framebuffer last
time and unmap
> > > > > it.  AIUI that''s how real hardware would
behave if you changed the
> > > > > framebuffer base address -- the framebuffer
wouldn''t still be mapped at
> > > > > the old location as well.
> > > > > 
> > > > 
> > > > In fact, this is not the case in OVMF. EFIFB driver in Linux
will always
> > > > use the EFIFB region (0x80000000) provided by OVMF. 
> > > 
> > > So what''s mapping it at 0xf00000000?  Is linux running
two drivers
> > > against the same graphics card at the same time?  That sounds
like
> > > trouble!
> > > 
> > 
> > During OVMF initialization:
> > 
> > (d28) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> > (d28) Type =   Io16; Base = 0xC000;     Length = 0x1000;       
Alignment = 0xFFF
> > (d28)  Base = 0xC000;   Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|04|
> > (d28)  Base = 0xC100;   Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|03|
> > (d28)  Base = 0xC200;   Length = 0x10;  Alignment = 0xF;        Owner
= PCI  [00|01|
> > (d28) Type =  Mem32; Base = 0x80000000; Length = 0x3100000;    
Alignment = 0x1FFFFF
> > (d28)  Base = 0x80000000;       Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owne
> > (d28) |02|00:10] 
> > 
> > Later when Linux loads EFIFB driver:
> > [    2.628264] efifb: framebuffer at 0x80000000, mapped to
> > 0xffffc90000100000, using 1876k, total 1875k
> > [    2.646827] efifb: mode is 800x600x32, linelength=3200, pages=1
> > [    2.658833] efifb: scrolling: redraw
> > [    2.666342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> > 
> > 0xf0000000 is mapped by:
> 
> What hardware is backing the framebuffer at 0x80000000? It doesn''t
> appear to be this cirrus device.
> 
> Does this VM have two graphics cards and therefore two drivers (efifb
> and cirrusfb/vesafb/etc)?
> 
> If there are two gfx cards then there should be two framebuffers and
> therefore no mfn sharing in the p2m, although you would probably be
> better off arranging for their to only one gfx card...
I suppose the other option is that 0x800000000 is just normal RAM and
the EFI BIOS is double buffering and syncing it to the actual VRAM at
0xf0000000... That would seem odd though...

Wei Liu

2013-Oct-18 15:01 UTC

head link

Re: Limitation in HVM physmap

On Fri, Oct 18, 2013 at 03:47:25PM +0100, Jan Beulich
wrote:> >>> On 18.10.13 at 16:36, Wei Liu <wei.liu2@citrix.com>
wrote:
> > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
> >> At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> >> > 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?
> 
> Since when does the Linux kernel have control over the physical
> address where the frame buffer sits (other than by writing PCI
> devices'' BARs, which implies the address range to change rather
> than a second instance to be created)?
> 
I don''t think Linux changes things -- 0xf0000000 is what it gets from
Xen and it honors that. It''s OVMF that plays with things. There is a
procedure in OVMF that remaps PCI resources.
> >> Qemu could remember where it put the framebuffer last time and
unmap
> >> it.  AIUI that''s how real hardware would behave if you
changed the
> >> framebuffer base address -- the framebuffer wouldn''t
still be mapped at
> >> the old location as well.
> >> 
> > 
> > In fact, this is not the case in OVMF. EFIFB driver in Linux will
always
> > use the EFIFB region (0x80000000) provided by OVMF. 
> > 
> > Unmapping the first region (0x80000000) 1) makes the guest not able to
> > refresh its framebuffer, 2) causes lots of traps in QEMU (because
guest
> > is still accessing first region) which makes QEMU busy-looping all the
> > time.
> 
> How does that behavior map to real hardware behavior?
> 
> Jan

Wei Liu

2013-Oct-18 15:04 UTC

head link

Re: Limitation in HVM physmap

On Fri, Oct 18, 2013 at 03:59:10PM +0100, Ian Campbell wrote:
[...]> > > 
> > 
> > During OVMF initialization:
> > 
> > (d28) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> > (d28) Type =   Io16; Base = 0xC000;     Length = 0x1000;       
Alignment = 0xFFF
> > (d28)  Base = 0xC000;   Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|04|
> > (d28)  Base = 0xC100;   Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|03|
> > (d28)  Base = 0xC200;   Length = 0x10;  Alignment = 0xF;        Owner
= PCI  [00|01|
> > (d28) Type =  Mem32; Base = 0x80000000; Length = 0x3100000;    
Alignment = 0x1FFFFF
> > (d28)  Base = 0x80000000;       Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owne
> > (d28) |02|00:10] 
> > 
> > Later when Linux loads EFIFB driver:
> > [    2.628264] efifb: framebuffer at 0x80000000, mapped to
> > 0xffffc90000100000, using 1876k, total 1875k
> > [    2.646827] efifb: mode is 800x600x32, linelength=3200, pages=1
> > [    2.658833] efifb: scrolling: redraw
> > [    2.666342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> > 
> > 0xf0000000 is mapped by:
> 
> What hardware is backing the framebuffer at 0x80000000? It doesn''t
> appear to be this cirrus device.
> 
Looking that the "Resource Map for Root Bridge" 0x8000000 is backed by
00:02:00 (trancated above) and 00:02.0 is also owned by Cirrus Logic
driver...
> Does this VM have two graphics cards and therefore two drivers (efifb
> and cirrusfb/vesafb/etc)?
> 
> If there are two gfx cards then there should be two framebuffers and
> therefore no mfn sharing in the p2m, although you would probably be
> better off arranging for their to only one gfx card...
> 
AIUI there is only one card.

Wei.
> > 
> > 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00
[VGA controller])
> > 	Subsystem: Red Hat, Inc Device 1100
> > 	Physical Slot: 2
> > 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
> > 	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
> > 	Latency: 0
> > 	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
> > 	Region 1: Memory at f3010000 (32-bit, non-prefetchable) [size=4K]
> > 	Expansion ROM at f3000000 [disabled] [size=64K]
> > 
> > > And how would this work with a real graphics card? 
Isn''t there only
> > > one BAR that controls where the framebuffer presents itself?
> > > 
> > 
> > No idea. Maybe I''m missing something? TBH I''ve never
had any EFI-capable
> > hardware. 
> > 
> > Wei.
> > 
> > > Tim.
>

George Dunlap

2013-Oct-18 15:06 UTC

head link

Re: Limitation in HVM physmap

On 18/10/13 16:04, Wei Liu wrote:> On Fri, Oct 18, 2013 at 03:59:10PM +0100, Ian Campbell wrote:
> [...]
>>> During OVMF initialization:
>>>
>>> (d28) PciBus: Resource Map for Root Bridge PciRoot(0x0)
>>> (d28) Type =   Io16; Base = 0xC000;     Length = 0x1000;       
Alignment = 0xFFF
>>> (d28)  Base = 0xC000;   Length = 0x100; Alignment = 0xFF;      
Owner = PCI  [00|04|
>>> (d28)  Base = 0xC100;   Length = 0x100; Alignment = 0xFF;      
Owner = PCI  [00|03|
>>> (d28)  Base = 0xC200;   Length = 0x10;  Alignment = 0xF;       
Owner = PCI  [00|01|
>>> (d28) Type =  Mem32; Base = 0x80000000; Length = 0x3100000;    
Alignment = 0x1FFFFF
>>> (d28)  Base = 0x80000000;       Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owne
>>> (d28) |02|00:10]
>>>
>>> Later when Linux loads EFIFB driver:
>>> [    2.628264] efifb: framebuffer at 0x80000000, mapped to
>>> 0xffffc90000100000, using 1876k, total 1875k
>>> [    2.646827] efifb: mode is 800x600x32, linelength=3200, pages=1
>>> [    2.658833] efifb: scrolling: redraw
>>> [    2.666342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
>>>
>>> 0xf0000000 is mapped by:
>> What hardware is backing the framebuffer at 0x80000000? It
doesn''t
>> appear to be this cirrus device.
>>
> Looking that the "Resource Map for Root Bridge" 0x8000000 is
backed by
> 00:02:00 (trancated above) and 00:02.0 is also owned by Cirrus Logic
> driver...
xentrace -e all should give you a record of all calls to 
set_p2m_entry(), as well as any MMIO / PIO, so you should be able to 
verify the remapping / double mapping happening from the other direction.

  -George

Wei Liu

2013-Oct-18 15:07 UTC

head link

Re: Limitation in HVM physmap

On Fri, Oct 18, 2013 at 04:04:17PM +0100, Wei Liu wrote:> On Fri, Oct 18, 2013 at 03:59:10PM +0100, Ian Campbell wrote:
> [...]
> > > > 
> > > 
> > > During OVMF initialization:
> > > 
> > > (d28) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> > > (d28) Type =   Io16; Base = 0xC000;     Length = 0x1000;       
Alignment = 0xFFF
> > > (d28)  Base = 0xC000;   Length = 0x100; Alignment = 0xFF;      
Owner = PCI  [00|04|
> > > (d28)  Base = 0xC100;   Length = 0x100; Alignment = 0xFF;      
Owner = PCI  [00|03|
> > > (d28)  Base = 0xC200;   Length = 0x10;  Alignment = 0xF;       
Owner = PCI  [00|01|
> > > (d28) Type =  Mem32; Base = 0x80000000; Length = 0x3100000;    
Alignment = 0x1FFFFF
> > > (d28)  Base = 0x80000000;       Length = 0x2000000;     Alignment
= 0x1FFFFFF;  Owne
> > > (d28) |02|00:10] 
> > > 
> > > Later when Linux loads EFIFB driver:
> > > [    2.628264] efifb: framebuffer at 0x80000000, mapped to
> > > 0xffffc90000100000, using 1876k, total 1875k
> > > [    2.646827] efifb: mode is 800x600x32, linelength=3200,
pages=1
> > > [    2.658833] efifb: scrolling: redraw
> > > [    2.666342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> > > 
> > > 0xf0000000 is mapped by:
> > 
> > What hardware is backing the framebuffer at 0x80000000? It
doesn''t
> > appear to be this cirrus device.
> > 
> 
> Looking that the "Resource Map for Root Bridge" 0x8000000 is
backed by
> 00:02:00 (trancated above) and 00:02.0 is also owned by Cirrus Logic
> driver...
> 
> > Does this VM have two graphics cards and therefore two drivers (efifb
> > and cirrusfb/vesafb/etc)?
> > 
> > If there are two gfx cards then there should be two framebuffers and
> > therefore no mfn sharing in the p2m, although you would probably be
> > better off arranging for their to only one gfx card...
> > 
> 
> AIUI there is only one card.
> 
FWIW there''s a QEMU Cirrus Logic card driver in OVMF which drives the
emulated card.

wei.

Ian Campbell

2013-Oct-18 15:07 UTC

head link

Re: Limitation in HVM physmap

On Fri, 2013-10-18 at 16:01 +0100, Wei Liu wrote:> On Fri, Oct 18, 2013 at 03:47:25PM +0100, Jan Beulich wrote:
> > >>> On 18.10.13 at 16:36, Wei Liu <wei.liu2@citrix.com>
wrote:
> > > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
> > >> At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> > >> > 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?
> > 
> > Since when does the Linux kernel have control over the physical
> > address where the frame buffer sits (other than by writing PCI
> > devices'' BARs, which implies the address range to change
rather
> > than a second instance to be created)?
> > 
> 
> I don''t think Linux changes things -- 0xf0000000 is what it gets
from
> Xen and it honors that. It''s OVMF that plays with things. There is
a
> procedure in OVMF that remaps PCI resources.
Does all of this get logged to the xen debug console? Can you post a
full log perhaps to clarify things for us?

Jan Beulich

2013-Oct-18 15:09 UTC

head link

Re: Limitation in HVM physmap

>>> On 18.10.13 at 17:01, Wei Liu <wei.liu2@citrix.com> wrote:
> On Fri, Oct 18, 2013 at 03:47:25PM +0100, Jan Beulich wrote:
>> >>> On 18.10.13 at 16:36, Wei Liu <wei.liu2@citrix.com>
wrote:
>> > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
>> >> At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
>> >> > 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?
>> 
>> Since when does the Linux kernel have control over the physical
>> address where the frame buffer sits (other than by writing PCI
>> devices'' BARs, which implies the address range to change
rather
>> than a second instance to be created)?
>> 
> 
> I don''t think Linux changes things -- 0xf0000000 is what it gets
from
> Xen and it honors that. It''s OVMF that plays with things. There is
a
> procedure in OVMF that remaps PCI resources.
Then I''d suppose there is where you would be looking for how
to fix it.

Jan

Ian Campbell

2013-Oct-18 15:09 UTC

head link

Re: Limitation in HVM physmap

On Fri, 2013-10-18 at 16:07 +0100, Wei Liu wrote:> On Fri, Oct 18, 2013 at 04:04:17PM +0100, Wei Liu wrote:
> > On Fri, Oct 18, 2013 at 03:59:10PM +0100, Ian Campbell wrote:
> > [...]
> > > > > 
> > > > 
> > > > During OVMF initialization:
> > > > 
> > > > (d28) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> > > > (d28) Type =   Io16; Base = 0xC000;     Length = 0x1000;    
Alignment = 0xFFF
> > > > (d28)  Base = 0xC000;   Length = 0x100; Alignment = 0xFF;   
Owner = PCI  [00|04|
> > > > (d28)  Base = 0xC100;   Length = 0x100; Alignment = 0xFF;   
Owner = PCI  [00|03|
> > > > (d28)  Base = 0xC200;   Length = 0x10;  Alignment = 0xF;    
Owner = PCI  [00|01|
> > > > (d28) Type =  Mem32; Base = 0x80000000; Length = 0x3100000; 
Alignment = 0x1FFFFF
> > > > (d28)  Base = 0x80000000;       Length = 0x2000000;    
Alignment = 0x1FFFFFF;  Owne
> > > > (d28) |02|00:10] 
> > > > 
> > > > Later when Linux loads EFIFB driver:
> > > > [    2.628264] efifb: framebuffer at 0x80000000, mapped to
> > > > 0xffffc90000100000, using 1876k, total 1875k
> > > > [    2.646827] efifb: mode is 800x600x32, linelength=3200,
pages=1
> > > > [    2.658833] efifb: scrolling: redraw
> > > > [    2.666342] efifb: Truecolor: size=8:8:8:8,
shift=24:16:8:0
> > > > 
> > > > 0xf0000000 is mapped by:
> > > 
> > > What hardware is backing the framebuffer at 0x80000000? It
doesn''t
> > > appear to be this cirrus device.
> > > 
> > 
> > Looking that the "Resource Map for Root Bridge" 0x8000000 is
backed by
> > 00:02:00 (trancated above) and 00:02.0 is also owned by Cirrus Logic
> > driver...
> > 
> > > Does this VM have two graphics cards and therefore two drivers
(efifb
> > > and cirrusfb/vesafb/etc)?
> > > 
> > > If there are two gfx cards then there should be two framebuffers
and
> > > therefore no mfn sharing in the p2m, although you would probably
be
> > > better off arranging for their to only one gfx card...
> > > 
> > 
> > AIUI there is only one card.
> > 
> 
> FWIW there''s a QEMU Cirrus Logic card driver in OVMF which drives
the
> emulated card.
So is the bug that both OVMF and Linux are trying to drive the card?
They can''t both do it, unless OVMF is even more magic than I thought...

Ian.

Paul Durrant

2013-Oct-18 15:12 UTC

head link

Re: Limitation in HVM physmap

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of George Dunlap
> Sent: 18 October 2013 15:26
> To: Wei Liu; Jan Beulich; Tim (Xen.org); Keir (Xen.org)
> Cc: Stefano Stabellini; Ian Campbell; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Limitation in HVM physmap
> 
> 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...)
> 
This doesn''t sound that unusual. The std-vga device model in QEMU moves
the vram around when the PCI bar is set up. The VRAM starts at 0xff000000 and is
mapped for access by the emulated aperture from a0000-bffff and then when the
PCI bar is set up it gets moved to wherever the firmware puts it.

  Paul

Stefano Stabellini

2013-Oct-18 15:14 UTC

head link

Re: Limitation in HVM physmap

On Fri, 18 Oct 2013, Ian Campbell wrote:> On Fri, 2013-10-18 at 15:56 +0100, Wei Liu wrote:
> > On Fri, Oct 18, 2013 at 04:41:49PM +0200, Tim Deegan wrote:
> > > At 15:36 +0100 on 18 Oct (1382107000), Wei Liu wrote:
> > > > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
> > > > > Hi,
> > > > > 
> > > > > At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> > > > > > 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?
> > > > > 
> > > > > 1. For simplicity.  That code is hard wnough to work
with already. :)
> > > > > 
> > > > > 2. It helps avoid worrying about inconsistent cache
settings if the
> > > > >    HAP tables only have one entry for each MFN. 
> > > > > 
> > > > > 3. Xen maintains a single mapping from MFN back to PFN,
and any code
> > > > >    that uses it would have to be able to deal with
getting multiple
> > > > >    answers.  That''s already been partly
changed by the mem_sharing
> > > > >    code (which obviously _can_ have multiple P2M
entries pointing to
> > > > >    the same MFN but is a bit complex as a result).
> > > > > 
> > > > 
> > > > I see.
> > > > 
> > > > > > 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?
> > > > > 
> > > > > Qemu could remember where it put the framebuffer last
time and unmap
> > > > > it.  AIUI that''s how real hardware would
behave if you changed the
> > > > > framebuffer base address -- the framebuffer
wouldn''t still be mapped at
> > > > > the old location as well.
> > > > > 
> > > > 
> > > > In fact, this is not the case in OVMF. EFIFB driver in Linux
will always
> > > > use the EFIFB region (0x80000000) provided by OVMF. 
> > > 
> > > So what''s mapping it at 0xf00000000?  Is linux running
two drivers
> > > against the same graphics card at the same time?  That sounds
like
> > > trouble!
> > > 
> > 
> > During OVMF initialization:
> > 
> > (d28) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> > (d28) Type =   Io16; Base = 0xC000;     Length = 0x1000;       
Alignment = 0xFFF
> > (d28)  Base = 0xC000;   Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|04|
> > (d28)  Base = 0xC100;   Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|03|
> > (d28)  Base = 0xC200;   Length = 0x10;  Alignment = 0xF;        Owner
= PCI  [00|01|
> > (d28) Type =  Mem32; Base = 0x80000000; Length = 0x3100000;    
Alignment = 0x1FFFFF
> > (d28)  Base = 0x80000000;       Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owne
> > (d28) |02|00:10] 
> > 
> > Later when Linux loads EFIFB driver:
> > [    2.628264] efifb: framebuffer at 0x80000000, mapped to
> > 0xffffc90000100000, using 1876k, total 1875k
> > [    2.646827] efifb: mode is 800x600x32, linelength=3200, pages=1
> > [    2.658833] efifb: scrolling: redraw
> > [    2.666342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> > 
> > 0xf0000000 is mapped by:
> 
> What hardware is backing the framebuffer at 0x80000000? It doesn''t
> appear to be this cirrus device.
Is it possible that the UEFI VGA framebuffer is exposed via two
different regions?
After all that is what happens today on any VGA card: one is the PCI
MMIO region, the other is the legacy VGA framebuffer address.
Maybe 0x80000000 is the VGA framebuffer configured by the UEFI firmware
and needs to stay accessible even after the driver sets the PCI BAR for
the card.

Wei Liu

2013-Oct-18 15:30 UTC

head link

Re: Limitation in HVM physmap

On Fri, Oct 18, 2013 at 04:07:58PM +0100, Ian Campbell
wrote:> On Fri, 2013-10-18 at 16:01 +0100, Wei Liu wrote:
> > On Fri, Oct 18, 2013 at 03:47:25PM +0100, Jan Beulich wrote:
> > > >>> On 18.10.13 at 16:36, Wei Liu
<wei.liu2@citrix.com> wrote:
> > > > On Fri, Oct 18, 2013 at 04:28:24PM +0200, Tim Deegan wrote:
> > > >> At 15:20 +0100 on 18 Oct (1382106012), Wei Liu wrote:
> > > >> > 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?
> > > 
> > > Since when does the Linux kernel have control over the physical
> > > address where the frame buffer sits (other than by writing PCI
> > > devices'' BARs, which implies the address range to change
rather
> > > than a second instance to be created)?
> > > 
> > 
> > I don''t think Linux changes things -- 0xf0000000 is what it
gets from
> > Xen and it honors that. It''s OVMF that plays with things.
There is a
> > procedure in OVMF that remaps PCI resources.
> 
> Does all of this get logged to the xen debug console? Can you post a
> full log perhaps to clarify things for us?
> 
Firmware log (with tedious bits removed):
(d1) HVM Loader
(d1) Detected Xen v4.4-unstable
(d1) Xenbus rings @0xfeffc000, event channel 4
(d1) System requested OVMF
(d1) CPU speed is 2131 MHz
(d1) Relocating guest memory for lowmem MMIO space disabled
(XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5
(d1) PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10
(d1) PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11
(d1) PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5
(d1) PCI-ISA link 3 routed to IRQ5
(d1) pci dev 01:3 INTA->IRQ10
(d1) pci dev 03:0 INTA->IRQ5
(d1) pci dev 04:0 INTA->IRQ5
(d1) No RAM in high memory; setting high_mem resource base to 100000000
(d1) pci dev 02:0 bar 10 size 002000000: 0f0000008
(d1) pci dev 03:0 bar 14 size 001000000: 0f2000008
(d1) pci dev 02:0 bar 30 size 000010000: 0f3000000
(d1) pci dev 04:0 bar 30 size 000010000: 0f3010000
(d1) pci dev 02:0 bar 14 size 000001000: 0f3020000
(d1) pci dev 03:0 bar 10 size 000000100: 00000c001
(d1) pci dev 04:0 bar 10 size 000000100: 00000c101
(d1) pci dev 04:0 bar 14 size 000000100: 0f3021000
(d1) pci dev 01:1 bar 20 size 000000010: 00000c201
(d1) Multiprocessor initialisation:
(d1)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d1)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d1) Testing HVM environment:
(d1)  - REP INSB across page boundaries ... passed
(d1)  - GS base MSRs and SWAPGS ... passed
(d1) Passed 2 of 2 tests
(d1) Writing SMBIOS tables ...
(d1) Loading OVMF ...
(d1) Loading ACPI ...
(d1) vm86 TSS at fc012c00
(d1) BIOS map:
(d1)  00000-fffff: Main BIOS
(d1) Invoking OVMF ...
(d1) SecCoreStartupWithStack(0xFFFEC000, 0x80000)
(d1) File->Type: 0xB
(d1) Section->Type: 0x2
(d1) Section->Type: 0x19
(d1) Section->Type (0x19) != SectionType (0x17)
(d1) Section->Type: 0x17
(d1) File->Type: 0x2
(d1) File->Type (0x2) != FileType (0x4)
(d1) File->Type: 0xF0
(d1) File->Type (0xF0) != FileType (0x4)
(d1) File->Type: 0x4
(d1) Section->Type: 0x19
(d1) Section->Type (0x19) != SectionType (0x10)
(d1) Section->Type: 0x10
(d1) The 0th FV start address is 0x00000800000, size is 0x00800000, handle is
0x8000
(d1) 00
(d1) Loading PEIM at 0x000008162A0 EntryPoint=0x00000816500 PcdPeim.efi
(d1) Loading PEIM at 0x0000081DD20 EntryPoint=0x0000081DF80 StatusCodePei.efi
(d1) Loading PEIM at 0x00000823920 EntryPoint=0x00000823B80 PlatformPei.efi
(d1) Platform PEIM Loaded
(d1) CMOS:
(d1) 00: 21 00 59 00 14 00 05 18 10 13 26 02 10 80 00 00
(d1) 10: 00 00 F0 00 06 80 02 FF FF 2F 00 FF 3F 10 FF FF
(d1) 20: C8 FF 3F 3F 00 00 00 00 00 00 00 00 00 00 00 00
(d1) 30: FF FF 20 00 80 0E 00 20 10 01 00 00 00 32 00 00
(d1) 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(d1) 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
(d1) 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(d1) 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(d1) MemDetect called
(d1) PeiInstallPeiMemory MemoryBegin 0xB800000, MemoryLength 0x4000000
(d1) Xen was detected
(d1) Detected Xen version 4.4
(d1) Reserved variable store memory: 0xF7D0000; size: 128kb
(d1) Platform PEI Firmware Volume Initialization
(d1) Firmware Volume HOB: 0x800000 0x800000
(d1) Temp Stack : BaseAddress=0x78000 Length=0x8000
(d1) Temp Heap  : BaseAddress=0x70000 Length=0x820
(d1) Total temporary memory:    65536 bytes.
(d1)   temporary memory stack ever used: 32768 bytes.
(d1)   temporary memory heap used:       2080 bytes.
(d1) Old Stack size 32768, New stack size 131072
(d1) Heap Offset = 0xB7B0000 Stack Offset = 0xB7A0000
(d1) Stack Hob: BaseAddress=0xB800000 Length=0x20000
(d1) TemporaryRamMigration(0x70000, 0xB818000, 0x10000)
(d1) Loading PEIM at 0x0000F7B7000 EntryPoint=0x0000F7B7260 PeiCore.efi
(d1) Loading PEIM at 0x0000F7AD000 EntryPoint=0x0000F7AD260 DxeIpl.efi
(d1) Notify: PPI Guid: EA7CA24B-DED5-4DAD-A389-BF827E8F9B38, Peim notify entry
point
(d1) : 8037BC
(d1) The 1th FV start address is 0x0000F25C000, size is 0x00550000, handle is
0xF25C
(d1) 000
(d1) DXE IPL Entry
(d1) Loading PEIM at 0x0000F226000 EntryPoint=0x0000F226260 DxeCore.efi
(d1) Loading DXE CORE at 0x0000F226000 EntryPoint=0x0000F226260
(d1) HOBLIST address in DXE = 0xEFDB018
(d1) Memory Allocation 0x00000004 0xF7FF000 - 0xF7FFFFF
(d1) Memory Allocation 0x00000004 0xF7CF000 - 0xF7FEFFF
(d1) Memory Allocation 0x00000004 0x800000 - 0xFFFFFF
(d1) Memory Allocation 0x00000004 0xF206000 - 0xF225FFF
(d1) Memory Allocation 0x00000004 0xF7CE000 - 0xF7CEFFF
(d1) Memory Allocation 0x00000004 0xF7B7000 - 0xF7CDFFF
(d1) Memory Allocation 0x00000004 0xF7AD000 - 0xF7B6FFF
(d1) Memory Allocation 0x00000004 0xF25B000 - 0xF7ACFFF
(d1) Memory Allocation 0x00000004 0xF226000 - 0xF25AFFF
(d1) Memory Allocation 0x00000003 0xF226000 - 0xF25AFFF
(d1) Memory Allocation 0x00000004 0xF206000 - 0xF225FFF
(d1) Memory Allocation 0x00000004 0xF1C4000 - 0xF205FFF
(d1) Memory Allocation 0x00000004 0xB800000 - 0xB81FFFF
(d1) FV Hob            0x800000 - 0xFFFFFF
(d1) FV Hob            0xF25C000 - 0xF7ABFFF
(d1) FV2 Hob           0xF25C000 - 0xF7ABFFF
(d1) fi
(d1)   Flushing GCD
(d1)   Flushing GCD
(d1)   Flushing GCD
(d1)   Flushing GCD
(d1)   Flushing GCD
(d1) xe.efi
(d1) EMU Variable FVB Started
(d1) EMU Variable FVB: Using pre-reserved block at F7D0000
(d1) EMU Variable FVB: Basic FV headers were invalid
(d1) Installing FVB for EMU Variable support
(d1) efi
(d1) Ftw: Remaining work space size - 1FE0
(d1) Ftw: Work block header check error
(d1) Ftw: Work block header check error
(d1) Ftw: Both are invalid, init workspace
(d1) Ftw: start to reclaim work space
(d1) Ftw: reclaim work space successfully
(d1)
(d1) eDxe.efi
(d1) Select Item: 0x0
(d1) FW CFG Signature: 0xFFFFFFFF
(d1) Select Item: 0x1
(d1) FW CFG Revision: 0xFFFFFFFF
(d1) QemuFwCfg interface not supported.
(d1) Select Item: 0x0
(d1) FW CFG Signature: 0xFFFFFFFF
(d1) Select Item: 0x1
(d1) FW CFG Revision: 0xFFFFFFFF
(d1) QemuFwCfg interface not supported.
(d1) efi
(d1)
(d1) [BdsDxe] Locate Variable Lock protocol - Success
(d1) [Variable] Lock: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:PlatformLangCodes
(d1) [Variable] Lock: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:LangCodes
(d1) [Variable] Lock: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:BootOptionSupport
(d1) [Variable] Lock: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:HwErrRecSupport
(d1) [Variable] Lock:
8BE4DF61-93CA-11D2-AA0D-00E098032B8C:OsIndicationsSupported
(d1) Variable Driver Auto Update Lang, Lang:eng, PlatformLang:en
(d1) PlatformBdsInit
(d1) Registered NotifyDevPath Event
(d1) PlatformBdsPolicyBehavior
(d1) PCI Bus First Scanning
(d1) PciBus: Discovered PCI @ [00|00|00]
(d1)
(d1) PciBus: Discovered PCI @ [00|01|00]
(d1)
(d1) PciBus: Discovered PCI @ [00|01|01]
(d1)    BAR[4]: Type =   Io32; Alignment = 0xF; Length = 0x10;  Offset = 0x20
(d1)
(d1) PciBus: Discovered PCI @ [00|01|03]
(d1)
(d1) PciBus: Discovered PCI @ [00|02|00]
(d1)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length = 0x2000000;    
Offset = 0
(d1) x10
(d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x1000;       
Offset = 0x14
(d1)
(d1) PciBus: Discovered PCI @ [00|03|00]
(d1)    BAR[0]: Type =   Io32; Alignment = 0xFF;        Length = 0x100; Offset =
0x10
(d1)    BAR[1]: Type = PMem32; Alignment = 0xFFFFFF;    Length = 0x1000000;    
Offset = 0x
(d1) 14
(d1)
(d1) PciBus: Discovered PCI @ [00|04|00]
(d1)    BAR[0]: Type =   Io32; Alignment = 0xFF;        Length = 0x100; Offset =
0x10
(d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x100; Offset =
0x14
(d1)
(d1) PciBus: Discovered PCI @ [00|00|00]
(d1)
(d1) PciBus: Discovered PCI @ [00|01|00]
(d1)
(d1) PciBus: Discovered PCI @ [00|01|01]
(d1)    BAR[4]: Type =   Io32; Alignment = 0xF; Length = 0x10;  Offset = 0x20
(d1)
(d1) PciBus: Discovered PCI @ [00|01|03]
(d1)
(d1) PciBus: Discovered PCI @ [00|02|00]
(d1)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length = 0x2000000;    
Offset = 0
(d1) x10
(d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x1000;       
Offset = 0x14
(d1)
(d1) PciBus: Discovered PCI @ [00|03|00]
(d1)    BAR[0]: Type =   Io32; Alignment = 0xFF;        Length = 0x100; Offset =
0x10
(d1)    BAR[1]: Type = PMem32; Alignment = 0xFFFFFF;    Length = 0x1000000;    
Offset = 0x
(d1) 14
(d1)
(d1) PciBus: Discovered PCI @ [00|04|00]
(d1)    BAR[0]: Type =   Io32; Alignment = 0xFF;        Length = 0x100; Offset =
0x10
(d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x100; Offset =
0x14
(d1)
(d1) PciBus: HostBridge->SubmitResources() - Success
(d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
[  403.936062] xenbr0: port 3(vif1.0-emu) entered forwarding state
(d1) PciBus: Resource Map for Root Bridge PciRoot(0x0)
(d1) Type =   Io16; Base = 0xC000;      Length = 0x1000;        Alignment =
0xFFF
(d1)  Base = 0xC000;    Length = 0x100; Alignment = 0xFF;       Owner = PCI 
[00|04|00:10]
(d1)  Base = 0xC100;    Length = 0x100; Alignment = 0xFF;       Owner = PCI 
[00|03|00:10]
(d1)  Base = 0xC200;    Length = 0x10;  Alignment = 0xF;        Owner = PCI 
[00|01|01:20]
(d1) Type =  Mem32; Base = 0x80000000;  Length = 0x3100000;     Alignment =
0x1FFFFFF
(d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment = 0x1FFFFFF; 
Owner = PCI  [00
(d1) |02|00:10]
(d1)  Base = 0x82000000;        Length = 0x1000000;     Alignment = 0xFFFFFF;  
Owner = PCI  [00|
(d1) 03|00:14]
(d1)  Base = 0x83000000;        Length = 0x100; Alignment = 0xFFF;      Owner =
PCI  [00|04|00:1
(d1) 4]
(d1)  Base = 0x83001000;        Length = 0x1000;        Alignment = 0xFFF;     
Owner = PCI  [00|02|00:
(d1) 14]
(d1)
(d1) Found Mass Storage device: PciRoot(0x0)/Pci(0x1,0x1)
(d1)  BlockSize : 512
(d1)  LastBlock : 1FFFFFF
(d1)  Valid efi partition table header
(d1)  Valid efi partition table header
(d1)  Valid primary and Valid backup partition table
(d1)  Partition entries read block success
(d1)  Number of partition entries: 128
(d1)  start check partition entries
(d1)  End check partition entries
(d1)  Index : 0
(d1)  Start LBA : 800
(d1)  End LBA : 1E99FFF
(d1)  Partition size: 1E99800
(d1)  Start : 100000 End : 3D33FFE00
(d1)  Index : 1
(d1)  Start LBA : 1E9A000
(d1)  End LBA : 1FFF7FF
(d1)  Partition size: 165800
(d1)  Start : 3D3400000 End : 3FFEFFE00
(d1) Prepare to Free Pool
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(d1)  BlockSize : 512
(d1)  LastBlock : 1657FF
(d1)  BlockSize : 2048
(d1)  LastBlock : 0
(d1) FsAccess.c: LoadNvVarsFromFs
(d1) FsAccess.c: Read 1467 bytes from NV Variables file
(d1) Variable Driver Auto Update PlatformLang, PlatformLang:en, Lang:eng
(d1) Variable Driver Auto Update Lang, Lang:eng, PlatformLang:en
(d1) FsAccess.c: Read NV Variables file (size=1)
(d1) Saved NV Variables to NvVars file
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) PlatformBdsGetDriverOption
(d1) Boot Mode:0
(d1) Found PCI VGA device
(d1) QemuVideo: Cirrus 5446 detected
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) Adding Cirrus Video Mode 0: 640x480, 32-bit, 60 Hz
(d1) Adding Cirrus Video Mode 1: 800x600, 32-bit, 60 Hz
(d1) Adding Cirrus Video Mode 2: 1024x768, 24-bit, 60 Hz
(XEN) stdvga.c:147:d1 entering stdvga and caching modes
(XEN) stdvga.c:151:d1 leaving stdvga
(XEN) multi.c:3336:d1 write to pagetable during event injection: cr2=0xf225508,
mfn=0x156a25
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) FrameBufferBase: 0x80000000, FrameBufferSize: 0x12C000
(d1) 0: shl:0 shr:0 mask:FF0000
(d1) 1: shl:0 shr:0 mask:FF00
(d1) 2: shl:0 shr:0 mask:FF
(d1) Bytes per pixel: 4
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) Terminal - Mode 0, Column = 80, Row = 25
(d1) Terminal - Mode 1, Column = 80, Row = 50
(d1) Terminal - Mode 2, Column = 100, Row = 31
(d1) EmuVariablesUpdatedCallback
(d1) Saved NV Variables to NvVars file
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) FrameBufferBase: 0x80000000, FrameBufferSize: 0x1D4C00
(d1) 0: shl:0 shr:0 mask:FF0000
(d1) 1: shl:0 shr:0 mask:FF00
(d1) 2: shl:0 shr:0 mask:FF
(d1) Bytes per pixel: 4
(d1) GraphicsConsole video resolution 800 x 600
(d1) Graphics - Mode 0, Column = 80, Row = 25
(d1) Graphics - Mode 1, Column = 0, Row = 0
(d1) Graphics - Mode 2, Column = 100, Row = 31
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) PlatformBdsDiagnostics
(d1) PlatformBdsConnectSequence
(d1)  BlockSize : 512
(d1)  LastBlock : 1FFFFFF
(d1)  Valid efi partition table header
(d1)  Valid efi partition table header
(d1)  Valid primary and Valid backup partition table
(d1)  Partition entries read block success
(d1)  Number of partition entries: 128
(d1)  start check partition entries
(d1)  End check partition entries
(d1)  Index : 0
(d1)  Start LBA : 800
(d1)  End LBA : 1E99FFF
(d1)  Partition size: 1E99800
(d1)  Start : 100000 End : 3D33FFE00
(d1)  Index : 1
(d1)  Start LBA : 1E9A000
(d1)  End LBA : 1FFF7FF
(d1)  Partition size: 165800
(d1)  Start : 3D3400000 End : 3FFEFFE00
(d1) Prepare to Free Pool
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(d1)  BlockSize : 2048
(d1)  LastBlock : 0
(d1)  BlockSize : 512
(d1)  LastBlock : 1FFFFFF
(d1)  Valid efi partition table header
(d1)  Valid efi partition table header
(d1)  Valid primary and Valid backup partition table
(d1)  Partition entries read block success
(d1)  Number of partition entries: 128
(d1)  start check partition entries
(d1)  End check partition entries
(d1)  Index : 0
(d1)  Start LBA : 800
(d1)  End LBA : 1E99FFF
(d1)  Partition size: 1E99800
(d1)  Start : 100000 End : 3D33FFE00
(d1)  Index : 1
(d1)  Start LBA : 1E9A000
(d1)  End LBA : 1FFF7FF
(d1)  Partition size: 165800
(d1)  Start : 3D3400000 End : 3FFEFFE00
(d1) Prepare to Free Pool
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(d1)  BlockSize : 2048
(d1)  LastBlock : 0
(d1)  BlockSize : 512
(d1)  LastBlock : 1FFFFFF
(d1)  Valid efi partition table header
(d1)  Valid efi partition table header
(d1)  Valid primary and Valid backup partition table
(d1)  Partition entries read block success
(d1)  Number of partition entries: 128
(d1)  start check partition entries
(d1)  End check partition entries
(d1)  Index : 0
(d1)  Start LBA : 800
(d1)  End LBA : 1E99FFF
(d1)  Partition size: 1E99800
(d1)  Start : 100000 End : 3D33FFE00
(d1)  Index : 1
(d1)  Start LBA : 1E9A000
(d1)  End LBA : 1FFF7FF
(d1)  Partition size: 165800
(d1)  Start : 3D3400000 End : 3FFEFFE00
(d1) Prepare to Free Pool
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(d1)  BlockSize : 2048
(d1)  LastBlock : 0
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 11
(XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 11
(XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 10
(XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 10
(d1) BdsLibConnectAll
(d1)  BlockSize : 512
(d1)  LastBlock : 1FFFFFF
(d1)  Valid efi partition table header
(d1)  Valid efi partition table header
(d1)  Valid primary and Valid backup partition table
(d1)  Partition entries read block success
(d1)  Number of partition entries: 128
(d1)  start check partition entries
(d1)  End check partition entries
(d1)  Index : 0
(d1)  Start LBA : 800
(d1)  End LBA : 1E99FFF
(d1)  Partition size: 1E99800
(d1)  Start : 100000 End : 3D33FFE00
(d1)  Index : 1
(d1)  Start LBA : 1E9A000
(d1)  End LBA : 1FFF7FF
(d1)  Partition size: 165800
(d1)  Start : 3D3400000 End : 3FFEFFE00
(d1) Prepare to Free Pool
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(d1)  BlockSize : 2048
(d1)  LastBlock : 0
(d1)  BlockSize : 512
(d1)  LastBlock : 1FFFFFF
(d1)  Valid efi partition table header
(d1)  Valid efi partition table header
(d1)  Valid primary and Valid backup partition table
(d1)  Partition entries read block success
(d1)  Number of partition entries: 128
(d1)  start check partition entries
(d1)  End check partition entries
(d1)  Index : 0
(d1)  Start LBA : 800
(d1)  End LBA : 1E99FFF
(d1)  Partition size: 1E99800
(d1)  Start : 100000 End : 3D33FFE00
(d1)  Index : 1
(d1)  Start LBA : 1E9A000
(d1)  End LBA : 1FFF7FF
(d1)  Partition size: 165800
(d1)  Start : 3D3400000 End : 3FFEFFE00
(d1) Prepare to Free Pool
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(d1)  BlockSize : 2048
(d1)  LastBlock : 0
(d1)  BlockSize : 512
(d1)  LastBlock : 1FFFFFF
(d1)  Valid efi partition table header
(d1)  Valid efi partition table header
(d1)  Valid primary and Valid backup partition table
(d1)  Partition entries read block success
(d1)  Number of partition entries: 128
(d1)  start check partition entries
(d1)  End check partition entries
(d1)  Index : 0
(d1)  Start LBA : 800
(d1)  End LBA : 1E99FFF
(d1)  Partition size: 1E99800
(d1)  Start : 100000 End : 3D33FFE00
(d1)  Index : 1
(d1)  Start LBA : 1E9A000
(d1)  End LBA : 1FFF7FF
(d1)  Partition size: 165800
(d1)  Start : 3D3400000 End : 3FFEFFE00
(d1) Prepare to Free Pool
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(d1)  BlockSize : 2048
(d1)  LastBlock : 0
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(d1) Buffer: EFI DVD/CDROM
(d1) Buffer: EFI Hard Drive
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) Memory  Previous  Current    Next
(d1)  Type    Pages     Pages     Pages
(d1) ======  ========  ========  =======(d1)   0A    00000004  00000001 
00000004
(d1)   09    00000008  0000001A  00000020
(d1)   00    00000004  00000002  00000004
(d1)   06    00000024  0000003A  00000048
(d1)   05    00000030  00000048  0000005A
(d1)   03    00000180  000003B2  0000049E
(d1)   04    00000F00  00001ACA  0000217C
(d1) Booting EFI DVD/CDROM
(d1)  BlockSize : 2048
(d1)  LastBlock : 0
(d1) PlatformBdsBootFail
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) Memory  Previous  Current    Next
(d1)  Type    Pages     Pages     Pages
(d1) ======  ========  ========  =======(d1)   0A    00000004  00000001 
00000004
(d1)   09    00000020  0000001A  00000020
(d1)   00    00000004  00000002  00000004
(d1)   06    00000048  0000003A  00000048
(d1)   05    0000005A  00000048  0000005A
(d1)   03    0000049E  000003B2  0000049E
(d1)   04    0000217C  00001ACA  0000217C
(d1) Booting EFI Floppy
(d1) PlatformBdsBootFail
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) Memory  Previous  Current    Next
(d1)  Type    Pages     Pages     Pages
(d1) ======  ========  ========  =======(d1)   0A    00000004  00000001 
00000004
(d1)   09    00000020  0000001A  00000020
(d1)   00    00000004  00000002  00000004
(d1)   06    00000048  0000003A  00000048
(d1)   05    0000005A  00000048  0000005A
(d1)   03    0000049E  000003B2  0000049E
(d1)   04    0000217C  00001ACA  0000217C
(d1) Booting EFI Floppy 1
(d1) PlatformBdsBootFail
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) Memory  Previous  Current    Next
(d1)  Type    Pages     Pages     Pages
(d1) ======  ========  ========  =======(d1)   0A    00000004  00000001 
00000004
(d1)   09    00000020  0000001A  00000020
(d1)   00    00000004  00000002  00000004
(d1)   06    00000048  0000003A  00000048
(d1)   05    0000005A  00000048  0000005A
(d1)   03    0000049E  000003B2  0000049E
(d1)   04    0000217C  00001ACA  0000217C
(d1) Booting EFI Hard Drive
(d1)  BlockSize : 512
(d1)  LastBlock : 1FFFFFF
(d1)  Valid efi partition table header
(d1)  Valid efi partition table header
(d1)  Valid primary and Valid backup partition table
(d1)  Partition entries read block success
(d1)  Number of partition entries: 128
(d1)  start check partition entries
(d1)  End check partition entries
(d1)  Index : 0
(d1)  Start LBA : 800
(d1)  End LBA : 1E99FFF
(d1)  Partition size: 1E99800
(d1)  Start : 100000 End : 3D33FFE00
(d1)  Index : 1
(d1)  Start LBA : 1E9A000
(d1)  End LBA : 1FFF7FF
(d1)  Partition size: 165800
(d1)  Start : 3D3400000 End : 3FFEFFE00
(d1) Prepare to Free Pool
(d1)  BlockSize : 512
(d1)  LastBlock : 1E997FF
(d1) PixelBlueGreenRedReserved8BitPerColor
(d1) ConvertPages: Incompatible memory types
(XEN) irq.c:375: Dom1 callback via changed to Direct Vector 0xf3
(XEN) irq.c:270: Dom1 PCI link 0 changed 11 -> 0
(XEN) irq.c:270: Dom1 PCI link 1 changed 11 -> 0
(XEN) irq.c:270: Dom1 PCI link 2 changed 10 -> 0
(XEN) irq.c:270: Dom1 PCI link 3 changed 10 -> 0
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff


dmesg in guest:
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.13-stable-for-h16 (weil@dt47) (gcc version
4.7.2 (Debian 4.7.2-5) ) #10 SMP Thu Oct 3 15:18:49 BST 2013
[    0.000000] Command line: root=/dev/xvda1 loglevel=10 earlyprintk=xen
console=ttyS0 console=hvc0 console=tty1 console=tty0
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000000d94dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000d94e000-0x000000000d95ffff] ACPI data
[    0.000000] BIOS-e820: [mem 0x000000000d960000-0x000000000d98efff] reserved
[    0.000000] BIOS-e820: [mem 0x000000000d98f000-0x000000000f15efff] usable
[    0.000000] BIOS-e820: [mem 0x000000000f15f000-0x000000000f1b6fff] reserved
[    0.000000] BIOS-e820: [mem 0x000000000f1b7000-0x000000000f1befff] ACPI data
[    0.000000] BIOS-e820: [mem 0x000000000f1bf000-0x000000000f1c2fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000000f1c3000-0x000000000f7fffff] usable
[    0.000000] e820: update [mem 0x0d258018-0x0d267057] usable ==> usable
[    0.000000] extended physical RAM map:
[    0.000000] reserve setup_data: [mem 0x0000000000000000-0x000000000009ffff]
usable
[    0.000000] reserve setup_data: [mem 0x0000000000100000-0x000000000d258017]
usable
[    0.000000] reserve setup_data: [mem 0x000000000d258018-0x000000000d267057]
usable
[    0.000000] reserve setup_data: [mem 0x000000000d267058-0x000000000d94dfff]
usable
[    0.000000] reserve setup_data: [mem 0x000000000d94e000-0x000000000d95ffff]
ACPI data
[    0.000000] reserve setup_data: [mem 0x000000000d960000-0x000000000d98efff]
reserved
[    0.000000] reserve setup_data: [mem 0x000000000d98f000-0x000000000f15efff]
usable
[    0.000000] reserve setup_data: [mem 0x000000000f15f000-0x000000000f1b6fff]
reserved
[    0.000000] reserve setup_data: [mem 0x000000000f1b7000-0x000000000f1befff]
ACPI data
[    0.000000] reserve setup_data: [mem 0x000000000f1bf000-0x000000000f1c2fff]
ACPI NVS
[    0.000000] reserve setup_data: [mem 0x000000000f1c3000-0x000000000f7fffff]
usable
[    0.000000] ERROR: earlyprintk= xenboot already used
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] efi: EFI v2.31 by EDK II
[    0.000000] efi:  SMBIOS=0xf1b6000  ACPI=0xf1be000  ACPI 2.0=0xf1be014 
[    0.000000] efi: mem00: type=7, attr=0xf,
range=[0x0000000000000000-0x00000000000a0000) (0MB)
[    0.000000] efi: mem01: type=2, attr=0xf,
range=[0x0000000000100000-0x0000000000107000) (0MB)
[    0.000000] efi: mem02: type=7, attr=0xf,
range=[0x0000000000107000-0x0000000000800000) (6MB)
[    0.000000] efi: mem03: type=4, attr=0xf,
range=[0x0000000000800000-0x0000000001000000) (8MB)
[    0.000000] efi: mem04: type=2, attr=0xf,
range=[0x0000000001000000-0x00000000022e6000) (18MB)
[    0.000000] efi: mem05: type=7, attr=0xf,
range=[0x00000000022e6000-0x000000000b800000) (149MB)
[    0.000000] efi: mem06: type=4, attr=0xf,
range=[0x000000000b800000-0x000000000b820000) (0MB)
[    0.000000] efi: mem07: type=7, attr=0xf,
range=[0x000000000b820000-0x000000000c73e000) (15MB)
[    0.000000] efi: mem08: type=1, attr=0xf,
range=[0x000000000c73e000-0x000000000ccd3000) (5MB)
[    0.000000] efi: mem09: type=7, attr=0xf,
range=[0x000000000ccd3000-0x000000000d258000) (5MB)
[    0.000000] efi: mem10: type=2, attr=0xf,
range=[0x000000000d258000-0x000000000d268000) (0MB)
[    0.000000] efi: mem11: type=1, attr=0xf,
range=[0x000000000d268000-0x000000000d27f000) (0MB)
[    0.000000] efi: mem12: type=7, attr=0xf,
range=[0x000000000d27f000-0x000000000d287000) (0MB)
[    0.000000] efi: mem13: type=2, attr=0xf,
range=[0x000000000d287000-0x000000000d288000) (0MB)
[    0.000000] efi: mem14: type=7, attr=0xf,
range=[0x000000000d288000-0x000000000d289000) (0MB)
[    0.000000] efi: mem15: type=4, attr=0xf,
range=[0x000000000d289000-0x000000000d293000) (0MB)
[    0.000000] efi: mem16: type=2, attr=0xf,
range=[0x000000000d293000-0x000000000d294000) (0MB)
[    0.000000] efi: mem17: type=4, attr=0xf,
range=[0x000000000d294000-0x000000000d71a000) (4MB)
[    0.000000] efi: mem18: type=3, attr=0xf,
range=[0x000000000d71a000-0x000000000d94e000) (2MB)
[    0.000000] efi: mem19: type=9, attr=0xf,
range=[0x000000000d94e000-0x000000000d960000) (0MB)
[    0.000000] efi: mem20: type=6, attr=0x800000000000000f,
range=[0x000000000d960000-0x000000000d962000) (0MB)
[    0.000000] efi: mem21: type=5, attr=0x800000000000000f,
range=[0x000000000d962000-0x000000000d97a000) (0MB)
[    0.000000] efi: mem22: type=6, attr=0x800000000000000f,
range=[0x000000000d97a000-0x000000000d98f000) (0MB)
[    0.000000] efi: mem23: type=4, attr=0xf,
range=[0x000000000d98f000-0x000000000e0df000) (7MB)
[    0.000000] efi: mem24: type=7, attr=0xf,
range=[0x000000000e0df000-0x000000000e0e1000) (0MB)
[    0.000000] efi: mem25: type=4, attr=0xf,
range=[0x000000000e0e1000-0x000000000efdf000) (14MB)
[    0.000000] efi: mem26: type=7, attr=0xf,
range=[0x000000000efdf000-0x000000000efe1000) (0MB)
[    0.000000] efi: mem27: type=3, attr=0xf,
range=[0x000000000efe1000-0x000000000f15f000) (1MB)
[    0.000000] efi: mem28: type=5, attr=0x800000000000000f,
range=[0x000000000f15f000-0x000000000f18f000) (0MB)
[    0.000000] efi: mem29: type=6, attr=0x800000000000000f,
range=[0x000000000f18f000-0x000000000f1b3000) (0MB)
[    0.000000] efi: mem30: type=0, attr=0xf,
range=[0x000000000f1b3000-0x000000000f1b7000) (0MB)
[    0.000000] efi: mem31: type=9, attr=0xf,
range=[0x000000000f1b7000-0x000000000f1bf000) (0MB)
[    0.000000] efi: mem32: type=10, attr=0xf,
range=[0x000000000f1bf000-0x000000000f1c3000) (0MB)
[    0.000000] efi: mem33: type=4, attr=0xf,
range=[0x000000000f1c3000-0x000000000f800000) (6MB)
[    0.000000] SMBIOS 2.7 present.
[    0.000000] DMI: Xen HVM domU, BIOS 4.4-unstable 10/15/2013
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.4.
[    0.000000] Xen Platform PCI: I/O protocol version 1
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for
this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for
this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0xf800 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF write-combining
[    0.000000]   C0000-FFFFF write-back
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0F0000000 mask FF8000000 uncachable
[    0.000000]   1 base 0F8000000 mask FFC000000 uncachable
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] BRK [0x02ec5000, 0x02ec5fff] PGTABLE
[    0.000000] BRK [0x02ec6000, 0x02ec6fff] PGTABLE
[    0.000000] BRK [0x02ec7000, 0x02ec7fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x0d000000-0x0d1fffff]
[    0.000000]  [mem 0x0d000000-0x0d1fffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x0c000000-0x0cffffff]
[    0.000000]  [mem 0x0c000000-0x0cffffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x00100000-0x0bffffff]
[    0.000000]  [mem 0x00100000-0x001fffff] page 4k
[    0.000000]  [mem 0x00200000-0x0bffffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x0d200000-0x0d94dfff]
[    0.000000]  [mem 0x0d200000-0x0d7fffff] page 2M
[    0.000000]  [mem 0x0d800000-0x0d94dfff] page 4k
[    0.000000] BRK [0x02ec8000, 0x02ec8fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x0d98f000-0x0f15efff]
[    0.000000]  [mem 0x0d98f000-0x0d9fffff] page 4k
[    0.000000]  [mem 0x0da00000-0x0effffff] page 2M
[    0.000000]  [mem 0x0f000000-0x0f15efff] page 4k
[    0.000000] BRK [0x02ec9000, 0x02ec9fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x0f1c3000-0x0f7fffff]
[    0.000000]  [mem 0x0f1c3000-0x0f1fffff] page 4k
[    0.000000]  [mem 0x0f200000-0x0f7fffff] page 2M
[    0.000000] ACPI: RSDP 000000000f1be014 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 000000000f1bd0e8 00054 (v01    Xen      HVM 00000000  
01000013)
[    0.000000] ACPI: FACP 000000000f1bc000 000F4 (v04    Xen      HVM 00000000
HVML 00000000)
[    0.000000] ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS
tables! (20130328/tbfadt-395)
[    0.000000] ACPI BIOS Bug: Warning: 32/64X FACS address mismatch in FADT -
0x0F1C2000/0x00000000FC001000, using 32 (20130328/tbfadt-522)
[    0.000000] ACPI: DSDT 000000000d94e000 1138D (v02    Xen      HVM 00000000
INTL 20100528)
[    0.000000] ACPI: FACS 000000000f1c2000 00040
[    0.000000] ACPI: APIC 000000000f1bb000 00460 (v02    Xen      HVM 00000000
HVML 00000000)
[    0.000000] ACPI: HPET 000000000f1ba000 00038 (v01    Xen      HVM 00000000
HVML 00000000)
[    0.000000] ACPI: WAET 000000000f1b9000 00028 (v01    Xen      HVM 00000000
HVML 00000000)
[    0.000000] ACPI: SSDT 000000000f1b8000 00031 (v02    Xen      HVM 00000000
INTL 20100528)
[    0.000000] ACPI: SSDT 000000000f1b7000 00031 (v02    Xen      HVM 00000000
INTL 20100528)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000000f7fffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x0f7fffff]
[    0.000000]   NODE_DATA [mem 0x0d285000-0x0d288fff]
[    0.000000]  [ffffea0000000000-ffffea00003fffff] PMD ->
[ffff88000c600000-ffff88000c9fffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009ffff]
[    0.000000]   node   0: [mem 0x00100000-0x0d94dfff]
[    0.000000]   node   0: [mem 0x0d98f000-0x0f15efff]
[    0.000000]   node   0: [mem 0x0f1c3000-0x0f7fffff]
[    0.000000] On node 0 totalpages: 63226
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 2071 pages reserved
[    0.000000]   DMA zone: 3999 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 812 pages used for memmap
[    0.000000]   DMA32 zone: 59227 pages, LIFO batch:15
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x1e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x20] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x22] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x24] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x26] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x28] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x2a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x2c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x2e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x18] lapic_id[0x30] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x19] lapic_id[0x32] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x34] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x36] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x38] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x3a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x3c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x3e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x20] lapic_id[0x40] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x21] lapic_id[0x42] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x22] lapic_id[0x44] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x23] lapic_id[0x46] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x24] lapic_id[0x48] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x25] lapic_id[0x4a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x26] lapic_id[0x4c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x27] lapic_id[0x4e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x28] lapic_id[0x50] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x29] lapic_id[0x52] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2a] lapic_id[0x54] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2b] lapic_id[0x56] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2c] lapic_id[0x58] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2d] lapic_id[0x5a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2e] lapic_id[0x5c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x2f] lapic_id[0x5e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x30] lapic_id[0x60] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x31] lapic_id[0x62] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x32] lapic_id[0x64] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x33] lapic_id[0x66] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x34] lapic_id[0x68] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x35] lapic_id[0x6a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x36] lapic_id[0x6c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x37] lapic_id[0x6e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x38] lapic_id[0x70] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x39] lapic_id[0x72] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3a] lapic_id[0x74] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3b] lapic_id[0x76] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3c] lapic_id[0x78] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3d] lapic_id[0x7a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3e] lapic_id[0x7c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x3f] lapic_id[0x7e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x40] lapic_id[0x80] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x41] lapic_id[0x82] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x42] lapic_id[0x84] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x43] lapic_id[0x86] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x44] lapic_id[0x88] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x45] lapic_id[0x8a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x46] lapic_id[0x8c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x47] lapic_id[0x8e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x48] lapic_id[0x90] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x49] lapic_id[0x92] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4a] lapic_id[0x94] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4b] lapic_id[0x96] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4c] lapic_id[0x98] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4d] lapic_id[0x9a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4e] lapic_id[0x9c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x4f] lapic_id[0x9e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x50] lapic_id[0xa0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x51] lapic_id[0xa2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x52] lapic_id[0xa4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x53] lapic_id[0xa6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x54] lapic_id[0xa8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x55] lapic_id[0xaa] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x56] lapic_id[0xac] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x57] lapic_id[0xae] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x58] lapic_id[0xb0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x59] lapic_id[0xb2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5a] lapic_id[0xb4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5b] lapic_id[0xb6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5c] lapic_id[0xb8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5d] lapic_id[0xba] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5e] lapic_id[0xbc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x5f] lapic_id[0xbe] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x60] lapic_id[0xc0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x61] lapic_id[0xc2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x62] lapic_id[0xc4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x63] lapic_id[0xc6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x64] lapic_id[0xc8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x65] lapic_id[0xca] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x66] lapic_id[0xcc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x67] lapic_id[0xce] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x68] lapic_id[0xd0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x69] lapic_id[0xd2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6a] lapic_id[0xd4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6b] lapic_id[0xd6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6c] lapic_id[0xd8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6d] lapic_id[0xda] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6e] lapic_id[0xdc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x6f] lapic_id[0xde] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x70] lapic_id[0xe0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x71] lapic_id[0xe2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x72] lapic_id[0xe4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x73] lapic_id[0xe6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x74] lapic_id[0xe8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x75] lapic_id[0xea] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x76] lapic_id[0xec] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x77] lapic_id[0xee] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x78] lapic_id[0xf0] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x79] lapic_id[0xf2] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7a] lapic_id[0xf4] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7b] lapic_id[0xf6] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7c] lapic_id[0xf8] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7d] lapic_id[0xfa] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7e] lapic_id[0xfc] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x7f] lapic_id[0xfe] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ5 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ10 used by override.
[    0.000000] ACPI: IRQ11 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] smpboot: Allowing 128 CPUs, 126 hotplug CPUs
[    0.000000] nr_irqs_gsi: 64
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 000000000d258000 - 000000000d259000
[    0.000000] PM: Registered nosave memory: 000000000d267000 - 000000000d268000
[    0.000000] PM: Registered nosave memory: 000000000d94e000 - 000000000d960000
[    0.000000] PM: Registered nosave memory: 000000000d960000 - 000000000d98f000
[    0.000000] PM: Registered nosave memory: 000000000f15f000 - 000000000f1b7000
[    0.000000] PM: Registered nosave memory: 000000000f1b7000 - 000000000f1bf000
[    0.000000] PM: Registered nosave memory: 000000000f1bf000 - 000000000f1c3000
[    0.000000] e820: [mem 0x0f800000-0xffffffff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:128
nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88000a800000 s84800 r8192
d21696 u131072
[    0.000000] pcpu-alloc: s84800 r8192 d21696 u131072 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 000 001 002 003 004 005 006 007 008 009 010 011
012 013 014 015
[    0.000000] pcpu-alloc: [0] 016 017 018 019 020 021 022 023 024 025 026 027
028 029 030 031
[    0.000000] pcpu-alloc: [0] 032 033 034 035 036 037 038 039 040 041 042 043
044 045 046 047
[    0.000000] pcpu-alloc: [0] 048 049 050 051 052 053 054 055 056 057 058 059
060 061 062 063
[    0.000000] pcpu-alloc: [0] 064 065 066 067 068 069 070 071 072 073 074 075
076 077 078 079
[    0.000000] pcpu-alloc: [0] 080 081 082 083 084 085 086 087 088 089 090 091
092 093 094 095
[    0.000000] pcpu-alloc: [0] 096 097 098 099 100 101 102 103 104 105 106 107
108 109 110 111
[    0.000000] pcpu-alloc: [0] 112 113 114 115 116 117 118 119 120 121 122 123
124 125 126 127
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total
pages: 60287
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: root=/dev/xvda1 loglevel=10 earlyprintk=xen
console=ttyS0 console=hvc0 console=tty1 console=tty0
[    0.000000] PID hash table entries: 1024 (order: 1, 8192 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Calgary: detecting Calgary via BIOS EBDA area
[    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[    0.000000] Memory: 172924k/253952k available (7422k kernel code, 1048k
absent, 79980k reserved, 5713k data, 1004k init)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=128.
[    0.000000] NR_IRQS:33024 nr_irqs:2112 16
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty1] enabled
[    0.000000] console [hvc0] enabled
[    0.000000] console [ttyS0] enabled
[    0.000000] hpet clockevent registered
[    0.000000] tsc: Detected 2131.278 MHz processor
[    0.016000] Calibrating delay loop (skipped), value calculated using timer
frequency.. 4262.55 BogoMIPS (lpj=8525112)
[    0.036016] pid_max: default: 131072 minimum: 1024
[    0.048045] init_memory_mapping: [mem 0x0d960000-0x0d961fff]
[    0.060016]  [mem 0x0d960000-0x0d961fff] page 4k
[    0.068079] init_memory_mapping: [mem 0x0d962000-0x0d979fff]
[    0.080016]  [mem 0x0d962000-0x0d979fff] page 4k
[    0.092060] init_memory_mapping: [mem 0x0d97a000-0x0d98efff]
[    0.104015]  [mem 0x0d97a000-0x0d98efff] page 4k
[    0.112063] init_memory_mapping: [mem 0x0f15f000-0x0f18efff]
[    0.124017]  [mem 0x0f15f000-0x0f18efff] page 4k
[    0.136060] init_memory_mapping: [mem 0x0f18f000-0x0f1b2fff]
[    0.148015]  [mem 0x0f18f000-0x0f1b2fff] page 4k
[    0.165158] Security Framework initialized
[    0.172018] AppArmor: AppArmor disabled by boot time parameter
[    0.184374] Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
[    0.200284] Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
[    0.216101] Mount-cache hash table entries: 256
[    0.224650] Initializing cgroup subsys devices
[    0.236018] Initializing cgroup subsys freezer
[    0.244017] Initializing cgroup subsys net_cls
[    0.256018] Initializing cgroup subsys blkio
[    0.264016] Initializing cgroup subsys perf_event
[    0.276212] CPU: Physical Processor ID: 0
[    0.284015] CPU: Processor Core ID: 0
[    0.292019] mce: CPU supports 2 MCE banks
[    0.300066] Last level iTLB entries: 4KB 128, 2MB 4, 4MB 4
[    0.300066] Last level dTLB entries: 4KB 256, 2MB 0, 4MB 32
[    0.300066] tlb_flushall_shift: -1
[    0.332452] Freeing SMP alternatives: 20k freed
[    0.346063] ACPI: Core revision 20130328
[    0.366616] ACPI: All ACPI Tables successfully acquired
[    0.383369] Switched APIC routing to physical flat.
[    0.397018] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.449580] smpboot: CPU0: Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
(fam: 06, model: 0f, stepping: 06)
[    0.471351] Xen: using vcpuop timer interface
[    0.480023] installing Xen timer for CPU 0
[    0.488336] Performance Events: unsupported p6 CPU model 15 no PMU driver,
software events only.
[    0.503184] NMI watchdog: disabled (cpu0): hardware events not enabled
[    0.504251] installing Xen timer for CPU 1
[    0.508283] smpboot: Booting Node   0, Processors  #1
[    0.526426] Brought up 2 CPUs
[    0.528025] smpboot: Total of 2 processors activated (8525.11 BogoMIPS)
[    0.534294] devtmpfs: initialized
[    0.539642] PM: Registering ACPI NVS region [mem 0x0f1bf000-0x0f1c2fff]
(16384 bytes)
[    0.540459] xor: measuring software checksum speed
[    0.584020]    prefetch64-sse:   936.000 MB/sec
[    0.628020]    generic_sse:   923.000 MB/sec
[    0.632020] xor: using function: prefetch64-sse (936.000 MB/sec)
[    0.636240] regulator-dummy: no parameters
[    0.640281] NET: Registered protocol family 16
[    0.644428] xs_reset_watches failed: -38
[    0.648374] ACPI: bus type PCI registered
[    0.652023] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.656171] dca service started, version 1.12.1
[    0.660441] PCI: Using configuration type 1 for base access
[    0.666950] bio: create slab <bio-0> at 0
[    0.736029] raid6: sse2x1    3100 MB/s
[    0.808025] raid6: sse2x2    3333 MB/s
[    0.880032] raid6: sse2x4    4510 MB/s
[    0.884020] raid6: using algorithm sse2x4 (4510 MB/s)
[    0.888022] raid6: using ssse3x2 recovery algorithm
[    0.892365] ACPI: Added _OSI(Module Device)
[    0.896023] ACPI: Added _OSI(Processor Device)
[    0.900021] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.904022] ACPI: Added _OSI(Processor Aggregator Device)
[    0.911144] ACPI: EC: Look up EC in DSDT
[    0.922511] ACPI: Interpreter enabled
[    0.924030] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State
[\_S1_] (20130328/hwxface-568)
[    0.936024] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State
[\_S2_] (20130328/hwxface-568)
[    0.948039] ACPI: (supports S0 S3 S4 S5)
[    0.952020] ACPI: Using IOAPIC for interrupt routing
[    0.956080] PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
[    0.994658] ACPI: No dock devices found.
[    1.099635] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    1.100191] acpi PNP0A03:00: fail to add MMCONFIG information, can''t
access extended PCI configuration space under this bridge.
[    1.104144] acpiphp: Slot [0] registered
[    1.108625] acpiphp: Slot [1] registered
[    1.112605] acpiphp: Slot [2] registered
[    1.116631] acpiphp: Slot [3] registered
[    1.120616] acpiphp: Slot [4] registered
[    1.124618] acpiphp: Slot [5] registered
[    1.128652] acpiphp: Slot [6] registered
[    1.132622] acpiphp: Slot [7] registered
[    1.136655] acpiphp: Slot [8] registered
[    1.140642] acpiphp: Slot [9] registered
[    1.144716] acpiphp: Slot [10] registered
[    1.148673] acpiphp: Slot [11] registered
[    1.152622] acpiphp: Slot [12] registered
[    1.156634] acpiphp: Slot [13] registered
[    1.160646] acpiphp: Slot [14] registered
[    1.164641] acpiphp: Slot [15] registered
[    1.168630] acpiphp: Slot [16] registered
[    1.172661] acpiphp: Slot [17] registered
[    1.176626] acpiphp: Slot [18] registered
[    1.180619] acpiphp: Slot [19] registered
[    1.184686] acpiphp: Slot [20] registered
[    1.188625] acpiphp: Slot [21] registered
[    1.192617] acpiphp: Slot [22] registered
[    1.196625] acpiphp: Slot [23] registered
[    1.200601] acpiphp: Slot [24] registered
[    1.204587] acpiphp: Slot [25] registered
[    1.208616] acpiphp: Slot [26] registered
[    1.212663] acpiphp: Slot [27] registered
[    1.216631] acpiphp: Slot [28] registered
[    1.220623] acpiphp: Slot [29] registered
[    1.224675] acpiphp: Slot [30] registered
[    1.228655] acpiphp: Slot [31] registered
[    1.232599] PCI host bridge to bus 0000:00
[    1.236027] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.240025] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    1.244027] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    1.248024] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    1.252025] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
[    1.256279] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[    1.262599] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[    1.267158] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[    1.288023] pci 0000:00:01.1: reg 20: [io  0xc200-0xc20f]
[    1.301320] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
[    1.306711] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4
ACPI
[    1.308125] pci 0000:00:01.3: quirk: [io  0xb100-0xb10f] claimed by PIIX4 SMB
[    1.313586] pci 0000:00:02.0: [1013:00b8] type 00 class 0x030000
[    1.323760] pci 0000:00:02.0: reg 10: [mem 0x80000000-0x81ffffff pref]
[    1.328024] pci 0000:00:02.0: reg 14: [mem 0x83001000-0x83001fff]
[    1.352022] pci 0000:00:02.0: reg 30: [mem 0xffff0000-0xffffffff pref]
[    1.356817] pci 0000:00:03.0: [5853:0001] type 00 class 0xff8000
[    1.368024] pci 0000:00:03.0: reg 10: [io  0xc100-0xc1ff]
[    1.380023] pci 0000:00:03.0: reg 14: [mem 0x82000000-0x82ffffff pref]
[    1.426397] acpi PNP0A03:00: ACPI _OSC support notification failed, disabling
PCIe ASPM
[    1.428026] acpi PNP0A03:00: Unable to request _OSC control (_OSC support
mask: 0x08)
[    1.432427] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11)
[    1.440224] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
[    1.448226] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11)
[    1.456236] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11)
[    1.495647] ACPI: Enabled 2 GPEs in block 00 to 0F
[    1.496032] acpi root: \_SB_.PCI0 notify handler is installed
[    1.500211] Found 1 acpi root devices
[    1.504152] xen/balloon: Initialising balloon driver.
[    1.508217] xen-balloon: Initialising balloon driver.
[    1.512141] vgaarb: device added:
PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    1.516022] vgaarb: loaded
[    1.520018] vgaarb: bridge control possible 0000:00:02.0
[    1.524294] SCSI subsystem initialized
[    1.528023] ACPI: bus type ATA registered
[    1.532241] libata version 3.00 loaded.
[    1.536093] pps_core: LinuxPPS API ver. 1 registered
[    1.540022] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo
Giometti <giometti@linux.it>
[    1.544036] PTP clock support registered
[    1.548169] PCI: Using ACPI for IRQ routing
[    1.552021] PCI: pci_cache_line_size set to 64 bytes
[    1.556292] pci 0000:00:02.0: no compatible bridge window for [mem
0x80000000-0x81ffffff pref]
[    1.560024] pci 0000:00:02.0: no compatible bridge window for [mem
0x83001000-0x83001fff]
[    1.564118] pci 0000:00:03.0: no compatible bridge window for [mem
0x82000000-0x82ffffff pref]
[    1.568345] e820: reserve RAM buffer [mem 0x0d258018-0x0fffffff]
[    1.572022] e820: reserve RAM buffer [mem 0x0d94e000-0x0fffffff]
[    1.576023] e820: reserve RAM buffer [mem 0x0f15f000-0x0fffffff]
[    1.580027] e820: reserve RAM buffer [mem 0x0f800000-0x0fffffff]
[    1.584477] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[    1.588050] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    1.594507] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    1.599142] Switching to clocksource xen
[    1.605585] pnp: PnP ACPI init
[    1.612193] ACPI: bus type PNP registered
[    1.620749] pnp 00:00: disabling [mem 0x00000000-0x0009ffff] because it
overlaps 0000:00:02.0 BAR 0 [mem 0x00000000-0x01ffffff pref]
[    1.645190] pnp 00:00: disabling [mem 0x00000000-0x0009ffff disabled] because
it overlaps 0000:00:03.0 BAR 1 [mem 0x00000000-0x00ffffff pref]
[    1.671839] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[    1.685956] pnp 00:01: Plug and Play ACPI device, IDs PNP0103 (active)
[    1.699746] system 00:02: [io  0x08a0-0x08a3] has been reserved
[    1.712399] system 00:02: [io  0x0cc0-0x0ccf] has been reserved
[    1.724695] system 00:02: [io  0x04d0-0x04d1] has been reserved
[    1.737078] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[    1.751649] pnp 00:03: [dma 4]
[    1.758382] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)
[    1.772147] xen: --> pirq=16 -> irq=8 (gsi=8)
[    1.781429] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)
[    1.795434] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)
[    1.809035] xen: --> pirq=17 -> irq=12 (gsi=12)
[    1.818562] pnp 00:06: Plug and Play ACPI device, IDs PNP0f13 (active)
[    1.832430] xen: --> pirq=18 -> irq=1 (gsi=1)
[    1.841976] pnp 00:07: Plug and Play ACPI device, IDs PNP0303 PNP030b
(active)
[    1.856768] xen: --> pirq=19 -> irq=6 (gsi=6)
[    1.866014] pnp 00:08: [dma 2]
[    1.872599] pnp 00:08: Plug and Play ACPI device, IDs PNP0700 (active)
[    1.886430] xen: --> pirq=20 -> irq=4 (gsi=4)
[    1.895905] pnp 00:09: Plug and Play ACPI device, IDs PNP0501 (active)
[    1.910075] xen: --> pirq=21 -> irq=7 (gsi=7)
[    1.919324] pnp 00:0a: Plug and Play ACPI device, IDs PNP0400 (active)
[    1.933213] system 00:0b: [io  0x10c0-0x1141] has been reserved
[    1.945278] system 00:0b: [io  0xb044-0xb047] has been reserved
[    1.957795] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (active)
[    2.002091] pnp: PnP ACPI: found 12 devices
[    2.010855] ACPI: bus type PNP unregistered
[    2.033043] pci 0000:00:02.0: no compatible bridge window for [mem
0xffff0000-0xffffffff pref]
[    2.051233] pci 0000:00:02.0: BAR 0: assigned [mem 0xf0000000-0xf1ffffff
pref]
[    2.075939] pci 0000:00:03.0: BAR 1: assigned [mem 0xf2000000-0xf2ffffff
pref]
[    2.095317] pci 0000:00:02.0: BAR 6: assigned [mem 0xf3000000-0xf300ffff
pref]
[    2.110471] pci 0000:00:02.0: BAR 1: assigned [mem 0xf3010000-0xf3010fff]
[    2.128572] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    2.140163] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    2.152051] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    2.165376] pci_bus 0000:00: resource 7 [mem 0xf0000000-0xfbffffff]
[    2.178590] NET: Registered protocol family 2
[    2.188477] TCP established hash table entries: 2048 (order: 3, 32768 bytes)
[    2.203525] TCP bind hash table entries: 2048 (order: 3, 32768 bytes)
[    2.217308] TCP: Hash tables configured (established 2048 bind 2048)
[    2.231006] TCP: reno registered
[    2.238176] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    2.250400] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    2.263776] NET: Registered protocol family 1
[    2.273456] RPC: Registered named UNIX socket transport module.
[    2.285853] RPC: Registered udp transport module.
[    2.295391] RPC: Registered tcp transport module.
[    2.305489] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    2.319365] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    2.332201] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    2.344598] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    2.357695] pci 0000:00:02.0: Boot video device
[    2.367518] PCI: CLS 0 bytes, default 64
[    2.376871] audit: initializing netlink socket (disabled)
[    2.388310] type=2000 audit(1382108399.061:1): initialized
[    2.431647] bounce pool size: 64 pages
[    2.439845] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    2.454463] VFS: Disk quotas dquot_6.5.2
[    2.463000] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    2.477652] NFS: Registering the id_resolver key type
[    2.488532] Key type id_resolver registered
[    2.496996] Key type id_legacy registered
[    2.505408] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[    2.519036] NTFS driver 2.1.30 [Flags: R/W].
[    2.528098] msgmni has been set to 427
[    2.538007] alg: No test for stdrng (krng)
[    2.546763] async_tx: api initialized (async)
[    2.556131] Block layer SCSI generic (bsg) driver version 0.4 loaded (major
250)
[    2.571741] io scheduler noop registered
[    2.580127] io scheduler deadline registered
[    2.589296] io scheduler cfq registered (default)
[    2.599721] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    2.611740] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    2.626110] efifb: probing for efifb
[    2.633970] efifb: framebuffer at 0x80000000, mapped to 0xffffc90000100000,
using 1876k, total 1875k
[    2.653264] efifb: mode is 800x600x32, linelength=3200, pages=1
[    2.666000] efifb: scrolling: redraw
[    2.673718] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    2.688479] Console: switching to colour frame buffer device 100x37
[    2.704381] fb0: EFI VGA frame buffer device
[    2.713781] intel_idle: does not run on family 6 model 15
[    2.725237] GHES: HEST is not enabled!
[    2.733131] ioatdma: Intel(R) QuickData Technology Driver 4.00
[    2.745752] Event-channel device installed.
[    2.755367] xen: --> pirq=22 -> irq=28 (gsi=28)
[    2.764982] Grant tables using version 1 layout.
[    2.777848] Grant table initialized
[    2.789859] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    2.835495] 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    2.848826] Linux agpgart interface v0.103
[    2.859905] loop: module loaded
[    2.874093] Loading iSCSI transport class v2.0-870.
[    2.887071] bnx2fc: Broadcom NetXtreme II FCoE Driver bnx2fc v1.0.14 (Mar 08,
2013)
[    2.905645] blkfront: xvda: flush diskcache: enabled using persistent grants
[    2.905693] iscsi: registered transport (tcp)
[    2.905754] Adaptec aacraid driver 1.2-0[30200]-ms
[    2.964625] qla2xxx [0000:00:00.0]-0005: : QLogic Fibre Channel HBA Driver:
8.05.00.03-k.
[    2.969833]  xvda: xvda1 xvda2
[    2.970549] Setting capacity to 33554432
[    2.970555] xvda: detected capacity change from 0 to 17179869184
[    3.016758] iscsi: registered transport (qla4xxx)
[    3.028244] QLogic iSCSI HBA Driver
[    3.037135] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST
2006)
[    3.054230] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006)
[    3.070207] megasas: 06.506.00.00-rc1 Sat. Feb. 9 17:00:00 PDT 2013
[    3.084713] mpt2sas version 14.100.00.00 loaded
[    3.095852] mpt3sas version 01.100.01.00 loaded
[    3.107112] Broadcom NetXtreme II iSCSI Driver bnx2i v2.7.2.2 (Apr 25, 2012)
[    3.123488] iscsi: registered transport (bnx2i)
[    3.134669] st: Version 20101219, fixed bufsize 32768, s/g segs 256
[    3.149024] osst :I: Tape driver with OnStream support version 0.99.4
[    3.149024] osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $
[    3.178255] SCSI Media Changer driver v0.25 
[    3.188543] osd: LOADED open-osd 0.2.1
[    3.197969] ata_piix 0000:00:01.1: version 2.13
[    3.209314] ata_piix 0000:00:01.1: setting latency timer to 64
[    3.224149] scsi0 : ata_piix
[    3.232282] scsi1 : ata_piix
[    3.239917] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc200 irq 14
[    3.255506] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc208 irq 15
[    3.270851] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[    3.287753] eql: Equalizer2002: Simon Janes (simon@ncm.com) and David S.
Miller (davem@redhat.com)
[    3.309304] tun: Universal TUN/TAP device driver, 1.6
[    3.321404] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    3.336041] cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.16 (Dec 05,
2012)
[    3.353100] bnx2x: Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit Ethernet
Driver bnx2x 1.78.17-0 (2013/04/11)
[    3.376213] tsc: Refined TSC clocksource calibration: 2131.280 MHz
[    3.391677] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[    3.405941] e100: Copyright(c) 1999-2006 Intel Corporation
[    3.418997] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[    3.435253] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    3.448955] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    3.453220] ata2.01: NODEV after polling detection
[    3.458122] ata2.00: ATAPI: QEMU DVD-ROM, 1.3.1, max UDMA/100
[    3.464501] ata2.00: configured for MWDMA2
[    3.500250] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
[    3.515596] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.3-k
[    3.531763] igb: Copyright (c) 2007-2013 Intel Corporation.
[    3.531814] scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     1.3.
PQ: 0 ANSI: 5
[    3.564003] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version
2.0.2-k
[    3.582826] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    3.597374] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version
3.13.10-k
[    3.615406] ixgbe: Copyright (c) 1999-2013 Intel Corporation.
[    3.615448] sr0: scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[    3.615469] cdrom: Uniform CD-ROM driver Revision: 3.20
[    3.615701] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    3.616899] sr 1:0:0:0: Attached scsi generic sg0 type 5
[    3.679125] ixgb: Intel(R) PRO/10GbE Network Driver - version 1.0.135-k2-NAPI
[    3.695646] ixgb: Copyright (c) 1999-2008 Intel Corporation.
[    3.709058] Initialising Xen virtual ethernet driver.
[    3.727646] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at
0x60,0x64 irq 1,12
[    3.751934] serio: i8042 KBD port at 0x60,0x64 irq 1
[    3.764340] serio: i8042 AUX port at 0x60,0x64 irq 12
[    3.777402] mousedev: PS/2 mouse device common for all mice
[    3.812980] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input0
[    3.831875] input: Xen Virtual Keyboard as /devices/virtual/input/input1
[    3.847279] input: Xen Virtual Pointer as /devices/virtual/input/input2
[    3.865896] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[    3.881453] rtc_cmos 00:04: alarms up to one day, 114 bytes nvram, hpet irqs
[    3.897797] md: linear personality registered for level -1
[    3.911058] md: raid0 personality registered for level 0
[    3.923673] md: raid1 personality registered for level 1
[    3.936219] md: raid10 personality registered for level 10
[    3.949131] md: raid6 personality registered for level 6
[    3.961740] md: raid5 personality registered for level 5
[    3.974178] md: raid4 personality registered for level 4
[    3.986618] md: multipath personality registered for level -4
[    4.000254] md: faulty personality registered for level -5
[    4.013241] device-mapper: uevent: version 1.0.3
[    4.024741] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised:
dm-devel@redhat.com
[    4.044903] device-mapper: multipath: version 1.5.1 loaded
[    4.057949] device-mapper: multipath round-robin: version 1.0.0 loaded
[    4.073072] device-mapper: multipath queue-length: version 0.1.0 loaded
[    4.088333] device-mapper: multipath service-time: version 0.2.0 loaded
[    4.103543] device-mapper: dm-log-userspace: version 1.1.0 loaded
[    4.117545] device-mapper: raid: Loading target version 1.5.0
[    4.130801] cpuidle: using governor ladder
[    4.140751] cpuidle: using governor menu
[    4.150319] drop_monitor: Initializing network drop monitor service
[    4.165267] ipip: IPv4 over IPv4 tunneling driver
[    4.176636] gre: GRE over IPv4 demultiplexor driver
[    4.188181] ip_gre: GRE over IPv4 tunneling driver
[    4.199837] TCP: cubic registered
[    4.208110] Initializing XFRM netlink socket
[    4.218331] NET: Registered protocol family 10
[    4.229991] mip6: Mobile IPv6
[    4.237610] NET: Registered protocol family 17
[    4.248218] NET: Registered protocol family 15
[    4.258727] Bridge firewalling registered
[    4.268411] Key type dns_resolver registered
[    4.279573] PM: Hibernation image not present or could not be loaded.
[    4.293972] registered taskstats version 1
[    4.304799] console [netcon0] enabled
[    4.313436] netconsole: network logging started
[    4.324026] rtc_cmos 00:04: setting system clock to 2013-10-18 15:00:01 UTC
(1382108401)
[    4.342219] md: Waiting for all devices to be available before autodetect
[    4.357587] md: If you don''t use raid, use raid=noautodetect
[    4.371127] md: Autodetecting RAID arrays.
[    4.381023] md: Scanned 0 and added 0 devices.
[    4.391537] md: autorun ...
[    4.398628] md: ... autorun DONE.
[    4.408099] EXT3-fs (xvda1): recovery required on readonly filesystem
[    4.423185] EXT3-fs (xvda1): write access will be enabled during recovery
[    4.599042] kjournald starting.  Commit interval 5 seconds
[    4.648627] EXT3-fs (xvda1): recovery complete
[    4.659404] EXT3-fs (xvda1): mounted filesystem with ordered data mode
[    4.674756] VFS: Mounted root (ext3 filesystem) readonly on device 202:1.
[    4.692246] Freeing unused kernel memory: 1004k freed
[    4.704929] Write protecting the kernel read-only data: 12288k
[    4.721487] Freeing unused kernel memory: 760k freed
[    4.737113] Freeing unused kernel memory: 1084k freed
[   10.060882] EXT3-fs (xvda1): using internal journal
[   12.850499] svc: failed to register lockdv1 RPC service (errno 97).
[   12.866469] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery
directory
[   12.893409] NFSD: starting 90-second grace period (net ffffffff81cabcc0)
[   14.209140] sshd (1181): /proc/1181/oom_adj is deprecated, please use
/proc/1181/oom_score_adj instead.

Wei Liu

2013-Nov-01 12:21 UTC

head link

Re: Limitation in HVM physmap

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

George Dunlap

2013-Nov-01 12:26 UTC

head link

Re: Limitation in HVM physmap

On 01/11/13 12:21, Wei Liu wrote:> 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.
Good to know - thanks for testing this.  So it looks like we''ll need to
support the same functionality for HVM guests, one way or another.

  -George

Ian Campbell

2013-Nov-01 12:33 UTC

head link

Re: Limitation in HVM physmap

On Fri, 2013-11-01 at 12:21 +0000, Wei Liu wrote:> 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.
I''m not sure you can draw too many conclusions wrt the behaviour on the
emulated cirrus though.

This devices seems to have three memory bars? Whereas the Cirrus card
has only 2.

The original problem was that the Cirrus card was being accessed at two
distinct locations, where is that happening here? I can only see
0xd5800000 being used.

The cirrus card also differs in that the address reported by efifb
(0x80000000) does not match either of the BARS configured on the Cirrus
card (0xf000000 and 0xf3xxxx). Whereas here efifb is using the first
memory BAR of the matrox card, which is logical.

So where does the discrepancy between the efifb view and the Cirrus
device''s view come from? Does OVMF contain a cirrus driver or is it
using a generic (e.g. stdvga driver)? Where does it get this address
0x80000000 from and why does it think it maps to the Cirrus device?

Looking back at an earlier mail:
> During OVMF initialization:
> 
> (d28) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> (d28) Type =   Io16; Base = 0xC000;     Length = 0x1000;        Alignment =
0xFFF
> (d28)  Base = 0xC000;   Length = 0x100; Alignment = 0xFF;       Owner = PCI
[00|04|
> (d28)  Base = 0xC100;   Length = 0x100; Alignment = 0xFF;       Owner = PCI
[00|03|
> (d28)  Base = 0xC200;   Length = 0x10;  Alignment = 0xF;        Owner = PCI
[00|01|
> (d28) Type =  Mem32; Base = 0x80000000; Length = 0x3100000;     Alignment =
0x1FFFFF
> (d28)  Base = 0x80000000;       Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owne
> (d28) |02|00:10] 
This seems to show that 0x80000000 is a bar on the PCI root bridge, not
the Cirrus device. Could that be the root (no pun intended) of the
confusion?

The rest of that mail also had this:
> Later when Linux loads EFIFB driver:
> [    2.628264] efifb: framebuffer at 0x80000000, mapped to
> 0xffffc90000100000, using 1876k, total 1875k
> [    2.646827] efifb: mode is 800x600x32, linelength=3200, pages=1
> [    2.658833] efifb: scrolling: redraw
> [    2.666342] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> 0xf0000000 is mapped by:
> 
> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA
controller])
>         Subsystem: Red Hat, Inc Device 1100
>         Physical Slot: 2
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0
>         Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
>         Region 1: Memory at f3010000 (32-bit, non-prefetchable) [size=4K]
>         Expansion ROM at f3000000 [disabled] [size=64K]
There seems to be a disconnect between what the efifb is discovering and
how the actual hardware is configured.

Ian.

Wei Liu

2013-Nov-01 12:45 UTC

head link

Re: Limitation in HVM physmap

On Fri, Nov 01, 2013 at 12:33:28PM +0000, Ian Campbell wrote:
[...]> > 
> > So I think the behavior of OVMF is consistent with real hardware.
> 
> I''m not sure you can draw too many conclusions wrt the behaviour
on the
> emulated cirrus though.
> 
> This devices seems to have three memory bars? Whereas the Cirrus card
> has only 2.
> 
> The original problem was that the Cirrus card was being accessed at two
> distinct locations, where is that happening here? I can only see
> 0xd5800000 being used.
> 
Good catch. I only noticed that efifb is probably using the mapped
location.
> The cirrus card also differs in that the address reported by efifb
> (0x80000000) does not match either of the BARS configured on the Cirrus
> card (0xf000000 and 0xf3xxxx). Whereas here efifb is using the first
> memory BAR of the matrox card, which is logical.
> 
> So where does the discrepancy between the efifb view and the Cirrus
> device''s view come from? Does OVMF contain a cirrus driver or is
it
Yes, it has a cirrus driver.
> using a generic (e.g. stdvga driver)? Where does it get this address
> 0x80000000 from and why does it think it maps to the Cirrus device?
> 
Snippet from the full log:
(d1) PlatformBdsInit
(d1) Registered NotifyDevPath Event
(d1) PlatformBdsPolicyBehavior
(d1) PCI Bus First Scanning
(d1) PciBus: Discovered PCI @ [00|00|00]
(d1)
(d1) PciBus: Discovered PCI @ [00|01|00]
(d1)
(d1) PciBus: Discovered PCI @ [00|01|01]
(d1)    BAR[4]: Type =   Io32; Alignment = 0xF; Length = 0x10;  Offset = 0x20
(d1)
(d1) PciBus: Discovered PCI @ [00|01|03]
(d1)
(d1) PciBus: Discovered PCI @ [00|02|00]
(d1)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length = 0x2000000;    
Offset = 0
(d1) x10
(d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x1000;       
Offset = 0x14
(d1)
(d1) PciBus: Discovered PCI @ [00|03|00]
(d1)    BAR[0]: Type =   Io32; Alignment = 0xFF;        Length = 0x100; Offset =
0x10
(d1)    BAR[1]: Type = PMem32; Alignment = 0xFFFFFF;    Length = 0x1000000;    
Offset = 0x
(d1) 14
(d1)
(d1) PciBus: Discovered PCI @ [00|04|00]
(d1)    BAR[0]: Type =   Io32; Alignment = 0xFF;        Length = 0x100; Offset =
0x10
(d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x100; Offset =
0x14
(d1)
(d1) PciBus: Discovered PCI @ [00|00|00]
(d1)
(d1) PciBus: Discovered PCI @ [00|01|00]
(d1)
(d1) PciBus: Discovered PCI @ [00|01|01]
(d1)    BAR[4]: Type =   Io32; Alignment = 0xF; Length = 0x10;  Offset = 0x20
(d1)
(d1) PciBus: Discovered PCI @ [00|01|03]
(d1)
(d1) PciBus: Discovered PCI @ [00|02|00]
(d1)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length = 0x2000000;    
Offset = 0
(d1) x10
(d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x1000;       
Offset = 0x14
(d1)
(d1) PciBus: Discovered PCI @ [00|03|00]
(d1)    BAR[0]: Type =   Io32; Alignment = 0xFF;        Length = 0x100; Offset =
0x10
(d1)    BAR[1]: Type = PMem32; Alignment = 0xFFFFFF;    Length = 0x1000000;    
Offset = 0x
(d1) 14
(d1)
(d1) PciBus: Discovered PCI @ [00|04|00]
(d1)    BAR[0]: Type =   Io32; Alignment = 0xFF;        Length = 0x100; Offset =
0x10
(d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x100; Offset =
0x14
(d1)
(d1) PciBus: HostBridge->SubmitResources() - Success
(d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
[  403.936062] xenbr0: port 3(vif1.0-emu) entered forwarding state
(d1) PciBus: Resource Map for Root Bridge PciRoot(0x0)
(d1) Type =   Io16; Base = 0xC000;      Length = 0x1000;        Alignment =
0xFFF
(d1)  Base = 0xC000;    Length = 0x100; Alignment = 0xFF;       Owner = PCI 
[00|04|00:10]
(d1)  Base = 0xC100;    Length = 0x100; Alignment = 0xFF;       Owner = PCI 
[00|03|00:10]
(d1)  Base = 0xC200;    Length = 0x10;  Alignment = 0xF;        Owner = PCI 
[00|01|01:20]
(d1) Type =  Mem32; Base = 0x80000000;  Length = 0x3100000;     Alignment =
0x1FFFFFF
(d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment = 0x1FFFFFF; 
Owner = PCI  [00
(d1) |02|00:10]
(d1)  Base = 0x82000000;        Length = 0x1000000;     Alignment = 0xFFFFFF;  
Owner = PCI  [00|
(d1) 03|00:14]
(d1)  Base = 0x83000000;        Length = 0x100; Alignment = 0xFFF;      Owner =
PCI  [00|04|00:1
(d1) 4]
(d1)  Base = 0x83001000;        Length = 0x1000;        Alignment = 0xFFF;     
Owner = PCI  [00|02|00:
(d1) 14]


Looks like OVMF does something tricky and doesn''t propogate the change
to Xen?

Wei.

Ian Campbell

2013-Nov-01 12:49 UTC

head link

Re: Limitation in HVM physmap

On Fri, 2013-11-01 at 12:45 +0000, Wei Liu wrote:> On Fri, Nov 01, 2013 at 12:33:28PM +0000, Ian Campbell wrote:
> [...]
> > > 
> > > So I think the behavior of OVMF is consistent with real hardware.
> > 
> > I''m not sure you can draw too many conclusions wrt the
behaviour on the
> > emulated cirrus though.
> > 
> > This devices seems to have three memory bars? Whereas the Cirrus card
> > has only 2.
> > 
> > The original problem was that the Cirrus card was being accessed at
two
> > distinct locations, where is that happening here? I can only see
> > 0xd5800000 being used.
> > 
> 
> Good catch. I only noticed that efifb is probably using the mapped
> location.
> 
> > The cirrus card also differs in that the address reported by efifb
> > (0x80000000) does not match either of the BARS configured on the
Cirrus
> > card (0xf000000 and 0xf3xxxx). Whereas here efifb is using the first
> > memory BAR of the matrox card, which is logical.
> > 
> > So where does the discrepancy between the efifb view and the Cirrus
> > device''s view come from? Does OVMF contain a cirrus driver or
is it
> 
> Yes, it has a cirrus driver.
> 
> > using a generic (e.g. stdvga driver)? Where does it get this address
> > 0x80000000 from and why does it think it maps to the Cirrus device?
> > 
> 
> Snippet from the full log:
[...]> (d1) PciBus: Discovered PCI @ [00|02|00]
> (d1)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length = 0x2000000;
Offset = 0
> (d1) x10
> (d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x1000;   
Offset = 0x14
This is the cirrus device, I think?

I don''t see any mention of either 0xf0000000 or 0x80000000 here.
> (d1) PciBus: HostBridge->SubmitResources() - Success
> (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
> [  403.936062] xenbr0: port 3(vif1.0-emu) entered forwarding state
> (d1) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> (d1) Type =   Io16; Base = 0xC000;      Length = 0x1000;        Alignment =
0xFFF
> (d1)  Base = 0xC000;    Length = 0x100; Alignment = 0xFF;       Owner = PCI
[00|04|00:10]
> (d1)  Base = 0xC100;    Length = 0x100; Alignment = 0xFF;       Owner = PCI
[00|03|00:10]
> (d1)  Base = 0xC200;    Length = 0x10;  Alignment = 0xF;        Owner = PCI
[00|01|01:20]
> (d1) Type =  Mem32; Base = 0x80000000;  Length = 0x3100000;     Alignment =
0x1FFFFFF
> (d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owner = PCI  [00
> (d1) |02|00:10]
> (d1)  Base = 0x82000000;        Length = 0x1000000;     Alignment =
0xFFFFFF;   Owner = PCI  [00|
> (d1) 03|00:14]
> (d1)  Base = 0x83000000;        Length = 0x100; Alignment = 0xFFF;     
Owner = PCI  [00|04|00:1
> (d1) 4]
> (d1)  Base = 0x83001000;        Length = 0x1000;        Alignment = 0xFFF; 
Owner = PCI  [00|02|00:
> (d1) 14]
> 
> 
> Looks like OVMF does something tricky and doesn''t propogate the
change to Xen?
I''m not sure what you were trying to illustrate with that log, what
tricky thing are you thinking of?

Is OVMF trying to do MMIO reassignment? I think we do this in hvmloader
so you could try turning that behaviour off, if possible.

"propogate changes to Xen" would mean writing various BAR registers,
which are emulated (by qemu I suppose), I wouldn''t expect OVMF to be
propagating things to Xen directly. We could be getting the emulation of
those updates wrong I guess, but surely we''d have noticed it elsewhere
before now?

Ian.

Wei Liu

2013-Nov-01 14:08 UTC

head link

Re: Limitation in HVM physmap

On Fri, Nov 01, 2013 at 12:49:12PM +0000, Ian Campbell
wrote:> On Fri, 2013-11-01 at 12:45 +0000, Wei Liu wrote:
> > On Fri, Nov 01, 2013 at 12:33:28PM +0000, Ian Campbell wrote:
> > [...]
> > > > 
> > > > So I think the behavior of OVMF is consistent with real
hardware.
> > > 
> > > I''m not sure you can draw too many conclusions wrt the
behaviour on the
> > > emulated cirrus though.
> > > 
> > > This devices seems to have three memory bars? Whereas the Cirrus
card
> > > has only 2.
> > > 
> > > The original problem was that the Cirrus card was being accessed
at two
> > > distinct locations, where is that happening here? I can only see
> > > 0xd5800000 being used.
> > > 
> > 
> > Good catch. I only noticed that efifb is probably using the mapped
> > location.
> > 
> > > The cirrus card also differs in that the address reported by
efifb
> > > (0x80000000) does not match either of the BARS configured on the
Cirrus
> > > card (0xf000000 and 0xf3xxxx). Whereas here efifb is using the
first
> > > memory BAR of the matrox card, which is logical.
> > > 
> > > So where does the discrepancy between the efifb view and the
Cirrus
> > > device''s view come from? Does OVMF contain a cirrus
driver or is it
> > 
> > Yes, it has a cirrus driver.
> > 
> > > using a generic (e.g. stdvga driver)? Where does it get this
address
> > > 0x80000000 from and why does it think it maps to the Cirrus
device?
> > > 
> > 
> > Snippet from the full log:
> [...]
> > (d1) PciBus: Discovered PCI @ [00|02|00]
> > (d1)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length =
0x2000000;     Offset = 0
> > (d1) x10
> > (d1)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length =
0x1000;        Offset = 0x14
> 
> This is the cirrus device, I think?
> 
> I don''t see any mention of either 0xf0000000 or 0x80000000 here.
> 
Yes. You can tell from the BDF.

It didn''t print out base address by default. I added my own debug patch
and confirmed that base address was set correctly by hvmloader.

(d9) PciBus: Discovered PCI @ [00|02|00]
(d9)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length = 0x2000000;    
Offset = 0x10        BaseAddress = 0xF0000000
(d9)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x1000; Offset
= 0x14   BaseAddress = 0xF3020000

Sorry about the confusion.
> > (d1) PciBus: HostBridge->SubmitResources() - Success
> > (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
> > [  403.936062] xenbr0: port 3(vif1.0-emu) entered forwarding state
> > (d1) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> > (d1) Type =   Io16; Base = 0xC000;      Length = 0x1000;       
Alignment = 0xFFF
> > (d1)  Base = 0xC000;    Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|04|00:10]
> > (d1)  Base = 0xC100;    Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|03|00:10]
> > (d1)  Base = 0xC200;    Length = 0x10;  Alignment = 0xF;        Owner
= PCI  [00|01|01:20]
> > (d1) Type =  Mem32; Base = 0x80000000;  Length = 0x3100000;    
Alignment = 0x1FFFFFF
> > (d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owner = PCI  [00
> > (d1) |02|00:10]
> > (d1)  Base = 0x82000000;        Length = 0x1000000;     Alignment =
0xFFFFFF;   Owner = PCI  [00|
> > (d1) 03|00:14]
> > (d1)  Base = 0x83000000;        Length = 0x100; Alignment = 0xFFF;    
Owner = PCI  [00|04|00:1
> > (d1) 4]
> > (d1)  Base = 0x83001000;        Length = 0x1000;        Alignment =
0xFFF;      Owner = PCI  [00|02|00:
> > (d1) 14]
> > 
> > 
> > Looks like OVMF does something tricky and doesn''t propogate
the change to Xen?
> 
> I''m not sure what you were trying to illustrate with that log,
what
> tricky thing are you thinking of?
> 
> Is OVMF trying to do MMIO reassignment? I think we do this in hvmloader
> so you could try turning that behaviour off, if possible.
> 
I will see what I can do. My impression was that reassignment process is
mandatory in UEFI but I could be wrong. Real hardware doesn''t behave
like that anyway.
> "propogate changes to Xen" would mean writing various BAR
registers,
> which are emulated (by qemu I suppose), I wouldn''t expect OVMF to
be
> propagating things to Xen directly. We could be getting the emulation of
> those updates wrong I guess, but surely we''d have noticed it
elsewhere
> before now?
> 
Yes, it''s indeed caught by QEMU. And I think QEMU gets the right value.
I''m just not very sure about certain QEMU-specific behavior. I will
investigate that.

Wei.
> Ian.

Ian Campbell

2013-Nov-01 14:12 UTC

head link

Re: Limitation in HVM physmap

On Fri, 2013-11-01 at 14:08 +0000, Wei Liu wrote:> It didn''t print out base address by default. I added my own debug
patch
> and confirmed that base address was set correctly by hvmloader.
> 
> (d9) PciBus: Discovered PCI @ [00|02|00]
> (d9)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length = 0x2000000;
Offset = 0x10        BaseAddress = 0xF0000000
> (d9)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length = 0x1000;
Offset = 0x14   BaseAddress = 0xF3020000
> 
> Sorry about the confusion.
OK, so even OVMF thinks the Cirrus memory range is at 0xf0000000, so
where did efifb get 0x80000000 from?

Ian.

Wei Liu

2013-Nov-01 14:19 UTC

head link

Re: Limitation in HVM physmap

On Fri, Nov 01, 2013 at 02:12:32PM +0000, Ian Campbell
wrote:> On Fri, 2013-11-01 at 14:08 +0000, Wei Liu wrote:
> > It didn''t print out base address by default. I added my own
debug patch
> > and confirmed that base address was set correctly by hvmloader.
> > 
> > (d9) PciBus: Discovered PCI @ [00|02|00]
> > (d9)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length =
0x2000000;     Offset = 0x10        BaseAddress = 0xF0000000
> > (d9)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length =
0x1000; Offset = 0x14   BaseAddress = 0xF3020000
> > 
> > Sorry about the confusion.
> 
> OK, so even OVMF thinks the Cirrus memory range is at 0xf0000000, so
> where did efifb get 0x80000000 from?
> 
A few lines later in log

 (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success

EDK2 (not OVMF-specific as this is in generic PCI code) allocates
resources for devices.

Wei.
> Ian.

Ian Campbell

2013-Nov-01 14:31 UTC

head link

Re: Limitation in HVM physmap

On Fri, 2013-11-01 at 14:19 +0000, Wei Liu wrote:> On Fri, Nov 01, 2013 at 02:12:32PM +0000, Ian Campbell wrote:
> > On Fri, 2013-11-01 at 14:08 +0000, Wei Liu wrote:
> > > It didn''t print out base address by default. I added my
own debug patch
> > > and confirmed that base address was set correctly by hvmloader.
> > > 
> > > (d9) PciBus: Discovered PCI @ [00|02|00]
> > > (d9)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;   Length =
0x2000000;     Offset = 0x10        BaseAddress = 0xF0000000
> > > (d9)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;       Length =
0x1000; Offset = 0x14   BaseAddress = 0xF3020000
> > > 
> > > Sorry about the confusion.
> > 
> > OK, so even OVMF thinks the Cirrus memory range is at 0xf0000000, so
> > where did efifb get 0x80000000 from?
> > 
> 
> A few lines later in log
> 
>  (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
Hrm, I was confused because this line obviously doesn''t say 0x8000000
(or much of anything) anywhere, but you meant it as a reference to the
first line of a block, which I''ll quote in full for
clarity:> > (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
> > (d1) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> > (d1) Type =   Io16; Base = 0xC000;      Length = 0x1000;       
Alignment = 0xFFF
> > (d1)  Base = 0xC000;    Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|04|00:10]
> > (d1)  Base = 0xC100;    Length = 0x100; Alignment = 0xFF;       Owner
= PCI  [00|03|00:10]
> > (d1)  Base = 0xC200;    Length = 0x10;  Alignment = 0xF;        Owner
= PCI  [00|01|01:20]
> > (d1) Type =  Mem32; Base = 0x80000000;  Length = 0x3100000;    
Alignment = 0x1FFFFFF
> > (d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owner = PCI  [00|02|00:10]
> > (d1)  Base = 0x82000000;        Length = 0x1000000;     Alignment =
0xFFFFFF;   Owner = PCI  [00|03|00:14]
> > (d1)  Base = 0x83000000;        Length = 0x100; Alignment = 0xFFF;    
Owner = PCI  [00|04|00:14]
> > (d1)  Base = 0x83001000;        Length = 0x1000;        Alignment =
0xFFF;      Owner = PCI  [00|02|00:14]
(I''ve undamaged the whitespace a bit too). I suppose the interesting
line is:
> > (d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment =
0x1FFFFFF;  Owner = PCI  [00|02|00:10]
Is this report based on what EDK2 wanted to set or is it based on what
it actually does set? How come this is not reflected in the device BAR
by the time Linux has a look?

Do you know what the ":10" in "00|02|00:10" is? Does it
indicate BAR[0]
which is a memory BAR somehow or something else?

The log in <20131018153009.GH20185@zion.uk.xensource.com> has:
[    1.556292] pci 0000:00:02.0: no compatible bridge window for [mem
0x80000000-0x81ffffff pref]
[    1.560024] pci 0000:00:02.0: no compatible bridge window for [mem
0x83001000-0x83001fff]
[    1.564118] pci 0000:00:03.0: no compatible bridge window for [mem
0x82000000-0x82ffffff pref]

could be the reason Linux is trying to rewrite things again itself?

Ian.

Wei Liu

2013-Nov-01 14:55 UTC

head link

Re: Limitation in HVM physmap

On Fri, Nov 01, 2013 at 02:31:03PM +0000, Ian Campbell
wrote:> On Fri, 2013-11-01 at 14:19 +0000, Wei Liu wrote:
> > On Fri, Nov 01, 2013 at 02:12:32PM +0000, Ian Campbell wrote:
> > > On Fri, 2013-11-01 at 14:08 +0000, Wei Liu wrote:
> > > > It didn''t print out base address by default. I
added my own debug patch
> > > > and confirmed that base address was set correctly by
hvmloader.
> > > > 
> > > > (d9) PciBus: Discovered PCI @ [00|02|00]
> > > > (d9)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;  
Length = 0x2000000;     Offset = 0x10        BaseAddress = 0xF0000000
> > > > (d9)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;      
Length = 0x1000; Offset = 0x14   BaseAddress = 0xF3020000
> > > > 
> > > > Sorry about the confusion.
> > > 
> > > OK, so even OVMF thinks the Cirrus memory range is at 0xf0000000,
so
> > > where did efifb get 0x80000000 from?
> > > 
> > 
> > A few lines later in log
> > 
> >  (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) - Success
> 
> Hrm, I was confused because this line obviously doesn''t say
0x8000000
> (or much of anything) anywhere, but you meant it as a reference to the
> first line of a block, which I''ll quote in full for clarity:
Oh, what I meant is there is a procedure to allocate resource.
> > > (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) -
Success
> > > (d1) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> > > (d1) Type =   Io16; Base = 0xC000;      Length = 0x1000;       
Alignment = 0xFFF
> > > (d1)  Base = 0xC000;    Length = 0x100; Alignment = 0xFF;      
Owner = PCI  [00|04|00:10]
> > > (d1)  Base = 0xC100;    Length = 0x100; Alignment = 0xFF;      
Owner = PCI  [00|03|00:10]
> > > (d1)  Base = 0xC200;    Length = 0x10;  Alignment = 0xF;       
Owner = PCI  [00|01|01:20]
> > > (d1) Type =  Mem32; Base = 0x80000000;  Length = 0x3100000;    
Alignment = 0x1FFFFFF
> > > (d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment
= 0x1FFFFFF;  Owner = PCI  [00|02|00:10]
> > > (d1)  Base = 0x82000000;        Length = 0x1000000;     Alignment
= 0xFFFFFF;   Owner = PCI  [00|03|00:14]
> > > (d1)  Base = 0x83000000;        Length = 0x100; Alignment =
0xFFF;      Owner = PCI  [00|04|00:14]
> > > (d1)  Base = 0x83001000;        Length = 0x1000;        Alignment
= 0xFFF;      Owner = PCI  [00|02|00:14]
> 
> (I''ve undamaged the whitespace a bit too). I suppose the
interesting line is:
> 
> > > (d1)  Base = 0x80000000;        Length = 0x2000000;     Alignment
= 0x1FFFFFF;  Owner = PCI  [00|02|00:10]
> 
> Is this report based on what EDK2 wanted to set or is it based on what
> it actually does set? How come this is not reflected in the device BAR
> by the time Linux has a look?
> 
... And this is the result of allocation.

I can see 0x80000000 in QEMU''s log, but that''s as far as I can
go
because I was sure QEMU was behaving correctly at that point. I can see
that the memory region of FB was updated in log, but some steps to
untrack the previous memory region seemed to be missing.  Probably a bug
in code updating the BAR in QEMU?
> Do you know what the ":10" in "00|02|00:10" is? Does it
indicate BAR[0]
> which is a memory BAR somehow or something else?
> 
"10" is the offset, nothing special. B|D|F:OFFSET
> The log in <20131018153009.GH20185@zion.uk.xensource.com> has:
> [    1.556292] pci 0000:00:02.0: no compatible bridge window for [mem
0x80000000-0x81ffffff pref]
> [    1.560024] pci 0000:00:02.0: no compatible bridge window for [mem
0x83001000-0x83001fff]
> [    1.564118] pci 0000:00:03.0: no compatible bridge window for [mem
0x82000000-0x82ffffff pref]
> 
> could be the reason Linux is trying to rewrite things again itself?
> 
There seems to be something wrong with that. My speculation is that this
is caused by other errors early on, but I''m not sure.

Wei.
> Ian.
>

Ian Campbell

2013-Nov-01 15:04 UTC

head link

Re: Limitation in HVM physmap

On Fri, 2013-11-01 at 14:55 +0000, Wei Liu wrote:> On Fri, Nov 01, 2013 at 02:31:03PM +0000, Ian Campbell wrote:
> > On Fri, 2013-11-01 at 14:19 +0000, Wei Liu wrote:
> > > On Fri, Nov 01, 2013 at 02:12:32PM +0000, Ian Campbell wrote:
> > > > On Fri, 2013-11-01 at 14:08 +0000, Wei Liu wrote:
> > > > > It didn''t print out base address by default. I
added my own debug patch
> > > > > and confirmed that base address was set correctly by
hvmloader.
> > > > > 
> > > > > (d9) PciBus: Discovered PCI @ [00|02|00]
> > > > > (d9)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;  
Length = 0x2000000;     Offset = 0x10        BaseAddress = 0xF0000000
> > > > > (d9)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;      
Length = 0x1000; Offset = 0x14   BaseAddress = 0xF3020000
> > > > > 
> > > > > Sorry about the confusion.
> > > > 
> > > > OK, so even OVMF thinks the Cirrus memory range is at
0xf0000000, so
> > > > where did efifb get 0x80000000 from?
> > > > 
> > > 
> > > A few lines later in log
> > > 
> > >  (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) -
Success
> > 
> > Hrm, I was confused because this line obviously doesn''t say
0x8000000
> > (or much of anything) anywhere, but you meant it as a reference to the
> > first line of a block, which I''ll quote in full for clarity:
> 
> Oh, what I meant is there is a procedure to allocate resource.
> 
> > > > (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) -
Success
> > > > (d1) PciBus: Resource Map for Root Bridge PciRoot(0x0)
> > > > (d1) Type =   Io16; Base = 0xC000;      Length = 0x1000;    
Alignment = 0xFFF
> > > > (d1)  Base = 0xC000;    Length = 0x100; Alignment = 0xFF;   
Owner = PCI  [00|04|00:10]
> > > > (d1)  Base = 0xC100;    Length = 0x100; Alignment = 0xFF;   
Owner = PCI  [00|03|00:10]
> > > > (d1)  Base = 0xC200;    Length = 0x10;  Alignment = 0xF;    
Owner = PCI  [00|01|01:20]
> > > > (d1) Type =  Mem32; Base = 0x80000000;  Length = 0x3100000; 
Alignment = 0x1FFFFFF
> > > > (d1)  Base = 0x80000000;        Length = 0x2000000;    
Alignment = 0x1FFFFFF;  Owner = PCI  [00|02|00:10]
> > > > (d1)  Base = 0x82000000;        Length = 0x1000000;    
Alignment = 0xFFFFFF;   Owner = PCI  [00|03|00:14]
> > > > (d1)  Base = 0x83000000;        Length = 0x100; Alignment =
0xFFF;      Owner = PCI  [00|04|00:14]
> > > > (d1)  Base = 0x83001000;        Length = 0x1000;       
Alignment = 0xFFF;      Owner = PCI  [00|02|00:14]
> > 
> > (I''ve undamaged the whitespace a bit too). I suppose the
interesting line is:
> > 
> > > > (d1)  Base = 0x80000000;        Length = 0x2000000;    
Alignment = 0x1FFFFFF;  Owner = PCI  [00|02|00:10]
> > 
> > Is this report based on what EDK2 wanted to set or is it based on what
> > it actually does set? How come this is not reflected in the device BAR
> > by the time Linux has a look?
> > 
> 
> ... And this is the result of allocation.
> 
> I can see 0x80000000 in QEMU''s log, but that''s as far as
I can go
> because I was sure QEMU was behaving correctly at that point. I can see
> that the memory region of FB was updated in log, but some steps to
> untrack the previous memory region seemed to be missing.  Probably a bug
> in code updating the BAR in QEMU?
It certainly seems like something isn''t "sticking" at least.
I''d have
throught the PCI bar emulation in qemu would be pretty well established,
might be some hook missing on our end?
> > Do you know what the ":10" in "00|02|00:10" is?
Does it indicate BAR[0]
> > which is a memory BAR somehow or something else?
> > 
> 
> "10" is the offset, nothing special. B|D|F:OFFSET
Ah, 0x10 is the offset of BAR[0] within the PCI CFG space, OK, makes
sense.
> > The log in <20131018153009.GH20185@zion.uk.xensource.com> has:
> > [    1.556292] pci 0000:00:02.0: no compatible bridge window for [mem
0x80000000-0x81ffffff pref]
> > [    1.560024] pci 0000:00:02.0: no compatible bridge window for [mem
0x83001000-0x83001fff]
> > [    1.564118] pci 0000:00:03.0: no compatible bridge window for [mem
0x82000000-0x82ffffff pref]
> > 
> > could be the reason Linux is trying to rewrite things again itself?
> > 
> 
> There seems to be something wrong with that. My speculation is that this
> is caused by other errors early on, but I''m not sure.
Right.

Fabio Fantoni

2013-Nov-04 09:28 UTC

head link

Re: Limitation in HVM physmap

Il 01/11/2013 16:04, Ian Campbell ha scritto:> On Fri, 2013-11-01 at 14:55 +0000, Wei Liu wrote:
>> On Fri, Nov 01, 2013 at 02:31:03PM +0000, Ian Campbell wrote:
>>> On Fri, 2013-11-01 at 14:19 +0000, Wei Liu wrote:
>>>> On Fri, Nov 01, 2013 at 02:12:32PM +0000, Ian Campbell wrote:
>>>>> On Fri, 2013-11-01 at 14:08 +0000, Wei Liu wrote:
>>>>>> It didn''t print out base address by default. I
added my own debug patch
>>>>>> and confirmed that base address was set correctly by
hvmloader.
>>>>>>
>>>>>> (d9) PciBus: Discovered PCI @ [00|02|00]
>>>>>> (d9)    BAR[0]: Type = PMem32; Alignment = 0x1FFFFFF;  
Length = 0x2000000;     Offset = 0x10        BaseAddress = 0xF0000000
>>>>>> (d9)    BAR[1]: Type =  Mem32; Alignment = 0xFFF;      
Length = 0x1000; Offset = 0x14   BaseAddress = 0xF3020000
>>>>>>
>>>>>> Sorry about the confusion.
>>>>> OK, so even OVMF thinks the Cirrus memory range is at
0xf0000000, so
>>>>> where did efifb get 0x80000000 from?
>>>>>
>>>> A few lines later in log
>>>>
>>>>   (d1) PciBus: HostBridge->NotifyPhase(AllocateResources) -
Success
>>> Hrm, I was confused because this line obviously doesn''t
say 0x8000000
>>> (or much of anything) anywhere, but you meant it as a reference to
the
>>> first line of a block, which I''ll quote in full for
clarity:
>> Oh, what I meant is there is a procedure to allocate resource.
>>
>>>>> (d1) PciBus: HostBridge->NotifyPhase(AllocateResources)
- Success
>>>>> (d1) PciBus: Resource Map for Root Bridge PciRoot(0x0)
>>>>> (d1) Type =   Io16; Base = 0xC000;      Length = 0x1000;   
Alignment = 0xFFF
>>>>> (d1)  Base = 0xC000;    Length = 0x100; Alignment = 0xFF;  
Owner = PCI  [00|04|00:10]
>>>>> (d1)  Base = 0xC100;    Length = 0x100; Alignment = 0xFF;  
Owner = PCI  [00|03|00:10]
>>>>> (d1)  Base = 0xC200;    Length = 0x10;  Alignment = 0xF;   
Owner = PCI  [00|01|01:20]
>>>>> (d1) Type =  Mem32; Base = 0x80000000;  Length = 0x3100000;
Alignment = 0x1FFFFFF
>>>>> (d1)  Base = 0x80000000;        Length = 0x2000000;    
Alignment = 0x1FFFFFF;  Owner = PCI  [00|02|00:10]
>>>>> (d1)  Base = 0x82000000;        Length = 0x1000000;    
Alignment = 0xFFFFFF;   Owner = PCI  [00|03|00:14]
>>>>> (d1)  Base = 0x83000000;        Length = 0x100; Alignment =
0xFFF;      Owner = PCI  [00|04|00:14]
>>>>> (d1)  Base = 0x83001000;        Length = 0x1000;       
Alignment = 0xFFF;      Owner = PCI  [00|02|00:14]
>>> (I''ve undamaged the whitespace a bit too). I suppose the
interesting line is:
>>>
>>>>> (d1)  Base = 0x80000000;        Length = 0x2000000;    
Alignment = 0x1FFFFFF;  Owner = PCI  [00|02|00:10]
>>> Is this report based on what EDK2 wanted to set or is it based on
what
>>> it actually does set? How come this is not reflected in the device
BAR
>>> by the time Linux has a look?
>>>
>> ... And this is the result of allocation.
>>
>> I can see 0x80000000 in QEMU''s log, but that''s as far
as I can go
>> because I was sure QEMU was behaving correctly at that point. I can see
>> that the memory region of FB was updated in log, but some steps to
>> untrack the previous memory region seemed to be missing.  Probably a
bug
>> in code updating the BAR in QEMU?
> It certainly seems like something isn''t "sticking" at
least. I''d have
> throught the PCI bar emulation in qemu would be pretty well established,
> might be some hook missing on our end?
>
>>> Do you know what the ":10" in "00|02|00:10" is?
Does it indicate BAR[0]
>>> which is a memory BAR somehow or something else?
>>>
>> "10" is the offset, nothing special. B|D|F:OFFSET
> Ah, 0x10 is the offset of BAR[0] within the PCI CFG space, OK, makes
> sense.
>
>>> The log in <20131018153009.GH20185@zion.uk.xensource.com>
has:
>>> [    1.556292] pci 0000:00:02.0: no compatible bridge window for
[mem 0x80000000-0x81ffffff pref]
>>> [    1.560024] pci 0000:00:02.0: no compatible bridge window for
[mem 0x83001000-0x83001fff]
>>> [    1.564118] pci 0000:00:03.0: no compatible bridge window for
[mem 0x82000000-0x82ffffff pref]
>>>
>>> could be the reason Linux is trying to rewrite things again itself?
>>>
>> There seems to be something wrong with that. My speculation is that
this
>> is caused by other errors early on, but I''m not sure.
> Right.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
Could be a similar problem on qxl too?
On latest debug about qxl time ago I found this error on domU''s
log:> ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0 For details see the full post:
http://lists.xen.org/archives/html/xen-devel/2013-10/msg00016.html
If you need more informations and/or tests tell me and I''ll post them.
Thanks for any reply.

Wei Liu

2013-Nov-04 11:42 UTC

head link

Re: Limitation in HVM physmap

On Mon, Nov 04, 2013 at 10:28:57AM +0100, Fabio Fantoni wrote:
[...]> 
> Could be a similar problem on qxl too?
> On latest debug about qxl time ago I found this error on domU''s
log:
> >ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0
> For details see the full post:
> http://lists.xen.org/archives/html/xen-devel/2013-10/msg00016.html
> If you need more informations and/or tests tell me and I''ll post
them.
> Thanks for any reply.
Is OVMF involved? If not then I don''t think it''s related.

Wei.

Fabio Fantoni

2013-Nov-04 12:05 UTC

head link

Re: Limitation in HVM physmap

Il 04/11/2013 12:42, Wei Liu ha scritto:> On Mon, Nov 04, 2013 at 10:28:57AM +0100, Fabio Fantoni wrote:
> [...]
>> Could be a similar problem on qxl too?
>> On latest debug about qxl time ago I found this error on
domU''s log:
>>> ioremap error for 0xfc001000-0xfc002000, requested 0x10, got 0x0
>> For details see the full post:
>> http://lists.xen.org/archives/html/xen-devel/2013-10/msg00016.html
>> If you need more informations and/or tests tell me and I''ll
post them.
>> Thanks for any reply.
> Is OVMF involved? If not then I don''t think it''s related.
>
> Wei.
No, this was with seabios.
With ovmf qxl seems to have the same critical general performance 
problem of stdvga already reported days ago.
On my tests at the moment with me ovmf start properly only with Saucy 
using cirrus video card but when arriveto the DE has very poor graphics 
performance (not usable).

Wei Liu

2013-Nov-04 12:17 UTC

head link

Re: Limitation in HVM physmap

On Mon, Nov 04, 2013 at 01:05:39PM +0100, Fabio Fantoni
wrote:> Il 04/11/2013 12:42, Wei Liu ha scritto:
> >On Mon, Nov 04, 2013 at 10:28:57AM +0100, Fabio Fantoni wrote:
> >[...]
> >>Could be a similar problem on qxl too?
> >>On latest debug about qxl time ago I found this error on
domU''s log:
> >>>ioremap error for 0xfc001000-0xfc002000, requested 0x10, got
0x0
> >>For details see the full post:
> >>http://lists.xen.org/archives/html/xen-devel/2013-10/msg00016.html
> >>If you need more informations and/or tests tell me and
I''ll post them.
> >>Thanks for any reply.
> >Is OVMF involved? If not then I don''t think it''s
related.
> >
> >Wei.
> 
> No, this was with seabios.
> With ovmf qxl seems to have the same critical general performance
> problem of stdvga already reported days ago.
> On my tests at the moment with me ovmf start properly only with
> Saucy using cirrus video card but when arriveto the DE has very poor
> graphics performance (not usable).
I need to fix underlying issues before attending performance related
ones.

Fabio Fantoni

2013-Nov-04 14:08 UTC

head link

Re: Limitation in HVM physmap

Wei Liu

2013-Nov-04 14:14 UTC

head link

Re: Limitation in HVM physmap

On Mon, Nov 04, 2013 at 03:08:25PM +0100, Fabio Fantoni
wrote:> Il 04/11/2013 13:17, Wei Liu ha scritto:
> >On Mon, Nov 04, 2013 at 01:05:39PM +0100, Fabio Fantoni wrote:
> >>Il 04/11/2013 12:42, Wei Liu ha scritto:
> >>>On Mon, Nov 04, 2013 at 10:28:57AM +0100, Fabio Fantoni wrote:
> >>>[...]
> >>>>Could be a similar problem on qxl too?
> >>>>On latest debug about qxl time ago I found this error on
domU''s log:
> >>>>>ioremap error for 0xfc001000-0xfc002000, requested
0x10, got 0x0
> >>>>For details see the full post:
> >>>>
> >>>>If you need more informations and/or tests tell me and
I''ll post them.
> >>>>Thanks for any reply.
> >>>Is OVMF involved? If not then I don''t think
it''s related.
> >>>
> >>>Wei.
> >>No, this was with seabios.
> >>With ovmf qxl seems to have the same critical general performance
> >>problem of stdvga already reported days ago.
> >>On my tests at the moment with me ovmf start properly only with
> >>Saucy using cirrus video card but when arriveto the DE has very
poor
> >>graphics performance (not usable).
> >I need to fix underlying issues before attending performance related
> >ones.
> >
> 
> If can be useful on attachment logs of Fedora19 domU with ovmf and qxl vga.
> 
> On ovmf test I see that is missed the ioremap error present on seabios
test.
> 
> If these data are useless sorry for the trouble.
There''s a workaround for Cirrus not working correctly. Add pci=nocrs in
your Linux command line. But it''s just a workaround, a proper fix is
still to be determined.

Wei.

Xen devel - Oct 2013 - Limitation in HVM physmap

Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap

Re: Limitation in HVM physmap