Re: [Xen-devel] XSA-60 solutions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.10.13 at 18:03, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> Jan Beulich wrote:
>>>>> On 07.10.13 at 16:29, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>>> wrote: Any comments/suggestions? 
>> 
>> As pointed out in earlier private conversation, I think that the dual
>> table approach would be preferable if it can be made work.
> 
> No, solution 2 has an important update compared with our private 
> conversation before:
> The old solution 2 is, Xen do nothing for guest cr0.cd setting.
> The new solution 2 in this email is, Xen set IA32_PAT fields as UC when 
> needed (that means, only when guest work with vt-d but vt-d non-snooped, 
> since 
> under this case h/w can not guarantee cache coherency), so that all guest 
> memory type are UC. For other cases (when guest work w/o vt-d, and when guest 
> work with vt-d but vt-d snooped), Xen can still do nothing for guest cr0.cd 
> setting (since h/w has guaranteed cache coherency, otherwise Xen doesn't dare 
> to do what it does now -- it set iPAT bit as 1, totally ignoring guest memory 
> type point of view).
> 
> Compared with Dual-EPT solution, it's much simpler (only need IA32_PAT MSR 
> emulation under rare case) and avoid the inconsistency issue between 2 EPT 
> tables.

Right - as long as PAT is guaranteed to only be used for guest
induced memory accesses, that sounds like a viable yet not too
intrusive solution. Short of anyone else having an opinion here,
why don't you start drafting a patch for this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel