Re: [Xen-devel] Guest-vs-Host MTRR/PAT conflict and a crash?

["David Stone" <unclestoner@xxxxxxxxx>]

On Jan 2, 2008 11:55 PM, Su, Disheng <disheng.su@xxxxxxxxx> wrote:
>
> > So my first question is, does anyone have a guess as to what this 64KB
> > region assigned to the graphics card is for?  I assume the 256MB
> > region is the general-purpose video memory for textures, vertices,
> > etc.
> 64KB region is GART?(just guess:)
That would make sense, I had not thought of that.

> > The mtrr warning message happens when the shadow page table is getting
> > updated as the guest is trying to update his page tables.  But why
> > would the guest only update the PTE at the beginning of the 64KB
> > region, and not all 64KB/4KB=16 PTEs in the region?  I assume the
> > guest isn't updating them all, because then I would get 16 of the mtrr
> > warning messages?  I wonder if the guest is updating the page table
> > (causing the MTRR warning but succeeding), and then trying to
> > read/write from that page, and this is timing out causing the machine
> > check?
> Why the guest thinks this region as WB? Is it already wrong in there?

OK, I did some more tracing based on your question and now I think I
_may_ see a problem.  Anyway:

The guest thinks the memory is WB because the guest has a single
(virtual) variable-range MTRR that specifies the addresses
0x00000000-0x40000000 are WB.  0x10000000 falls in this range.  This
MTRR is coming from the guest's (emulated?) E820.
This in turn is coming from the "memory" directive in the domain's
configuration file...I am specifying memory='1024' which is 1GB which
is 0x00000000-0x40000000.  So, the emulated E820 is reporting the
bottom 1GB as available, and an MTRR is getting created to represent
this area as WB.

On the other hand the hypervisor says the memory is uncacheable
because the host has three variable range MTRRs:
 - The first specifies the entire 32-bit address range as WB
 - A second overrides the first for 0x7df00000-0x7dffffff as uncacheable
 - A third overrides the first for 0x80000000-0xfffffff s uncacheable.
These set of MTRRs seem to be standard for bare-metal Linux, Dom0
Linux, and the Xen hypervisor.

So, the guest address of 0x10000000 is WB according to the guest's
MTRRs.  The corresponding host address 0x80020000 is uncacheable
according to the hypervisor's MTRRs.

But hold on...this excercise made me realize that it appears the guest
is programming the graphics card's BAR with an address (guest-physical
address of 0x10000000) that is within the guest's system memory (lower
1GB of guest-physical address space, 0x00000000-0x40000000).  Can
someone out there throw me a bone and tell me that I'm right in
thinking this should never happen?

Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel