* Limitation in HVM physmap
@ 2013-10-18 14:20 Wei Liu
2013-10-18 14:26 ` George Dunlap
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Wei Liu @ 2013-10-18 14:20 UTC (permalink / raw)
To: Jan Beulich, tim, keir
Cc: George Dunlap, Stefano Stabellini, wei.liu2, Ian Campbell,
xen-devel
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:20 Limitation in HVM physmap Wei Liu
@ 2013-10-18 14:26 ` George Dunlap
2013-10-18 15:12 ` Paul Durrant
2013-10-18 14:28 ` Tim Deegan
2013-11-01 12:21 ` Wei Liu
2 siblings, 1 reply; 36+ messages in thread
From: George Dunlap @ 2013-10-18 14:26 UTC (permalink / raw)
To: Wei Liu, Jan Beulich, tim, keir
Cc: Stefano Stabellini, Ian Campbell, xen-devel
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:20 Limitation in HVM physmap Wei Liu
2013-10-18 14:26 ` George Dunlap
@ 2013-10-18 14:28 ` Tim Deegan
2013-10-18 14:36 ` Wei Liu
2013-11-01 12:21 ` Wei Liu
2 siblings, 1 reply; 36+ messages in thread
From: Tim Deegan @ 2013-10-18 14:28 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:28 ` Tim Deegan
@ 2013-10-18 14:36 ` Wei Liu
2013-10-18 14:41 ` Tim Deegan
2013-10-18 14:47 ` Jan Beulich
0 siblings, 2 replies; 36+ messages in thread
From: Wei Liu @ 2013-10-18 14:36 UTC (permalink / raw)
To: Tim Deegan
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, xen-devel,
Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:36 ` Wei Liu
@ 2013-10-18 14:41 ` Tim Deegan
2013-10-18 14:56 ` Wei Liu
2013-10-18 14:47 ` Jan Beulich
1 sibling, 1 reply; 36+ messages in thread
From: Tim Deegan @ 2013-10-18 14:41 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:36 ` Wei Liu
2013-10-18 14:41 ` Tim Deegan
@ 2013-10-18 14:47 ` Jan Beulich
2013-10-18 15:01 ` Wei Liu
1 sibling, 1 reply; 36+ messages in thread
From: Jan Beulich @ 2013-10-18 14:47 UTC (permalink / raw)
To: Wei Liu, Tim Deegan
Cc: George Dunlap, xen-devel, keir, Ian Campbell, Stefano Stabellini
>>> 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:41 ` Tim Deegan
@ 2013-10-18 14:56 ` Wei Liu
2013-10-18 14:59 ` Ian Campbell
0 siblings, 1 reply; 36+ messages in thread
From: Wei Liu @ 2013-10-18 14:56 UTC (permalink / raw)
To: Tim Deegan
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, xen-devel,
Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:56 ` Wei Liu
@ 2013-10-18 14:59 ` Ian Campbell
2013-10-18 15:00 ` Ian Campbell
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Ian Campbell @ 2013-10-18 14:59 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, Tim Deegan, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:59 ` Ian Campbell
@ 2013-10-18 15:00 ` Ian Campbell
2013-10-18 15:04 ` Wei Liu
2013-10-18 15:14 ` Stefano Stabellini
2 siblings, 0 replies; 36+ messages in thread
From: Ian Campbell @ 2013-10-18 15:00 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, Tim Deegan, xen-devel,
Jan Beulich
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...
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:47 ` Jan Beulich
@ 2013-10-18 15:01 ` Wei Liu
2013-10-18 15:07 ` Ian Campbell
2013-10-18 15:09 ` Jan Beulich
0 siblings, 2 replies; 36+ messages in thread
From: Wei Liu @ 2013-10-18 15:01 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, Ian Campbell, Stefano Stabellini, George Dunlap,
Tim Deegan, xen-devel, keir
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:59 ` Ian Campbell
2013-10-18 15:00 ` Ian Campbell
@ 2013-10-18 15:04 ` Wei Liu
2013-10-18 15:06 ` George Dunlap
2013-10-18 15:07 ` Wei Liu
2013-10-18 15:14 ` Stefano Stabellini
2 siblings, 2 replies; 36+ messages in thread
From: Wei Liu @ 2013-10-18 15:04 UTC (permalink / raw)
To: Ian Campbell
Cc: keir, Stefano Stabellini, George Dunlap, Tim Deegan, xen-devel,
Jan Beulich, Wei Liu
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.
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 15:04 ` Wei Liu
@ 2013-10-18 15:06 ` George Dunlap
2013-10-18 15:07 ` Wei Liu
1 sibling, 0 replies; 36+ messages in thread
From: George Dunlap @ 2013-10-18 15:06 UTC (permalink / raw)
To: Wei Liu, Ian Campbell
Cc: keir, Stefano Stabellini, Tim Deegan, Jan Beulich, xen-devel
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 15:04 ` Wei Liu
2013-10-18 15:06 ` George Dunlap
@ 2013-10-18 15:07 ` Wei Liu
2013-10-18 15:09 ` Ian Campbell
1 sibling, 1 reply; 36+ messages in thread
From: Wei Liu @ 2013-10-18 15:07 UTC (permalink / raw)
To: Ian Campbell
Cc: keir, Stefano Stabellini, George Dunlap, Tim Deegan, xen-devel,
Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 15:01 ` Wei Liu
@ 2013-10-18 15:07 ` Ian Campbell
2013-10-18 15:30 ` Wei Liu
2013-10-18 15:09 ` Jan Beulich
1 sibling, 1 reply; 36+ messages in thread
From: Ian Campbell @ 2013-10-18 15:07 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, Tim Deegan, xen-devel,
Jan Beulich
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?
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 15:01 ` Wei Liu
2013-10-18 15:07 ` Ian Campbell
@ 2013-10-18 15:09 ` Jan Beulich
1 sibling, 0 replies; 36+ messages in thread
From: Jan Beulich @ 2013-10-18 15:09 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, Tim Deegan,
xen-devel
>>> 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 15:07 ` Wei Liu
@ 2013-10-18 15:09 ` Ian Campbell
0 siblings, 0 replies; 36+ messages in thread
From: Ian Campbell @ 2013-10-18 15:09 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, Tim Deegan, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:26 ` George Dunlap
@ 2013-10-18 15:12 ` Paul Durrant
0 siblings, 0 replies; 36+ messages in thread
From: Paul Durrant @ 2013-10-18 15:12 UTC (permalink / raw)
To: George Dunlap, Wei Liu, Jan Beulich, Tim (Xen.org),
Keir (Xen.org)
Cc: xen-devel@lists.xen.org, Ian Campbell, Stefano Stabellini
> -----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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:59 ` Ian Campbell
2013-10-18 15:00 ` Ian Campbell
2013-10-18 15:04 ` Wei Liu
@ 2013-10-18 15:14 ` Stefano Stabellini
2 siblings, 0 replies; 36+ messages in thread
From: Stefano Stabellini @ 2013-10-18 15:14 UTC (permalink / raw)
To: Ian Campbell
Cc: keir, Stefano Stabellini, George Dunlap, Tim Deegan, xen-devel,
Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 15:07 ` Ian Campbell
@ 2013-10-18 15:30 ` Wei Liu
0 siblings, 0 replies; 36+ messages in thread
From: Wei Liu @ 2013-10-18 15:30 UTC (permalink / raw)
To: Ian Campbell
Cc: Wei Liu, Stefano Stabellini, George Dunlap, Tim Deegan, xen-devel,
Jan Beulich, keir
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-10-18 14:20 Limitation in HVM physmap Wei Liu
2013-10-18 14:26 ` George Dunlap
2013-10-18 14:28 ` Tim Deegan
@ 2013-11-01 12:21 ` Wei Liu
2013-11-01 12:26 ` George Dunlap
2013-11-01 12:33 ` Ian Campbell
2 siblings, 2 replies; 36+ messages in thread
From: Wei Liu @ 2013-11-01 12:21 UTC (permalink / raw)
To: Jan Beulich, tim, keir
Cc: George Dunlap, Stefano Stabellini, wei.liu2, Ian Campbell,
xen-devel
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 12:21 ` Wei Liu
@ 2013-11-01 12:26 ` George Dunlap
2013-11-01 12:33 ` Ian Campbell
1 sibling, 0 replies; 36+ messages in thread
From: George Dunlap @ 2013-11-01 12:26 UTC (permalink / raw)
To: Wei Liu, Jan Beulich, tim, keir
Cc: Stefano Stabellini, Ian Campbell, xen-devel
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 12:21 ` Wei Liu
2013-11-01 12:26 ` George Dunlap
@ 2013-11-01 12:33 ` Ian Campbell
2013-11-01 12:45 ` Wei Liu
1 sibling, 1 reply; 36+ messages in thread
From: Ian Campbell @ 2013-11-01 12:33 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 12:33 ` Ian Campbell
@ 2013-11-01 12:45 ` Wei Liu
2013-11-01 12:49 ` Ian Campbell
0 siblings, 1 reply; 36+ messages in thread
From: Wei Liu @ 2013-11-01 12:45 UTC (permalink / raw)
To: Ian Campbell
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 12:45 ` Wei Liu
@ 2013-11-01 12:49 ` Ian Campbell
2013-11-01 14:08 ` Wei Liu
0 siblings, 1 reply; 36+ messages in thread
From: Ian Campbell @ 2013-11-01 12:49 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 12:49 ` Ian Campbell
@ 2013-11-01 14:08 ` Wei Liu
2013-11-01 14:12 ` Ian Campbell
0 siblings, 1 reply; 36+ messages in thread
From: Wei Liu @ 2013-11-01 14:08 UTC (permalink / raw)
To: Ian Campbell
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 14:08 ` Wei Liu
@ 2013-11-01 14:12 ` Ian Campbell
2013-11-01 14:19 ` Wei Liu
0 siblings, 1 reply; 36+ messages in thread
From: Ian Campbell @ 2013-11-01 14:12 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 14:12 ` Ian Campbell
@ 2013-11-01 14:19 ` Wei Liu
2013-11-01 14:31 ` Ian Campbell
0 siblings, 1 reply; 36+ messages in thread
From: Wei Liu @ 2013-11-01 14:19 UTC (permalink / raw)
To: Ian Campbell
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 14:19 ` Wei Liu
@ 2013-11-01 14:31 ` Ian Campbell
2013-11-01 14:55 ` Wei Liu
0 siblings, 1 reply; 36+ messages in thread
From: Ian Campbell @ 2013-11-01 14:31 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 14:31 ` Ian Campbell
@ 2013-11-01 14:55 ` Wei Liu
2013-11-01 15:04 ` Ian Campbell
0 siblings, 1 reply; 36+ messages in thread
From: Wei Liu @ 2013-11-01 14:55 UTC (permalink / raw)
To: Ian Campbell
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich, Wei Liu
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.
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 14:55 ` Wei Liu
@ 2013-11-01 15:04 ` Ian Campbell
2013-11-04 9:28 ` Fabio Fantoni
0 siblings, 1 reply; 36+ messages in thread
From: Ian Campbell @ 2013-11-01 15:04 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-01 15:04 ` Ian Campbell
@ 2013-11-04 9:28 ` Fabio Fantoni
2013-11-04 11:42 ` Wei Liu
0 siblings, 1 reply; 36+ messages in thread
From: Fabio Fantoni @ 2013-11-04 9:28 UTC (permalink / raw)
To: Ian Campbell, Wei Liu
Cc: keir, Stefano Stabellini, George Dunlap, tim, xen-devel,
Jan Beulich
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-04 9:28 ` Fabio Fantoni
@ 2013-11-04 11:42 ` Wei Liu
2013-11-04 12:05 ` Fabio Fantoni
0 siblings, 1 reply; 36+ messages in thread
From: Wei Liu @ 2013-11-04 11:42 UTC (permalink / raw)
To: Fabio Fantoni
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, tim,
xen-devel, Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-04 11:42 ` Wei Liu
@ 2013-11-04 12:05 ` Fabio Fantoni
2013-11-04 12:17 ` Wei Liu
0 siblings, 1 reply; 36+ messages in thread
From: Fabio Fantoni @ 2013-11-04 12:05 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, tim,
xen-devel, Jan Beulich
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).
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-04 12:05 ` Fabio Fantoni
@ 2013-11-04 12:17 ` Wei Liu
2013-11-04 14:08 ` Fabio Fantoni
0 siblings, 1 reply; 36+ messages in thread
From: Wei Liu @ 2013-11-04 12:17 UTC (permalink / raw)
To: Fabio Fantoni
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, tim,
xen-devel, Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-04 12:17 ` Wei Liu
@ 2013-11-04 14:08 ` Fabio Fantoni
2013-11-04 14:14 ` Wei Liu
0 siblings, 1 reply; 36+ messages in thread
From: Fabio Fantoni @ 2013-11-04 14:08 UTC (permalink / raw)
To: Wei Liu
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, tim,
xen-devel, Jan Beulich
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
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.
[-- Attachment #2: xl-dmesg-fedora19-qxl-ovmf.txt --]
[-- Type: text/plain, Size: 2851 bytes --]
(d5) HVM Loader
(d5) Detected Xen v4.4-unstable
(d5) Xenbus rings @0xfeffc000, event channel 4
(d5) System requested OVMF
(d5) CPU speed is 2661 MHz
(d5) Relocating guest memory for lowmem MMIO space disabled
(XEN) irq.c:270: Dom5 PCI link 0 changed 0 -> 5
(d5) PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom5 PCI link 1 changed 0 -> 10
(d5) PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom5 PCI link 2 changed 0 -> 11
(d5) PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom5 PCI link 3 changed 0 -> 5
(d5) PCI-ISA link 3 routed to IRQ5
(d5) pci dev 01:3 INTA->IRQ10
(d5) pci dev 02:0 INTA->IRQ11
(d5) pci dev 03:0 INTA->IRQ5
(d5) pci dev 04:0 INTA->IRQ5
(d5) No RAM in high memory; setting high_mem resource base to 100000000
(d5) pci dev 03:0 bar 10 size 004000000: 0f0000000
(d5) pci dev 03:0 bar 14 size 004000000: 0f4000000
(d5) pci dev 02:0 bar 14 size 001000000: 0f8000008
(d5) pci dev 04:0 bar 30 size 000040000: 0f9000000
(d5) pci dev 03:0 bar 30 size 000010000: 0f9040000
(d5) pci dev 03:0 bar 18 size 000002000: 0f9050000
(d5) pci dev 02:0 bar 10 size 000000100: 00000c001
(d5) pci dev 04:0 bar 10 size 000000100: 00000c101
(d5) pci dev 04:0 bar 14 size 000000100: 0f9052000
(d5) pci dev 03:0 bar 1c size 000000020: 00000c201
(d5) pci dev 01:1 bar 20 size 000000010: 00000c221
(d5) Multiprocessor initialisation:
(d5) - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d5) - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
(d5) Testing HVM environment:
(d5) - REP INSB across page boundaries ... passed
(d5) - GS base MSRs and SWAPGS ... passed
(d5) Passed 2 of 2 tests
(d5) Writing SMBIOS tables ...
(d5) Loading OVMF ...
(d5) Loading ACPI ...
(d5) vm86 TSS at fc012c00
(d5) BIOS map:
(d5) 00000-fffff: Main BIOS
(d5) Invoking OVMF ...
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) irq.c:270: Dom5 PCI link 0 changed 5 -> 11
(XEN) irq.c:270: Dom5 PCI link 1 changed 10 -> 11
(XEN) irq.c:270: Dom5 PCI link 2 changed 11 -> 10
(XEN) irq.c:270: Dom5 PCI link 3 changed 5 -> 10
(XEN) irq.c:375: Dom5 callback via changed to Direct Vector 0xf3
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) mm.c:620:d0 Could not get page ref for pfn ffffffffffffffff
(XEN) irq.c:270: Dom5 PCI link 0 changed 11 -> 0
(XEN) irq.c:270: Dom5 PCI link 1 changed 11 -> 0
(XEN) irq.c:270: Dom5 PCI link 2 changed 10 -> 0
(XEN) irq.c:270: Dom5 PCI link 3 changed 10 -> 0
[-- Attachment #3: fedora19-log-serial-qxl-ovmf.txt --]
[-- Type: text/plain, Size: 68685 bytes --]
cat /dev/pts/3
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.9.5-301.fc19.x86_64 (mockbuild@bkernel01.phx2.fe
doraproject.org) (gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC) ) #1 SMP T
ue Jun 11 19:39:38 UTC 2013
[ 0.000000] Command line: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:
LABEL=Fedora\x2019\x20x86_64 console=hvc0 console=ttyS0,38400n8 debug ignore_lo
glevel LOGLEVEL=8
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000766c0fff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000766c1000-0x00000000766d2fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000766d3000-0x00000000766dffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000766e0000-0x0000000077b5ffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000077b60000-0x0000000077bb7fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000077bb8000-0x0000000077bbffff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x0000000077bc0000-0x0000000077bc3fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000077bc4000-0x0000000077fcefff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000077fcf000-0x0000000077ffefff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000077fff000-0x0000000077ffffff] usable
[ 0.000000] debug: ignoring loglevel setting.
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] efi: EFI v2.31 by EDK II
[ 0.000000] efi: SMBIOS=0x77bb7000 ACPI=0x77bbf000 ACPI 2.0=0x77bbf014
[ 0.000000] efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000
00000a0000) (0MB)
[ 0.000000] efi: mem01: type=2, attr=0xf, range=[0x0000000000100000-0x000000
0000102000) (0MB)
[ 0.000000] efi: mem02: type=7, attr=0xf, range=[0x0000000000102000-0x000000
0000800000) (6MB)
[ 0.000000] efi: mem03: type=4, attr=0xf, range=[0x0000000000800000-0x000000
0001000000) (8MB)
[ 0.000000] efi: mem04: type=2, attr=0xf, range=[0x0000000001000000-0x000000
00023e5000) (19MB)
[ 0.000000] efi: mem05: type=7, attr=0xf, range=[0x00000000023e5000-0x000000
003e0ab000) (956MB)
[ 0.000000] efi: mem06: type=2, attr=0xf, range=[0x000000003e0ab000-0x000000
0040000000) (31MB)
[ 0.000000] efi: mem07: type=7, attr=0xf, range=[0x0000000040000000-0x000000
00569a7000) (361MB)
[ 0.000000] efi: mem08: type=2, attr=0xf, range=[0x00000000569a7000-0x000000
0074000000) (470MB)
[ 0.000000] efi: mem09: type=4, attr=0xf, range=[0x0000000074000000-0x000000
0074020000) (0MB)
[ 0.000000] efi: mem10: type=7, attr=0xf, range=[0x0000000074020000-0x000000
007621e000) (33MB)
[ 0.000000] efi: mem11: type=2, attr=0xf, range=[0x000000007621e000-0x000000
0076301000) (0MB)
[ 0.000000] efi: mem12: type=1, attr=0xf, range=[0x0000000076301000-0x000000
0076438000) (1MB)
[ 0.000000] efi: mem13: type=7, attr=0xf, range=[0x0000000076438000-0x000000
00764a1000) (0MB)
[ 0.000000] efi: mem14: type=2, attr=0xf, range=[0x00000000764a1000-0x000000
0076587000) (0MB)
[ 0.000000] efi: mem15: type=4, attr=0xf, range=[0x0000000076587000-0x000000
007660f000) (0MB)
[ 0.000000] efi: mem16: type=3, attr=0xf, range=[0x000000007660f000-0x000000
00766c1000) (0MB)
[ 0.000000] efi: mem17: type=9, attr=0xf, range=[0x00000000766c1000-0x000000
00766d3000) (0MB)
[ 0.000000] efi: mem18: type=6, attr=0x800000000000000f, range=[0x0000000076
6d3000-0x00000000766e0000) (0MB)
[ 0.000000] efi: mem19: type=4, attr=0xf, range=[0x00000000766e0000-0x000000
00779e0000) (19MB)
[ 0.000000] efi: mem20: type=7, attr=0xf, range=[0x00000000779e0000-0x000000
00779e1000) (0MB)
[ 0.000000] efi: mem21: type=3, attr=0xf, range=[0x00000000779e1000-0x000000
0077b60000) (1MB)
[ 0.000000] efi: mem22: type=5, attr=0x800000000000000f, range=[0x0000000077
b60000-0x0000000077b90000) (0MB)
[ 0.000000] efi: mem23: type=6, attr=0x800000000000000f, range=[0x0000000077
b90000-0x0000000077bb4000) (0MB)
[ 0.000000] efi: mem24: type=0, attr=0xf, range=[0x0000000077bb4000-0x000000
0077bb8000) (0MB)
[ 0.000000] efi: mem25: type=9, attr=0xf, range=[0x0000000077bb8000-0x000000
0077bc0000) (0MB)
[ 0.000000] efi: mem26: type=10, attr=0xf, range=[0x0000000077bc0000-0x00000
00077bc4000) (0MB)
[ 0.000000] efi: mem27: type=4, attr=0xf, range=[0x0000000077bc4000-0x000000
0077fcf000) (4MB)
[ 0.000000] efi: mem28: type=6, attr=0x800000000000000f, range=[0x0000000077
fcf000-0x0000000077fff000) (0MB)
[ 0.000000] efi: mem29: type=4, attr=0xf, range=[0x0000000077fff000-0x000000
0078000000) (0MB)
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] DMI: Xen HVM domU, BIOS 4.4-unstable 11/04/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] HVMOP_pagetable_dying not supported
[ 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 = 0x78000 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 [0x01fc5000, 0x01fc5fff] PGTABLE
[ 0.000000] BRK [0x01fc6000, 0x01fc6fff] PGTABLE
[ 0.000000] BRK [0x01fc7000, 0x01fc7fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x76200000-0x763fffff]
[ 0.000000] [mem 0x76200000-0x763fffff] page 2M
[ 0.000000] BRK [0x01fc8000, 0x01fc8fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x74000000-0x761fffff]
[ 0.000000] [mem 0x74000000-0x761fffff] page 2M
[ 0.000000] init_memory_mapping: [mem 0x00100000-0x73ffffff]
[ 0.000000] [mem 0x00100000-0x001fffff] page 4k
[ 0.000000] [mem 0x00200000-0x73ffffff] page 2M
[ 0.000000] init_memory_mapping: [mem 0x76400000-0x766c0fff]
[ 0.000000] [mem 0x76400000-0x765fffff] page 2M
[ 0.000000] [mem 0x76600000-0x766c0fff] page 4k
[ 0.000000] BRK [0x01fc9000, 0x01fc9fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x766e0000-0x77b5ffff]
[ 0.000000] [mem 0x766e0000-0x767fffff] page 4k
[ 0.000000] [mem 0x76800000-0x779fffff] page 2M
[ 0.000000] [mem 0x77a00000-0x77b5ffff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x77bc4000-0x77fcefff]
[ 0.000000] [mem 0x77bc4000-0x77bfffff] page 4k
[ 0.000000] [mem 0x77c00000-0x77dfffff] page 2M
[ 0.000000] [mem 0x77e00000-0x77fcefff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x77fff000-0x77ffffff]
[ 0.000000] [mem 0x77fff000-0x77ffffff] page 4k
[ 0.000000] RAMDISK: [mem 0x3e0ab000-0x3fffafff]
[ 0.000000] ACPI: RSDP 0000000077bbf014 00024 (v02 Xen)
[ 0.000000] ACPI: XSDT 0000000077bbe0e8 00054 (v01 Xen HVM 00000000
01000013)
[ 0.000000] ACPI: FACP 0000000077bbd000 000F4 (v04 Xen HVM 00000000
HVML 00000000)
[ 0.000000] ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS tab
les! (20130117/tbfadt-395)
[ 0.000000] ACPI BIOS Bug: Warning: 32/64X FACS address mismatch in FADT - 0
x77BC3000/0x00000000FC001000, using 32 (20130117/tbfadt-522)
[ 0.000000] ACPI: DSDT 00000000766c1000 1138D (v02 Xen HVM 00000000
INTL 20100528)
[ 0.000000] ACPI: FACS 0000000077bc3000 00040
[ 0.000000] ACPI: APIC 0000000077bbc000 00460 (v02 Xen HVM 00000000
HVML 00000000)
[ 0.000000] ACPI: HPET 0000000077bbb000 00038 (v01 Xen HVM 00000000
HVML 00000000)
[ 0.000000] ACPI: WAET 0000000077bba000 00028 (v01 Xen HVM 00000000
HVML 00000000)
[ 0.000000] ACPI: SSDT 0000000077bb9000 00031 (v02 Xen HVM 00000000
INTL 20100528)
[ 0.000000] ACPI: SSDT 0000000077bb8000 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-0x0000000077ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x00000000-0x77ffffff]
[ 0.000000] NODE_DATA [mem 0x76572000-0x76585fff]
[ 0.000000] [ffffea0000000000-ffffea0001dfffff] PMD -> [ffff880072200000-ff
ff880073ffffff] 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-0x766c0fff]
[ 0.000000] node 0: [mem 0x766e0000-0x77b5ffff]
[ 0.000000] node 0: [mem 0x77bc4000-0x77fcefff]
[ 0.000000] node 0: [mem 0x77fff000-0x77ffffff]
[ 0.000000] On node 0 totalpages: 491244
[ 0.000000] DMA zone: 64 pages used for memmap
[ 0.000000] DMA zone: 23 pages reserved
[ 0.000000] DMA zone: 3999 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 7616 pages used for memmap
[ 0.000000] DMA32 zone: 487245 pages, LIFO batch:31
[ 0.000000] tboot: non-0 tboot_addr but it is not of type E820_RESERVED
[ 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 - 000000000010000
0
[ 0.000000] PM: Registered nosave memory: 00000000766c1000 - 00000000766d300
0
[ 0.000000] PM: Registered nosave memory: 00000000766d3000 - 00000000766e000
0
[ 0.000000] PM: Registered nosave memory: 0000000077b60000 - 0000000077bb800
0
[ 0.000000] PM: Registered nosave memory: 0000000077bb8000 - 0000000077bc000
0
[ 0.000000] PM: Registered nosave memory: 0000000077bc0000 - 0000000077bc400
0
[ 0.000000] PM: Registered nosave memory: 0000000077fcf000 - 0000000077fff00
0
[ 0.000000] e820: [mem 0x78000000-0xffffffff] available for PCI devices
[ 0.000000] Booting paravirtualized kernel on Xen HVM
[ 0.000000] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:128 nr_
node_ids:1
[ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff880074c00000 s85120 r8192 d21
376 u131072
[ 0.000000] pcpu-alloc: s85120 r8192 d21376 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 pa
ges: 483541
[ 0.000000] Policy zone: DMA32
[ 0.000000] Kernel command line: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.sta
ge2=hd:LABEL=Fedora\x2019\x20x86_64 console=hvc0 console=ttyS0,38400n8 debug ig
nore_loglevel LOGLEVEL=8
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] Checking aperture...
[ 0.000000] No AGP bridge found
[ 0.000000] Memory: 1844884k/1966080k available (6473k kernel code, 1104k ab
sent, 120092k reserved, 6764k data, 1352k init)
[ 0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=128
, Nodes=1
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] NR_IRQS:8448 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 [hvc0] enabled
[ 0.000000] console [ttyS0] enabled
[ 0.000000] allocated 7864320 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memo
ry cgroups
[ 0.000000] hpet clockevent registered
[ 0.000000] tsc: Detected 2661.210 MHz processor
[ 0.011000] Calibrating delay loop (skipped), value calculated using timer f
requency.. 5322.42 BogoMIPS (lpj=2661210)
[ 0.025003] pid_max: default: 131072 minimum: 1024
[ 0.032031] init_memory_mapping: [mem 0x766d3000-0x766dffff]
[ 0.040004] [mem 0x766d3000-0x766dffff] page 4k
[ 0.046026] init_memory_mapping: [mem 0x77b60000-0x77b8ffff]
[ 0.054003] [mem 0x77b60000-0x77b8ffff] page 4k
[ 0.060017] init_memory_mapping: [mem 0x77b90000-0x77bb3fff]
[ 0.068003] [mem 0x77b90000-0x77bb3fff] page 4k
[ 0.075016] init_memory_mapping: [mem 0x77fcf000-0x77ffefff]
[ 0.082003] [mem 0x77fcf000-0x77ffefff] page 4k
[ 0.089409] Security Framework initialized
[ 0.095009] SELinux: Initializing.
[ 0.100022] SELinux: Starting in permissive mode
[ 0.106192] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes
)
[ 0.117067] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.127082] Mount-cache hash table entries: 256
[ 0.133489] Initializing cgroup subsys cpuacct
[ 0.140004] Initializing cgroup subsys memory
[ 0.146018] Initializing cgroup subsys devices
[ 0.152003] Initializing cgroup subsys freezer
[ 0.158003] Initializing cgroup subsys net_cls
[ 0.164003] Initializing cgroup subsys blkio
[ 0.170003] Initializing cgroup subsys perf_event
[ 0.177097] CPU: Physical Processor ID: 0
[ 0.182003] CPU: Processor Core ID: 0
[ 0.187005] mce: CPU supports 2 MCE banks
[ 0.193029] Last level iTLB entries: 4KB 512, 2MB 7, 4MB 7
[ 0.193029] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[ 0.193029] tlb_flushall_shift: 6
[ 0.213216] Freeing SMP alternatives: 24k freed
[ 0.222972] ACPI: Core revision 20130117
[ 0.237156] ACPI: All ACPI Tables successfully acquired
[ 0.246025] ftrace: allocating 24409 entries in 96 pages
[ 0.289004] Switched APIC routing to physical flat.
[ 0.299794] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[ 0.317727] smpboot: CPU0: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz (
fam: 06, model: 1e, stepping: 05)
[ 0.331009] Xen: using vcpuop timer interface
[ 0.337006] installing Xen timer for CPU 0
[ 0.343198] Performance Events: unsupported p6 CPU model 30 no PMU driver, s
oftware events only.
[ 0.347751] NMI watchdog: disabled (cpu0): hardware events not enabled
[ 0.348072] installing Xen timer for CPU 1
[ 0.349057] smpboot: Booting Node 0, Processors #1
[ 0.362117] Brought up 2 CPUs
[ 0.363007] smpboot: Total of 2 processors activated (10644.84 BogoMIPS)
[ 0.365010] devtmpfs: initialized
[ 0.366215] PM: Registering ACPI NVS region [mem 0x77bc0000-0x77bc3fff] (163
84 bytes)
[ 0.367757] atomic64 test passed for x86-64 platform with CX8 and with SSE
[ 0.368032] RTC time: 14:26:30, date: 11/04/13
[ 0.369143] NET: Registered protocol family 16
[ 0.370215] ACPI: bus type PCI registered
[ 0.371402] PCI: Using configuration type 1 for base access
[ 0.372703] bio: create slab <bio-0> at 0
[ 0.373103] ACPI: Added _OSI(Module Device)
[ 0.374006] ACPI: Added _OSI(Processor Device)
[ 0.375006] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.376006] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.378838] ACPI: EC: Look up EC in DSDT
[ 0.384285] ACPI: Interpreter enabled
[ 0.385009] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1
_] (20130117/hwxface-568)
[ 0.388006] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2
_] (20130117/hwxface-568)
[ 0.391012] ACPI: (supports S0 S3 S4 S5)
[ 0.392005] ACPI: Using IOAPIC for interrupt routing
[ 0.393024] PCI: Using host bridge windows from ACPI; if necessary, use "pci
=nocrs" and report a bug
[ 0.455880] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.456084] acpi PNP0A03:00: fail to add MMCONFIG information, can't access
extended PCI configuration space under this bridge.
[ 0.457027] PCI host bridge to bus 0000:00
[ 0.458007] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.459006] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7]
[ 0.460006] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff]
[ 0.461006] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[ 0.462006] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
[ 0.463177] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[ 0.465677] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[ 0.468431] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[ 0.479007] pci 0000:00:01.1: reg 20: [io 0xc220-0xc22f]
[ 0.484653] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
[ 0.487130] pci 0000:00:01.3: quirk: [io 0xb000-0xb03f] claimed by PIIX4 AC
PI
[ 0.488064] pci 0000:00:01.3: quirk: [io 0xb100-0xb10f] claimed by PIIX4 SM
B
[ 0.489840] pci 0000:00:02.0: [5853:0001] type 00 class 0xff8000
[ 0.492006] pci 0000:00:02.0: reg 10: [io 0xc100-0xc1ff]
[ 0.495006] pci 0000:00:02.0: reg 14: [mem 0x88000000-0x88ffffff pref]
[ 0.506601] pci 0000:00:03.0: [1b36:0100] type 00 class 0x030000
[ 0.509007] pci 0000:00:03.0: reg 10: [mem 0x84000000-0x87ffffff]
[ 0.512006] pci 0000:00:03.0: reg 14: [mem 0x80000000-0x83ffffff]
[ 0.515006] pci 0000:00:03.0: reg 18: [mem 0x89000000-0x89001fff]
[ 0.518009] pci 0000:00:03.0: reg 1c: [io 0xc200-0xc21f]
[ 0.527466] acpi PNP0A03:00: ACPI _OSC support notification failed, disablin
g PCIe ASPM
[ 0.528007] acpi PNP0A03:00: Unable to request _OSC control (_OSC support ma
sk: 0x08)
[ 0.530272] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11)
[ 0.532987] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
[ 0.534960] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11)
[ 0.537311] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11)
[ 0.559950] ACPI: Enabled 2 GPEs in block 00 to 0F
[ 0.560010] acpi root: \_SB_.PCI0 notify handler is installed
[ 0.561092] Found 1 acpi root devices
[ 0.584419] ACPI: No dock devices found.
[ 0.585043] xen/balloon: Initialising balloon driver.
[ 0.587029] xen-balloon: Initialising balloon driver.
[ 0.588077] vgaarb: device added: PCI:0000:00:03.0,decodes=io+mem,owns=io+me
m,locks=none
[ 0.589008] vgaarb: loaded
[ 0.590009] vgaarb: bridge control possible 0000:00:03.0
[ 0.591102] SCSI subsystem initialized
[ 0.592007] ACPI: bus type ATA registered
[ 0.593036] libata version 3.00 loaded.
[ 0.594025] ACPI: bus type USB registered
[ 0.595021] usbcore: registered new interface driver usbfs
[ 0.596013] usbcore: registered new interface driver hub
[ 0.597023] usbcore: registered new device driver usb
[ 0.598058] PCI: Using ACPI for IRQ routing
[ 0.599006] PCI: pci_cache_line_size set to 64 bytes
[ 0.600261] pci 0000:00:02.0: no compatible bridge window for [mem 0x8800000
0-0x88ffffff pref]
[ 0.601060] pci 0000:00:03.0: no compatible bridge window for [mem 0x8400000
0-0x87ffffff]
[ 0.602007] pci 0000:00:03.0: no compatible bridge window for [mem 0x8000000
0-0x83ffffff]
[ 0.603007] pci 0000:00:03.0: no compatible bridge window for [mem 0x8900000
0-0x89001fff]
[ 0.604262] e820: reserve RAM buffer [mem 0x766c1000-0x77ffffff]
[ 0.605006] e820: reserve RAM buffer [mem 0x77b60000-0x77ffffff]
[ 0.606006] e820: reserve RAM buffer [mem 0x77fcf000-0x77ffffff]
[ 0.607109] NetLabel: Initializing
[ 0.608006] NetLabel: domain hash size = 128
[ 0.609005] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.610014] NetLabel: unlabeled traffic allowed by default
[ 0.611048] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[ 0.612022] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[ 0.614384] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[ 0.616015] Switching to clocksource xen
[ 0.622494] pnp: PnP ACPI init
[ 0.626721] ACPI: bus type PNP registered
[ 0.632269] pnp 00:00: disabling [mem 0x00000000-0x0009ffff] because it over
laps 0000:00:02.0 BAR 1 [mem 0x00000000-0x00ffffff pref]
[ 0.648507] pnp 00:00: disabling [mem 0x00000000-0x0009ffff disabled] becaus
e it overlaps 0000:00:03.0 BAR 0 [mem 0x00000000-0x03ffffff]
[ 0.664955] pnp 00:00: disabling [mem 0x00000000-0x0009ffff disabled] becaus
e it overlaps 0000:00:03.0 BAR 1 [mem 0x00000000-0x03ffffff]
[ 0.681624] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.691525] pnp 00:01: Plug and Play ACPI device, IDs PNP0103 (active)
[ 0.700375] system 00:02: [io 0x08a0-0x08a3] has been reserved
[ 0.708484] system 00:02: [io 0x0cc0-0x0ccf] has been reserved
[ 0.716454] system 00:02: [io 0x04d0-0x04d1] has been reserved
[ 0.724557] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.733497] pnp 00:03: [dma 4]
[ 0.737928] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)
[ 0.746881] xen: --> pirq=16 -> irq=8 (gsi=8)
[ 0.752885] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.761638] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)
[ 0.770811] xen: --> pirq=17 -> irq=12 (gsi=12)
[ 0.776995] pnp 00:06: Plug and Play ACPI device, IDs PNP0f13 (active)
[ 0.785868] xen: --> pirq=18 -> irq=1 (gsi=1)
[ 0.791839] pnp 00:07: Plug and Play ACPI device, IDs PNP0303 PNP030b (activ
e)
[ 0.801737] xen: --> pirq=19 -> irq=6 (gsi=6)
[ 0.807736] pnp 00:08: [dma 2]
[ 0.811965] pnp 00:08: Plug and Play ACPI device, IDs PNP0700 (active)
[ 0.820917] xen: --> pirq=20 -> irq=4 (gsi=4)
[ 0.827040] pnp 00:09: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.836082] system 00:0a: [io 0x10c0-0x1141] has been reserved
[ 0.844077] system 00:0a: [io 0xb044-0xb047] has been reserved
[ 0.852200] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.881856] pnp: PnP ACPI: found 11 devices
[ 0.887597] ACPI: bus type PNP unregistered
[ 0.901445] pci 0000:00:03.0: no compatible bridge window for [mem 0xffff000
0-0xffffffff pref]
[ 0.912946] pci 0000:00:03.0: BAR 0: assigned [mem 0xf0000000-0xf3ffffff]
[ 0.925616] pci 0000:00:03.0: BAR 1: assigned [mem 0xf4000000-0xf7ffffff]
[ 0.938055] pci 0000:00:02.0: BAR 1: assigned [mem 0xf8000000-0xf8ffffff pre
f]
[ 0.959648] pci 0000:00:03.0: BAR 6: assigned [mem 0xf9000000-0xf900ffff pre
f]
[ 0.969487] pci 0000:00:03.0: BAR 2: assigned [mem 0xf9010000-0xf9011fff]
[ 0.981822] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7]
[ 0.996100] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff]
[ 1.003714] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[ 1.012331] pci_bus 0000:00: resource 7 [mem 0xf0000000-0xfbffffff]
[ 1.028236] NET: Registered protocol family 2
[ 1.035193] TCP established hash table entries: 16384 (order: 6, 262144 byte
s)
[ 1.045164] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[ 1.060908] TCP: Hash tables configured (established 16384 bind 16384)
[ 1.069840] TCP: reno registered
[ 1.074634] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[ 1.082774] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[ 1.098864] NET: Registered protocol family 1
[ 1.104806] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[ 1.112880] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[ 1.120832] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[ 1.136045] pci 0000:00:03.0: Boot video device
[ 1.142326] PCI: CLS 0 bytes, default 64
[ 1.147902] Unpacking initramfs...
[ 5.777177] Freeing initrd memory: 32064k freed
[ 5.819680] Initialise system trusted keyring
[ 5.825892] audit: initializing netlink socket (disabled)
[ 5.833284] type=2000 audit(1383575196.154:1): initialized
[ 5.869085] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 5.886060] VFS: Disk quotas dquot_6.5.2
[ 5.891485] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 5.901156] msgmni has been set to 3717
[ 5.906505] SELinux: Registering netfilter hooks
[ 5.913981] alg: No test for stdrng (krng)
[ 5.926322] NET: Registered protocol family 38
[ 5.932389] Key type asymmetric registered
[ 5.937895] Asymmetric key parser 'x509' registered
[ 5.944518] Asymmetric key parser 'pefile' registered
[ 5.958054] Block layer SCSI generic (bsg) driver version 0.4 loaded (major
252)
[ 5.968579] io scheduler noop registered
[ 5.973886] io scheduler deadline registered
[ 5.979808] io scheduler cfq registered (default)
[ 5.992786] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 6.000452] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 6.009529] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 6.018393] acpiphp: Slot [0] registered
[ 6.030629] acpiphp: Slot [1] registered
[ 6.036176] acpiphp: Slot [2] registered
[ 6.041550] acpiphp: Slot [3] registered
[ 6.047070] acpiphp: Slot [4] registered
[ 6.052471] acpiphp: Slot [5] registered
[ 6.057875] acpiphp: Slot [6] registered
[ 6.070030] acpiphp: Slot [7] registered
[ 6.075415] acpiphp: Slot [8] registered
[ 6.080783] acpiphp: Slot [9] registered
[ 6.086158] acpiphp: Slot [10] registered
[ 6.091596] acpiphp: Slot [11] registered
[ 6.103881] acpiphp: Slot [12] registered
[ 6.109311] acpiphp: Slot [13] registered
[ 6.114715] acpiphp: Slot [14] registered
[ 6.120131] acpiphp: Slot [15] registered
[ 6.125735] acpiphp: Slot [16] registered
[ 6.137873] acpiphp: Slot [17] registered
[ 6.143350] acpiphp: Slot [18] registered
[ 6.148824] acpiphp: Slot [19] registered
[ 6.154233] acpiphp: Slot [20] registered
[ 6.159792] acpiphp: Slot [21] registered
[ 6.165408] acpiphp: Slot [22] registered
[ 6.177572] acpiphp: Slot [23] registered
[ 6.183073] acpiphp: Slot [24] registered
[ 6.188776] acpiphp: Slot [25] registered
[ 6.194393] acpiphp: Slot [26] registered
[ 6.199880] acpiphp: Slot [27] registered
[ 6.212090] acpiphp: Slot [28] registered
[ 6.217722] acpiphp: Slot [29] registered
[ 6.223748] acpiphp: Slot [30] registered
[ 6.229427] acpiphp: Slot [31] registered
[ 6.235544] efifb: probing for efifb
[ 6.247292] efifb: framebuffer at 0x84000000, mapped to 0xffffc90000400000,
using 1876k, total 1875k
[ 6.259444] efifb: mode is 800x600x32, linelength=3200, pages=1
[ 6.267314] efifb: scrolling: redraw
[ 6.272194] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 19.466665] Console: switching to colour frame buffer device 100x37
[ 31.233930] fb0: EFI VGA frame buffer device
[ 31.239899] intel_idle: does not run on family 6 model 30
[ 31.247340] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/in
put0
[ 31.257341] ACPI: Power Button [PWRF]
[ 31.269156] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/in
put1
[ 31.279223] ACPI: Sleep Button [SLPF]
[ 31.315850] GHES: HEST is not enabled!
[ 31.321392] xen: --> pirq=21 -> irq=24 (gsi=24)
[ 31.327640] Grant tables using version 1 layout.
[ 31.340791] Grant table initialized
[ 31.345989] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 31.391582] 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 31.403168] Non-volatile memory driver v1.3
[ 31.415625] Linux agpgart interface v0.103
[ 31.422837] loop: module loaded
[ 31.427286] ata_piix 0000:00:01.1: version 2.13
[ 31.433731] ata_piix 0000:00:01.1: setting latency timer to 64
[ 31.449070] scsi0 : ata_piix
[ 31.453156] scsi1 : ata_piix
[ 31.457217] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc220 irq 14
[ 31.466324] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc228 irq 15
[ 31.475587] libphy: Fixed MDIO Bus: probed
[ 31.488639] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 31.498056] ehci-pci: EHCI PCI platform driver
[ 31.504136] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 31.512527] uhci_hcd: USB Universal Host Controller Interface driver
[ 31.527839] usbcore: registered new interface driver usbserial
[ 31.535705] usbcore: registered new interface driver usbserial_generic
[ 31.544451] usbserial: USB Serial support registered for generic
[ 31.559411] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,
0x64 irq 1,12
[ 31.572601] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 31.579385] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 31.592997] mousedev: PS/2 mouse device common for all mice
[ 31.601524] input: AT Translated Set 2 keyboard as /devices/platform/i8042/s
erio0/input/input2
[ 31.615119] input: Xen Virtual Keyboard as /devices/virtual/input/input3
[ 31.636808] ata1.01: ATAPI: QEMU DVD-ROM, 1.6.1, max UDMA/100
[ 31.647224] ata1.01: configured for MWDMA2
[ 31.653628] input: Xen Virtual Pointer as /devices/virtual/input/input4
[ 31.656884] scsi 0:0:1:0: CD-ROM QEMU QEMU DVD-ROM 1.6. P
Q: 0 ANSI: 5
[ 31.667992] sr0: scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[ 31.667994] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 31.668073] sr 0:0:1:0: Attached scsi CD-ROM sr0
[ 31.669087] sr 0:0:1:0: Attached scsi generic sg0 type 5
[ 31.737154] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[ 31.745784] rtc_cmos 00:04: alarms up to one day, 114 bytes nvram, hpet irqs
[ 31.756846] device-mapper: uevent: version 1.0.3
[ 31.764279] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-
devel@redhat.com
[ 31.782948] cpuidle: using governor ladder
[ 31.789395] cpuidle: using governor menu
[ 31.798540] EFI Variables Facility v0.08 2004-May-17
[ 31.812440] hidraw: raw HID events driver (C) Jiri Kosina
[ 31.819769] usbcore: registered new interface driver usbhid
[ 31.827449] usbhid: USB HID core driver
[ 31.832791] drop_monitor: Initializing network drop monitor service
[ 31.849718] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 31.857237] TCP: cubic registered
[ 31.861841] Initializing XFRM netlink socket
[ 31.868075] NET: Registered protocol family 10
[ 31.881502] mip6: Mobile IPv6
[ 31.885694] NET: Registered protocol family 17
[ 31.892666] PM: Hibernation image not present or could not be loaded.
[ 31.901496] Loading compiled-in X.509 certificates
[ 31.909040] Loaded X.509 cert 'Fedora kernel signing key: 78fb4a79e920e6faab
7a0c9f59d1d38942b01496'
[ 31.928201] registered taskstats version 1
[ 31.934580] XENBUS: Device with no driver: device/vbd/768
[ 31.942052] XENBUS: Device with no driver: device/vbd/832
[ 31.956271] XENBUS: Device with no driver: device/vif/0
[ 31.963642] Magic number: 5:190:434
[ 31.968882] rtc_cmos 00:04: setting system clock to 2013-11-04 14:27:03 UTC
(1383575223)
[ 31.988678] Freeing unused kernel memory: 1352k freed
[ 31.996909] Write protecting the kernel read-only data: 12288k
[ 32.008369] Freeing unused kernel memory: 1708k freed
[ 32.025960] Freeing unused kernel memory: 1332k freed
[ 32.042341] systemd[1]: systemd 204 running in system mode. (+PAM +LIBWRAP +
AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
[ 32.067764] systemd[1]: Detected virtualization 'xen'.
[ 32.074886] systemd[1]: Running in initial RAM disk.
[ 32.099447] systemd[1]: No hostname configured.
[ 32.105545] systemd[1]: Set hostname to <localhost>.
[ 32.112479] systemd[1]: Initializing machine ID from random generator.
[ 32.133649] systemd[1]: Starting Timers.
[ 32.145404] systemd[1]: Reached target Timers.
[ 32.151504] systemd[1]: Starting Encrypted Volumes.
[ 32.172383] systemd[1]: Reached target Encrypted Volumes.
[ 32.179719] systemd[1]: Starting Journal Socket.
[ 32.192353] systemd[1]: Listening on Journal Socket.
[ 32.205890] systemd[1]: Starting dracut cmdline hook...
[ 32.218697] systemd[1]: Started Load Kernel Modules.
[ 32.225516] systemd[1]: Starting Journal Service...
[ 32.250965] systemd[1]: Started Journal Service.
[ 32.257529] systemd[1]: Starting udev Kernel Socket.
[ 32.278378] systemd[1]: Listening on udev Kernel Socket.
[ 32.286167] systemd[1]: Starting udev Control Socket.
[ 32.293317] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 32.301605] EDD information not available.
[ 32.321389] systemd[1]: Listening on udev Control Socket.
[ 32.328780] systemd[1]: Starting Sockets.
[ 32.339707] systemd[1]: Reached target Sockets.
[ 32.352728] systemd[1]: Starting Device-Mapper Multipath Device Controller..
.
[ 32.370542] systemd[1]: Starting Swap.
[ 32.386552] device-mapper: multipath: version 1.5.1 loaded
[ 32.398568] systemd[1]: Reached target Swap.
[ 32.405277] systemd[1]: Starting Local File Systems.
[ 32.426382] systemd[1]: Reached target Local File Systems.
[ 32.497159] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i804
2/serio1/input/input5
[ 32.557443] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 32.575459] Loading iSCSI transport class v2.0-870.
[ 32.587064] iscsi: registered transport (tcp)
[ 32.605285] alua: device handler registered
[ 32.613391] emc: device handler registered
[ 32.621428] hp_sw: device handler registered
[ 32.629714] rdac: device handler registered
[ 32.659671] FDC 0 is a S82078B
[ 32.674123] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 32.682296] EDD information not available.
[ 32.699810] No iBFT detected.
[ 32.713015] md: raid0 personality registered for level 0
[ 32.723044] md: raid1 personality registered for level 1
[ 32.732686] async_tx: api initialized (async)
[ 32.746735] xor: measuring software checksum speed
[ 32.763070] prefetch64-sse: 2336.000 MB/sec
[ 32.785062] generic_sse: 2264.000 MB/sec
[ 32.790927] xor: using function: prefetch64-sse (2336.000 MB/sec)
[ 32.819063] raid6: sse2x1 3207 MB/s
[ 32.841067] raid6: sse2x2 6343 MB/s
[ 32.869070] raid6: sse2x4 7085 MB/s
[ 32.874250] raid6: using algorithm sse2x4 (7085 MB/s)
[ 32.881122] raid6: using ssse3x2 recovery algorithm
[ 32.901087] md: raid6 personality registered for level 6
[ 32.908300] md: raid5 personality registered for level 5
[ 32.915601] md: raid4 personality registered for level 4
[ 32.934493] md: raid10 personality registered for level 10
[ 32.944254] md: linear personality registered for level -1
[ 32.965632] device-mapper: multipath round-robin: version 1.0.0 loaded
[ 32.998489] RPC: Registered named UNIX socket transport module.
[ 33.006598] RPC: Registered udp transport module.
[ 33.013177] RPC: Registered tcp transport module.
[ 33.019658] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 33.130001] systemd-udevd[254]: starting version 204
[ 33.257860] [drm] Initialized drm 1.1.0 20060810
[ 33.275382] Initialising Xen virtual ethernet driver.
[ 33.321201] blkfront: xvda: flush diskcache: enabled using persistent grants
[ 33.333466] vbd vbd-832: 19 xenbus_dev_probe on device/vbd/832
[ 33.343036] vbd vbd-832: failed to write error node for device/vbd/832 (19 x
enbus_dev_probe on device/vbd/832)
[ 33.343296] xen: --> pirq=22 -> irq=28 (gsi=28)
[ 33.382410] [drm] Device Version 0.0
[ 33.383038] xvda: unknown partition table
[ 33.402319] [drm] Compression level 0 log level 0
[ 33.411305] [drm] Currently using mode #0, list at 0x488
[ 33.419870] [drm] 12286 io pages at offset 0x1000000
[ 33.434475] [drm] 16777216 byte draw area at offset 0x0
[ 33.442706] [drm] RAM header offset: 0x3ffe000
[ 33.450321] [drm] rom modes offset 0x488 for 128 modes
[ 33.514103] [TTM] Zone kernel: Available graphics memory: 953940 kiB
[ 33.514104] [TTM] Initializing pool allocator
[ 33.514107] [TTM] Initializing DMA pool allocator
[ 33.514179] [drm] qxl: 16M of VRAM memory size
[ 33.514179] [drm] qxl: 63M of IO pages memory ready (VRAM domain)
[ 33.587644] [drm] main mem slot 1 [f0000000,3ffe000)
[ 33.588318] [drm] fb mappable at 0xF0000000, size 3145728
[ 33.588319] [drm] fb: depth 24, pitch 4096, width 1024, height 768
[ 33.588321] checking generic (84000000 1d5000) vs hw (f0000000 1000000)
[ 33.675614] fbcon: qxldrmfb (fb1) is primary device
[ 33.675616] fbcon: Remapping primary device, fb1, to tty 1-63
[ 34.143346] qxl 0000:00:03.0: fb1: qxldrmfb frame buffer device
[ 34.151570] qxl 0000:00:03.0: registered panic notifier
[ 34.158874] [drm] Initialized qxl 0.1.0 20120117 for 0000:00:03.0 on minor 0
[ OK ] Started Show Plymouth Boot Screen.
[ OK ] Reached target Paths.
[ OK ] Reached target Basic System.
dracut-initqueue[340]: mount: /dev/sr0 is write-protected, mounting read-only
[ 34.891223] ISO 9660 Extensions: Microsoft Joliet Level 3
[ 34.905655] ISO 9660 Extensions: RRIP_1991A
[ 35.156469] bio: create slab <bio-1> at 1
[ OK ] Started dracut initqueue hook.
Starting dracut pre-mount hook...
[ OK ] Started dracut pre-mount hook.
[ OK ] Reached target Initrd Root File System.
Starting Reload Configuration from the Real Root...
[ OK ] Started Reload Configuration from the Real Root.
[ OK ] Reached target Initrd File Systems.
Starting dracut mount hook...
[ 35.258137] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
(null)
[ OK ] Started dracut mount hook.
[ OK ] Reached target Initrd Default Target.
[ 35.533910] systemd-journald[66]: Received SIGTERM
[ 36.371712] SELinux: 2048 avtab hash slots, 100052 rules.
[ 36.396500] SELinux: 2048 avtab hash slots, 100052 rules.
[ 36.658401] SELinux: 8 users, 82 roles, 4468 types, 252 bools, 1 sens, 1024
cats
[ 36.671264] SELinux: 83 classes, 100052 rules
[ 36.683765] SELinux: Completing initialization.
[ 36.691465] SELinux: Setting up existing superblocks.
[ 36.699780] SELinux: initialized (dev sysfs, type sysfs), uses genfs_context
s
[ 36.711418] SELinux: initialized (dev rootfs, type rootfs), uses genfs_conte
xts
[ 36.723410] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
[ 36.734857] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[ 36.746123] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SI
Ds
[ 36.758468] SELinux: initialized (dev devtmpfs, type devtmpfs), uses transit
ion SIDs
[ 36.771685] SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
[ 36.782831] SELinux: initialized (dev debugfs, type debugfs), uses genfs_con
texts
[ 36.798281] SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
[ 36.809392] SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses
genfs_contexts
[ 36.822876] SELinux: initialized (dev devpts, type devpts), uses transition
SIDs
[ 36.835068] SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses trans
ition SIDs
[ 36.848043] SELinux: initialized (dev mqueue, type mqueue), uses transition
SIDs
[ 36.860250] SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs
_contexts
[ 36.873212] SELinux: initialized (dev sysfs, type sysfs), uses genfs_context
s
[ 36.885124] SELinux: initialized (dev securityfs, type securityfs), uses gen
fs_contexts
[ 36.898136] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SI
Ds
[ 36.909996] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SI
Ds
[ 36.922362] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SI
Ds
[ 36.934350] SELinux: initialized (dev cgroup, type cgroup), uses genfs_conte
xts
[ 36.946518] SELinux: initialized (dev pstore, type pstore), uses genfs_conte
xts
[ 36.958609] SELinux: initialized (dev efivarfs, type efivarfs), uses genfs_c
ontexts
[ 36.971260] SELinux: initialized (dev cgroup, type cgroup), uses genfs_conte
xts
[ 36.983150] SELinux: initialized (dev cgroup, type cgroup), uses genfs_conte
xts
[ 36.995246] SELinux: initialized (dev cgroup, type cgroup), uses genfs_conte
xts
[ 37.007343] SELinux: initialized (dev cgroup, type cgroup), uses genfs_conte
xts
[ 37.019109] SELinux: initialized (dev cgroup, type cgroup), uses genfs_conte
xts
[ 37.030982] SELinux: initialized (dev cgroup, type cgroup), uses genfs_conte
xts
[ 37.042984] SELinux: initialized (dev cgroup, type cgroup), uses genfs_conte
xts
[ 37.054824] SELinux: initialized (dev cgroup, type cgroup), uses genfs_conte
xts
[ 37.066642] SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses gen
fs_contexts
[ 37.079831] SELinux: initialized (dev sr0, type iso9660), uses genfs_context
s
[ 37.091610] SELinux: initialized (dev loop0, type squashfs), uses xattr
[ 37.102502] SELinux: initialized (dev dm-0, type ext4), uses xattr
[ 37.128460] type=1403 audit(1383575228.659:2): policy loaded auid=4294967295
ses=4294967295
[ 37.147591] systemd[1]: Successfully loaded SELinux policy in 1.100746s.
[ 37.233297] systemd[1]: Relabelled /dev and /run in 21.280ms.
Welcome to Fedora 19 (Schrödingerâs Cat)!
[ OK ] Stopped Switch Root.
[ OK ] Stopped target Switch Root.
[ OK ] Stopped target Initrd File Systems.
[ OK ] Stopped target Initrd Root File System.
[ OK ] Listening on Syslog Socket.
[ OK ] Listening on Delayed Shutdown Socket.
[ OK ] Listening on /dev/initctl Compatibility Named Pipe.
[ OK ] Listening on LVM2 metadata daemon socket.
Starting Create static device nodes in /dev...
[ OK ] Reached target Paths.
Mounting POSIX Message Queue File System...
[ 37.684982] SELinux: initialized (dev autofs, type autofs), uses genfs_conte
xts
[ OK ] Set up automount Arbitrary Executable File Formats F...utomount Point.
Mounting Huge Pages File System...
Mounting Debug File System...
Starting Apply Kernel Variables...
Mounting Configuration File System...
Starting Monitoring of LVM2 mirrors, snapshots etc. ...ress polling...
[ OK ] Listening on udev Kernel Socket.
[ OK ] Listening on udev Control Socket.
Starting udev Coldplug all Devices...
Starting Device-Mapper Multipath Device Controller...
[ OK ] Reached target Swap.
Starting Remount Root and Kernel File Systems...
Mounting Temporary Directory...
[ OK ] Stopped Trigger Flushing of Journal to Persistent Storage.
Stopping Journal Service...
[ OK ] Stopped Journal Service.
Starting Journal Service...
[ OK ] Started Journal Service.
[ OK ] Started Remount Root and Kernel File Systems.
Starting Import network configuration from initramfs...
Starting Configure read-only root support...
[ OK ] Started Apply Kernel Variables.
[ 38.083459] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SI
Ds
[ 38.083734] SELinux: initialized (dev configfs, type configfs), uses genfs_c
ontexts
[ 38.091716] SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses trans
ition SIDs
[ OK ] Mounted Temporary Directory.
[ OK ] Mounted POSIX Message Queue File System.
[ OK ] Mounted Huge Pages File System.
[ OK ] Mounted Debug File System.
[ OK ] Mounted Configuration File System.
[ OK ] Started udev Coldplug all Devices.
Starting udev Wait for Complete Device Initialization...
[ OK ] Started Create static device nodes in /dev.
Starting udev Kernel Device Manager...
[ OK ] Started Configure read-only root support.
Starting Load Random Seed...
[ OK ] Started Load Random Seed.
[ OK ] Started udev Kernel Device Manager.
[ OK ] Reached target Local File Systems (Pre).
[ 38.435351] systemd-udevd[589]: starting version 204
[ OK ] Started Import network configuration from initramfs.
Starting LVM2 metadata daemon...
[ OK ] Started LVM2 metadata daemon.
[ OK ] Started Device-Mapper Multipath Device Controller.
[ OK ] Started udev Wait for Complete Device Initialization.
Starting Activation of DM RAID sets...
[ OK ] Started Monitoring of LVM2 mirrors, snapshots etc. u...ogress polling.
[ 38.850031] microcode: CPU0 sig=0x106e5, pf=0x2, revision=0x5
[ OK ] Started Activation of DM RAID sets.
[ OK ] Reached target Local File Systems.
Starting Recreate Volatile Files and Directories...
Starting Trigger Flushing of Journal to Persistent Storage...
Starting Tell Plymouth To Write Out Runtime Data...
[ OK ] Reached target Encrypted Volumes.
[ 38.936922] piix4_smbus 0000:00:01.3: Host SMBus controller not enabled!
[ 38.983921] microcode: CPU1 sig=0x106e5, pf=0x2, revision=0x5
[ OK ] Started Trigger Flushing of Journal to Persistent Storage.
[ 38.998229] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet
.co.uk>, Peter Oruba
[ OK ] Started Tell Plymouth To Write Out Runtime Data.
[ 39.040281] type=1400 audit(1383575230.570:3): avc: denied { create } for
pid=629 comm="systemd-tmpfile" name="tmp" scontext=system_u:system_r:systemd_t
mpfiles_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir
[ 39.080322] type=1400 audit(1383575230.610:4): avc: denied { setattr } for
pid=629 comm="systemd-tmpfile" name="tmp" dev="dm-0" ino=34185 scontext=syste
m_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=d
ir
[ 39.122659] type=1400 audit(1383575230.652:5): avc: denied { relabelfrom }
for pid=629 comm="systemd-tmpfile" name="tmp" dev="dm-0" ino=34185 scontext=s
ystem_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:var_t:s0 tcla
ss=dir
[ OK ] Started Recreate Volatile Files and Directories.
[ OK ] Reached target System Initialization.
[ OK ] Reached target Timers.
[ OK ] Listening on Open-iSCSI iscsid Socket.
[ OK ] Listening on Avahi mDNS/DNS-SD Stack Activation Socket.
[ OK ] Listening on Open-iSCSI iscsiuio Socket.
[ OK ] Listening on D-Bus System Message Bus Socket.
[ OK ] Reached target Sockets.
[ OK ] Reached target Basic System.
Starting firewalld - dynamic firewall daemon...
Starting anaconda performance monitor...
[ OK ] Started anaconda performance monitor.
Starting Terminate Plymouth Boot Screen...
Starting Wait for Plymouth Boot Screen to Quit...
Starting System Logging Service...
[ 44.630892] type=1400 audit(1383575236.152:24): avc: denied { read write }
for pid=715 comm="auditd" path="/dev/mapper/control" dev="devtmpfs" ino=7083
scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:lvm_control_t
:s0 tclass=chr_file
[-- Attachment #4: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Limitation in HVM physmap
2013-11-04 14:08 ` Fabio Fantoni
@ 2013-11-04 14:14 ` Wei Liu
0 siblings, 0 replies; 36+ messages in thread
From: Wei Liu @ 2013-11-04 14:14 UTC (permalink / raw)
To: Fabio Fantoni
Cc: keir, Ian Campbell, Stefano Stabellini, George Dunlap, tim,
xen-devel, Jan Beulich, Wei Liu
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.
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2013-11-04 14:14 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-18 14:20 Limitation in HVM physmap Wei Liu
2013-10-18 14:26 ` George Dunlap
2013-10-18 15:12 ` Paul Durrant
2013-10-18 14:28 ` Tim Deegan
2013-10-18 14:36 ` Wei Liu
2013-10-18 14:41 ` Tim Deegan
2013-10-18 14:56 ` Wei Liu
2013-10-18 14:59 ` Ian Campbell
2013-10-18 15:00 ` Ian Campbell
2013-10-18 15:04 ` Wei Liu
2013-10-18 15:06 ` George Dunlap
2013-10-18 15:07 ` Wei Liu
2013-10-18 15:09 ` Ian Campbell
2013-10-18 15:14 ` Stefano Stabellini
2013-10-18 14:47 ` Jan Beulich
2013-10-18 15:01 ` Wei Liu
2013-10-18 15:07 ` Ian Campbell
2013-10-18 15:30 ` Wei Liu
2013-10-18 15:09 ` Jan Beulich
2013-11-01 12:21 ` Wei Liu
2013-11-01 12:26 ` George Dunlap
2013-11-01 12:33 ` Ian Campbell
2013-11-01 12:45 ` Wei Liu
2013-11-01 12:49 ` Ian Campbell
2013-11-01 14:08 ` Wei Liu
2013-11-01 14:12 ` Ian Campbell
2013-11-01 14:19 ` Wei Liu
2013-11-01 14:31 ` Ian Campbell
2013-11-01 14:55 ` Wei Liu
2013-11-01 15:04 ` Ian Campbell
2013-11-04 9:28 ` Fabio Fantoni
2013-11-04 11:42 ` Wei Liu
2013-11-04 12:05 ` Fabio Fantoni
2013-11-04 12:17 ` Wei Liu
2013-11-04 14:08 ` Fabio Fantoni
2013-11-04 14:14 ` Wei Liu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.