|
xen-devel
Re: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization
A couple of other comments:
1. I don't see any changes to shadow code to look at the _PAGE_PAT bit;
only _PAGE_PCD and _PAGE_PWT. Is this correct?
2. Introducing non-WB types for normal RAM is potentially a problem due to
attribute mismatches (E.g., mappings in Xen and mappings in qemu-dm). Do you
disallow non-WB types for RAM, or handle this in some other way? Disallow
would probably work fine except for a few cases like AGP GART.
Given that this is probably only safe for non-RAM pages, and given that
usually such mappings will be UC anyway, is there any advantage to this
large patch except accelerated access to passed-through video framebuffer
access? The current 'collapse all memory types to UC for non-RAM mappings'
is I believe always safe, and video framebuffer access is the only case I
can think of where there would be a performance loss that we might care
about. We could probably fix that with a much smaller patch with a higher
chance of acceptance for 3.2.0.
-- Keir
On 8/10/07 08:57, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:
> The second patch is a bit of a hack-and-slash job. New memory-type
> virtualisation code should go in a new file, instead of being put in host
> MTRR management files (which are mostly unmodified from Linux anyway, and
> shouldn't deviate more than necessary). There are various other one-line
> changes in various MTRR source files that are unexplained (e.g., mask
> changes from |0xf00 to |0x7ff). Initialisation of guest MTRR state will need
> to be moved to hvmloader -- we do not call setvcpucontext for HVM guests any
> more, so the current hack won't work with current xen-unstable. Coding style
> needs cleaning up (looks like there is some spaces vs. tabs mixing up going
> on).
>
> -- Keir
>
> On 8/10/07 08:34, "Su, Disheng" <disheng.su@xxxxxxxxx> wrote:
>
>> Hi,
>> The following 2 patches add basic MTRR/PAT support into
>> hypervisor. When vt-d enabled, direct IO and RAM
>> could be mapped to different cache attribute, such as UC or WC, which
>> will bring some trouble.
>> xen.patch: some data structures of MTRR in xen are exported.
>> mtrr_pat.patch: The basic idea is listed below:
>> a. MTRR/PAT MSRs are per vcpu. The value of guest MTRR is
>> initialized in host, after guest E820 table is build. The value of guest
>> PAT is initialized as default. The host PAT is initialized to cover all
>> the page attributes.
>> b. The guest page attribute is virtualized through shadow page
>> attribute. First, get the effective guest page attribute, by calculating
>> from the combination of guest MTRR/PAT. Then the shadow page attribute
>> is calculated from effective guest page attribute and host MTRR. If
>> conflict occurs(e.g effective guest page attribute is WB, host MTRR of
>> this range is UC, can't set this page attribute as guest required), set
>> this range as UC. Some lookup tables are added to accelerate above
>> procedure.
>>
>> Signed-off-by: Disheng Su <disheng.su@xxxxxxxxx>
>>
>> Best Regards,
>> Disheng, Su
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home