The issue with setting the WB/UC boundary at top of RAM rather than at 3.75G
is that this boundary is general no more than page-aligned. Hence you'd need
tens of variable MTRR ranges to express it; considerably more than the eight
which we supply. This is because of the requirement for each such range to
be power-of-two sized and aligned.
-- Keir
On 23/10/08 10:49, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
> Why take any notice of guest MTRR/PAT in cases where the host knows better?
>
> -- Keir
>
> On 23/10/08 10:36, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote:
>
>> In changeset 17471:cd5dc735bdf3(x86, hvm: Lots of MTRR/PAT emulation
>> cleanup),
>> the default memory type is set to WB and the type of each special memory
>> range
>> is set properly. Specially, [3.75G, 4G) is assumed as PCI space and marked as
>> UC.
>>
>> I meet with an issue:
>> When I "xm pci-attach" a NIC into RHEL5.1 Linux guest(memory=256M), the
>> virtual MMIO BAR assigned by guest starts from 0x20000000 and I don't find
>> guest kernel tries to set the MTRR registers at all; as a result, the type of
>> the pfn is WB, but in hypervisor, the host mfn is UC, so when guest accesses
>> the vBAR, there are many lines of such warnings printed:
>>
>> (XEN) mtrr.c:400:d10 Conflict occurs for a given guest l1e flags:163 at
>> 20000000 (the effective mm type:6), because the host mtrr type is:0
>>
>> Here I think the device should work normally since the actual host mfn is
>> UC,
>> but we might as well fix such inconsistency.
>> Can't we set the default type to UC?
>>
>> BTW: when I statically assign a NIC to guest via config file, since the vBAR
>> assigned by hvmloader starts from 0xF0000000, I don't see the warnings.
>>
>> Thanks,
>> -- Dexuan
>>
>>
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home