Re: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 9/10/07 05:38, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:

> But, yes this is really a good point. So we need to do WBINVD when VP
> migrates (of course for pass-through domain only), while the prefered
> approach is to pin VCPU on pCPUs.

Or WBINVD all CPUs when a VCPU executes WBINVD. Or explicitly track dirty
caches for each vCPU.
 
>> We get no benefit for non-pass-thru domains and some concern about
>> correctness. 
> Yes, we can do in this way.

Good.

> For a native OS, will OS unconditionally map the whole memory itself?
> I think no, otherwise same issue will happen to native OS.

Yup. This issue was fixed in Linux back in 2.4.

> BTW, if we don't remove those fixed 1:1 mapping, even without MTRR
> patch, we may meet problem in future when there are complicated drivers
> in domain0. E.g. high end graphics driver in domain0 may use UC for its
> batch
> buffer, same for audio driver and other PCIe drivers in future.
> Processor will see 2 different memory attribute in its direct page
> table.

Yup. Jan Beulich posted a patch some time ago. At least some variant of that
is certainly needed and I plan to put that in before 3.2.0.

> Do u mean AMD processor support speculative write? I don't think
> Intel processor support this.

A speculative store is never made visible to other processors of course.
That would be hard to roll back! However the data can be safely prefetched
into the cache and it is then an implementation detail as to whether the
processor 'optimistically' marks the cache line as dirty before the
speculated store is actually executed (rather than discarded).

> I may lose here. The MTRR patch only tighten the memory
> access attribute, never loosen it, so we are toward much safer
> direction, isn't it?

Yes, that may be true. I don't think that mismatching attributes can cause
system stability issues except in very special circumstances where having
all attributes as WB is no safer.

> Anyway, we can split the patch into 2, one for MMIO only and
> another one for both with RAM. Probably the patch is almost
> same, just one line to eliminate the RAM mmeory type propogatio.

If you need both then may as well enable both in the same patch. Just make
it for pass-thru domains only, clean up the patch as I described before, and
I'll be happy. Probably.

 -- Keir



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